Your Passion…Your Product…Is it Secure enough?

Are you passionate about your product? I am sure you are!

You spent a few months or years coming up with a great idea.

You spent days and nights brainstorming your idea, doing validation, came across naysayers, and yet you didn’t lose hope.

You worked hard to design, probably did multiple iterations, and built a world-class product.

Your product gained traction, built a user base and trust.

You put all your hopes on your product being successful.

You have a ton of user data, and you are responsible to protect it! 

Did you give some thought on what are you doing about it? 
All it requires is a simple security hole in your product that hackers could use to get in. 

It could just kill everything that you did so far! 

Loss of data, loss of reputation, and more importantly your user’s trust.

Now you see why it is critical to ensure your product is secure. So, the next obvious question is how would you do that?

This blog explains the high-level steps that are required to ensure your product is secure.

Does your application satisfy these requirements?

1. Security Policies and Guidelines

Setting up some policies and guidelines will help your team to think about security during the initial stages of development itself. Generally speaking, most developers focus on functional aspects of the product and their goal is to bring a working product. Even that’s what the business will look for. Often, implementing Security right from the start of the project is not something that’s defined in their scope.

Having a Security Architect at an early stage helps the team to think from a Security perspective and design accordingly. The team will need to be provided with proper guidelines and the Security Architect can help by taking a few things into consideration – Organization Security Policy (if already in place), Industry/Domain the Organization is in, Compliances that are required for that industry, etc.  Without these, we can’t expect the developers to implement good security practices. Policies and guidelines are built on industry standards such as NIST, OWASP, SANS.

2. Secure Architecture Review

Anything that you build needs a strong base. Considering security at a Design level is critical as you don’t have to worry about making major changes at a later stage. Architecture review focuses on both infrastructure and application components. It is required to ensure all the data flows within your application have proper security controls in place that relates to Authentication, Encryption, Access Controls, API Security, Container Security, DevSecOps processes, etc. Defining proper architecture plays a major role depending on the domain your product is in and the compliances that need to be followed. For example, PCI mandates much more in-depth security controls to be in place.

3. Configuration Review and Hardening

It is important to secure the infrastructure where your application is hosted and deployed. It could be on-premises or in the cloud. Ensuring proper configuration is in place and hardening standards are followed is critical. CIS benchmarks could be a baseline standard to start with. Regular patching of your infrastructure is essential.

4. Secure Code Review & Fix

We all know that Code is an integral part of any application. Either your build your own code or import external libraries, testing the code for security is of utmost critical. Source code analysis tools, or Static Application Security Testing (SAST) tools, helps in analyzing the source code or compiled versions of code to find security flaws such as buffer overflows, SQL injection, cross-site scripting. This process helps in finding security flaws early on, so it is easy for the developers to fix them. Think about integrating such tools in your CI/CD pipeline.

5. Vulnerability Assessment & Penetration Testing (VAPT)

Another critical process that most aware of is VAPT. Now that your setup is mostly ready, it is time to ensure proper VAPT is done on both your Infrastructure and Application. Both Blackbox and Whitebox testing need to be considered from outside and inside of your environment. Consider performing VAPT on all OWASP 100+ vulnerabilities instead of just OWASP Top 10.

6. Risk Analysis

Okay, you performed all the above assessments, found a bunch of issues, and probably fixed most of them. But what about the issues that you are not able to fix immediately for whatever reasons, could be technical limitations or business limitations? Can’t imagine leaving those risks alone. It is highly important to assess the risks that are leftover or technically speaking ‘Residual Risks’. We must ensure proper compensating controls are put in place to mitigate as much risk as possible.

Moreover, these risks need to be documented in the ‘Risk Register’ with a proper plan of action to eliminate them when possible. Such risks need to be notified to Business or Application owners, help them understand the criticality and the impact on the business. Depending on the criticality of the risks identified, the application owner might Accept or Deny those risks to be left alone as at the end of the day, she/he will have to approve them and take responsibility. This process could help them to interact with top management and get the necessary funds or resources to eliminate those critical risks.

7. Continuous Monitoring & Management

And finally, you have taken care of everything to ensure your product is secure (for now!) That’s right. Security Assessments are ‘Point in time which means the issues that are identified and fixed ensure that your product is secure during that particular assessment, but it doesn’t mean that security is ensured all the time unless you have regular assessments are performed, continuous monitoring is enabled, new issues are notified, and changes are managed.

Few items to consider for Continuous Security:

  • Ensure proper processes in place so policies and guidelines are updated as required.
  • Review Design and Architecture related changes by a Security Architect.
  • Implement proper tools to identify configuration related issues.
  • Ensure the new code is scanned for security flaws and vulnerabilities.
  • Monitor the release of patches and apply them on both your infrastructure and application components.
  • Integrate Advanced Threat Detection capabilities to identify new threats that apply to your environment.
  • Perform VAPT at regular intervals.
  • Perform continuous monitoring of issues, alerted and notified to ensure resolution.
  • Ensure Residual Risks are properly assessed and put a plan of action to mitigate or eliminate them.

And just because your product is certified for some compliance, it doesn’t mean that it is entirely secure unless all the above processes have been followed. If that’s the case, we shouldn’t be really seeing a lot of attacks as a lot of organizations and their products are certified and compliant, isn’t it?

I hope this is helpful. If you are looking for your Product to be secure, please reach out to us at connect@risksek.com and we are more than happy to provide you Genuine and Holistic Security!

Sarat Lingamallu

Founder & CEO, RiskSek