Security in the SDLC - A Real World Perspective

Intro

It is important to understand why it is critical to consider security in the early phases of the SDLC. Whether the system is out of the box or a custom developed system, vulnerabilities can arise in each stage of the life cycle. Evidence suggests that the payoff for eliminating security flaws, or vulnerabilities, early on in the life cycle is high.   As the diagram suggests below (data gathered from Microsoft), the earlier - the better.

Initiation & Requirements & Design		Build/Configure/Test		Go Live/Post Go Live & Sunset
1X	5X	10X	15X	30X
Figure 2:  Example of the acceleration of cost of flaw repairs NOTE: X is a normalized unit of cost and can be expressed in terms of person-hours, dollars, etc.

The earlier the vulnerabilities (or their sources) are identified, the more time there is for corrective actions. The longer a flaw exists within a system, the more costly it is to repair or mitigate. During the undetected period, other system components might be developed based on the flawed assumption — to undo entire layers of system design is a costly proposition. The National Institute of Standards and Technology (NIST) estimates that system flaw re-work or repairs performed after implementation can result in 30 times the cost of fixes performed during the design phase.

Roles and Responsibilities

Many participants have a role in information systems development. The names for the roles and titles will vary among organizations. Not every participant works on every activity within a phase. The determination of which participants need to be consulted in each phase is as unique to the organization as the system development. With any systems development project, it is important to involve the appropriate information security personnel as early as possible, preferably in the planning phase.  The table below is an example 

Role	Responsibilities
IT Program Leader/Business VP	The Business VP is senior management or executive has the authority to formally assume responsibility for operating an information system at an acceptable level of risk to organization operations and assets, individuals, and other organizations. To do this, the approver relies primarily on the completed security assessment report and security plan of action for reducing or eliminating information system vulnerabilities.
Chief Information Officer (CIO)	Responsible for the organization’s information system planning, budgeting, investment, performance, and acquisition. As such, the CIO provides advice and assistance to senior organization personnel in acquiring the most efficient and effective information system to fit the organization’s enterprise architecture.
Director, Global IT Configuration and Change Management	The CM manager is responsible for managing the effects of changes or differences in configurations on an information system or network. Thus, the CM manager assists in streamlining change management processes and prevents changes that could detrimentally affect the security posture of a system before they happen.
GSO Purchasing Agent	The Contracting Officer is the person who has the authority to enter into, administer, and/or terminate contracts and make related determinations and findings.
Director, Global IT Security	Responsible for ensuring the security of an information system throughout its life cycle.
IT Security Assessor	Responsible for conducting the security assessment and focal point for security related matters.
Director, Risk and Compliance	Responsible for ensuring that the services or system being procured meet existing regulatory requirements, IT standards and corporate policies
Risk and Compliance Assessor	Responsible for conducting the compliance and risk assessment and focal point for risk and compliance related matters.
IT Project Manager	This person represents business and programmatic interests in the information system during the SDLC process. The program manager plays an essential role in security and is, ideally, intimately aware of functional system requirements.
Business Program Leader	Represents the business, is responsible for providing the business requirements and understand the existing process.
Business Executive (VP or SVP)	Responsible for the procurement, development, integration, modification, operation, and maintenance of an information system. Has the authority to formally assume responsibility for operating an information system at an acceptable level of risk to his/her organization.
VP (CISO), Global IT Security, Risk, Compliance and Change Management	Responsible for promulgating policies on security integration in the SDLC and developing enterprise standards for information security. This individual plays a leading role in introducing an appropriate structured methodology to help identify, evaluate, and minimize information security risks to the organization.
Enterprise Architect	As the overall designer and integrator of the Enterprise Architecture, the architect is responsible for creating the overall design architecture and for maintaining the conceptual integrity of the architecture throughout the project life cycle and ensuring cohesiveness among other projects and systems. The Enterprise Architect is also responsible for ensuring the quality of technical work products delivered by the project team, including designs, specifications, procedures, and documentation.
Other Participants	The list of SDLC roles in an information system development can grow as the complexity increases. It is vital that all development team members work together to ensure that a successful development is achieved. Because information security officials must make critical decisions throughout the development process, they should be included as early as possible in the process. System users may assist in the development by helping the program manager to determine the need, refine the requirements, and inspect and accept the delivered system. Participants may also include personnel who represent IT, configuration management, design and engineering, and facilities groups.

Categorization of Systems

Security categorization starts with the identification of what information supports which lines of business, as defined by my previous blog entry, “The "C" word that will save you some Trouble: Categorization".  The business and privacy impact will help determine the categorization of the system.  Subsequent steps focus on the evaluation of security in terms of confidentiality, integrity, and availability. As stated in the NIST Document on SDLC, "the result is strong linkage between mission, information, and information systems with cost-effective information security".  The best approach is to have the business tower leaders endorse and participate in the categorization process. This helps to ensure that individual information systems are categorized at the appropriate level in accordance with the business objectives of the organization. Security categorization help security professionals consider potential adverse impacts to the risk program and security in general for your organization.

The Rest of it in a Nutshell

