Security Considerations – Building Software vs. Building a House

Have you ever imagined building your dream house without any security considerations ? What about software or products that we are building? It occurred to me while constructing my home that there are some similarities between building a house and building secure software.


Put people first! Builders, architects and designers make your dream a reality. Pick the right people for the work you plan to do, whether it’s building a house or secure software.


Technology stack considerations and security standards in the industry will enable the organization to gain customer trust. Determine and come up with a framework that works best for your company and customers.


Cost of building security after the structure is built is always higher than when it is built-in during the inception phase. Planning on including security requirements in the inception phase provides an edge over bolting on security at a later phase.

Design Considerations

Everything is design. Everything. Security is not outside design; it is an integral part of it. How our home looks is a reflection of us, and that truth is the same with the products we build.

When deciding on the structural elements of a home, common options include steel, cement or wood. For building products, these are tantamount to the hardware, software, technology stack, and programming language. These choices then determine the bricks and tiles. In software development, following security standards such as use of pre-hardened images, and CIS benchmarks and standards can help avoid a lot of security debt in the future, which also reduces development cost.

The door and windows of a home are akin to ports and protocols. Just as we ensure we have the strongest door for the entries and exits, we must also pick the right ports and protocols for your design. Do not compromise on these.

Of course we want our homes to be resilient, so we are attentive to the beams, pillars and load-bearing walls that are integral parts of the overall design. Just like structural resilience, resilience of software needs to be thought about upfront. Make use of tools and technology and have SAST, DAST and protocol robustness tests as part of the development plan.

Few people would design a home without installing safety locks. Some may even have hidden vaults and other security mechanisms built-in. We need the same for critical data like customer PII, secrets and passwords, and must use secret management software that fits the design. The homeowners and their personal belongings and investments must be protected. In the same way, data privacy and protection needs to be part of software and product design. We need to encrypt the customer data, keep it safe, protected all the times – in use, at rest and in transit.

As we build, we must also look for leakages and loopholes and fix them. Security debt can grow quickly and easily. Don’t ignore it. Investing early in continuous monitoring with best-in-class detection mechanisms will go a long way. There are lots of tools that can help in this.

What about Re-Architecting?

Not every house or product is going to be built from the ground up, and it will often be the case that instead of building new, we are re-architecting or trying to secure a product that is already built with very few security considerations. This process is always a struggle and takes longer to achieve the desired security standards.

Renovating a house is similar to re-architecting legacy software to meet current customer demands and compliance. If this is the road you must travel, consider taking a risk-based approach. Always evaluate the high-risk areas to get the maximum value and consider the customer impact. Taking a phased approach can help minimize customer impact and maximize product experience.

Consider the ways to layer in defence. Replace broken structures with current, stronger and better options. Wherever possible, replace risky and vulnerable areas with better options, such as using TLS 1.2, 1.3 with stronger ciphers, keeping third-party software updated and patched regularly, and hardening the production components like OS.

Technology stacks take longer to re-build, deploy and re-test, particularly if you are covering all supported functionality. While re-architecting there may be fewer options and flexibility depending on the older architectural design choices, which means it is wise to evaluate the costs vs. benefits, especially if there are hardware-related dependencies. Because it’s always harder to add on security at the end, it’s a much better approach to ensure security is built-in throughout the process.


Share With Your Community:

*** This is a Security Bloggers Network syndicated blog from RSAConference Blogs RSS Feed authored by RSAConference Blogs RSS Feed. Read the original post at: