Some of the most famous information breaches over the past few years have been a result of entry through embedded and IoT system environments. Often these breaches are a result of unexpected system architecture and service connectivity on the network that allows the hacker to enter through an embedded device and make their way to the financial or corporate servers. Experts in embedded security discuss key security issues for embedded systems and how to address them.
Implementing an Application Security Pipeline in JenkinsSuman Sourav
Performing continuous security testing in a DevOps environment with short release cycles and a continuous delivery pipeline is a big challenge and the traditional secure SDLC model fails to deliver the desired results. DevOps understand the process of built, test and deploy. They have largely automated this process in a delivery pipeline, they deploy to production multiple times per day but the big challenge is how can they do this securely?
This session will focus on a strategy to build an application security pipeline in Jenkins, challenges and possible solutions, also how existing application security solutions (SAST, DAST, IAST, OpenSource Libraries Analysis) are playing a key role in growing the relationship between security and DevOps.
Some of the most famous information breaches over the past few years have been a result of entry through embedded and IoT system environments. Often these breaches are a result of unexpected system architecture and service connectivity on the network that allows the hacker to enter through an embedded device and make their way to the financial or corporate servers. Experts in embedded security discuss key security issues for embedded systems and how to address them.
Implementing an Application Security Pipeline in JenkinsSuman Sourav
Performing continuous security testing in a DevOps environment with short release cycles and a continuous delivery pipeline is a big challenge and the traditional secure SDLC model fails to deliver the desired results. DevOps understand the process of built, test and deploy. They have largely automated this process in a delivery pipeline, they deploy to production multiple times per day but the big challenge is how can they do this securely?
This session will focus on a strategy to build an application security pipeline in Jenkins, challenges and possible solutions, also how existing application security solutions (SAST, DAST, IAST, OpenSource Libraries Analysis) are playing a key role in growing the relationship between security and DevOps.
The development world has come to realize that the way we build applications opens the door to hackers.
We are starting to realize that it is the code itself that is enabling the attacks. It’s the responsibility of the
development team to build software that is inherently impervious to attack. Catching and dealing with
security defects earlier in the development lifecycle is much more economical than dealing with them once
the applications have been deployed.
6 Most Common Threat Modeling MisconceptionsCigital
There are some very common misconceptions that can cause firms to lose their grip around the threat modeling process. This presentation shines a bright light onto the essentials and helps to get your bearings straight with all things related to threat modeling.
Shifting the conversation from active interception to proactive neutralization Rogue Wave Software
When did we forget that old saying, “prevention is the best medicine”, when it comes to cybersecurity? The current focus on mitigating real-time attacks and creating stronger defensive networks has overshadowed the many ways to prevent attacks right at the source – where security management has the biggest impact. Source code is where it all begins and where attack mitigation is the most effective.
In this webinar we’ll discuss methods of proactive threat assessment and mitigation that organizations use to advance cybersecurity goals today. From using static analysis to detect vulnerabilities as early as possible, to managing supply chain security through standards compliance, to scanning for and understanding potential risks in open source, these methods shift attack mitigation efforts left to simplify fixes and enable more cost-effective solutions.
Webinar recording: http://www.roguewave.com/events/on-demand-webinars/shifting-the-conversation-from-active-interception
In QA organizations today, a tester must have technical know-how, good communication skills, and attention to detail. We know that a tester’s main responsibility is to test the software that developers develop to ensure that the product meets the quality standards expected of today’s applications. But apart from that, it’s difficult to measure what exactly makes a good tester.
QA managers and their team members are constantly under pressure to test faster and more efficiently, and deliver software with fewer defects. The role and importance of QA in today’s R&D teams is evolving from simply finding defects to protecting the corporate image. As a result, your testers have to be more productive and more efficient, and change their mindset to think about quality over quantity. It’s not just about finding bugs; it’s about continuing to measure and improve, and finding the right bugs to make the end-user experience better.
In this lecture I will share with you some of the key performance indicators (KPIs) that we use to measure our own testing efforts: Percentage of high/critical, escaped defects, Time to test, Defect resolution time, Percentage of rejected defects and what we’ve learned from each of them, and how our team improved its efficiency and productivity as a result.
DevSecOps - It can change your life (cycle)Qualitest
QualiTest explains how a secured DevOps (DevSecOps) delivery process can be achieved using automated code scan, enabling significant shift left of issues detection and minimizing the time to fix. Whether you are considering DevSecOps, on the path, or already there, this slide is for you.
For more information, please visit www.QualiTestGroup.com
Now that you’ve learned how to create code confidence for better application security, the second webinar in this series focuses on ensuring your processes are secure.
With many organizations transforming development efforts from traditional environments toward Agile development, the need to redefine and establish security standards and testing methods is more important than ever.
In this second one-hour webinar you'll learn how to:
- Integrate security and compliance testing with Agile development
- Provide context for fast triage and remediation
- Create policies for code management in integrated testing environments
Programming languages and techniques for today’s embedded andIoT worldRogue Wave Software
This presentation looks at the problem of selecting the best programming language and tools to ensure IoT software is secure, robust, and safe. By taking a look at industry best practices and decades of knowledge from other industries (such as automotive and aerospace), you will learn the criteria necessary to choose the right language, how to overcome gaps in developers’ skills, and techniques to ensure your team delivers bulletproof IoT applications.
Testing NodeJS, REST APIs and MongoDB with UFTOri Bendet
Today’s applications are becoming more complex. From multi-layers applications, to micro-services to containers, QA & automation engineers are required to test more with less and without compromising the quality of the app.
Join me and Yossi Neeman as we explain the pros & cons of testing at each of the different layers of the application and also share some best practices around Agile Testing. Everything will be demonstrated on a demo application built with the latest technology stack including NodeJS, REST APIs and MongoDB and tested using UFT 12.52.
Static Application Security Testing Strategies for Automation and Continuous ...Kevin Fealey
Static Application Security Testing (SAST) introduces challenges with existing Software Development Lifecycle Configurations. Strategies at different points of the SDLC improve deployment time, while still improving the quality and security of the deliverable. This session will discuss the different strategies that can be implemented for SAST within SDLC—strategies catering to developers versus security analysts versus release engineers. The strategies consider the challenges each team may encounter, allowing them to incorporate security testing without jeopardizing deadlines or existing process.
In this chapter, we will introduce you to the fundamentals of testing: why testing is needed; its limitations, objectives and purpose; the principles behind testing; the process that testers follow; and some of the psychological factors that testers must consider in their work. By reading this chapter you'll gain an understanding of the fundamentals of testing and be able to describe those fundamentals.
How To Implement DevSecOps In Your Existing DevOps WorkflowEnov8
Prioritizing DevOps without considering security can be dangerous. So how can security be implemented within a DevOps team? Adapt to DevSecOps and see how it assists you in developing your implementation technique. This blog will provide a comprehensive understanding of the DevSecOps methodology.
Link to Youtube video: https://youtu.be/-awH_CC4DLo
You can contact me at abhimanyu.bhogwan@gmail.com
My linkdin id : https://www.linkedin.com/in/abhimanyu-bhogwan-cissp-ctprp-98978437/
Basic Introduction to DevSecOps concept
Why What and How for DevSecOps
Basic intro for Threat Modeling
Basic Intro for Security Champions
3 pillars of DevSecOps
6 important components of a DevSecOps approach
DevSecOps Security Best Practices
How to integrate security in CI/CD pipeline
The development world has come to realize that the way we build applications opens the door to hackers.
We are starting to realize that it is the code itself that is enabling the attacks. It’s the responsibility of the
development team to build software that is inherently impervious to attack. Catching and dealing with
security defects earlier in the development lifecycle is much more economical than dealing with them once
the applications have been deployed.
6 Most Common Threat Modeling MisconceptionsCigital
There are some very common misconceptions that can cause firms to lose their grip around the threat modeling process. This presentation shines a bright light onto the essentials and helps to get your bearings straight with all things related to threat modeling.
Shifting the conversation from active interception to proactive neutralization Rogue Wave Software
When did we forget that old saying, “prevention is the best medicine”, when it comes to cybersecurity? The current focus on mitigating real-time attacks and creating stronger defensive networks has overshadowed the many ways to prevent attacks right at the source – where security management has the biggest impact. Source code is where it all begins and where attack mitigation is the most effective.
In this webinar we’ll discuss methods of proactive threat assessment and mitigation that organizations use to advance cybersecurity goals today. From using static analysis to detect vulnerabilities as early as possible, to managing supply chain security through standards compliance, to scanning for and understanding potential risks in open source, these methods shift attack mitigation efforts left to simplify fixes and enable more cost-effective solutions.
Webinar recording: http://www.roguewave.com/events/on-demand-webinars/shifting-the-conversation-from-active-interception
In QA organizations today, a tester must have technical know-how, good communication skills, and attention to detail. We know that a tester’s main responsibility is to test the software that developers develop to ensure that the product meets the quality standards expected of today’s applications. But apart from that, it’s difficult to measure what exactly makes a good tester.
QA managers and their team members are constantly under pressure to test faster and more efficiently, and deliver software with fewer defects. The role and importance of QA in today’s R&D teams is evolving from simply finding defects to protecting the corporate image. As a result, your testers have to be more productive and more efficient, and change their mindset to think about quality over quantity. It’s not just about finding bugs; it’s about continuing to measure and improve, and finding the right bugs to make the end-user experience better.
In this lecture I will share with you some of the key performance indicators (KPIs) that we use to measure our own testing efforts: Percentage of high/critical, escaped defects, Time to test, Defect resolution time, Percentage of rejected defects and what we’ve learned from each of them, and how our team improved its efficiency and productivity as a result.
DevSecOps - It can change your life (cycle)Qualitest
QualiTest explains how a secured DevOps (DevSecOps) delivery process can be achieved using automated code scan, enabling significant shift left of issues detection and minimizing the time to fix. Whether you are considering DevSecOps, on the path, or already there, this slide is for you.
For more information, please visit www.QualiTestGroup.com
Now that you’ve learned how to create code confidence for better application security, the second webinar in this series focuses on ensuring your processes are secure.
With many organizations transforming development efforts from traditional environments toward Agile development, the need to redefine and establish security standards and testing methods is more important than ever.
In this second one-hour webinar you'll learn how to:
- Integrate security and compliance testing with Agile development
- Provide context for fast triage and remediation
- Create policies for code management in integrated testing environments
Programming languages and techniques for today’s embedded andIoT worldRogue Wave Software
This presentation looks at the problem of selecting the best programming language and tools to ensure IoT software is secure, robust, and safe. By taking a look at industry best practices and decades of knowledge from other industries (such as automotive and aerospace), you will learn the criteria necessary to choose the right language, how to overcome gaps in developers’ skills, and techniques to ensure your team delivers bulletproof IoT applications.
Testing NodeJS, REST APIs and MongoDB with UFTOri Bendet
Today’s applications are becoming more complex. From multi-layers applications, to micro-services to containers, QA & automation engineers are required to test more with less and without compromising the quality of the app.
Join me and Yossi Neeman as we explain the pros & cons of testing at each of the different layers of the application and also share some best practices around Agile Testing. Everything will be demonstrated on a demo application built with the latest technology stack including NodeJS, REST APIs and MongoDB and tested using UFT 12.52.
Static Application Security Testing Strategies for Automation and Continuous ...Kevin Fealey
Static Application Security Testing (SAST) introduces challenges with existing Software Development Lifecycle Configurations. Strategies at different points of the SDLC improve deployment time, while still improving the quality and security of the deliverable. This session will discuss the different strategies that can be implemented for SAST within SDLC—strategies catering to developers versus security analysts versus release engineers. The strategies consider the challenges each team may encounter, allowing them to incorporate security testing without jeopardizing deadlines or existing process.
In this chapter, we will introduce you to the fundamentals of testing: why testing is needed; its limitations, objectives and purpose; the principles behind testing; the process that testers follow; and some of the psychological factors that testers must consider in their work. By reading this chapter you'll gain an understanding of the fundamentals of testing and be able to describe those fundamentals.
How To Implement DevSecOps In Your Existing DevOps WorkflowEnov8
Prioritizing DevOps without considering security can be dangerous. So how can security be implemented within a DevOps team? Adapt to DevSecOps and see how it assists you in developing your implementation technique. This blog will provide a comprehensive understanding of the DevSecOps methodology.
Link to Youtube video: https://youtu.be/-awH_CC4DLo
You can contact me at abhimanyu.bhogwan@gmail.com
My linkdin id : https://www.linkedin.com/in/abhimanyu-bhogwan-cissp-ctprp-98978437/
Basic Introduction to DevSecOps concept
Why What and How for DevSecOps
Basic intro for Threat Modeling
Basic Intro for Security Champions
3 pillars of DevSecOps
6 important components of a DevSecOps approach
DevSecOps Security Best Practices
How to integrate security in CI/CD pipeline
Mike Spaulding - Building an Application Security Programcentralohioissa
Application Security in many organizations is a simply a 'wish list' item, but with some staff and some training, AppSec can be a reality, even for a small organization. This talk will discuss the best practices, strategies and tactics, and resource planning to build an internal AppSec function - enterprise to 'mom & pop' operations will all benefit from this talk.
Protecting Agile Transformation through Secure DevOps (DevSecOps)Eryk Budi Pratama
Respresenting Cyber Defense Community (cdef.id) to present and share my view on Secure DevOps / DevSecOps. Through this presentation, I shared several insights about:
1. How to balance the risk and controls in the "great shift left" paradigm (agile)
2. DevOps activities
3. How to seamlessly integrate security into DevOps
4. How to "shift left" the security"
5. Get started with Secure DevOps / DevSecOps
6. Case Study about DevSecOps implementation
For further discussion, especially how to secure digital and agile transformation in your organization, don't hesitate to contact me :)
Security teams are often seen as roadblocks to rapid development or operations implementations, slowing down production code pushes. As a result, security organizations will likely have to change so they can fully support and facilitate cloud operations.
This presentation will explain how DevOps and information security can co-exist through the application of a new approach referred to as DevSecOps.
AppSec How-To: Achieving Security in DevOpsCheckmarx
How do you integrate security within a Continuous Deployment (CD) environment, where every 5 minutes a feature, an enhancement, or a bug fix needs to be released? Find out in this Checkmarx How-To Paper.
Why Security Engineer Need Shift-Left to DevSecOps?Najib Radzuan
In the fusion between DevOps and DevSecOps, the pace and agility of the DevSecOps approach made AppSec and InfoSec were a little left behind. The DevOps squad topology does not involve any of the organization's AppSec and InfoSec Engineer. Many DevOps team are also not included them since they lack the information on how to manage and configure DevOps CI / CD pipelines and DevSecOps approaches. There's no shortage of talent — you probably don't have a mission worth getting out of bed or a culture that fosters continuous learning such DevSecOps skill and tools and growth where people feel psychologically safe. Besides, there is no shortage of skills — most have a poor understanding of what they need to be successful or the skills that need to leverage to improve their security posture.
DevOps and Devsecops- Everything you need to know.Techugo
DevOps is a software development approach that emphasizes collaboration and communication between developers and IT operations teams to streamline the development and deployment of software. DevSecOps extends DevOps by integrating security into every stage of the software development lifecycle, from planning to deployment, to ensure that security risks are identified and addressed early on.
In Agile’s fast-paced environment with frequent releases,
security reviews and testing can sound like an impediment to success. How can you keep up with Agile development's demands of continuous integration and deployment without
abandoning security best practices? These 10 steps will help you get the best of both worlds.
_Best practices towards a well-polished DevSecOps environment (1).pdfEnov8
DevSecOps is a software development approach that encourages the adoption of security throughout the whole software development lifecycle. It favors security automation, communication, and scalability in the entire IT environments. DevSecOps infuses security practices in the DevOps process.
Security engineering 101 when good design & security work togetherWendy Knox Everette
Security concerns are often dealt with as an afterthought—the focus is on building a product, and then security features or compensating controls are thrown in after the product is nearly ready to launch. Why do so many development teams take this approach? For one, they may not have an application security team to advise them. Or the security team may be seen as a roadblock, insisting on things that make the product less user friendly, or in tension with performance goals or other business demands. But security doesn’t need to be a bolt-on in your software process; good design principles should go hand in hand with a strong security stance. What does your engineering team need to know to begin designing safer, more robust software from the get-go?
Drawing on experience working in application security with companies of various sizes and maturity levels, Wendy Knox Everette focuses on several core principles and provides some resources for you to do more of a deep dive into various topics. Wendy begins by walking you through the design phase, covering the concerns you should pay attention to when you’re beginning work on a new feature or system: encapsulation, access control, building for observability, and preventing LangSec-style parsing issues. This is also the best place to perform an initial threat model, which sounds like a big scary undertaking but is really just looking at the moving pieces of this application and thinking about who might use them in unexpected ways, and why.
She then turns to security during the development phase. At this point, the focus is on enforcing secure defaults, using standard encryption libraries, protecting from malicious injection, insecure deserialization, and other common security issues. You’ll learn what secure configurations to enable, what monitoring and alerting to put in place, how to test your code, and how to update your application, especially any third-party dependencies.
Now that the software is being used by customers, are you done? Not really. It’s important to incorporate information about how customers interact as well as any security incidents back into your design considerations for the next version. This is the time to dust off the initial threat model and update it, incorporating everything you learned along the way.
DOES14 - Jonny Wooldridge - The Cambridge Satchel Company - 10 Enterprise Tip...Gene Kim
Jonny Wooldridge, CTO, The Cambridge Satchel Company at the DevOps Enterprise Summit 2014
View video: https://www.youtube.com/watch?v=CzUTztwcc58
View Jonny Wooldridge's blog: http://www.enterprisedevops.com
Following 3.5 years building a DevOps capability and culture at M&S I will be condensing the experience down to 10 Enterprise DevOps tips that are relevant to companies of all sizes and complexities. Bringing start-up lean thinking to an enterprise was never going to be easy but the lessons learned are relevant to us all.
DevOps and Devsecops- What are the Differences.Techugo
Pharmaceutical manufacturing software is a tool that streamlines the manufacturing process of pharmaceutical products. The difference between different pharmaceutical manufacturing software lies in their features and capabilities. Some software may focus on specific areas of manufacturing, such as quality control, while others may provide end-to-end solutions for the entire manufacturing process. Factors such as scalability, customization, and regulatory compliance are also important considerations when choosing pharmaceutical manufacturing software. Ultimately, the right software should meet the unique needs of a pharmaceutical manufacturing company and improve their operational efficiency.
DevSecOps: Integrating Security Into DevOps! {Business Security}Ajeet Singh
The key benefit of DevOps is speed and continuous delivery but with secure DevOps teams often suffer from the notion that there’s a tradeoff between security and speed. However, that is not the scenario always.
Prudent use of Security automation allows the teams to maintain both security and speed. The automated security testing makes the security consistent and less vulnerable to human errors. Shifting of the security practices left towards the design phase is a major advantage. It is a big achievement to catch the security loophole at the design or the development phase of a new feature. This is what DevSecOps tooling strategies aim at.
Check out this presentation and learn more about integrating security into DevOps with DevSecOps!
4 approaches to integrate dev secops in development cycleEnov8
DevSecOps is an advanced extension of the DevOps technique in application engineering. In this model, developers/software engineers, operations teams and security teams collaborate and function closely throughout the software development lifecycle (SDLC) workflows and continuous integration / continuous deployment (CI/CD) pipelines.
Oprah Winfrey: A Leader in Media, Philanthropy, and Empowerment | CIO Women M...CIOWomenMagazine
This person is none other than Oprah Winfrey, a highly influential figure whose impact extends beyond television. This article will delve into the remarkable life and lasting legacy of Oprah. Her story serves as a reminder of the importance of perseverance, compassion, and firm determination.
Senior Project and Engineering Leader Jim Smith.pdfJim Smith
I am a Project and Engineering Leader with extensive experience as a Business Operations Leader, Technical Project Manager, Engineering Manager and Operations Experience for Domestic and International companies such as Electrolux, Carrier, and Deutz. I have developed new products using Stage Gate development/MS Project/JIRA, for the pro-duction of Medical Equipment, Large Commercial Refrigeration Systems, Appliances, HVAC, and Diesel engines.
My experience includes:
Managed customized engineered refrigeration system projects with high voltage power panels from quote to ship, coordinating actions between electrical engineering, mechanical design and application engineering, purchasing, production, test, quality assurance and field installation. Managed projects $25k to $1M per project; 4-8 per month. (Hussmann refrigeration)
Successfully developed the $15-20M yearly corporate capital strategy for manufacturing, with the Executive Team and key stakeholders. Created project scope and specifications, business case, ROI, managed project plans with key personnel for nine consumer product manufacturing and distribution sites; to support the company’s strategic sales plan.
Over 15 years of experience managing and developing cost improvement projects with key Stakeholders, site Manufacturing Engineers, Mechanical Engineers, Maintenance, and facility support personnel to optimize pro-duction operations, safety, EHS, and new product development. (BioLab, Deutz, Caire)
Experience working as a Technical Manager developing new products with chemical engineers and packaging engineers to enhance and reduce the cost of retail products. I have led the activities of multiple engineering groups with diverse backgrounds.
Great experience managing the product development of products which utilize complex electrical controls, high voltage power panels, product testing, and commissioning.
Created project scope, business case, ROI for multiple capital projects to support electrotechnical assembly and CPG goods. Identified project cost, risk, success criteria, and performed equipment qualifications. (Carrier, Electrolux, Biolab, Price, Hussmann)
Created detailed projects plans using MS Project, Gant charts in excel, and updated new product development in Jira for stakeholders and project team members including critical path.
Great knowledge of ISO9001, NFPA, OSHA regulations.
User level knowledge of MRP/SAP, MS Project, Powerpoint, Visio, Mastercontrol, JIRA, Power BI and Tableau.
I appreciate your consideration, and look forward to discussing this role with you, and how I can lead your company’s growth and profitability. I can be contacted via LinkedIn via phone or E Mail.
Jim Smith
678-993-7195
jimsmith30024@gmail.com
The Team Member and Guest Experience - Lead and Take Care of your restaurant team. They are the people closest to and delivering Hospitality to your paying Guests!
Make the call, and we can assist you.
408-784-7371
Foodservice Consulting + Design
Artificial intelligence (AI) offers new opportunities to radically reinvent the way we do business. This study explores how CEOs and top decision makers around the world are responding to the transformative potential of AI.
The case study discusses the potential of drone delivery and the challenges that need to be addressed before it becomes widespread.
Key takeaways:
Drone delivery is in its early stages: Amazon's trial in the UK demonstrates the potential for faster deliveries, but it's still limited by regulations and technology.
Regulations are a major hurdle: Safety concerns around drone collisions with airplanes and people have led to restrictions on flight height and location.
Other challenges exist: Who will use drone delivery the most? Is it cost-effective compared to traditional delivery trucks?
Discussion questions:
Managerial challenges: Integrating drones requires planning for new infrastructure, training staff, and navigating regulations. There are also marketing and recruitment considerations specific to this technology.
External forces vary by country: Regulations, consumer acceptance, and infrastructure all differ between countries.
Demographics matter: Younger generations might be more receptive to drone delivery, while older populations might have concerns.
Stakeholders for Amazon: Customers, regulators, aviation authorities, and competitors are all stakeholders. Regulators likely hold the greatest influence as they determine the feasibility of drone delivery.
2. He/Him
CISSP, C|EH, MSCE
Information Security Executive, Consultant, Wise-Guy
LinkedIn: https://www.linkedin.com/in/robbkeefer
Robb.keefer@outlook.com
Who is Robert Keefer?
3.
4. Some
Definitions
Flaw: A weakness in an application. This may come about
due to a missed best practice, a syntax or other error,
misconfiguration, or a weakness inherent to the language
or framework.
Vulnerability: A flaw with a known exploit. All
vulnerabilities are flaws, but not all flaws are
vulnerabilities…at least not yet!
Remediation: A change made in the code to address a
vulnerability or flaw. A remediated flaw or vulnerability
does not exist in the finished app any longer.
Mitigation: The creation or documentation of a
compensating control. A compensating control does not
remove the flaw or vulnerability, but hopefully makes it
impossible to exploit.
5. The Agile Manifesto
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to
value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more.
6. The Twelve Agile Principles
1. Our highest priority is to
satisfy the customer
2. Welcome changing
requirements, even late
in development.
3. Deliver working software
frequently.
4. Business people and
developers must work
together
5. Build projects around
motivated individuals.
6. Face-to-face
conversation.
7. Twelve Principles Continued
7. Working software is the
primary measurement of
progress.
8. Agile processes promote
sustainable development.
9. Continuous attention to
technical excellence.
10.Simplicity is essential.
11.self-organizing teams.
12.At regular intervals, the
team reflects on how to
become more effective.
9. Ask Yourself:
Does insecure software value individuals and interactions?
Does insecure software count as working?
Is insecure software the result of customer collaboration?
Does insecure software (or rather software development
that doesn’t take security into account) respond
appropriately to change?
10. The Twelve Agile Principles?
1. Our highest priority is to
satisfy the customer.
2. Welcome changing
requirements, even late
in development.
3. Deliver working software
frequently.
4. Business people and
developers must work
together.
5. Build projects around
motivated individuals.
6. Face-to-face
conversation.
11. Twelve Principles?
7. Working software is the
primary measurement of
progress.
8. Agile processes promote
sustainable development.
9. Continuous attention to
technical excellence.
10.Simplicity is essential.
11.self-organizing teams.
12.At regular intervals, the
team reflects on how to
become more effective.
13. Hardening Sprints
Security dedicated dev pass
Often result of customer complaint
✅ Useful to resolve complex issues
✅ Shows dedication to security
❌ Delays product
❌ Seen as tedious
❌ Creates “Security at the End” mindset
14. User Stories
Include security requirements in epic
Adds to “definition of done”
✅ Easy to accomplish
✅ Handy metric
❌ Can add complexity
❌ Security stories are hard to score
❌ Incomplete approach
19. Acronyms: SAST
Static Application Security Tool
Source code scanner
Language dependent
Unaware of infrastructure or mitigations
20. Acronyms: DAST
Dynamic Application Security Tool
Runs on external server
Runs against compiled code
Checks for API, web interface, SQL calls, etc.
Uses CVS, OWASP Top 10, etc. to rate
Different results inside firewall from outside
“Black Box” testing
21. Acronyms: IAST
Interactive Application Security Tool
Runs on application server
Real-time as application is used
Aware of server, frameworks, backend, etc.
“White Box” testing
22. Layered Approach: SAST
Runs internally against code repositories
Run from developer IDE if possible
Trigger after set number of updates
23. Layered Approach: DAST
Run outside of security perimeter, pointing to UAT
Run after every deployment to environment
Used to confirm flaws have been identified and
remediated or mitigated
24. Layered Approach: IAST
IAST: Installed on QA servers
Runs constantly
Reports as part of QA testing
25. Layered Approach: External Testing
Used to supplement automated testing
Separate team; either onboarded Red Team
or external vendor
Fuzzing tools, vuln scanners, manual testing
Should not be confrontational!
26. Conclusion: Three Takeaways
Application security is not anti-Agile; not being secure is
anti-Agile.
Application security principles can be folded into the
development process, rather than bolted on to the end.
No matter how many tools you deploy or tests you run,
secure applications are developed by people, for people.
27. Thank You! Questions?
References:
Agile Alliance: http://www.agilealliance.org
Microsoft SDL: https://www.microsoft.com/en-us/securityengineering/sdl
Microsoft SDL-Agile: https://docs.microsoft.com/en-us/previous-
versions/windows/desktop/ee790620(v=msdn.10)
My LinkedIn (feel free to add me!):
https://www.linkedin.com/in/robbkeefer
Editor's Notes
Thank you all for coming today! My name is Robert Keefer; I am an information security executive; I have about 20 or so years of experience in InfoSec and some of the requisite alphabet soup after my name to show it. My LinkedIn is on this slide and will be at the end if you want to know more about me, but today I’m here to discuss concepts around application security with you.
Now, here is where a lot of security presentations insert the disaster stories. You know, the ones where the developer forgot to close an HTML tag and the local orphanage burned down. I don’t really like disaster stories most of the time, so I’m not going to do that here. Instead I’m going to talk to you a little bit about Agile.
First, Some Definitions and Terms
Flaw: A weakness in an application. This may come about due to a missed best practice, a syntax or other error, misconfiguration, or a weakness inherent to the language or framework.
Vulnerability: A flaw with a known exploit. All vulnerabilities are flaws, but not all flaws are vulnerabilities…at least not yet!
Remediation: A change made in the code to address a vulnerability or flaw. A remediated flaw or vulnerability does not exist in the finished app any longer.
Mitigation: The creation or documentation of a compensating control. A compensating control does not remove the flaw or vulnerability, but hopefully makes it impossible to exploit.
Note that a mitigated vulnerability still exists! This means that if the control fails, the application can be exploited. This is why we prefer remediation over mitigation.
This is probably review for all of you, but it’s good to look it over every once in awhile.
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Alliance (www.agilealliance.org) is an organization founded by some of the authors of the original manifesto. One of their tasks was to expand the concepts in the manifesto into the following 12 principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measurement of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
A department that is Agile will conform to more of these concepts and principles, and do so more closely, than a department that is not Agile. That does not mean, of course, that a department needs to adhere slavishly to all of the 4 concepts or 12 principles.
Why did we just go through this review? Many people, both application developers and information security folks, act from the belief, often unstated, that security requirements conflict with Agile.
Does security really conflict with the Agile Manifesto?
Ask yourself:
Does insecure software value individuals and interactions?
Does insecure software count as working? (if a coffee maker squirts you in the face with scalding water while it brews, is that working?)
Is insecure software the result of customer collaboration? (do you *really* think the customer wants credit card data to be easy for strangers to obtain?)
Does insecure software (or rather software development that doesn’t take security into account) respond appropriately to change? Remember that flaws, even mitigated ones, may have exploits developed against them in the future.
I would suggest that NOT focusing on security conflicts with the Agile Manifesto. It also conflicts with the 12 principles:
-It doesn’t satisfy the customer (1)
-It doesn’t provide competitive advantage for the customer (2)
-It’s not working software—certainly not as the customer requires! (3,7)
-Unaddressed flaws are bad for the business (4)
-They certainly aren’t technical excellence! (9)
So we can see that designing software without keeping security in mind is actually pretty far from Agile. So how can we include security in an Agile way?
A “Hardening Scrum/Sprint/Pass” is just what it sounds like; taking a development pass to focus on resolving identified security issues, whether flaws, unresolved threat models, configuration issues, or the like, instead of developing new functionality. Sometimes these are done at behest of QA as well, but typically that sort of debt is resolved over multiple scrums.
This is often done as a resolution to a customer complaint—in other words if you are doing hardening sprints then Something Has Gone Very Wrong Indeed.
Why might you want to use this approach? Well, as we just discussed it can be a way to show a dissatisfied customer that you are now taking security seriously. For very complicated security issues, or ones that are mission critical, it may be worthwhile to set other development aside for awhile and focus on this particular thing. If you really haven’t been addressing security issues, then doing a hardening sprint can be a way to get some momentum going as well.
However, it comes with what I consider some pretty significant downsides. First, any sprint that isn’t developing new features is a delay on the final product. Second, developers as a rule would prefer to develop neat new features rather than address debt, and unresolved security issues are debt. This means that a hardening sprint is seen as tedious, which is hard on the squad, hard on the department, and hard on the project managers who have to deal with the morale issues. Lastly, this approach allows the department to consider security as something you do “after” the features are developed, instead of being part of the development process. This makes the whole process less efficient and more error-prone.
One way to overcome the inertia of hardening sprints is to make security part of the requirements. Often this is done by creating stories for security requirements and/or threat models and including them in the epic. By doing this we can make security part of the “definition of done”.
The advantages to this approach are: First, it’s pretty easy to do. Most people are already comfortable working with stories, and these are just another type. It moves security concerns from a release gating factor to part of requirements gathering, with all the advantages that has (less overall effort, greater flexibility in implementation, and so on). And, it provides a handy metric that gives a rough idea of the level of security in a project and the level of effort being spent to increase that level.
On the other hand, using stories as your sole method of application security has its own issues. There is the danger of increasing complexity beyond what is sustainable in an Agile team. Security stories can be challenging to score without additional information, such as threat models or risk analysis. It’s also an incomplete approach. Security can’t always be reduced to a set of requirements; it’s part of the application and project ecosystem.
Which means that security can be aligned with the project’s lifecycle. There are a number of different approaches to this; the one that I use draws heavily from the SDL-Agile model developed by Microsoft.
This model breaks application security into several tasks that align with the project lifecycle of your organization. Some of them are done pre-project, like security training and tools implementation, some are done once per project, some are done per-sprint, and some are bucket tasks, which are tasks that need to be scheduled during the project’s development, but aren’t necessarily done every sprint. Depending on the task and the team’s rhythm I try to do these every retrospective or every other retrospective.
The Pre-Project Tasks include security training (this counts, by the way!), creation or maintenance of Incident Response Boards, other security Boards, and so on. Most of these are done yearly, and often at the enterprise, division, or department level.
The One-Time Tasks are things like requirements gathering, initial threat modeling, tool decision and implementation, and final security assessment (usually fuzz testing/pentest, etc).
The Per-Sprint Tasks include code scanning, unit reviews, bug tracking, and similar tasks.
The Bucket Tasks are those things that are important, but for one reason or another aren’t necessary every sprint—usually because they don’t get updated that often. These are tasks like updating the threat model, designing or updating privacy and security documents, creating the incident response plan, and so forth.
Now for each of these you can draft a specific set of steps, depending on your application, it’s intended use and audience, your customized Agile methodology, etc. In fact, doing so is one of the One-Time tasks I usually recommend.
So: We’ve talked about why we do appsec, and discussed some approaches to implementing it. Let’s talk about some of the common types of tools that are used in the pursuit of secure software.
SAST, DAST, IAST. That’s a lot of acronyms that all look very much alike. Let’s look at these a bit closer and see how they differentiate from each other and how they complement each other in an appsec program.
First, SAST or Static Application Security Tool. This is your classic “source code scanner”. Typically this is a syntactic analysis tool that will review submitted code and run it against a list of known flaws, vulnerabilities, and best practices. It will then provide an indication of the sort of issue it finds, locate it within the code, and in some cases provide additional information on the nature of the issue and provide recommendations on how to resolve it. These tools tend to be heavily language specific, signature based, and a little on the resource heavy side. They’re usually pretty quick, however.
The output of a SAST is a list of flaws and/or potential vulnerabilities, based on the source code in a vacuum. It does not know how your databases are set up, what kind of firewall is in front of the finished application, or even the operating system that will be used. For that reason the output needs to be triaged by the team before it can be acted on. Please note, however, that even if a flaw cannot be exploited at this time, that does not mean it isn’t a flaw in the code! This is why many SAST tools don’t have a way to mark issues as “false positive”; instead you mark them “not exploitable”. The flaw is real, it just doesn’t lead to a security finding. At least, not today.
DAST, or Dynamic Application Security Tool, operates differently. A DAST runs against compiled code, looking for vulnerabilities in the APIs, web interfaces, SQL calls, etc that it can find. They get pointed at the application from the outside; for this reason they are also called “black box testing” tools. Their output is a list of potential vulnerabilities that typically comes from a known source such as CVS (Common Vulnerability System), and uses a common framework to rank them, such as OWASP Top 10.
The accuracy of a DAST tool depends on where it’s placed. If you run it against a production system from outside your security perimeter, then anything it can see an attacker can see as well, which means it’s highly unlikely to be any sort of false positive. As with SAST however you will not want to just blindly accept the findings, as it may not be aware of other mitigations in place.
Finally IAST is Interactive Application Security Tool. This runs on the application server, and monitors application activity in real time as it’s used. Because it’s part of your deployment infrastructure, it is aware of the underlying server, any application frameworks, backend databases, and so forth. What most IASTs look for is vulnerable behavior or results. These tools provide a comprehensive look at the application infrastructure and can help pinpoint any underlying vulnerabilities and how they may interact with flaws in the compiled code. Again as with all automated tools you want to triage the results to ensure that the detected issues are aligned with your risk model. If DAST is “black box” testing, then IAST can be considered “white box” testing.
In order to maximize the effectiveness of these tools I usually recommend a layered approach:
SAST running internally, at the very least performing regular scans on the repositories. Ideally the tool is able to be run by developers out of their IDE as well—this will provide them with near-real-time feedback on their code as they’re developing it. Failing that, the SAST should be triggered after a certain number of updates to the repository; how many depends on your internal processes.
DAST should be running externally to your User Acceptance infrastructure, and should be run after every deployment. The purpose of this tool is largely to confirm that flaws have been identified and remediated, and that any proposed mitigations are in fact protecting the system as described.
IAST should be running on your QA systems, and runs constantly. This will generate new data with every QA pass, so it should ideally be a part of that team’s output.
Automated testing can only get you so far. In order to test completely a certain amount of more manual testing is necessary. This should be done by a team that is not associated with the development team or the application security team—either a dedicated Red Team within the organization or an external vendor. They will perform a manual security analysis using standard penetration testing tools and techniques. This process is usually time and labor intensive, and results in a comprehensive report of the overall security stance of the application and its infrastructure. Because of the time and intensity factor I rarely have this run more often than twice a year. As a rule of thumb, you want to have external testing performed with every major release iteration.
Many people see red teams as confrontational. They shouldn’t be. You should be able to have the red team, whether internal or external contractors, working in close cooperation with the application development and project management teams to identify, prioritize, and remediate issues as they are found, and if you can’t? Find a different team. Remember that will all of these tools and approaches the final goal is secure, working software.
I’ve given you a lot of information, and hopefully some of it has been enlightening. When I’m building a presentation like this one of the things I try to consider is this: If you were only going to take away three things from my time here with you, what would I want them to be? And in this case those three things are:
1. Application Security is not anti-Agile; in fact not being secure is anti-Agile.
2. Application security principles can be folded into your development processes, rather than bolted on to the end, and
3. No matter how many tools you deploy or tests you run, secure applications are developed by people, for people.