Shea Ryan Ario Nejad Alan Messinger SECURE SOFTWARE ENGINEERING

SIX FEATURES OF SECURE SOFTWARE 1.Confidentiality 2.Integrity 3.Authentication 4.Authorization 5.Availability 6.Non-Repudiation Typical Black Hat

CONFIDENTIALITY Information should only be accessible to the intended recipient Example: I call my friends doctors office and ask for his test results. The office tells me the results: its Boneitis. I now know confidential information.

INTEGRITY Information should be accurate. Example: I go to the bank and ask for my balance. I should get my actual balance, not the balance as of 3 months ago.

AUTHENTICATION Identity checking (of user or a software component) Example: I check to see if the Bank of America website I visit is authentic with VeriSign

AUTHORIZATION Is the requester allowed to make this request? Example: I have a new job. My employer needs to check that Im legally allowed to work. Let me just make a copy of this

AVAILABILITY Services and information should be available when theyre needed Example: Del Taco (open 24h, because sometimes we need tacos at 4AM)

NON-REPUDIATION There cannot be a way for me to send you a message and later have either of us deny our involvement. Example: I buy something at Amazon. They ship it and provide a tracking number. I must sign for the package.

SECURITY MODELS AND POLICIES A security policy is a statement of the security we expect the system to enforce. Multilevel Security ( Security Levels) The Bell-LaPadula Model ( No read up and No write down) The Biba Model (Read Up, Write Down )

SECURITY MODELS CONT. Multilateral Security Brewer and Nash model. (The Chinese Wall) The BMA Model (British Medical Association)

SECURITY ACCESS CONTROL Access control is an important aspect of any system. Security access control is the act of ensuring that an authenticated user accesses only what they are authorized to and no more. Authentication Authorization

AUTHENTICATION The goals of authentication are verify that the user, either a person or system, which is attempting to interact with your system is allowed to do so. gather information regarding the way that the user is accessing your system.

AUTHENTICATION CONT. There are several strategies that you can follow to identify a client: User id and password. This is the most common, and typically the simplest, approach to identifying someone because it is fully software-based. Physical security device. A physical device, such as a bank card, a smart card, or a computer chip (such as the Speed Pass key chains used by gas stations) is used to identify a person. Sometimes a password or personal identification number (PIN) is also required to ensure that it is the right person. Biometric identification. Biometrics is the science of identifying someone from physical characteristics. This includes technologies such as voice verification, a retinal scan, palm identification, and thumbprints.

AUTHENTICATION CONT. You should consider some or all of the following factors when choosing an authentication method: i.Server and client operating systems ii.The client browser type iii.The number of users, and the location and type of the user name and password database iv.Deployment considerations v.The application type vi.Sensitivity of the data you are protecting vii.Performance and scalability factors viii.Application authorization requirements

AUTHENTICATION CONT.

Anonymous Authentication The information you are protecting is considered "public. Basic Authentication Passwords and user names are encoded using Base64 encoding Digest Authentication It uses a hashing mechanism, MD5 developed by RSA Certificate Authentication You require mutual authentication. Forms Authentication custom user interface component

SSO is a property of access control where user logs in once and gains access to all systems without being prompted to log in again at each of them.

SINGLE SIGN-ON SSO uses centralized authentication servers Generating a single sign-on token SAML, SPNEGO, X.509 Mapping users to applications Identity Provider (IdP) Benefits include: Reduces phishing success Reducing time spent re-entering passwords for the same identity Can support conventional authentication such as Windows credentials Security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users

SINGLE SIGN-ON

CLAIMS-BASED IDENTITY Claims (some piece of information about the user ) Tokens (contains one or more claims) identity providers

CLAIMS-BASED IDENTITY

AUTHORIZATION Authorization is the act of determining the level of access that an authenticated user has to behavior and data.

ACCESS CONTROL Access control models are sometimes categorized as either discretionary or non-discretionary. Mandatory Access Control (MAC) Discretionary Access Control (DAC) Role Based Access Control (RBAC)

MANDATORY ACCESS CONTROL Definition: A system-wide policy decrees who is allowed to have access. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system examines these security attributes and decides whether the access can take place. Individual user cannot alter that access. Relies on the system to control access.

DISCRETIONARY ACCESS CONTROL Definition: An individual user can set an access control to allow or deny access to an object. Access Restrictions are based on the identity of the user, and any process and/or groups to which they belong. File and data ownership: Every object in the system has an owner. In most DAC systems, each object's initial owner is the subject that caused it to be created. The access policy for an object is determined by its owner. Access rights and permissions: These are the controls that an owner can assign to other subjects for specific resources.

DISCRETIONARY ACCESS CONTROL Limitation of DAC: Global policy: DAC let users to decide the access control policies on their data, regardless of whether those policies are consistent with the global policies. Therefore, if there is a global policy, DAC has trouble to ensure consistency. Information flow: information can be copied from one object to another, so access to a copy is possible even if the owner of the original does not provide access to the original copy. This has been a major concern for military. Malicious software: malicious program running by the owner can change DAC policies on behalf of the owner.

ROLE-BASED ACCESS CONTROL A role is a category or set of users who share the same security privileges. RBAC is an access policy determined by the system, not the owner. Although RBAC is non-discretionary, it can be distinguished from MAC primarily in the way permissions are handled.

ROLE-BASED ACCESS CONTROL Using roles rather than specific user identities provides the following benefits: You don't have to change your application when changes occur. Maintaining permissions for roles is easier than for individual users. A user can be a member of more than one role, allowing flexibility in how you assign and test permissions. You can also use roles to indicate the types of operations that a user performs for his or her job.

SECURE DEVELOPMENT LIFE CYCLE

Extreme Security Engineering: On Employing XP Practices to Achieve Good Enough Security without Defining It. Beznosov, Konstantin. BizSec, 2003. Towards Agile Security Assurance. Beznosov, Konstantin & Kruchten. ACM, 2004, 2005. Secure Software Development Life Cycle Processes. Davis, Woody. SEI/CMU, 2005, 2006, 2009. Some of these [Agile] practices are in direct conflict with secure SDLC processes. Almost 50% of traditional security assurance activities are not compatible with Agile methods (12 out of 26). THE AGILE DEBATE

The best practices and methods described are applicable to any and all development approaches as long as they result in the creation of software artifacts. BSI PROCESS AGNOSTIC APPROACH

The participants of the study willing to be identified by name are: Adobe, Aon, Bank of America, Capital One, EMC, Google, Intel, Intuit, Microsoft, Nokia, Qualcomm, Sallie Mae, Standard Life, the Society for Worldwide Interbank Financial Telecommunication, Symantec, Telecom Italia, the Depository Trust & Clearing Corporation, Thomson Reuters, VMware, and Wells Fargo. THE BUILDING SECURITY IN MATURITY MODEL (BSIMM)

CERT at SEI/CMU Architectural-level Patterns Design-level Patterns Implementation- level patterns SECURE DESIGN PATTERNS

Distrustful Decomposition PrivSep (Privilege Separation) Defer to Kernel (PrivSep and Defer to Kernel are specializations of Distrustful Decomposition.) ARCHITECTURAL-LEVEL PATTERNS

Split separate functions into mutually untrusting programs. Reduce the attack surface of the individual programs that make up the system Reduce the functionality and data exposed to an attacker if one of the mutually untrusting programs is compromised DISTRUSTFUL DECOMPOSITION

Motivation Many attacks target vulnerable applications running with elevated permissions. Various attacks in which Internet Explorer running in an account with administrator privileges is compromised Security flaws in Norton AntiVirus 2005 that allow attackers to run arbitrary VBS scripts when running with administrator privileges A buffer overflow vulnerability in BSD-derived telnet daemons that allows an attacker to run arbitrary code as root DISTRUSTFUL DECOMPOSITION

