Trend Micro is excited to launch new Trend Micro Cloud One – Conformity capabilities that will strengthen protection for Azure resources.
As with any launch, there is a lot of new information, so we decided to sit down with one of the founders of Conformity, Mike Rahmati. Mike is a technologist at heart, with a proven track record of success in the development of software systems that are resilient to failure and grow and scale dynamically through cloud, open-source, agile, and lean disciplines. In the interview, we picked Mike’s brain on how these new capabilities can help customers prevent or easily remediate misconfigurations on Azure. Let’s dive in.
What are the common business problems that customers encounter when building on or moving their applications to Azure or Amazon Web Services (AWS)?
The common problem is there are a lot of tools and cloud services out there. Organizations are looking for tool consolidation and visibility into their cloud environment. Shadow IT and business units spinning up their own cloud accounts is a real challenge for IT organizations to keep on top of. Compliance, security, and governance controls are not necessarily top of mind for business units that are innovating at incredible speeds. That is why it is so powerful to have a tool that can provide visibility into your cloud environment and show where you are potentially vulnerable from a security and compliance perspective.
Common misconfigurations on AWS are an open Amazon Elastic Compute Cloud (EC2) or a misconfigured IAM policy. What is the equivalent for Microsoft?
The common misconfigurations are actually quite similar to what we’ve seen with AWS. During the product preview phase, we’ve seen customers with many of the same kinds of misconfiguration issues as we’ve seen with AWS. For example, Microsoft Azure Blobs Storage is the equivalent to Amazon S3 – that is a common source of misconfigurations. We have observed misconfiguration in two main areas: Firewall and Web Application Firewall (WAF),which is equivalent to AWS WAF. The Firewall is similar to networking configuration in AWS, which provides inbound protection for non-HTTP protocols and network related protection for all ports and protocols. It is important to note that this is based on the 100 best practices and 15 services we currently support for Azure and growing, whereas, for AWS, we have over 600 best practices in total, with over 70 controls with auto-remediation.
Can you tell me about the CIS Microsoft Azure Foundation Security Benchmark?
We are thrilled to support the CIS Microsoft Azure Foundation Security Benchmark. The CIS Microsoft Azure Foundations Benchmark includes automated checks and remediation recommendations for the following: Identity and Access Management, Security Center, Storage Accounts, Database Services, Logging and Monitoring, Networking, Virtual Machines, and App Service. There are over 100 best practices in this framework and we have rules built to check for all of those best practices to ensure cloud builders are avoiding risk in their Azure environments.
Can you tell me a little bit about the Microsoft Shared Responsibility Model?
In terms of shared responsibility model, it’s is very similar to AWS. The security OF the cloud is a Microsoft responsibility, but the security IN the cloud is the customers responsibility. Microsoft’s ecosystem is growing rapidly, and there are a lot of services that you need to know in order to configure them properly. With Conformity, customers only need to know how to properly configure the core services, according to best practices, and then we can help you take it to the next level.
Can you give an example of how the shared responsibility model is used?
Yes. Imagine you have a Microsoft Azure Blob Storage that includes sensitive data. Then, by accident, someone makes it public. The customer might not be able to afford an hour, two hours, or even days to close that security gap.
In just a few minutes, Conformity will alert you to your risk status, provide remediation recommendations, and for our AWS checks give you the ability to set up auto-remediation. Auto-remediation can be very helpful, as it can close the gap in near-real time for customers.
What are next steps for our readers?
I’d say that whether your cloud exploration is just taking shape, you’re midway through a migration, or you’re already running complex workloads in the cloud, we can help. You can gain full visibility of your infrastructure with continuous cloud security and compliance posture management. We can do the heavy lifting so you can focus on innovating and growing. Also, you can ask anyone from our team to set you up with a complimentary cloud health check. Our cloud engineers are happy to provide an AWS and/or Azure assessment to see if you are building a secure, compliant, and reliable cloud infrastructure. You can find out your risk level in just 10-minutes.
Get started today with a 60-day free trial >
Check out our knowledge base of Azure best practice rules>
Do you see value in building a security culture that is shifted left?
Yes, we have done this for our customers using AWS and it has been very successful. The more we talk about shifting security left the better, and I think that’s where we help customers build a security culture. Every cloud customer is struggling with implementing earlier on in the development cycle and they need tools. Conformity is a tool for customers which is DevOps or DevSecOps friendly and helps them build a security culture that is shifted left.
We help customers shift security left by integrating the Conformity API into their CI/CD pipeline. The product also has preventative controls, which our API and template scanners provide. The idea is we help customers shift security left to identify those misconfigurations early on, even before they’re actually deployed into their environments.
We also help them scan their infrastructure-as-code templates before being deployed into the cloud. Customers need a tool to bake into their CI/CD pipeline. Shifting left doesn’t simply mean having a reporting tool, but rather a tool that allows them to shift security left. That’s where our product, Conformity, can help.
The post Knowing your shared security responsibility in Microsoft Azure and avoiding misconfigurations appeared first on .
Dan Burke is the director of strategy, risk, and compliance for AppDynamics, a company acquired by Cisco in 2017. Burke and his team are a vital part of the Cisco acquisition process in helping acquired companies adhere to a higher level of cybersecurity. This blog is the fourth in a series focused on M&A cybersecurity, following Shiva Persaud’s post on When It Comes to M&A, Security Is a Journey.
Part of the secret to Cisco’s success is its ability to acquire companies that strengthen its technology portfolio and securely integrate them into the larger organization. From the outside, that process might appear seamless—consider Webex or Duo Security, for instance—but a fruitful acquisition takes tremendous work by multiple cross-functional teams, mainly to ensure the acquired company’s solutions and products meet Cisco’s rigorous security requirements.
“My team is responsible for aligning new acquisitions to Cisco controls to maintain our compliance with SOC2 and FedRAMP, as well as other required certifications,” says Burke.
When Cisco acquires a new company, it conducts an assessment and produces a security readiness plan (SRP) document. The SRP details the identified weaknesses and risks within that company and what they need to fix to meet Cisco standards.
“In the past, my team wouldn’t find out about an acquisition until they received a completed SRP. The downside of this approach was that the assessments and negotiations had been done without input from our group of experts, and target dates for resolution had already been decided on,” shares Burke.
“We needed to be involved in the process before the SRP was created to understand all risks and compliance issues in advance. Now we have a partnership with the Cisco Security and Trust M&A team and know about an acquisition months before we can start working to address risks and other issues—before the SRP is completed and the due dates have been assigned,” Burke adds.
“Another issue resolved in this process change is that Cisco can gain earlier access to the people in the acquired company who know the security risks of their solutions. During acquisitions, people will often leave the company, taking with them their institutional knowledge, resulting in Cisco having to start from scratch to identify and assess the risks and determine how best to resolve them as quickly as possible,” says Burke. “It could be vulnerabilities in physical infrastructure or software code or both. It could be that the company isn’t scanning often enough, or they don’t have SOC 2 or FedRAMP certification yet—or they’re not using Cisco’s tools.”
“Third-party vendors and suppliers can also present an issue,” he adds. “One of the biggest risk areas of any company is outside vendors who have access to a company’s data. It’s vital to identify who these vendors are and understand the level of access they have to data and applications. The earlier we know all these things, the more time we must devise solutions to solve them.”
“Now that I’m in the process earlier, I can build a relationship with the people who have the security knowledge—before they leave. If I can understand their mindset and how all these issues came about, I can help them assimilate more easily into the bigger Cisco family,” says Burke.
The additional benefits of bringing teams in earlier are reduced risk and compliance requirements can be met earlier. It also provides a smoother transition for the company being acquired and ensures they meet the security requirements that customers expect when using their technology solutions.
“Without that early involvement, we might treat a low-risk issue as high risk, or vice versa. The misclassification of risk is extremely dangerous. If you’re treating something as high risk, that’s low risk, and you’re wasting people’s time and money. But if something’s high risk and you’re treating it as low risk, then you’re in danger of harming your company,” Burke shares.
“The key is to involve their risk, compliance, and security professionals from the beginning. I think other companies keep the M&A process so closely guarded, to their detriment. I understand the need for privacy and to make sure deals are confidential but bringing us in earlier was an advantage for the M&A team and us,” Burke adds.
When asked what he thinks makes Cisco successful in M&A, Burke says, “Cisco does an excellent job of assimilating everyone into the larger organization. I have worked at other companies where they kept their acquisitions separate, which means you have people operating separately with different controls for different companies. That’s not only a financial burden but also a compliance headache.”
“That’s why Cisco tries to drive all its acquisitions through our main programs and controls. It makes life easier for everyone in terms of compliance. With Cisco, you have that security confidence knowing that all these companies are brought up to their already very high standards, and you can rely on the fact that they don’t treat them separately. And when an acquisition has vulnerabilities, we identify them, set out a remediation path, and manage the process until those risks are resolved,” Burke concludes.
Managing Cybersecurity Risk in M&A
Demonstrating Trust and Transparency in Mergers and Acquisitions
When It Comes to M&A, Security Is a Journey
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels