• SwA Communities
• SwA Forums & Working Groups
• Workforce Education & Training
•     - Activities
•     - Resources
•     - Collaborations
•     - Licensing and Certification
• Processes & Practices
•     - Activities
•     - Resources
•     - Collaborations
• Technology & Tools
•     - Activities
•     - Resources
•     - Collaborations & Research
• Acquisition & Outsourcing
•     - Activities
•     - Resources
•     - Collaborations
• Measurement & Business Case
•     - Activities
•     - Resources
•     - Business Case
•     - Collaborations & Examples
•     - Resources
• Malware & Cyber Observables
•     - Activities
•     - Resources
• Resilient Software
• SwA Market Place
• SwA Landscape
• SwA Ecosystem
• Security Automation & Measurement
• Build Security In

Resilient Software

The resilient software of the future will require cyber defenses that are proactive, not reactive. Moreover, these defenses, as appropriate, need to marshal automated collective action to protect, detect, respond, and recover our cyber assets. They will categorize cyber attacks and provide a set of future cyber ecosystem capabilities to mitigate those attacks. These desired capabilities are not expected to change as a result of changes in threats, attack methods, technologies, and processes. This is because our approach is based on broad attack categories, not the specific technical details of those cyber attacks that will change as technology evolves. Nevertheless, the cyber ecosystem capabilities must be able to adapt to support new environments, such as the global supply chain and cloud and mobile technologies.  

Software Assurance goals promote the security and resilience of software across the development, acquisition, and operational lifecycle; as such, SwA is scoped to address trustworthiness, dependability (correct and predictable execution), conformance, and survivability. The focus on resilience and survivability enables stakeholders to understand and proactively take action to design, build, acquire, and operate software and software-enabled services with knowledge that software must be able to operate in non-benign environments. Moreover, if compromised, damage to the software will be minimized, and it will recover quickly to an acceptable level of operating capacity; it’s "rugged." Several initiatives have focused on developing rugged software that is attack-aware and self-defending.

Rugged Software

The Rugged Project is a community collaboration effort actively seeking anyone interested in finding new and better ways to create secure software.

The Rugged Software Manifesto enables developers to recognize that their code will be used in ways not anticipated or designed, and that their software will be attacked by talented and persistent adversaries. It enables developers to take a stand—that their software will not be a source of vulnerability or weakness, and that their software will support its mission.

“Rugged” describes software development organizations that have a culture of rapidly evolving their ability to create available, survivable, defensible, secure, and resilient software. Rugged organizations use competition, cooperation, and experimentation to learn and improve rather than making the same mistakes over and over. Rugged organizations also actively seek out threats and create defenses before they are a problem.

Rugged can also be used to describe the software applications produced by rugged organizations. These applications are not only well-protected against attacks, but are also able to analyze themselves, report on their own security status, detect attacks in progress, and respond appropriately.

Rugged is NOT a technology, process model, SDLC, or organizational structure. It’s not even a noun. Rugged is NOT the same as “secure.” Secure is a possible state of affairs at a certain point in time. But rugged describes staying ahead of the threat over time. Rugged organizations create secure code as a byproduct of their culture. You are rugged because you run the gauntlet, instrument your organization and your code, constantly experiment to see if anything breaks, and survive the process of hardening yourself through real-world experience. Rugged organizations produce rugged code that is designed to withstand not just today’s threats but future challenges as well. Rugged also represents a balance between two approaches to establishing, verifying, and monitoring security —a positive control-based approach and a negative attack based approach.

The “Rugged Handbook” and the “Rugged Implementation Guide” are both available via the Rugged Software site at http://ruggedsoftware.org.

Creating Software that is Attack-Aware and Self-Defending (1)

Most developers know that security needs to be built into applications, but most of them also currently implement reactive methods to provide information assurance.  The Open Web Application Security Project (OWASP), under the Season of Code 2008, developed AppSensor (2) as a new approach to application security that is both proactive and provides real-time responses. AppSensor is freely available online for public use. The AppSensor project provides a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the AppSensor tool that can be utilized by any existing application interested in adding detection and response capabilities. Training material is available for download.(3)

AppSensor is based on the theory that conventional defensive measures (i.e., Transport Layer Security (TLS) and network firewalls) lack important aspects of security such as context.  Just like with the use of robust code, they may provide protection from many known vulnerabilities, but there are always unknown vulnerabilities that exist or are introduced with changes. Techniques like TLS are currently in use to provide the services of confidentiality and integrity so that attackers cannot intercept and read/modify messages. However, an attacker could still send a separate encrypted payload to the server in the same way normal traffic is sent without being stopped. Network firewalls are another popular defensive measure that can be circumvented with ease. They allow/deny data on a per port basis, but then cannot truly detect malicious intent in the payload of traffic sent over the allowed ports.

AppSensor is more effective at detecting and responding to threats because it is implemented within the individual applications (and is therefore specific to each one) and receives/provides additional data externally in order to analyze events. Most software applications lack sensors that can be used for intelligence about what is occurring and whether or not it should be happening that way. However, it is possible to make such a determination since applications are aware of the code logic and roles/permissions of users. It is also possible to do so in real-time. AppSensor includes over 50 detection points and also provides documentation to help create custom ones, which is often more effective, using the OWASP Enterprise Security API (ESAPI) library as a model.

The best place to start with AppSensor is during the development lifecycle.  Developers can add specific sensors into their robust code that will be used by the AppSensor analysis engine. The analysis engine utilizes data from the sensors to track history for behavior profiles and determine what kind of response is necessary.  These behavior profiles help differentiate between normal and malicious behavior, especially when combined with the human interface aspects of applications.  AppSensor can be told which inputs should be keyboard entry, which ones require client-side validation, and which ones should not be changed by users.  It also prevents using obfuscation to bypass black list inspections since all data within the application is fully canonicalised.

Once detection points have been implemented into the code, AppSensor can gather data and set thresholds for each point or group of points. These thresholds are the basis of the real-time responses. Responses are conventionally one dimensional with a binary result such as allow or deny. With AppSensor, responses can be two or even three dimensional. The second dimension is added by the ability to group detection points and user groups for responses. The third dimension is added as it collects data over time to build behavior profiles. When combined with other systems, AppSensor can lock accounts, remove permissions, etc. As such, it is fully capable of being integrated with other systems such as Intrusion Detection Systems (IDS).

The AppSensor project is well-aligned with U.S. Federal Government initiatives for software assurance, especially efforts researching and advancing security technologies like active defenses (with real-time response engines).  AppSensor improves compliance, reduces risk to data, and reduces the consequences of breaches. It is able to provide proactive mechanisms and respond in real-time with a very low false positive rate. Most importantly, it solves an age old problem where it is necessary to protect critical data/systems with little to no visibility of the overall health of the environment. OWASP is working to reduce implementation overhead so that all companies can have insight into custom attack attempts occurring within their applications.

 
Top

 

Contact Us Terms of Use Privacy Policy Sitemap Get a PDF Reader ©2013 Department of Homeland Security