Known Uses Include qmail and Postfix, Both responses to Sendmails security issues in the 90s. DISTRUSTFUL DECOMPOSITION The Big qmail Picture Andre Opperman

SENDMAIL ARCHITECTURE

CERT/CC UNIX EMAIL ADVISORIES

QMAIL ARCHITECTURE

POSTFIX ARCHITECTURE

Consequences Distrustful Decomposition prevents an attacker from compromising an entire system. Even if a single component program is successfully exploited, the other programs still do not trust the results from the compromised one. DISTRUSTFUL DECOMPOSITION

Secure Factory Security specific extension of the Abstract Factory pattern. A caller asks the Secure Factory for an object and gives a specific set of security credentials. The Secure Factory uses the given security credentials to select and return the appropriate version of the object. Caller does not receive any more functionality or data than their credentials warrant. Specializations include Secure Strategy Factory & Secure Builder Factory DESIGN-LEVEL PATTERNS

Secure Chain of Responsibility Monolithic system wide role- based access is broken up into a chain of distinct handlers. More checks of credentials. One breach does not give access to whole system. Specific checks tailored for specific roles/access requests DESIGN-LEVEL PATTERNS

Secure State Machine Separate security mechanisms from user-level functionality. Separate state machines for each Secure Visitor Nodes in a data structure lock themselves from being read. Visitors must provide credentials in order to unlock the nodes. DESIGN-LEVEL PATTERNS

Secure Logger Prevents an attacker from gathering potentially useful information about the system from system logs. Prevents an attacker from hiding their actions by editing system logs. IMPLEMENTATION-LEVEL PATTERNS

Clear Sensitive Information Memory or disk space released for reuse or garbage collection may have sensitive data on it and become visible to unauthorized users. Secure Directory Prevents an attacker from manipulating files used by a program during that programs execution. Pathname Canonicalization Avoid string based paths, symbolic links, aliases and shortcuts. IMPLEMENTATION-LEVEL PATTERNS

Input Validation The use of unvalidated user input by an application is the root cause of buffer overflow attacks, SQL injection attacks, and cross-site scripting attacks. Many web frameworks and language libraries provide support for performing input validation and sanitization. Ruby on Rails Java Struts Pylons Django Resource Acquisition Is Initialization (RAII) Ensures that system resources are properly allocated and deallocated under all possible program execution paths. IMPLEMENTATION-LEVEL PATTERNS

Challenges and Barriers to Adoption: Security Many organizations are uncomfortable with the idea of storing their data and applications on systems they do not control. Migrating workloads to a shared infrastructure increases the potential for unauthorized access and exposure. Consistency around authentication, identity management, compliance, and access technologies will become increasingly important. To reassure their customers, cloud providers must offer a high degree of transparency into their operations. CLOUD THE NEXT SECURITY CHALLENGE

State of Cloud Survey 2011 The survey included 5,300 organizationsfrom small businesses to large enterprisesacross 38 countries. Organizations are conflicted about security rating it both as a top goal and as a top concern with moving to the cloud. The survey found that while many organizations are evaluating the move to the cloud, less than 20 percent have actually crossed the finish line with their cloud implementations. About half of the organizations surveyed said their IT staff is not ready for the move to cloud.

CHOOSE WISELY/KNOW YOUR ENEMY Programming languages can be (partially) responsible for problems Buffer Overflow (C/C++) Format String (C/C++, Perl, PHP, Java, Python, Ruby) %n : causes the number of characters written so far to be stored in the integer whose address is given as the argument Thanks, Indiana Jones ride!

SO WHAT SHOULD WE DO? Test Follow Best Practices

TEST!!! Name Two of Six Features of Secure Software Hint: CIAAAN

BACK TO WORK: BEST PRACTICES Risk analysis (EARLY) What are the threats we may face? (Internal/External) What is the likelihood of each threat? What is the potential impact of each threat? How can we mitigate the risk?

