It’s no coincidence that Halloween and Cybersecurity Awareness Month are both observed in October. Just as monsters, ghosts, and witches wreak havoc in our favorite Halloween movies, cyber adversaries haunt organizations across the globe with their increasingly sophisticated attack tactics.

There are three cybersecurity threats that, in my opinion, are the most frightening of them all: ransomware, work from home attacks, and software as a service (SaaS). Have no fear, not only will this article reveal the spookiest threats, but I’ll also share tips and best practices for prevention – no spell book required!

Beware of ransomware

By now, we can all generally define ransomware. It’s making national headlines due to its widespread impact in both the cyber and physical world. One of the more frightening aspects of ransomware is the uncertainty of the attack, specifically the varying attacker motivations.

Killware is an emerging ransomware threat in which the motivation is to impact critical infrastructure with the intent to do harm. In the case of Killware, they are not after money. It’s ransomware with no decryption keys. They want you to be down and stay down. For more, this USA Today article explains possible Killware scenarios and motivations.

It’s also a fluid and uncertain legislative and regulatory space. As it becomes more challenging to recover from a ransomware attack, payment is often the fastest way to get back to business. So, what happens if ransom payments become illegal? 

Ransomware attack outcomes can also vary significantly. For example, just because you pay, doesn’t mean you will get the decryption keys or access to all your data. Often, ransomware families blackmail organizations with stolen data to increase their financial gain. 

Ransom payments also fluctuate. Just this year it was reported that CNA Financial paid $40 million in ransom. And Palo Alto Networks found that the average ransomware payment climbed 82% since 2020 to a record-high $570,000 in the first half of 2021. 

Ransomware is a financial loss event and should be treated as such. It’s no longer the sole responsibility of cybersecurity and technology teams, finance, and others responsible for managing business and financial risk have a critical role to play.

Ransomware simulation assessments can remove some of the uncertainty surrounding these adversarial attacks. An attack simulation can benchmark how well an organization is positioned to detect, prevent, and defend against ransomware. Are your controls sufficient? Are your response teams effective? If there is a detection or response failure… can you recover? These are questions NetSPI’s Ransomware Attack Simulation service and AttackSim technology platform can help address.

Haunted by work from home attacks

The percentage of people in the U.S. working from home doubled between 2019 and 2020, according to the U.S. Bureau of Labor Statistics American Time Use Survey. Now more than ever, organizations are embracing flexible work environments and, with that, comes employees connecting to external WiFi networks.

Consider this: Each employee device is an extension of your corporate network. The workstation itself is provisioned and managed by IT, but beyond that, they do not have control over these devices. Home networks are a black box, even more so if you use a router supplied by your internet provider. More concerning are the uncontrolled connections (coffee shops, hotels, family member’s homes, etc.) that can serve as another entry point for an attacker to access the device.

Another factor to consider is the management of personal devices. Through the pandemic, we’ve seen a shift away from office phones and often people use their personal cellphones to manage their work. It’s the lack of control organizations have over these devices that is the most frightening.

The shift to work from home ultimately broadens an organization’s attack surface. But that is the reality of our workforce today. Remote work is here to stay in some capacity and infosec teams are tasked with creating security tactics and policies to ensure business continuity and productivity… simultaneously.

To address work from home security challenges a focus on endpoint security is critical, particularly for devices not inside the ‘walled garden’ of your corporate network. Network penetration testing can help you identify the right level of protection and telemetry for your endpoint controls.

I also anticipate technology innovation in the attack surface management space to help infosec professionals tackle the many challenges that accompany a remote workforce: asset management, shadow IT, bring your own device (BYOD), and more.

Software as a Service (SaaS) in the shadows

Add to that the fact that organizations use an average of 110 SaaS applications, according to the 2021 State of SaaSOps report, and there’s a real issue with SaaS visibility and security. The adoption SaaS platforms has increased given its ability to enable remote work, create workflow efficiencies, and collaborate (see: Zoom, Slack, Teams, Wrike).

