Where does security fit into SDLC phases?

Transcript - Where does security fit into SDLC phases?

Let's talk about understanding and applying security in the software development life cycle (SDLC). The focus on security in the SDLC is going to involve the following module topics, development life cycle methodologies, maturity models, operation and maintenance, change management, and integrated product team discussions.

Let's begin with development life cycle methodologies. The SDLC, the software development life cycle, helps us to define the SDLC phases. There may be three phases. There may be seven phases. It may depend on the nature of the methodology you're using, and certainly the SDLC phases that are important to you in your business in regards to how you and your team develop may vary slightly from the ones that I may think are important. But if we use standardized methodologies, we're then going to use standardized phasing.

So the SDLC gives us that structure and that ability to understand that structure, and you select the most appropriate model based on the requirements of the project you're engaging in when you think about how to then use and deploy the SDLC within the environment. The typical SDLC phases you see on the screen in front of you, project initiation and planning, functional requirements definition, system design specifications, development and implementation, followed by documentation, followed by testing, followed by, finally, the transition to production. All of these phases are sequential. They are linear. We move from one to the next in a proper and prescribed order. The handoff from one to the next involves passing a gate or a phase for transition and usually some sort of deliverable that will clearly demarcate the success of one phase and the transition to the next.

Getting comfortable with software development

So keep in mind that it's, we look at security in SDLC phases, you as a security professional, you may not be focused on development, this may not be your wheel house, you may not, in other words, be coming from a background where you have a background doing development work. A lot of security professionals do, some may not, it really just depends on the skill sets you bring to the discussion. But if you've never done this kind of work before, never been involved with a project team, never had a reason to think about chunking and project phasing out a solution, then you may not really necessarily be familiar with the mindset, that's okay. As we've said in other areas, it's never a problem if you haven't done it before. But you do need to understand how to do it and have knowledge of it so that way those that do it professionally and regularly can be managed by you, can be overseen by you, you can interact with them, you can provide guidance and assistance, and you may over time choose to take this on and become more knowledgeable about this by actually doing it. But awareness of and knowledge of at a high level of the thought processes is the beginning point in that journey.

So make sure you're comfortable with the various SDLC phases, project initiation and planning, where we do the thought process behind and lay up a very high-level sketch of what the actual project will be focused on. We then gather functional requirements. We interview customers and user stakeholders, whoever those may be, write down and figure out what it is they want us to be able to do. We take those requirements that are gathered, and then we start designing and laying out the system design. We take that design, we then develop and implement the design we build, in other words, to make sure we can validate it. We do proof of concepts and ultimately create a production level or production-ready solution. We create documentation around that solution, very detailed documentation. We test all the assumptions in the system and test the individual parts as well as the overall system together. And then we transition that system, that thing that we've built ultimately, to production, and that is the finalization of the cycle, because there, we are effectively releasing the item that we have built, and we're transitioning that management of it over to operations. These are the SDLC phases that we often interact with and see, and you do want to make sure you're comfortable with them and understand the high-level description of them as I've just laid out for you. 

A look at the first few SDLC phases

When we think about project initiation and planning, outlining project objectives, scope, strategies, and other factors, as I said, or what we engage in here, when we think about functional requirements definition, we think about comprehensive analysis, ensuring systems will meet the end user needs. We're identifying what those needs are through interviewing and discussing with different audience groups what their focus and their requirements will be. We're capturing them. We're documenting them.

System design specifications allows to design systems and software established at inputs, flows, and output requirements, design security features. We're building, in other words, and writing down, and getting ready to understand how to build out all the requirements into a coherent system. That's what we're doing with system design specifications.

Development and implementation is the SDLC phase where we actually build. We're going to generate source code, develop testing scenarios and use in test cases, conduct unit and integration testing, conduct individual modular testing, as well as the integration of those units together. And we're going to document the system and start to write up the documentation around maintenance so we can understand how to manage it.

When we think about acceptance at the end of the cycle, we're thinking about an independent group, the test to ensure functionality within the organization's environment and making sure that we meet all the functional and security requirements that have been laid out. Acceptance, in other words, is making sure that the system has been built to spec, the system requirements are met through the design and the implementation, and we're now ready to manage that and accept use of that system in production as a result of that.

Take a hard look attesting  

When we think about testing and evaluation controls, we have to understand that we have things that we need to run through from a testing perspective in these SDLC phases. Testing data should include data at the ends of the acceptable data ranges. We should not just test the comfortable median, the comfortable middle, but push the boundary and test the acceptable edges of the data range to ensure, for instance, that if we say that an input validation parameter, let's say we have a form field that we're going to ask somebody to put information into, we want to test the validity of that form field and the validity of the fact that we're limiting the character input to a string of 500 characters. We want to test, not just 5 characters, not just 20, not just 200, but we want to test what happens when we put no characters in. We want to test when we put in a lot of characters. We want to test what happens when we put 500 characters, 430, and 550. So we're bracketing that range to ensure we understand what happens during normal use, and acceptable edge or boundary use, and beyond the boundary what happens. 

These are all part of what the test data elements or test data set should include, various points in between, as we said, and data beyond expected, and all allowable data limits. All of that should be bracketed within the test data, which you test with known good data. Never use live production data. Always use a replicated data set that has been tailored to allow the test to occur. We understand the data and expect the proper outcomes as a result of that. And we should use sanitized data, data that is scrubbed clean, that will not expose confidentiality, violate integrity, or interact in some way to create negative availability within production systems. Always want to make sure we're thinking about these things, we're taking steps to understand them when we talk about testing and evaluation.

Security in the later SDLC phases

