If you’ve ever gone through the process of building a new home, or know someone who has, you know that it’s a major process. It’s something that you hope to live with (and in!) for a long time. And in the case of application development, you might even have possibly millions of visitors!
It all starts with a solid foundation. You wouldn’t build your house on unstable ground, would you? The same applies to any business application you’re developing.
Just like we build a home on stable, level ground, we need to ensure we’re building or installing applications on a secure computing platform. Best practices will help us identify and prevent quality issues and security vulnerabilities. A solid foundation will save us time, money, and headaches in the long run.
Understand the network architecture in which the solution will be housed:
- Systems should have most recent reliable OS (e.g., not Windows 2003 Server).
- Systems should have most recent patches.
- Systems should be hardened (e.g., no default settings, no unnecessary services/daemons running, and certainly no unsecure ones).
- Vulnerability scans should be run to verify that the host(s) security posture is reasonably sound.
- Oh, and it should go without saying that developers should undergo periodic secure coding training and code reviewers should undergo secure code review training.
- Availability – does the solution need to include a Business Continuity Plan (BCP) or Disaster Recovery (DR) plan?
Build a strong frame. From a security perspective, this means ensuring that the solution is aligned with your risk appetite. Things to consider:
- What is the nature of the data to be handled? Is any of it sensitive? (e.g., what would happen if it were captured and posted in the newspaper or on a website, or found its way to enemy hands, be it a competing business or be it a rogue state?)
- Once we understand the data sensitivity/value, we should determine which controls should be in place to adequately protect data/applications that we or our customers care about – this will involve encryption, secure coding (e.g., OWASP Top Ten), server side controls, etc.
- Ensure that a security-related test plan is included (in addition to regression testing, etc.)!
- Does the data, application, system, etc., need to be logged/monitored? What about Intrusion Detection System (IDS) or file integrity monitoring?
- What are the authentication mechanisms and are they reasonable for what we’re building?
Measure twice, cut once. Quality is the name of the game. Ensure that good security practices and testing are embedded throughout the development process.
- Infuse security through AGILE System Development Life Cycle (SDLC) – all decisions should include the question – Can this impact the security posture?
- If the answer to the above question is yes, then make sure controls/code are created to adequately address business/security risk. This should be in our everyday decision-making DNA.
- Ensure that important pieces of code undergo code review, including SECURITY-related peer review by those who understand what that means. Sometimes this can be partially performed through automated code review tools, but they should not be relied upon for 100% of the review.
- Findings with security implications (this is subjective, but generally speaking, if the vulnerability allows for unauthorized access or privilege escalation, that would be a bad thing) should be corrected and reviewed. This should also include a lessons learned phase to ensure that the person who wrote the code understands the weakness so they can learn from this.
Flip the breaker – test!!! Just like you would test all systems before you occupy your new home, a new application should be tested extensively before moving into production.
- In addition to the regression testing that we all know and love, all applicable controls must undergo security testing.
- Security testing should include, at a minimum, and to the extent it applies, a network-layer and application-layer penetration testing.
- Any “significant” findings (see “security implications” above) should be corrected with subsequent validation pen testing to ensure that remediation was effective. Holistically, there should be lessons learned for both the person(s) who wrote the code and the person who was supposed to have reviewed the code.
- There should be project audit trails that can demonstrate that these steps have occurred (allows us to demonstrate our own due diligence if ever called upon).
Even a turnkey home requires maintenance. There is constant care and feeding needed to keep your applications running without interruption or security issue. Some of these things can be offered up on a subscription basis:
- To the extent it applies – vulnerability management. Apply patches to OS and platforms (e.g., Apache, Tomcat) on a regular basis.
- Who owns the ongoing monitoring? Is it being monitored effectively? Learn more about how Online can help.
- Periodic vulnerability scans are a great way to determine the system’s current security posture. Scans should be performed at least once every quarter, and after any significant changes.
- Penetration testing should take place at least once a year, and after a significant change. The threat landscape and your environment are constantly changing and, for this reason, penetration testing needs to be completed periodically to ensure your systems are being tested against current threats.
- Change management is critical. Each and every change you make has the potential to cause business disruption or create a new vulnerability. Effective change management minimizes these risks.
No one said that home ownership was easy, and the same can be said for good, secure application development – some of the best things about it go unnoticed after it’s built, but if they are NOT done right, they become quite noticeable!