Chapter -5

GOVERNANCE AND MANAGING FOR MORE SECURE SOFTWARE

GOVERNANCE AND SECURITY:

Governance entails setting clear expectations for business conduct and then following through to ensure
the organization fulfills those expectations. Governance action flows from the top of the organization to all
of its business units and projects. Done right, governance facilitates an organization’s approach to nearly
any business problem, including security. National and international regulations call for organizations—and
their leaders—to demonstrate due care with respect to security. This is where governance can help.

DEFINITIONS OF SECURITY GOVERNANCE:

Governance in enterprise security means directing and controlling an organization to create and
maintain a culture where security is prioritized in how the organization operates. It involves treating
security as a crucial requirement for doing business.

According to NIST, information security governance is about setting up and maintaining a structure and
processes to ensure that security strategies:

- Support the business goals

- Follow laws and regulations
- Assign responsibility for managing risks

John Steven from Cigital says governance in enterprise software security means being able to measure the
risks posed by software and making decisions about fixing them. This includes giving software risk the same
importance as budget and scheduling in project management.
In security, governance also focuses heavily on managing risks responsibly. It does this by providing a
framework for making decisions, clarifying who can make decisions, their rights, and who is responsible for
them. Making decisions consistently across the organization builds confidence and reduces risks.

CHARACTERISTICS OF EFFECTIVE SECUIRTY GOVERNANCE AND MANAGEMENT:

One of the best signs that an organization is taking security seriously is if it consistently follows certain
beliefs, behaviors, capabilities, and actions that align with security best practices. These measures help
create a culture where security is valued and prioritized. Here are some key points:

- Security is managed throughout the organization, from top executives down to all staff. It's seen as
essential for the organization's success and is treated as a necessary investment rather than just a
cost.
- Security is integrated into all planning processes, from strategic planning to day-to-day operations.
Goals related to security are set, and progress is regularly monitored and evaluated.
- Security is considered from the start of any new project or business relationship and is integrated
into all stages of development, from design to retirement.
- Managers understand the importance of security and are accountable for their team's performance
in this area.
- All staff members know their responsibilities in maintaining security and are motivated to comply
with security policies. Rewards and consequences for following or violating security policies are
consistently applied.

Leaders who want to ensure a strong security culture can use this checklist to assess their organization's
practices. Each point's importance may vary depending on the organization's culture and business needs.
ADOPTING AN ENTERPRISE SOFTWARE SECURITY FRAMEWORK:
- Many organizations no longer assume that their applications are automatically secure. Even after
conducting tests, security teams still spend a lot of time dealing with incidents. Many organizations
have realized that simply securing the perimeter isn't enough because the software they use or
build isn't resilient to attacks.

- Aware of this issue, smart organizations have been trying to integrate security into their software
for some time. However, they often face challenges, mainly because the problem is more about
organization and culture than just technical issues.

- For some organizations, software security might be a new concept, and even knowing where to
start can be difficult. The first step towards improving software security across the organization is to
assess the current strengths and weaknesses in software development and security practices. This
assessment should include software developed in-house, outsourced, purchased off-the-shelf, or
integrated from vendors.

- As part of this assessment, organizations should consider how much software they purchase versus
how much they build internally. If most software is outsourced, then ensuring its security is more
about verifying assurance from the vendors rather than building security from scratch. Since many
organizations do both, they need to address security concerns for both internally developed and
externally sourced software.

COMMON PITFALLS:
When organizations aim to enhance the security of their applications, they encounter similar obstacles
regardless of whether they approach the problem formally or informally, from the top down or the bottom
up. How each organization deals with these obstacles depends on its specific strengths and weaknesses.
There isn't a universal solution that works for everyone, but being aware of common challenges can help
organizations navigate them more effectively. Let's explore some of these common challenges.

Lack of Software Security Goals and Vision

- It's important to emphasize that the main challenge in software security is often cultural. It's about
how well the software can withstand attacks, not just about securing the environment it operates in.
While organizations are starting to grasp this idea, they often don't know how to address it. Typically,
their initial response is to throw money and resources at it, like hiring someone to set up security
guidelines or buying a quick fix tool.

- However, it's crucial not to rush into this approach. In larger organizations, politics play a significant
role, especially at the director level where headcount, budget, and timelines are key. Demanding
that development teams follow security guidelines they haven't budgeted for or imposing tools that
highlight vulnerabilities can lead to political tensions.

- To succeed in improving software security, it's like preparing for a battle: each person involved
needs to understand their role and take responsibility. But the most critical factor for success is
having executive support, clear roles and responsibilities, and a shared vision for software security.
Without these, efforts to improve security may get bogged down in political conflicts or simply stall.

Software Security Best Practices Nonexistent

