On February 26, 2021, NetSPI Managing Director Nabil Hannan was featured in TechTarget:
We’re in the midst of a cybersecurity staffing crisis. Many major news outlets, such as The New York Times, have reported that unfilled jobs in the industry are expected to reach up to 3.5 million this year – leaving existing security teams stretched thin and burnt out.
To make matters worse, attackers have increased their activity since the beginning of the pandemic and continue to take advantage of the prolonged crisis. In this new year, CISOs everywhere will need to shift their talent management practices in order to attract new candidates to the field and prevent employee burnout. How? Here are a few ideas.
It is fairly straightforward, yet its meaning and value can vary. Formally defined, as a Service refers to a subscription-based delivery model designed to give customers maximum flexibility with little to no overhead. The same concept applies in cyber security, where we often see vendors managing a particular piece of technology for a customer that can also include services.
The as a Service delivery model has seen a tremendous evolution over the years and now takes many forms, from the foundational Software as a Service (SaaS) to the emerging Penetration Testing as a Service (PTaaS) – and there’s even a term for Anything as a Service (XaaS). The adoption of the delivery model continues to expand. Analysts expect the market to grow 24% by 2024 and Gartner anticipated that all new software providers and the majority of existing vendors would offer subscription-based business models by the end of 2020.
NetSPI recently launched Application Security (AppSec) as a Service to help organizations manage and mature their application security programs. To navigate the evolving landscape and better understand its value, this blog explores what it really means to deliver something as a Service and why an as a Service partnership for application security is valuable.
Four core attributes of an ‘as a Service’ partnership
It’s important to note that by purchasing something as a Service, it does not necessarily mean that you are outsourcing that product or service to a third party. The terms are often used interchangeably; however, they differ greatly. Recognizing the differences between outsourcing and entering an as a Service partnership is key to understanding the true value of the delivery model.
There are four key components that define an as a Service offering and contribute to the success of the program. The core attributes of an as a Service partnership are as follows:
Collaboration: A successful partnership enables collaboration and information sharing between vendor and client on a much deeper level. Because the vendor should serve as an extension of a client’s team, they receive internal context that allows them to provide the needed technical depth, while also driving efficiency through technology innovation.
Scalability: The ability to scale up or down to meet capacity and performance requirements is core to an as a Service partnership. It is essential for your vendor partner to work with you to forecast capacity needs and allocate necessary resources. Vendors should not only have the capability to scale up during a time of need, but also to redirect capacity to other areas at times where demand is less significant.
Automation: Process automation helps free up your team members’ and vendor partners’ time to focus on more strategic initiatives. Any as a Service offering should incorporate some level of automation. For example, with NetSPI’s AppSec as a Service, automation and tools are deployed to support manual testers in finding application vulnerabilities that tools alone cannot.
Continuity: Relationships such as an as a Service partnership need to be continuous to be most effective. Having continuity in your vendor partnership allows for greater understanding of business processes, the threats an organization is most likely to face, and techniques for preventing cyber-attacks. A long-standing relationship also supports trending data collection to track progress over time.
The value of Application Security as a Service
When I talk about an “as a Service partnership”, I mean that NetSPI, a partner, is working inside of a client’s program as an extension of their team.
With an AppSec as a Service partnership, clients gain dedicated technology and leadership that supports a scalable team of application security testers. It is a modular and scalable approach to application security comprised of multiple components that may be deployed as a complete program or individually, integrating with existing processes and technologies. We invest significant time, resources, and budget into onboarding our experienced consulting team into the client environment where there are specific nuances and requirements. Oversight and crosschecks are done to ensure expectations are met, to identify areas within the parameters of the project that may require more attention, and to report back to the client-side leadership with findings we uncover.
Throughout the partnership, there are touchpoints at the executive, technical, and project levels. At the executive level, we look at the metrics, communications, and structures in place to align to the program thematically. At the technical level, there is collaboration around process, technology toolsets, and ways to automate in a high-volume environment. And at the project level, we evaluate our resource planning, communications, and alignment with the client-side team.
There are many ways an organization can benefit from an as a Service partnership for its application security program. Here are a few to note:
Add context to an environment. AppSec as a Service enables organizations to gain context inside of their applications by deepening their insight through technical testing and collaboration. The delivery model helps both client- and vendor-side teams better understand the attack surface to target its weaknesses.
Reduce time managing expectations. Create more meaningful touchpoints inside of an organization and build trust by not having to manage multiple vendors, doing different things, through different processes. Having one single source of truth for all application security activities, one that is integrated into your program nevertheless, eliminates chaos around remediation.
Support during staffing shortages. My colleague, Florindo Gallicchio said it best in his 2021 predictions. He wrote, “Cyber security leaders will be challenged by filling roles that require candidates with mid- to senior- level experience – and entry level job openings will continue to be in high demand. Because of this, companies will need to do more with fewer people. This will result in increased adoption of program-level partnerships with third parties or using vendors to fill in-house positions at scale.”
Identify the right metrics. Goal alignment is clear-cut with AppSec as a Service given the vendor is aware of the day-to-day application security activities, has a direct line of sight into the goals and objectives of the program, and understands a business’s most valuable – and vulnerable – assets. Given this enhanced insight and context, your partner can help identify which metrics to track to communicate program progress and Return on Investment (ROI) to leadership team.
Whether it is application security, penetration testing, software, infrastructure, or anything, an as a Service delivery model can provide immense value to any organization. As these offerings continue to evolve and more vendors jump on the as a Service bandwagon, use the above criteria to evaluate potential providers to ensure you’re getting the most out of your relationship.
One of the major challenges CISOs, like myself, face today is finding balance between keeping a business running efficiently versus the security controls implemented. It is an ongoing challenge that takes time to figure out. But, as we all know, time is not something that is readily available to CISOs.
To help, Nabil Hannan, NetSPI Managing Director and a former colleague of mine, invited me to share insights on his Agent of Influence podcast. From the conversation, here are my top tips for achieving balance and, in turn, eliminating friction between business and cyber security.
Create realistic security awareness campaigns – and learn from them
Phishing engagements are a great opportunity to keep people on their toes while garnering awareness around email security. One particular engagement I coordinated was so effective, it fooled our security team. Our phishing emails were deployed at the same time as our real security awareness training and tricked people into clicking on a “malicious” link to confirm they had completed the company-wide training. Over 70 percent of people in the company fell for it.
We learned a few lessons from this engagement.
First, security practitioners are not immune to phishing attacks. There is a misconception that security teams are immune to being hacked or compromised. It is important to find curious and creative methods of security awareness training to challenge not only your general employees, but also your security teams.
Second, someone had said to me, “I will never trust an email from you again.” And I thought about that for a long time – and still do to this day. How do we as security practitioners create effective training campaigns without losing some level of trust? Well, it’s not necessarily a bad thing for people to be skeptical. People can be easily tricked when their guard is down. When we receive an email from an outside source nowadays we are much more cautious when opening attachments or clicking on links. But if an email appears to come from your friendly HR team, manager, or CEO, we are much more comfortable clicking on a link or opening an attachment.
Third, cybercriminals are getting more creative, and our security awareness engagements should too. More now than ever we need to imitate real-world attacks using the latest attack tactics, techniques, and procedures (TTPs). Had this been a real attack, if somebody had access to our email system, they would have known that the real security training email had gone out that day. And they could have easily distributed the exact email and captured many usernames and passwords. Our engagement was not far from how an advanced persistent threat (APT) would work.
Finally, as with many things in life, security is circumstantial. From a business perspective, it is important to understand your user base and change your security approach accordingly. Every company’s user base is different. Your security offerings, penetration testing, and training are all circumstantial based on the type of users you have. Account for organizational cultural norms when making security decisions.
Prioritize risk – while also moving the business forward
In my first three months as a CISO, there were outstanding tasks and projects to complete. To prioritize my focus, I took a step back and looked at what the risks to the business were. By prioritizing my tasks based on the biggest business risks, securing the business came naturally.
Every CISO should ask themselves, “How can I help make the business move faster, while staying secure?” This is an interesting question because security is almost inverse of being able to go fast. However, we have made great strides over the past 10 to 15 years where we can now have a level of transparency, while maintaining an adequate level of security. This allows for a frictionless experience where things happen fast in an organization, such as DevOps.
During my conversation with Nabil, he explained this well. He said, “Recently, I read something that really resonated with me. It took me back to the early days where we would say, ‘security is just a subset of quality.’ If you think about it that way, if we are doing quality correctly, security goes along hand in hand. Similarly, I think if you’re doing DevOps correctly, you shouldn’t need DevSecOps. If you’re doing DevOps correctly, security should be part of that process already. Security really needs to be frictionless and needs to focus on how to be secure while still enabling the business and enabling people to move ahead.”
Understand the business – and how it makes money
When I first became a CISO, the most valuable advice I received was, “you need to understand how the business makes money, that’s the most important job of a CISO.” If you can understand how the business makes money, then you’re able to protect the business’s critical assets and transactions.
And that’s exactly what I did when I came to MicroStrategy. I followed the guidance of my mentors. CISOs, especially first time CISOs, should have mentors to help them understand their role formally, hear real-world experiences, and learn what others have gained from being in a similar position. One book I recommend to any CISO is CISO Leadership: Essential Principles for Success from ISC². It digests the thought process behind the CISO role. The first half of the book explains the role of the CISO and the second provides real scenarios and examples of how CISOs dealt with different technology and security challenges.
The CISO role is really a business position, a leadership position. It is not about the tooling or the firewalls – your job is to reduce company risk. Different organizations have different appetites for risk. Once you understand that, everything else will fall into place.
On February 14, 2021, NetSPI President and CEO Aaron Shilts was featured in the Star Tribune.
Many cybersecurity firms hit the brakes quickly and laid off workers when the pandemic hit last year, throwing the country into recession.
Their revenue was disrupted as corporate and government customers put off spending decisions and adjusted to new ways of work, with most employees logged in from home.
But the work-from-home model just as quickly presented them new opportunities, and many were staffing up by summer to stay ahead of demand.
“Our business ended up growing and we did great,” said CEO Aaron Shilts of Minneapolis-based NetSPI. “Some of our smaller customers slowed. But our Fortune 1000 [clients] never stopped growing.
“In some ways it accelerated our business,” he added. “We used to have wait a month for a sales meeting. Now everybody can jump on a telemeeting. I do worry about long-term effects on collaboration. Humans need to work together to maximize the results.”
NetSPI, an enterprise-security tester and system-vulnerability manager, said it grew sales 35% for a fourth year in a row and is approaching revenue of $50 million. Its employs more than 200 workers around the country and expects to add up to 50 more this year.
The firm works with large banks and several units of the Department of Defense. Like its clients, NetSPI had to adjust to remote work.
“Internally, we try to over-communicate and stay in touch,” Shilts said. “People do lose energy when they’re just on Zoom. Most would like to be in the office some. But they mostly got the job done from home. I think the future is probably more flexibility.”
Media throughout the world have reported on the SolarWinds manual supply chain attack which has created concern about cyber security and software vulnerabilities among businesses and government entities alike. What hasn’t been in the headlines outside of the cyber security world is the need to not only plan and test for external threats, but CISOs must also start prioritizing efforts around abating insider threats. In the case of the SolarWinds attack, malicious code was inserted somewhere within the supply chain as part of a software update, which then was made available to all SolarWinds customers. This insider attack has to-date impacted hundreds of private companies and government agencies. CISOs must lead their organizations in preventing both external and internal cyber security threats.
Thwarting External and Internal Threats – A Two-Pronged Approach
Protecting against internal threats should be the first prong in a threat detection program. The SolarWinds breach brings to light this under-discussed application security challenge: developers writing malicious code which can later be exploited. And while this isn’t the only means that inside threat actors can wreak havoc on an organization, the frequency and financial impacts of insider threats—defined as a careless or negligent employee or contractor; a criminal or malicious insider; or a credential thief—has grown dramatically in just the past two years. In a recent Ponemon Institute study, the overall average cost of insider threats per incident increased by 31% from $8.76 million in 2018 to $11.45 million in 2020. In addition, the number of incidents has increased by a staggering 47% in just two years, from 3,200 in 2018 to 4,716 in 2020. This data shows that insider threats are still a lingering and often under-addressed cyber security threat within organizations, compared to external threats.
Thwarting external threats is the second prong of a threat detection program. As explored in-depth in our whitepaper, How to Build the Best Penetration Testing and Vulnerability Management Program, the reality is that cyber security breaches today from outside the organization are inevitable and put companies at grave risk. One of the key cyber security weaknesses is the lack of continuous penetration testing and patching. This can turn into the “Achilles heel” of any organization’s security posture if not addressed and implemented properly. Organizations should think of pentesting as the final security gate. It ensures all other security controls and applications are working as designed from a security standpoint, an approach that is not often adopted by organizations with young or immature application security programs.
Further, organizations with a mature security program understand that point-in-time pentesting is not the best option for securing their applications and networks. You cannot test yourself to be more secure. New code and configurations are released every day; a continuous penetration testing approach can help test an entire system in totality and delivers results to customers around the clock, enabling them to manage their vulnerabilities easier and more efficiently.
Now, let’s focus on the steps to take to prevent insider threats. To do so, I believe that CISOs need a shift in vision. Most companies prioritize external threats but give a blanket of trust to the people within the organization. Now, in large part because of SolarWinds, it is apparent that organizations have to change this mindset.
Changing Your Mindset Around Your Threat Landscape
Threat modeling needs to first be adopted more widely to understand the organization’s threat landscape. It is essential to identify who would want to attack a system, and where the assets are, in order to understand the appropriate attack vectors, and to best enable the appropriate security controls. In my opinion, this involves a mindset shift. The biggest change is in moving from only looking for vulnerabilities to also looking for suspicious or malicious code. Let’s define the two threats. With a vulnerability, the threat actor interacts with the attack surface in a way that exploits a weakness. With malicious code, the threat actor is either choosing or creating the attack surface and functionality because they have control over the system internally. So, instead of the threat actor exploiting vulnerabilities in the attack surface, now the threat actor creates the attack surface and exercises the functionality that he or she implements. Given that, threat modeling should study potential threat to both vulnerabilities and malicious code, as the harm from both could cost an organization millions. Doing one type of threat modeling without the other can set your organization up with a false sense of security.
Potential Insider Threat Exposure
Job Responsibility
Possible exposure area for threat activity
Administration or Operations
Local area network, high access credentials, production systems
Developers
Design and source code; Application configurations; Third-party libraries and deployment descriptors
Control Management
Binaries (susceptible to repackaging); Code promotion from QA to production; Encryption keys
Additionally, how you go about detecting a threat like the SolarWinds supply chain attack is vastly different from traditional pentesting, code review, or other vulnerability detection techniques. It not only requires a different type of lens on how you look at software to identify these issues, but it also requires a complete change in your organization’s internal threat detection governance process. Altogether, dealing with a threat issue once it’s identified is not as simple as going back to the developers asking them to fix them. Unfortunately, your developers could be the adversary.
Putting in Place a Proactive and Ongoing Internal Threat Detection Governance Program
To put in place a proactive and ongoing threat detection governance program you’ll first have to get buy-in from the leadership team. After all, at its core, malicious code review is a process where you theoretically treat those within your operations who have privileged access as threats. And secondly, you’ll need to educate the leadership team regularly on the scope of your malicious code review engagements. While finding malicious code is difficult and the probability is small, the risk of an insider threat is on the rise. In fact, Forrester research predicts that this year, 33% of data breaches will be caused by insider incidents.
Importantly, all of your malicious code review efforts have to be done in secrecy, involving only small teams you trust completely. It has to be a covert operation where you don’t notify or give knowledge to stakeholders in the software supply chain. They should never know that you are implementing a process to look through their code with a lens of trying to identify code that looks suspicious and potentially malicious.
Risk Scenarios and Escalation Steps to Take
Once your malicious code review regimen is in process and suspicious activity is detected, there are escalation steps that can be put in place to mitigate risk. Consider the following:
Suspicious, But Not Malicious: You find something that looks suspicious or malicious but that can’t be exploited, and it may have even be left my mistake. Escalation Step: In this case, you may do nothing.
Circle of Trust Invitation: You find something that looks suspicious, but you can’t get confirmation on whether it is malicious or not. Escalation Step: This is where you have to build a relationship with a trusted developer or someone from a developer organization who you can trust and can bring into your circle of trust to verify that suspicion.
Passive Monitoring: You’ve found suspicious code but choose a monitoring stance. Escalation Step:This is where you do additional logging in production or potentially add some type of data layer protection that you can trigger so you can passively monitor if there’s a point in time when someone is trying to exploit the suspicious line of code.
Active Suppression: You find suspicious or malicious code and work to suppress it. Escalation Step: This is where you actively either write a rule within your firewall, build a compensating function or do some type of dependency injection or weaving to actively stop that suspicious code from ever being executed.
Commencement of an Executive Event: You find malicious code and have identified its source, whether it be a sole insider threat, a whole team of suspicious actors, or find threats that involve a particular department, country or line of business. Escalation Step: This step has nothing to do with software, but it has everything to do with safeguarding your organization. You will need to involve your organization’s leadership and execute some sort of severe executive level event which could include terminations of implicated employee(s) or contractors and may even involve law enforcement.
A Caveat: Another challenge with supply chain attacks: they may never happen at the code level—they may happen in the process of a piece of code being elevated from development to production. Therefore, analysis both at the code level and also at the binary level is warranted to get information in artifacts from operations themselves.
Looking holistically at supply chain attacks, the security industry does not yet have a complete solution. Long term, we need to examine how the industry approaches the evaluation and risk acceptance of third-party solutions, which could come in the form of changes to compliance requirements around least privilege, auditing, and integrity checks.
However, with many studies and news reports pointing to a continuing rise in both external and insider threats—in number of incidences, time to contain, and cost implications – it’s essential for us to begin taking immediate steps as a part of the holistic solution. It’s imperative that CISOs advance leadership support in the development and implementation of a two-pronged threat detection and governance program that involves both malicious code review and vulnerability management initiatives. With breaches often costing organizations millions of dollars, there’s no time to waste.
On February 8, 2021, NetSPI Managing Director Nabil Hannan was featured in TechTarget:
Ransomware attack simulations, accessing enterprise logs and pen testing software code are among the best practices cybersecurity pros suggest following the SolarWinds breach.
Forensics teams are still investigating how hackers were able to exploit SolarWinds’ patching system to attack numerous high-profile commercial and governmental organizations, including Microsoft and the U.S. Department of Justice, as well as other customers of the security monitoring software vendor. At the same time, experts from a range of security service providers — including those offering penetration testing, vulnerability scanning and software code reviews — advise businesses to act now to shore up their own enterprise security.
The SolarWinds breach was first revealed in late 2020 — although the attacks may have begun in 2019 — and now includes the discovery of two backdoors created by malware. The first, named Sunburst, has been linked to numerous supply chain infections and nation-state attacks, and the second, named Supernova, is not a supply chain attack, but rather malware that required the exploitation of a vulnerability in the Orion software program recently patched by SolarWinds. U.S. government and cybersecurity experts are still uncovering the damage caused by the two infections.
Security service providers suggest the following list of five lessons learned to help organizations ward off or detect a SolarWinds-type hack. These best practices also lessen the “threat noise” across the enterprise, enabling a company to quickly identify and handle suspicious behavior.
Don’t rely on internal developers to test internally developed software
Developers should not have the final say on how secure their code is. They are not security experts, and they might be the ones who inserted malicious code, intentionally or not, according to Nabil Hannan, managing director at pen testing provider NetSPI. “To uncover a SolarWinds type of issue, you have to think differently than a developer would about what you are looking for, including who has access to your systems,” he said. “How can a developer determine another developer’s true intent for putting code in the system and how it will behave? He can’t.” Hannan recommended forming a group of trusted executives and senior managers to work with an external testing firm. When developers are done with their reviews or completed updates, the group sends it to the testers to look for malicious code and insider threats. “We examine the source code and binaries, looking at executables and comparing what is published versus what is in the source code,” he said. Testers search for backdoors, time bombs, Trojan horses and signature patterns. “If there are differences, we will report back to the group in a discreet way and work with them to mitigate the issues.” Hannan said having this practice and these controls in place are helpful when there is a management shakeup, a disgruntled developer leaves or a merger or acquisition is about to take place.
On February 9, 2021, NetSPI’s VP of Strategic Accounts Mary Braunwarth was featured in SC Magazine:
Security leaders, especially in highly regulated industries, are overwhelmed because their security decisions solely comply with audit and regulatory frameworks.
Many have to comply with HIPAA for healthcare, PCI DSS for credit card handling, and the Office of the Controller of the Currency and FDIC for financial services, leaving security teams fatigued and unable to innovate. Over time, their strategy mirrors their organization’s regulatory and compliance demands. This impacts the maturity of security programs and exponentially increases an organization’s risk, making it susceptible to cyberattacks and even nominal regulatory fines. For example, the Citibank incident, in which Citibank was fined $400 million for falling short in its regulatory-driven risk management processes.
Over the years, I’ve observed that security leaders lose control of their programs because they try to meet the ever-growing demands of regulators, line of business, expanding attack surface, and third parties – the list goes on. It’s critical for security leaders to drive an organization’s security strategy – not the second line of defense (risk management) nor the third line (auditors), nor regulators. After all, it’s the security leaders who inform executives and board members of the risk to critical information assets and how to manage it – and whose jobs are on the line.
My recommendation? Security leaders should pivot from their institutionalized regulatory and audit-driven security programs to one that focuses on both risk and compliance.
It’s simple in theory. Finding, fixing, and even preventing, vulnerabilities is a shared responsibility between security and development teams. That being said, silos still exist between DevOps and application security teams. DevSecOps – symbolically putting security at the center – is a great theory but is only effective if these groups work together to develop the people, process, and technology needed to be effective.
In fact, a recent Ponemon Institute Research report shows that 71 percent of AppSec professionals believe security is undermined by developers who don’t include proper security functionality early in the software development life cycle (SDLC). That statistic, to me, shows that there is a substantial divide between development and security teams, a divide that can (and should) be overcome. It’s not surprising, though, that these divides exist considering how teams are spread thinner everyday while aiming to increase release velocity. If we are going to solve these problems, we need to focus on creating human connections across teams, and a DevSecOps mentality will become not just policy, but also culture.
Come together by understanding motivations
In my experience, developers and security personnel don’t think that differently. They just have different incentives. Developers work to move through the SDLC quickly to get applications launched. Security teams, on the other hand, are incentivized to make the SDLC process as secure as possible, which is oftentimes viewed as slowing down progress by adding non-functional security requirements. If this is the viewpoint, it is no wonder that the groups may be at odds. Human relationships – even in the work environment – need to find common ground.
One of the best books I’ve read is Hit Refresh, the New York Times bestseller about the transformation happening inside Microsoft, from its CEO Satya Nadella. As Satya describes, “It’s about how people, organizations, and societies can, and must, transform and “hit refresh” in their persistent quest for new energy, new ideas, and continued relevance and renewal.” He is able to achieve this “refresh” he describes by being “out in the world, meeting people where they live and seeing how the technology we create affects their daily activities.” I believe in this philosophy and it has direct parallels to how we work in security.
Empathy for our colleagues and the relationships we develop with them is critical to achieving success within organizations because we can understand how the policies and procedures we develop impact their work and why the outcomes we expect often don’t materialize. Some may view empathy as letting people off the hook for not performing a specific task. But it’s important to connect empathy with accountability. By understanding the needs and incentives of our peers, we develop policies and procedures that are fair and transparent. Holding each other accountable is not only fair, but expected – as a result, security and development teams will uncover creative ways to collaborate to ultimately achieve overlapping goals, faster and with less friction.
Simple steps to start building a strong and productive relationship between development and security teams are:
Spend time connecting with people – A Journal of Experimental Social Psychology study reported in the Harvard Business Review that face-to-face meetings are 34 times more successful than email. This also provides a forum to develop a mutual understanding of each team’s incentives and mission. Or, if working remote, set up a video conference between security and development teams.
Creating processes together – Oftentimes development and security teams build processes separately, in a silo. Coming together at the start will help to develop realistic and cohesive goals, processes, and metrics. Further, each team can help to make the case for support, even financial or budgeting support, if necessary for the other team. There have been times in my career when I was able to secure additional budget or resources on-behalf of infrastructure or development teams to ensure they were able to support a specific security initiative.
“What do you need to effectively support this? I’ll do my best to include it in the project budget.”
In a ticket-driven world, cleanup is essential – Stacks and stacks of IT tickets notifying of vulnerabilities will never motivate an already stressed development team, especially if they are not deduplicated and remove false positives. Taking the time to clean up this process will show developers that the security team does not want to waste time, respects their SDLC counterparts, and wants to quickly get to the root of any vulnerability issues, particularly high-severity issues. Tickets are important for tracking and accountability, but let’s make sure we’re giving the right information, to the right person at the right time.
Leveraging automation, in combination with manual pentesting – An effective, reimagined AppSec program includes being able to manage manual penetration testing and secure code review augmented by automated vulnerability discovery tools that are deployed at various phases of the SDLC process. Shifting to this mindset will take collaboration and commitment amongst the DevSecOps teams.
“What tools make the most sense and how can we maximize the value of existing investments?”
“What is the roadmap for the development team and how do we ensure we can grow together?”
Bringing empathy to the situation to have credible conversations – Allowing openness and a safe space to say “I don’t know, but I’ll get the answers” will go far in building a strong DevSecOps team. At the end of the day, we’re all supporting the same business and striving for excellence. Let’s work smart, lead with integrity, and treat each other with respect to ensure we meet that end goal and, hopefully, have a little fun along the way.
It’s come to be expected that security is an emergent property of software. In fact, with Continuous Integration/Continuous Deployment (CI/CD) being adopted more and more, both development and security teams must come together, bringing empathy, accountability, and collaboration into the process, by working toward the same goal with transparency. When done, I’m confident that DevSecOps can become the norm.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Test
test.com
Testing
7 days
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.
Back
