Docstoc

ch1

Document Sample
ch1 Powered By Docstoc
					               CS 502

Chapter 1. Defining a Principle
      C. Edward Chow

 http://cs.uccs.edu/~cs502/
 http://uccsonline.net/
Defining a Discipline
    Software Security – the idea of engineering
    software so that it continues to function correctly
    under malicious attack

    Network security $45B in 2003.
    532% increase in CERT incidents reported
    (2000-2003)
    43% of 500 companies report increase of
    cybercrime.



6/27/2011              C. Edward Chow                 2
Good SW Security Practice
    Leverage good SE practice
    Think security early in software lifecyle
    Understand common problems (flaws/pitfalls)
    Design for security
    Subject all SW artifacts through thorough risk
    analysis and testing

    Software Security is a
    “Knolwedge-intensive” field.


6/27/2011             C. Edward Chow                 3
# of SW Vulnerabilities




6/27/2011   C. Edward Chow   4
Trinity of Trouble
    Why the problem is growing?
    Three Trends has impact on growth and
    evolution of the problem.
        Connectivity
        Extensibility
        Complexity




6/27/2011               C. Edward Chow      5
Connectivity
    Networked computer through Internet
    From Home PC to system control critical
    infrastructures. e.g. Supervisory control and data
    acquisition, (SCADA)
    Networked enable communication: email/web
    Easy access (no physical access needed)
    More software to attack.




6/27/2011              C. Edward Chow                6
Trend in Enterprises
    Web Services and Service Oriented Architecture
    (SOA)
    Consequences
    Legacy applications (never intended to be
    internetworked) are exposed as web services
        Not support SSL, authentication/authorization, cipher
        use.
        No hook to directory service
    How about middle ware vendor solution?
        Authentication/application level protocol don’t align
        Ad hoc cross-enterprise FTP between applications
6/27/2011                  C. Edward Chow                       7
Legacy Product Integration Problem




6/27/2011      C. Edward Chow        8
Extensibility
    Web server system: CGI shared object, scripting
    Web browser: mobile code (Java Applet,
    Javascript, plug-in)
    Web Services/SOA on extensible systems
    (J2EE/.NET)
    OS: dll, loadable device drivers/modules
    Advantages: rapid deployed to market; new
    features/release; base application shipped early
    Problems: SW Vulnerabilities slip in as unwanted
    extensions.

6/27/2011             C. Edward Chow               9
Complexity
    Information system unbridled growth in size and
    complexity.




6/27/2011             C. Edward Chow              10
Lines of Code in OS/Kernels




6/27/2011   C. Edward Chow    11
Code Base Growth
    Even source code small, the code based in
    executable space grow quite a bit.
    Why “hello world” application size is 2MB in MS
    ASP or IBM WebSphere?
    Things get worse when we rely on:
        Databases
        Application servers, web containers
        MVC framework, struct deployment container
        XML representation format/parsers
        Identify mangement/provisioning
        Data flattening: Castor, JDO, container-managed
        persistence
6/27/2011                 C. Edward Chow                  12
Prove “More lines, More Bugs”
    Dan Geer, “CyberInsecurity: The cost of Monopoly”, 2003.




6/27/2011               C. Edward Chow                   13
Opportunity=#Hosts*#Vuln




6/27/2011   C. Edward Chow   14
DefectRate=CodeSize 2

    Impact factors on Complexity
        Code size
        Whether code tightly integrated
        Overlay of patches
        Post-deployment fixes
        Critical Architecture Issues




6/27/2011                 C. Edward Chow   15
MILOCs3^2+1 vs. Incidents
    Square of 3yr moving average of code volume
    shift right one year.




6/27/2011            C. Edward Chow               16
Implication of the curves
    More code, more bugs, more security problems




6/27/2011            C. Edward Chow                17
Security Problems in SW
    Defects: Both implementation vulnerabilities and
    design vulnerabilities.
    Bugs: “fairly simple” implementation-level
    software problem
        Research Tools: FIST, ITS4, Jscan, Metal,
        Prfix/Preffast
        Commercial Tools: Fortify SW’s Source Code
        Analyzer
    Flaw: a problem at a “deeper level”
        Microsoft Bob: A design flow on Windows ME/98.
        “I see you have forgotten your password, please enter
        a new password.”
