Steve Wilson is the Chief Product Officer at Contrast Security, with over 25 years of experience developing and marketing products at multi-billion-dollar technology companies such as Citrix, Oracle, and Sun Microsystems. In this AMA, Steve tells us about serverless security, application security in the JAVA ecosystem, SBOMs, and best practices.
This Slogging thread by Mónica Freitas, Steve Wilson, Zach Taylor, Victor de Avila, Jack Boreham and Sara Pinto occurred in slogging's official #amas channel, and has been edited for readability.
Hey @channel, please join me in welcoming our next AMA guest, Steve Wilson. Steve is currently the Chief Product Officer at Contrast Security. Today his team is responsible for Engineering, Product Management and Product Design for all products.
Steve has over 25 years of experience developing and marketing products at multi-billion-dollar technology companies such as Citrix, Oracle and Sun Microsystems.
Prior to Contrast, Steve was the Vice President of Product Management for Citrix Cloud where he led the transformation of Citrix products from traditional on-prem to SaaS.
At Oracle, he led core engineering for a billion-dollar product line of systems management software. During his time at Sun Microsystems, Steve was an early member of the team that developed the Java computer programming system, the most widely used set of software development tools in history.
Please feel free to ask Steve anything about:
- What Is Serverless and Why Is It Important?
- How Serverless security is different—Current Threats and Dangers
- How to Address Application Security in the Java Ecosystem
- What are SBOMs and the latest Software Security Standards I should be aware of?
- Best Practices to Bridge the Divide between Developers, Security and DevSecOps
Hi Steve Wilson! It's great to have you with us! Could you start by telling us a bit about your background and how you came to work with Contrast Security?
Hi Mónica Freitas! It’s great to be here. I’d like to start off by first thanking HackerNoon for having me join their AMA and I look forward to answering your questions.
I am the Chief Product Officer at Contrast Security, a leader in application security that empowers developers to secure-as-they code. Our platform provides developers with self-service security solutions to improve efficiencies throughout the entire software development lifecycle while also protecting applications from vulnerabilities pre-, during and post-production. I leverage my 25+ years of experience in developing and marketing products to lead my teams who are responsible for the engineering, product management, and product design of all products at Contrast.
2 fun facts about me:
- I have a second-degree blackbelt in Taekwondo.
- I enjoy playing classic rock tunes on the guitar.
Feel free to follow me on Twitter
Thanks, Mónica Freitas, happy to talk about how I came to Contrast!
I joined about 18 months ago after stints at large companies like Citrix, Oracle and Sun Microsystems.
I've worked in individual contributor and management roles in both Engineering and Product Management, going all the way back to my days as an early member of the Java team in the late 90s. Happy to answer questions about early Java/Sun trivia if people are interested. 🙂
Quick story though about how I came to Contrast.
In my previous role, I got into a situation where a team of hundreds of engineers got completely derailed by a security team running a bad "code scanning" product. It generated huge amounts of technical debt for us (that we were required to address), but led to almost no improvements in our security posture. It slipped schedules and created huge frustration. Joining Contrast, I realized there was a better way to do that!
Hi Steve! Can you explain what serverless is?
Thanks, Zach Taylor! Serverless is one of those terms that means a lot of things to a lot of people, so let's break it down. In essence, it's a set of technologies that are designed to make server-side computing more efficient and simpler. One usage of the term is about the idea of abstracting away the heavy-weight concept of a "Virtual Machine" (ala VMware) and instead of using lighter weight, scalable constructs like Docker Containers and Kubernetes. However, I think there's a much more interesting movement going on inside Serverless...
The biggest revolution in 20 years for application architecture is Functions as a Service. The most popular example of this is Amazon Web Services (AWS) Lambda -- although other clouds like Microsoft and Google have added similar constructs. In the same way that Java Servlets were a massive improvement in web architecture vs. the "CGI" that came before it, Serverless functions can be 100x faster and cheaper than traditional architectures. These functions don't fun all the time, they're more "event-based" and run only when needed. You see these being used in places where massive scalability and low cost are critical. Internet of Things (IoT) applications where you might be sending data from thousands or millions of devices back to a data-collection service. This is really exciting stuff.
That is very exciting for developers! And when you mention IoT, sounds like it opens the doors to a lot of different use cases.
How is serverless security different, from say, traditional application security?
Great question, Zach Taylor! There are a lot of differences!
On the "plus" side, you lose a whole lot of things you can "not" worry about. You don't need to worry about having an Operating System or even an AppServer you need to patch. All that "disappears" underneath you. Some version still exists somewhere, but you don't see or manage them. That's a big plus from a security perspective!
However, on the "caution" side, your code for your app will look REALLY different. In fact, you should assume your code AppSec tools (like your "code scanner") don't work at all. All the entry and exit points are different so your logic flow is different. You need entirely new AppSec tools to ensure you're able to spot OWASP Top 10 type vulnerabilities (which all still exist).
In fact, OWASP has a whole specialized Top 10 list for Serverless that is worth checking out.
So, you still have two big things to worry about that your AppSec tools need to help with: vulnerabilities in Open Source code you bring, and vulnerabilities in custom code you write. However, there's also a new item to worry about which is your Identity and Access Management (IAM) permissions on each function. It's a critical piece of keeping your code secure when it's running in the public cloud, but it's painstaking to do by hand. Better make sure you have a tool that can automate that for you.
Wow, that is very insightful! So despite the tradeoffs (pros and cons of both), overall it sounds like automation is a key component in filling in the gaps? That OWASP Top 10 looks very interesting, I'm definitely going to dive deeper into that—thanks for sharing!
Hi Steve! If an organization considers moving to serverless/cloud-native environments, what are the most immediate threats/dangers? What should security teams keep in mind to improve protection?
Hey, Victor de Avila, great question! While serverless technology eliminates many of the security responsibilities for underlying technologies, developers are still on the hook for securing serverless functions. If code is written in an insecure manner, the application can still be vulnerable to traditional application-level attacks, like Cross-Site Scripting (XSS), Command/SQL Injection, Denial of Service (DoS), broken authentication and authorization, security misconfigurations, and many more.
Not only must security teams deal with common vulnerabilities and exposures (CVEs), or risks associated with open-source libraries, but serverless environments also introduce threats driven by broken access control, particularly when developers need to add permissions to support the necessary functionality. In this situation, the developer is often instructed by the security team to select from a list of predefined permissions that provides more privileged access than is necessary.
A good automation process could be a great opportunity for a least-privilege application – something that was impossible at that level before. However, automating this process at scale, in an accurate and fast way is not easy.
In a serverless environment, the attack surface also increases as deserialization attacks are more common, and auditing and monitoring are more difficult than in traditional applications. As a result, organizations need to follow least privilege principles and ensure strong access controls to reduce the attack surface and ensure only authorized individuals can have access.
Similarly, DevSecOps teams should also be mindful of “sprawl” within serverless functions. Functions can have multiple versions, in different regions and on multiple accounts, making it hard for management and security teams to understand the overall size of the serverless inventory at the organization level. To address this, they will need strong asset management controls relevant to both cloud infrastructure and serverless.
Finally, teams should consider their library permissions. While it is not different from regular application security, the functions tend to have a lot of dependencies. Additionally, in some cases, even if the code seems clean, the infrastructure (such as IaC) can introduce more libraries at the deployment time, leading to missed 3rd party vulnerabilities. DevSecOps teams should enable strong security processes with a critical eye for these serverless-specific considerations.
Hi, Steve Wilson! I would love to know about your time working at Oracle. What did you do over there?
Hi, Jack Boreham, thanks for asking! I was at Oracle for about 3.5 years from 2010 to 2013. During that time I was "VP of Core Engineering" for the Enterprise Manager team. This was Oracle's suite of management tools for their entire portfolio (from hardware to hypervisor to database, middleware and apps). It's a job where I learned a lot about working at scale (my team was around 500 people split between North America, Europe (France and the Czech Republic) and India. Oracle had a strange corporate culture, but a very disciplined engineering culture (having started with the Oracle DB). I learned a lot about testing and driving quality there.
But, just to elaborate, I joined Oracle when they acquired Sun Microsystems. I actually joined Sun in the mid-90s as a coder working on the Java Developer Kit where I got to work with all sorts of smart people like James Gosling (and many others who've become famous programmers and built awesome things). I started working on the Java GUI Toolkit and then went on to become the first full-time Performance Engineer for Java. In fact, I wrote a book about it. I'll provide a link just for fun, but it's super out of date and I wouldn't suggest anyone read it now! 😉
I moved into management and led the NetBeans IDE team (my favorite job ever, BTW) and then Sun's Virtualization and Systems management teams. Let me know if you have more questions about any parts of this. Lots of fun stories about Sun/Oracle.
Steve Wilson that's a great journey!
What challenges have you faced in your role in Contrast? And what do you mean by self-service security solutions? Do you have an established set of security solutions and any company can just pick what best suits their need? Is it possible for businesses to ask Contrast for tailored solutions?
Mónica Freitas, thanks for asking about Contrast! Contrast is a company that specializes in tools to help developers build secure applications. A lot of people think about things like Network, Identify or Endpoint security tools when they consider security (and that's important), but what are we all trying to protect from hackers? It's really about our applications and the data they're storing for us. That's why application security is so important and those are the tools Contrast builds.
We have what's called a Secure Code Platform. It includes many technologies to help developers and security teams. This includes source code scanning (SAST), instrumentation that can test your app from the "inside out") IAST, runtime protection (RASP) that can actually neutralize attackers trying to exploit zero-day vulnerabilities. Recent examples are things like Log4J and Spring4Shell. And finally, we recently introduced the world's first security tools for cloud-native Serverless code. We'd be happy to talk to people about the best options for how to create a DevSecOps program that will allow them to maintain their development velocity, but also ensure their code is secure.
You can reach out for more details here.
Mónica Freitas, on the topic of "self-service" security... Self-service security solutions refer to the ability for developers to leverage Contrasts tools on their own and use them how they best see fit. This means that developers and DevOps teams can get just the tools they need to get the job done and can find and fix vulnerabilities with minimal security training (or constant oversight from a dedicated Security engineering team). As for asking Contrast for tailored solutions, absolutely. Our team is able to guide teams on what will work best based on their objectives as well as long-term and short-term needs.
Steve Wilson, what are the most common security issues you've seen and what steps can companies take to solve them?
Mónica Freitas, thanks for the question about the most common security issues. I'm going to steer clear of things like phishing and bad passwords (since that's obvious and well-trod ground). Instead, I'll focus on problems creating secure applications. There are two main things you need to look at: securing the code your write and securing the code you use that someone else wrote (usually open-source).
With the code you write, there are a pretty large number of vulnerability types that are classified. One of the most common (and most serious) is called an "injection" attack. This means that an outside entity (a hacker!) is able to put data into some part of your system in a way you didn't anticipate or intend. These can be things like a "SQL Injection Attack" where a hacker is able to put a piece of database query language into your database and execute it remotely. This is really common and has been a top problem for 20 years. Another one that was often thought to be less serious is "Log File Injection" where a hacker is able to drop tainted data directly into a log file of your app. Sounds like it's not too bad, but this was at the heart of the recent Log4J security incident that impacted so many companies back in December/January.
As for open-source code, we know that a majority of the code in modern business apps isn't even written by a company's developers. It's open-source. It's open to all sorts of attacks and while open source does provide a solid foundation for secure code by having many eyes on the code, many of those eyes are now hackers (from students to nation-state hackers). Some of these libraries (like Struts, Log4J, Spring) are so popular that they're embedded into millions of apps around the world. A few years ago, the credit rating agency called Equifax was using a vulnerable version of Struts and lost the personal financial data of hundreds of millions of Americans. They were fined over $400,000,000 dollars as a result. This is serious.
The best way to handle both of these problems is to modernize your dev practices to include automated tools that help you detect and remediate these types of issues. Contrast's secure code platform works with Java, JavaScript .NET, Go, Ruby, Python, Scala & Kotlin so if you're using any of these popular technologies we'd be happy to help you modernize your tools and build a program around automating all of this.
Hey Steve Wilson! I'm curious, what are SBOMs? Can they impact security systems?
Sara Pinto, thanks for asking about SBOM. Such an interesting and topical area right now! This is really a part of the larger topic called Software Supply Chain Security. As noted in some of the other questions on this thread, much of the code in modern apps isn't written by a company's own developers. It's from a third-party (often open-source). A little while back, a software vendor called Solar Winds was hacked. That was bad for solar winds, but what was worse was that the code Solar Winds built was embedded into cloud and data center environments of many other companies and even governments.
Knowing this, the hackers who attacked SolarWinds didn't just steal from SolarWinds, they used the opportunity to place back doors into SolarWind's software that would then be embedded by many other companies. The exploration was massive and it led to the idea that you must keep track of your own code, but also the code you're getting from elsewhere. The whole process must be secure from end to end and that's called Software Supply Chain Security.
SBOMs stands for the software bill of materials. An SBOM is a list of all the open-source and third-party components present in a codebase in addition to all the licenses that govern those components. Think of it as the nutrition labels on the side of a food box. It helps a consumer know what's in the food so they can use it to ensure the food is safe and healthy for them.
SBOMs can create more transparency in the software marketplace and also allow developers to act quickly if a vulnerability has been identified. The recent Cybersecurity Executive Order stated that SBOMs should be required and the NTIA released a "Minimum Elements for a SBOM" for SBOM must-haves, and many of these points were only further emphasized in Biden's recent Statement on our Nation's Cybersecurity and accompanying Fact Sheet.
Furthermore, Gartner predicts that by 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice. While these are great first steps to securing modern applications—including serverless—developers and security teams are still on the hook to keep their applications secure, and that responsibility falls on DevSecOps teams.
Steve Wilson, as Web3 develops, do you consider the possibility to create security options for web3?
Mónica Freitas, thanks for the question abound Web3 security. This is a FASCINATING topic and a pretty broad one. I'll try to add my perspective. First, we have to define Web3.
In popular culture, the idea of Web3 is dominated by trading strange pieces of digital art. There are constant discussions on Ponzi schemes and fraud. But I think the concepts of Web3 are fascinating.
When you strip it all away, Web3 is a bold set of attempts (and I'm sure many will fail) to rebuild much of the internet from scratch. Why do we need to do that? Well, it's really about security and trust!
The internet and the world-wide-web that sit on top of it were built by academics for academics. They were meant to open information, advance science and technology and promote the exchange of ideas. In that sense, the internet/web is the most successful endeavor in human history.
However, because of its nature, it's missing a key concept - trust! How do I know who you are? How do I know what you own? How do I know what you're entitled to? None of that was built into the internet at the start. Everything that's layered on top of that is fragile and centrally controlled. How do I know what you own? I ask your bank/credit card company. How do I know who you are? Wow, that's an almost totally unsolved problem on the internet to this day!
Web3 tends to start with the concepts pioneered by Bitcoin/Crypto-currency - with Blockchain at its core. About four years ago, I found my teen daughter and her friends were using free VPN services to tunnel through the high school firewall so they could watch Netflix at school. Rather than be mad, I found it a great way to open a conversation with her about security and cryptography (NERD DAD ALERT!). We somehow wound up embarking on a fabulous adventure mining Ethereum and learning about Blockchain. You can read about some of our adventures here.
This led me personally to really dive into how the Blockchain worked. In some ways, it's a computer science marvel, and in some ways, it's an engineering nightmare, but it pioneered a new set of concepts in how you do distribute trust without a central authority. This is the core of web3! How do I know who you are and what you own (in a certain context) without a third-party institution in the middle telling me?
If you're interested in reading my thoughts on the good and bad of blockchain you can check out this article. It's a few years old, but the core concepts here are moving slow enough that it's all largely relevant to the discussion.
So, now let's get down to brass tacks! What would I tell someone looking to dive into web3 security?
First, there are high-profile instances of security failures in smaller blockchains. Blockchain trust is usually based on consensus voting and if you don't have critical mass, then someone can own more than 50% of the votes and you're in trouble. However, I don't think this is the most important topic for developers looking at Web3 today.
When I look at the big security incidents around Web3/NFT/Crypto in recent years, they're not related to the core blockchain. They're around the Web2 parts of a company's code/infrastructure that still glues the world together. The Web3 play, in the very long-term (think in terms of decades) play, is to replace the underpinnings of the internet with things that include trust as a core component. That may happen, and it's laudable, but it's a long way off.
Today, we have things like IPv4/6, SSL, HTML, JavaScript, REST, AppServers, open-source libraries and SQL databases that hold the world together (with islands of blockchain/web3 technologies). If you're running an NFT exchange (or something similar) then I'd spend as much (or more) of my time worried about the Web2 part of my world that is the glue between me and my customers/partners. It's susceptible to all the same application security concepts we've talked about before here. You need a GREAT DevSecOps program and platform. And most of it should look similar to a credit card processor or a major bank. Contrast can help here.
If you can harden your Web2 "glue" to the same level as a major bank, then you can spend your time worrying about how to differentiate in the Web3 world. It's exciting times. I can't wait to see how this develops.
Let me know if you want to talk more on this topic. I'd love to chat!
Steve Wilson, I'm new to all these Software Security Standards. Could you elaborate on them? What should I know about this?
Sara Pinto, thanks for the question on Software Security Standards. Wow! You just hit on a really big and important topic.
There are broadly two types of standards: Contractual/commercial and Statutory. Commercial standards are things that will help you do business. Adhering to one of these standards might be written into a contract. For example, your customer might require that you adhere to a standard called SOC2 and are regularly audited to demonstrate that.
On the other hand, in order to sell Cloud Computing Services to the US Government, you must adhere to a set of standards called FedRAMP (that's "by law" so it's considered a statutory requirement).
Both of these examples are interesting and important if you're running a software/SaaS company. However, for individual developers, they are really abstract. For example, these standards include lots of items well beyond just "software". A good example would be, do you have sufficient background checks and basic security training for all your employees?
For software developers, there are finer-grained standards that get much more into the details you might want to worry about. Here's a partial list of fun things to go start exploring on your journey! Note that some requirements are technical and some requirements are the processes that you use to build software.
Cybersecurity Executive Order 14028
- High-level statement of the importance of appsec and directives to various agencies. Emphasizes Zero trust, application security testing, SBOM, transparency, labels
PCI SSF (Replaced PA-DSS)
- Goal: protect payment cardholder information from disclosure. “Objective-based”
- PCI SSS – specific technical requirements for applications processing PCI
- PCI SSLC – specific process requirements for organizations building apps
OWASP
- T10: Top app/API risks, including lack of threat modeling and runtime protection
- ASVS: Baseline technical requirements for common appsec security mechanisms
- OpenSAMM: Maturity Model/process standard
- OWASP Cheat Sheets - technical guidance on most appsec controls and defenses
NIST
- Goal: Complete risk management framework that includes appsec as one aspect
- NIST 800-53: Baseline technical and process security controls for systems - includes apps
- NIST Consumer Labels: Describes “scheme” for labeling software/security claims
- NIST SSDF: a basic framework for secure development processes
- NIST Minimum AST Standard: Defines minimum security testing for apps and APIs
CISA
- Zero Trust Maturity Model – 5 pillars (identity, device, network/env, application workload, and Data) – requires all apps to be internet facing. appsec testing with static, manual, and dynamic. Also monitoring and protection in operations.
OMB
- Zero Trust Directive – agencies must implement zero trust (CISA 5 pillars) by EY Fiscal 2024. All agencies need high-quality firms specializing in appsec for evals. Move to continuous testing and monitoring. References NIST minimum Application Security Testing standard.
Privacy (security is a precondition for privacy
- HIPAA - Ensure confidentiality, integrity, and security of electronically transmitted Personal Health Information
- GDPR - European Union privacy rules
- CCPA
Other
- FTC - Consumer Protection Regulations - Must not mislead consumers about security
- SEC - Breach Disclosure Rule
- BSIMM - Maturity Model/process standard (waterfall style)
- Dept of Commerce - Review found serious problems in security problems in planning, assessing, vulns, and tracking at agencies
This has been super fun everyone. Thanks for joining! I'll be watching this channel for the rest of the day, but if this is the end of this thread, I'll leave you with a little something here that I've been working on. Hope you enjoy it!
Thank you for joining us Steve Wilson, and for your thoughtful answers. We loved to have you here!
