If you run a SaaS business or mission critical software, the security of your web platform is crucial to your success. You may not, however, know the questions to ask your technical staff or outsourced providers. Knowing the answers to these questions can highlight vulnerabilities you need to address before they become a nightmare scenario.
This list and associated recommendations are not comprehensive, but should be used as the starting point to a larger assessment of your valuable technical assets. If you don't have complete answers to these questions from your team, bring in a security professional to analyze and address the issues before they are exploited.
1. Are your development or staging environments leaking data or credentials?
Developers often copy actual production data to a development environment to test new features. This isn't necessarily bad practice depending on the sensitivity of the data, but it can be if PII (Personally Identifiable Information) is involved. They also often use the same usernames and passwords to connect to the database, a caching system or other resources. The problem is that development environments are not usually as secure as production and make for an easier target to attack. Solutions like mock data, a subset of the production database and different credentials should be used.
2. How does your application get authorization to connect to other systems?
Web servers often need to use credentials to interact with data from another system like the database. They can also be used for automated activity on a third-party service like an API. Those credentials should not be in your code or checked in to your version control system. They should be encrypted and ideally should be temporary with short expirations.
3. Are any critical services available on public IP addresses?
Nothing in your network should be on the public internet unless absolutely necessary, especially your database. These belong in a private network with tightly restricted access.
4. Do you use HTTP instead of HTTPS anywhere that is publicly available?
For the resources that are available publicly like load balancers, web servers and the CDN (Content Delivery Network), HTTP should disabled or automatically redirected to HTTPS.
5. If any component of your infrastructure were breached, how much access would an attacker have from that system?
For each individual system on your network like servers, databases, monitoring hosts and bastion hosts you should know what else could potentially be compromised. Limiting the damage is done by Network Segmentation. Many attacks start by exploiting a small crack in the armor, then spread from the inside, so separating access internally is important.
6. Are you limiting outbound as well as inbound traffic?
Modern networks don't assume attacks will come from the outside. Good security also includes limiting what can leave your servers or networks. Malware and other types of attacks try to spread by contacting local servers or "phone home" to a master server and get updates. Control exactly what your internal resources can reach to firewall any malicious activity.
7. Do you have an exit process for technical staff and contractors?
When a user leaves your company, especially privileged administrators or developers, disabling their access thoroughly is an important step. Even if they leave on good terms, their credentials can still get in the hands of the bad guys. Old, unused logins and passwords are easy targets. Create a process that serves as a central inventory of the services used and as a checklist for offboarding. Similarly, you should have a process for onboarding new hires and keep both updated.
8. Do have clearly defined privilege levels for everyone working on your web application?
In the mad rush to get products to market, we often just give everyone the "Full Admin Access" IAM role out of convenience. For trusted team members, this is sometimes needed for working on highly interconnected projects. For contractors or other users, this can end badly. Whether by intent or ignorance, giving too much permission opens the door for catastrophic problems. Create well-named groups of access and assign each user to the appropriate group. Even senior administrators and developers should be working with limited privileges unless escalation is necessary. These include user roles, ssh keys, IAM policies, DB permissions, etc.
9. Have you ensured your employees and contractors are encrypting their drives, locking their devices and using Multi-Factor Authentication?
All it takes is one stolen laptop or eavesdropped wifi connection to ruin your company's day. Make sure all your employees, including the non-technical staff, practice good security. My blog post on securing your digital life is a good place to start.
10. Have you checked all your S3 buckets to make sure they are private?
Specific to AWS, S3 is an incredible resource and dangerous vulnerability if left open. Many major recent data breaches occurred because of unsecured S3 buckets. Make sure all your buckets are private unless they require public access for an explicit purpose like hosting a public website. Even then, using CloudFront and OAI with public access disabled is a better option.
Next Steps
Regularly assessing the state of your infrastructure will not only help keep your data safe, but it will also improve overall operational efficiency. Make sure you have a qualified, up-to-date specialist reviewing these and related questions, making actionable recommendations and educating your team.