6/27/2011                 C. Edward Chow                   18
The Use of Unsafe PL C/C++
    Result in buffer overflow attacks. 45% [Wagner2000]




    In theory we can scan, analyze and prove small program
    free of problem. But the size of SW system (even small
    desktop) grows too big for such analysis.
6/27/2011                C. Edward Chow                   19
Examples of Bugs and Flaws




6/27/2011   C. Edward Chow   20
Quiz
    Can code review solve all software security
    problems? How much % of problems?
    Software security is exclusively about coding
    issues.

    Microsoft found 50% of problem uncovered
    during security push are architectural in nature.
    Cigital found 60/40 split “in favor of flaws”
    reflecting Cigital’s specialization in architectural
    risk analysis.

6/27/2011               C. Edward Chow                     21
Risk=Probability*Impact
    Impact: cause great harm.
    Where are these numbers come from?
    How to measure the impact?
    What number to give 0-1?




6/27/2011           C. Edward Chow       22
Software Security vs. Application Security

    Application Security: “protection of software after
    it is built.
        Sandboxing code; obfuscating code, lock down
        executables, monitoring program run, enforcing
        software–use policy, deal with extensible systems.
    It is easier to protect something that is defect
    free than something riddled with vulnerabilities.
    Software security is about building secure sw:
        Design software to be secure
        Make sure that software is secure
        Educate software developer, architects, users about
        how to build security in.
6/27/2011                 C. Edward Chow                      23
Application Security Approaches
    Penetration testing
    Input filtering (block malicious input)




6/27/2011               C. Edward Chow        24
Application Security Problems
    Limit purview of software security.
    Web-based application is not the only problem.
    There are software in wireless devices, cell
    phones, pda, router, server, os, public key
    infrastructures, firewalls.

    Focus on application group.
    Real projects involves systems people, network
    people, architecture group, application
    developers (territorial problems too)

6/27/2011             C. Edward Chow                 25
Application Security Testing Tools
    Can tell you if you are in deep trouble.
    Cannot tell you that you are free of security
    problems. Passing tests is not reassuring.
    Common Problem: focus on input on port 80.
    Input to modern application arrives from
        SSL, environment variables, outside lib, distributed
        components.
    Software security needs to consider also
        Data security, access control, sw environment.
    Prefab test cannot all these.

6/27/2011                  C. Edward Chow                      26
Software Security vs. Operations
    In most organizations, security is the domain of
    infrastructure people who set up/maintain
    firewalls, IDS, antivirus engine (reactives
    technologies)
    These are operators not builders.
    Perimeter defense
    Innerwall philosophy




6/27/2011              C. Edward Chow                  27
Three Pillars of Software Security




6/27/2011      C. Edward Chow        28
Applied Risk Management
    Traditional Architectural risk analysis is important
        AKA thread modeling or security design analysis
        Chapter 5.
    But here we emphasize tracking and mitigating
    risk as a full lifecycle activity. Called it Risk
    Management Framework (RMF). Chapter 2.
        Gather requisite data to make a good judgment call
        based on knowledge of vulnerabilities, threats,
        impacts, and probabilities.




6/27/2011                 C. Edward Chow                     29
Software Security Touch Points




      Adopted by US Government/National Security Task
         Force report, DHS, Cigital, Ernst and Young
        Choose artifact instead of choosing processes



6/27/2011               C. Edward Chow                  30
Microsoft Trustworthy Computing Initiative

    Bill Gate Jan/2002 memo. Included in p.31-34.
    >$300M, >2000workerdays




6/27/2011             C. Edward Chow                31
MS SW Security Process




    Bill Gate “So now, when we face a choice
    between adding features and resolving security
    issues, we need to choose security.”


6/27/2011             C. Edward Chow                 32
Pillar III: Knowledge




6/27/2011    C. Edward Chow   33

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:52
posted:6/28/2011
language:English
pages:33