SaaS adoption requires you to examine the security of your extended attack surface, but its footprint doesn’t receive the same level of shared responsibility as infrastructure as a service (IaaS) or cloud environments. We put a lot of trust into the security of SaaS providers today, however, these applications present many interesting security challenges.

Most people connect direct from a managed device to the SaaS platform without going through a secure corporate network, which creates authentication and identity and access management (IAM) challenges. For example, are you requiring SSO or multi-factor authentication for SaaS platforms? How do you ensure authentication best practices for SaaS applications outside the corporate network? 

SaaS platforms are a critical component of our workflow today and contain troves of sensitive data. With the rapid adoption of SaaS applications today, it is important for security teams to align and communicate SaaS security policies within their organizations and ensure secure configuration of SaaS platforms. To strengthen security, SaaS security posture management is key. 

Defined by Gartner in the Hype Cycle for Cloud Security, SaaS security posture management (SSPM) is “tools and automation that can continuously assess the security risk and manage SaaS application security posture.” This could include continuous monitoring and alerts, configuration review, comparison against industry frameworks, and more.

For a detailed conversation on SaaS posture management, CEO and Co-Founder at Adaptive Shield Maor Bin joins us on the Agent of Influence cybersecurity podcast next month. Tune in!

Being a cybersecurity leader is not for the faint of heart. The increasing sophistication of adversaries and number of successful breaches puts significant pressure on security teams today. For advice, I invited Pacific Northwest infosec leader David Quisenberry to join me on the Agent of Influence podcast, a series of interviews with industry leaders and security gurus where we share best practices and trends in the world of cybersecurity and vulnerability management. 

During our conversation, David shared four ways he’s approaching cybersecurity leadership today by:

1. Tapping into his wealth management experience.
2. Collaborating across the organization.
3. Working closely with his local security community as the president of OWASP Portland, Oregon.
4. Creating a solid network of mentors.

Continue reading for highlights from our conversation around wealth management, collaboration mentorship, OWASP Portland, and more. You can listen to the full episode on the NetSPI website, or wherever you listen to podcasts.

Can you tell me about your career transition from wealth management to cybersecurity?

David Quisenberry: The decisions you make, the careers you go down, the things you do – everything’s interrelated and connected. There are some differences, but there are also a lot of similarities. In wealth management, you deal a lot with risk tolerance. Like companies, when someone is just starting off as an investor, they don’t have a lot of money and they’re much more willing to take on risk and do things that a more established person, family, or trust might not do with their money because they have a fiduciary standard to make sure that they invested wisely for all the beneficiaries. 

Again, like companies, when they’re building out their foundation of revenue, security may not be as front and center to a lot of the decisions that get make. But as companies grow, a lot of enterprise corporations view security and risk tolerance much differently. They want to understand all the risks that go into each decision they make as a business. Risk tolerance is a similar theme. 

Another thing that’s very similar between the world of wealth management and the world of cybersecurity is you’re always reading, always studying. As a wealth manager, you’re constantly keeping up to speed on all the trends with global investment flows, global economics, and mutual funds. That obviously translates into the security world where you’re reading and learning things all the time. 

Lastly, convincing others to take action. As a wealth manager, there’s this tension, especially if you’re working with families where you want them to save as much as possible so that they can have a lot of money in retirement for their kids, for their charities. They care about their future self, but they also want to live life. There are these tensions, and you have to convince someone to spend their dollars one way versus the other. This is very similar to security work with developers, product owners, product managers, et cetera. It’s a constant game of understanding all the various priorities and working together to identify that sweet spot of paying security debt, staying on top of future security debt, as well as getting other features built to drive your business forward. 

You are taking some unique approaches to better collaborate across different teams within your organization. Can you share with us the approach you’re taking? Are there things that worked well or not?

