New version page

Security in the System Development Life Cycle

Upgrade to remove ads

This preview shows page 1-2 out of 7 pages.

Save
View Full Document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Upgrade to remove ads
Unformatted text preview:

Proceedings of the 2005 IEEEWorkshop on Information AssuranceUnited States Military Academy, West Point, NY 15–17 June 2005This work was partially funded by the Academy Center for Information Security, at the United States Air Force Academy under researchcontract # F05611-03-D-0003.Survey: Security in the System Development LifeCycleSuhair Hafez Amer1, Major Jeffrey W. Humphries2, Ph.D. and John A. Hamilton, Jr.1, Ph.D., Senior Member, IEEEAbstract - A general approach to security architecture isintroduced. A survey of existing attempts to develop thesecurity architecture introduces the topic. Security can behighlighted as part of the system development life cycle. Theauthors assume that security cannot be achieved byconcentrating on one system component but can be achievedby identifying the relationship between these components andhow information is used among them. An original sphere ofuse and interaction is presented upon which security measurescan be evaluated and the required security controls can bechosen.Index Terms - security architecture, policy, security threats,security attacks.I. INTRODUCTION Defining a general structure for a security architecture ischallenging because each organization attempts to tailorsecurity according to its needs. To develop a securesystem, a thorough understanding of the desired securityproperties and functional and non-functional properties ofthe system is required.Typical attempts to define a security architecture areconcentrated on one system component and ignored bythe rest. Such an approach was tailored to theorganization’s needs. For example, [1] proposed a three-step approach to secure architectures. First, the systemarchitecture is formalized in terms of commonarchitectural abstractions. Then the system architecture isrefined into specialized architectures where each one issuitable for implementation under different securityassumptions. Finally, a proof is constructed to see ifevery implementation satisfies the intended securitypolicy.Another approach was proposed by [2] who recommendemploying six layers of security to protect the operationsof an organization. The physical security layer addressesthe protection of physical items, objects or areas from 1. Auburn University, Auburn, Alabama. 2. United States Air Force Academy, Colorado Springs, Colo.unauthorized access and misuse. The personal securitylayer addresses the protection of the individual or a groupof individuals who are authorized to access theorganization and its operation. The operations securitylayer focuses on the protection of detail of a particularoperation or series of activities. The communicationssecurity layer encompasses the protection of theorganization’s communication media, content andtechnology. The network security layer protects thenetwork components, connections and contents. Finally,the information security layer is concerned withprotecting the information, the systems and hardware thatuse, store and transmit that information.In this paper, the authors will attempt to highlight securityarchitecture development through the steps that arecarried out during the system development life cycle.The steps and the details of each step to be consideredwhile developing secure architectures can be found in[2].II. INVESTIGATION PHASEInvestigation is the first phase in the development of thesecurity system life cycle. In general the project scopeand goals are outlined in this phase and the existingresources are evaluated. Security principles and practicescan help in developing and identifying the goals that areto be accomplished while trying to secure the system. Theresult of this phase is documenting the goals in theprogram security policy [2].A. Evaluate Existing ResourcesIdentifying the system requirements is important becauseit determines the specification of the security policy. Ingeneral, any system consists of five components [2] thatenable the inputting, processing, outputting and storing ofinformation. The first component is software thatcorresponds to the applications, operating systems, andthe assorted command utilities. The software componentsare the most difficult ones to secure since they aredeveloped under demanding constraints and are notchecked fully for security leaks, holes, bugs, orweaknesses. The second component is hardware which isthe physical technology that hosts and executes thesoftware. The hardware component also stores data andprovides the interfaces for information entry and removal.The third component is data which is stored, processedand transmitted through the computer system. The fourthcomponent is people who can pose a threat oninformation security intentionally or unintentionally.Finally, procedures are the written policy instructions thataccomplish a specific task.B. Security Principles and PracticesStoneburner, Hayden and Feringa present a compiled listof engineering principles for system security by theNational Institute of Standards and Technology [3].These principles do not apply to all systems at all timesand therefore should be carefully considered throughoutthe lifecycle of a system. This is also not an inclusive listdue to the constant changes in the information systemsecurity environment.C. Security GoalsOrganizations have different security goals but generallythose goals include confidentiality, integrity andavailability [4]. The first goal is confidentiality whichensures that any computer assets are to be accessed onlyby authorized parties. Integrity ensures that modificationof assets can only be performed by authorized parties andin authorized ways. Availability ensures that authorizedparties may always have access to their assets atauthorized times which is opposite to denial of service.Availability applies, in general, to data, systems andservices that are considered available if there is a timelyresponse to requests and a fair allocation of resources.Also availability implies that the system is fault tolerantand will gracefully shutdown in case of a hardware orsoftware fault. Another


Download Security in the System Development Life Cycle
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Security in the System Development Life Cycle and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Security in the System Development Life Cycle 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?