Security Concern Throughout System Development Life Cycle
Defining a general structure for a security architecture is challenging because each organization attempts to tailor security according to its needs. To develop a secure system, a thorough understanding of the desired security properties and functional and non-functional properties of the system is required.
What is Security
Confidentiality - Ensuring that there is no deliberate or accidental improper disclosure of sensitive automated information.
Integrity - Protecting against deliberate or accidental corruption of automated information.
Availability - Protecting against deliberate or accidental actions that cause automated information resources to be unavailable to users when needed.
There are six areas of security programming concerns:
1.Access Controls
2.System and Data Integrity
3.Unauthorized Access
4.Privacy and Confidentiality
5.Production Implementation
6.Documentation[7]
When do we actually have to pay attention to the security requirements of our information system?
From the very earliest stages of planning for the development of the system to its final disposal is the advice of the National Institute of Standards and Technology (NIST). Although general way of protecting a system is simply considering the fact that there is no user, no power or no network but it is
also possible that sometimes we give our own private informations either intentionally, unintentionally or somehow people steal it. By considering security early in the information system development life cycle (SDLC), we may be able to avoid higher costs later on and develop a more secure system from the start.
NIST’s Information Technology Laboratory recently issued Special Publication (SP) 800-64, Security Considerations in the Information System Development Life Cycle, by Tim Grance, Joan Hash, and Marc Stevens, to help organizations include security requirements in their planning for every phase of the system life cycle, and to select, acquire, and use appropriate and cost-effective security controls.
The guide discusses the selection of a life cycle model by the organization and the responsibilities of the organization’s managers and staff members for conducting the system development process. While NIST SP 800-64 describes security and a generic system development life cycle for illustrative purposes, the basic concepts can be applied, with tailoring, to any SDLC model or acquisition method the organization is using.[1]
The System Development Life Cycle (SDLC)
NIST SP 800-34 defines the SDLC as “the scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation.”
The system development life cycle starts with the initiation of the system planning process, and continues through system acquisition and development, implementation, operations and maintenance, and ends with disposition of the system. Specific decisions about security must be made in each of these phases to assure that the system is secure.[6]
Phases of the SDLC:
The initiation phase begins with a determination of need for the system. The organization develops its initial definition of the problem that could be solved through automation.This is followed by a preliminary concept for the basic system that is needed, a preliminary definition of requirements, and feasibility and technology assessments. Also during this early phase, the organization starts to define the security requirements for the planned system. For systems developed in-house (I.e. at NIH), the IT Security office would: define security features, monitor the development process for security problems, respond to changes, and monitor threats and vulnerabilities such as accidents, acts of nature, design limitations, Trojan horses, incorrect code, poorly functioning development tools, manipulation of code, and malicious insiders. Management approval of decisions reached is important at this stage. A preliminary risk assessment should be performed to develop a brief initial description of the basic security needs of the system, including needs to protect the integrity, availability, and confidentiality of system information. During the implementation phase the system moves/transitions to production. If this is not done correctly, it can cause unnecessary delays, cause additional expenditures and possibly embarrass the organization, management, and the developers. Critical activities of the implementation phase includes: final testing, system certifying, and system installation.
NIST 800-30 HHS SLC Requirements
Guide
ISO/IEC 12207
1. Initiation System Concept Development Investment Analysis
Planning Acquisition
Requirements Requirements Analysis
Design Design and Engineering
2. Development or
Acquisition
Development Development
3. Implementation Integration and Test Testing
Implementation Implementation
4. Operations or
Maintenance
Operations and Maintenance Operations and Maintenance
5. Disposition Disposition Retirement
The preliminary risk assessment should define the threat environment in which the system will operate and the potential vulnerabilities. This assessment should be followed by an initial identification of equired security controls that will protect the system in its operational environment. A detailed risk assessment is developed in the next phase. In development or the acquisition phase the security functional requirements analysis considers the system security environment, including the enterprise information security policy and the enterprise security architecture. The analysis should address all requirements for confidentiality, integrity, and availability of information, and should include a review of all legal, functional, and other security requirements contained in applicable laws, regulations, and guidance. A security test and evaluation plan should be developed for the security controls that can be evaluated prior to deployment. The controls must be tested and evaluated for correct implementation and effectiveness. Controls of a non-technical activity, such as management and operational controls, cannot be tested and evaluated until the information system is deployed. The security plan ensures that the planned or existing security controls are fully documented.[2] The security plan also provides a complete description of the information system, and provides references to key documents supporting the organization’s information security program: the configuration management plan, contingency plan, incident response plan, security awareness and training plan, rules of behavior, risk assessment, security test and evaluation plan, system interconnection agreements, security authorizations and accreditations, and the plan of action with milestones.[1] In disposition phase, Information should be retained to conform to current legal requirements and to accommodate future technology changes that might make the system’s data retrieval method obsolete. The implementation phase security issues involves Backup, restore, and restart instructions and procedures. It also ensures implementation of only approved or accredited systems.[2][3][6]
Data should be deleted, erased, and written over as necessary, and the media that stored the data should be sanitized. Degaussing, overwriting, and media destruction are some of the methods that may be used. The security assurance requirements analysis addresses the activities and assurance needed to produce the desired level of confidence that the information security will work correctly and effectively. This analysis, based on legal and functional security requirements, should be used to determine how much and what kinds of assurance are required. The goal is to achieve cost-effective assurance that meets the requirements for protecting the organization’s information assets.Tests and evaluations, such as the following, can provide information about system quality and support
confidence in the system.The Common Criteria for IT Security Evaluation, contained in International organization for Standardization/International Electrotechnical Commission (ISO/IEC) 15408, is used to evaluate information security products to support user confidence that the products meet defined security claims.[3][5] Security policies are used for several purposes such as recognizing sensitive information assets, clarifying security responsibilities of users, promoting the awareness of existing
employees and finally guiding new employees to the goals and constraints of using a system.[7]
Performance Measurements
The need of performance measurement is mendatory because of quantify benefit/cost analyses, budget monitoring, quality control/improvement, regulatory reporting etc. To meet the performance measurement the following things need to be considered:
1. Meeting the privacy, integrity, confidentiality, availability of the system as defined in the “statement of work” or “statement of need”
2. Labor hours spent on IT Security
3. Dollars associated with IT Security
Web Application Security Vulnerabilities:
Web application security vulnerabilities include:
1.Un-validated parameters – Attackers frequently exploit this vulnerability to gain access to back-end components.
2.Broken access control – An exploit to this flaw could give an outsider access to user accounts, sensitive files or functions.
3.Broken account and session management – Attackers exploiting this hole can access passwords, keys, session cookies and other tokens to gain account credentials.
4.Cross-site scripting (XSS) flaws – A cracker may exploit one of these flaws to use a Web application to transport an attack to a user’s browser.
5.Buffer overflows – Overrunning a buffer in a Web application could enable an attacker to take control of processes like CGI, libraries, drivers, and Web application server components.[4]
Conclusion
Establishing a strong security management program requires that agencies take a comprehensive approach that involves both (1) senior agency program managers who understand which aspects of their missions are the most critical and sensitive and (2) technical experts who know the agencies’
systems and can suggest appropriate technical security control techniques.[5][1] The modified sphere of use and component interaction model suggests that in order to achieve security, all thecomponents of model should be considered while addressing security during the developments life cycle.The interaction between every component: people, DB, System, information, network, internet, and procedures and policies can pose a threat to security.[7] One should not focus on just protecting
network and internet components, for example, because the raw data or data in large scale databases must also be protected. In this paper I tried to present a new sphere explaining that, threats can exist at different levels and components. Security has been introduced and surveyed while being employed throughout the development life cycle that is used by any organization and how security can beemployed had been explained.
References
[1]. www.eng.auburn.edu/users/hamilton/security/pubs/Hamilton_IEEE_USMA_2005.pdf
[2]. www.ffiec.gov/ffiecinfobase/booklets/d_a/08.html
[3]. http://www.itl.nist.gov/lab/bulletns/bltndec03.htm
[4] Frank, Diane, “Agencies Seek Security Metrics.”Federal Computer Week, 19 June 2000.
URL: http://www.fcw.com/fcw/articles/2000/0619/pol-metrics-06-19-00.asp
[5] Carnegie Mellon Software Engineering Institute CERT Coordination Center, “Understanding
Malicious Content Mitigation for Web Developers”, 2 February 2000.
URL: http://www.cert.org/tech_tips/malicious_code_mitigation.html
[6] NIH IT Security Web Site URL: http://www.cit.nih.gov/security.html
[7] Burris, Peter, and Chris King. “A Few Good Security Metrics.”METAGroup, Inc. 11 October 2000.URL: http://www.metagroup.com/metaview/mv0314/mv0314.html
Tags: Security
