The idea of engineering software so that it continues to function correctly under malicious attack.
There is always a need to understand and manage software-induced security risks. The
touchpoints are said to be a system wide activity from design to testing and feedback. They are
also the best practices that can be applied to various software artifacts during software
development. The touchpoints are one of the three pillars of software security. Touchpoints are
also considered to possess destructive and constructive activities which in other words can be
said as black hat and white hat activities. The practice of applying touchpoints isn’t complex or
cost effective. Touchpoints are also monitored through RMF. Touchpoints can be applied to
software that are developed under different processes.
Touchpoints are numbered based on their effectiveness
1.) Architectural Risk Analysis:
It begins by building a one page overview of the system. Architectural Risk Analysis
follows a three step process:
a.) Attack Resistance
Apply a list of known attacks
Calculate risk based impact
b.) Ambiguity Analysis – Modeling techniques helps expose vulnerable area
Finds attack based on how the system works
Expose invalid assumptions
Three types of modeling can be used
Trust Modeling – identifies boundaries for security policy for function and data
Data Sensitivity Modeling – identifies privacy and trust issues for application data
Threat Modeling – identifies the attacker’s perspective and areas of weakness
c.) Weakness analysis
Think over dependencies.
2.) Code Review:
Code review is a necessary but not a sufficient practice.
Code Review introduces statistical analysis tools to identify common coding problems
before the program is releases. This can sometimes give a false negative which is a wrong
sense of security. About 50% of security problems are said to be design flaws which
cannot be found by looking at code but instead need a higher level of understanding.
Code review is a white hat activity. The main aim is to avoid implementation problems
while we build software. Code review comes before architectural risk analysis though the
fact is that both of the two touchpoints are critical. Code review aims on finding bugs
which solves 50% of the problems.
There are different approaches the statistical analysis tools can perform
Lexical analysis
Local analysis
Module-level analysis
Global analysis
These analysis tools also determine the amount of content the tool considers.
Code Review dramatically helps in the quality of the product. By catching mistakes early,
a lot of problems can be avoided. Not all developers or companies take advantage of this
process, but more and more are making it a part of their development culture.
Key characteristics of using this tool
a.) Be designed for security
b.) Support multiple tiers
c.) Be extensible
d.) Be useful for security analysts and developers alike
e.) Support existing development processes
f.) Make sense to multiple stakeholders.
3.) Software Penetration Testing
Testing is most often involved in running a series of dynamic functional tests late in the
lifecycle to ensure that the application features have been implemented properly. A
unique problem the testing faces is that majority of security defects and vulnerabilities in
software are not directly related to security functionality. Testing uses both white and
black hat concepts. It is usually aided by the use of automated tools. These tools include
Fault Injection Tools that allow the user to inject malicious input to the system and
observe the results. Other tools allow user to analyze http traffic directly in the browser.
Penetration testers also use tools that are also used traditionally associated with attackers
such as decompiler, control flow tools, as well as tools for causing buffer overflows and
injecting shell code. These tests should be conducted multiple times, as a successful test
does not necessarily mean the system is secure. The results of these tests greatly benefit
the company by propagating them back through the organization to develop mitigation
strategies and best practices. Future test should then be compared to metrics derived from
the results of these previous tests. The company can then also set goals based on these
metrics.
4.) Risk-based security tests
Testers carry out a risk-based approach, in both a system’s architecture reality and an
attacker’s mindset, to gauge software security. By identifying risks in the system and
creating tests driven by those risks, testers can focus on the areas of code where an attack
is likely to succeed. This provides a higher level of software security. The only difference
between the security testing and penetration testing is the level of approach and the
timing of the test performed. Security tests are done at the unit level.
Security testing involves two approaches:
(i)
Functional security testing – to ensure their functionalities implementation
(ii)
Adversarial security testing – based on understanding and simulating the
attacker’s approach.
5.) Abuse Cases
The special requirement that software poses is to think in a way a hacker thinks and avoid
the possible attack performed by them. During source code analysis the tool pumped out
a bunch of possible problems and suggestions on what might go wrong and at this part
it’s about deciding which ones are worth pursuing. Abuse cases are tools that help in
thinking about the software the way attackers do. This is done by having previous
experience and is an opportune time to involve the network security team. Security is an
emergent property of the system, not a feature. This involves making explicit tradeoffs
when specifying system requirements. One way to do this is through Brainstroming. It is
important to identify and document the threats.
6.) Security Requirements
This is about identifying the requirements that can bridge the gap between two disparate
fields. This deals with years of experience and it takes time to learn as much as they can
about software development in general and their organization’s software development
environment.
7.) Security Operations
The fielding of secure software are the centralized activities of deployment and
operations. Configuration and customization of software application’s deployment
environment greatly enhance its security posture.
http://agile.csc.ncsu.edu/SEMaterials/1_SoftwareSecurity.pdf
http://www.sis.pitt.edu/jjoshi/Devsec/securitytouchpoints.pdf
http://www.cigital.com/presentations/ARA10.pdf
JOURNALS
Information and Software Technology
Information and Software Technology is the international archival journal focusing on research and
experience that contributes to the improvement of software development practices.
McGraw, G. Software Security: Build Security In, Addison-Wesley, 2006.
R. Anderson: Security Engineering. John Wiley, 2001.
Humphrey W. S. Introduction to the Team Software process. Addison Wesley, 2000.
The three pillars of software security are applied risk management, software security touchpoints and
knowledge. Risk management tool is a tool that aids a business in making decisions. It uses knowledge
of threats and vulnerabilities, their probability of occurring and impact they could have on the
organization. This process should be integrated throughout the SDLC by identifying ranking, tracking
and understanding each software security risk.
Software security touchpoints are the second pillar. There are seven software security touchpoints. They
are:
Code Review-focus on finding bugs
Architectural Risk Analysis-focus on finding design flaws
Penetration Testing-Test system in its real environment
Risk-Based security tests- Test the attacks that’s most likely to succeed
Abuse cases-Describe system behavior under attack.
Security Requirements- Identify functional security and emergent characteristics
Security Operations-Involve network security professionals to monitor systems.
These touchpoints can be applied regardless of how the software is built.
The third security pillar is the knowledge. It involves gathering and sharing security knowledge to better
train future security professionals. There are seven knowledge catalog they are principles , guidelines,
rules, vulnerabilities, exploits, attack patterns and historical risks. Each of these catalogs can be placed
into one of these categories: Prescriptive knowledge, Diagnostic knowledge and historical knowledge.
Software security touchpoints can be used to apply these knowledge categories throughout the SDLC.
This knowledge can also be used to develop training program in the area of security engineering, design
principle and guidelines, implementation risks, design flaws, analysis techniques and security testing.
Explain the software security framework - there are 12 practices organized into 4 domains
The software security framework is organized into 4 domains containing 12 total practices. The 4
domains are Governance, Intelligence, SSDL touchpoints and Deployment.
Governance: Processes that aid in organizations measurement of software security as well as
staff developments are categorized in the governance domain.
Strategy and Metrics: The main objective of this practice is to set and assign values for goals and
accountability. This includes assigning roles, determining budgets and identifying metrics.
Compliance and policy: Auditability is the primary goal of this practice as well as ensuring that
all compliance regulations are met. Tasks in this practice include developing organizational
policy and conducting audits against this.
Training: This practice is used for training employees to be more knowledgeable about software
security. Also it can be used to increase the effectiveness of business processes.
Intelligence: Processes that are involved in the collection of information to increase corporate
knowledge and create resources are categorized in this intelligence domain.
Attack Models: This practice is used to gather and classify threats to the organization. This could
involve tasks ranging from top ten attack list to develop new attack methods.
Security Features and Design: Creating new security features and ensuring their use is the main
goal of this practice.
Standards and Requirements: Tasks in this practice include creating security standards as well as
a review board. Informing the outside parties of these standards is also the part of this practice.
SSDL Touchpoints: Processes used to develop best practices and integrate them in SDLC are a
part of this domain.
Architecture Analysis: Quality control is the main focus of this practice. Creating diagrams, lists
of risks, adopting a process for review are included in this practice.
Code Review: Finding security bugs and implementing processes to prevent them are the key
components in this practice.
Security Testing: This practice consists of performing tests to find security vulnerabilities,
analyzing code coverage and using an attack model.
Deployment: Processes that involve network security, system configuration or environment
issues are part of this domain.
Penetration Testing: Penetration testing is used to test the software in its production environment.
It is performed from the perspective of an attacker trying to break into the system.
Software Environment: Change management is the focus of this practice. Things such as OS
patching, code signing and publishing installing guides are all involved.
Configuration Management and Vulnerability Management: Processes such as enforcing
corporate policy, version control, documenting both authorized and unauthorized changes to the
system are part of this practice.
Reference:
http://bsimm.com/online/
What is the fundamental concept of building security in mature model (BSIMM)? Explain the
benefits of using this model.
The fundamental concept of BSIMM is to provide a way to measure software security. It does
this by providing a framework so that elements and vocabulary terms can be described in a
consistent way. It helps an organization improve its security by allowing them to focus their
efforts in the areas they are weak. This BSIMM was developed by studying 67 large well known
companies. The work of almost 3000 people, of which the average has been in the field of
software security for over 4 years, has contributed to its development. It identifies and describes
112 activities that a company may use in securing its software. By combining all of these
processes from different companies, organizations large and small can benefit through the
sharing of knowledge. Large companies can implement ideas they have not previously imagined
and small companies can learn how successful organizations are thinking about software
security. The end result of this provides a strong foundation for an organization to begin using
safer security practices. Most organizations begin by forming a software security group, the
average of which is about 15 people with some employing as many as 100. There are 4 general
circumstances that occur and lead to the creation of a SSG. The first of which is that it begins as
an idea from executives with funding in place for its creations. Another circumstance is that the
organization must comply with a set of standards and it is deemed necessary to create a SSG.
The third circumstance is due to a security breach where it is determined that the IT security
team is not at the fault. The last circumstance is that someone begins implementing security
measures and eventually gets funding for an actual program. Regardless of how it is formed, the
creation of SSG and the usage of the practices set forth by BSIMM, better prepare an
organization for future security.
Reference:
file:///C:/Users/jjebaraj/Downloads/BSIMM-V.pdf
http://bsimm.com/facts/
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ve
d=0CCUQFjAA&url=http%3A%2F%2Fbsimm.com%2Fdownload%2Fdl.php&ei=M0QjU5C5N
Mjh0wGP6ICQBA&usg=AFQjCNEZAvEFXvknIhIJyrULqAXS2AH_XA&bvm=bv.62922401,
d.dmQ
Purchase answer to see full
attachment