Security certification includes assessing an information system to verify its compliance with diverse, pre-selected security controls. The goal of certification is to identify where controls are implemented correctly and where they are violated, creating potential vulnerability risks. Certification complexity is magnified in software composed of systems of systems where there are limited formal methodologies to express management policies, given a set of security control properties, and verify them against the interaction of the participating components and their individual security policy implementations. In this paper, we extend Context UNITY, a formal, distributed, and context aware coordination language to support policy controls. The new language features enforce security controls and provide a means to declare policy specifics in a manner similar to declaring variable types. We use these features in a specification to show how verifying system compliance with selected security controls, such as those found in the NIST SP800-53 document, can be accomplished.
Increasing integration services can improve opportunistic development by presenting monolith applications as opportunities for mashups. Opportunities are available resources that yield desired results. Their suitability depends on who seizes the opportunity and the context for its use. Opportunistic development relies on the availability of reusable software components to produce hybrid applications that opportunistically join such components to meet immediate functional or content needs. 1 Availability and connectivity are key qualities of an opportunity. 2 Situational assessment determines when the best available, most deployable opportunities exist within time and resource constraints. 3 This article examines opportunistic development from an enterprise perspective in which the reusable resources are called opportunistic assets. We define fitness criteria for classifying resources according to their potential as opportunistic assets. We consider the roles of the monolith and the mashup in opportunistic development. Monoliths are large, self-contained software applications that control significant data and processing components. Mashups are Web application hybrids that consume opportunistic assets. Developers of end-user mashups choose APIs from multiple providers to weave a new application, joining content and functionality. The more opportunistic assets there are, the faster the resulting application comes together. Often, providers expose services as part of the growing trend of modern monoliths, scalable software applications from Internet companies that offer a wide range of useful services. Unfortunately, the range of reuse opportunities doesn't extend to enterprise mashups, where hybrid-application development relies on legacy monoliths of industry IT for robust functions that ensure quality of service (QoS) in the resulting software.Monoliths produce opportunistic assets when they expose key functions that are easy to mash. Reusing legacy monoliths poses integration problems, however. More than a surface interoperability analysis is required, leading to longer development times and missed opportunities when enterprise mashups are evaluated against the quick deployment and innovative outcomes of end-user mashups. To reduce this integration barrier, we advocate elevating integration strategies to first-class opportunistic assets. These assets can present monolith applications as opportunities for mashups. Opportunistic AssetsTo reuse existing software artifacts (components, services, data, and so on), developers must determine which features are most important in a given situation. This assessment is per reuse artifact type and within a window of opportunity. It determines when an artifact is an opportunistic asset. Concerns beyond functionality come into play,
Software composition relies heavily on the ability to reuse software within the context of a complex target system. When components are built or sourced from third party suppliers, some form of design material is reused that embodies a variety of artifacts that differ in both granularity and abstraction. The more concrete the design material, particularly if it is in the form of a fully realized reusable component, the more likely it has evolved from a distinct supplier development path that will cause interoperability problems in the composite design. Unfortunately, recognizing integration problems occurs late in a typical design process, often disrupting the process of choosing alternative components. We express the design reuse process using a concept map whose nodes represent sources of design material. Guidance for consolidating and analyzing reuse alternatives is shown via design moves between concepts culminating in the choice of components for the target system. We use isolation as the determinant for interoperability assessment. Leveraging a biological analogy, we define distinct integration levels where isolating mechanisms occur to add assessment clarity. This is illustrated with an example showing conflicts between reusable components from different suppliers. Copyright © 2008 John Wiley & Sons, Ltd.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.