Chapter 2- Software Security FULL SLIDES.ppt

2
 Software security is the idea of engineering software so that it
continues to function correctly under malicious attack.
 A central and critical aspect of the computer security
problem is a software problem.
 Software security is an idea implemented to protect software
against malicious attack and other hacker risks so that the
software continues to function correctly under such potential
risks. Security is necessary to provide integrity, authentication
and availability.
Overview

3
 Any compromise to integrity, authentication and availability
makes a software unsecure.
 Software systems can be attacked to steal information, monitor
content, introduce vulnerabilities and damage the behavior of
software.
 Malware can cause DoS (denial of service) or crash the
system itself.
 Software defects with security ramifications including :
 implementation bugs such as buffer overflows and
 design flaws such as inconsistent error handling.
Software Security Threats

4
 Any compromise to integrity, authentication and availability
makes a software unsecure.
 Buffer overflow, stack overflow, command injection and
SQL injections are the most common attacks on the
software.
 Buffer and stack overflow attacks overwrite the contents
of the heap or stack respectively by writing extra bytes.

5
Command injection can be achieved on the software code
when system commands are used predominantly. New
system commands are appended to existing commands by
the malicious attack. Sometimes system command may stop
services and cause DoS.
SQL injections use malicious SQL code to retrieve or
modify important information from database servers. SQL
injections can be used to bypass login credentials.
Sometimes SQL injections fetch important information from
a database or delete all important data from a database.

6
 Malicious intruders can hack into systems by exploiting
software defects
 Software security includes:
 software design principles including the principles of
 least privilege,
 fail-safe stance, and
 defence-in-depth (These also included in
Computer Security)
 Internet-enabled software applications present the
most common security risk encountered today, with
software’s ever-expanding complexity and extensibility
adding further fuel to the fire.

7
 Software security best practices leverage good
software engineering practice and involve thinking
about security early in the software development
lifecycle,
 Knowing and understanding common threats including:
 Language-based flaws and pitfalls
 Designing for security and subjecting all software
artefacts to thorough objective risk analyses and
testing.

8
 The only way to avoid such attacks is to practice good
programming techniques.
 System-level security can be provided using better
firewalls.
 Using intrusion detection and prevention can also aid in
stopping attackers from easy access to the system.

9
 Software security is about building secure software:
 designing software to be secure,
 making sure that software is secure and educating
software developers, architects and users about how to
build secure things.
 Application security is about protecting software and the
systems that software runs in a post facto way, after
development is complete.
Application Security Vs Software Security

10
 Application security follows naturally from a network-centric
approach to security,
 by embracing standard approaches such as penetrate
and patch
 Input filtering (trying to block malicious input)
 by providing value in a reactive way.
 Application security is based primarily on finding and fixing
known security problems after they’ve been exploited in
fielded systems.

11
 Software security is the process of designing, building and
testing software for security
 Identifies and expunges problems in the software itself.
 In this way, software security practitioners attempt to build
software that can withstand attack proactively.
 Example: although there is some real value in stopping
buffer overflow attacks by observing HTTP traffic as it
arrives over port 80, a superior approach is to fix the
broken code and avoid the buffer overflow completely.

12
 Issues critical to this subfield include:
 sandboxing code (as the Java virtual machine does),
 protecting against malicious code,
 obfuscating code,
 locking down executables,
 monitoring programs as they run (especially their input),
 enforcing the software use policy with technology and
dealing with extensible systems.

13
 Application security technologies such as firewalls have
evolved the way they have is because operations people
dreamed them up.
 In most corporations and large organizations, security is the
domain of the infrastructure people who set up and maintain
firewalls, intrusion detection systems, and antivirus engines
 (all of which are reactive technologies).

14
 Must make progress on both fronts.
 But in the long run, software engineers must figure out ways
to build easier-to-defend code.
 Software security is about helping builders do a better job so
that operators end up with an easier job.
 Software security is a system-wide issue that takes into
account both security mechanisms (such as access control)
(Chapter 6) and design for security (such as robust design
that makes software attacks difficult) (Chapter 6).