PROGRAMMING STANDARDS Programmers should follow coding standards established by their companies Programmers must be trained so that they follow these standards and understand their value Example: We shall use prepared statements for MySQL queries

TESTING: REWARDING FOR HUMANS AND AI!

TESTING TYPES AND TOOLS Static Analysis Target program is not actively running. Analyzer checks source code or object code. What can it do? Find possible coding errors Mathematically prove a programs behavior matches its specification (using model checking, data-flow analysis, abstract interpretation) Analysis of this is probably a poor investment of time

DYNAMIC ANALYSIS Test the running program What should I test for? Might be time to refer back to those requirements We at least want to test if our program produces the outputs our requirements state (only the patient and her doctor shall be able to retrieve test results)

MODEL CHECKING Model checkers are decision procedures for temporal prepositional logic Some properties can be described using temporal safety properties These say what order of operations is OK for a security procedure Program and its security properties are modeled as finite state automata, then you can ask: can I reach unsafe states?

PENETRATION TESTING Maybe we dont know all the flaws we should test for Lets hire someone to break in! T-Rex tests the systemT-Rex has found a weakness and exploits it

WHAT DO PEN TESTERS DO? Simulate attack by malicious users, both external and internal (perhaps a disgruntled Intuit employee) Determine how feasible attacks are Identify sequences of vulnerabilities that may be catastrophic Find vulnerabilities that security testing frameworks (like Metasploit) may miss Assess potential business impact Check if you can even detect/defend against attacks Recommend mitigation strategies Bonus: eat lawyers

FUZZ TESTING Type of Black Box testing Give the program bad inputs and see how it reacts Check for issues like: Crashing Failing asserts Memory leaks Crossing trust boundaries Good cost-benefit ratio Example: A web application lets me upload files to it. I upload a nice little exploit. Does the application fall for it?

BECAUSE WE LOVE AGILE How do we test with Agile methods? Its impossible! Back to waterfall! Microsoft Employee who I made up assert unit_testing This owl hates agile

UNIT TESTING Each step of the way, we can write unit tests (even before we code!) Design tests to fail initially Code the unit until it passes the test Benefits We can test early! We can test integration! We can test malicious inputs!

BONUS DEMO? Target: www.makeupalley.comwww.makeupalley.com http://makeupalley.com/product/sreview.asp/itemid=52681/ rid=2292164/ http://makeupalley.com/product/sreview.asp/itemid=52681/ rid=2292164/ Failure 1: integrity? Goal: cause search bar to malfunction Method: XSS http://www.messengermods.com/data/thumbnails/18/freaky_ cat.jpg

MORE DEMO Target www.makeupalley.comwww.makeupalley.com http://www.makeupalley.com/user/notepad/evilowl http://www.makeupalley.com/user/notepad/evilowl Failure 2: authorization Goal: log users out Method: Exploit poorly validated input http://www.makeupalley.com/account/logout.asp

REFERENCES http://csrc.nist.gov/nissc/1999/proceeding/papers/t02. pdf http://csrc.nist.gov/nissc/1999/proceeding/papers/t02. pdf http://www.safecode.org/publications/SAFECode_BestPr actices0208.pdf http://www.safecode.org/publications/SAFECode_BestPr actices0208.pdf http://en.wikipedia.org/wiki/Unit_testing http://en.wikipedia.org/wiki/Unit_testing http://en.wikipedia.org/wiki/Fuzz_testing http://en.wikipedia.org/wiki/Fuzz_testing http://en.wikipedia.org/wiki/Penetration_test http://en.wikipedia.org/wiki/Penetration_test http://fie-conference.org/fie2004/papers/1221.pdf http://fie-conference.org/fie2004/papers/1221.pdf

Documents

Shea Ryan Ario Nejad Alan Messinger SECURE SOFTWARE ENGINEERING