Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Secure development lifecycle in the cloud: Trust but verify

It's natural to want to validate what someone tells us. When the weather forecast calls for rain, you still look out the window to determine whether you need an umbrella. When a merchant professes to sell an item at the lowest-possible price, a customer will likely want to see whether competitors offer a better deal. And no matter how persuasively they're told something is too hot to eat or drink right away, many people will still burn their mouth in the process of corroborating the claim.  

But, for whatever reason, this trust-but-verify mentality isn't always how enterprises approach cloud application security. Even if the software seems to come from a reputable vendor who says their product is secure, information security professionals should still ensure the cloud software their organization is preparing to deploy has been verified as secure and undergone a secure development lifecycle.

In this video, expert Adam Gordon, author of The Official (ISC)2 Guide to the CCSP CBK, Second Edition, explains the importance of using vendors and cloud providers that have verified secure software, which includes secure APIs, digital signatures, a secure development lifecycle and more.

"If you're allowing non-validated software to run, you are increasing the likelihood of a security vulnerability and a threat that can lead to a risk and some sort of an attack," Gordon says. "If we choose to go with vendors knowingly that don't provide these services, we are going to have a problem. It's not a matter of if -- it's a matter of when."

View All Videos

Transcript - Secure development lifecycle in the cloud: Trust but verify

The following is a full transcript of Adam Gordon's video.

Hello and welcome to the use of verified secure software conversation. We've been talking in some of our previous sections about the value and the importance of secure application development. We've talked about the secure development lifecycle, the SDLC. We've talked about the need to identify threats and risks and understand common vulnerabilities. We've talked about the need for training and awareness around software and software security. We continue those conversations in this area by talking about verified secure software, the idea of understanding as you could see on the screen in front of you what APIs are approved and the use of secure APIs becomes incredibly important, as we've already discussed. Take a look at and talk about supply chain management, upstream and downstream liabilities from vendors and how we can then figure out how to secure or rather consume securely, and then community knowledge. You know, what is it that we know and how do we share that knowledge broadly and widely to ensure that we're using secure software but also consuming and interacting securely in as many areas and places as possible.

The value of secure APIs

So when we think about approved application programming interfaces or APIs we have to think about the fact that before using for instance in a SaaS service model security or rather in the SaaS service model software rather from the security perspective that the software vendor, the SaaS vendor is providing to us, we have to rely on the vendor to assume in our mind as the customer that they have done their due diligence and are providing secure software -- created through a secure development lifecycle -- and that the APIs that we are using are going to be secure. So APIs are a means for a company to expose functionality to applications, and that has to be done securely. If we use an insecure management software API in order to access management interfaces we run the risk that a bad actor may be able to integrate themselves into that process and may actually then be able to interact with our data, steal our passwords, steal our usernames, change configurations, or whatever the case may be. This is something we have to be concerned about and something we have to think about.

So programmatic control and access, automation, integration with third-party tools, these are all things that secure APIs do provide. But we do have to be aware of and understand how to consume software securely and validate that software is secured. So for instance, if Company A provides a software API that we're supposed to use in a cloud services model, let's say a SaaS model, we would want that software to be digitally signed and validated by the creator, by the Company A software vendor so that we know that if we download the hash and validate the digital signature for integrity we know that the code has not been compromised and we know that we are creating or rather consuming securely the software that is the particular version that they've put in market that is supposed to be considered secure.

Cloud software integrity

We'd want to work with the vendor to make sure we have the most recent version and all the patches that are supposed to be applied are also software integrity checked. So we want to make sure we're running the latest version, that it's digitally signed and we have integrity as well as confidentiality around the use of that software, meaning we know that we're installing and using it securely, and that we're doing so in a secure matter with a secure thought process from the vendor being applied, best practices, configuration management, settings, and whatever the case may be.

If we download software from a common website without the ability to validate the signature to know that we have integrity we may be using insecure software and we may lead to exposure of data as a result. These are things we have to think about as security professionals in the cloud, things that customers have to be taught and be made aware of in order to think about and things that providers have to understand they have to do as part of a secure development lifecycle.

Today, lots and lots of providers are signing their code to validate it but not all do. Some are making it available only through secure internal private cloud-based customer authenticated sites so they don't feel that they have to download or, excuse me, that they don't have to verify the download by digitally signing it. That may or not be a good thing, it's hard to say. Think about your companies whether or not you actually do application development or not, I don't know. But if you do and if you provide applications or web-based services and provide those services through an application API to customers, if it is internal only in a private cloud, you may not be digitally signing the data, or digitally signing the software rather, in order to prove and provide authenticity and integrity before users again internally in the private cloud, behind the firewall, private only, are downloading that software. You may not feel there's value in that. Your developers may not feel they want to go through the time and trouble of having integrated KPI, or excuse me, a PKI solution as part of a secure development lifecycle in order to be able to use signatures and digital signatures and certificates to be validating. You just may not want that infrastructure and that headache.

But if you are a public-facing vendor that's going to provide software APIs and management through APIs to cloud vendors, or through cloud vendors to customers rather, you may have to digitally sign those applications, and that as a result will lead you down that road. So it really is a question of degrees and a question of functionality, but remember a lot of cloud services are consumed privately inside companies today. A lot of those companies although they may know better may not be using something like a secure API validation or integrity check solution, they just may be allowing software to be provided and downloaded because the assumptive operational thought process is, "Well it's a private cloud, it's behind the firewall, it's our internal people, we're not going to worry about now where nobody's going to get in and download or rather get in and provide bad software." And as a result, why would we go to the time and trouble of validating it. Well, that may or may not be the case, it's hard to say but it's definitely a risk that we would then have to identify and a control that either needs to be put in place or document that it's one that we are choosing to bypass. We would then have to operate accordingly.

