Abstract:
There are provided systems and methods for integrating requirements driven security code into an application system. The security code is integrated into an application system in such a way as to make the integrated security code maintainable and traceable as the application system evolves over time.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of prior filed co-pending U.S. application Ser. No. 60/816,456, filed on Jun. 23, 2006, the entirety of which is hereby incorporated by reference. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates generally to the field of security requirements in software systems and, more particularly, to methods and systems for implementing security requirements into application code. 
         [0004]    2. Description of the Related Art 
         [0005]    Security evaluations for software systems can be time consuming and expensive endeavors. In particular, the tracing of security requirements into code and the accurate maintenance of that mapping as a system evolves over time can be tedious and error-prone. It has been generally recommended to those who wish to have secure systems that they should integrate the required security functionality into their system designs at the earliest possible stages of the process. However, even when the full complement of security requirements are known in advance, the manner in which security functionality is traditionally integrated, which is via largely manual methods, can cause its own problems. Such problems can make assurance claims more difficult to support and result in systems which are more difficult to understand, evolve, and ultimately to certify and accredit from a security perspective. 
         [0006]    In a typical process, the integration of software functionality into a software application adheres to the following general approach. First, a risk analysis is performed to determine threats and a likelihood of realizing those threats based on a characterization of the adversary. Second, security requirements are documented for the system to counter selected threats. Third, appropriate software security mechanisms are selected to meet the requirements established at the second step and minimize the vulnerabilities to the threats. Fourth, the security mechanisms are integrated throughout the system under construction. Lastly, the system is tested and results are documented for stakeholders, such as security evaluators and accreditors. The described process may be repeated as the system, the information processed, and risks evolve over time. It should be appreciated that the described process can be difficult to realize with precision in the real world. 
         [0007]    The present invention addresses the fourth step of integrating security mechanisms throughout the system. It is at this step where certain difficulties can occur. One problem is that developers may lack the expertise to integrate security mechanisms in a proper fashion. In addition, many types of security functionality permeate the various parts of a complex application, with different software application developers responsible for those different parts. As the various developers implement similar security code in different places throughout the system, classic “code scattering” and “code tangling” problems often result, thus complicating evolution and tracking of such security mechanisms (i.e., code). These problems are typical of functionality that cuts across systems. Code scattering refers to like functionality which is needed across a system. References to such functionality show up in numerous places, complicating the maintenance/evolution of such code. Code tangling refers to such functionality becoming necessarily mixed in with code whose main purpose is to accomplish some goal unrelated to security. 
         [0008]    Another consequence of the difficulty of integrating security mechanisms into application code is demonstrating to a security evaluator that such integration clearly maps back to original security-related requirements derived from the risk analysis. It can be easy for developers to miss integration points entirely; this is especially true as new code is added to a system subsequent to the initial integration of security countermeasures. Furthermore, should the details of a security mechanism&#39;s invocation change, developers are forced to revisit all the different places in the system where such invocations occur, with the consequence that certain updates may be missed. 
         [0009]    As one example, consider an access control check in a finance application implemented as a service-oriented architecture. One might have access control checks for a wide variety of actions within such a system, from viewing certain reports, to updating accounting entries, exporting data to other systems, and performing system maintenance procedures. Suppose, for example, that there are twenty services in the architecture, six operations/service which require an access control check, and two lines of code per access control check. The result is an additional 240 lines of code (LOC) in the system to ensure that access control checks are invoked where needed. Such code is replicated across 120 distinct places (code scattering) where the operations are implemented. Furthermore, the focus of each operation is not access control but some other goal, such as report generation, so authorization checking code is mixed in with application code (code tangling). Besides access control, other common security tasks may include, logging/time-stamping/auditing, authentication checks, “just-in-time” encryption and decryption, message authentication code and signature generation and verification, locking and unlocking of critical data structures, session time-out checks, and assertion checks. In any given application function, multiple of these security tasks may be present, further exacerbating code scattering and code tangling problems. 
         [0010]    Using the above example but expanding the average number of security-related tasks to five per service operation, the total lines of security-related code that are scattered/tangled rises to 1,200 LOC. This calculation only accounts for top-level services and ignores similar code in underlying software layers and supporting class libraries. 
         [0011]    The security functionality described above is just one example of what are known as “cross cutting concerns” (CCCs). CCCs represent functionality found throughout systems that are difficult to modularize using traditional programming languages, including object-oriented languages, resulting in the code scattering and tangling properties discussed above. 
       SUMMARY OF THE INVENTION 
       [0012]    Therefore, the present invention has been made in view of the above problems. Accordingly, the present invention provides computer-implemented methods and systems for integrating requirements driven security code into an application system. The security code is integrated into an application system in such a way as to make the integrated security code maintainable and traceable as the application system evolves over time. 
         [0013]    According to one aspect of the invention, integration of security code into a code base of an application system comprises tagging various language-level constructs of the code base, such as classes, methods and instance variables, using annotation mechanisms. In this usage, each annotation label unambiguously maps code which implements a security requirement to target application code in which the security code is to be integrated. The tagging process itself is preferably performed in an automation-assisted manner. Annotations are tagged to the application code base in accordance with the tagging process to provide an accurate mapping of security code in the aspects to the application code base where security requirements must be met. The annotation mechanisms represent a form of meta-data. 
         [0014]    According to a related aspect of the invention, a software tool is provided to allow a developer to quickly label various language-level constructs with annotations in an automation-assisted manner. The various language-level constructs are quickly labeled with the annotations described above with the assistance of simple search wizards. That is, after a programmer identifies where the files containing the source code reside, the programmer can then iteratively enter search keywords. The software tool then finds matches within the identified code base. The programmer can review these matches, one by one, and indicate to the software tool whether the code should be “branded” with an annotation or not. 
         [0015]    In one embodiment, the software tool consists of a four-paneled window, where the window represents a particular software development “project”. As will be described in greater detail below, the first (left-most) panel shows a listing of security requirements. A second panel shows the same security requirements listed in a hierarchical form, a third panel shows a list of aspects, which represent a new form of code modularity that is orthogonal to traditional classes in object-oriented languages. Each aspect contains code that meets a security requirement. 
         [0016]    A primary advantage provided by the invention is a process for raising the assurance level of software via clear traceability of security requirements to security code, and an unambiguous mapping of security code to target application code base. Another related advantage of the invention is in lowering the cost and expense of security evaluations with the rationale that security evaluators can now very clearly trace security requirements into code and back again, even as security requirements and the application code base evolve over time. Other ancillary advantages include a reduction of code bulk, ease of maintenance, and improved separation of duties between security developers and application code developers, assisting developers to integrate cross-cutting concerns more effectively, reduce time and expense of conducting security evaluations by reducing the amount of security-critical code to be evaluated and showing up-to-date traceability from security requirements to security-critical functions implementation. 
         [0017]    As will be apparent, the present invention may generally benefit security analysts/security software developers and application developers by streamlining the coordination of integrating security related requirements into application code. The present invention may also benefit security evaluators for reasons described above. Other beneficiaries include system evaluators/certifiers, and system accreditors. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0018]    These and other objects, features and advantages of the invention will be apparent from a consideration of the following Detailed Description Of The Invention considered in conjunction with the drawing Figures, in which: 
           [0019]      FIG. 1  is a diagram of a process directed to the automation-assisted integration of requirements-driven security functionality into an existing software application code base; 
           [0020]      FIG. 2  is a diagram illustrates there is shown a common requirements decomposition scheme found in Common Criteria, which the process, as depicted in  FIG. 1 , can support; 
           [0021]      FIG. 3  there is shown a snapshot of a typical GUI interface  300  of the software tool of the invention; 
           [0022]      FIG. 4  is a listing of exemplary XML Schema which may be used to create the underlying XML file, according to one embodiment; 
           [0023]      FIG. 5  is a flow diagram illustrating an exemplary operational flow of the software tool, according to one embodiment. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0024]    1. Introduction 
         [0025]    In the following discussion, numerous specific details are set forth to provide a thorough understanding of the present invention. However, those skilled in the art will appreciate that the present invention may be practiced without such specific details. In other instances, well-known elements have been illustrated in schematic or block diagram form in order not to obscure the present invention in unnecessary detail. Additionally, for the most part, details concerning network communications, electromagnetic signaling techniques, and the like, have been omitted inasmuch as such details are not considered necessary to obtain a complete understanding of the present invention and are considered to be within the understanding of persons of ordinary skill in the relevant art. 
         [0026]    It is further noted that, unless indicated otherwise, all functions described herein may be performed in either hardware or software, or some combination thereof. In a preferred embodiment, however, the functions are performed by a processor, such as a computer or an electronic data processor, in accordance with code, such as computer program code, software, and/or integrated circuits that are coded to perform such functions, unless indicated otherwise. 
         [0027]    It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium such as a computer readable storage medium or a computer network where program instructions are sent over optical or electronic communication links. Several inventive embodiments of the present invention are described below. 
         [0028]    The following paragraphs describe an overview of the invention and a software tool for storing and executing software in accordance with an illustrative embodiment of the invention. 
         [0029]    2. Overview 
         [0030]    In accordance with the present invention, there are provided herein methods and systems for integrating requirements-driven security code into an application system. The methods and systems facilitate the traceability of software requirements from their initial declaration to their implementation in code to the integration of that code into an existing target application software code base. Software requirement traceability is facilitated in part by aspect-oriented programming and programming language annotation mechanisms. A key advantage of providing such traceability is to assist security evaluators, security developers, application developers and other stakeholders to gain confidence that security requirements have been met. 
         [0031]    Referring now to the drawings,  FIG. 1  provides a process overview of a process directed to the automation-assisted integration of requirements-driven security functionality into an existing software application code base. 
         [0032]      FIG. 1  illustrates in the upper left hand corner, a requirements tree  102 . The requirements tree  102  comprises a set of security-related requirements for a software application (i.e., “project”) based on a risk/threat analysis. 
         [0033]    Generally, the integration of security functionality into a software application begins by performing a risk/threat analysis to determine threats and the likelihood of the realization of threats. An experienced security analyst considers potential threats to information confidentiality, integrity and availability. The analyst then assesses the likelihood and impact of such threats being realized and how those threats should be addressed in the context of a given environment in order to minimize vulnerabilities. Next, the analyst develops a strategy for handling the identified threats. All threats deserve scrutiny, with particular attention to those threats believed to be of higher likelihood and impact to the organization. Common responses to threats are: ignore the threats (i.e., absorb any losses), indemnify oneself from the threat (e.g., purchase insurance), and/or adopt active countermeasures to lower the risk of the threat being realized. The present invention addresses this last option, namely, the adoption of active countermeasures to lower the risk of the threat being realized. 
         [0034]    Continuing with  FIG. 1 , the requirements tree  102  is illustrated in a hierarchical form, with a security threat (T) implying the need to meet certain high level security objectives (O), which lead to higher and lower level security requirements (H) and (L). It is noted from the hierarchically organized requirements tree  102  that the lower level requirements (L) may appear in different parts of the same hierarchical depiction. 
         [0035]    Security analysts and security developers work together to identify which security requirements (e.g., L 6 ) from the requirements tree require that code be implemented to meet the requirement. The security developer then creates an aspect (e.g., aspect  14  ( 106 )) for each of the identified requirements. Working with application developers, the security developer then marks via marker annotations those places (e.g., certain methods in certain classes) in the application code bases where the code from each aspect is required to be inserted. The actual insertion is itself an automated process carried out by the aspect pre-compiler or compiler. 
         [0036]    With reference now to  FIG. 2 , there is shown a common requirements decomposition scheme  200  found in Common Criteria, which the process, as depicted in  FIG. 1 , can support. Common Criteria is well known to those knowledgeable in the art as an international standard for describing a framework for representing security requirements. The common requirements decomposition scheme  200 , sometimes referred to as a traceability mapping, illustrates one particular way in which security requirements may be structured. In other words, it provides a design trace from security threats to the various places in code where an aspect could be integrated. It should be appreciated that other evaluation approaches for measuring software assurance may be used. However, the Common criteria decomposition scheme  200  is illustrated in the instant example, given that it is an internationally recognized evaluation approach for measuring software assurance. 
         [0037]    Due to the afore-mentioned cross-cutting nature of security requirements in a system, so-called aspects, which are well known to those knowledgeable in the computer arts, are abstraction mechanisms which are typically added as extensions to existing object-oriented programming languages, as an implementation strategy for capturing code for the implementation of cross cutting concerns, of which security requirement implementation is an example. More particularly, aspects are typically used in conjunction with standard aspect predicate matching to automatically integrate the aspect code into the application code base. For example, with reference again to  FIG. 1 , “Aspect  14 ” is created to implement security requirement L 6 . A problem arises, however, in that a common approach to identifying the various places in code where an aspect could be integrated, known as join points, is usually done by certain search predicate expressions, known as pointcuts. Different aspect languages offer different facilities with respect to how one specifies pointcuts, but a general concern is the matching accuracy, or lack thereof, of such pointcut expressions. 
         [0038]    By way of reference, a pointcut is a structure of an aspect language that denotes a set of so called joinpoints. A joinpoint is a place in program execution where an aspect component (AC) needs to be integrated. The aspect component represents a segment of code which addresses a particular security requirement at a specific jointpoint. Hence, by defining a pointcut for an AC, one defines the locations where an AC is to be woven by a pointcut weaver. Different aspect languages offer different facilities with respect to how one specifies pointcuts, but a general concern is the accuracy of such pointcut expressions. Such expressions may overshoot, i.e., include certain integration points where functionality is not needed, or undershoot, i.e., miss certain integration points where function is needed. The inventor has overcome this problem by deriving a method to increase the accuracy of the aspect-to-code mapping problem. Specifically, the inventor has proposed to simplify pointcut expressions via the use of annotations. Languages such as Java and C# now support the addition of annotations at the source code level. Annotations provide the ability to supply meta-data to describe various language level constructs, such as classes and methods, for a variety of purposes. The simplest form of annotation is a “marker annotation” which simply associates an identifier with a language level construct. The inventor has recognized that marker annotations may be leveraged as a means to accurately map aspects into code via pointcuts. This is illustrated as follows. 
         [0039]    The following code segment, illustrates, by way of example and not limitation, how to create a simple annotation, called a marker annotation in Java 5. The method “someMethod( )” of class “SomeClass” requires that an authentication check be made as part of its implementation. In the present example, AuthenticationCheck( ) represents the marker annotation which is associated with the language level construct, the Public class, “SomeClass”. 
         [0000]    
       
         
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 Public @interface AuthenticationCheck( ) 
               
               
                   
                 ...... 
               
               
                   
                 Public class SomeClass { 
               
             
          
           
               
                   
                 @AuthenticationCheck 
               
               
                   
                 Void someMethod ( ) (....) 
               
             
          
           
               
                   
                 ...... 
               
               
                   
                 } 
               
               
                   
                   
               
             
          
         
       
     
         [0040]    Hence, automated integration is ideally realized via such marker annotations due to their pinpoint accuracy, assuming the selection of unique names for the marker annotations. Note that it is necessary, of course, for security developers and application developers to coordinate on the places in the application code (e.g., certain methods of certain classes). However, once those places have been identified, marker annotations can provide an accurate mapping of aspects into such code. 
         [0041]    3. Software Tool 
         [0042]    According to one aspect, the present invention provides a software tool to allow a developer to quickly label various language-level constructs with marker annotations in an automation-assisted manner. In a preferred embodiment, the software tool generally operates by identifying various language-level constructs using a search wizard to quickly label the various language-level constructs with the marker annotations. In other words, after a programmer identifies where the files containing the application source code reside, the programmer can then iteratively enter search keywords. The programmer, using the search wizards, finds matches by iteratively searching through the application code base. The programmer can manually review the resulting matches one by one, and indicate to the software tool whether the application code in question should be “branded” with the respective marker annotation or not. 
         [0043]    The labeling operation performed by the software tool occurs as a necessary foundational step to facilitate the next sequential process during which security code (previously created aspects) is weaved into the application code. Note, however, that this weaving process is not performed by the software tool, but is instead performed using an aspects add-on (e.g., AspectJ) to the software development environment which a developer uses in conjunction with a programming language compiler. In various embodiments, AspectJ can be a program invoked via a command line, or may otherwise be added into an Integrated Development Environment (IDE) via a plug-in. 
         [0044]    Referring now to  FIG. 3 , there is shown a snapshot of a typical GUI interface  300  of the software tool of the invention, according to one embodiment. The GUI interface  300  is divided into four general regions  302 ,  304 ,  306  and  308  to be described as follows. 
         [0045]    GUI—First Screen Region  302   
         [0046]    A first screen region  302  of the GUI interface  300  corresponds to the left-most pane of the GUI  300 . This first region  302  is a data entry area allowing a user (i.e., security program person) to enter or import security requirements into the software tool. 
         [0047]    GUI—Second Screen Region  304   
         [0048]    A second screen region  304  of the GUI interface  300  allows the user to relate the requirements entered in the first screen region  302  See  FIG. 3  for labeling of screen regions in a hierarchical fashion. While the first screen region  302  is a simple linear list, a programmer, using the second screen region forms a hierarchy based on a relationship that the programmer knows about the security requirements. For example, knowing to place lower level requirements beneath higher level requirements. It is noted that a given requirement in the left-most panel can appear more than once in the resulting hierarchy. 
         [0049]    Third Screen Region  306   
         [0050]    A third screen region  306  of the GUI interface  300  is used to identify aspects that should be developed by a security software developer to be made available to implement the security requirements identified in the first screen region  302 . In the present embodiment, the aspects are created external to the software tool, however, it is contemplated to integrate the creation of aspects within the tool in other embodiments. 
         [0051]    By double-clicking the mouse on a requirement in the second screen region  304 , a dialog box appears (not shown) which allows the developer to identify the aspect that implements the requirement. The dialog box consists of an optional “rationale field” to explain the reason that a requirement exists in the hierarchy displayed in the second screen region  304 . The dialog box is followed by a drop-down list box, displayed to the user, which lists all of the aspects from the aspects list. The programmer simply selects the aspect corresponding to the requirement that was previously clicked on. Otherwise, the programmer leaves the aspect list box on the default selection of “Not Selected”. By double-clicking the mouse on an aspect, a dialog box appears that has various tabs. One tab describes the aspect overall (e.g., its name, description, and unique identifier). Another tab allows the user to search an identified code base for places in the source code that should be marked with a marker annotation. The marker annotation identifies that the corresponding aspect should be automatically integrated into the code 
         [0052]    Fourth Screen Region  308   
         [0053]    A fourth screen region  308  of the GUI interface  300  is used to allow the programmer to identify the location of the application code base into which the aspects will be automatically woven based on the marker annotations. 
         [0054]    Compilation 
         [0055]    Finally, the programmer compiles the system, taking care to employ the appropriate aspect preprocessor to carry out the automatic weaving of the aspects into the application code base. 
         [0056]    XML File 
         [0057]    The software tool stores all the information on a “project” in an underlying XML file, which only includes meta-data defining the elements to name the requirements and their types, meta-data relating the requirements to one another and to an implementing aspect, and an enumeration of the aspects themselves. It should be understood, however, that the XML file does not contain the code for the aspect; such code resides in ordinary source code files. 
         [0058]      FIG. 4  is a listing of exemplary XML Schema which may be used to create the underlying XML file, according to one embodiment. In other words, the XML Schema spells out the rules for how the underlying XML file is to be properly formed. An XML parser in the tool automatically checks XML files against the Schema for proper structure. 
         [0059]    4. Operational Flow 
         [0060]      FIG. 5  is a flow diagram illustrating an exemplary operational flow  500  of the software tool to allow a developer to quickly label various language-level constructs with marker annotations in an automation-assisted manner according to one embodiment. 
         [0061]    Operational flow  500  begins at step  502  where a collection of related security requirements for a system are entered or imported into the software tool, referred to above. 
         [0062]    Next, at step  504 , for each “actionable” requirement (some requirements are not directly implemented, such as requirements located close to the root of the requirements tree), author an aspect that implements the code for the requirement. In the present embodiment, the authoring of aspects occurs outside of the scope of the software tool. In this manner, a programmer may use a software development environment that includes an aspect add-on, such as, for example, Eclipse™ with AspectJ. As stated above, it is also contemplated to author aspects within the software tool environment. 
         [0063]    At step  506 , for mapping purposes, record in each requirement the identity of the respective aspect that implements the requirement. A requirement node in the hierarchy of the second screen region  304  includes a field that identifies the implementing aspect, if there is one. 
         [0064]    Next, at step  508 , find places in the target source code base where the aspects created above should map. To do this, use an automated search function to assist in such searching. Mark each place in the target source code base with the marker annotation whose name corresponds to the aspect. 
         [0065]    Lastly at step  510 , compile the aspects along with the annotation code. The aspect compiler (e.g., AspectJ), referred to above, will automatically weave the aspect code into the application code based on the names in marker annotations matching to markers identified by programmers in the aspects themselves. It should be understood once again, that the software tool itself doesn&#39;t perform this step. The programmer carries out this step outside of the software tool using the appropriate software development tools for the given environment. 
         [0066]    While the invention has been described with reference to an example embodiment, it will be understood by those skilled in the art that a variety of modifications, additions and deletions are within the scope of the invention, as defined by the following claims.