15
 Security is an emergent property of a software system.
 A security problem is more likely to arise because of a
problem in a standard-issue part of the system ( the
interface and access control to the database module)
than in some given security feature.
 This is an important reason why software security must
be part of a full life cycle approach.
 As software engineers become aware of software
security’s importance, they are increasingly adopting and
evolving a set of best practices to address the problem.
Software Security in Software Development life Cycle

16

17

18
 In Application development, the cost of finding and
remediating any defect is dramatically reduced when the
defect is found early in the development lifecycle the
earlier the better.
 Finding and fixing security vulnerabilities is a vital and
necessary part of the software development process.
 However, the trial-and-error approach to scanning and
remediating code adds a significant amount of time to
the development process, which risks delaying the
delivery of product upgrades and enhancements eroding
the organization’s competitiveness and threatening
revenue.

19
 Application scanning remains a critical tool in ensuring
the security of those applications.
 Unfortunately, because application scanning occurs so
late in the development lifecycle, security defects aren’t
discovered until they’re very expensive and time-
consuming to fix.
 Even the costs of hardware, software, and personnel
required can be staggering: organizations with
comparatively modest application portfolios easily spend
millions of dollars per year.

20

21
 Security should be explicitly at the requirements level.
 Security requirements must cover both overt functional
security (say, the use of applied cryptography) and emergent
characteristics.
 One great way to cover the emergent security space is to
build abuse cases.
 Similar to use cases, abuse cases describe the system’s
behavior under attack; building them requires explicit
coverage of what should be protected, from whom, and for
how long.

23
 At the design and architecture level, a system must be
coherent and present a unified security architecture that
takes into account security principles (such as the
principle of least privilege).
 Designers, architects, and analysts must clearly
document assumptions and identify possible attacks.
 At both the specifications-based architecture stage and at
the class-hierarchy design stage, risk analysis is a
necessity security analysts should uncover and rank risks
so that mitigation can begin.
 Disregarding risk analysis at this level will lead to costly
problems down the road. External review (outside the
design team) is often necessary.

24
 At the code level, we should focus on implementation
flaws, especially those that static analysis tools (Synopsis
Statistic Analysis) tools that scan source code
for common vulnerabilities and can discover.
 Several vendors now address this space, and tools
should see market-driven improvement and
rapid maturity later this year.
 Code review is a necessary, but not sufficient, practice
for achieving secure software.
 Security bugs (especially in C and C++) can be deadly,
but architectural flaws are just as big a problem.
 Bugs and flaws divide the software security defect space
50/50

25
 Bugs
 Bugs are found in software code (source or binary).
 One of the classic bugs of all time, the buffer overflow,
has at its root the misuse of certain string handling
functions in C.
 The most notorious such functions is gets() -- a
system call that gets input from a user until the user
decides to hit return.
 In the case of a buffer overflow in C, too much input
can overwrite the heap or even overwrite the stack in
such a way as to take control of the process. Simple
bug. Awful repercussions. (And in the case of gets(),
particularly easy to find in source code.)

26
 Hundreds of system calls exist in all programming
languages that can lead to security bugs if they are used
incorrectly, ranging from string handling functions to
integer overflow and integer underflow hazards.
 There are just as many bugs in Java and other
languages.
 There are also common bugs in Web applications (
cross-site scripting or cross-site request forgery) and
bugs related to databases (like SQL injection).

27
 Many commercial source code review tools available
include HP's Fortify, IBM AppScan Source, Coverity Inc.'s
Quality Advisor, and Klocwork Inc.'s Clocwork Insight.
 The latest twist in source code review is to integrate
bug finding directly into each developer's integrated
development environment (IDE), so that bugs are
uncovered as close to conception as possible.
 For example, Cigital Inc.'s SecureAssist does this.

28
 Flaws
 At the other end of the defect spectrum we find flaws.
Flaws are found in software architecture and design.
 Here's a really simple flaw example. For example,
Forgot to authenticate user.
 This kind of error of omission will usually not be found
