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