Shanty or Fortress? How Application Development is Like Building a House

If you’ve ever gone through 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 millions of visitors!

Foundation

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.

Like building 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 the most recent reliable OS (e.g., not Windows 2003 Server).
• Systems should have the most recent patches.
• Application developers should harden systems (e.g., no default settings, no unnecessary services/daemons running, and no unsecured ones).
• Application Developers should run vulnerability scans to verify that the host(s) security posture is reasonably sound.
• 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?

Frame

Build a strong frame. This means ensuring that the solution aligns with your risk appetite from a security perspective.

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 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 our customers or we 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!

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, ensure that controls/codes are created to address business/security risks adequately. Again, 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.

Test

Flip the breaker – test!!! Like you would test all systems before you occupy your new home, you should test a new application extensively before moving into production.

• In addition to the regression testing 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.
• Project audit trails should demonstrate that these steps have occurred (allows us to show our due diligence if ever called upon).

Maintenance

Even a turnkey home requires maintenance. Constant care and feeding are needed to keep your applications running without interruption or security issues.

Some of these things can be offered up on a subscription basis:

• To the extent it applies – vulnerability management. Regularly apply patches to OS and platforms (e.g., Apache, Tomcat).
• 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 occur at least once a year and after a significant change. This is because the threat landscape and your environment are constantly changing. For this reason, penetration testing needs to be completed periodically to ensure your systems are being tested against current threats.
• Change management is critical. 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 homeownership 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 they become quite noticeable if they are NOT done right!