Cyber Security is one of the things that is often overlooked by organizations unless they have been hacked once or twice. In most cases security breaches can be disastrous. If they are not leading to complete shutdown of the organizations, they can certainly tarnish the reputation of the organization in eyes of its customers. You can find the list of some of most popular hacks in the recent history on this link.
The aim of this blog post is to give you a basic checklist of security practices that applies to companies of all sizes. If you have crossed off every item on the checklist, then you can be assured that a novice/amateur hacker won't be able to hack you.
I have tried my best to compile a basic checklist. But if you feel I have missed something, please ping me in the comments or on my Twitter or LinkedIn and I will add it to this blog post.
A small note on observability
Before we go into the detailed security checklist, it's important to discuss observability. You will notice that observability has been mentioned multiple times in each security category we discuss in the blog. The reason is simple: Regardless of how well you design or implement your security setup, there is always a chance of getting hacked. That is a reality you must accept and be prepared for. Your observability setup can be a huge difference-maker in stopping the attacks when they are happening and preemptively preparing for them. Hackers often prepare for large attacks by poking holes into your system and figuring out the attack vector. If you have followed the checklist below and used your observability set up to support your security measures, you will have a better chance against all current and future attacks.
If you don't know what observability is, please go through this link. I encourage you to read about it as much as possible. People often confuse observability with monitoring, but they are not exactly synonyms. Let me explain with a few analogies -
Monitoring is like having a smoke detector, alerting you to potential fires, while observability is like having a full fire alarm system, pinpointing the exact location and cause of the fire.
Monitoring is like watching a single gauge on your car's dashboard, it tells you if something is wrong (e.g., overheating) but not necessarily why. While Observability is like having access to all the gauges and engine data, it provides a complete picture, allowing you to diagnose the root cause (e.g., faulty fan or coolant leak).
Therefore, while monitoring is a crucial aspect of observability, they are not interchangeable. Ideally, both work together to understand system health and performance comprehensively.
Various categories of security
For the sake of simplicity and better organization, we will divide the checklist into the following sections.
Application layer security
Infrastructure security
Data privacy
Physical security
Backup and disaster recovery
In most organizations, these categories are owned by different teams/people. But if you are a startup developer, then its all on you. Either way, I recommend you go through the entire list.
Application layer security
Years ago, there was a famous joke I used to hear - "If hackers can reach your application and database layer, then they deserve to hack your systems". The joke's premise was that infrastructure security should be strong enough to withhold any significant attack. But times and technology have changed, and the attack mechanisms have become more sophisticated. From supply chain attacks to leaked credentials from the application layer, bad actors always find a way to reach your application layer. But, you can do the following things to ensure you haven't made their life easy.
Don't program endpoints that expose infinite/large amounts of data—whether you have REST APIs, GraphQL, Websockets, gRPC, or something else. Always ensure that you are not programming endpoints that, under any circumstances, allow infinite/large amounts of data to be queryable easily. People often do this for internal tooling within the organization, which becomes the attack vector through social engineering. Also, ensure you control page sizes(and other limits) from the backend and not as an input parameter. This will ensure the bad actor cannot query too much data in a single query.
Strong authentication and authorization - Use proper authorization checks on all interfaces(REST APIs/ GraphQL of whatever else you use). Ensure that these checks are the first set of checks in the programming logic. Never bypass your own system's authentication and authorization. People tend to do that for internal APIs/tools or other exceptional cases (that your manager asked for). However, a single interface like that can be the downfall of your entire system.
Implement the principle of least privilege, granting users and services only the minimum permissions necessary to perform their tasks. Regularly review and update access controls to align with this principle. Do this for credentials of third-party services and cloud providers as well (IAM roles, secure tokens, authorization files etc).
Don't hardcode credentials, and follow twelve factors as much as possible. Configuration-first applications are the future and secure by design. If you don't know what this means, please read this blog post to understand it better in the modern context.
Perform strong validation checks of your input and output and do data sanitization as much as possible to ensure that people cannot execute old-school attacks like SQL injection.
Secure communication and data practices—Enforce TLS on all your endpoints. Ensure that you encrypt mission-critical data, such as users' personal information, payment information, account information, etc. You can also use mutual authentication if you are building for mobile clients or building realtime communication using WebSockets or WebRTC. When it comes to mutual authentication, I prefer client-side certificates over the other approaches as they are relatively simple to maintain.
Implement CSRF protection mechanisms, such as anti-CSRF tokens, to prevent malicious third-party sites from performing unauthorized actions on behalf of authenticated users.
Implement relevant security headers in HTTP responses, such as Content Security Policy (CSP), Strict Transport Security (HSTS), X-Frame Options, etc. I know CORS has caused most developers pain at some point in their lives, but it's worth it when it comes to security.
Regularly update your open-source packages, especially when security updates are released. This will ensure you can prevent supply chain attacks.
Always use timeouts for every long-running task/functionality. This will prevent attacks similar to Slow DOS attacks. If hackers find out that some functionality in your system results in a very long execution and uses a lot of memory and computing, they can use that to overload your system and consequently take it down.
Don't send sensitive information in the logs/error logs - this will be covered again later in the Data privacy section, but just consider this a thumb rule. Any information sent in logs can be intercepted or acquired by users through different means and can be used to determine the attack vector in your system.
Use your observability setup to log and alert about weird behaviour in inputs/outputs of the system. Anything out of the ordinary can be sent to the error logs and then developers can evaluate that not as a bug but as potential security attack.
Do penetration testing and other vulnerability testing, especially if you are building mission critical systems. Hire external agencies if your team doesn't have the necessary bandwidth or skill set to do this.
Think like a hacker - Last but not least, it's very important for developers to think like hackers when they are writing their programs. People in infrastructure roles tend to do this by default because of their training, but in my experience, developers often don't bother with it too much while writing code. Developers need to stay up-to-date on the latest hacks and hacking news, in general, to ensure they know what to take care of while writing code.
Infrastructure layer security
Infrastructure is usually the first to take the hit in case of coordinated attacks. This is also a low-hanging fruit for bad actors if they are targeting a mid-scale company or a startup because they tend to spend less time and resources on infrastructure security. You can follow the following basic pointers to ensure that your infrastructure is secure -
Strong network security - Check your VPC setup for potential leaks like unnecessary open ports or any outgoing traffic that is allowed without any authorization. Infact, revisiting incoming and outgoing traffic settings at a regular interval helps a lot. When you are talking to third-party services, at least ensure that you are using IP-based security. People often ignore IP-based security if some kind of authorization file/key is also available. But please understand that even if the attacker doesn't get access to your data without that file, they can still abuse your endpoints by trying to establish several open connections and keeping them busy. If given a choice between IP-based security and VPC peering, I always try to go for VPC peering. Even though the initial setup is tedious, it's worth it in terms of speed, scalability and security benefits in the future.
Protect your keys, secrets and authorization files like your life depends on it - Implement the principle of least privilege as much as possible. Keep revisiting the permission of each key/secret/authorization file and user at a regular interval. Your infrastructure and application setup should only use keys using environment variables or from mount points in order to avoid accidentally exposing them to people who don't have the necessary authorization.
Keep rotating each user's and service's credentials, keys, secrets and authorization keys at regular interval. For most of these recurring activities, I just mark a recurring event in my calendar. It serves both as a reminder and blocks a time period for carrying out this activity.
If your organization/systems are susceptible to DDOS attacks, you can either setup IP based rate limiting along with alerts for unusual behaviour or go for a paid DDOS protection service depending on the severity of the problem, your team's bandwidth and skillset.
Endpoint protection - Ensure that your API endpoints are not easily accessible or reversible. If you have certain endpoints that expose some privileged data, consider creating them as private endpoints available within your organization's private network.
Use your observability setup as much as possible for infra security - set alerts for 3X jumps in usual metrics (like requests per second, queries per second, operations per second, bandwidth consumption, etc, depending on the resource). Unless these are planned jumps due to some promotional (marketing) activities, they are usually an indicator of an attack. At the infra level, also do as much data validation and sanitization as possible and log/alert any suspicious values received or processed. Attackers often look for edge/corner scenarios of your infra setup to find the attack vector. If your setup is alerting for such a scenario, that will be the first major step in mitigating that attack and even pinpointing the source of the problem.
Data privacy
Have you ever hashed or encrypted your user data when you send them to third-party services such as Auth0 (and other identity management tools), Google Analytics (and other analytics tools like Mixpanel, clever tap, etc.), logging services (sentry, etc.), payment gateways, media providers and hundreds of other third party services you use while building your platform? If not, then irrespective of how secure you make your systems, you are still open to attack. Because now your data security is in the hands of these companies, the larger these companies are, the more susceptible they are to attack. The recent breach of Okta in September 2023 is a classic example of the same. Attackers were able to access data from other companies like Cloudflare, 1Password and BeyondTrust which use Okta's system. And to make matters worse, it was weeks before Okta could assess the magnitude of the data access by the attackers.
Ensure that no sensitive user data is released to a third party. If this data needs to be sent, always encrypt it.
Ensure that the communication between your system and the third-party systems is secure (and encrypted if possible)
Even user behaviour data can be triaged to create an attack vector or to understand your system's internal workings. Be super careful about what you send.
Physical security and human factors
I was once in the offices of a fintech company, where anyone could just enter without any authorization, plug in a USB drive and copy data from any of the systems. Nobody would have even noticed this attacker if done during the correct time (for example, lunch hours). This is the case with a lot of companies that handle financial data. They don't invest heavily in physical security and human factors. The leak can be as simple as a Google sheet containing sensitive data and has poor sharing permissions where it is open to the public for viewing.
Social engineering refers to a trickery technique used to manipulate people into divulging confidential information or performing actions that benefit the attacker. It's essentially a con job that exploits human psychology and vulnerabilities.
If you read this blog on state of social engineering, you will learn that social engineering accounts for more than 90% of cyber attacks in the recent years.
You can take the following steps the following steps yourself and ensure that people in all departments of your organization are aware of them -
Social engineering often relies on a sense of urgency or panic. Take a moment to breathe and assess the situation before acting.
Be sceptical of unsolicited emails, calls, messages, or people approaching you in person. Don't assume they are who they say they are.
Too good to be true? It probably is: If an offer seems incredibly enticing or a situation feels suspicious, it's likely a ploy to manipulate you.
Don't click on links or attachments in emails from unknown senders. Verify email addresses carefully, even those seemingly from familiar sources. Phishing emails often mimic legitimate senders.
Use strong passwords for all your accounts, and ideally, enable two-factor authentication (2FA) for added security. This requires an extra verification step beyond just your password.
Keep your antivirus and anti-malware software up-to-date. These can help detect and block malicious software that might be downloaded through social engineering tactics.
When entering personal information online, ensure the website is legitimate and secure. Look for the https:// prefix in the address bar and a lock symbol, indicating a secure connection.
If you receive a call from someone claiming to be from a company (bank, tech support, etc.), don't give out personal information or grant remote access to your computer. Call the company directly using a verified phone number to confirm the call's legitimacy.
Careful with Physical Documents: Be cautious about sharing sensitive documents or information in person. Don't leave them unattended or readily accessible to strangers.
Social Media Savvy: Be mindful of what information you share on social media platforms. Attackers can use this information to personalize social engineering attempts.
Stay Informed: Keep yourself updated on the latest social engineering tactics. Learning about common tricks can help you identify and avoid them. You can subscribe to the hackernews newsletter. It should be enough to update yourself on recent attacks.
Double check your organization sharing setting and permissions in all the tools used. Enforce the correct permissions at global level (example, nobody should be allowed to share a document publicly irrespective of the circumstances).
Given that social engineering attacks are becoming sophisticated by the day, it is virtually impossible to list down all the actions possible. But the above steps should serve as a general thumb rules to follow in order to avoid getting hacked.
Backup and disaster recovery
I mean to be sarcastic when I say this - If I have to sell why automated backups, point in time recovery and general disaster recovery mechanisms are important for you, then you may not be the right audience for this blog post.
Let's be honest. Irrespective of how much you invest in your security, there is always a talented hacker (or a group of hackers) who will defeat every measure you have put in place. Your backup and disaster recovery setup should probably be the first item on the security checklist.
Automate your backups to run at regular intervals so that you can sleep peacefully at night.
Establish a data retention policy for each of the backup (and backup type) that can factor in both short term and long term goals of the organization. Remember, that there are archival storage solutions like S3 glacier that are available that allow you to retain a lot of data at a fraction of storage cost.
If you are an enterprise, consider backing up data in different availability zones or even different cloud providers in order to be safe. Also, consider disaster recovery drills at a regular interval.
Just don't assume that your backup automations are working correctly. Mark your calendars to check them at a reasonably regular interval (I check once a month).
Document your backup strategy but keep the documentation to limited set of users. Otherwise, hackers may social engineer the backup strategy out of your team members and leverage that information to gain an upper hand in the attack. A lot of ransomware attacks do exactly the same.
Owasp security cheat sheet
While doing research for this blog post, I came across this interesting well-organized cheat sheet by OWASP. Do give it a thorough reading. It covers a lot of topics and is in sufficient detail.
Ending note
Cyber Security is a big business now. There are several billion-dollar companies that are working in the domain of cybersecurity, and I am sure there will be many more down the line. If you are not thinking about security today, then there is a very good chance that by the time you start thinking about it, it will be too late. If you are not actively doing security, the least you can do is to add it as a technical debt. Acknowledging it as a to-do will be enough because you will hear about new attacks and data breaches every month, and the panicky person inside you will force you to revisit that list.
I tried my best to list as much basic stuff as possible. This list will never be complete, but it should serve as a good starting point. And sometimes, that's all you need—a good starting point.
I hope the above system helps you as much as it has helped me. If you have any questions, doubts or suggestions, please contact me on Twitter, Linkedin or Instagram. Do share this blog post with your friends and colleagues.