When software security best practices are absent, it leaves systems vulnerable to various threats and
compromises. Here are some key consequences of lacking software security best practices:
1. Increased Risk of Breaches: Without established security practices, software systems become easy
targets for cyberattacks such as data breaches, malware infections, and unauthorized access.

2. Data Loss or Theft: Weak security measures expose sensitive data to theft or loss, leading to financial
losses, legal liabilities, and damage to reputation.

3. Compromised User Privacy: Inadequate security can compromise user privacy by exposing personal
information to unauthorized parties or data breaches.

4. System Downtime: Security vulnerabilities can lead to system disruptions, downtime, or loss of
functionality, impacting business operations and user experience.

5. Reputation Damage: Security incidents resulting from the absence of best practices can severely damage
an organization's reputation, leading to loss of customer trust and business opportunities.

6. Regulatory Non-Compliance: Failure to implement security best practices may result in non-compliance
with regulatory requirements and industry standards, leading to legal consequences and financial penalties.

To address these issues, organizations should prioritize implementing robust software security practices,
including regular vulnerability assessments, secure coding standards, access controls, encryption,
authentication mechanisms, and ongoing security training for developers and users. By investing in
proactive security measures, organizations can mitigate risks and safeguard their systems, data, and
reputation from potential threats.

Software Risk Doesn’t Support Decision Making:

When software risk isn't considered in decision-making processes, it can lead to various negative
outcomes and hinder effective management. Here are some consequences of neglecting software risk in
decision-making:

1. Increased Likelihood of Failures: Ignoring software risk means decisions may not adequately account for
potential vulnerabilities or flaws in software systems, increasing the likelihood of failures, errors, or
malfunctions.

2. Security Breaches: Without factoring in software risk, decisions may inadvertently expose systems to
security breaches, data leaks, or cyberattacks, compromising sensitive information and damaging
reputation.

3. Financial Losses: Failure to consider software risk may result in investing resources in projects or
technologies that later prove to be insecure or unsustainable, leading to financial losses for the
organization.

4. Missed Opportunities: Ignoring software risk can lead to missed opportunities for innovation, growth, or
competitive advantage, as organizations may be hesitant to adopt new technologies or approaches due to
perceived risks.

5. Regulatory Compliance Issues: Neglecting software risk may result in non-compliance with industry
regulations or data protection laws, leading to legal consequences, fines, or reputational damage.

To address these challenges, organizations should integrate software risk assessment and management into
their decision-making processes. This involves identifying and analyzing potential risks associated with
software projects, products, or systems, and using this information to inform strategic decisions. By
considering software risk early and proactively managing it throughout the software lifecycle, organizations
can minimize negative impacts and enhance the success of their initiatives.

FRAMING THE SOLUTION:

An enterprise software security framework (ESSF) offers a comprehensive approach to software security
at the organizational level without requiring drastic changes to staffing or IT operations. ESSFs bring
together the right people, expertise, technologies, and development practices to ensure software is more
secure. While every organization's ESSF will be unique based on its specific needs and risks, there are some
common characteristics:

1. "Who, What, when" Structure: An effective ESSF outlines the responsibilities of each role involved in
securing software and specifies when these activities should be performed. This includes roles beyond just
security analysts and developers.

[Link] in Group Names: The names of groups may vary between organizations, and that's okay. What
matters is clarifying who needs to do what.

[Link] Responsibilities: Each group's responsibilities should be clearly defined, but there should be
flexibility in how these activities are carried out. For example, the development business owner might
choose to provide secure programming handbooks or mandate developer training.

4. Relative Ordering of Activities: The framework should indicate which activities depend on others, but it
shouldn't overly constrain individual suborganizations. Detailed project planning should be left to the
teams themselves.
Avoid common pitfalls when developing an ESSF, such as:

- Getting too detailed about when activities should occur, as this can be seen as overly restrictive.
- Trying to predict every possible activity in advance. Instead, allow for flexibility and adaptation
based on evolving needs and circumstances.

Focus on Resisting Attack, Not Including Security Features:

Security isn't just about adding a bunch of security features to an application. It's more like a quality that
emerges from how the application is built and how it's designed to resist attacks. Sometimes, organizations
fall into the trap of thinking that if they just use encryption and user authentication, they're covered. While
it's important to use security features provided by tools and languages, it's not enough on its own.

To be truly effective, security needs to be woven into every aspect of how the application is developed and
maintained. Instead of just focusing on features, organizations should aim to make their applications
resistant to attacks right from the start. Here are some tips to help achieve this:

- Think about how the application might be misused or abused.