with code review. But it can be a serious problem. Does
your process run as root? Better be darn sure who's
using it!
 Other examples of flaws include "attacker in the middle"
problems that allow tampering or eavesdropping
between components, layers, machines, or networks;
and "replay attack" problems that have to do with weak
protocols.

29
 A list of some common Java-related flaws:
 misuse of cryptography,
 compartmentalization problems in design,
 privileged block protection failure (DoPrivilege()),
 catastrophic security failure (fragility),
 type safety confusion error,
 insecure auditing,
 broken or illogical access control,
 method over-riding problems (subclass issues),
 too much trust in (client-side) components that should
not be trusted.
(For more on these issues, see McGraw's ancient book
Securing Java.)

30
 Security testing must encompass two strategies:
 Testing security functionality with standard functional
testing techniques,
 Risk-based security testing based on attack patterns
and threat models.
 A good security test plan (with traceability back to
requirements) uses both strategies.
 Security problems aren’t always apparent, even when
software engineers probe a system directly, so
standard-issue quality assurance is unlikely to uncover
all the pressing security issues.

31
 Penetration testing is also useful, especially if an
architectural risk analysis is specifically driving the tests.
 The advantage of penetration testing is that it gives a good
understanding of fielded software in its real environment.
 However, any black box penetration testing that doesn’t
take the software architecture into account probably won’t
uncover anything deeply interesting about software risk.

32
 Software that falls prey to canned black box testing: which
simplistic application security testing tools on the market
today practice is truly bad.
 This means that passing a cursory penetration test
reveals very little about your real security posture, but
failing an easy canned penetration test tells you that
you’re in very deep trouble indeed.

33
 Operations people should carefully monitor fielded systems
during use for security breaks.
 Simply put, attacks will happen, regardless of the strength
of design and implementation, so monitoring software
behavior is an excellent defensive technique.

34
 Knowledge gained by understanding attacks and exploits
should be cycled back into the development organization,
and security practitioners should explicitly track both threat
models and attack patterns.
 Note that risks crop up during all stages of the software life
cycle, so a constant risk analysis thread, with recurring risk
tracking and monitoring activities, is highly recommended.

35
 Software security can and should borrow from other
disciplines in computer science and software engineering
when developing and evolving best practices. Of
particular relevance are:
 Security requirements engineering,
 Design for security, software architecture and
architectural analysis,
 Security analysis, security testing, and use of
the Common Criteria,

36
 Guiding principles for software security and case studies
in design and analysis
 Auditing software for implementation risks, architectural
risks, automated tools and technology developments
(code scanning, information flow and so on), and
 Common implementation risks (buffer overflows, race
conditions, randomness, authentication systems, access
control, applied cryptography and trust management).

37
 As the trinity of trouble—connectedness, complexity and
extensibility continues to impact software security in a
negative way
 Integrating a decent set of best practices into the software
development life cycle is an excellent way to do this.
 Although software security as a field has much maturing to
do

38
 ARA is a four-step process
 Step 0 (naturally start with 0 since you're geeks) is get an
architecture diagram.
 A relevant and up-to-date architecture diagram out of the
development team is sometimes harder than it should be.
 For example, some extreme Agile methods say things like
"the code is the design." I beg to differ.
Finding Flaws with ARA (Architecture Risk Analysis)

39
 The ultimate goal for this step is to create a one-page
diagram of the software system.
 One page is important, because software engineers want a
forest-level view of the software.
 Bugs are found at the tree level, flaws at the forest level.
 We don't want reams of code, we don't want UML and we
don't want a firewall placement network map.
 In many cases, we build the one-page diagram ourselves
through a process of interviewing software architects,
developers and testers.
Finding Flaws with ARA

40
 Your diagram will have some essential components
including:
 but not limited to DAO/persistence layers,
 business logic/business rules,
 security features,
 toolkits (WSE, WCF, Ajax),
 middleware,
 Web services, cloud API, caching and distribution.

41
 There are three specialized analysis steps in an ARA:
 1) known-attack analysis,
 2) system-specific attack analysis, and
 3) dependency analysis.

