Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Tuesday, September 15, 2020
How we use Agile Scrum for SIEM Detection Engineering and Threat Hunting
Thought I’d share a thread on how we use a form of #Agile Scrum to keep our #SIEM detection engineering and threat hunting organized. #blueteam
https://en.wikipedia.org/wiki/Scrum_(software_development)
We are responsible for tracking threat intel at our org and use it to build SIEM detections and threat hunt the environment.
To track and organize our work and ensure progress we have adopted a form of Agile Scrum.
We have stakeholders such as the SOC and CISO who have a stake in the success of the SIEM detections and threat hunting results.
We have a scrum master, a member of our team that ensures we are successful, follow process, and leads us day to day.
We have the development team that builds detections in the SIEM, and hunts. Thwy make the magic happen.
We use github project management to track our story backlog and in-sprint progress.
https://github.com/features/project-management/
Our story backlog is full of SIEM detection ideas , known Mitre Technique gaps we need to fill, threat hunt ideas, SOC dashboard ideas, etc.
Each story in the backlog has a point value to gauge effort as well as a priority to ensure we get important stuff done first.
The story backlog also contains other deliverables such as TableTop excercises, SOC training, management reporting, etc.
We can create burn down charts and calculate velocity to gauge metrics on how well we are doing.
We can predict future deployment dates for detections based on whats in the backlog and our average velocity.
Every 2 weeks we start a new sprint with a planning meeting where we pull the items highest priority items off the backlog ans assign them out.
At thua time we also engage the automation team in case any hunts or detections will require SIEM or SOAR customizations.
In the planning meeting we consider story size, staff member capacity, stakeholder priorites, etc.
Then daily we have a short call/huddle to identify roadblocks or new priorities.
At the end of the 2 weeks we have a sprint review where we present new detections, dashboards, documentation to stakeholders like SOC.
We use the Palantir Alert and Detection Strategy framework to provide a documented deliverable to SOC for each detection
https://medium.com/palantir/alerting-and-detection-strategy-framework-52dc33722df2
After the sprint review the actual deployment to the SIEM occurs which could include adding, updating, or deleting SIEM detections or dashboards.
After deployment we have a retrospective where we talk about what went well or didnt to ensure we never make the samw mistake twice.
Using Agile creates awareness that #infosec is constantly changing and requires constant freding to ensure youre on top of the latest threats.
As you can expect there is an expedited process for critical or emeegency detections.
But most work we have found can be planned, built, and tested in the 2 week time frame.
For each detection, following Palantir, we define the detection and its purpose, we build it, twst it by actually getting it to fire, and retro hunt each time to ensure we were not already breached.
I hope you found this interesting and helpful. #infosec #blueteam
Monday, November 23, 2015
LinkedIn Resolves XSS in 3 hours
A long while back I wrote a blog expressing my opinion that Agile is better for security than waterfall. The company LinkedIn gave a good example of that this past week. Per this article about an XSS vulnerability they recently resolved, "Dua alerted the company of the bug shortly after 11 p.m. on Monday, and according to his disclosure timeline, LinkedIn implemented a fix shortly after 2 a.m. on Tuesday.".
Now that's quick turn-around! You aren't able to consistently do that successfully unless you're comfortable with moving fast, coding fast, and testing fast. But if you're good at moving fast like that, I believe your site is going to end up much more secure.
More about neonprimetime
Top Blogs of all-time
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Now that's quick turn-around! You aren't able to consistently do that successfully unless you're comfortable with moving fast, coding fast, and testing fast. But if you're good at moving fast like that, I believe your site is going to end up much more secure.
More about neonprimetime
Top Blogs of all-time
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Monday, September 1, 2014
Security Implications of Agile vs Waterfall
Security Implications of Agile vs Waterfall
By Justin C Miller
Posted 9/1/2014
Projects are a necessity in the corporate world. They provide a means for justification and cost estimation. They give guidance and put standards around big changes. They ensure something is built to be efficient and beneficial and well tested. They provide a means to look back, reflect, and improve for the next time.
Two of the more common methodologies you'll find are Waterfall and Agile.
In waterfall you do things in sequence one after another such as requirements, design, development, testing, and release. In general you end up with large volumes of documentation and a lengthy but thorough process. There tends to also be the risk that you'll build something big only to find out when you pass it off that it's no longer what the business wanted.
In Agile you do all those things, but in small tiny waves. In general you end up with very little documentation but you see results almost immediately. You can eliminate the risk of big surprises because the business is involved during each of those tiny waves.
So, a question you might contemplate is in terms of IT Security, does it matter whether my company is using Agile or Waterfall?
I contend that YES, the choice your company makes for Project Methodology has big implications on your company's IT security. I'll skip the dance and games and get straight to the point ... Agile has become a necessity in the corporate world if you're hoping to ensure your environment is secure.
Agile builds your massively complex software in small tiny waves, perhaps 2-4 weeks at a time.
Here are 5 examples of why Agile promotes a more secure environment than Waterfall ever will ...
1.) In Agile there are fewer features built at a time thus it easier to test, and testing is an important step in finding security vulnerabilities. Imagine being asked to test whether the security groups are configured correctly in your application's 10 administrative screens, each of which have 50 tests cases each. Would you be more likely to get it right if you had to test one of the screens/50 test cases at a time, or if you had to test all 10 screens and 500 test cases at once ? Short and sweet means you can concentrate more and feel less stressed and time constrained and get it right.
2.) There are fewer lines of code to review at a time, thus the peer reviews of the code are going to be done more thoroughly and get a good solid look. I've seen it happen way too many times where in your waterfall project you just get done creating 100's of code files and 1000s of lines of code, and now your code review becomes weak and pathetic ... because you'll NEVER get a developer to review 100's of files and 1000s of lines of code in one shot. But in an Agile scenario it is much more realistic to expect them to view a handful of files and a few lines of code and review it correctly.
3.) One of the key aspects of IT security is code complexity. The simpler the code, the easier it is to secure, the easier it is to understand and the less likely it is to contain a mistake. Thus Agile brings big benefits again because you're writing smaller chunks of code that are less complex and thus by default easier to secure.
4.) Waterfall projects have a history of lasting months if not years from inception till completion. If you've been paying attention to the current state of IT security then you know that things change much quicker than that in our arena. Therefore if you start a project on a certain version of software using certain defense techniques, by the time the project is complete the vendor has probably released numerous software updates, security patches, and even the techniques used to prevent and mitigate vulnerabilities may have changed. Thus by the time a Waterfall project is deployed it's likely already old and out of date and needing an upgrade. Agile on the other hand is pushing out fixes every few weeks and by definition allowing for changing requirements, not just changing business requirements but also changing security requirements. If a patch or vulnerability needs a quick fix, you're able to toss it into the backlog as a feature on the next wave. With Waterfall you'll have a nightmare of a time trying to work it in, and things that get pushed to the backlog in Waterfall typically wait until the project is completely over. Too long in our world.
5.) The biggest, and perhaps least obvious advantage that Agile brings to the table over waterfall is a mindset. You go from moving slow, turning the Titanic, to moving swiftly, piece-mealing it to get the job done quickly. I've seen it many times already where those companies stuck in the mindset of Waterfall are the same companies that struggle to get security patching done because they want to plan it for a month, test it for another month or two, then deploy after a few weeks of Change Advisory board discussions. This of course leaves your company open and vulnerable while you're waiting for the process to play out. The Waterfall mindset also leads to end-of-life software hanging out there because the project is just too large and intense to upgrade ... which obviously is a huge security risk. The Waterfall mindset also leads to known risks being pushed off, delayed, or kicked down the road into the next project. That mindset is just not acceptable in this day and age.
IT projects are just like IT Security ... they're too big and complex to bite off in one chew. The only way you're going to succeed is to cut them up and tackle them as smaller pieces of the puzzle. Get your head wrapped around the idea that the IT world moves quickly and you have to choose a project methodology that matches that pace. Agile is the clear front runner of project methodologies when you're discussing the implications it makes to IT security.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
By Justin C Miller
Posted 9/1/2014
Projects are a necessity in the corporate world. They provide a means for justification and cost estimation. They give guidance and put standards around big changes. They ensure something is built to be efficient and beneficial and well tested. They provide a means to look back, reflect, and improve for the next time.
Two of the more common methodologies you'll find are Waterfall and Agile.
In waterfall you do things in sequence one after another such as requirements, design, development, testing, and release. In general you end up with large volumes of documentation and a lengthy but thorough process. There tends to also be the risk that you'll build something big only to find out when you pass it off that it's no longer what the business wanted.
In Agile you do all those things, but in small tiny waves. In general you end up with very little documentation but you see results almost immediately. You can eliminate the risk of big surprises because the business is involved during each of those tiny waves.
So, a question you might contemplate is in terms of IT Security, does it matter whether my company is using Agile or Waterfall?
I contend that YES, the choice your company makes for Project Methodology has big implications on your company's IT security. I'll skip the dance and games and get straight to the point ... Agile has become a necessity in the corporate world if you're hoping to ensure your environment is secure.
Agile builds your massively complex software in small tiny waves, perhaps 2-4 weeks at a time.
Here are 5 examples of why Agile promotes a more secure environment than Waterfall ever will ...
1.) In Agile there are fewer features built at a time thus it easier to test, and testing is an important step in finding security vulnerabilities. Imagine being asked to test whether the security groups are configured correctly in your application's 10 administrative screens, each of which have 50 tests cases each. Would you be more likely to get it right if you had to test one of the screens/50 test cases at a time, or if you had to test all 10 screens and 500 test cases at once ? Short and sweet means you can concentrate more and feel less stressed and time constrained and get it right.
2.) There are fewer lines of code to review at a time, thus the peer reviews of the code are going to be done more thoroughly and get a good solid look. I've seen it happen way too many times where in your waterfall project you just get done creating 100's of code files and 1000s of lines of code, and now your code review becomes weak and pathetic ... because you'll NEVER get a developer to review 100's of files and 1000s of lines of code in one shot. But in an Agile scenario it is much more realistic to expect them to view a handful of files and a few lines of code and review it correctly.
3.) One of the key aspects of IT security is code complexity. The simpler the code, the easier it is to secure, the easier it is to understand and the less likely it is to contain a mistake. Thus Agile brings big benefits again because you're writing smaller chunks of code that are less complex and thus by default easier to secure.
4.) Waterfall projects have a history of lasting months if not years from inception till completion. If you've been paying attention to the current state of IT security then you know that things change much quicker than that in our arena. Therefore if you start a project on a certain version of software using certain defense techniques, by the time the project is complete the vendor has probably released numerous software updates, security patches, and even the techniques used to prevent and mitigate vulnerabilities may have changed. Thus by the time a Waterfall project is deployed it's likely already old and out of date and needing an upgrade. Agile on the other hand is pushing out fixes every few weeks and by definition allowing for changing requirements, not just changing business requirements but also changing security requirements. If a patch or vulnerability needs a quick fix, you're able to toss it into the backlog as a feature on the next wave. With Waterfall you'll have a nightmare of a time trying to work it in, and things that get pushed to the backlog in Waterfall typically wait until the project is completely over. Too long in our world.
5.) The biggest, and perhaps least obvious advantage that Agile brings to the table over waterfall is a mindset. You go from moving slow, turning the Titanic, to moving swiftly, piece-mealing it to get the job done quickly. I've seen it many times already where those companies stuck in the mindset of Waterfall are the same companies that struggle to get security patching done because they want to plan it for a month, test it for another month or two, then deploy after a few weeks of Change Advisory board discussions. This of course leaves your company open and vulnerable while you're waiting for the process to play out. The Waterfall mindset also leads to end-of-life software hanging out there because the project is just too large and intense to upgrade ... which obviously is a huge security risk. The Waterfall mindset also leads to known risks being pushed off, delayed, or kicked down the road into the next project. That mindset is just not acceptable in this day and age.
IT projects are just like IT Security ... they're too big and complex to bite off in one chew. The only way you're going to succeed is to cut them up and tackle them as smaller pieces of the puzzle. Get your head wrapped around the idea that the IT world moves quickly and you have to choose a project methodology that matches that pace. Agile is the clear front runner of project methodologies when you're discussing the implications it makes to IT security.
Copyright © 2014, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)