David Quisenberry: One of the philosophies I have about most things is “relationships first.” As an information security manager, I’ve tried to take the approach of being available and approachable. If somebody sends me a question or an email, most of the time I will drop what I’m doing so that I can answer them in that moment. Even when people get frustrated with me, I take the opportunity to take a step back and think, “We have a tension right now. But they’re thinking about security. What’s not clear? How do I communicate the why?” If I can accurately explain the why, it’s going to help so much. I try to take that relationship first approach, identify those early wins, and set clear expectations of what is a milestone and then celebrate those when we hit them.

It’s important to have regular monthly meetings with the scrum masters with the various leadership teams for the different products, engineering managers, project managers. I encourage them to ask questions and know that we’re going to have an opportunity to dig into things. To prepare for those meetings, we have a working agenda that both parties can add to, and I also try to give visibility into data and analytics. 

As the president of the OWASP chapter in Portland, how did you get involved with the community? And what are some interesting things that you’re doing that might be different from other chapters? 

David Quisenberry: David Merrick introduced me to the chapter. I started going to the chapter meetings whenever I could. Around late 2018/2019, I started being mentored by the previous chapter President, Ian Melvin, who’s been an amazing mentor and really helped me along in my progress. He got me more involved on the on the leadership side. 

What I found is most OWASP chapters have leadership that have been laboring hard for a long time to keep the chapter going. If you’re willing to help bring in speakers, engage in membership, promote social media activity, or think of topics to present, they’ll open up. Especially if you prove yourself and that you can deliver on it. What I found with the Portland chapter was that, as I started getting involved, we needed to meet developers where they’re at. 

We did a lot early on when I took over as president of the Portland OWASP chapter. We built out a mentorship program where we had around 24 people with varying skill levels meeting regularly. We really ramped up our social media presence, specifically Twitter and LinkedIn. We used meetup.com which helped us solidify returning visitors and provided an easy mechanism for people to RSVP to our monthly meetings. By the end of 2019, we were close to 50-60 people per meeting. And we brought in a lot of great speakers. 

And then then COVID-19 hits, and suddenly you can’t meet in person anymore. We had to do everything virtually, but we were able to continue our path of monthly, or bi-monthly meetings. We also have another thing that we do as a local chapter, which is study sessions. More hands-on, shorter sessions or labs and then 40-minutes hands on keyboard. Working with Burp Suite or Wireshark. You name it. We started a podcast in late 2019 and that’s been super successful. We had 6,500 listeners or so over this last year and some interesting guests. We’re also exploring some other opportunities for cybersecurity training with other chapters. We’ve been trying to collaborate more with the chapters around us and that’s been going quite well. 

NetSPI’s Portland, OR office is growing. Check out our open cybersecurity careers in PDX!

I wouldn’t be where I am today without my involvement with OWASP. If you’re interested in truly excelling and expanding your horizons in the security space, these community meetings and chapters really pay dividends in the long run. I’d be curious to get your perspective on any guidance you have on how to choose a mentor that’s right for you?

David Quisenberry: The first thing I would say is don’t have one mentor. And I think of it almost as a personal board of directors. For myself what I want is people from across the spectrum. So, business leaders, engineering leadership, security leadership, different types of security leadership. I want 4-10 people that I talk with quarterly, some people more often. I want to be able to have multiple perspectives to bounce ideas off when I’m having a hard time with something at work or a moral decision I need to make or just trying to understand what is normal or what is acceptable. 

One of the big things that I always try to push with my mentors is what are you learning? What are you reading? What are the things that you go back to time and time again? There is a saying that I always think about: “If you dig, you get diamonds.” Where can you dig to get diamonds? With mentors, I try to have a lot of people, I try to be real with them, and make it clear that this is only between us. And I also try to pay it forward. I want to help people and lots of people have helped me. 

There is a book by Keith Ferrazi I read a long time ago, it’s called Never Eat Alone. It’s all about how people like to help people. We’re all hesitant to ask for advice or ask for help. But the most successful people ask for help all the time. As humans, we like to help each other. His whole thing is to find out what you want to do and where you want to get, and then build a relationship action plan to move your way there. He’s also big on building your network before you really need it. If you’re in a job hunt, and you’re trying to build your mentorship, or mentor platform at that point in time, that’s going to be hard to do. But if you’re in career, and you start building that network, and you don’t need to use it for a couple years, by the time you do need to use it those people will know that you’re genuine and know who you really are. They’ll be more than willing to help you. 