42
 1) Known attack analysis is about as straightforward as it
gets.
 Take a list of known attacks relevant to your
architecture and go through them.
 Example: Microsoft's STRIDE approach (part of what
they mistakenly call threat modeling) is a good example.
 STRIDE is an acronym for spoofing, tampering,
repudiation, information disclosure, denial of service,
and elevation of privilege.

43
 The key to known attack analysis is to know some attacks.
 One way to create such a list is to ask your vulnerability
management group which attacks are consistently being
uncovered.
 When you find an attack on your list that's relevant,
calculate its impact and think about how you would fix the
architecture to mitigate the risk.
 Sometimes a defect does not need to be entirely solved or
completely eradicated. It just need to reduce the risk to an
acceptable level for a given set of conditions.

44
 2) System-specific attack analysis focuses on exposing
invalid assumptions, ferreting out ambiguity and finding
new attacks based on how the system works.
 This step requires the most hard-core experience and
natural ability because security itself is an emergent
property of software.
 Sometimes a piece of software seems to behave properly
when it's all by itself, but when it's added to a bigger
ecosystem it goes entirely off the rails? That's partially what
it means.
 Anticipating emergent consequences can be tricky
business.

45
 In any case, decomposing the problem can be helpful.
 At the very least, during this step a software designer
should think about trust modeling
 (identifying trust boundaries explicitly),
 data sensitivity modeling (identifying privacy and trust
issues) and
 threat modeling (identifying attackers and considering
the attacker's perspective).

46
 3) Dependency analysis has to do with determining how
wobbly the tower of other software your counting on to work
turns out to be.
 Today's software almost always relies on the proper
behavior of components and frameworks that someone
else designed and built.
 What were their assumptions, and
 How do they impact your system?
 What will happen to your design if the frameworks
misbehave?

47
 Start with the components you're relying on.
 Are there known vulnerabilities in the components
you're counting on? (Open source or otherwise, the
answer is often "yes.")
 Do you have sufficient security controls built into the
framework? Do they actually work? (Sadly, the answer
is "no" more often than we would like.)
 Are there features or functions that need to be
disabled? (Probably.)
 Is the framework secure by default? (Maybe, if you have
been very good lately.)
 Write down what you find. Think through impact. Determine
what to do about it.

48
 After completing the above four steps to ARA, you'll find
yourself with a bunch of risks and some ideas for improving
the design.
 Take those risks and explicitly consider business impact.
 Then rank your findings, organize them and propose a
solution to the most important flaws you've uncovered.

49
 The process of ARA is intense and the work is high-
expertise, an in-depth ARA will not make sense for all of
the applications you have in your portfolio.
 ARA is a must-have for critical systems, but not so much
for systems that are not the core of your business.
 In a future article, software engineers to tackle what can be
done to address the flaws in these "lesser" systems.
Lightweight design review

50
 Whether your architecture review process leads to quick
refactorings or multi-year enterprise architecture changes
over multiple releases, today is the time to focus real
attention on software security flaws.
 Software engineers can't abandon the bug parade and the
tools they use to find and fix bugs, but because flaws make
up about half the problem, it's only prudent to address
them.
Fix your flaws

51
 In the Application Security space, one of those groups is
the Open Web Application Security Project (or OWASP for
short).
 The Open Web Application Security Project (OWASP) is
a worldwide not-for-profit charitable organization focused
on improving the security of software.
 Their mission is to make software security visible, so
that individuals and organizations are able to make
informed decisions.
 OWASP is in a unique position to provide impartial,
practical information about AppSec to anyone.
 Operating as a community of like-minded professionals,
OWASP issues software tools and knowledge-based
documentation on application security.
OWASP

Chapter 2- Software Security FULL SLIDES.ppt

Recommended

More Related Content

Similar to Chapter 2- Software Security FULL SLIDES.ppt (20)

More from Lina Shimelis (6)

Recently uploaded (20)

Chapter 2- Software Security FULL SLIDES.ppt

Editor's Notes