Difference between revisions of "Project Proposals/SRT"
(→Vendor Neutral) |
|||
| Line 4: | Line 4: | ||
{{Project Facts | {{Project Facts | ||
| − | |name= | + | |name=SRT |
| − | |shortname= | + | |shortname=SRT |
| − | |jiraName= | + | |jiraName= |
|projectLead= | |projectLead= | ||
|committers= | |committers= | ||
| Line 66: | Line 66: | ||
CHAPTER ONE | CHAPTER ONE | ||
INTRODUCTION | INTRODUCTION | ||
| − | Consideration of security in the System Development Life Cycle is essential to | + | Consideration of security in the System Development Life Cycle is essential to implementing and integrating a comprehensive strategy for managing risk for all information technology assets in an organization. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-64 is intended to assist federal government agencies to integrate essential security activities into their established system development life cycle guidelines. --> |
| − | implementing and integrating a comprehensive strategy for managing risk for all | + | |
| − | information technology assets in an organization. The National Institute of Standards and | + | |
| − | Technology (NIST) Special Publication (SP) 800-64 is intended to assist federal government | + | |
| − | agencies to integrate essential security activities into their established system development life | + | |
| − | cycle guidelines. --> | + | |
| − | The purpose of this guideline is to assist agencies in building security into their IT development | + | The purpose of this guideline is to assist agencies in building security into their IT development processes. This should result in more cost-effective, risk-appropriate security control identification, development, and testing. This guide focuses on the information security components of the SDLC. Overall system implementation and development is considered outside the scope of this document. Also considered outside scope is an organization’s information |
| − | processes. This should result in more cost-effective, risk-appropriate security control | + | system governance process. First, the guideline describes the key security roles and responsibilities that are needed in development of most information systems. Second, sufficient information about the SDLC is provided to allow a person who is unfamiliar with the SDLC process to understand the relationship between information security and the SDLC. |
| − | identification, development, and testing. This guide focuses on the information security | + | |
| − | components of the SDLC. Overall system implementation and development is considered outside | + | |
| − | the scope of this document. Also considered outside scope is an organization’s information | + | |
| − | system governance process. First, the guideline describes the key security roles and responsibilities that are needed in | + | |
| − | development of most information systems. Second, sufficient information about the SDLC is provided to allow a person who is unfamiliar with the SDLC process to understand the relationship between information security and the SDLC. | + | |
The scope of this document is security activities that occur within a waterfall SDLC | The scope of this document is security activities that occur within a waterfall SDLC | ||
methodology. It is intended that this could be translated into any other SDLC methodology that an agency may have adopted. | methodology. It is intended that this could be translated into any other SDLC methodology that an agency may have adopted. | ||
== Initial Committers == | == Initial Committers == | ||
| − | <!-- A list of the name/email/IRC nick of the initial project committers | + | <!-- A list of the name/email/IRC nick of the initial project committers |
| + | |||
| + | |||
IMPORTANT: Committers should be people who will actually write code, being a committer is an actual commitment of time. Please also note that committerness is an individual trait. If a committer changes employers, they remain a committer. New committers arise via meritocracy after the project is created, this typically involves some time of establishing history of meritocractic code contribution to the project.. Therefore, it is crucial that a committer is committed to ongoing work on the project in the longer term, not just short term. For more information on how committers are added after project creation see: | IMPORTANT: Committers should be people who will actually write code, being a committer is an actual commitment of time. Please also note that committerness is an individual trait. If a committer changes employers, they remain a committer. New committers arise via meritocracy after the project is created, this typically involves some time of establishing history of meritocractic code contribution to the project.. Therefore, it is crucial that a committer is committed to ongoing work on the project in the longer term, not just short term. For more information on how committers are added after project creation see: | ||
Revision as of 22:10, 22 July 2016
| SRT Facts |
|
Project Lead:
Repository: git clone https://gerrit.fd.io/r/SRT |
Contents
Name
Security Response Team
Project Contact Name and Email
Repository Name
SRT
Description
This section addresses security considerations unique to the second SDLC phase. Key security activities for this phase include:
•Conduct the risk assessment and use the results to supplement the base line security controls;
•Analyze security requirements;
•Perform functional and security testing;
•Prepare initial documents for system certification and accreditation; and
•Design security architecture.
Although this section presents the information security components in a sequential top-down manner, the order of completion is not necessarily fixed. Security analysis of complex systems will need to be iterated until consistency and completeness is achieved.
Scope
The purpose of this guideline is to assist agencies in building security into their IT development processes. This should result in more cost-effective, risk-appropriate security control identification, development, and testing. This guide focuses on the information security components of the SDLC. Overall system implementation and development is considered outside the scope of this document. Also considered outside scope is an organization’s information system governance process. First, the guideline describes the key security roles and responsibilities that are needed in development of most information systems. Second, sufficient information about the SDLC is provided to allow a person who is unfamiliar with the SDLC process to understand the relationship between information security and the SDLC. The scope of this document is security activities that occur within a waterfall SDLC methodology. It is intended that this could be translated into any other SDLC methodology that an agency may have adopted.
Initial Committers
Vendor Neutral
Meets Board Policy (including IPR, being within Board defined Scope etc)
Meets board policy as expressed in Technical Community Charter and IP Policy
Administrata
- Request for Project proposal consideration
- Email: (place link to email to TSC proposing project, this can be obtained from TSC Archives
- Date: (date proposed, makes it simpler to calculate the pre-requisite 2 week time period of gestation before being permitted to be voted on)
