Nowadays, data breaches are a subject of conversation at dinner tables and in boardrooms. Cyber insurance premiums to cover these breaches are skyrocketing. Recent surveys and breach reports have highlighted the challenges with software security.
The 2015 Annual Verizon Data Breach Investigations Report points out that applications are the number one attack vector leading to breaches. The 2014 State of Open Source Development and Application Security Survey says poor software controls put 75% consumers are risk. Others have suggested 90 % of data breaches are caused by software vulnerabilities. This is result of poor software design, testing and use of untested third party modules
It is time organizations implement tighter controls around in-house software development, and implement DevOps processes that adhere to a defined standard.
Data is often pulled from main systems for analytics purposes, home-grown applications are then used to process and build dashboards. Most organizations are not equipped to build a software development practice to ensure in-house software development is of the same quality that is expected of a mature software provider.
The risks associated far outnumber the benefits as bad guys are looking to exploit vulnerabilities to gain a foothold in your network and quietly steal data without anyone finding out. We all know the statistics around the breach discovery timeline and the cost of breach management.
The core challenges are poor software design, testing, and use of third party modules that expose sensitive data and are rarely patched for vulnerabilities.
A few strategic steps can move the needle towards safe from danger.
- Develop a corporate Software Development Lifecycle Policy (SDLC): A simple short two to three page policy outlining the company’s position regarding in house software development. The policy must provide concise guidelines about what is required if a department wants to develop software, tools, and reporting applications to save costs and time. Publish the approved policy, and distribute and promote the policy so that all concerned parties are aware of the policy. The policy should require the SDLC framework be used to maintain consistency and discipline.
- Centralize governance of all in-house development: It would be impossible to centralize all development but centralizing governance may help protect the environment. This will, of course, require a core team with expertise in SDLC, and training in secure software development. Essentially, it is a product manager who leads the use of resources that do not report to him. The governance process should require the following for approval before the product can be released for use:
- Requirement and design document: The design document should provide information on how the software will be developed and the business problem being addressed. What platform will it support: thin, mobile application etc. Database design for review to ensure data security should also be provided.
- Core development requirement: There need to be requirements around access and data management. For all key systems access control should be through central access management such as Active Directory or a similar identity system. Direct database access, and process management controls need to be setup according to the company’s privileged account management policy.
- Application development and testing: The plan needs to outline development; software security testing phases that demonstrate all vulnerabilities associated with the chosen technologies will then be tested and resolved. A number of questions need to be answered at this time, including:
- If third party modules are used, how will security be taken into account?
- How will encryption be utilized to secure data at rest and in motion?
- What level of logging and alerting is part of the features used to detect malfeasance?
- And if needed require penetration testing for applications that present a risk of data loss. For a larger software development project, consider utilizing DevOps techniques.
- Roles should also be tested to ensure that user roles are not able to perform functions or see data that they are not authorized to perform or see.
- Lifecycle support for supported technologies: A big issue with in-house development is support of end of life systems. When SQL and Operating Systems are end of life and then subsequently end of support, there is rarely a process or mechanism in place to migrate the legacy application to a supported environment. IT ends up supporting systems that cannot be patched because it would cause a critical application to cease to work.
Additional precautions can also be taken to further fortify security of applications and databases. Web Application Firewalls (WAF) can also be used to help protect poorly developed applications or legacy applications.
Database Access Monitoring (DAM) is also a very good mechanism to monitor and detect and control access to databases subsequently, unauthorized access can be detected and application vulnerabilities can also be uncovered. It is also good practice to implement centralized logging of security tools, authentication systems, and user demographic information.
This and the other aforementioned points can help immensely by quickly detecting abnormal activity enabling you to mitigate in a timely manner – hopefully making those conversations at the dinner table and in the boardroom less frequent.