Good afternoon and welcome to our Kuppinger call webinar, rising to the security challenge of heavy cloud adoption. My name is Dan bloom. I'm a senior Analyst with Kuppinger call and I'm also a principal consultant with security architects partners, which is a consulting organization, specializing in security and identity management. My email address is on the screen DB Kuppinger call.com and would love to hear from many of you in the audience. If you have questions or comments later, I have a long background in cloud security and a long background as an Analyst and consultant.
And you'll probably hear more about that as I actually talk through the slides. So before we get started, there's a little background on Kuppinger call. We are a enterprise it research advisory, decision support and networking company for it professionals. We are based in Germany, but we have analysts like myself all over the world.
I'm based in Maryland, outside of Washington and the United States. And we provide research. We provide advisory services and we provide events.
Some of our upcoming conferences in 2017 are the digital finance world conference in Frankfurt, March 1st through third, 2017 and the European identity in cloud conference in Munich, Germany, which will be may nine through 12th, 2017. And hopefully some of you were there. I was there in 2016 and hello, if I saw you there and hope to see you again.
Anyway, here's our agenda for the presentation today, we have three sections to this presentation part one, which is about the challenges part two, which is about recommendations or what to do about the challenges and part three, which is your questions and answers. And I'm hoping to leave at least 10 minutes for the questions and answers. So please think of them as you go along and, and you should see on your WebEx control panel, or I'm sorry, your go to meeting control panel. You should see a questions box into which you can type your questions.
So in terms of the challenges, the basic issue is this whether or not enterprises have decided on cloud first strategy,
Many have seen heavy clouds form spontaneously around their it environment, which is sort of a storm metaphor for the widespread adoption of cloud computing. Sometimes in what we call the shadow it format, where different teams have gone out and or different business units have gone out and adopted cloud computing, even in advance of the it strategy, embracing it with cloud first or cloud at all.
And, and that environment it's, it's tough for us security teams to get a handle on the problem. And they face challenges protecting their cloud estates. So we will talk about heavy cloud adoption as a challenge, but that's not because, because, because not all the clouds bring the warm life, giving rain for your farms. Some of them bring the risk of hacker lightning and regulatory funder, but in the recommendations, we don't want to clear the sky.
We know we can't go back to it as it was before the cloud, we can't put the cloud genie back in the bottle anymore than we could stop using electrical power plants.
But we do wanna bring out the sun from behind the clouds to try to try to improve the weather for your company, but let's first detail. These challenges a little more in, and I actually have a report by the same title as the title of this presentation. And in that report, I identify five cloud security challenges.
The first one is strategic uncertainty in it itself mean leaves, many security organizations rudderless in the storm, regulatory and shared responsibility, conundrums, paralyzed decision making shadow. It brings risk it and security infrastructure can be come fragmented with unplanned cloud adoption. And a lack of agility can disconnect it security from the creative forces in the business. And as we'll see, a lot of these challenges are related and the solutions have to be architectural and they have to be cross functional and they have to be related to these challenges as well.
Let's talk about the first one, the strategic uncertainty in it itself. Now this is my 10th year working as a cloud security Analyst. I was first put in that role when I worked at the Burton group, which I worked there from 1998, through 2010, and now I'm a security consultant with security architects partners. But as I like to say, once an Analyst always an Analyst, and it was my great pleasure to put on a Kuppinger call hack this year and start doing Analyst work as well.
Again, but meantime, I never left cloud security. I've been working in this space, as I said for about 10 years. And we used to say back in 2007, cloud computing will transform it. Let's experiment, but not put our sensitive data in the cloud. Unfortunately, for many organizations that horse has left the barn. Hopefully the horse had a saddle and a bridal, and you had a good strategy for putting the sensitive data in the cloud.
But unfortunately we've dealt with customers that have not in 2016. We now see that the in industry has moved forward.
The horses are running, but some enterprise it departments still have no it cloud strategy or their strategy is outdated. Now, what is the strategy? Because the term strategy is heavily overloaded in our industry. The strategy is a high level guidance on how your organization will manage a problem and how it will interact with external forces like regulators, like vendors like partners, a PowerPoint that says we have a cloud. First strategy is not enough guidance for security. And the other option saying no is no longer an option for most companies. CSO cannot be Dr.
No, we're here to enable the business to protect the business, but we can't stop the business.
But as the industry moves on and we see unplanned cloud adoption can really fragment the it infrastructure and also fragment the it security infrastructure. We started out with the vision that cloud would rationalize and simplify it itself, but there's a long transition before that happens.
I mean, if only you could just lift and shift all your applications, life would be easier, but you can, some of the security patterns that you used inside the firewall don't fit anymore. When you end up in the inevitable hybrid multi-cloud environment that exists in a unplanned format and even in a planned format, a planned format for your future hybrid multi-cloud environment has to be well architected.
This recommendations that I provide will show you can do a lot to interconnect integrate and protect complex cloud environments, but you, you need some kind of parallel projects for application rationalization. As you move out to new cloud systems, you need to be decommissioning legacy systems or else. Simplification is unlikely. You have to create
New patterns like microservices, security, automated compliance, checking in a continuous integration, continuous development pipeline.
And so on, no presentation on cloud security challenges would be complete without covering the regulations. So we have a little slide with a maze here, and I have to announce the borderless internet. The cloud have not yet erased the nation state. And the rumors of the demise of nationalism were exaggerated in the 1920s. We had trade protectionism in the thirties, the great depression. What is next? I don't know, but I do know that today. There's great regulatory confusion about data protectionism. Here's your free English lesson today.
If you're joining me from Europe and that is the word conundrum, not a word you hear every day, but the definition is it's a confusing or difficult problem or questions. Some of the synonyms for that are quandary or dilemma. And if you go into the world of English slang, you have things like head scratchers and brain teasers and poses.
For example, conundrum, regulatory issues certainly qualifies a conundrum. Lawyers don't understand the technology technologists don't understand the law. And this is very challenging for the multinational corporation.
It becomes more challenging in light of the nature of the management of cloud security. The management of cloud security is a shared responsibility. The diagram you see on the left, I originally drew this, I think in 2008 or 2009. And it was often plagiarized by my colleagues in the industry. And when we sold the Burton group to Gartner, I had to stop using it. So rather than plagiarizing it, I redrew it myself with different words, but it's the same concept in the private cloud environment or in the legacy environment. You control everything on your premises. So it's all green.
Soon as you go into the infrastructure as a service environment, though, they control the physical and network security and even the host physical operating system.
And then in PAs, your control starts only application upwards. And in SA actually some would say you don't control much of anything, but actually you control a lot because you control security monitoring.
You control part of identity management, but both of those are a shared responsibility and the regulatory community, and even the security industry itself is not fully understood or specified how that shared responsibility can work, especially at a technical level, take encryption, take, bring your own key. And on the right of the slide, I have examination factor myth. This is part of a slide that I got at a conference from Microsoft last week, Microsoft ignite in Atlanta. This slide said a number of myths says regulatory requirements, mandate that I own.
My encryption keys encryption allows me to control all the access to my data. Bring your own key can prevent cloud personnel from as accessing my data.
And if your provider requires you to hand over your keys, find another cloud service.
Well, the first three of these are basically not true. And the fourth one is probably not a good idea. Let's look at them regulatory requirements. There's only one country that mandates bring your own key for a financial institution. Other than that, the regulations pretty much leave your own your own to figure out how to manage your keys. And at this point that's probably a good idea, but we, as I said, need to figure out architectures for how we handle this shared responsibility. And I'll have a few things in the next section that sort of go in that direction.
Now, the next one is that encryption allows me to control all access to my data, but encryption is not access control. If a hacker takes control of my computer, he or she will then have remote access through the computer to any data that I am authorized to access, even if it is encrypted because I would have the, the rights to access it.
And they have that through me, B Y K prevents cloud personnel from accessing my data, not true for software as a service or SA basically the SA provider has to have access to the data, to provide the applications.
And even though cloud security access brokers CASBS do provide SA encryption. It has a lot of limitations and, and in that light then bring your own key is something that Microsoft now offers. And it's something that Amazon now offers, but it's more like you own the master key. You can change the key, you have a copy of the key, but they still have to use that master key to make valet keys for the parking lot at attendants that go around actually encrypting your data in the infrastructure as a service or software as a service environment.
The final challenge is that a lack of agility may disconnect security from business developers.
What we've seen in the industry is that agile development and DevOps practices have gained a lot of adoption.
And what we found though, is that it security way of working rooted in the waterfall development methodology, where we specify, build, test, and verify and have rigid gates that we go through puts us in a very difficult position when the move business is moving in at the speed of internet years through its more iterative, agile development processes, a little case study here, the quote from a frustrated former security auditor at one of our global 1000 clients that found himself in security engineering, trying to deliver solution to the business.
What he had to say was by the time an it security project going through its waterfall stages is finally complete. The agile development team has already finished what it was doing. Usually without the security piece we planned built in after a few iterations of this, where they may have waited for a few weeks on security to deliver the solution.
If they waited the agile teams won't even ask for help anymore.
So, so this fellow was very frustrated. So we can argue all day about which methodology is more effective, the waterfall tortoise or the agile hair, but one thing is clear. They do not mix well. It or security engineering teams grounded in a waterfall methodology and rigid change management are gonna have trouble remaining relevant to development groups using more iterative, agile and DevOps methodologies.
Well, I don't wanna be the tortoise. I don't wanna be the hair. I want to be the auditor. I just watch what happens and point out what's wrong.
Well, that's great for the auditors, but some of us do have to deliver solutions. And, and so I hope you can see as we've gone through these challenges, cuz we're at the end of them now that a lot of them are related and they're interconnected where you're seen that, you know, your security infrastructure's fragmented and it's getting hard to deliver solutions, but you have these agile development teams moving on and aggravating the problem of cloud security adoptions.
And you're trying to figure out a strategy, but everybody's confused about the regulations, but that doesn't stop the shadow it from growing. And this is what actually is happening to many customers of global corporations. So we're gonna look at recommendations for developing a strategy and how to bring stakeholders together. Some decision frameworks and good practices, how to discover and govern, shadow it and how to engage with agile and DevOps practices.
So this cloud security decision framework is a artifact that I created actually working for the, the same customer that our frustrated former security auditor worked for a global publishing company. They operate in, I think it was more than 50 countries. So it's a big, big company and it was hard to get a real it cloud strategy from them. And yet many of their products are moving already into infrastructure as a service environments. So you have issues with multi-cloud monitoring and visibility. How are you going to actually get the events and the data from the different cloud environments?
So you can deploy security information and event management system, but you first, you also have to know what are the accounts in the various infrastructure as a service environments that you use and have access to those accounts. For example, in AWS, you would need to make sure they were all using cloud checker and have Lambda scripts that were creating the necessary events and so forth.
So how, how are you gonna do that? How are you going to get visibility of where all your cloud service providers are and where all the accounts are through which you control them and, and how do you the inability to do that reflects the lack of the cloud governance model. But perhaps we should have started with the centerpiece here, the primary cloud direction, and that is, are you going primarily with a public cloud strategy or are you going primarily with a private cloud strategy?
I think you can see that without answers to these questions, security staff are working in a vacuum and that getting answers to the questions is like getting oxygen. And so we're actually gonna recommend on the next slide that you align with an it led initiative. This should be to, to, to answer all these questions. A lot of them are not security questions, they're it questions, they're business, government governance questions. So you need to align with an it led strategy. That's doing that. Hopefully there is a, it led strategy. That's doing that. And you have a seat at the table.
Most likely, at least the C I S O or some of the chief lieutenants under the C,
I O do have a seat at the table. You need to find those people and you need to make sure that, that you're getting minutes from those meetings and that you have representations at those meetings to ask those questions, even if there is not already, and it led strategy to answer them. You also need to have guidance on what is the application hosting strategy? Where are the strategic applications for the organization? We worked with a customer that had a registry of over a hundred hundreds of applications.
And even that wasn't complete, but it wasn't clear which of those were going to move to the cloud, which of them were already in the cloud and what new ones were under development. And what is the strategic cloud service provider that you're using? What are your key managed service provider partnerships? So there's, you can see that enterprise architecture is gonna be a really critical stakeholder in this cloud management framework. This goes to some of the multi-cloud monitoring and, and visibility questions. I mention the style of private cloud that you have.
If you have a private cloud, the way that you do cloud networking, are you just relying on pure internet access methods? Are you deploying virtual private cloud or VPN type of technology?
And if so, where are the gateways? Where are the tunnels?
What is the business continuity and it disaster recovery strategy. How do you address data classification, privacy and compliance? And that is obviously bound up with identity management and privilege management as well. So we have a lot of strategic questions that our core to the way it operates here, that need to be answered before you can develop cloud security architecture.
So how do, how do you go about doing this? Well, as I mentioned, the it security strategy needs to be more than just a statement of direction and a vision. It needs to actually talk about how it is governed and how business units are governed and cloud service providers are governed and how partners interplay with this and how you address the regulatory requirements. It's a cross-functional effort.
And, and in the center of this cloud security strategy wheel that we created, we have the requirement to discover in the first place, what are the cloud services that you're using, which business units are using them, what are their needs and what are the risks?
And in parallel with that to establish some sort of team of stakeholders in an it led initiative.
Now, if you're unable to find, or, or catalyze an, it led initiative of this type, then at least the, the second best alternative, the only other alternative, as I said, was to find the right people in your security organization that are going to the right meetings and make sure that your C I S O or someone high in the organization has a concerted approach to getting minutes and asking questions around this cloud security decision framework.
So you have your virtual team of stakeholders or your information gathering goals, and you go out and you try to discover, you have to discover what is the primary cloud direction? What is the governance model now? What is it going to be? What are the application hosting guidelines and come around the wheel then to the risk management framework.
Now the risk management framework is something that Kuppinger call has worked on a lot. And Kuppinger call has a number of documents on how you assess cloud risks.
In order to verify that the cloud service providers, you select are complying with the regulations, and that will not, will not put your company at risk. And, and that is all very important work to do.
And, but, but in addition to that, you need to fully align the way you manage cloud risk with the way you manage any risk in your enterprise risk management process in your it risk management processes, you need to discover what is the risk appetite, what are the risk fresh holds and so on? And you need to answer that question that I posed earlier in light of the regulatory conundrum, around the complex technical issues like encryption, what is the shared responsibility model for managing keys, but not just for managing keys?
What is the shared responsibility model for security monitoring or for vulnerability management or for incident response for disaster recovery and all, all these things.
Now, once you get halfway down the wheel here, if everything's gone well, you should have some answers on what the existing corporate standards and policies are or what the intended strategy is. And you know, how you wanna host your applications, what your cloud direction is, how you want to govern the vendor management and how you wanna govern projects and what your risk management framework is.
That should give you a pretty good set of requirements, where if you were in a green field, you could use that to select the best fit cloud service provider and manage service provider partners. So you could be looking, you know, at, at anything from Amazon web services, SAP, H Oracle human capital management, Microsoft dynamics, CRM sales force, they're all in the cloud.
And many of these are strategic infrastructure as a service platforms or strategic software as a service platforms with application marketplaces, which have hundreds or thousands of other vendors pouring their software into those environments and integrating and working with those environments and those APIs.
So those core partners are the ones that you can use to deliver modern it solutions. But obviously you want to get the ones that are fit for purpose fit for the way that you're governing your environment and that that match your installed base.
And that can move over your solutions into the cloud environment, in the optimal and lowest cost manner. All that being said, you may already have one of the major vendors in house, in which case it may be a moot point once you've sort of decided, you know, what your strategic well, what your center of gravity is, what, what sort of solutions you still have on premise? What sort of solutions are going into the cloud? What data classifications are going into the cloud, how you govern and manage the risk around that, and, and which are your partners.
Now you can develop a management framework for all those issues, and you can start to optimize cloud networking and cloud identity and come around the circle.
This needs to be a living document. It needs to be updated probably at least once a year. And it's more than a document.
Actually, it's a process of maintaining this strategy once you've gone around the wheel once or twice, which I think many of you may already have cloud may become sort of a normal part of doing business for your organization. And it may sort of not be a distinct thing anymore, so to speak, but for many organizations, still, as we mentioned, there are these challenges and there are, there is this confusion about how to adopt cloud solutions. And we're trying here to find an approach to resolving those.
So we mentioned establishing a stakeholder team in an it led initiative as being sort of the ideal approach that you wanna take to developing and implementing a cloud strategy. It cloud strategy here is a high level responsible accountable consultant informed, or, or, or R Iraqi.
I dunno how you pronounce that matrix. So you see each of the decisions is on the left, who owns the primary cloud direction, who owns the style of private cloud, who owns the data classification, privacy and compliance, for example.
So something like the primary cloud direction for a big company that could be the CIO, but it could also go all the way up to the CEO. Certainly in terms of accountability of you, you choose the wrong approach, you choose the wrong vendor.
You, you, you start losing money. The CEO is gonna be held accountable for that in much the same sense as the captain of the ship.
It's sort of that important as, as it's also true for the cloud governance model, because if cloud is transforming it and, and 50% or more of your, it is in the cloud, and you have a catastrophic it failure, that's gonna show up in the quarterly results in terms of things like data classification, privacy, and compliance, obviously that too can go all the way up to the CEO.
But the first line of accountability is the compliance department and the responsible people would be the C I S O for the technical side and the legal for the legal side. And so you see this, this matrix kind of gives you an idea of who needs to get involved in this kind of it led initiative or who, if you're in the security department, you at least need to, you know, ask these questions of, you'll see enterprise architecture here a lot too, particularly around the application strategy and the application hosting guidance.
So let's go through some of these decisions.
I'll show you some patterns that I've worked with with customers that I've worked with on cloud security. This one is on the primary cloud direction and the governance model and the infrastructure strategy. So here organizations are often looking to say, you know, are, are we, are we adopt?
Are, are we willingly adopting cloud? Are we, are we even gonna go to the point of saying that we're public cloud first, that, that if you have a new solution, a new project, you wanna deploy, you have to justify why it's not going into the cloud, not justify that it should go into the cloud.
And I, I remember, I, I think it was five or more than five years ago when this, the needle shifted or the center of gravity shifted on virtualization. It used to be that virtual machines, virtual machine infrastructure was kind of a scary thing to a lot of it professionals.
And you had to justify whether your project could be supported, whether it would, would perform your database would perform. If you moved it into a virtual machine environment.
At some point, the, the, the pendulum swung to the other side and virtual machine environments had become pretty reliable and they cost a lot less because you had less physical hardware you had to buy, and they were more, more, more, more agile. You could, you could create virtual machines faster than you could buy new physical servers. And at that point it became virtual first direction. You had to justify why you weren't going with a virtual approach.
The same thing I think is starting to shift in the cloud computing space, to where for many organizations, the scalability, agility, and choice of functional solutions from cloud services has become so compelling that to build something in house that may cost more and take longer, has to be justified rather than going to something that's already built and is already out there in the cloud.
That being said, there's still a lot of good use cases for private clouds, a lot of good use cases for keeping sensitive data on premises.
And, and certainly you want to keep control of that sensitive data on premises. And until you've got a strategy and a good set of guidance on the regulatory issues, for example, in the case of personal information. So private cloud is, is still a, a very important concept as the next evolution of virtualization. But whereas five years ago, there were a lot of companies that were saying, okay, private cloud is our primary strategy, our preferred approach.
And we're gonna build out with cloud management platforms and orchestration something that is almost as, as scalable as Amazon, but it's under our control.
They have often found that the cost and difficulty of building out that private cloud environment is, is too excessive.
So, and now you have to look at, at, at a choice. What, what does private cloud mean to you?
Is it just a better, faster version of your virtual machine environment, your virtual data center environment, or are you actually trying to, as a, as a large corporation, trying to build a huge software defined data center in multiple countries to satisfy multiple regulatory regimes, you know, build the kind of giant infrastructure that one of the big cloud computing providers would have, or you're looking for something intermediate, like adding self-service service catalogs to your virtual automation in your private cloud, most organizations are sort of scaling back a bit, dialing back to the middle or the left of the, of the private cloud spectrum.
And then, you know, in terms of the cloud service provider, partnering strategy, you know, on one extreme, you have just one infrastructure vendor and a few core platform vendors, you know, like, like SAP Hannah or, or Oracle human capital management or sales force or something like that at another extreme, you have the line of business driving, which cloud providers you select, and it's pretty tactical, and you don't really have a control on how many there are.
And, and then in the middle, you may say, we wanna have a healthy mix of many cloud service providers, but we're gonna limit how many we have for each type. And we're gonna try to use architectures where we're good at brokering between them. So there there's different approaches and, and you, you just have to decide which one you're gonna take. Looking at the governance model.
The question has to be asked, who makes these decisions? Is there a central point in the organization where you make these decisions? How many cloud service providers you have?
Is that the CIO, or is it the head of each business unit that makes those decisions? So you can have centralized decentralized or, or matrixed model. We find that most organizations have a matrix model, but not all of the matrixed models work that well.
So if you, if you have further questions on that, I can point you to some research we've done on those questions, the application hosting guidance.
I mentioned earlier that it's multinational corporations, that, that have the greatest challenges, some of them even more than others, because you have to decide whether in general, you want to take a build versus buy approach.
And, and if you're building into the cloud environment, that that is compounding some of the challenges you face, but also some of the opportunities. And then in terms of cloud networking, I've had customers say that the network is our greatest dependency, because as you have heavy cloud adoption and, and you have multiple products in different regions of the world that need to interact with each other, and your, your finding that in each region, you had a different VPC or virtual private cloud, and there's no VPC peering where you can connect them all.
And some of your connections or bridges running through office buildings, you don't end up in a happy place.
Now, there are some solutions for that, where you can go to network colo, colocation hub vendors also called carrier hotels and place a commonly used data tier closer to the major regional center of your cloud provider. But it is another whole architecture that has to be worked through. Now. I mentioned that that one of the early things to work on in the cloud strategy, we wheel was discovering your cloud services and discovering the risk.
And that means getting a grip on shadow it from a Cisco study. I read it departments estimate that companies are using a department of an average of 51 cloud services. But in reality, they're using an average of over 700 services and that this multiple between the, the estimate they had, and the reality of the number of services is growing was once seven times multiple. And now it's up to 15 times and given the exponential growth of cloud, Cisco predicts by the end of this calendar year, it will be 20 times and more or more than 1000 external cloud services per company.
That's actually shocking, really shocking. Even when you think that maybe 900 of those are maybe only a few users to have hundreds of services that weren't deployed with the shared it organization planning seems very difficult to manage, and it is a general phenomena in the industry that business unit level spending is on. It is increasing in its proportion of it, total it spending. We think that within a few years, it'll get to be 50%. That business units will be spending about 50% of the pie in the budget, but you can get a grip on shadow it.
There are these cloud access security broker products that can look through all the network logs and, and even put sensors in the network access points. And, and they can discover all the cloud services that are being accessed, and they can produce reports saying which ones are riskier than others and what they do and categorize them and prioritize them and so forth. And over time using cloud discovery systems, you should be able to separate what was once shadow it into four categories, known and sanctioned services that, that you promote as shared services to the enterprise.
They may have once originated as shadow it. And then there's services that you discover they're not sanctioned, and they're not good, they're risky.
And, and so these, you need to put them into the risk management exception process so that they're discouraged and deprecated and reduce over time.
Although you may discover some of them once unknown could become sanctioned.
So, so, you know, having a strategy for how you're gonna discover and manage and how, how you're gonna publish the, the services that you have and recommend to the business unit. This is a very critical governance and management question for, for your stakeholders.
Now, the, the, the types of products that I mentioned, the CASB can do much more than just discover your cloud services or shadow it services. And they can do much more than actually provide risk reporting or, or blocking access or anything like that. They can provide a carrot as well as a stick. And that is a cloud single sign on. It's no secret that password management is very frustrating thing for our users and for the executives that have to pay for the help desks for the password resets, for example.
So deploying cloud single sign on is sort of the next step of what you could do.
If you engaged with a cloud access security broker, the pattern that you see on the right is something that I developed for financial services customer just developed it last week, actually. And, and it shows how you could use a identity as a service offering like Okta or one login or a Microsoft Azure active directory premium can provide logins. I think Okta can log in single sign on to 4,000 SA vendors. And I think Microsoft can log to 1700 and, and some of them are through SAML. Some of them are through open ID connect.
Some of them are through password management technologies like remembering the ID and password and form filling it. If there is finer grain control of access required, then some of these vendors have cloud provisioning solutions too.
Also for another client. Here's another pattern to look at for addressing privacy and compliance issues.
If you are a multinational corporation operating in many countries, keeping track of, you know, thousands or millions of customers on behalf of your, your business customers, as you provide your self cloud service, you have a real challenge around the regulatory conundrum and the shared responsibility that I talked about starting to get a grip on that. You need to create an identity abstraction layer so that all your identity information is logically centralized, but physically it may be distributed.
So for example, you may have a virtual directory solution in place, and you're using its L D repository, but then you find that for a particular country, the way you need to access it from other countries that you're gonna need to store the identity data for that country in that country.
As long as you have the country codes in the records, you can partition off a section of the logical directory into that country, modify the access control this and the access control rules appropriately.
And then you can use that data as if it was still centrally available, as long as the access control permits and where it does not permit. You can even deploy a anonymization services to get some of that data up to analytics, because they say data is king. And that the data is really what's gonna be able to drive your business to figure out what it's next generation of products and marketing opportunities are.
So, so this is an actual architecture that one of my customers is building some other quick wins for assurance. It's important to harden the APIs because in the, in, in the cloud environment, it's, there are still network zones and network segments, but it's much more open it's.
It's much more about logical zones than physical network zones.
And, and even within our internal networks, we need to have more secure APIs. So hardening the APIs using technologies like oof, using HTTPS bidirectional authentication, IP address, white listing for the really critical stuff, then developing secure configuration baselines for your workloads in an infrastructure as a service environment and automated compliance reporting on the process side to support the governance, figure out where you're gonna put the security hooks into vendor management or project management, and then looking at a bimodal approach.
We're gonna talk, my last slide here will be about the contrast with the agile and DevOps environment. Maybe that's one mode that you operate in. We used to say for only your lower risk projects, but I think it's not just for them anymore. It's for most of your projects, not a question of when, but a question of how I even have one client.
That's looking at a tri modal approach where their leading wave is, is going out with orchestrated microservices based on Docker with Kubernetes and other orchestration platforms.
And then last year's leading edge approach, which was orchestrated workloads and Amazon web services is still around. And, and then they'll have other organizations that are either still on premises or still in AWS, but not orchestrated through the standard process and, and they'll have security standards and checklists for, for, for that group as well. So having a, a process for each track of adoption, whether it's premise based private cloud or whether it's instance based, or whether it's microservices based, we're almost out of time. So I'll just touch on automation and agility.
Very quickly. I mentioned that along with cloud comes the agile development framework, and certainly the DevOps or development plus operations paradigm, the way you align with that from a security perspective is not by playing Dr.
No, but by actually building your security documentation and other artifacts into the tools that the agile developers use like JIRA or, or, or for issues management, an agile development management or GitHub for open source, not just a code, but also the specifications. So your security specifications go in there too. They get maintained jointly by the developers and also by security staff attached to the agile projects. So you're providing training awareness and tools into the agile environment. You wanna encourage just as you would in the, you know, regular it standard it environments.
You wanna encourage fewer better suppliers and, and you wanna shift security to the lift. So you address security requirements earlier in the design phase and not wait till the project's done. And you're in pen test and you wanna create automated tooling. There's actually some, a website called awesome DevOps tools. There's links to all this in the report that link to these articles and, and these tools, but they support the continuous integration, continuous development pipeline.
So we, we we've been through the challenges. We've looked at how a lot of these challenges are interrelated, and they basically require a strategic approach to solve. And that developing that solve that strategy requires answering a number of different questions, which I put into the decision framework, that there's a few accelerators you can use, like discovering and governing shadow IP and engaging with agile and DevOps practices.
And I'm confident that if you can either find an it led initiative and, and guided in this direction, or get high enough support in your security department to ask the right questions and get the minutes from the meetings with the right people, that you can start to make progress on resolving all these challenges. And it has been a pleasure to present all this to you today. I hope that you've gotten some benefits from it and I'll stop now. And we still have five minutes for questions. Thank you.
I'm just gonna shift over here to take a look and see what I have in the question box, the acronyms CGR, and FGR stand for course, grained authorization and fine grained authorization. That, that particular slide, I think it's back here. Yeah.
Slide is, is a slide. Just did it a few days ago for a financial services client. I'm developing authorization framework for them. And this is one of the patterns that they required. The slide uses the standard Oasis and ITF models for policy architecture, with policy enforcement points, policy, decision points, policy, information points, and policy access points. I'm sure you've probably seen those before, but I apologize for the CGR. It's a bit obscure. Let's see. I have another question here. Do your customers have a cloud first direction? And what does that mean?
So a lot of customers do have a cloud first direction where they now, as, as I said, have to justify why a new project, a new application is not being sourced from the cloud. I don't know what the percentage is. I'm sure it varies.
I think it's very high in, in the us and in, in parts of the far east. And I'm not so sure about other regions. I actually also, also though, I've run into one customer that, that had a metric for it, where they, they had a goal by 2018, that 70% of their applications would run in the cloud. So they actually have, they're actually trying to manage to that.
Let's see. I've got, I'm trying to find here.
Can you, okay. I think, I think that's not a different question.
Oh, why are then why are then CGR? So yeah, course grained grain starts with a gr. Sorry about that. Let's see. I have another question. How would you start discovering the shadow it in your environment? I think that, again, a lot of the cloud access security broker vendors, their, their, their including, you know, vendors like net scope or evident, oh, or blue code or CipherCloud or sky high networks, quite a few vendors in the space, UHS are called recently, did a report on CASB vendors that you can look at as well.
A lot of them will offer a preliminary discovery engagement as a free service. If they think that your enterprise could be a actual client in the future. So I would, I would recommend doing a assessment of your cloud access security broker requirements. Do you need single sign on, do you need discovery? Do you need data leakage protection? Do you wanna try encrypting files in software as a service environments or other use cases that they work well for?
You know, and then, and then, you know, come up with a short list of cloud access, security brokers that you think you could use for some of those entry level requirements, and then see if they can prove their worth by helping you discover where your main risks are and how they could help out. Let me see if there's any other questions.
I, I, I, I think we have no further questions and we're at the top of the hour, so I will bring this to the close again, once again. Thank you very much for coming to the webinar.
I, I hope you've enjoyed it. And just going back to the first page again, you see my name and my email address. Feel free to contact me. If you have any further questions or contact Coser call, and you can arrange a inquiry.
If, if, if you want to go deeper into these topics. Thanks very much and have a great day of you're in the us and enjoy your dinner and your evening. If you're over in Europe, take care. Bye-bye.