When we think about certification and accreditation from a security authorization perspective, certification is the idea of specifying that the system was built to meet the requirements and the criteria that were laid out. So we built to spec is what we're talking about when we certify. System was delivered and built according to specification or requirements. Authorization is then the ability to manage and run that system in production. So we first certify a system is being built to spec. We then authorize a system to be operated as a second step. Authorization involves sign of acceptance of ownership and responsibility to manage from senior management and/or the stakeholder, the person of record, the owner of the system that commissioned it. It may be one or more of these people depending on the nature of the system involved.

Authorization, In other words, is the permission to operate that is granted by the system owner that accepts responsibility for the system as delivered according to the bill to spec certification. We can always certify a system, but we may not always authorize a system. What I mean by that is, if a system is built to spec, it will be certified as such. Certification is a precursor activity to authorization, but we may not always authorize all certified systems. We may not, in other words, choose to accept responsibility and therefore operational control of a system just because it is certified. Make sure you understand the difference here between the two, and make sure you understand that certification always comes first before accreditation activities.

When we think about transition to production, implementation of the system, we have to obtain security accreditation. We can never run a system in production unless it has been accredited. And remember we can never accredit a system unless it has been first certified. Train new users on it, and then implement the system or the stages and the steps we engage in.

Life after implementation

When we think about revision and system replacement, we're thinking about life cycle, you know, thought processes here as we go through the entire arc of security in SDLC phases, and then we are starting to operate the system. Over time, that system may need updates and revisions. It may need to be replaced at an end of life. Changes have to be followed and must be recorded in the SDLC, and periodic evaluation and auditing of systems has to be accounted for and allowed as well. 

When we think about different models that allow us to engage in these activities and understand system maturity over time, the Capability Maturity Model for Software, what's known as CMM or the SW-CMM, Software Capability Maturity Model, helps us to focus on quality management and has typically a five maturity level life cycle associated with it. We go from an immature kind of beginning state through more advanced stages of maturity over time as the understanding of the software, the validation of the software, and the complexity of the systems that manage the software continue to evolve. We move through those maturity levels from really kind of crawling, to standing, to walking, if you think about the maturity movement. As we think about the different levels, this is what a Capability Maturity Model will provide for us, the ability to understand how to manage and measure additional quality enhancements and focuses on quality processes over time that make the organization and the software, in this case, more mature. 

When we think about international standardization around software, software development, software development life cycles, software engineering, we think about ISO standards, as we do in many cases. The ISO/IEC 90003 standard, the 2014 revision to that standard is appropriate to software that is mostly focused on what's called TQM or total quality management, focuses in capabilities. This ISO standard allows us to understand how to really focus on quality holistically across the entire software system, and this is one of the key standards that we reference in this regard.

When we think about operation and maintenance, we think about monitoring performance of the system, we think about ensuring continuity of operations, think about detection of defects or weaknesses, understanding how to identify and deal with them, managing and prevention of system problems, recovery from system problems, and, ultimately, the implementing of system changes over time. Any and all of these activities have to be accounted for, and we have to think about them within the operation and the maintenance cycle.

When we think about that, we obviously have to think about systems that help us to do those things. Change management is one of those key focal points and one of those key areas. Successful change management is going to require benefits management and realization, effective communication, effective education and training, counter resistance, monitoring of the implementation. The idea here is that awareness of any and all activities then interact with and will then cause some sort of change to occur as part of what change management represents for us. The ability to understand change, record it, document it, control it, and, as a result of that, engage in change through a prescriptive process that is tightly monitored, tightly regulated, and designed to produce desired and known outcomes or documented outcomes is what change management really represents to the organization. This is one of those areas where the CISSP can have tremendous impact if they focus the organization on the need, and importance of, and value of change. If the organization is not formally managing change today, that doesn't mean that we can't start doing that, but it does mean we have to be aware of the need in order to do that. And CISSPs can bring that understanding to bear for the organization.

And, finally, in our discussions in these areas, we overlay and really overview the initial steps of how to begin to engage in software development and the value of the SDLC, the development life cycle, and the phases associated with it. No conversation in that area would be complete without at least a nod and a reference to DevOps, development operations methodology. The idea here that we're linking development and operations together, really linking two disparate areas of the organization, and sharing information, sharing management thought processes, sharing development and operational procedures and policies, and life cycle systems, and information about them in such a way that we're integrating and we're blending the need for and the support of these two teams to operate together is what DevOps is all about. 

We monitor and validate operational quality. We deploy with reputable reliable processes, have you focus on automation, have you focus on declare and develop life cycles, and understanding how to use them to quickly and proactively spin up new systems and integrate that system methodology, that system life cycle, into every area and corner of what we do is what DevOps is all about. It's an emerging trend in the market today. It's becoming very, very important in many of the areas and systems that we manage. It will continue to grow in importance and focus as cloud-based technologies, and virtualization technologies, and software definition of the data center, the network, the storage plans are all becoming more and more focused on and more and more important in what we do in large scale data center management. Today, DevOps is continuing to grow in importance as a result of that. 

Security professionals that understand that and are aware of that as an emerging trend are positioned to take advantage of this thought process. Those that are not, there's always time to educate yourself, but obviously keep in mind that the more you begin to hear about and see DevOps, probably culminating at some point, and ultimately in the use of DevOps in one or more areas of your business over time, the more likely it is that you're going to have to come into contact with this, the more likely it is that you should develop an understanding of it, and a familiarity, and a comfort level with it.

As we wrap up our conversations here, begin to think about the additional steps we'll take and look at additional areas of information within software development and software engineering thought processes in the rest of the material and discussions in this domain. Want to make sure you are focused on, as we're reviewing here quickly what the key takeaways are, the software development life cycle, the SDLC phases, understanding their importance, understanding the progression from phase to phase, understanding what the key milestones are for each of those phases in terms of the names of the phases, and how we represent success moving from phase to phase is going to be a very important takeaway for you.