A big difference in the way on-premises infrastructures and cloud infrastructures are implemented centers on the way that user permissions are assigned. As you move towards software-defined everything, where data and systems are far more connected (generally a good thing), you need to pay special attention to the roles and permissions you grant to ensure that users are only given as much access as they absolutely need. No more, no less. Read more “Considerations For Creating Secure User Groups on AWS Using IAM”
Compliance is a complex, ongoing process. Between deciphering requirements into relatable terms, allocating a budget, and assembling a team for your compliance audit — all while trying to stay focused on running your business — there’s a lot to think about and do. And after all of this, there is still more that needs to be managed.
From regular maintenance of the processes, controls, and technology you implemented, to questions from customers about your level of compliance, you’ll quickly realize that compliance is a continuous process that needs to be managed, not a one-and-done activity.
Having said that, what are you doing, or going to do, to make your compliance plan accessible so team members — from Security to IT to Sales — can quickly verify a control or process?
We write about compliance (and talk to customers about it) pretty regularly, and if you’ve been following our blog over the last two months, then you know we also just did a full series on the topic. In addition, we released the The Threat Stack Compliance Playbook that’s full of practical information you can use to help your company achieve compliance without losing your sanity.
When companies prepare to meet compliance, whether it’s PCI DSS, HIPAA, or SOC 2, one thing that can be estimated inaccurately is the stakeholders who need to be involved — who they are, what departments they come from within your organization, what their roles are, what knowledge and skill sets they require, how long they’ll be needed, etc. This post is intended as a practical guide to help you develop a thorough and realistic resource plan for your next compliance audit.
Have you heard one about the bear and the two hikers?
A bear jumps out of the bush and starts chasing two hikers. They both start running for their lives, but then one of them stops to put on his running shoes.
The first hiker says, “What are you doing? You can’t outrun a bear!”
The second hiker replies, “I don’t have to outrun the bear; I only have to outrun you!”
Compliance works in a similar way. You don’t need to be the most compliant company; you just need to meet the requirements well enough to satisfy regulators, auditors, customers, and stakeholders. And, ideally, you want to be more compliant than your competitors. That’s how you outrun the bear (err… win the customer.)
When’s the last time someone made an unauthorized change to your system files?
To answer this and other important security questions, as well as to meet many compliance requirements, you first need to have file integrity monitoring. In case you aren’t familiar with the term, file integrity monitoring (sometimes abbreviated to FIM) is the method for knowing exactly when and how your files are being changed at any moment in time. This includes critical system files, configuration files, and content files.
Companies can easily underestimate the investment required to meet compliance. Thinking compliance is a one-and-done activity that you can skate by with minimal spend only sets you up for unpleasant surprises later on. Compliance can be a long, drawn-out process, involving HR, finance, security, leadership, and others. So it’s important to look at all the costs up front in order to set aside a realistic budget.
A good way to approach compliance is to treat it like a new product launch. You’ll need a dedicated project team, new technology, a reasonable budget, and more to get it off the ground.
The Threat Stack Compliance Playbook for Cloud Infrastructure is now available!
The Compliance Playbook is intended for readers who want to understand what’s involved in becoming compliant in a cloud environment — without getting caught up in the details and complexity that the compliance process is well known for.
Monitoring is the most reliable method of identifying and tracking users who are accessing data on company systems. Whether you’re on the lookout for an unauthorized employee viewing confidential patient data, or a malicious outsider trying to steal cardholder data, monitoring is indispensable to a strong security posture.
As well, monitoring is a requirement for just about every major compliance framework and regulation, from PCI DSS to HIPAA and beyond. For the sake of this post, we’ll be focusing on security monitoring requirements for PCI DSS and HIPAA, two of the most widely applicable regulations today.
Amazon Web Services (AWS) has pioneered the Shared Responsibility Model in the cloud. Basically, this model outlines how cloud service providers and consumers of these cloud-based services should share responsibilities when it comes to ensuring security in the cloud. AWS and other cloud service providers (CSPs) are responsible for ensuring that cloud infrastructure is secure. Meanwhile, companies (those using the cloud services) are responsible for their data, networks, applications, and operating systems — anything they own that lives in the cloud.