- Identify potential threats that the application might face.
- Regularly assess the application against these threats, including the misuse and abuse cases.
- Provide training using real-life examples of vulnerabilities.
- Establish standards based on the risks and vulnerabilities specific to the application.
- Don't rely solely on security checklists or standard APIs for guidance.
- Instead of trying to implement all these guidelines at once, start by incorporating them gradually,
building on what your organization already does well.

Competencies for Effective Enterprise Software Security

The ESSF defines an organization’s approach to
software security and describes roles,
responsibilities, activities, deliverables, and
measurement criteria. It also includes a
communication plan for enterprise-wide rollout.
Enterprise software security framework
Enterprise software and data architectures are
essential anchors of the goal-state an ESSF defines.
Definition of and migration toward a secure
enterprise architecture are thus part of the
framework competency.

An organized collection of security knowledge is

likely to include policy, standards, design and attack
patterns, threat models, code samples, and
eventually a reference architecture and secure
development framework. Another element of this
Knowledge management, training competency is the development and delivery of a
training curriculum. Topics include security
knowledge as well as help for conducting
assurance activities. This pursuit also includes new
courseware, along with retrofitting of existing
courseware to software security concepts.
 The definition of tasks and activities that augment
existing development processes (formally or
informally) help developers build security into any
custom software development process, as well as
Security touchpoints
in-place out-source assurance and commercial off-
the-shelf validation processes. This competency
defines how to assure software. See [McGraw
2006]
The execution of security touchpoint activities pro-
vides assurance—conducting a software
architectural risk assessment, for example,
validates that security requirements were
translated into aspects of the soft-ware’s design
and that the design resists attack. Assurance
activities rely heavily on the knowledge and
Assurance
training competency to define what to look for.
Tool adoption is likely to be part of this pursuit in
the short to medium term. It will involve the
purchase, customization, and rollout of static
analysis tools as well as dynamic analysis aides.
Your organization might have already adopted a
penetration-testing product, for instance
In the context of an ESSF, governance is
competency in measuring software-induced risk
and supporting an objective decision-making
process for remediation and software release. This
competency involves creating a seat at the project
management table for software risk alongside
budget and scheduling concerns. Governance
Governance
should also be applied to the rollout and
maturation of an organization’s ESSF. The
framework’s owners can measure project coverage
and depth of assurance activities, reported risks
(and their severity), and the progress of software
security knowledge and skill creation, among other
things.

ROADMAP:
Each aspect of software security relies on the others, and developing them effectively requires
collaboration. Trying to understand all the connections at once and rolling out changes all at once isn't
practical. Instead, successful enterprise software security frameworks (ESSFs) build on initial successes
gradually over time.

Here are two important things to remember:

1. Patience: Building a strong software security framework takes time—usually three to five years. While
you might see some progress within a year, it's important to be patient and focus on gradually improving
over time.
2. Customers: The customers of the security framework are the software development teams within the
organization. Each milestone in the framework's development should provide value to these teams, rather
than creating additional obstacles.

How Much Security Is Enough?

Before deciding on security actions, you need to know how much security you actually need. One way to
figure this out is by asking some key security questions, like we discussed earlier.

Defining Enough Security

Knowing how much security you need is mostly about managing risks. If possible, you should put in
controls that meet the security needs of your most important business processes and assets. If that's not
possible, you identify and deal with the risks to those processes and assets until they're at a level your
organization can accept.

What's Adequate Security?

Adequate security means your protection plans for the most important parts of your organization match up
with how much risk your organization can handle. This includes things like rules, policies, procedures, and
how well you're keeping an eye on things.

What Are Critical Assets?

Critical assets are the things your organization really needs to keep going strong. That includes stuff like
your data, technology, buildings, and even your reputation. If something is really important for your
organization to succeed, it's considered a "critical asset."

Why Software Matters:

Software plays a big role in handling and protecting important data and technology. So, it's crucial to make
sure any software your organization uses is built with security in mind.

Processes are Important Too:

Processes are the steps you take to get things done, like making products or managing money. Keeping
these processes secure is just as important as keeping your data safe.
Sure, here's a simplified version:

Risk Tolerance
An organization's risk tolerance is how much risk it's okay with taking while trying to achieve its goals. This
influences how the organization operates, makes decisions, and spends resources. It's not fixed, though,
and can change based on what's happening around it.

Defining Risk Tolerance

Figuring out how much risk an organization can handle is the job of top executives. They look at things like
the potential impact of risks, how likely they are to happen, and what actions can be taken to reduce them.
Risk tolerance can be described in terms of the risks the organization is willing to accept even after trying to
lower them.

Expressing Risk Tolerance

You can talk about risk tolerance in different ways, like saying a risk is high, medium, or low. For example, a
policy might say to focus on fixing high and medium risks and just keep an eye on the low ones.

Addressing Security Needs

