Jul 29
Ignorance is not a bliss
So, you or your team created a web application, great! But did you concern about protecting it? Here is a checklist from devs to CISOs and CEOs about what you should do and why.
I promise to do other posts describing technical controls that you must have on your site, but before this, we need to make focus on these three commandments:
Stop thinking like: “It’s just a blog” or “It’s just a static site” and other things similar to this… Every web application has a risk of containing vulnerabilities or be discovered new possibilities to have in the future. “Security needs to be a constant concern.”
It’s your business, and you shouldn’t outsource your worries: Let’s delve deeper here.
- Again, stop thinking like: “I’m using a super platform. They already worry about security”. All platforms like AWS, GCP, Azure, Wordpress.org, SalesForce, Outsystems, and anything else have worries about security, but they aren’t ready for your business. They are generic tools to help all kinds of companies, and they need to have some security breaches to accept all types of businesses, not only yours. It’s your job to complement the security controls of your application.
- If you don’t know how to protect your web application, contact a real expert to do it. Ok, this may be expensive, but many security experts can provide occasional services. They can tell you the real risks, and after knowing about them, you can decide what to do (I’ll talk more about it in the future).
Always be suspicious: When you are developing a new site, making changes, creating new processes, or adding new features, you need to analyze the risks before and after publishing. You should consider how much time you will spend on this security analysis. You can use many processes and tools to help you with this. For example:
- Logical Process Review: Think about all the controls this process needs before developing. Ask your process owner, security experts, and the developer/architect to specify these controls;
- Secure Code Review: analyze the code before merging and be published. Many SAST tools can help you in this process. But it’s always suitable for a security expert and a senior developer to make this manually sometimes.
- Security Controls in Place: Ensure the security controls are implemented and configured correctly for your site. (Tools like waf, API gateway, authentication, anti-DDoS, security headers, CDN, reverse proxy, antivirus, system hardening, CASB, and others) These controls must be constantly analyzed.
- Make security tests: Preferably, do these tests before publishing your application. Many Vulnerability Scanning tools can help at this moment (but they aren’t perfect, you need a security expert to analyze and make advanced tests).
- Unexpected behaviors Review: analyze the unpredictable behaviors of your application. They can be security breaches or someone trying to find one. Many tools that work with observability, DAST and SIEM will help at this moment.
- Contract someone to hack your web application: There are many ways to make this. Some companies will sell you Security Penetration Tests; you can have a segregated Red Team on your company or contract someone in the bug bounty platforms. It’s expensive but necessary to have this external analysis when your system is a critical process to your company.
- Have a clear and open channel for receiving security feedback on your site: Even if you have several controls in place to prevent security breaches, users may notice strange behaviors and notify you about it
- Analyze if your providers (platforms, datacenters, and|or services) also have their security controls up to date. It’s no use investing your time and money if your supplier doesn’t do his part.
Don’t worry. Many of these controls can be automatized in CI/CD processes.
I will now stop on these three commandments and take my red pill. I don’t need a blue pill yet. But never knows :/
See you soon.
