Security Engineering is not Security Analyst or Incident Responder or Pentester or...
In November 2020, Lu Goon and I gave a joint presentation at BSides Delaware 2020 entitled “Security Engineers #NOT SYS ADMIN | #NOT PENTESTER | #NOT ANALYST | #NOT RESPONDER”. Lu and I had talked about doing this for a long time and I’m glad we finally made it happen. This talk came about during talks we were having about the tasks we have done in the past and are doing now and the skills needed to do those jobs. It occurred to us that we’ve seen talks about being a security analyst, an incident responder, a pen tester, and even a CISO, but we’ve never seen a talk on being a security engineer. Now, there are thousands of talks out there, so it is entirely possible we missed any. But we thought that even if there were previous presentations, the topic was scarce enough that our treatment of it might fill a needed niche.
Here is a link to the video and the slides are below
In November 2020, Lu Goon and I gave a joint presentation at BSides Delaware 2020 entitled “Security Engineers #NOT SYS ADMIN | #NOT PENTESTER | #NOT ANALYST | #NOT RESPONDER”. Lu and I had talked about doing this for a long time and I’m glad we finally made it happen. This talk came about during talks we were having about the tasks we have done in the past and are doing now and the skills needed to do those jobs. It occurred to us that we’ve seen talks about being a security analyst, an incident responder, a pen tester, and even a CISO, but we’ve never seen a talk on being a security engineer. Now, there are thousands of talks out there, so it is entirely possible we missed any. But we thought that even if there were previous presentations, the topic was scarce enough that our treatment of it might fill a needed niche.
Here is a link to the video and the slides are below
| bsides-delaware-security_engineering_2021.pdf |
Logging Best Practices
Last year I started working at GuidePoint Security, a company I've known for several years. Shortly after the transition, I was asked to present a webcast and write a white paper discussing best practices for logging. Now, while there are a number of opinions and suggestions, I tried to boil them down to actionable tasks organizations can accomplish.
Below are the links to the webinar and the whitepaper.
WARNING: It's a marketing thing, so you will have to register to watch and/or download.
Webinar Whitepaper
Last year I started working at GuidePoint Security, a company I've known for several years. Shortly after the transition, I was asked to present a webcast and write a white paper discussing best practices for logging. Now, while there are a number of opinions and suggestions, I tried to boil them down to actionable tasks organizations can accomplish.
Below are the links to the webinar and the whitepaper.
WARNING: It's a marketing thing, so you will have to register to watch and/or download.
Webinar Whitepaper
Help Someone Slide Down the Rabbit Hole. Getting New People to Infosec Con
Black Hat 2020
Last year I was fortunate enough to get a chance to speak at Black Hat. This opportunity came via an invite through Blacks In Cybersecurity, an organization I have worked with a few times since its founding several years ago. The talk, which ran under their community sessions, was about getting people to attend information security conferences (infosec cons). I found that when I invited my co-workers, many were reluctant to attend for various reasons. This talk was to share ways I have used to convince them to attend and help them feel comfortable while doing so.
I don't know when or if the talks will ever be released to the general public, but here is a link to the summary.
Black Hat 2020
Last year I was fortunate enough to get a chance to speak at Black Hat. This opportunity came via an invite through Blacks In Cybersecurity, an organization I have worked with a few times since its founding several years ago. The talk, which ran under their community sessions, was about getting people to attend information security conferences (infosec cons). I found that when I invited my co-workers, many were reluctant to attend for various reasons. This talk was to share ways I have used to convince them to attend and help them feel comfortable while doing so.
I don't know when or if the talks will ever be released to the general public, but here is a link to the summary.
Will that be one log or two? Logging before, during, and after an attack. - SANS Webcast Feb 2019
This was a fun webcast I got to do for SANS a couple of years ago. I had been thinking about the amount of logs we want to collect, but can't because of the volume of data. Also, there is the thought that some logs don't provide a very high signal to noise ratio and so often get disabled. But when under attack, you want to collect as much telemetry as possible. This talk was to discuss the logs that are usually disabled, but could be enabled to provide value during an ongoing incident.
Abstract: We all know logging is critical for monitoring activity on enterprise networks to detect malicious activity, especially on endpoints. Client side attacks are where adversaries are focused using a variety of methods including spear phishing and watering holes. Often most of the evidence of such an attack is at the user endpoint, that is in the host logs. Collection of logs from user endpoints is challenging already due to the volume and, if not carefully planed, can easily overwhelm the SIEM of any organization. But if an attack is occurring, these logs are invaluable in being able to detect (and thus alert on) the attack, for responding to the attack, performing forensic analysis to discover how and when the attack occurred, and after remediation has completed, monitoring for re-infections. While there are many guides (i.e. Microsoft, NSA, Palantir) for setting up a solid baseline logging configuration, there are few that discuss additional logs and/or items to monitor when machines are under attack, or at least under suspicion. Should all logs be enabled and collected or just a larger subset? If a subset, what is of most interest and value?
In this webcast Craig will present pros and cons of each option and discuss some of the current standards for configuring logging on workstations, explain what types of attacks leave no, or minimal traces with regards to those configurations, and suggest additional logs to enable or collect when a host is suspected of being compromised.
SANS Webcast
Slides
This was a fun webcast I got to do for SANS a couple of years ago. I had been thinking about the amount of logs we want to collect, but can't because of the volume of data. Also, there is the thought that some logs don't provide a very high signal to noise ratio and so often get disabled. But when under attack, you want to collect as much telemetry as possible. This talk was to discuss the logs that are usually disabled, but could be enabled to provide value during an ongoing incident.
Abstract: We all know logging is critical for monitoring activity on enterprise networks to detect malicious activity, especially on endpoints. Client side attacks are where adversaries are focused using a variety of methods including spear phishing and watering holes. Often most of the evidence of such an attack is at the user endpoint, that is in the host logs. Collection of logs from user endpoints is challenging already due to the volume and, if not carefully planed, can easily overwhelm the SIEM of any organization. But if an attack is occurring, these logs are invaluable in being able to detect (and thus alert on) the attack, for responding to the attack, performing forensic analysis to discover how and when the attack occurred, and after remediation has completed, monitoring for re-infections. While there are many guides (i.e. Microsoft, NSA, Palantir) for setting up a solid baseline logging configuration, there are few that discuss additional logs and/or items to monitor when machines are under attack, or at least under suspicion. Should all logs be enabled and collected or just a larger subset? If a subset, what is of most interest and value?
In this webcast Craig will present pros and cons of each option and discuss some of the current standards for configuring logging on workstations, explain what types of attacks leave no, or minimal traces with regards to those configurations, and suggest additional logs to enable or collect when a host is suspected of being compromised.
SANS Webcast
Slides
| logging_under_attack_sans_webcast.pptx |
Apples and Oranges?: A CompariSIEM - SOC Summit 2018
In 2018, I was fortunate to be on a panel with two great guys in the security space, Dave Herrald from Splunk (@daveherrald) and Justin Henderson from HA Solutions and a SANS Instructor and SANS course author (@securitymapper) which was moderated by Chris Crowley SANS Instructor (@ccrowmontance). While the abstract for the panel is below, the two main takeaways we wanted to get across were "Know your environment" and "Know your craft".
Link to video
Abstract: SIEMs have been a central tool of SOCs for at least a decade. There are currently a significant number of vendors in this space, each of whom offer different strengths that appeal to different organizations. While there are many measures that can be used to compare each vendor (i.e. Gartner magic quadrant, Proof of Concepts, or personal experiences), we want to focus on what they all do: help SOCs monitor and find “bad.” This will show that even if your SIEM doesn’t look like someone else’s SIEM, you can monitor and detect the bad guys just as well as anyone else.
To demonstrate this fact, we will take several SMEs, knowledgeable on different SIEM vendors, and give them two use cases each. They will demonstrate how each SIEM can be configured to monitor for and alert on that specific activity in an enterprise. This will include information about the level of effort needed, the data sources required, and a list of steps that you can use for implementation in your environment. The goal of this is not to bash competitors, but to encourage SOCs not to view their tool as a handicap, but to be inspired to find creative solutions.
In 2018, I was fortunate to be on a panel with two great guys in the security space, Dave Herrald from Splunk (@daveherrald) and Justin Henderson from HA Solutions and a SANS Instructor and SANS course author (@securitymapper) which was moderated by Chris Crowley SANS Instructor (@ccrowmontance). While the abstract for the panel is below, the two main takeaways we wanted to get across were "Know your environment" and "Know your craft".
Link to video
Abstract: SIEMs have been a central tool of SOCs for at least a decade. There are currently a significant number of vendors in this space, each of whom offer different strengths that appeal to different organizations. While there are many measures that can be used to compare each vendor (i.e. Gartner magic quadrant, Proof of Concepts, or personal experiences), we want to focus on what they all do: help SOCs monitor and find “bad.” This will show that even if your SIEM doesn’t look like someone else’s SIEM, you can monitor and detect the bad guys just as well as anyone else.
To demonstrate this fact, we will take several SMEs, knowledgeable on different SIEM vendors, and give them two use cases each. They will demonstrate how each SIEM can be configured to monitor for and alert on that specific activity in an enterprise. This will include information about the level of effort needed, the data sources required, and a list of steps that you can use for implementation in your environment. The goal of this is not to bash competitors, but to encourage SOCs not to view their tool as a handicap, but to be inspired to find creative solutions.
SIEMple Simon met a WMIman - SOC Summit 2017, Updated for SIEM Summit 2017
Abstract: While a SIEM is primarily designed to gather logs and events from network devices such as servers, routers, firewalls, IDS and Anti-Virus, the truth is a SIEM will accept and process just about any type of data you can throw at it. Therefore, you can greatly enhance the data you are collecting live on the network by comparing it to static (or semi-static) data you can gather directly from the enterprise via powershell scripts or WMI commands.
The data you manually gather (or schedule on a periodic basis) is used as a baseline or a reference to make sure the live data remains within a certain boundary. My talk will provide several examples of the scripts used, the data captured and how the comparison to live traffic enables SOC personnel to have better situational awareness of the security posture of their network by detecting possible suspicious behavior.
It is my hope that this talk will open your mind to other types of information you can ingest into your SIEM that will enable you have a better view of activity on your network and in your enterprise.
UPDATE: Here is the video from the SIEM Summit
These are the updated slides (with videos) and the scripts that go along with the slides:
Powerpoint Slides
Download File
Abstract: While a SIEM is primarily designed to gather logs and events from network devices such as servers, routers, firewalls, IDS and Anti-Virus, the truth is a SIEM will accept and process just about any type of data you can throw at it. Therefore, you can greatly enhance the data you are collecting live on the network by comparing it to static (or semi-static) data you can gather directly from the enterprise via powershell scripts or WMI commands.
The data you manually gather (or schedule on a periodic basis) is used as a baseline or a reference to make sure the live data remains within a certain boundary. My talk will provide several examples of the scripts used, the data captured and how the comparison to live traffic enables SOC personnel to have better situational awareness of the security posture of their network by detecting possible suspicious behavior.
It is my hope that this talk will open your mind to other types of information you can ingest into your SIEM that will enable you have a better view of activity on your network and in your enterprise.
UPDATE: Here is the video from the SIEM Summit
These are the updated slides (with videos) and the scripts that go along with the slides:
Powerpoint Slides
Download File
| scripts-v2.txt |
Operations vs Security: Bridging the Gap - SOC Summit 2016, DerbyCon 2016
Abstract: I've worked in, and managed several security groups. One of the biggest lessons I have learned is that Security and Operations have fundamentally different, but not necessarily opposing missions.
Optimal performance from both groups are needed to ensure the enterprise network satisfies customers, empowers users and facilitates development. However, often the relationship between these groups is tense and sometimes even downright hostile.
In this talk, I will go over three fundamental issues and three technical issues that can cause this conflict. I will talk about suggestions for resolving each of them. I also give some additional tips to enhance the relationship between the groups.
Link to video
Abstract: I've worked in, and managed several security groups. One of the biggest lessons I have learned is that Security and Operations have fundamentally different, but not necessarily opposing missions.
Optimal performance from both groups are needed to ensure the enterprise network satisfies customers, empowers users and facilitates development. However, often the relationship between these groups is tense and sometimes even downright hostile.
In this talk, I will go over three fundamental issues and three technical issues that can cause this conflict. I will talk about suggestions for resolving each of them. I also give some additional tips to enhance the relationship between the groups.
Link to video
| PowerPoint Slides |
| Speaker Notes |
10 Quick Win, Industry Agnostic SIEM Dashboards -
BSidesCharm2015, the SANS SOC Summit 2015, webcast prior to the SANS SOC Summit 2016
Abstract: Dashboards are a critical capability of a Security Information Event Monitor (SIEM) as they are able to display the near real time status of the health, operational availability, security posture and compliance level of networks of all sizes. While there are numerous papers, blog posts and examples of dashboards that provide deep insights, specific security alerts or complicated compliance metrics for your network, I wanted to create a list of dashboards that provided a solid starting point for Security Operation Centers to use when they installed their first SIEM. These are suggested quick-win, industry-agnostic dashboards which were chosen because of their ease of implementation and simple graphical presentation that provide SOC personnel an initial view into the security posture of a network.
Link to video
BSidesCharm2015, the SANS SOC Summit 2015, webcast prior to the SANS SOC Summit 2016
Abstract: Dashboards are a critical capability of a Security Information Event Monitor (SIEM) as they are able to display the near real time status of the health, operational availability, security posture and compliance level of networks of all sizes. While there are numerous papers, blog posts and examples of dashboards that provide deep insights, specific security alerts or complicated compliance metrics for your network, I wanted to create a list of dashboards that provided a solid starting point for Security Operation Centers to use when they installed their first SIEM. These are suggested quick-win, industry-agnostic dashboards which were chosen because of their ease of implementation and simple graphical presentation that provide SOC personnel an initial view into the security posture of a network.
Link to video
| PowerPoint Slides |