To figure out how much security is enough, start by asking what "enough security" means for your
organization. Some detailed questions to explore:
- What are the most important things for our organization, and how much risk are we okay with when it
comes to them?
- When are these important things at risk, and what could happen if those risks come true? Are these risks
within our limits?
- If the risks are too high, what can we do to lower them? Are we okay with some level of risk, and how are
we managing it?
- For risks we can't accept, what can we do to protect ourselves? Is it worth the cost?
- How well are we handling security right now? Are we confident our security plans will still work in the
future? Do we regularly update our plans to keep up with changes?

A Framework for Software Security Risk Management

To make sure software is secure enough, it's important to have a process for managing risks. This process
needs to be ongoing and integrated into every step of developing the software.

Five Steps in the Process

Imagine the risk management process like a loop with five main steps:
1. Understand the business context: Get a clear picture of what the software is for and how it fits into the
organization's goals.
2. Identify the risks:Figure out all the potential problems, both technical and business-related, that could
affect the software.
3. Prioritize the risks: Decide which risks are most important to tackle first by ranking them in order of
severity.
4. Plan how to deal with the risks: Come up with a strategy for reducing or managing each risk.
5. Take action:Put the plans into action by fixing the problems and making sure they're actually solved.
Then, double-check to make sure everything is working as it should.

Understanding the Business Context

When it comes to deciding how much security is needed for software, it's important to understand the
business side of things. This means realizing that software risks can have big effects on what the
organization is trying to achieve.

Why Understanding Business Matters

Software risks need to be looked at in terms of how they could affect the organization's goals. If a risk isn't
clearly tied to something important for the business, it might not seem urgent enough to fix.

Dealing with Risks

The first step in managing software risks is figuring out what matters most to the business. This might
include things like making money, keeping customers happy, or saving on costs.

During this Stage:

- We need to clearly understand the goals and priorities of the business.

- We figure out which software risks are most important to tackle based on what the business cares about.
- Business goals could be things like making more money, meeting agreements with customers, or cutting
down on development costs.
Identifying Business and Technical Risks:

Business risks are threats to a customer's goals, like losing money, damaging reputation, breaking rules, or
spending more than planned. These risks need to be measured using things like market share, direct costs,
or productivity levels.

Understanding Business Risks:

Identifying business risks helps figure out how they might affect the software. It guides how we measure
and reduce risks in things like requirements and design. This step helps connect technical issues to business
goals.

Dealing with Technical Risks:

Technical risks are problems with how the software is built or works. For example, the software might crash
unexpectedly or not meet its design goals. These risks can cause things like data breaches or extra work
during development.

Identifying Technical Risks:

To spot technical risks, we use methods described in Chapter 4, which talk about finding, assessing, and
fixing issues in the software's design and architecture.

Synthesizing and Prioritizing Risks:

In any system, there are a lot of risks. It's crucial to figure out which ones are most important so we can
deal with them first. This step helps answer questions like "What should we focus on first?" and "How
should we allocate our resources to fix these risks?" We create a list of all the risks, ranking them based on
how urgent they are to resolve. Metrics we use include things like how likely a risk is, how severe it could
be, and how many risks we're dealing with over time.

Defining the Risk Mitigation Strategy:

Once we know which risks are most urgent, we come up with a plan to fix them in a smart and cost-
effective way. This plan considers things like cost, how long it will take to fix, and how likely the fixes are to
work. We also need to make sure our plan fits with what the organization can handle and understand. This
step involves figuring out how we'll check that the fixes actually worked. Metrics we consider include how
much fixing the risks will cost, how effective our methods are in terms of money saved, and how many risks
our plan covers.

Fixing the Problems and Validating the Fixes:

After we've planned how to fix the risks, we put the plan into action. We fix any issues we've identified in
things like the software's design or requirements. We measure our progress by checking how well we're
following our plan. We also use techniques to make sure the fixes we've made actually work. Testing is one
way we do this, to see if the software is now safer and if our fixes are effective. The goal is to make sure
there are no more unacceptable risks in the software. We set up a process to keep checking on the quality
of the software regularly. We use metrics to see how well the software and our fixes are doing, and to
make sure we're continuously improving.

Measurement and Reporting on Risk:

It's really important to keep track of all the risks we've identified, how we're dealing with them, and how
things are changing over time. This helps us make better decisions about the software and improve how we
develop it. We maintain a list of risks throughout the process and regularly report on our progress. For
example, we might look at how many risks we've found in different parts of the software, or how many
risks we've fixed over time.

The Multilevel-Loop Nature of the RMF:

The risk management process is like a loop, where we go through the same steps over and over again. Risks
can come up at any point in the software's development, so we might need to loop through the process
multiple times during each phase. We also have to consider risks that pop up between phases. This process
happens at different levels: for the whole project, for each phase of development, and for individual parts
of the software. The goal is to continuously manage and improve the software's security, adapting to
changes and new risks as they arise.

