Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
AIT 681 Secure Software Engineering
Topic #2 Software Security Fundamentals
Instructor: Dr. Kun Sun
Readings
• This lecture: – McGraw: Chapter 1– Recommended:
• Avoiding the Top 10 Software Security Design Flaws• https://csis.gmu.edu/ksun/AIT681-s20/readings/Top-
10-Flaws.pdf
2
Outline
• Focuses of software security• Different roles on addressing software security• Three Pillars of Software Security• Avoid Top 10 Software Security Design Flaws
3
What is Software Security?
• Software security focuses on engineering software so that it continues to function correctly under malicious attacks– Functional requirements– Non-functional requirements (e.g., security)– Tradeoff between function/performance and
security
4
Security ≠ Correctness
• An adversary is not a normal user!• The adversary will actively attempt to find
defects in rare feature interactions and edge cases– For a typical user, (accidentally) finding a bug will
result in a crash, which he will try to avoid– An adversary will work to find a bug and exploit it
to achieve his goals
5
Software Security Problems
• Defects: implementation and design vulnerabilities– Bug: implementation-level vulnerabilities
• Program analysis tool
– Flaw: design-level vulnerabilities• subtle, not so easy to detect design problems• Manual analysis
• Risk = probability x impact
6
Why Software?
1. Increased complexity of software product– E.g., Apache server 2.4.29, 37.8MB
2. Increased extensibility– Reason: flexible, rapid deployment– New updates and extensions, e.g. browser plug-
ins, kernel module, word processors, etc.– Windows, Linux, open source/close source
7
Why Software (cont)?
3. Increased connectivity– Internet è no need for physical access– Smartphone è information sharing – IoT è everywhere– SCADA è legacy system
• More lines è more bugs è more security problems
• Increased complexity + extensibility + connectivity ê
Increased risk of security violations!
8
Why Software Security?
Software Security aims to address weaknesses directly9
NOT Security Software
• Security software is any computer program designed to enhance information security.
• Rely on operators, not builders• Examples
– Operating System (OS) security mechanisms– Firewall and IDS– Anti-virus scanner
10
Application Security
• Application security usually refers to security after the software is built– Adding more code does not make a faulty
software correct– Sandboxing – Network-centric approach– Focus on input checking
11
Operating System Security
• Operating systems mediate a program’s actions– Through system calls– such as reading and writing files,– sending and receiving network packets,– starting new programs, etc.
• Enforceable policies control actions– programs run by Alice cannot read files owned by Bob– programs run by Bob cannot use TCP port 80– programs run in directory D cannot access files outside of D
12
Limitations of OS Security
• Cannot enforce application-specific policies, which can be too fine-grained– Example: database management system (DBMS)– Semantic gap
• Cannot (precisely) enforce info-flow policies– An operating system typically implements an
execution monitor: decisions are based on past and current actions
– Information flow policies: a non-action may reveal something about a secret without leaking it directly
13
Firewalls and IDSs
• Firewalls and intrusion detection systems (IDSs) observe, block, and filter messages exchanged by programs– Based on their origin, content, frequency, etc.
• Examples:– Firewall could block all traffic from particular
hosts, or to particular TCP ports– An IDS could filter packets it recognizes are part of
a known exploit pattern
14
Filtering misses attacks
• Firewall filtering is coarse-grained, and unsound– Port 80 is assumed to be HTTP (web) traffic, which is
assumed benign, but can layer arbitrary traffic over HTTP, e.g., SOAP
– Previously benign sources can become malicious• E.g., due to malware infection
• IDS patterns is fine-grained, but still unsound– Attack traffic can be slightly modified to work around IDS
filters (which are often syntactic, not semantic)– Making filters too fine-grained can hurt performance
• Thus compromising availability
15
Anti-virus Scanners
• Anti-virus scanners look for signs of malicious behavior in local files and memory
• In many ways, anti-virus is related to IDS in looking for patterns
• Newer forms of anti-virus scanners are sophisticated, but in practice are frequently bypassed– Trade off precision and performance (latter could
compromise availability)
16
Ex: Heartbleed
• SSL/TLS is a core protocol for encrypted communications used by the web
• Heartbleed is a bug in the commonly used OpenSSL implementation of SSL/TLS, v1.0.1 - 1.0.1f– Discovered in March 2014, it has been in released code
since March 2012 (2 years old!)
• A carefully crafted packet causes OpenSSL to read and return portions of a vulnerable server’s memory– Leaking passwords, keys, and other private information
17
Why existing security software won’t work?!
• Black box security is incomplete against Heartbleed exploits– Issue is not at the level of system calls or
deposited files: nothing the OS or antivirus can do– Basic attack packets could be blocked by IDS, but
• “Packet chunking” may bypass basic filters• Exfiltrated data on the encrypted channel; invisible to
forensics
• Software security methods attack the source of the problem: the buggy code
18
How to address software security?
• Software Development Life Cycle (SDLC)– Feasibility study– Requirements definition– Design– Implementation– Integration and Testing– Operation and
Maintenance
• Options:– Do not address at all– Ad-hoc evaluation– Add security features
after the fact – Identify security
vulnerabilities– Test security level– Incorporate security
throughout of SDLC
To ensure security, we must eliminate bugs and design flaws, and/or make them harder to exploit.
19
Security Objectives
• Confidentiality: prevent/detect/deter improper disclosure of information
• Integrity: prevent/detect/deter improper modification of information
• Availability: prevent/detect/deter improper denial of access to services
Which objective SW security addresses?
20
How to address software security?
• Correctness point of view: We can test whether a given program implements a desired functionality under expected circumstances– Test I/O characteristics– Quality Assurance tests
• Security point of view: How do you test whether a program does not allow undesired functionality under all circumstances?– “Penetration” testing helps, but only up to a point
21
Outline
1. Focuses of software security2. Different roles on addressing software
security3. Three Pillars of Software Security4. Top 10 Software Security Design Flaws
22
Security Engineering
• Reduce the need for reactive technologies (e.g., intrusion detection) by developing safer products à Understand software
• Need for:– Software developers– Operations people– Administrators– Users– Executives
23
Different Roles
• A programmer is concerned with properties of source code such as correctness, performance, and security
• A system integrator is responsible for integrating new and existing software components to create programs or systems that satisfy a particular set of customer requirements.
• System administrators are responsible for managing and securing one or more systems including installing and removing software, installing patches, and managing system privileges.
24
Different Roles (cont)
• Network administrators are responsible for managing the secure operations of networks.
• A security analyst is concerned with properties of security defects and how to identify them.
• A vulnerability analyst is concerned with analyzing vulnerabilities in existing and deployed programs.
25
Different Roles (cont)
• A security researcher develops mitigation strategies and solutions and who may be employed in industry, academia, or government.
• The attacker:– Is a malicious actor who exploits vulnerabilities to
achieve an objective. – These objectives vary depending on the threat. – The attacker can also be referred to as the
adversary, malicious user, hacker, or other alias.
26
Sourcecode
Softwarecomponent Program
VulnerabilitySecurity flaw
may contain may
contain
may possess
composed of
composed of
resolved by
Programmer System integrator
Exploit
attackedby
Securityanalyst
Vulnerabilityanalyst
Attacker
System administrator
ComputerSystem Network
composed of
composed of
Network administrator
may possess
may contain
Mitigation
can lead to
addressedby
Security researcher
Securitypolicy
appliedto
Different Roles (cont)
27
Outline
1. Focuses of software security2. Different roles on addressing software
security3. Three Pillars of Software Security4. Top 10 Software Security Design Flaws
28
Three Pillars of Software Security
• Applied Risk Management• Software Security Touchpoints• Knowledge
29
Applied Risk Management
• How much effort to invest in security• Consequences of security breaches• Acceptable-level of security • Tracking and mitigating risk throughout the
full SDLC
Risk = probability x impact
30
Software Security Touchpoints
• System-wide activity: from design to testing and feedback
• Touchpoints:– Code review– Architectural risk analysis– Penetration testing– Risk-based security testing– Abuse cases– Security requirements– Security operations
31
Knowledge
• Gathering, encapsulating, and sharing security knowledge
• Knowledge catalogs: principles, guidelines, rules, vulnerabilities, exploits, attack patterns, historical risks
• Knowledge categories: – Prescriptive knowledge– Diagnostic knowledge– Historical knowledge
• Applied along the SDLC32
Outline
1. Focuses of software security2. Different roles on addressing software
security3. Three Pillars of Software Security4. Top 10 Software Security Design Flaws
33
34
1. Earn or give, but never assume, trust
• Make sure all data from an untrusted client are validated
• If IP or sensitive material must be stored or sent to the client, the system should be designed to cope with potential compromise.
• Confirm sensitive material really does need to be stored on the client.
• Avoid authorization, access control, policy enforcement, and use of sensitive data in client code
35
2. Use an authentication mechanism that cannot be bypassed
• Prevent the user from changing identity without re-authentication, once authenticated.
• Consider the strength of the authentication a user has provided before taking action
• Make use of time outs
• Do not stray past the big three – Something you are – Something you have – Something you know
• Avoid shared resources like IP numbers and MAC addresses and do not use them as credentials
• Avoid predictable tokens
36
3. Authorization after authentication
• Always follow this order. Don’t assume authorization automatically after authentication.
• Perform authorization as an explicit check
• Re-use common infrastructure for conducting authorization checks
• Failing to revoke authorization can result in authenticated users exercising out-of-date authorizations
37
4. Strict separation between data and code
• Utilize hardware capabilities to enforce separation of code and data
• Know and use appropriate compiler/linker security flags
• Expose methods or endpoints that consume structured types
• Co-mingling data and control instructions in a single entity is bad
• Beware of injection-prone APIs
• XSS, SQL injection, shell injection
• Watch out for – system() C library function– eval() function in Javascript
38
5. All data are explicitly validated
• Ensure that comprehensive data validation actually takes place
• Make security review of the validation scheme possible
• Use a centralized validation mechanism and canonical data forms (avoid strings)
• Use implementation-language-level types to capture assumptions about data validity.
• Watch out for assumptions about data
• Avoid blacklisting, use whitelisting in validation
39
6. Use cryptography correctly
• Use standard algorithms and libraries
• Centralize and re-use
• Design for crypto agility
• Get help from real experts
• Getting crypto right is VERY hard
• Do not roll your own • Misuse of libraries and
algorithms • Watch out for key
management issues • Avoid non-random
“randomness”
40
7. Identify and protect sensitive data
• Know where your sensitive data are
• Classify your data into categories
• Consider data controls – File, memory, database
protection
• Plan for change over time
• Do not forget that data sensitivity is often context sensitive
• Confidentiality only is not data protection
• Watch out for trust boundaries during data transition
41
8. Always consider the users
• Think about: deployment, configuration, use, update
• Know that security is an emergent property of the system
• Consider user culture, experience, biases, …
• Make things secure by default
• Security is not a feature!
• Don’t impose too much security
• Don’t assume the users care about security
• Don’t let the users make security decisions
42
9. Correctly integrate external components
• Test your components for security
• Include external components and dependencies in review
• Isolate components • Keep an eye out for
public security information about components
• Composition is dangerous
• Security risk can be inherited
• Open source is not secure
• Don’t trust until you have applied and reviewed controls
• Watch out for extra functionality
43
10. Be flexible for future changes
• Design for change • Consider security
updates • Make use of code
signing and code protection
• Allow isolation and toggling
• Have a plan for “secret compromise” recovery
• Watch out for fragile and/or brittle security
• Be careful with code signing and system administration/operation
• Keeping secrets is hard • Crypto breaks
44
Summary: Top 10 Software Security Design Flaws
1. Incorrect trust assumptions 2. Broken authentication mechanisms that can be bypassed or
tampered with 3. Neglecting to authorize after authentication 4. Lack of strict separation between data and control instructions,
and processing control instructions received from an untrusted source
5. Not explicitly validating all data6. Misuse of cryptography 7. Failure to identify sensitive data and how they should be handled 8. Failure to consider the users 9. Misunderstanding how integrating external components may
change the attack surface 10. Brittleness in future changes made to objects and actors.
45
Secure Design Recommendations
1. Earn or give, but never assume, trust2. Use an authentication mechanism that cannot be bypassed or
tampered with3. Authorize after you authenticate4. Strictly separate data and control instructions, and never process
control instructions received from untrusted sources5. Define an approach that ensures all data are explicitly validated6. Use cryptography correctly7. Identify sensitive data and how they should be handled8. Always consider the users9. Understand how integrating external components changes your
attack surface10. Be flexible when considering future changes to objects and actors
46
Inhibitors to Establishing Effective Defenses
Cutting Through the NoiseHaving “too much data to analyze” has been a top-three inhibitor to establishing effective cyberthreat defenses for all six years of the CDR. This time around, it finally claimed the top spot (see Figure 2). Based on anecdotal information we’ve been hearing for years – for example, about the “security data/event tsunami” – this finding is not surprising to us. Neither are the related findings of advanced security analytics topping 2019’s most wanted list for all technologies in this year’s report, along with user and entity behavior analytics (UEBA), full-packet capture and analysis, and threat intelligence services following close behind. Related solutions hold the promise not only of efficiently processing mountains of security events and other telemetry, but also of uncovering hidden threats and reducing the frequency of false positives. Add in the powerful benefits of rapidly maturing machine learning and artificial
About CyberEdge GroupCyberEdge Group is an award-winning research, marketing, and publishing firm serving the needs of information security vendors and service providers. Our expert consultants give our clients the edge they need to increase revenue, defeat the competition, and shorten sales cycles. For information, connect to our website at www.cyber-edge.com.
© 2019 CyberEdge Group, LLC. The CyberEdge Group name and logo are trademarks of CyberEdge Group, LLC. All other trademarks and service marks are the property of their respective owners.
intelligence technologies – which a whopping 81% of respondents believe are materially helping to defeat advanced cyberthreats – and enterprise security teams could very well pull their collective heads above the waterline, finally.
Overcoming the Skills ShortageWith 84% of organizations experiencing a shortage of IT security talent, it makes sense to see “lack of skilled personnel” near the top of Figure 2. This pervasive short-handedness emphasizes the need for security products that, simply put, get the job done. Enter security orchestration, automation, and response (SOAR). Emerging offerings promise
The Road AheadSecurity teams must ensure their organization’s defenses keep pace with changes to both the IT infrastructure and the threats acting against it. The good news, at least for 84% of our survey respondents, is that their IT security budgets are expected to increase in 2019. When it comes to investing this windfall, some additional areas to consider include:
� Rapidly maturing risk quantification solutions that help optimize IT security decisions and investments; � A container security platform (CSP) that provides full lifecycle security coverage for your burgeoning population of
containerized apps and services; and � A full-featured security orchestration, automation, and response (SOAR) solution capable of delivering faster incident response
times while reducing the demands on your overburdened SecOps team.
Complimentary Report For a complimentary copy of the full 2019 Cyberthreat Defense Report, connect to: www.dxc.technology/cdr2019.
About DXC TechnologyAs the world’s leading independent, end-to-end IT services company, DXC Technology (NYSE: DXC) leads digital transformations for clients by modernizing and integrating their mainstream IT, and by deploying digital solutions at scale to produce better business outcomes. The company’s technology independence, global talent, and extensive partner network enable 6,000 private and public-sector clients in 70 countries to thrive on change.
Together DXC and Micro Focus help organizations worldwide transform their IT and business processes to reap the benefits of a secure, productive and profitable digital future. Learn more at www.dxc.technology/microfocus.
to do everything from stitching together all of an organization’s disparate policy enforcement infrastructure and event management systems, to handling playbook coding and execution. The general idea is to bring a new level of automation, speed, and accuracy to every corner of the security operations landscape – from vulnerability and patch management to incident response. Of course, engaging outside assistance – in the form of seasoned consulting firms and/or managed security service providers (MSSPs) – is another practical way to address the security talent shortfall. In fact, with nine on 10 respondents’ organizations leveraging an external provider for one or more security services, it’s more than just a practical approach for filling one’s gaps; it’s a proven one.
Figure 2: Inhibitors to establishing effective cyberthreat defenses47
https://assets1.dxc.technology/security/downloads/2019_CDR_Exec_Brief_-_DXC.PDF