You can follow the rest of the NIST recommended processes or do something that your organization will adopt, accept and incorporate into your PMO ongoing processes.  In my experience, extracting the security requirements from your security standards - known as the "Security Requirements Master".  These should be all the common requirements.  Make sure the project team has this list as part of the initial engagement and then as the security analyst learns more about the system, the requirements can be refined and customized enough to apply to all the system interfaces, system management, password requirements, etc.  Another thing that you need to do to ensure success is to make security requirements a non-negotiable and... of course... support from the top.

---

A Note on BYOD: A Case Study

Can BYOD (Bring Your Own Device) work?  Can we secure a BYOD strategy?  The answer is yes to both but with all changes and new approaches to technology there are the basic rules that apply and always will.  I will cover the rules as I see them but keep in mind as you read this that industry and culture changes things somewhat.  I also want to discuss a couple of fictional company case studies.

Rules of new technology approaches:
First you must ask yourself a few questions:
1)  What is driving the change? cost reduction? personnel reduction? a strategic direction? work force retention?
2)  Are there regulatory or customer drivers for the change (or the opposite -  reasons you shouldn't make the change)?
3)  Where is the change coming from?  Senior leadership?  Writing on the Men's room wall?
4) What is the impact of the change and how will the change impact the culture (or how will the culture impact the change)?

Once you understand the drivers then you can apply the rules:
1) Efforts like this (changing approaches to technology and security) MUST HAVE TOP DOWN SUPPORT!  The "tone from the top" is imperative to make transitions successful.  There will always, always be naysayers (some with a high rank) that can derail plans.
2)  Understand the scope of the change and types of users it will affect.
3)  Ensure that a proof of concept is conducted and all types of users are included.  Troublesome end users are best and the higher in the food chain you go - the better.
4)  Evaluate security policy to ensure there is no conflict and to see if new policies are required.
5)  Do not institute BYOD as a cost savings initiative - there are no savings, this is an initiative that should be used as a retention tool or way to bring top talent to your company (if you think this will work). 

This is not an all inclusive list but it will get you started as you start to contemplate how to address BYOD.

CASE STUDIES:

The way it shouldn't go:
Picture for a moment a company that doesn't have to contend with financial or medical related regulations.  This company wants to institute a BYOD device program to create an image as a cutting edge company to work for - also because there are competitors who have also instituted programs like this.  A conversation between the CEO and CIO takes place and the CIO starts asking questions and telling people we should head in this direction.  No one has actually raised their hand or said "I own this and this is what we are doing".  There has been no funding set aside and no objectives aligned with a BYOD initiative.  It is an ad-hoc undertaking with no leadership or person accountable.  In this scenario there are pocket initiatives and none of them will be successful without a great deal of pain. 

The way it should go:
Same type company (or not), CEO has a conversation in his staff meeting about BYOD at their company and asks for Pro's/Con's.  Get consensus and add objectives to each of the CEO directs to do their part.
A) Policies are evaluated for changes and impact
B) IT evaluates a COMPLETE solution and funding is allocated - if it is important enough it should get funded
C) Other VPs agree that no employees will use personally owned devices until a solution is in place
D) Communications should go out informing end-users of the future approach

Conclusion:
There are many approaches to BYOD.  Factors to a successful new approach to an IT service is leadership, approach from leadership and company culture.    I have developed a BYOD solution that uses a combination of VDI, web services and client based certificates to identify "Authorized" endpoints.  The main theme is keep the "enterprise" separate from the "personal" content.  As I mentioned there are a number of political, organizational and technical approaches, but top down support is required to achieve a successful BYOD solution.  

The “C” word that will save you some trouble: Categorization

A few years ago I was trying to think of an approach to ensuring data that was classified was protected appropriately.  I had a few problems – I knew that the approach I came up with needed to be flexible.  I’ve tried assigning data owners and it is akin to pulling teeth. It has been my experience that corporate cultures do not want or support security liaisons or managers as additional duties.  I conducted some research and did some digging.  This blog entry is the result of that digging. I developed a system centric approach to increased information confidentiality, tighter regulatory compliance, smarter application of security controls (cuts costs too), shorter/better recovery times and improved information management.  The process begins with the system development lifecycle. 

System Categorization and the SDLC

In your IT project lifecycle there should be security integration.  If you are looking for a guidance on security integration in the SDLC, NIST is a great start.  Be ready to edit the NIST document as it is not a “one size fits all” approach.  It is important to know when a step in a process is too “heavy” for your corporate culture also.  Whatever the level of involvement of security in the Project Management Office (PMO) process (mileage may very per PMO process), there should be a step in there where IT Security understands the classification of the information being stored or processed by the system being implemented and security requirements are developed to be integrated into the system – as early as possible.  I’ve seen classification criteria vary from company to company, DoD’s classifications are Top Secret, Secret and Confidential. The private sector classification criteria may look something like Confidential, Private, Sensitive and Public.  The categorization process will not work without a data classification policy and documented criteria.   I’ll use the private sector classifications listed above in my examples.  In addition to data classification and protection, you also need to consider system criticality.  If there is a system failure many companies have a threshold documented and availability criteria documented.  My assumption is you have both of these required criterion that outline classification and system availability.  I will use Very critical, Pretty critical, Low criticality and No criticality.