Constantly Changing Security:

The level of security we need for the software is always changing based on the business and risk
environment. It's not a one-time thing but a continuous process of planning, monitoring, and updating. This
means security isn't something we achieve and forget about; it's part of our everyday business practices.
We need to be flexible and ready to adapt to new challenges and risks as they come up.

For more details on how to put these ideas into practice, you can refer to additional resources like "Risk-
Centered Practices" and "Software Security: Building Security In."

Security and Project Management:

This part talks about how security impacts project plans and management actions, and it suggests ways to
include security practices in the software development life cycle (SDLC) we discussed earlier.

Continuous Risk Management:

- Regularly assessing risks is important to help project managers decide which security practices to use and
how much.

Software Security Requirements:

- Security needs affect various parts of the project, including:
- Project scope
- Project plan
- Tools and expertise needed
- Estimating resources required
- Identifying project and product risks

Project Scope:
- Security affects the project's scope in a few ways:
- Identifying threats: Figuring out what kind of risks the software might face and who might try to exploit
them.
- Dealing with different attackers: Some attackers might be amateurs, while others are skilled and have
more resources.
- Response to attacks: Deciding how the system should react to an attack—whether it should just prevent
attacks or actively respond to them.
- Level of assurance needed: Depending on the importance of the system and the consequences of a
security failure, different levels of assurance are required. For example, systems handling sensitive
information or critical services might need higher levels of assurance.

Legal and Regulatory Requirements:

- Some projects need to meet legal, regulatory, or contractual obligations regarding security and data
protection. These requirements often demand a formal approach to governance and risk management.

Overall, understanding and addressing these aspects of security is crucial for managing projects effectively
and ensuring the security of the software being developed.

Project Planning:

Security risks and their potential impacts influence project planning and resource allocation. Low-
consequence and low-likelihood risks may be managed by project leaders with minimal oversight, while
high-probability risks with medium-level consequences require expert assistance and systematic review
processes.

Common Challenges:
1. Complexity in product development: Tight integration of components to meet market demands may
increase complexity and introduce vulnerabilities.
2. Risks in shared services: Failures in shared software or infrastructure services can affect multiple systems,
necessitating higher assurance levels.
3. System integration issues: Mismatches between internally developed and outsourced components
require careful resolution to ensure system integrity.

Communication and coordination among different development teams and between development and
operational environments are crucial aspects that project managers must address.

Software Security Practices:

Implementing software security practices requires a continuous risk management process, with early risk
assessments focusing on business-oriented factors. Stakeholders with business knowledge should
participate in these assessments.
Architectural risk analysis is an essential practice that involves reviewing threats, analyzing architectural
responses, and identifying additional risks introduced by the architecture. This analysis becomes more
detailed as the software architecture evolves.

Figure 7-4 illustrates how security can be integrated into the SDLC using touchpoints, representing security
best practices applied to various software artifacts created during development. While the figure may
suggest a traditional waterfall approach, most organizations today use iterative development cycles,
revisiting these touchpoints multiple times as the software evolves.

The Security Development Lifecycle (SDL) is a method used by Microsoft to make software safer during development.
Another approach, called CLASP (Comprehensive, Lightweight Application Security Process), is also available. CLASP is
designed to help development teams build security into their projects from the beginning. It provides a structured,
repeatable, and measurable way to ensure security. You can find more information about other methods for making
software secure in resources like "Secure Software Development Life Cycle Processes."

Objective:
The goal of integrating security into a defined Software Development Life Cycle (SDLC) isn't to completely
overhaul the existing process. Instead, it aims to incorporate clear security practices and deliverables
tailored to the software's characteristics.

Activities Required for Deliverables:

Meeting regulatory or contractual compliance may necessitate demonstrating that the software ensures
necessary controls when handling sensitive information. This often involves producing an assurance case,
showcasing how the software meets security compliance requirements, which can increase the software's
complexity.

Demonstrating Software Security:

Ensuring "secure" software involves proving that the desired level of assurance has been achieved. While
demonstrating functionality is crucial, software security assurance focuses more on showcasing what a
system doesn't do wrong. For example, does improper input lead to system failure or enable attackers to
bypass authentication or authorization defenses?

Resources:

Tools:
The environment where software is developed should be as secure as the level of security planned for the
software itself. It's important to have proper controls and configuration management for development
materials. Sometimes, specific tools are needed to help make sure the software is secure, like tools for
checking code for potential security issues.

The security features like authentication, authorization, and encryption are often made up of parts that can
be customized for a particular situation. These parts must meet the necessary level of assurance.

