arved sandstrom - the rotwithin - atlseccon2011
TRANSCRIPT
The Rot Within My point today is that, if we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
Edsger W. Dijkstra Companies spend millions of dollars on firewalls, encryption and secure access devices, and it’s money wasted, because none of these measures address the weakest link in the security chain.
Kevin Mitnick
Topics Introduction Definitions General Concepts – Areas of Concern Presentation Core Theme Security Development Lifecycle Standards Some Considerations in Detail Conclusions
Definitions Security – confidentiality, integrity, availability, authenticity, non-
repudiation (first 3 are CIA triad) SecDLC – Security Development Lifecycle SDLC - Software Development Lifecycle Attack Surface –
Subset of software system resources that an attacker can use to attack the system
Code that can be run by unauthenticated users Vulnerability – weakness that can be used to cause harm to asset Threat – anything that can cause harm Risk – likelihood that a threat will use a vulnerability to cause harm Control – how a risk is mitigated (my emphasis here is on logical/
technical controls)
Some Areas of Concern Category/Class Category/Class
Authentication E-Commerce Payments
Authorization Web Services
Data Validation Phishing
Configuration Management Denial of Service Attacks
Session Management Error Handling
Sensitive Information Data Integrity
Logging & Auditing
Interpreter Injection
File System
Database Access
Cryptography
Administrative Interfaces
Core Theme Software development is not simple; secure software
development is more difficult still. Application security can’t be bolted on after the fact by
“security” developers. All programmers must understand security.
Organization must be mature enough to field a working SDLC before it can consider a SecDLC.
Secure applications are “self-defending”. Security in a software application must be pervasive and
in depth. Many of the highest priority risks are due to bad code,
not malicious attackers or acts of God.
Other Observations Secure code starts with good code. If code is riddled with defects, is poorly-documented and
poorly tested, and the implementation only loosely corresponds to requirements & design, it is not possible to secure it.
If the organization is not mature enough to support a credible software development lifecycle, it cannot support a security development lifecycle either.
No such thing as “sort of secure” or “partially secure”.
Requirements Requirements: not only what an application must do, but
what it must not. Define security objectives and requirements
An objective is fairly high-level Requirements describe the objective in detail Categories: identity, financial, reputation, privacy & regulatory,
availability (SLAs)
Keep security requirements separate from functional requirements
Complement use cases with misuse cases. Use knowledge of risks and mitigation strategies to start work
on security test plan
Design 1 Understand security policies and regulations Establish components/layers/packages & boundaries
Includes shared and external components Includes other applications on same server or accessing same
databases
Understand data flows and interconnections Understand the security of single components Identify attack surface Perform threat analysis (risk modeling) Principle of least privilege
Design 2 Choose a development methodology
Any will do provided that you’ve got one
Understand the security features and published guidelines for the OS, managed platform, language, libraries/frameworks etc
Establish/select coding standards & principles Clearly identify design work that addresses security
requirements Review source code control & configuration management Complete the security test plan
Implementation Secure implementation demands a higher quality of design than
what is commonly seen today. Establish a philosophy of security:
Enforce least privilege as default. All coding guidelines suggest this.
Assume that if design does not explicitly require use of another component, then that use is not permitted. This includes libraries and frameworks.
Don’t guess at design intent: if required design information is absent make a formal request to have that corrected.
Frequent code reviews, tests, and static analysis. Don’t change the understood system/component
interconnections inadvertently.
SDLC Testing Normal software testing – despite the popular misconception
that it’s all about finding defects – is a QC measure used to verify that a product fulfils the requirements. Functional security testing is the security analog of this conventional
process.
Most security testing is the opposite – here we look for functionality that’s not supposed to be present. Negative requirements: what shouldn’t happen Risk-based testing focuses on testing against negative requirements Rank the risks before planning testing Understand the assumptions of the developers
Testing of all types starts when there is code to test.
Developer Standards All regulations, laws, organizational policies, e.g.
COBIT, ISO 27002, ISO 17799, PCI (DSS), HIPAA, SOX Possibly TCSEC, ITSEC, CTCPEC -> Common Criteria
Coding Guidelines By language, API, framework etc.
Secure Design Guidelines, e.g. OWASP Security Design Guidelines Threat Risk Modelling System documentation
Secure Coding Guidelines, e.g. Secure Coding Guidelines for the Java Programming Language OWASP Secure Coding Practices
Secure Testing Guidelines, e.g. OWASP Testing Guide
Security Code Review Single most effective technique for identifying security problems. Use together with automated tools and manual penetration testing. Security code review is a way of ensuring that the application is “self-
defending”: Verify that security controls are present; Verify that the controls work as intended; Verify that the controls are used where needed.
Reviewer(s) need to be familiar with: Code – language(s) and technologies used Context – need threat model Audience – intended users of application, other actors Importance – required availability of application
Define a checklist Varying levels of review formality – pick the one that suits the moment Build review phases into the Software Development Lifecycle Understand the attack surface
Enforcing Authorizations 1 Assumption: web pages are secured (e.g. web.xml, Web.Config). Now we
want to secure actions/methods, using either declarative or programmatic methods.
Example 1: ASP.NET MVC authorization filter – [Authorize(Roles=“Admin”)] Public ActionResult DoAdminAction() { …various code… }
Example 2: Java EE – JSF Web Tier Programmatic FacesContext.getCurrentInstance().getExternalContext
().isUserInRole(“role”)
Example 3: Java EE – JSF Web Tier Rendering Seam s:hasRole EL, ICEFaces renderedOnUserRole, or custom
user code
Example 4: J2EE/Java EE – EJBs J2EE 1.4 and prior has declarative authorizations Java EE 5/6 have @DenyAll, @PermitAll, @RolesAllowed, @DeclareRoles,
@RunAs annotations for classes/methods.
Enforcing Authorizations 2 The Authorization Disconnect: only the correct roles can
execute specific code…but there are limited or no controls on what that code is or does. Consider platform/language security managers if available Follow the detailed design; don’t stray.
Code reviews during detailed design and implementation are essential.
Static analysis can be used to help identify both calling, and called, code.
Defense in depth
Database Access Many J2EE/JavaEE and .NET applications use a common
database login This can work if the application and schema are rigorously
architected to implement proper security (roles wrt data access) and auditing;
Enforcing access permissions can be simplified in code if a database access layer (DAL) is designed.
Other alternatives include: Each application user has own database login; Proxy authentication to provide user context; Row-level access (e.g. pgacl, Oracle Virtual Private Databases).
Logging Who did what when What:
Authentication attempts; Authorization requests; CRUD operations on data – SQL or similar is often sufficient;
consider with DB auditing; Other events of security import.
Should be possible to form audit trail of user actions. Protect logs as you would other data. Do not log confidential data. Logs must be useful: analysis and reporting tools. Test logs through incident response team exercises.
Errors & Exceptions Fail securely –
Application should not fail into an insecure state Assess when user sessions should be invalidated
Error handling should not provide attacker with information. This includes “human” information that could be used in a social exploit
Use generic error pages Leverage the framework error-handling Keep debugging information in secure logs
Centralize error handling to help prevent information leakage