For more, listen to episode 23 of Agent of Influence. Or, connect with David on LinkedIn or listen to the OWASP Portland podcast.

For those engaged in the timely production of high-quality software, threat modeling is an invaluable method to minimize rework. Design defects can include useless code, or “cruft” and can be costly to fix. But the manual process of threat modeling doesn’t always fit well into ever-tightening iterative development methodologies. 

Fortunately, our industry is making big strides in the direction of automating threat modeling. I’ve explored as many of these tools as I can while looking for something that works best for us here at NetSPI. While I’m quite optimistic about the very near future of threat modeling automation, I’ve got my reservations. These reservations can be generalized as conjectures. 

If you are buying or building threat modeling automation, here are three conjectures to take into consideration.

Conjecture 1: The Only Automation is Semi-Automation

Don’t expect to run a threat modeling process entirely free of human care and attention. No matter your methodology, threat modeling operates on ideas about software – and the outputs of threat modeling are other, better ideas about software. Completely automating the improvement of these ideas requires expressing them in a useful format and yielding the resulting better ideas in a format suitable for implementation by another automated system. 

You see where this is going. 

It also requires producing genuine improvements which would unquestionably result in a better system overall: error free output.

So, let’s consider how semi-automation is a more realistic expectation than full automation by looking at this input-process-output (IPO) model in more detail, from bottom to top.

Automating the Outputs

The results of a threat modeling assessment do not need to be consumable as non-functional requirements (NFRs). They can inform coding standards, product roadmaps, build procedures, test plans, monitoring activities, and more.

For example: let’s say the consumer-grade IoT device your team is building requires customizations to the kernel level containerization system for OTA updates. Your product manager sees this as an indicator of how cutting edge this device is compared to the market, while your architect sees this as a necessary annoyance. But what the threat modeler sees is an unmanaged attack surface, accessible from the network, written in C, executing in Ring 0. 

What can your team do with this information, besides draft security requirements? Adjust your static analysis strategy? Amend your vendor management boilerplate to mandate relevant training? Whip up a fuzzing protocol? How many of these represent automatable opportunities? 

Threat modeling is a decision support process. You can automate aspects of it, but you’ll be limited by the amount of decision-making that is automated.

Now, you may have scripts available to automate the creation of backlog items—Jira tickets and the like. Keep in mind that 90 percent of all security tooling outputs are false positives. Threat modeling automation systems make no promises of being any different. So, you can either devote human care and attention to triaging the results, or you can let the implementation team do the triage work themselves. Either way, there’s still work to be done.

Automating the Processing

Threat modeling is a security process, and security is one of many aspects of quality. We used to think of the interaction between security and the software development process as one of trade-offs. Perhaps some still do. 

Many organizations are beginning to approach their going software concerns by finding an optimal balance considering known limitations. It isn’t security versus usability. It’s making sure our products are suitably usable, secure, performant, testable, resilient, scalable, marketable, et cetera.

So, your turnkey end-to-end threat modeling automation has to be able to recognize and accommodate other requirements in terms of the product’s usability, reliability, marketability, scalability, et ceterability. If it doesn’t, it will fall to you to strike the right balance. And if you’re the one striking a balance, you don’t have a fully automated system. 

Automating the Inputs

What tools do your security architects use? The ones I work with mostly use whiteboards. Many use team collaboration / CMS software like Confluence. Some use drawing tools like Visio. Does anyone still use Rational Rose?

If your threat modeling automation can meaningfully parse this information, great. If not, and you have to reproduce the architect’s design, then you won’t achieve full automation. 

Otherwise, what inputs can be automatically fed into your threat modeling tool?