As the level of assurance goes up, the development process should have the right mechanisms in place to
control and protect information. Changes need to follow a strict process, and unauthorized changes
shouldn't be tolerated. For highly sensitive parts of the code, changes might need to be made by two
developers to prevent someone from adding harmful code.

Knowledge and Expertise:

Most projects don't have a lot of expertise in security, so it's a challenge to decide how to use the limited
security resources available. This challenge is even greater when security needs to be part of developing
the software itself.

The expertise needed for making software more secure can be divided into two types:
1. Knowing how to include security features like access control, authentication, and encryption in the
software, and being aware of the security issues related to development and project management.
2. Knowing how to find and fix vulnerabilities that could be exploited. Unfortunately, many software
development teams lack this expertise. Vulnerabilities might be in parts of the system that aren't used
much or in how different parts of the system interact, which can be hard to predict.

Project managers need to make sure their teams have both types of expertise throughout the software
development process. Some tasks, like risk assessment and code review, need a lot of security knowledge,
while others can be done with less. For example, setting up a tool to check code for security issues might
need a lot of expertise, but using the tool might not need as much. Similarly, some testing methods, like
penetration testing, need experts, while others, like fuzz testing, can be done with less expertise.
Estimating Resources:
Impact of Assurance Level:
Increasing the level of assurance needed for a project can affect its cost and schedule significantly. It might
require additional skills, practices, and tools to show that the desired level of assurance is achieved.
Traditional ways of saving money, like using existing components or common commercial parts, might not
work well for projects needing medium to high levels of assurance.

Shared Services and Risks:

Using shared services and IT infrastructure for multiple projects can lower costs but also spreads risks
across all projects. For example, if a shared service has a risk, every project using that service needs to deal
with it. Some shared services include things like web portals, encryption, access control, and authentication.
Estimates for projects using shared services need to include the extra assurance needed for those services.

Nature of Security Expertise:

The kind of security expertise needed changes throughout the project. At the start, when planning and
requirements are being set, teams might need a lot of help from experts. Planning security tests usually
happens after the project's basic structure is decided. While risk analysis is ongoing, the specific expertise
needed for it can change. For example, analyzing detailed designs might need deep knowledge of a specific
technology, while looking at the actual code might need knowledge of known problems.
Deployment of Security Expertise at Microsoft:
Microsoft learned that having someone with security knowledge involved throughout the software design
and development process is crucial. They found this especially important for projects using agile
development methods.
To address this need, Microsoft set up a central security group. This group focuses on improving security
practices and processes across the organization. They also provide expertise and perform a final security
check before software is released.
During different phases of development, the product team can request a security advisor from this central
group. This advisor helps by reviewing plans, ensuring the team has the right resources, and guiding them
through security considerations. They also advise on setting security milestones and criteria for when a
project is ready to move forward.
For more details on how Microsoft implemented this approach, you can read "Lessons Learned from Five
Years of Building More Secure Software" by Howard (2007).
Project and Product Risks:

When you're using new protocols, like those for Web services, they might change frequently as people
learn from using them. This means that best practices don't stay the same for long, which can make
planning difficult. To deal with this, you might consider using a prototype or taking an iterative approach,
where you build and test things in smaller steps.

There can be extra requirements for securely accessing data during development, making sure facilities are
secure, or proving that the software works as intended. These things can make projects more complex and
affect the schedule.

Sometimes, software vulnerabilities are put into the code on purpose during development, either by the
team working on it or by a contracted group. Finding these kinds of vulnerabilities can be harder than
finding ones caused by mistakes in how the software was made. Having good change and configuration
management procedures can help catch these problems in internal development.

Some security risks are just part of the environment the software will run in or are tradeoffs made for other
benefits. For example, it might be really hard to stop a big denial-of-service attack. Other risks might come
from decisions made earlier in the project, like letting employees use their own laptops or phones to access
company information because it's more convenient, even though it might not be as secure.

In short, making sure software is secure affects a lot of parts of project management, like scoping out the
project, managing people, communicating, dealing with risks, getting what you need, making sure things
are good quality, and putting everything together. There are specific practices you can use during different
stages of development, like assessing the risks in the design, looking for threats, and checking the code for
problems. But dealing with security issues during development is always changing, so project managers
need to keep connecting the business side of things with the technical side, and keep an eye on how things
are going throughout the whole process.

Making sure software is secure isn't just about setting up things like firewalls and access controls. It's about
building security practices into how the software is made, and that's something project managers need to
oversee.
Mitigations May Create New Risks:

When you put security measures in place to deal with one problem, they can sometimes cause new
problems. For instance, if you have a big system where lots of different parts need to verify who's using
them, you might set up a system that handles authentication and authorization for all of them together. But
by doing this, you're putting all your eggs in one basket. If that system fails, it can bring down everything
else with it, and it becomes a target for attackers.
When making decisions like this, it's important to look at the risks involved. You need to figure out if there
are any new risks that come with the solution you're using, and how much it'll cost to keep everything
running once it's in place.
Measuring Software Security:

Measuring both the product and the development process has always been crucial for successful software
development.

Good measurement practices help in planning projects realistically, keeping track of progress, identifying
risks accurately, and improving processes effectively. We can analyze different aspects of software like
requirements, designs, and source code to find and fix problems during the project, which reduces defects,
rework, and cycle time.

Unfortunately, measuring software security is still in its early stages, and there's no agreement on the best
practices yet. However, we can extend some practices from general software development to address
security requirements.

To measure software security effectively, we need to first agree on the desired security characteristics and
set clear measurement objectives for both the product and the development process. This means we must
specify security aspects early in the Software Development Life Cycle (SDLC) and translate potential risks
into specific security requirements.

Here are some examples of questions that can help us set measurement objectives:
- What vulnerabilities have been found in our products? Are our current development practices enough to
prevent these vulnerabilities from happening again?
- Which steps or activities in our process are most likely to introduce security risks?
- What proportion of defects are related to security concerns? Do we have categories for security-related
defects in our classification schemes?
- How well do developers follow security-related processes and practices?
- To what extent do we address security concerns in our intermediate work products, like requirements and
design descriptions? Have we planned and defined measures for implementing security requirements?

Analyzing architectural risks can also guide the development of secure products. Several methodologies are
available for assessing risks and threats, such as those outlined by McGraw and CLASP. Microsoft has also
shared materials on how they analyze and mitigate threat risks during the development process.

Measuring Security in the Development Process:

When it comes to measuring security in the development process, there are specific areas we need to focus
on:

1. Presence and Compliance of Security Policies: We need to ensure that security policies, including roles,
responsibilities, procedures, coding rules, and acceptance criteria, are in place and followed throughout the
Software Development Life Cycle (SDLC).

2. Efficiency and Effectiveness of Security Policies: We should regularly assess how well our security policies
are working over time and whether they are achieving the desired results.

These measurements are crucial for ensuring that security is integrated into the development process
effectively. We can incorporate them as part of our quality assurance efforts.
While there's a NIST guide for security metrics, we can also use risk management practices to address
software security issues.

Measuring Security in the Product:

When assessing security in the product itself, we can focus on various aspects:

1. Security Requirements: These are based on privacy policies, legal requirements, and risks identified by
threat assessments. They should be specified clearly and completely.

2. Security Architecture: This reflects the security requirements and outlines how they are implemented in
the product.

3. Secure Design Criteria: These criteria ensure that security requirements are traceable throughout the
design phase.

4. Secure Coding Practices: These practices ensure that the integrity of the code is maintained.

Simplicity in Measurement:

Measures don't need to be complicated. They should be as simple as possible while still providing useful
information. For example, during the requirements phase, we can start by asking whether security
concerns have been considered or not.

We can use tools, inspections, and reviews to ensure that security measures are implemented during
design and coding. Inspection measurements can include traditional defect identification checklists with
added security items.

Insightful Metrics:

Simple measures like enumeration and appropriate handling of vulnerabilities can give us valuable insights
into the security status of the software during development.

There are resources available, like lists of measurable security entities and concepts, that provide useful
starting points for developing measurement objectives.

In conclusion, paying attention to these measurement areas is essential for project managers when
developing secure software. They help in understanding and managing security risks effectively throughout
the development process.

Maturity of Practice in Security:

The importance of security in organizations, especially in the IT sector, is gaining attention. While security
isn't given much focus in the early stages of software development, it's becoming more prominent during
detailed design, coding, and testing phases. Taking security seriously from the start of a project can lead to
stronger and less vulnerable software, reducing the need for reactive fixes later on.

To ensure effective security, it's crucial for organizations to have consistent governance and management
practices across different departments, including business units, human resources, legal, audit, risk
management, finance, and IT.

Protecting Information:
There's a growing recognition of the need to safeguard information, especially sensitive data related to
consumers, customers, clients, and employees. Organizations are realizing that mishandling such
information can damage their reputation, leading to public scrutiny and loss of trust. Federal and state laws
in the US, like the Sarbanes-Oxley Act and the California Database Protection Act, enforce the protection of
personal data. Similarly, the European Union has strict regulations regarding the protection of personal
data.

In the credit card industry, there's proactive effort to maintain security standards. The Payment Card
Industry Security Standards Council, established by major credit card companies, oversees the Payment
Card Industry Data Security Standard (PCI DSS). This standard outlines requirements for organizations
handling credit card information to ensure data security. It includes measures like maintaining a secure
network, protecting cardholder data, implementing access controls, and regularly testing networks for
vulnerabilities.

