2013 was a crazy year for internet security and information privacy. From Edward Snowden's NSA revelations to the Target Christmas Heist, our data was everywhere, some government, some personal. The consensus on how much privacy is enough privacy will rage on in 2014. And the proposed legislation will continue to languish as new legislation joins it.
In most countries there are regulations regarding information privacy, but in the US it’s still the wild west. In the US, the responsibility for securing potentially sensitive data falls on business and is passed to the consumer hidden in excessive service agreements. Currently the only assurances that the consumer has that their data is being safely stored and transmitted is a few lines of type in a service agreement and a lot of legal words absolving the aforementioned entity from any responsibility.
The Target heist is being blamed on outdated POS systems being used across the US. In the past, the credit card companies have typically accepted the cost of a data breach as the cost of doing business, because it's less costly than upgrading the systems. As these breaches get more costly, the credit card companies are looking to share the blame, therefore the cost. In some states the merchant, hosting company or developer may be liable for some of the loss. But with the current state of the laws, it is just a game of CYA. And the lawsuits are piling up.
The full extent of the consequences of wide spread data breaches will play out in the Target heist. These wide spread, high profile attacks are a PR nightmare and will cause brands to lose consumer confidence. In order to prevent this, the priority for businesses that use, store or transact customer data should be security of the data and the systems that transmit and store the data.
Security is a process, not a product. Security has to be built into any system from the start. In this blog I will discuss a holistic approach to security to ensure the security of the system and the data within.
The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. They provide guidance on a holistic approach to security and provide a ton of resources and useful tools.
Software development is a combination of people, process, and technology. An effective testing program should have components that test:
- People – to ensure that there is adequate education and awareness;
- Process – to ensure that there are adequate policies and standards and that people know how to follow these policies;
- Technology – to ensure that the process has been effective in its implementation.
Unless a holistic approach is adopted, testing just the technical implementation of an application will not uncover management or operational vulnerabilities that could be present.
OWASP promotes the following holistic approach:
There is No Silver Bullet
There is no security scanner or firewall that will provide all of the defenses or identify all of the problems, in reality there are no silver bullets to solve all of the problems that can be present in an insecure software system. It is important to consider security from the start, to plan accordingly and follow through.
Security is a process, not a product.
Think Strategically, Not Tactically
To prevent reoccurring security problems within an application, it is essential to build security into the Software Development Life Cycle (SDLC) by developing standards, policies, and guidelines that fit and work within the development methodology. Threat modeling and other techniques should be used to help assign appropriate resources to those parts of a system that are most at risk.
The SDLC is King
By integrating security into each phase of the SDLC, it allows for a holistic approach to application security that leverages the procedures already in place within the organization. Typical SDLC phases include: define, design, develop, deploy, maintain. Each phase has security considerations that should become part of the existing process, to ensure a cost-effective and comprehensive security program.
Test Early. Test Often
When a bug is detected early within the SDLC, it can be addressed more quickly and at a lower cost. A security bug is no different from a functional or performance-based bug in this regard. New threats arise constantly and developers must be aware of those that affect the software they are developing.
Understand the Scope of Security
It is important to know how much security a given project will require. Discussions should occur with legal council to ensure that any specific security need will be met. Compliance, ie HIPPA or PCI, to protect sensitive data, should be known at the outset of the project to ensure that it is properly implemented and tested throughout the process.
Develop the Right Mindset
Successfully testing an application for security vulnerabilities requires thinking "outside of the box.” Good security testing requires going beyond what is expected and thinking like an attacker who is trying to break the application. This is one of the reasons why automated tools are actually bad at automatically testing for vulnerabilities: this creative thinking must be done on a case-by-case basis and most web applications are being developed in a unique way
Understand the Subject
One of the first major initiatives in any good security program should be to require accurate documentation of the application. The architecture, data-flow diagrams, use cases, and more should be written in formal documents and made available for review. The technical specification and application documents should include information that lists not only the desired use cases, but also any specifically disallowed use case. Finally, it is good to have at least a basic security infrastructure that allows the monitoring and trending of attacks against an organization's applications and network
Use the Right Tools
While we have already stated that there is no silver bullet tool, tools do play a critical role in the overall security program. It is important to understand exactly what these tools can and cannot do, however, so that they are not oversold or used incorrectly.
The Devil is in the Details
It is critical not to perform a superficial security review of an application and consider it complete. This will instill a false sense of confidence that can be as dangerous as not having done a security review in the first place. Care should be taken to verify that every possible section of application logic has been tested, and that every use case scenario was explored for possible vulnerabilities.
Use Source Code When Available
If the source code for the application is available, it should be given to the security staff to assist them while performing their review. It is possible to discover vulnerabilities within the application source that would be missed during a black box engagement.
An important part of a good security program is the ability to determine if things are getting better. It is important to track the results of testing engagements, and develop metrics that will reveal the application security trends within the organization. Metrics are not easily developed, so using standard metrics like those provided by the OWASP Metrics project and other organizations might be a good head start.
Document the Results
To conclude the testing process, it is important to produce a formal record of what testing actions were taken, by whom, when they ware performed, and details of the test findings.
The report must be clear to the business owner in identifying where material risks exist and sufficient to get their backing for subsequent mitigation actions. The report must be clear to the developer in pin-pointing the exact function that is affected by the vulnerability, with associated recommendations for resolution in a language that the developer will understand.