Automatic scanning of Infrastructure-as-Code files can bring to light threats to the infrastructure. They may not have much to say about the actual software, though. And automatic code scanners tend to ignore those values of quality that I enumerated above. 

Finally, threat modeling tools that scan implementation artifacts often lack efficiency. You’ve already built to your design. Any findings produced by a scanner are opportunities for rework, and as I said at the beginning, threat modeling is supposed to minimize rework. 

Conjecture 2: Your Tool’s Diagrams and Your Team’s Diagrams Should Be Compatible

Whether your tool consumes or emits them, diagrams of the subject system must be recognizable by the implementation team as being a genuine, faithful reflection of the values of that system. Tools that invite you to re-invent or re-think the system’s architecture in a new schema tend to miss the mark.

This is not to say that re-diagramming is always problematic. Architecture diagrams must reflect the values of the organization, such as structure, redundancy, symmetry, priority, urgency, or flow. This helps them present the system—especially its attack surfaces—naturally. Automatically generated diagrams tend to disregard these values.

Conjecture 3: Your Tool’s Guidance Should Be Delivered with Humility

As mentioned earlier, threat modeling operates on ideas about software and its outputs include better ideas about software. The best tools and techniques will lead the threat modeler to the best ideas, faster.

But architecture works with abstractions about systems. Lacking a complete architecture description, any threat modeling tool is working on incomplete input. And who has time to produce complete architecture documents?

Have you seen a 300-page architecture document? Probably. But have you ever seen a 300-page architecture document that was up to date?

The problem arises when a threat modeling tool can’t adjust to the subtleties of your software. If a tool mistakes design elements for threats, you’ll be required to spend time adjusting its output.

Sometimes your tool will just be wrong through no fault of its own and it is easier to ignore the tool than to correct it.

Your Threat Modeling System Shouldn’t Be Repudiating Raisins

Some design intricacies are difficult to articulate. Consider the ‘R’ in STRIDE: Repudiation.

The Orange Book lists accountability as a fundamental requirement of computer security:

“Audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party. A trusted system must be able to record the occurrences of security-relevant events in an audit log. The capability to select the audit events to be recorded is necessary to minimize the expense of auditing and to allow efficient analysis. Audit data must be protected from modification and unauthorized destruction to permit detection and after-the-fact investigations of security violations.”

Clearly, the non-repudiation of audit logs is an important aspect of a system, and conventions around logging should be designed to be of adequate depth and granularity, and resilient against forging and deletion. 

But what’s true for audit logs isn’t true for every single aspect of every single software product. 

Suppose you were threat modeling a smart appliance, like a smart toaster. We want to make a simple change with little security impact, perhaps extending its capabilities to allow it to handle raisin bread. What are our repudiation concerns? What does that mean? Someone fakes a raisin? The question is trivial, and pondering it is not a great use of time.

A little time spent deciding what actions really warrant logging is time well spent. Applying a blanket repudiation standard to every system element, on the other hand, is tedious. By extension, tools that alert to every form of threat every time you make an adjustment to your architecture are tedious. A tool should be able to measure the threat at the proper scale. Tool output should be non-punitive.

Threats Can Be Features

Moreover, sometimes repudiation is not an attack but a feature. Consider repudiation in the following system contexts: ballot secrecy, civil-rights-related anonymity, digital cash, drive encryption.

For these systems, the implementation of some non-repudiation controls is antithetical to the business goal of the system.

Similarly, many systems offer user-impersonation features for support purposes, basically spoofing-as-a-service. Such functionality needs to thread a tight needle of security attention. Uniformly treating all forms of spoofing as threats is incorrect. 

Should tooling let users treat threats as security features? Maybe. These are edge cases. Perhaps this is a nice-to-have. It would suffice to have a tool treat its recommendations as suggestions for consideration.

Final Thoughts

Threat modeling is a time-consuming process and deserving of as much automation as we can throw at it. The teams making the current generation of tooling are right to be proud of their products. But these tools have limitations to be kept in mind, whether you are building or buying them.