Exactly. So yeah, we will tackle the DevSecOps in general and we'll try to highlight in this presentation couple of like lesson learned and best practices, which I found interesting to share with you today. Basically gathered from all the experience I had working with a couple of clients on this, on this kind of software development, first of all, I'd like to to ask you, how many of you already using DevOps or DevSecOps in their deployment? Okay, awesome. So there's a couple of guys already here using it. It's, it's usually, it varies. So there is a lot of technologies, there is a lot of tools in place, open source and enterprise application that you can use for this type of cycle of software development cycle.
It's really when you have to jump as a security professional to, to help the team secure their, their setup. It's very important to get to the level of the engineers and get to some kind of relationship between them, understanding their workflows, their challenges, how they are approaching their, their, their development cycle, what languages they are using, what tools in place. If you are migrating, you might, or if you are now migrating your, your workflow from being traditional to DevOps, then you might be more flexible, but still you have to understand their kind of like, their challenges and, and, and, and key points in the development. So once I've heard from one CISO about DevOps and his understanding for the DevOps and he said, yeah, it's just an inex excuse for the developers to get access to production. So this is kind of like I encapsulate like, you know, the whole, the whole story of the challenges from the security aspect of the DevOps.
I would like to kind of like sim summarize the presentation in this sentence here. It's a quotation from Pro Shiner. He's a cryptographer. Security is a process, not a product. And this is really hard to understand for many, many managers or, or you know, high level senior directors that it's not one time event that you do security and you make sure that your solution is ready and you just deploy it. It's a process. It has to come the whole lifecycle of the development. So that's why the DevOps came in place and I will share with you a brief of history about the why DevOps came in the first place. So most of this terminology, which we are using now in the software development is came from the manufacturing industry. The lean, the scrum, the CanBan, all of these were actually in the manufacturing and then transformed to software and then getting evolved and getting, you know, enhanced in the or adopted by the software development. What is the reason in your opinion of all these frameworks or all these methodologies that is presented here? What is the background why it's in, in place?
So if we summarize it, if we summarize it, it's efficiency, deploy more, make more money, it's a business, you know, you have to make more cars. So that's how it came from Toyota. That just, you have to streamline the whole process and DevOps is just streamlining making features. So this is the background we have to understand this and how it came and now there's like new trends get ops and no ops that we have. We eliminate the, the, the, the operations and we just have development team deploying everything together. However, the advantages of the DevOps, it's the same challenges of the DevOps, the fast pace of deploying features, it's security concerns for security professionals and you know, for the, for the enterprise as a business. So, so we have to understand the interests of each of these, of these parties playing role in this DevSecOps first came the agile breaking the, the barriers between the business and the development.
So it came through together that, you know, the product owner, the the the the, the developers came together working together and there's a backlog and all these kind of things and then came DevOps to eliminate this kind of, you know, ticketing having to to to provision the the server. You just streamline the, the, the development cycle and then came the security as a result of this. So we have to understand like for the developers, they want to do more features for the operations, they want more stable environment for the security guys. They want to have secured, you know, infrastructure and secured also application in total and for the business making more money.
So there is kind of attention, there is sometimes it's very good relationship. So operation and security, they work perfectly. They want stability, we want stability, perfect match. So they work together efficiently and that's historically was the case when it comes to security and development is not, not as smooth as in in in operations because the developers want to produce more, they want to be a bit more flexible, they want to be, you know, as easy as possible, work from home, work from the beach, it doesn't matter. Just work and give us features. So security is not always the, the, the best relationship between together and there's development operation get as necessity, you know, as a, as as part of the, the whole development. So we are approaching this little spot, this sweet spot in the middle and that's the challenge.
Change management. So as I mentioned, the advantage of the DevOps itself, giving more features and being able to be agile as much as possible is a security concerns for for security professionals. And when we are, when we are obviously when we are, you know, you remember in the time when when there was Windows XP just released and then after a year there's service back one, 2002, 2002 and then 2005 there's service pack two and now there's service pack three. And so there's a big, you know, big release for the security patches and there's like hot fixes and all these kind of things. So this was like the traditional way of, of developing software. However, this is not the case anymore in your opinion, who is able to patch software faster and more efficient? The diagram on the left or the diagram on the right, obviously doing less features in faster time being streamlined, the process will be much more secured as a total, but this is a bit hard to understand. This is like from culture mindset change.
So finally this is like a summary of the culture of the DevOps culture, automation, lean measurement and sharing. So this is what I would like to, you know, kind of like just sum it up. Okay, let's dive deep. So our agenda for today, I'll touch like two, two topics. The infrastructure, infrastructure orchestration, this is where microservices, serverless and security cloud architecture containers. However, containers will be a bit in the second more and second will be the operations where we'll touch on cloud ci, cd and monitoring at the protection and security management. So first of all, this is more like the operation side of things. There's a couple of technologies being introduced, introduced with the DevSecOps, always the DevOps in our kind of framework. Microservices were fitting perfectly with the idea of producing more features, streamline the process. Why? Because you have the Monodic app, you divide it, you have little features, so everything can deploy his feature whenever they want, can patch it whenever they want and it's much easier to, to manage in this way.
So this is a very, very good, you know, kind of example and then came the containers, it fits naturally with this. So you have each microservice as a a container itself. You can just deploy and and manage the microservice by one container or sometimes multiple containers, but it fits naturally with this. So there's advantages having this technology coming together and it's like, you know, kind of making the, the, the process streamlined. However, there is a change in the security aspect of this. So when we used to have the application, this is like just sample of application, this is how we used to be. You have the client accessing load balancer or what whatever you have as a, as a frontier. And then you have the public subnet and the private subnet where database or whatever and you have sub couple of controls on each, each layer.
However, when it change to microservices, how do you expect the, the the thread vector or the, the, the, the architecture of the, of the, of this solution can be, can be really complex. You have introduced yourself to a new sub of, of issues and, and and the threat vector that can be introduced even internally on your application. So it'll be something like this. You have even external issues and also internal cuz you know, you have, you have to link all these services together and they have to be configured well whenever, you know, whenever you change something on one service has to be integrated nicely in the other services and such. Obviously this was resolved a little bit with the, with the API gateways introduced from the cloud, you know, technologies. So that can help, but still the, the, the, the security aspect of this solution has changed but not eliminated and it has to be considered and rethinking our minds in this way.
So it can be get, get really complex. This is just an example of Netflix. How many of you notice that Netflix published a new feature and when nobody, it just happened, it just, you know, naturally happened. So, so they divided everything to each, you know, each microservice and they start, you know, to develop each one by itself. And whenever you have the, whenever you have the, there's an issue or security issues just patched automatically on the microservice level. However, this can be get very complex and can be really hard to monitor, hard to secure, hard to track what's going on. This is just another examples of the Amazon, Netflix and, and Twitter, all the using microservices. But just lately I just read an article that Amazon is trying to go back to couple, couple of microservices together and this is kind of like obvious complexity is not easy to handle.
So whenever you, you introduce more components in the architecture, you are having more complexity, more efforts to, to resolve. So it makes sense. Microservices is very good to a certain level cloud technology, cloud first is very good but to a certain level. So always, always when you are thinking on, you know, introducing a new technologies new, a new kind of way of, of deploying, have to consider all the aspects from security side of things. So serverless came then as also supporting these DevSecOps, there's a couple of benefits. So there's no service, there's no server all clean. Whenever you, you know, you you provision, if you have the latest image then it's all good. There's automatic scaling so you can just scale as much as you want. No fault tolerance. It's much easier to to manage and can be combined with API gateway as just mentioned to have fully serverless architecture and there's no expenses in cured so you have no, no cost from the business side, which is beneficial especially considering you know, budget and all these kind of things. So it's makes everything streamlined, best practices, how serverless can be secured. There's a couple of topics here I would like to mention. Serverless in the all time meant to be is the cloud architecture when when you have like any server in the service in the cloud, but lately it's just changed the terminology that it became means the functions, the lambda, the, you know, the the the the services from the cloud which has no servers.
It's important when we approach these functions, it's to have kind of like one source of truth because otherwise just get out of control. So have monorepo where you can track and have policies on this. Try to limit the scope as much as possible. So get the functions to be divided as each one doing one function, one exactly as is one function, one thing to do and try to be sensitive what this function can access. So be granular on the, on the scope of the functions and have a chalk point. So has some kind of way to channel all these functions to a way that if you need it you can stop it. So can be having kind of control over this.
I'll raise here a couple of questions just you know, kind of lecturing awareness what we consider when, when we up deploying cloud architecture. Obviously we're automating because dev DevOps automation as a principle, but what is the security aspect of, of automation? Having credentials in the place in the code, asking the right questions when you are deploying. So is this instances patched? Is there permission limited? Is there remote access limited? Is there firewalls, rules permissive? So all this question has to be asked before or when you are deploying your, your infrastructure. Couple of other questions. Is the packet is correctly configured? Is there is profiles and initiated roles with other services? Security group is misconfigured to allow un SSH cloud formation updated to be using the latest IM MI and immutable infrastructure doesn't needer remote SSH obviously trying to leverage immutable infrastructure as much as possible, which means there's no changes on this infrastructure, it has to be as is when it's deployed and is your load balance using tls?
So this is just the questions or type of questions you might ask your team when you are using or deploying this kind of framework. Let's go to the other section which is the streamline the process with C I C D and the monitoring that protection. So I noticed many of the enterprise, they say they are using DevOps but in reality they are not. They are in some way between. So just here to share with you what each stage means. So if you are doing agile, that's code and build that's right, which is many of organizations already using it. If you are in the integrated test place then you are continuous integration and then you have mostly the, the ones who say that they are doing DevOps, they are actually doing continuous delivery, which is the, the developers are not doing really in production, they are not pushing features to deploy, but there's kind of like a manual mechanism that you have to do to push deploy, which is like a permission or like a approval from the hire manager that yes this code can be deployed. So this is can be, you know, kind of like mis understood sometimes when you say develops.
Couple of techniques that we can use with the ci. So the test has to be fast, incremental, unambiguous static where you check credentials, dangerous functions or if there's any dependency, then you do the unit test where if the unit is itself functioning from security aspect and then finally a smoke test test, which is for example OAS app can, can work perfectly to have some baseline for your setup. Here I'm sharing with you a couple of tools you can use on each stage. There's the pre-commit, you can use red modeling in this, in this stage and the hooks for theit, you can also do some static code analysis, dependency checks and for the acceptance here when you do the dynamic test, which I'll touch after a couple of slides, acceptance test and infra code and then in production you can use server hardening and couple of other techniques like smoke test and operations. You can hear where you can do the post mode modes where you can review your, your setup and your, your kind of issues which you face during, during deployment.
Here's just an example of just to share with you a couple of tools, however it's really, you know, you can use Azure, you can use any, any other cloud provider, but just as just an example, so when we have a SaaS scan, there's a couple of options and you have to understand that this was the developers. So for example there is Jenkins here where you can take advantage of the hyper kind of setups. So you can use, you know, on, on-premise and on the cloud at the same time. But it has some issues with managing two environments. So you have your cloud environment, you have your on-premise environment, so it have to be, you know, extra resources. There's the lambda function where you can just invoke, but at the same time Lambda has limitation on the memory and on the CPU usage. So it, you might consider this and it's limited with the languages as well. And there's the code build which can streamline with the, with the code pipeline already from Amazon, which is integrated perfectly with Amazon. But also, you know, it has a couple of limitations like how you can manage the code inside this code build tool.
So for the dynamic test here you can ask a couple of questions where to run this, this test or the pen test and how to run it. So would you run it internally part of you know, your development team or you will do it like externally part of you know, some third party. You can also consider if you would do it internally or like on the container level. So part of the pipeline cycle or you would like to do it after the pipeline finished. You do kind of like outside pen test or scan. You can do it also on the, as I mentioned on the container level or you can do it on the WAF or the IDs or or the load balancer level. Finally, here's a couple of techniques that you can use like gamification obviously just try to, to kind of have this energy with the engineers that yes you can do some games to find out what vulnerabilities you have in the code.
So this can really help and myself like empowered by challenges. So this is really helps in general to facilitate this here. Sharing with you a couple of slides about the, the continuous delivery cycle and where you can have integrate your security tests. So here's like an example for containers where you have do file scan and container signing, registry check, smoke test and that scanning the final end. Here's another sample as well which you can use as to highlight couple of stages where you can implement your testing schema. Obviously I have to monitor this so logging and tracking, try to collaborate this information with the network infrastructures with IDs, WAF or rasp you have antio graph and report is to have some visibility of a normality or some issues that you can, or high trend spikes that you can find interesting and so you can resolve easily.
This is a couple of highlights regarding data protection. Try to explore the solution which you have in place in the cloud. Try to integrate this with identity and access management. Try to architect these components to be working nicely together and finally encrypt as much as possible in rest or in transit. Regarding circuit management, you can enforce policies, use secret vault plan to expire and to retain the secrets and pipeline the code change considering security. Finally preventing secrets in code. Look for look for secret manually try to automate this as a scan and use custom grips if if possible. And finally use as much as possible plugins that you can use even pre-commit the code. This can use plugins or hooks in place. Finally, there's isn't just an example of secret keepers and Vaults Hash Corporation have a good solution for this. So you can just use the tokens provided from Hash Corporation and you can just implement this in the pipeline. This is just to mention that when you are considering cloud, there's much better ways, you know, this is, it's just not like, okay, Amazon, because I like the, the logo of Amazon and just go with it. And that's it. You can scan the code to, to get the presentation and to get in contact with me and thank you. I hope that was helpful and informative for you. Thank you. Thank you very much.
