Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Avoiding Limitations of Traditional Approaches to Security


Published on

Published in: Software
  • Be the first to comment

  • Be the first to like this

Avoiding Limitations of Traditional Approaches to Security

  1. 1. AVOIDINGLIMITATIONS OFTRADITIONAL APPROACHESTO SECURITY Best practice advice for cloud and container security. Sponsored by
  2. 2. 2 INTRODUCTION In securing cloud and hybrid environments, some organizations try to replicate the traditional security stack they use for their on-premises infrastructure. Although they typically face the same security requirements when locking down cloud assets, the tools they have available to them and how they implement those tools are different. To get a better understanding of the practical differences between the traditional security stack and building a layered security strategy for a cloud infrastructure, we asked our experts the following question: What limitations can you expect when stitching together multiple security solutions in a cloud infrastructure? Mighty Guides make you stronger. These authoritative and diverse guides provide a full view of a topic. They help you explore, compare, and contrast a variety of viewpoints so that you can determine what will work best for you. Reading a Mighty Guide is kind of like having your own team of experts. Each heartfelt and sincere piece of advice in this guide sits right next to the contributor’s name, biography, and links so that you can learn more about their work. This background information gives you the proper context for each expert’s independent perspective. Credible advice from top experts helps you make strong decisions. Strong decisions make you mighty. © 2019 Mighty Guides, Inc. I 62 Nassau Drive I Great Neck, NY 11021 I 516-360-2622 I
  3. 3. 3 FOREWORD Traditional Approaches to Security Have Severe Limitations We all know the attributes of the cloud; agile, dynamic, adaptable. Doesn’t it make sense to use security products that operate the way the cloud does? From a business standpoint, the answer is yes. From a security perspective, there simply is no other way. Many organizations have built elaborate network-based security systems based on endpoints and linear flow of data. In these infrastructures, the key was to build a hard outer shell and prevent unwanted and unwarranted entry. The cloud, however, can only be effective when data can be shared and integrated among users and resources. It’s ad hoc and agile, but it helps companies achieve business goals with efficiency. All those users and data, however, can’t be protected in an infrastructure that’s using outdated concepts for risk management and threat detection. Cloud security demands an end-to-end experience that delivers better context, greater intelligence, and more sophisticated threat detection in order for customers to make sense of the data and workloads they’re running in the cloud. In this book are excellent examples of adept practitioners who have adopted cloud strategies within their enterprise cloud security, and who operate with a framework of protection while still enabling fast, scalable growth. The individuals interviewed in this book live the challenge of security every day; we hope it’s enlightening and helpful. Lacework is a SaaS platform that automates threat defense, intrusion detection, and compliance for cloud workloads & containers. Lacework monitors all your critical assets in the cloud and automatically detects threats and anomalous activity so you can take action before your company is at risk. The result? Deeper security visibility and greater threat defense for your critical cloud workloads, containers, and IaaS accounts. Based in Mountain View, California, Lacework is a privately held company funded by Sutter Hill Ventures, Liberty Global Ventures, Spike Ventures, the Webb Investment Network (WIN), and AME Cloud Ventures. Find out more at www. Regards, Dan Hubbard Chief Product Officer
  4. 4. 4 © 2019 Lacework, Inc. Lacework and Polygraph are registered trademarks of Lacework. All  other marks mentioned herein may be trademarks of their respective companies. Lacework  reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Get actionable recommendations on how to improve your security and compliance posture for your AWS, Azure, GCP, and private cloud environments. FREE ASSESSMENT Streamline security for AWS, Azure,  and GCP.  Gain unmatched visibility,  ensure compliance, and enable  actionable threat intelligence.
  5. 5. 5 TABLE OF CONTENTS Kathrine Riley, Director of Information Security & Compliance Braintrace.......................................................... 07 Mauro Loda, Senior Security Architect McKesson.......................................................... 09 Paul Dackiewicz, Lead Security Consulting Engineer Advanced Network Management (ANM)..................................... 08 James P. Courtney, Certified Chief Information Security Officer Courtney Consultants, LLC......................... 12 Darrell Shack Cloud Engineer Cox Automotive Inc....................................... 11 Milinda Rambel Stone, Vice President & CISO Provation Medical.......................................... 06 Ross Young, Director Capital One........................................................ 13
  6. 6. 6 “YOU NEED TO DEFINE ACCEPTABLE LEVELS OF RISK OR TOLERANCE, AND TUNE YOUR TOOLS IN TERMS OF RISK.” One of the challenges and limitations of complex security stacks is making sure the tools you are using are actually delivering their expected value. We want to implement the latest tools, but if you have too many running at once, you can lose focus of their value. It’s not just about implementation. You need to think about the value you’re going to get out of those tools in the context of the security control you need within your architecture. Otherwise your resources can’t pay attention to everything, and you accomplish less even though you have more tools. A cloud environment operating at scale generates a huge amount of event activity. You need to prioritize risk so that you can focus attention on the right things. You need to define acceptable levels of risk tolerance, and tune your tools in terms of risk and your business priorities. Once all the security controls are defined in your environment, you can monitor them so that you are able to evaluate how you’re doing in vulnerability management, application security, and other important areas. Then you can see where the weaknesses are and discuss with your teams where you are operating at risk and how to model threats in the context of your environment. You just have to keep looking at it, talking about it, automating it, and measuring it. It’s a continuous process because the cloud environment is constantly changing. n Milinda Rambel Stone, Vice President & CISO, Provation Medical Milinda Rambel Stone is an executive security leader with extensive experience in building and leading security programs, specializing in information-security governance, incident investigation and response, cloud security, security awareness, and risk-management compliance. As a former software engineer, Stone has passion and experience in building cloud security and DevSecOps environments. She currently practices this at Provation, where she is the vice president and chief information security officer (CISO).
  7. 7. 7 “WHENMOVINGTOTHECLOUD,YOU CAN’TFORGETTHATANAPPLICA- TIONISSTILLASVULNERABLEASIT EVERWAS.” When orchestrating security in the cloud, you face the same challenges and have to address the same threats as in an on-premises environment. When moving to the cloud, you can’t forget that an application is still as vulnerable as ever, and people still want to get to your data. Yet how you orchestrate your security operations changes. The platform is now orchestrating some of that for you, but you still need to know what is most important, what are your showstoppers, the things you absolutely must see first, what are your ports and access points, so you know what you should be turning on. One key to success in this environment is managing orchestration in a way that tunes out noise. You need to architect all of that before you go to the cloud so you know what functions and services you are choosing, and how to configure them operationally. You still need to know what your firewalls and access points are telling you, but these services are now orchestrated in the platform itself, and the platform’s security center becomes your security operations center where you can monitor alerts, the status of images, patch status, threat activity, and all the things that are important to your operation. Your approach to securing this environment is only as good as your definition of what is critical, what requires timeliness, what alerts you need to have, who gets them, and how to respond. Like any tool, it’s only as good as how you tune if to fit your requirements. n Katherine Riley, Director of Information Security & Compliance, Braintrace Katherine (Kate) Riley is skilled in leading teams to define cloud architecture, and in development of controls. She has developed and implemented security frameworks such as ISO and NIST, and performed compliance reviews such as FFIEC, HIPAA, HITRUST, SOX, GDPR, and GLBA.
  8. 8. 8 “THE ONLY WAY TO PROCESS ALL THAT DATA IS THROUGH AUTOMATION, AND FOR THAT TO WORK, YOU NEED TO SELECT YOUR TOOLS CAREFULLY.” One of the biggest challenges is vendor interoperability, or lack thereof. For example, you may have a requirement that involves using a security tool that only supports a particular cloud provider’s storage solutions. However, let’s say the tool you use to parse logs does not work with the type of data storage that particular security tool uses. You may be forced either to parse the data manually, which limits your ability to operate securely at scale, or to invest in and configure new security tools. Operating at scale in the cloud can generate large volumes of security data. The only way to process all that data is through automation, and for that to work, you need to select your tools carefully. n Paul Dackiewicz, Lead Security Consulting Engineer, Advanced Network Management (ANM) Paul Dackiewicz has over 10 years of systems engineering and cybersecurity experience in the fields of healthcare, government, and value- added resellers (VARs). He is currently leading the security operations center (SOC) for a premier managed security services provider (MSSP).
  9. 9. 9 “MANY SECURITY SOLUTIONS FOCUS ON SPECIFIC PIECES OF THE SECURITY STRATEGY, AND THEY PERFORM THOSE TASKS VERY WELL. BUT WHEN YOU LOOK AT THE ENTIRE ECOSYSTEM, LACK OF INTEROPERATION CAN WEAKEN A SECURITY PROFILE.” When architecting a security strategy to protect a cloud infrastructure, it’s important that different security tools play well together. Many security solutions focus on specific pieces of the security strategy, and they perform those tasks very well. But when you look at the entire ecosystem, lack of interoperation can weaken a security profile. Sometimes it is even difficult to have products from the same vendor working together. Mauro Loda, Senior Security Architect, McKesson Mauro Loda is a passionate, data- driven cybersecurity professional who helped define and drive the “Cloud First” strategy and culture within a Fortune 100 multinational enterprise. He is a strong believer in offensive security and simple- but-effective architecture-defense topology. Emotional intelligence, pragmatism and reliability are his guiding principles. He has achieved numerous industry certifications and actively participates in forums, technology councils, and committees.
  10. 10. 10 It’s often necessary to work closely with the vendor, and in some cases this involves writing custom functions that enable the tools to speak to each other. This is not always easy. Vendors need to be willing to help their customers and write code if necessary. They can often to cooperate with you on temporary solutions, but in most cases you can’t wait six to nine months to add capabilities to an operating platform. When operating in the cloud, solutions are deployed through the continuous integration, continuous delivery (CICD) pipeline in time frames measured in seconds and minutes. When working in a super-dynamic cloud environment, most vendors need to be more agile in the way they adjust to customer needs. n
  11. 11. 11 “IT’S IMPORTANT THAT EVERY SECURITY TOOL YOU IMPLEMENT GIVES YOU AN ADDITIONAL ADVANTAGE THAT YOU DO NOT ALREADY HAVE.” One challenge when securing cloud environments is avoiding the adoption of security tools with redundant services. You don’t want to be in a situation where you are monitoring more tool outputs than necessary, so it’s important that every security tool you implement gives you an additional advantage that you do not already have. For example, you may have a tool that monitors resources and configurations that are being used in your cloud environment. To gain further visibility, you don’t need another tool that does the same thing. You might want to implement a tool that has machine-learning capabilities and can look at usage patterns and trends, and then make predictions based on what it sees. This provides deeper insight than you gained from the tool that simply reported on resource usage. n Darrell Shack , Cloud Engineer, Cox Automotive Inc. Darrell Shack is a seasoned system engineer focused on building resilient and high--availability solutions. He has experience in developing solutions in the public cloud Amazon Web Services, helping teams manage their cost, and overall application performance in the cloud.
  12. 12. 12 “NOTHINGISGOINGTOBE100% SECURE.GIVENENOUGHTIMEAND DETERMINATION,ANADVERSARY WILLFINDTHEIRWAYIN.” Integration between the security tools in your layered security strategy is the key, and how companies address this integration is itself a limiting factor, because how you solve this problem can introduce vulnerabilities. For example, one company might decide to solve the integration problem by purchasing all of its security tools from one vendor. In this way they can be sure that all the tools work together. But this approach creates a flat security plan. An attacker really only has to attack one product successfully to breach the defenses. Alternatively, a company might choose the best security solutions from different vendors for their layered security strategy. This approach makes a more complex security stack that can be more difficult to attack, but if the solutions do not work well together, there can be gaps. Nothing is going to be 100% secure. Given enough time and determination, an adversary will find their way in. That is why a layered approach with a central monitoring point, such as a security information manager, is necessary. Artificial intelligence and behavior analytics tools are an important part of the layered approach, but if they are not properly configured, they may miss potentially threatening activity. They must be continuously trained for the continuously changing cloud environment, where you can have 100 servers running one minute, and a few minutes later business demands spin up 50 new ones. n James P. Courtney, Certified Chief Information Security Officer, Courtney Consultants, LLC James Courtney is a recognized cybersecurity professional who has spoken at multiple conferences, including the CyberMaryland Conference. He is a Certified Chief Information Security Officer (one of 1,172 in the world), serving as the IT network and operations security manager for a private SIP consulting firm in McLean, Virginia.
  13. 13. 13 “ONE SECURITY PERSON FOR EVERY 100 DEVELOPERS…WILL NOT BE ABLE TO DO HIS OR HER JOB REGARDLESS OF SKILL LEVEL AND TECHNICAL EXPERTISE.” The greatest limitation to integrating your security solutions and strategy in the cloud effectively is failing to have agreed-on standards in your DevSecOps environment. For example, let’s say you have 1,000 developers working on your systems, and there are at least 1,000 different ways you can implement an application service. Every one of those developers has their ideas about the best way to meet a requirement, so every developer has a use case for building snowflake instances, which are the enemies of automation. Now let’s also say that like a typical organization with 1,000 developers, you have 10 security people making sure the operational environment stays secure. That’s one security person for every 100 developers out there doing their own unique implementations. That one security person will not be able to do his or her job regardless of skill level and technical expertise. To address this, you need to develop basic frameworks that become starting points for every service implementation. Developers must be limited to just a few acceptable versions of containers or virtual instances, and these can be enforced through automation of the DevOps pipeline. With this kind of discipline, one security person can easily monitor the work of 100 developers. n Ross Young, Director, Capital One Ross Young is a veteran technologist, innovation expert, and transformational leader, having learned DevSecOps, IT infrastructure, and cybersecurity from a young age from both ninjas and pirates. Young currently teaches master-level classes in cybersecurity at Johns Hopkins University and is a director of information security at Capital One.
  14. 14. 14 KEY POINTS Tools used to secure a cloud environment are only as good as your definition of what is critical and how to respond. Like any tools, they are only as good as how you tune them to fit your requirements. Integration between the security tools in your layered security strategy is the key, and how companies address this integration is itself a limiting factor, because how you solve this problem can introduce vulnerabilities. When operating at scale in the cloud, if you do not have standards in your DevSecOps practice, you will end up with many snowflake instances that make automation difficult and effective security oversight almost impossible.
  15. 15. 15 © 2019 Lacework, Inc. Lacework and Polygraph are registered trademarks of Lacework. All  other marks mentioned herein may be trademarks of their respective companies. Lacework  reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Interested in more? Try Lacework for free and validate the security  of your cloud: TRY FOR FREE Streamline security for AWS, Azure,  and GCP.  Gain unmatched visibility,  ensure compliance, and enable  actionable threat intelligence.