1. 1515 N. Courthouse Road Suite 310 Arlington, VA 22201 703-841-5500 www.onpointcorp.com www.onpointcorp.com Integrating Security into the SDLC Eric Silberman, CISSP, CAP OnPoint Consulting, Inc Arlington VA

2. who, what, how, when, where, and why of integrating security into the systems development life cycle 3 lifecycles become a set of overlapping activities 1) Project Management Lifecycle 2) Traditional SDLC Lifecycle 3) Certification and Accreditation (C&A) Lifecycle 2 Introduction: A tale of three lifecycles

3. Where: system developers and project managers at National Laboratories (unclassified and classified) Why: - FISMA says unclassified labs must follow NIST standards; classified labs follow NNSA standards - OMB A-130 requires C&A - to maintain C,I,A of data - can be accredited, can accept the risk - to protect the reputation of your organization. 3 Where and Why

4. Who is responsible for security? everyone who designs it, develops it, uses it, and maintains it: project managers, system owners, ISSO, ISSM, developers (programmers, coders) What: -- developing and maintaining mission support systems (business or science); -- protecting data at rest and in use 4 Who and what

5. security measures are best planned, included at the beginning of system development at this time the measures are - more effective - more cost-effective 5 When

6. 6 When: why is earlier better?

7. How: SEI®, the Software Engineering Institute: - requirements development, requirements - management, technical solution -PMI®, the Project Management Institute: PMBOK® (project management body of knowledge). -NIST, National Institute of Standards & Technology -NNSA, National Nuclear Safety Administration -DOD, 8500.2 7 How

8. Lifecycle One: what is the SDLC? the entire lifecycle of an IT system: the project which builds and launches the system, and also the operations that maintain the system. the operational phase is the entire production life of the system, between building the system and disposing of it 8 what is the SDLC (lifecycle one)

9. a project has a beginning, a middle, and an end. - beginning: have an idea, about how to use software and computer systems to meet a business need or perform a business process. -- middle: build the system; design, construct, test -- end of the project: launch a system (HW, SW) -environment: network, physical environment, people, processes, common security controls 9 what is a project (lifecycle two)

10. 10 what is a project (lifecycle two)

11. Then your system enters the operational phase, where the system is in production and you maintain it. This may last for several years. Finally, at some point the system is shut down, and it should go through a thoughtful and well-ordered disposal phase. 11 what is the opposite of a project?

12. certification and accreditation, defined for Federal Civilian agencies by NIST 800-37 (2004) - - initiation phase -- certification phase -- accreditation phase -- continuous monitoring phase -national security systems -have other/different C&A -(NIACAP) 12 Certification and Accreditation (3 rd lifecycle) 12 Initiation Phase Security Certification Phase Security Accreditation Phase Continuous Monitoring Phase

13. 13 Project phase: initiating phase Initiating phase: - get a rough scope of security requirements (later consider them in detail in the planning phase) -- do FIPS-199 categorization of proposed system: what shall be the criticality and sensitivity: low, moderate, or high? What are the needs for confidentiality and integrity and availability? Is this a matter of national security, or is this an excel spreadsheet of phone numbers?

14. Planning phase: - consider security requirements in detail -select security controls from a standard list of requirements such as the 800-53 (from NIST) and/or a list of security requirements from NNSA -national security systems: DOD 8500.2 14 Project phase : planning phase

15. Planning phase: security activities: - gather requirements - create a requirements traceability matrix - write security requirements in such a way as to make them reusable from one project to the next all good requirements are testable (by definition) Ultimate goals: 1) get a clear list of common controls, 2) have a reusable list called “the list of security features that must be built into each system anew” 15 Project phase: planning phase

16. Executing phase: developers do unit testing to make sure that the system that they are building meets the requirements maintain and update a spreadsheet called the Requirements Traceability Matrix 16 Project phase: executing phase

17. Controlling phase: important concept is Change Management: control of change, versions, and configurations Change Control Board: considers cost, schedule, and security. 17 Project phase: controlling phase

18. Products like systems and software applications are tested before launch (quality control testing) -- test all the requirements -- requirements include security requirements - therefore -- quality control testing includes security testing 18 SDLC phase: quality control testing

19. 1)- preliminary risk assessment 2)- categorization (FIPS 199) – sensitivity 3)- write the system security plan (CSPP) 4)make plans for the certification: 5)- gather resources 6)- notify people 19 C&A phase: initiation: gather resources