When we think about the consumption of APIs as I said, obviously, insecure products -- that is, those that have not undergone a secure development lifecycle -- can be leveraged if we're not validating the APIs and they are being validated as secure. We've talked about this just now so be aware of that and think about that. Any software that is being deployed onto a system, internal or external, inside the firewall in a private cloud scenario, outside the firewall on a public, private or hybrid cloud environment, should only run authorized software that is validated, digitally signed and has integrity associated with it.

If you're allowing non-validated software to run, you are increasing the likelihood of a security vulnerability and a threat that can lead to a risk and some sort of an attack. When we think about supply chain management, we have to think about fact and understand and know that the vendors we deal with are acting securely, are acting in our best interest, are proving trusted interfaces and APIs and again, this comes down to, you know, risk management. If we choose to go with vendors knowingly that don't provide these services we are going to have a problem, it's not a matter of if, it's a matter of when.

If we choose to consume software only from vendors that are following a secure development lifecycle, validating with digital signatures and integrity checks, publishing best practices and documentation and guidance around usage, and consumption securely, deployment guidance, things like that, and are providing control mechanisms for auditability to ensure their software is used correctly, then we're going to be much less likely to run the risk of using software that's going to become a problem for us. But again, this is relative and this is a question of degrees. You know, everything is important, everything is a must-do and a must-have and a must-need until we ascribe a price tag to when it comes to security. And all of a sudden it's not so much now a question of must-have, but a question of nice-to-have.

And so we have to understand how to prioritize and really think through what the must-haves and the nice-to-haves from a control perspective are, both in supply chain management as well as in ongoing conversations around API security and these areas. We may say, yes, absolutely, very important, sign every piece of software, identify every supply chain upstream and downstream information management connection, you know, dependency, validation of this or that vendor, this or that risk, this or that concern and make sure we have all those liabilities, all those things documented out and that's all great, but it takes time, time usually equals money and we may or may not be willing to spend the time, therefore, invest the money as a vendor or as a customer in order to be able to achieve that end result of clear distinct documentation and transparency all up and down the supply chain and secure development lifecycle. If we're not willing to do that, then we have to take into account the fact that we may actually operate insecurely in certain environments and what that means, and again, that's something we would have to consider and be aware of.

Assessing cloud supply chain risks

So obviously, clearly supply chain risk can ripple through upstream and downstream a supply chain very easily, one vendor gets infected, one vendor acts in an insecure manner, one vendor exposes customer data that has been trusted as a subcontractor to deal with and that can ripple through an entire system. So we do need to be aware of that and think about that. You know, we see this time and again when we examine and explore breaches and the nature and the reasons behind as a root cause the breach takes place without going into detail about any one breach for any one reason in any one area of the world. You can think about some breaches that have occurred in the last several years, some of them very big and large and spectacular. Some of them very small and not often talked about but you can imagine one or more of them and if you think long and hard you'll come up with an example where supply chain risk and supply chain management was at the heart of the cause of the breach. It's not hard to think about today and it's certainly not hard to identify these breaches when they occur.

So think about from the cloud security perspective what you need to do differently on Monday morning to mitigate the risk of supply chain management that may be present in your infrastructure. How well are you managing your supply chain, how well documented is it, how much do you know about the upstream and downstream liability associated with consuming inside of your supply chain? If the answer is "not well, not much, and don't really know," then you probably have a little due diligence and due care homework to engage in. If the answer is "Oh, got it all under control, know every vendor, validate them and the people that they do business with, don't allow any non-authorized vendor to touch our data," you've got a great solution and my hat off to you literally and proverbially as we think about that because you have really figured out how to manage supply chain risk and to identify supply chain issues appropriately. But not every business is in that particular boat and we want to acknowledge that and be aware of that as well.

To that end, we may think about the fact that there is some guidance in international standards that may be of value and help here, you could see the ISO 27034 standard as mentioned here. "Information Technology - Security Techniques for Application Security" specifically, this helps us to define the concepts, frameworks and processes that help organizations to integrate security within their SDLC or within their software development lifecycle. This is really about the guidance necessary to create and implement a secure development lifecycle with regards to the cloud. So this ISO standard is going to really be valuable to help us to do that. If it's a standard you have not come across before, if it's one that you may or may not be familiar with, I would encourage you to go out and take a look and learn more about it. It has a wealth of information and guidance around the use of the secure development lifecycle within the cloud, it's going to be very, very valuable to you, obviously something that a cloud security professional would want to become familiar with, something that we may make recommendations to based on the guidance within for customers to follow, something certainly that application providers should be well aware of and be aligned with the guidance around as well.

So when we think about standardization and we think about the opportunity to create the sameness across the platforms that we look to, something like ISO 27034 would be a great starting point for us to level set around the use of a secure development lifecycle.

+ Show Transcript

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

How do you validate vendor claims around secure software development?
Cancel

-ADS BY GOOGLE

SearchSecurity

SearchCloudComputing

SearchAWS

SearchCloudApplications

SearchServerVirtualization

SearchVMware

ComputerWeekly.com

Close