Overall, it's essential for organizations to prioritize security and comply with industry standards to protect
sensitive information and maintain trust with customers.
Audit’s Role:

The Institute of Internal Auditors (IIA) organized six summit conferences in 2000 to understand better how
governance relates to information security management and assurance. They also provided guidance in
2001 titled "Information Security Governance: What Directors Need to Know," which includes case studies
from companies like General Motors, IBM, and others. This guidance offers useful questions for assessing
maturity levels, which can be found on the BSI website.

The Information Systems Audit and Control Association (ISACA) and its partner, the IT Governance Institute
(ITGI), have published detailed guidance on information technology and security governance. Their report
"Information Security Governance: Guidance for Boards of Directors and Executive Management" explains
what information security governance is, why it's important, and who is responsible for it. Additionally, the
report outlines how organizations can measure their maturity level in terms of information security
governance.
Operational Resilience and Convergence:

CERT, working with the Financial Services Technology Consortium (FSTC), is looking into how security,
business continuity, and IT operations management can converge to manage operational risks better. Their
goal is to enhance the organization's ability to adapt to changes in operational risks effectively.

They've developed a framework for improving business continuity and security, which is being tested with
FSTC members and other partners. Many organizations are also integrating business continuity, operational
and technology risk management, compliance, and information security and privacy efforts, supported by
audit.

These integrations involve various aspects like people, processes, infrastructure, and information, aiming to:
- Decrease the risk of business interruptions.
- Reduce recovery time during interruptions.
- Maintain public trust and meet customer expectations.
- Enhance compliance with regulations and internal service level requirements.

The Alliance for Enterprise Security Risk Management, formed by ASIS International, ISACA, and ISSA, is
working on integrating traditional and information security functions to gain attention from board
members and senior executives. They define convergence as identifying security risks within business
functions and developing managed solutions to address them.
Their efforts highlight the importance of addressing security within a broader convergence strategy to
improve organizational readiness.
A Legal View:

The American Bar Association’s Privacy and Computer Crime Committee has released a "Roadmap to an
Enterprise Security Program." It was created by a diverse team of experts to provide a structured approach
to cybersecurity that aligns with global standards, meets compliance requirements, supports law
enforcement cooperation, and fosters public-private sector collaboration.

The Roadmap outlines steps for governance, including:

- Establishing governance structure, oversight, and policies.
- Inventorying digital assets like networks and applications.
- Assigning ownership and security responsibilities for each asset.
- Identifying compliance requirements with laws and regulations.
- Conducting threat and risk assessments, security plan reviews, and risk management based on asset
categorization and risk level.

A Software Engineering View:

There's a growing body of knowledge on applying governance and management principles to develop
secure software. Articles like "Adopting an Enterprise Software Security Framework" and "Bridging the Gap
Between Software Development and Information Security" provide concrete steps and practices for
improvement.

"Software Security: Building Security In" elaborates on these ideas, discussing elements of an enterprise
software security program, common pitfalls to avoid, establishing metrics, continuous improvement,
managing commercial off-the-shelf (COTS) software, and adopting a secure development life cycle.

"The Security Development Lifecycle" emphasizes the importance of executive support for implementing a
Secure Development Lifecycle (SDL). It outlines the 12-stage SDL process, highlighting the need for visible
commitment from leadership, resource allocation, and ensuring products meet security and SDL
requirements.

Exemplars:

The article "Maturity of Practice and Exemplars" on the BSI website presents 12 examples of principles,
guidelines, frameworks, and roadmaps that can help organizations implement a governance-based
enterprise security program. These examples showcase how various professional associations and market
sectors have successfully addressed security at governance and management levels. They often use
strategic questions and guiding principles as starting points. Here's a summary of some of these
organizations and events:

- Aberdeen Group
- American Chemistry Council
- Audit Associations (Institute of Internal Auditors, Information Technology Governance Institute)
- BITS
- Corporate Governance Task Force
- Corporate Information Security Working Group
- Federal Financial Institutions Examination Council
- Health Information and Management Systems Society
- ISO/IEC 27001 and ISO/IEC 17799
- National Association of Corporate Directors
- National Institute of Standards and Technology
- Payment Card Industry Data Security Standard
- Veterans Administration Data Breach

These examples, along with their references, offer enough detail to help organizations start implementing a
security governance and management program.

Across various sectors and organizational functions like risk management, IT, business continuity, audit,
legal, and software development, progress is being made. By treating security as an enterprise-wide issue,
organizations are integrating security into business councils, decision-making processes, plans, business
and development processes, and measures of success.