20. 20 SDLC phase: pre-launch: C&A phase: certification 1)security test and evaluation: -- low system: can be tested and certified by the system owner -- moderate or high system: required to have independent and impartial assessors 1)- requirements were just tested 2)- 800-53A requires some other tests 1)- apply recent results or common results 2)- test remaining 800-53 controls now

21. 1)AO might be CIO, or DOE Site Office Manager - the role of the AO is to decide to accredit the system by issuing an authority to operate (ATO). - AO may also choose to deny the authority to operate. AO will accept the risk when the benefit of the system to the mission outweighs the risk. 21 SDLC phase: launch: C&A phase: accreditation

22. launch begins the operational phase: this may entail a significant transition of security responsibilities Importantly, there may be different managers or owners of security during the lifecycle, and the system may change hands at the time of product launch. 22 SDLC phase: launch

23. Maintenance is defined as meeting the original requirements. Enhancements are defined as creating and meeting new requirements. Each requested change should be assessed for impact on the risk profile of the system. 23 SDLC phase: operations & maintenance

24. 24 SDLC phase: operations and maintenance Operational security for an ongoing system as part of an enterprise: a) Configuration management: change control, versions, inventory b) Awareness and training (usually more enterprise than system) c) media protection: labels, storage, backup, transportation, erasure d) maintenance: authorization, procedures, qualifications e) auditing and receiving alerts and reviewing audit logs f) scanning for vulnerabilities, optional penetration testing g) updates such as patches and hotfixes, including their testing h) monitoring network traffic; protection like antivirus, antimalware i) checksums and other integrity protection j) from the Human Resources department: personnel security k) from the facility and building team: physical security (ES&H) l) Contingency planning, training, testing m) Incident detection, response, handling, reporting

25. - sensitivity data labels - any NNSA considerations - IIF (PII) considerations identify and involve relevant stakeholders: data owners end users civilians and customers who have personal data on the system -- thoroughly erase the hard drives. 25 SDLC phase: disposal (“disposition”)

26. C&A phase: re-entering the C&A cycle A system is in the Operations phase as long as its Authority to Operate is still valid. a system leaves the Operations phase and returns to the C&A phase of initiation when : -- major change affects its risk profile -- system is turned off, data is disposed -- or when the three-year ATO expires 26

27. 27 C&A phase: re-entering the C&A cycle Initiation Phase Security Certification Phase Security Accreditation Phase Continuous Monitoring Phase when a major change affects the system’s risk profile, return to Initiation Phase

28. C&A phase: Continuous Monitoring - periodic review of a selected subset of security controls - change management: configuration management, version control, -change control process (Change Advisory Board) - document updating - reporting - 28

29. Summary: Security in the SDLC: - categorization and initial broad risk assessment - select requirements from 800-53 and work them into a reusable list - test the security function before launch, certify the system - accredit the system at launch - operations phase: hopefully for a long time. operations security can be synonymous with continuous monitoring - disposal: “do the right thing” with the data, erase the hard drives 29

30. Summary: If the other two lifecycles have been implemented with due care, then the C&A lifecycle becomes straightforward and easy. Since you have done your security implementation in the project lifecycle and the system lifecycle, then it will require very little additional effort The documentation that is part of the C&A process is used for reporting compliance for systems overseen by FISMA. 30 two lifecycles describe function, one lifecycle describes FISMA compliance

31. Questions and Answers Questions? 31

32. Contact information Eric Silberman, CISSP, CAP Eric.Silberman@onpointcorp.com 703 – 841 – 5500 ext 242 1515 N Courthouse Rd STE 310 Arlington VA 22201 32

33. REFERENCES and additional reading CMMI® Capability Maturity Model Integration; version 1.2, © by Software Engineering Institute PMBOK®, the Project Management Body of Knowledge, 3 rd edition, © by Project Management Institute, 2004. Building and Implementing a Security Certification and Accreditation Program, Patrick D. Howard, (ISC) 2 Press, 2005. Software Security Engineering: A Guide for Project Managers, Allen, Barnum, Ellison, McGraw and Mead; Addison-Wesley, 2008. NIST Special Publication 800-64, “Security Considerations in the Information System Development Life Cycle” by Grance, Hash, and Stevens, 2004. NIST SDLC brochure August 2004, “Information Security in the System Development Life Cycle”. www.epmbook.com 33