Obstacles implementing a security engineering program in support of certification and accreditation and enteprise security compliance are arguably similar to those organizations experience with traditional quality programs. Introduction Information technology (IT) products and information systems (IS) are an essential part of modern life. In fact, most businesses would not be competitive without it. The problem with using IT/IS, however, is tied to the very reason for its existence - nformation. We use IT/IS "for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display or transmission" of all sorts of information. And the more useful the information, the more valuable it is to the people who have it - and the people that want it - whether they are entitled to it or not. And this is exactly where the skullduggery begins. Information is better than gold in the new Information Age and there appears to be no shortage of thieves. A recent survey by Deloitte of the global financial services industry found an increase in the sophistication of threats, specifically mentioning viruses and worms, phishing and pharming, and spyware and malware as the top three categories of external breaches. The survey also noted an increase in the number and types of exploitable vulnerabilities, in large part due to mobile IT/IS assets once outside the corporate perimeter. Individual companies responding to the survey estimated losses of up to $5 million dollars or more over the course of the preceding 12 months. "There is little doubt that IT and information security remain fundamental concerns of the financial services environment of today. Financial institutions, held to the ultimate standards of trust and security, are expected to manage risk effectively, protecting both internal and external environments from potential breaches." Given phishing, pharming, and spyware top the list of threats in 2006, it is probably no surprise the survey categorized identity theft as the "number two IT security hot button ... [and] the crime of the 21st century." But concern for the loss of personal or private information predates the turn of the century by more than 25 years. Congress began legislating requirements for due diligence and due care for this type of information since at least 1974 with passage of the Privacy Act. In the three decades since, we've seen the Computer Security Act of 1986, the Clinger-Cohen Act (CCA) of 1996, the Health Insurance Portability and Accountability Act (HIPAA) of 1996, the Gramm-Leach-Bliley Act (GLBA) of 1999, the Government Information Systems Reform Act (GISRA) of 2000, the Sarbanes-Oxley Act (SOX) of 2002, and the Federal Information Security Management Act (FISMA) of 2002. And, as with other 'Acts of Congress', this legislation places a burden on the organizations that use IT/IS to ensure compliance in addition to the technical, administrative and operational controls required to ensure security. For our purposes, however, we will focus on the implementation of technical security controls in acquired IT/IS. Background The Department of Defense (DoD) has been instrumental in specifying and evaluating technical security controls since at least 1985, publishing the Trusted Computer System Evaluation Criteria (TCSEC) - better known as 'The Orange Book' - and has matured security standards and supporting processes to reflect technological and legislative changes. The DoD now certifies the implementation of security controls in IT products and IS and authorizes operation of all IT/IS based on a formal assessment of residual risk - a process referred to as certification and accreditation (C&A). So how can IT/IS project managers influence the successful implementation of technical security controls during system design and development? Aside from the technical disciplines such as computer science or engineering, there are arguably two overarching disciplines integral to the IT/IS acquisition process: systems engineering and project management, both of which are addressed from a security perspective in a specialized discipline known as information systems security engineering, or ISSE. Information Systems Security Engineering While the concept of security engineering isn't new, if measured against the three criteria for a discipline provided by Joannou, ISSE as "a field of study, knowledge, or expertise" wasn't firmly established until publication of the Systems Security Engineering Capability Maturity Model (SSE-CMM) in 1996 and the Information Assurance Technical Framework (IATF) in 1998. The "Rules of conduct or methods of practice ... and [the] method to ensure adherence to the rules" were established when the National Security Agency (NSA) partnered with the International Information Systems Security Certification Consortium (ISC)2 in 2002 to develop the ISSE Professional (ISSEP) certification, a specialty certification for the Certified Information Systems Security Professional (CISSP). As defined by NSA, ISSE consists of four domains or knowledge areas: security engineering, C&A, technical management, and U.S. government rules and regulations. Assuming only those project management issues relevant to implementing technical controls prior to certification testing are relevant, a comparison of Schwalbe and Hansche indicates most - if not all - project management issues are addressed by at least one of the four domains. ISSE domains Each phase of the ISSE process is iterative, with 'assess information protection effectiveness' performing the function of a feedback loop. ISSE process Ensuring the value of information is properly identified (phase 1), defining security requirements based on the value of the information (phase 2), translating the security requirements into the IT/IS architecture (phase 3), verifying their incorporation into the system design (phase 4), and validating the system is built and configured as designed (phase 5) with constant assessment of the security controls' effectiveness related to the original requirements throughout the process (phase 6), is absolutely essential to the development of secure IT/IS. And despite ISSE's recent 'coming of age', the literature indicates security engineering during system development has been advocated for quite some time. Davis stated the case for ISSE as follows: "Although the upfront cost of performing the tasks of ISSE during a systems engineering lifecycle may seem great due to uncertainty and time or budget constraints, the cost if compared to applying the security, changing system designs and possibly rebuilding components post hoc is extremely low. In fact, if ISSE is properly utilized from the beginning of a systems engineering process, ISSE may provide additional benefits such as identifying and mitigating system risk in regards to cost, schedule and performance earlier on and thus further enhance a system's ability to remain on target.... In order to build IA into today's system, the current, most systematic and cost effective method is ISSE." Unfortunately Davis also indicates there is a general failure of organizations to incorporate IA into the systems engineering process even though ISSE is a formal discipline and - perhaps most important of all - endusers increasingly demand better security. Yet despite the apparent challenges, there is very little in the literature on the implementation of ISSE other than various recommendations for a security engineering method, process, or tool. This is also true of the rather extensive literature on security requirements engineering. The literature specifically addressing ISSE in the C&A process also appears limited. One relevant contribution is a somewhat dated paper on the certification of trusted application systems in an acquisition environment by Froscher, McDermott, Payne, and Lubbes. The authors base their discussion and recommendations on their personal experience certifying two command and control systems under the TCSEC. They discovered many of the problems experienced during system certification can be traced to programmatic issues as well as technical. Fourteen years after Froscher, et al was published - despite the implementation of new DoD IA policy, formal integration of IA and ISSE requirements into the acquisition process, ongoing research on C&A within the DoD and without, the maturation of ISSE, and the relatively extensive body of knowledge on security engineering and security requirements engineering - a paper by Peters and Schleipfer again focuses on addressing security early in the acquisition process, albeit at an earlier stage in system development. Lim and Carastan also indicate that "even in cases where there are security components in the [System Development Life Cycle] SDLC, security is oftentimes the sacrificial lamb in a compressed project delivery timeframe," which is consistent with the conclusions made by Davis and Mouratidis, suggesting not much has changed in the intervening years with the implementation of ISSE in support of IS acquisition. Non-Functional or Quality Requirements Although the reasons project managers have difficulty implementing ISSE may not be apparent from the literature, the answers may be found exploring the very nature of the requirements ISSE attempts to address. Unlike functional requirements such as baud rate and latency, security requirements are considered non-functional because they are generally disassociated from the system's intended purpose. (Exceptions are IA products whose primary function is security, e.g., network firewall appliances.) This does not imply non-functional requirements are unimportant nor have little relationship with their functional counterparts, however. "The complexity of an information system is determined partly by its functionality - i.e., what the system does - and partly by global requirements on its development or operational costs, performance, reliability, maintainability, portability, robustness and the like. These non-functional requirements play a crucial role during system development ... Errors of omission or commission in laying down and taking properly into account such requirements are generally acknowledged to be among the most difficult to correct once the information system has been completed." Since this was written in 1992, numerous papers have been published on the subject of defining, modeling, and satisfying non-functional requirements. But what is important to note is these nonfunctional requirements - including security requirements - are also viewed in the literature as quality attributes, quality characteristics, or quality requirements, emphasis added. The key to solving the ISSE implementation problem may very well reside in this distinction. Quality Implementations Hansche indicates quality programs like the Baldrige Criteria for Performance Excellence, ISO 9001 certification, Six Sigma, and the Software Engineering Institute (SEI) CMM (SEI-CMM) directly support 'system assessment,' the iterative feedback loop in systems engineering that is applied throughout the SDLC to ensure system design and configuration satisfy functional requirements. As ISSE is a specialized implementation of systems engineering, it follows quality implementations support ISSE 'system security assessment' processes and activities as well. While the SSE-CMM is certainly applicable, other quality implementations may also play an important role in ISSE. Quality programs focus on more than just 'process improvement,' rather, as with a CMM, they are more concerned with developing 'capable' processes. An organization with mature processes may not necessarily produce a quality product or service, just a consistent one - good or bad. Organizations with capable processes, however, "satisfy ... specified product quality, service quality, and process-performance objectives." Given security requirements are generally considered nonfunctional, i.e., they are essentially quality requirements, the process of implementing security requirements in an IS may itself be rightly considered a quality implementation process - and implemented similarly. Barriers to Implementation Quality and process improvement arguably began in production and manufacturing since the time of W. Edward Deming and has successfully spread to other industries at various organizational levels. And whether the quality program is Total Quality Management (TQM), the Baldrige award, Six Sigma or one of numerous other variants, the principles for successful implementation and sustainment of a quality program - and the problems or barriers to the same - are certainly well understood. It thus seems reasonable to turn to the literature on quality to identify potential barriers to ISSE. Subsequently, examination of the literature reviewed by Hill indicates the most significant barriers may be grouped into five general categories: Culture: An organization's culture may be incompatible with quality principles, especially when there is little or no focus on customer requirements; organizations may not understand how to implement cultural change. Strategy/planning: Organization's may not understand the need, have the resources, or even know how to plan adequately for an undertaking as significant as a quality implementation; organizations may have disconnects between strategic- and operational-level planning. Leadership/management: Management may lack support or commitment for the implementation, may be focused on short-term rewards rather than long-term benefits, or unrealistic expectations for the implementation; organizations may experience high management turn-over, creating a lack of continuity, or there may be a general disconnect between management and employee goals and objectives. Resources: Organizations may not have or simply fail to apply a sufficient number of personnel, allow sufficient time to achieve short- and long-term objectives and goals, or provide appropriate and sufficient quality tools or other resources to support the implementation. Training: Organizations, for whatever reason, may provide little or no training, or the training provided may be inadequate or inapplicable to the implementation. Recommendations To overcome these barriers, the author offers the following recommendations: Culture: Stress the importance of ISSE through policy; provide penalties for non-compliance with the policy and enforce the penalties. Strategy/planning: Incorporate ISSE into systems engineering plans, procedures, standards and guidance; fully integrate ISSE in all engineering design reviews and project milestone reviews; and implement the SSE-CMM. Leadership/management: Ensure leadership/management understands their compliance requirements (e.g., SOX and FISMA) and the penalties for non-compliance. Resources: Assign dedicated security engineers to all IT/IS acquisition efforts and provide them the tools needed for ISSE, e.g., access to relevant government documentation, current literature/research, and vulnerability and risk assessment/management tools. Training: Provide ISSE awareness training to systems engineers and project managers, and ensure security engineers are properly trained and certified in ISSE. Conclusion The successful implementation of ISSE, like quality, requires a fundamental change - a cultural change - in the way we acquire IT/IS, and it should be done in much the same way as any other organizational change. Management support at all levels for the formal incorporation of ISSE in systems engineering plans and the assignment of trained, dedicated security engineers may not guarantee success, but it will certainly go a long way toward helping project managers (1) provide targeted application of scarce resources (dollars and personnel), (2) facilitate the proper engineering and implementation of technical security controls, (3) reduce overall risk to project scope, cost and schedule, and (4) address the most critical IT/IS security compliance issues affecting their project. |
 |
|
|
|