Figure 1: Example of System Categorization

The example in Figure 1 is how some common systems may fall out in the matrix.  Figure 2 shows the actual categories under each of the criteria.

Figure 2: System Categorization Matrix

Where the rubber meets the road

Next you will want to show where security requirements relate to the matrix.  WARNING: This can get very complex very fast.  Pace yourself – the hard part will be getting teams to agree to the ratings.  The REALLY REALLY hard part is when you try to get people to pay for requirements associated with the matrix.  It is very important to get alignment from IT leadership on the technical security requirements.  Try not to lock yourself into a specific brand technology (technology changes).  I recommend starting with a simple table like Figure 3 (this is an example and not to be considered a complete list of requirements).  Some might export all the requirements from the corporate security standards while others might refer to the monster list that NIST created and called the “Security Control Catalog”. Whatever control catalog you use, when aligned with a categorization methodology, it will greatly assist in applying the correct security investment and controls to your systems.  Also, by building these steps into your SDLC you will ensure the project teams fund for the controls that apply according to your approach.

Figure 3: Control Requirements

I hope this helps you if you have been faced with trying to ensure controls are applied at the right level for the right asset at the right time.  Next blog entry I’ll post something about security in the SDLC.

Enterprise Security Architecture: As Basic an approach as it gets

I wanted to share some work that I'm particularly proud of.  I was struggling with how I should go about documenting a security architecture in a way that any business leader could look at it and understand it.  If leadership don't get it - it ain't goin' nowhere! 

I had the traditional form of documented security architecture consisting of security processes, diagrams with firewall placement, roadmaps, hype charts, etc.  What I needed was something that someone could consume in one sitting and take away the priority and impact of a proposed strategic approach to security architecture.  I looked at several methodologies (TOGAF, SABSA, etc.) and they were shaping up to be months of effort.  These methodologies have their place and I'm not saying that the outcome wouldn't be worth the effort but in a time when we are asked to do more with less - I simply did not have the time to invest.   If you do choose to adopt a methodology like SABSA, this approach can be built upon to reach the same outcome.  Figure 1 below illustrates the process.

Figure 1: Rapid Security Architecture Development 

The process described:  Back to basics  
1) Brainstorm Security Services - I built a database of all the security services that any security organization could offer.  I brainstormed and documented over 65 core services ranging from Authentication to Vulnerability Assessments.  The Security Services database should continue to grow as the security program changes to meet new challenges.

2) Align Services with Technology - I chose to include this step to show alignment with our Enterprise Architecture team and to show services that were enhanced or covered by technology today.

3) Align Services with Defensive Strategies - Group the services into groups called Defensive Strategies. The defensive strategies should also align with the business and IT strategy if you ever expect to get any projects accomplished.

4) Organization assessment against listed security services - Assess each security service to determine what the status is.  Assign YES for security service is working; Assign PARTIAL for partial coverage and; Assign NO for not offered.

5) Align threats and gaps with the corporate enterprise risks - This is a multi-step process:
a) Develop a threat taxonomy - brainstorm all the threats that could have an impact on your particular business.  You can choose general threats like Abuse of Authority, Disgruntled Employees and Environmental Disaster.  Group the threats by Internal Malicious, External Malicious, Internal Non-malicious and External Non-malicious (this helps one understand threat vectors). 
b) It is a good idea to show risky business practice ratings, risk drivers/security motivators and show the Net Impact and Net Likelihood of the threats (Fig 2).  This gets the attention of leaders who understand threats and risks in business terms and places a kind of dashboard all on one slide.

Figure 2: Security Risk Context Example

6. Document the impact or priority of the security services - assign a HIGH, MEDIUM and LOW impact to each service to indicate the security services that are important to your organization.

7. Document the gaps in current services - By just adding up the number of services with yes, no and partial then looking at the impact rating, it is easy to see where time money and effort should be spent.

8. Align gaps with the corporate threat taxonomy - As you develop the threat taxonomy and align the threat with the risk this process helps you think of mitigation for the risks.  Simply align the risk with a security service.

9. Report findings - The alignment of gaps from step 8 will show you the services that you need to address the risks.   Figure 3 shows an example of how I might report the MFA security service, relevant threats and risk before and after the mitigation is applied and figure 4 shows another method of reporting the security services and before and after mitigation.  The risk level can be determined using the National Vulnerability Database by going through the weighted questions for each risk then going through them again and applying the security service.  This process may surprise you.

Figure 3: Example Security Service MFA

Figure 4: Another View of Security Services and Risk Ratings

10. Create a business aligned security roadmap - The roadmap will be all the security services that are developed as a result of your work.  Estimate external cost and time to implement for each security service as shown in Figure 3 in the lower right hand corner, this will help business leaders understand the level of effort and cost.

Whether you use this approach or another (or a combination) the result of an effort like this should benefit any security program.  I hope this helps readers strengthen their program or will expand your thinking.  If you find this useful, please just let me know - I like the endorphin rush when someone gains from my research, thought and hard work.