Common Infrastructure Security Mistakes Made by Startups
Throughout my career, I observe that we are solving the same security issues over and over. The technology may change, but the problems don’t.
In the military, we used two concepts two describe problems of technology: 1. People, Process, and Technology 2. Prescriptive v Kinistec.
These concepts will help to shape the way I describe common mistakes. In a prescriptive manner, we follow written guides for every aspect; alternatively, in the Kinesthetic learning method, we feel our way through the issues and deal with them based on how they make us learn through experiences (or gut instinct). Less experienced professionals use the latter by building consensus or dealing with high priority reactive issues. More experienced professionals are likely to follow proven written methodologies. Both perspectives have different advantages and disadvantages. In the concept of people, process, and technology, we demonstrate an understanding that all problems cannot be solved by only adding more people, more technology, or more intricate procedures. On the process side, the issue is demonstrated by how easily we are all driven crazy by telemarketers with scripts or every sale and interaction, followed by an in-depth survey.
The problem with many of these mistakes is it creates an ever-increasing technical debt against which security is consistently de-prioritized for business growth. The Agile methodology compound and exasperates the issues. The result is a set of data breaches and hacks that are always effective using standard techniques. The fact that the OWASP 10 issues haven’t changed much in the last ten years is a testament to this.
2019 was a banner year for data breaches. If you take a look at this list, you can see a well-known set of problems.
- Unsecured Webpage / Database / Service
- Changing URL information
- Commonly used passwords
- Github w/AWS Keys
- OWASP top 10
Mistake 1. Governance
Startup companies are just so happy that they got funding or got an application to be saleable that they ignore basic business functions like having policies.
At a minimum, all companies need to have the following written Guidance:
- Acceptable Use Policy
- Password creation and maintenance Policy
- Policy on Background Checks for employees with elevated access. (this can include Customer Service Representatives)
- Security Framework
- Secure Coding Practices
- Standards and Review Procedures
- Change Control Procedures
- Key and Cryptographic rotation procedures
- “Don’t put your passwords and keys in GitHub.”
When a company is 1–10 people working in a small space, these issues are settled by group consensus and yelling across the room, “What do you think we should do?”
As the business grows, customers and vendors may ask questions related to security and processes. I pulled this language from a public RFP.
Data Security. Evaluate and assess current enterprise database security controls for mission critical applications located within the Finance, Fire, Human Resources, and Water Services Departments. Assessment should focus on controls for both regulatory and legal compliance (HIPAA, PCI, PII) as well as controls protecting Restricted City Information (RCI) following the NIST Cybersecurity Framework, per http://www.nist.gov/itl/csd/launchcybersecurity-framework-021214.cfm and http://www.nist.gov/cyberframework/upload/cybersecurity-framework021214.pdf
Eventually, the sales process requires a company to tell its “security” story. Making sure your companies story will sell is essential.
Mistake 2:
Choose standards before anything gets built.
In the United States, we have national standards. In other countries, they have regulations as well. The NIST Standards are about 80–90% of most others. So following it will make it easier to do business domestically and internationally.
Read the full Executive Order on America’s Cybersecurity Workforce at https://www.whitehouse.gov/presidential-actions/executive-order-americas-cybersecurity-workforce/.
My recommendations are as follows:
- NIST 800–53r4 or r5 when it comes out.
- NICE: NIST 800–181 (a cut down version of 800–53)
- CIS Hardening standards for all technology that has them. (AWS, Azure, GCP, Linux, Windows, Docker, etc) https://www.cisecurity.org/cis-benchmarks/. These are guides, not checklists.
- Vendor Best Business Practices (AWS has a long list of these)
The NICE Cybersecurity Workforce Framework (NICE Framework), NIST Special Publication 800–181, is a national-focused resource that categorizes and describes cybersecurity work. The NICE Framework establishes a taxonomy and common lexicon that describes cybersecurity work and workers irrespective of where or for whom the work is performed. The NICE Framework is intended to be applied in the public, private, and academic sectors.
Mistake 3:
IP address management or lack of it
A common misconception is that you don’t need network engineering in the cloud. Most companies want to multi-hat someone that is a programmer, cybersecurity (enterprise-level), network guy, terraform programmer, and AWS expert. These are vastly different disciplines, and knowing just a little can have some disastrous problems in technical debt.
Everybody decides that they will rule the world and use a Class “A” address 10.0.0.0/8 everywhere in AWS. What they fail to understand is that all of that space, approximately 16.7 million IPs, needs to be tracked and can’t be duplicated anywhere in their organization.
When you spin up an AWS environment and assign 10.0.0.0/0 to each account, you can create a security tooling nightmare. Most tools still focus on IP addresses, not AWS ARNs. Proper Management of IP space will simply “oodles” of problems.
Case in point:
Almost every home and guest wireless networks use space from RFP 1918. (Private Addresses).https://tools.ietf.org/html/rfc1918
Recommendation 1: Don’t use the following address space anywhere in a startup. Avoiding some IP ranges helps you track rouge systems.
Home Routers: 192.168.0.0/16
Default AWS Space: 172.16.0.0/12
Widely used Class A portion: 10.0.0.0/16
These addresses are widely used by well-known retailer’s like Starbucks and in almost every hotel
Recommendation 2:
Subnet your 10.0.0.0 network into/16 or more. Subnetting will give you approximately 254 class “B” networks of 65,000 hosts.
Allocation Guidelines:
Corporate Offices: 10.1.0.0/16.
Guest Networks and VPN connector space: 10.2.0.0/16
Unrouteable Docker and Kubernetes internal networks: 10.255.0.0/16. Sub allocate this as much as possible.
10.3.0.0/16: AWS Root Account
10.3–254.0.0/16: AWS Sub accounts.
Use a /21 or 21 for each VPC (that is 4–8k of address space)
Make sure that Development, Test, and QA don’t have overlapping allocation. Avoid all temptation to use hardcoded IPs in your architecture and create IP identical environments.
Mistake 4:
Initial lack of Single Sign or and Over-reliance on O365/gSuite directories. To maintain the level of security required under almost any framework, you need to have centralized control over access to all cloud services, workstations, and OS based VMs. These must also have Two Factor(2FA) authentication.
Recently, I found JumpCloud that provides a free single sign-on for up to 10 users. After that, I recommend Okta and OneLogin.
Case in point:
Without variation, every AWS deployment starts with regular user accounts and off the wall IAM policies. Later there is a massive re-engineering effort to use a singles sign-on provider.
Recommendation:
Make sure that all of your vendors support SAML or LDAP for SSO.
Mistake 5:
Bad Cloud Architecture and capacity planning
Design your architecture to scale with your project growth. Don’t just add more “stuff” as needed.
The SDLC model of Development, Staging/QA, and Production is valid in all models. CI/CD is no different.
Recommendation:
Create at least the following AWS account structures:
- Root Account
- Development Account
- Staging Account
- Production Account
- Security and AdHoc Account.
Use complete automation to spin out the accounts and not the console. Configuration Management is another critical factor in security frameworks. Terraform is free and is very easy to use.
Recommendation:
- Know before you grow. — Do a costing model
- Make sure you are using the correct services. (RDS v EC2 w/database).
- Engage the AWS transformation teams before you start. They will frequently review your plan for free.
Mistake 6:
Too much reliance on vendors and too many vendors.
When it comes to security, using the shared security model to avoid doing the security work and oversight does not protect your company from the front page of the Wall Street Journal.
Do due diligence in your cloud vendors. If they store your customer’s information, they must comply with the standards required for wherever your clients are. They also must have the same or higher standards for access to data with their employees as you do.
Outsourcing your SOC and Infrastructure still has to have oversight and due diligence. Auditors will not accept, “They handle all that security stuff.”
Mistake 7.
Patch and Vulnerability program/system/methods for all of your infrastructure and IT systems. Antivirus and endpoint systems like Crowstike are not a common operating picture for risk.
In all cases, systems must be secure against published vulnerabilities. There are only two ways this happens is by scheduled updates or instance replacements.
Recommendation:
Even when your company is small, have a policy of patching all systems, including desktops within 30 days for Critical and High Vulnerabilities. Sixty days for everything else.
If you can’t patch a system because it will break a production, there are legitimate wats to deal with that besides ignoring it. You can create a mitigating control or process. You can accept the risk and work on fixing the production issue. The critical factor for security is recognizing the requirement, creating mitigations, and documenting the situation. Documentation will help you pass any security compliance audits.
Recommendation:
The Tenable suite of products is useful in providing a real-time solution to may of these issues to include continuous monitoring and oversight.
Mistake 8:
Lack of endpoint security controls in the production environment.
Recommendation:
Pick a solution that can support your corporate systems and workstations in addition to your cloud-based OS VM/EC2.
Solutions Sophos, Crownstrike, and others are all good.
File Integrity Monitoring and Antivirus/Malware scanning are requirements for NIST Compliance and CIS Hardening. However, it does not have to be a traditional on-demand scanner. It can be a once a week scan. There are free products (ClamAV, AIDES) and others.
Mistake 9:
Not hardening production systems and corporate workstations.
Recommendation:
Workstations:
- Data at Rest FIPS-140–2 encryption
- Bios Passwords
- Centralized management and configuration
Production Systems:
- CIS Level 1 hardening and Central Management
- Scheduled updates, patches or replacement
It is 1000 times easier to develop on hardened platforms, then it is to harden production platforms in uses.
Little known fact:
It is tough to prosecute a hacker or person for unauthorized use of a system without a legally approved banner and Acceptable Use Policy.
Mistake 10:
Not understanding the connection between Cyber Security and Business Development and Business Risk.
A good cybersecurity program, even if your company is three people working in a garage, gives your company an advantage in RFPs. It can enhance your business grown and be a “Force Multiplier” for the business. Customers read about the hacks and lack of security all the time. Having a good program makes your product or application more desirable. It can also reduce your insurance costs and liability.
Case in Point: Twitter
Does Twitter have liability in the murder or wrongful death of this reporter? The employees of Twitter potentials were accessories before the fact in this murder. Perhaps Twitter may or may not have vetted its employees or had internal controls on their access to the data.
Mistake 11:
Depending on “Free” stuff for your business.
Thirty years ago, n Unix operating system could cost $1000 or more. Now, we have Linux virtually free. In past days software came with support and a back end of people making sure it was stable and secure. Today, the “community” finds problems and hacks. Patches and fixes happen when “community” reaches consensus. You have no legal recourse on anything you get for free. Paying for AWS does not protect you for an opensource software package.
There are many useful opensource products to help a startup company. There are also paid-for choices that can reduce development time and increase security. Free is free for the code, not for the time to learn, understand, and implement. (and in some cases remediate and re-architect.
Something to consider:
Look for opensource products that have the capability to moving up to a supported version. For instance, Terraform and Terraform Enterprise. JumpCloud free for ten users, and without reconfiguration the ability to grow.
Also, don’t let a vendor talking you into a free trial that turns into a paid product unless you understand the long-term cost. For instance, AWS free trial is more or less a single server for a year and associated services. If you start there and develop a production system, you will be there for a long time. Make sure your business model can support the growth of cost in the same manner that the business grows. In AWS, there is a typical pattern of EC2 -> Docker -> Kubernetes -> GCP evaluation due to cost and lack of understanding of how things scale and their associated fees.
Consider the most basic “Free Stuff of All,” the Internet. We get it for free from StarBucks, McDonald’s, WeWork, Airports, Major Cities, and more.
WeWork’s Lax Wi-Fi Security
Security issues with WeWork’s Wi-Fi network were first introduced in August 2019 in a Fast Company report, which noted that the company “used the same weak passwords and outdated Wi-Fi system throughout all its branches”. WeWork’s lack of password security has gotten to the point that it has regularly been featured on the list of the worst passwords that anyone can possibly use. The report described that WeWork’s Wi-Fi weak security is “laughably weak” and “downright dangerous.”
The “laughably weak” Wi-Fi at WeWork now has resulted in exposing the sensitive documents and data of it’s New York’s Financial District members.
Mistake 12:
Microservices and Data Comingling as it affects customers, cost, and sales.
Typically, developers are not well informed with issues of regulation, security, or costs. After something is in production, the business folks will tell them to reduce costs. They always come up with some microservice strategy with docker/Kubernetes. However, this always leads to data co-mingling of customer data (including logs). Some regulations regarding the Government, HIPPA, Financial systems frown on customers’ data co-mingling with other customers.
All systems consist of data and data that is protected by regulatory law. Regulations like PCI, PII, HIPPA, and more, requires two things:
- Data in-transit encryption
- Data at-rest encryption.
If you co-mingle your customer’s data, you may not be able to serve other customers.
If you use microservices and SSL offloading, then the data may pass through some systems unencrypted. This situation may require a considerable number of risk acceptance steps if it is accepted at all.
Mistake 13:
Treasure Maps and Booty
Where is your data?
How many copies are there?
If you have an eCommerce application, you may or may not have PCI information, depending on how you process payments. However, you most certainly have PII and PI data that requires protection under another standard like COPA or FERPA.
Making a copy of production data for developers to work with is risky. Especially if the data has a name, address, phone, number, security questions, logs, and purchases, hackers can use this for identity theft. Or perhaps someone could use it for stalking a famous person.
Recommendation:
Take the time to create a development set of data that is approved. It can be an automated pull of production that changes out PI/PII data for anonymizing.
Know where every copy is stored, how it is protected, and if you have backups.
Have a standard and a policy even if there are two of you,
Mistake 14:
Reconstruction
Disaster Recovery and Continuity of Operations.
Most startups don’t consider this until they are so big that figuring it out requires hiring a person for this.
In simple terms, know how to duplicate your production environment from scratch. If you created your AWS architecture with the console as it evolved, then you don’t know what it will take to duplicate.
A startup should be able to use a set of offline or in another region backup to regenerate a production environment in 24 hours.
Case in Point: World Trader Center 9/11/2001
Most financial companies had their backup data centers in the opposite tower with a fiber connection. They had their hot and warm sites destroyed at the same time. They had to revert to their cold sites in New Jersey and rollback the data to the last good backup.
Recommendation:
- Be able to create your root and production AWS Accounts with terraforming and no console. Including links to your SSO provider.
- Maintain code and data backups online and under control, even if that is an SSD in your safe.
- Practice spinning up a new account and recovering the data once a year.
- Github is excellent, but where is the physical location of the data? What if it is the same AWS data center that has a problem?
Mistake 15:
The acquisition of shiny objects.
Engineers, marketing people, programmers and office techs love chasing the next shiny new thing. It seems like every week, we can learn about a new technology, software, or media platform that promises to be the much better and easier thing to use than what we have. I call the instant reaction to this the “Shiny Object Syndrome.”
The more technologies, vendors, and complexity you create, the number of risks you add to your company increases.
There is an adage. If you own a hammer, then every problem is a nail. When you are hiring developers, they will want to shift the design the language or technology they used last, want to learn more about, or think will help their career.
If shifts in technology are unmanaged and focused on personalities, it can damage a company’s capabilities and growth.
Recommendation:
Pick your technology changes carefully. Make sure that any new technology does what you want without introducing a new problem. There are a plethora of unintended consequences that can occur. New technology for performance can lead to instability or increased costs.
Mistake 16:
Let your fingers do the walking: Yellow Pages
Ignoring DNS related issues
Most developers have a consumer-level understanding of how the Internet works and how data exfiltration can occur. Developers are good at what they do.
A few attacks and hacks related to DNS:
- BotNets
- DDOS
- MTM
- DNS Data Exfiltration
- RansomWare
Route53 is useful for what it does. It is not a DNS firewall.
One of the most common security issues is Phishing by all its names and variations. I have heard no end of junior security engineer lecture me on the education of end-users, tricking them, consequences, and so on. When I was in the military, we had to take a 3 hours online class every year about knowing when it’s a phishing email. I receive many hundred emails on multiple accounts. I correspond with people from around the world some that have English skills that good use a little polish. Generally speaking, no matter how much education or ability an end-user has or anyone who is acting like an end-user at the time of the email has, they will fail prey 7–20% of the time. (This includes security professionals). The result for the Enterprise is we have to train people on phishing for compliance, to lower our cybersecurity insurance, and to perform due diligence in our security framework. It also requires us to find another defense.
Phishing mostly works when someone clicks on a link. A click either downloads malware or runs malware as an attachment. Most of the email systems like O365 and others filter out the malware attachments. By using a DNS firewall, we can eliminate the clickable threat. Most DNS Firewall services have a real-time feed that updates to prevent this clicks.
Besides, botnets and some malware use DNS for a Command and Control C2 system. If they can’t reach their controller, they can’t get activated. A DNS firewall provides reporting for actions that attempt communication to a controller and prevents them at the same time.
Most home internet providers provide some level of DNS firewall. If we use (8.8.8.8) Google DNS on workstations then, we bypass all levels of filtering and firewalls. There are cases that require avoiding our standard DNS procedures for testing, but it should not be the rule.
Little Known Fact:
Companies like BitSight, track the click-through to bad sites and report on this (about you) to other companies. BitSight will accept IP markers for guest networks.
Your IP usage belongs to your company. If your guest network allows full access to the Internet, all actions are yours and tracked.
For guest wireless networks, always makes sure they are using a protected DNS firewall and use different external IP ranges than regular employees. If employees use it, have them use it with a username and a password; then, have it change external IPs based on authentications.
Mistake 17:
“to close the stable door after the horse has bolted.”
Lack of VPN usage and understanding regarding cloud security.
In the current “Startup View” of the world, everything is a cloud service. Infrastructure from AWS/Azure/GCP, HR/Payroll from UltiPro, Benefits from SWIFT, and this list goes on. The new paradigm of the inclusive Internet and Business centers in apartment buildings creates new challenges.
Where are hackers located? Sometimes it is from upper Moldovia, and sometimes it is from a compromised desktop in San Clara, CA, on the Xfinity network.
Use VPN access when not in your office if you own your network. If you use a place like WeWork, always use a VPN.
There are many providers like Permiter 81 that provide Zero trust access solutions. In a very general sense, you can have almost any Cloud Provider white list your Office or VPN IPs so that the whole rest of the world can’t access your SaaS services. Public based VPNs provide an additional level of protection. Unlike using the AWS VPN internal services, it connects and provisions based on your SSO provider.
Recommendation:
When setting up a VPN:
- Limit concurrent user sessions.
- VPNs are not for service accounts; they are for people.
- Site2Site VPN is for services.
- Check usage to ensure people are not connecting for extraordinary periods or moving extraordinary amounts of data.
- Retain user access and session logs according to your data retention policy, or at least 90 days.
By using a VPN provider, you can also limit the number of points of access to your corporate and cloud services, which reduces your attack surface.
Mistake 18:
Fight as you train, train as you fight
We use the manta, “Fight as you train, train as you fight.” We translate this to any industry, “don’t do anything in development or staging that you don’t want in production.”
This concept is general, but failing it very costly.
Case in point:
Don’t let developers work on non-hardened OS Images or Docker Images. If it is allowed, they will find some way to create code that does not work after security is applied. Security needs to evolve with the development needs, not created after. The best practice is development on standard and secured images.
Layer the application development like icing on a cake. Don’t try to slide a cake under the icing
Develop your business and technical process end to end with security in place. Don’t just stop when you “get it working.”
Jenkins systems that are unsecured are just as prevalent as AWS keys in Github.
Mistake 19:
Use your Gym Membership
Although this sounds funny, how many people have a gym membership that they pay for and never use. Even if they go, how many people know all of the services available to them under their membership plan.
This translates to, Use what you are paying for to the fullest and don’t get talked into “Best of Breed” solution sets.
You don’t buy a car in pieces, chassis from one vendor, engine from another transmission from a third, and computer systems from a fourth. Just because they all said, “Conforms to Open Standards.”
- Review your security tooling annually
- Fully utilize your tooling.
- Make sure it all works together.
- Reduce the number of “places” people have to look for information
- Create a common operating picture for your company
Do all of this while you are at the beginning. It only gets harder as things get more complicated.
Mistake 20:
Rogues, Thieves, and Dreamers
I can’t tell you the number of times a developer, financial person, security engineer, or some other team member tells me how their project can’t conform to the company guidelines. What they mean is they don’t know how to do it, or it’s too much work for them to do it, or perhaps some other variation.
There is a minimal set of security standards that must be applied to even be in this market place.
- Central User Management
- System Hardening / Layered Defenses
- Infrastructure Hardening / East-West Security
- Edge Hardening / North-South Security
- External Defenses
- Good Housekeeping Practices (user remove, data purges, etc.)
- DR/CooP capabilities
There is no credible case to step outside of this.
Every AWS account should be pre-hardened to a standard before you create a service.
Every OS/VM/EC2/Docker image needs hardening before its use, including how the base OS (or in ZERO os systems) Software is updated.
If the standard doesn’t work for the new project, use a process to update the rule. Don’t create a long list of edge cases with different standards.
Implementation of baseline controls is a must from AWS to VPNs, including Coffee Pots, Refrigerators, and animated dolls.
Mistake 21:
Isaac Asimov’s “Three Laws of Robotics”
- A robot may not injure a human being or, through inaction, allow a human being to come to harm.
- A robot must obey orders given it by human beings except where such orders would conflict with the First Law.
- A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
Translation: Don’t forget about IoT in the workplace.
In a modern workplace, tons of IT “stuff” exists. IoT equipment is easy to overlook. Sometimes it just walks in. Here are some crazy ones to look for and make sure they have at least a password on them. IoT is not limited to WiFi, BlueTooth, Zigbee, and other protocols are also used. If it can have an App, it’s connected.
- Security Systems, Cameras, Elevators
- Coffee Makers, Dishwashers, Refrigerators, Game Systems
- Copier, Fax, Printer Multifunction devices.
- Vendor provided equipment(postage machines)
- Loyalty Systems, Guest Checking Systems
- Conference Room Equipment and TVs.
Think about if someone got control of your TV and recorded every presentation. Perhaps used the Office printer as a scanner sniffing device and emailed copies of every document printed.
A lot of very inexpensive equipment as “very inexpensive” security.
Mistake 22:
The world is listening
There is no law against anyone sniffing wireless signals and gaining information from them.
WiFi is ubiquitous in the workplace. Cisco provides an excellent series of tools to secure wifi.
Basic Rules:
- No access without credentials
- Protect DNS
- Don’t allow old devices or Rooted Devices to connect.
- Log Connections and usage for at least 90 days.
- Track for rogue equipment if practical.
- SSID for the company should not be the company name.
- Guest SSID should also not be the company name or the word “Guest.”
- Don’t put encryption levels (WPA, for instance) in the SSID.
- Every security domain and location should have a different external address.
- All Wifi Equipment needs updating within 30 days or less. Don’t forget about it in a closet.
Wireless LANs (WLANs) bring incredible productivity and new efficiencies to organizations of all sizes. Advances in WLAN features and capabilities allow organizations to offer the benefits of wireless to their employees without sacrificing security. Properly deployed, WLANs can be as secure as wired networks. This paper discusses the five steps to creating a secure WLAN infrastructure. link
Mistake 23:
Liberté, égalité, fraternité
The IT department and corporate infrastructure is not subject to different rules, policies and leadership.
I see this one a lot in the DOT COM startup world. The product engineering side grows until they need to hire enough people to have a corporate team. Because the engineering team did not conform to standards, they set up a situation of us v them. When the company grows to an Enterprise level, the teams merge with varying levels of success.
When a company starts with baseline security from the beginning, it provides freedom to grow unrestricted by technical debt. All aspects of engineering and corporate are equally important. All security professionals belong to the same fraternity. If a burglar or nefarious individual make their way into the corporate side, they sidestep to the product engineering environment.
Without governance and baseline controls, applied from the beginning, the company acquires technical debt that is very expensive and hard to pay.
Mistake 24:
Yertle the Turtle and other stories.
The Shared Responsibility Model (AWS)
AWS responsibility “Security of the Cloud” — AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
Many professionals think that the OS instances in EC2 are secured or that AWS performs some magic related to security. They are not responsible for making sure your account, neither is Azure or GCP, is secure meets a standard or protected in any way. They are also not responsible if your EC2s crash or reboot.
Before using “Infrastructure as a Service” read the SLAs for each service that you use.
Amazon’s business is to provide a service for money and get you to spend as much money as you want with them.
It is easier to build your service or application on a solid foundation; then it is to fix the Millennium Tower. As an example, the building cost $350 million to build and now will take $100 million to fix, if it is fixable at all. A better initial foundation cost is a fraction of the repair bill.
IT systems are very similar. Build it secure, and it will scale as large as you want. These structures were technology for security.
Mistake 25:
A submarine with a screen door
AWS Accounts are not ready to go. They need to be secured.
AWS provides great services. They have great people and innovative technology. A new account is very far from secure. Much like this screen door.
I ran an initial scan on a new AWS account courteous of CloudSplot. They provide a free account for startups to check out their security posture. Their service offers a series of features that help find and fix security issues.
I will place the CSV scan results on Github along with Terraform projects that go with these articles.
In summary, the issues of infrastructure security only get harder to implement over time. Each of these issues is root in People, Process, and Technology and none of them can be solved by downloading a how-to guide 2 years after production work started. One of the key concepts in security work is due diligence. Even if you do everything right, your company still can experience a breach. But if you have done everything right along the way, you have a much better story to tell to your investors and customers.
My next article will feature wiring up a new AWS account with Terraform to resolve the security issues and create a method for deploying the same security to all sub-accounts.