 Well, hello everybody and welcome again to another OpenShift Commons briefing. One week after the OpenShift Commons gathering in Seattle, so we're glad you've all joined back and are ready for another one. Today we're going to talk about DevSecOps, another acronym, but hey, Security Injection with Secure Puzz on OpenShift with Shadowsoft and Eric Sutherland, who's going to talk about some cybersecurity concerns and how to address those in the DevOps world we all live in now and demonstrate how using Secure Puzz, the Shadowsoft offering, can help on OpenShift. So, without too much further ado, I'm going to let you all introduce yourselves over there, Derek, and if you have questions, post them in the chat, we'll try and answer them online. And then once Derek is done with his presentation in demo, we'll open it up for Q&A. Thank you all for joining us again and Derek, take it away. Thank you, Diane. Hi guys, my name is Derek Sutherland. I am an engineer and a solution architect here at Shadowsoft. I have helped lead and co-develop in a lot of ways, Secure Puzz from kind of the ground up. What we're going to be talking about today is the idea of incorporating automated security into a DevOps lifecycle. Some of you guys may be familiar with DevOps, some of you may not, so we're going to walk through just kind of a brief overview of some automation tools that fit into the space, the idea, and what kind of efficiencies it's brought through its inception. Before going into it, I introduced myself, but I want to introduce our company a little bit just so you guys are familiar with who we are and what we do. Shadowsoft, we're an open source integrator. We were founded in 2008. We have offices currently in Atlanta, Georgia, rest in Virginia, and we service a lot of the Southeast, but we also do work across the entire US, and we're starting to do some work as well in Canada. Our work has led us to have multiple accolades from partner of the year, catalyst partner of the year, and middleware partner of the year from Red Hat's perspective. We've been Puppet's public sector partner of the year. We were a Docker Foundation partner. We've been the commercial and public sector partner of the year for Red Hat. We've won a couple of accolades from doing different things. Our company really specializes in different tools that exist throughout the entire software development lifecycle, cloud infrastructure, cybersecurity, big data. We try and focus a lot on automation and helping our customers get to market faster, cheaper, more lean, trying to help them adopt better practices within their organization, learning how to take advantage of a lot of the new technologies that are out there, and for real all intents and purposes, what we really found are Brent and Butter was trying to help customers see the value in open source products. For a long time, when the company was first founded, it was founded on the idea of really evangelizing open source since at the time, at least, their open source really wasn't talked about from an enterprise perspective all that much. Obviously, now in the last couple of years, it's drastically changed. And we find that's for the better. It's helped drive down the cost to do business and it's helped us, you know, help our customers do things better and drive down cost of products to different customers of theirs. So with that, we're going to talk about SecurePaz and DevOps in general. So for all of you who've been in the IT industry for a long time, DevOps has done a lot of different things in the field. Over the years, we've transitioned from things like punch cards to, you know, the adoption eventually of and creation of virtualization of hardware. And even when we started to get a little bit faster back in the 90s, we still were being held up a lot in our processes from the inception of how do we acquire hardware to setting it up to getting operating since patch and installed manually creating users accounts. It was a really tedious and long process. And for some organizations, it still is. Virtualization helped that a little bit, but it really just made it so we had to get hardware less often, but we still had to handle a lot of the hardware aspect ourselves. Where DevOps and really automation tools from infrastructure to service to configuration management has led us is to environments where we can more streamline the process of how quickly we can get a teammate or a customer up and running inside of their environment with a very few short steps rather than having to go through the process of building out all these individual things each time we want to do this. So DevOps has really helped us lean in that direction. Across DevOps and automation tools has really led to the development and creation as well as adoption of different product categories. I'm sure a lot of you guys are familiar with Ansible, with Azure, with AWS, with Docker, Jenkins tools like that. We have tools that are kind of existing in different areas. And in a lot of ways, DevOps has started to lead to these different competitors and companies forming together to start branching across these categories. Traditional configuration management tools are now also trying to do things like CI CD, they're trying to get involved in test automation. And we at ShadowSoft, and a lot of DevOps practices are really about bringing all these tools together to make them as clean and efficient as humanly possible. The one area that really hasn't been talked about all the much and it's really just starting to be talked about though is cybersecurity. How does the practice of DevOps affect our security footprint? How does it affect how we integrate our tools and how we should be mitigating risk inside of our environment? Does it create more risk? Does it create less risk? How can we best optimize ourselves? So the problem space has really started to grow from a cybersecurity's perspective. We've obviously seen how the news has been broadcasting this from cyber attacks against major companies such as Sony, Home Depot, and the likes. Different types of attack vectors from internal threat to outsider threat from web locations to databases. And it's really because as we're working towards the idea of automating and simplification of our development processes, we feel that in part that's taking us a little bit away from best practices around cybersecurity. It's making us sometimes try and get something out the door really, really fast without necessarily doing all the testing and remediation that we really need to accomplish before releasing a product at times. So what does that mean? It means we need to develop automation tools around applying security and really being able to overview the security of our footprint across our infrastructure and our organization. And it has to fit into a DevOps model. So today, if you're an organization and you're implementing DevOps practices, you know, you're spending a lot more time coding and less time deploying and trying to get your code running, obviously. But if you're taking security in mind, you might still be spending between, you know, 25 and 35 percent of your time just on cybersecurity. Most organizations are, you know, they can't slow down that much. So they're skipping over this problem, which is leading their customers, obviously, to be vulnerable and themselves. So what is SecurePads? SecurePads is not to be confused with a platform as a service. We are a security platform acting as a service. What we provide is a security framework that offers management capabilities, automatically injected authentication, authorization and auditing controls for microservice-based systems. Now, cybersecurity covers a whole slew of things, obviously. There's not really one category, but we feel this is a big category that needs to be tackled in the near term. As we've kind of seen cyber threats grow, we're seeing more and more people attack web applications and web services. Why? Because you can put up all the firewalls you want in the world. You can put up intrusion detection systems, but at the end of the day, your web applications are going to face the internet and they're going to be a direct link between an attacker and your customer's data. So we're really about trying to figure out what's new, unique ways we can automate the injection of cybersecurity controls into our web applications in a DevOps life cycle. How do we do that? Well, for those of you who are maybe familiar with APM tools like Nurellic or App Dynamics, things like this, we've built an auto injection agent specifically that's enabled for Java at this point. We're looking to conquer.net as well as other languages in the near term future. We are already very far down the .net pipeline and hopefully we'll be releasing something in the next coming months. But our agent attaches to a JVM at runtime. It auto detects any apps or services that might get deployed as well as clients and client libraries. And when it sees those things getting deployed, it modifies the code at runtime. Meaning we're not, we don't need access to the source code of the bits. We can access the bytecode when it's being deployed inside of a JVM and make the changes as is necessary. What this allows us to do is it allows us to make changes to your applications and services in seconds rather than, you know, weeks or months and having to go through deep integration processes. This integration application agent talks up to our master server, which has a single sign on portal and audit collection system. It has a server info collector to give us information about what apps and services are deployed so we can write policies appropriately. It has a globally shared access control point, a management dashboard and then a user store that's based on LDAP. So you can talk to Active Directory, Open LDAP, your own LDAP store outside of that. Or you can just use the one that's pre-provided in the system. Now, in regards to OpenShift, OpenShift leads you to be able to take leverage of a lot of these capabilities. You're getting speed to market a lot faster, obviously, to the caveat and the adoption of something as a platform as a service. Where secure paths lies in places that we can actually deliver ourselves as a Docker container inside of OpenShift and then be able to quickly patch your different applications that are getting deployed inside of your environment quickly and easily. So what this gives you is about, you know, a massive inclination of how quickly can we get yourself to market? How quickly can we start operating with a security life cycle management inside of your DevOps or your PlotMesa service type environment? And it gives you that seamless single pane of glass that allows you to monitor all of your apps deployed with inside of OpenShift. With that, this is easily installable. As I said, we can be deployed inside of OpenShift. That's typically the easiest way to do it. But if you're not an OpenShift customer today and you're considering OpenShift, we also have pre-built Docker containers and also this is leverageable via configuration management for deploying the agents as well. That's kind of the neat caveat of what we do. With that, I'd like to get into demonstration. Our code is currently deployed on an AWS test drive. If any of you guys are interested today, let me actually exit out of this presentation and do this. You guys can go to our website at securepass.com, click on Test Drive, enter Test Drive. And as long as you sign up with an account with us, which is free, you can do that at any time, you can spin up an instance of secure pass to try out for a few hours. It has a technical guide that goes along with it. And so you can try this at home and see how you like it. If you have any questions, you can feel free to email me. And if you have any questions for the environment, I will gladly answer them after we start getting a little bit into the details of the demo so you guys can see how it works and maybe pose any questions that might lead your curiosity. So with that, I'm going to start with the demonstration. I've already spun up a test drive instance. So this is a lot what you guys would be looking at. If you used our test drive specifically, let me just grab the URLs and passwords and things. So first what we're going to be looking at is our administrative console. Right now it's deployed in AWS. When you log into any application or any web service or the management console itself instead of securepass, you'll be prompted with this login screen. This can be configured rather easily. It's just some HTML and CSS you can change on your own. So I'm going to log in with the username and password that's auto-generated with my environment. This is going to bring us to our management console screen. And our management console screen allows us to be able to control users and roles that are built into LDAP. You can do audit records for who's done what inside of the environment and you can really quickly and easily start integrating different application servers into the environment as well. To do that, you'd go to system integration. And you're going to type in the name of an app server that's out there to be deployed. And it's some kind of unique identifier to say this is what this does. So for example, we have a demo application server that comes with our test drive. I'm going to open that real quick. This is just a random web app that we've built. It has no code references to securepass whatsoever. You can actually download this demo app off of Vedin's website. Vedin is a Java web framework. For those of you who aren't familiar, we pretty much downloaded it from them. You'll notice it says welcome guest. It doesn't have any context as to who we are though. There's some information on this screen. We have some data points that are located for different parking tickets associated with this demo. We have some shift information regarding what people have been recording, what date and times have been working. Notice the different areas that are displayed from A, B, and C. And we have some statistics that are up here as well. You don't really need to understand the data that's on here since this is just a demo application. We're going to actually show you in real time, though, how we can make changes to this environment and start locking down all these different features. The first thing I'm going to do is I'm going to copy the URL of this web server. Paste it in here. If the app server was running on a different port number, like JBoss typically runs on 8080, we have an Apache instance in front of this, so we're just using 80 as our default port. But you could select the actual port number in there. In this case, I'll call it demo app. Now, to get an agent for this server, you can either call our REST API to grab it or you can grab this link right here and click on this download button. This is going to automatically generate an agent for us that's meant for secure pass. I'm going to hit Save now. This saves the server into our entry list, which obviously the application server doesn't know anything about this system. And that's because our agent hasn't been deployed in that environment yet. So while the agent's downloading in the meantime, I'm going to start opening up an SSH terminal instance to the box where we have to connect. So we're going to connect back up to that web server that we just looked at. So I'm going to pop up a putty instance. Let's do... What's the name of it? Is it EC2 user? And our password. Okay, so now we're logged into our box. It looks like our agent finished downloading. I'm going to leave this maximized for now. Let's open up a one SCP instance. You could use regular SCP obviously during this step. And what we're going to do here is I'm going to copy that agent over onto this box so we can start making changes. Let's look back at my host name again. Now if you wanted to, obviously an open shift, you could push this and change it out pretty easily by using a different configuration for your Jboss instance. You can use a configuration management instance for pushing this out. It's kind of up to you how you want to deploy the agent itself. The purposes of this demo makes it very easy though to just do it this way. So the first thing I'm going to do is go to my downloads folder where the agent was downloaded. Let's do it actually over here. I get a little bit easier for myself. And this is the latest agent I just downloaded. Now to get this agent working on this box is rather simple. So we're going to go onto this host and if I LS here, we'll see there's the agent that I just copied. The first thing I'm going to do is change the root because we're going to be modifying permissions and things. I'm going to unzip this agent. And I'm going to undo it to opt agent. You can put it wherever you want on the box, but this is just where I'm going to be putting it. Okay, now I'm going to change the permissions on this. So it matches our Jboss instance. In this case, it's the user's Jboss or the group Jboss. I'm going to do the same thing for modifying the permissions. I'm just going to make them very, very open. We don't recommend obviously you do that in production. You set them however you should for your environment. And then I got to modify my Jboss startup script quickly to include some Java operations. So what I'm going to do is I'm going to reference the Java agent that we're going to be using in our environment. So I said the Java ops equal to our Java agent, which is included in our package and specified our secure pass configuration was at the same directory. That configuration tells it essentially where to talk to what secure pass system it should be talking to what classes it should include, things like that. So at this point, I'm going to restart my wild fly instance or my Jboss instance, depending on what it is you're running. We currently support any J2E container, so anything will work. As long as you're running JDK 1.6 or later, that is. Okay, so now our system is starting back up. This is going to take a few moments. In the meantime, we can go look at our logs and see if we can see any of these changes occurring quite yet. Zoom down to the bottom to see what we got. We can see actually the agent's attached here on this line and that's going to start making changes throughout our subsystems while it's being deployed. We're currently in debug mode. So you'll notice that it says attempting to load and it specifies these different jar files that are from our agents. As it goes through, it'll detect different apps that are being deployed and then launch them appropriately. So if we go back to our web browser, you'll now notice it says, hey, this is a Jboss server that I'm working with. And if I go back to this application and hit refresh, it's actually going to block me from having access. And that's because I don't have any policies written to access server. This might take a few seconds on the first go around because the changes are still being applied. In the meantime, we can go look at our application and see, oh, it looks like we have a couple of different app servers or apps that are deployed on this app server. So in order to detect these war files, as I said, we'll see an access denied load on the page. But make note of the app we're trying to access in this case, which is Polish demo. So we go back to our list. The war file we're looking at actually is this war file. If you've deployed any ears in your environment, any jars that applications or things, you'll see those here as well. It automatically grabs us through the server container through nothing that's specific to this environment, just using the J2E spec. So if I want to start granting access back to this, what I'm going to do is I'm going to click on Polish demo. And I'm going to look at the main servlet, which is slash star. We could add our own custom configurations if we wanted to add things like picture files or JavaScript files or individual page markers, but slash star refers to everything inside of yours. We're going to use that. I apologize for the resolution issues at this point, guys. As well. It's just I have a very small screen that I'm working with. So bear that with me. So what I'm going to do is I'm going to select the method that I want to try and grant access for. Now these methods refer to HTTP methods. If it's a web app, if it's a soap service, it's going to show you the soap methods that are currently attached to that system. If it's a rest service, then you're going to see HTTP methods again. Because this application is vaden based, it's very chatty on rest. So we're going to be using get and post methods. So I'm going to grant access. They speak yet. My resolution is bought me again. Hang on. Let me move this here for a second. Derek, don't worry too much about it. It actually looks kind of okay for us. Okay, good. So what I'm going to do is I'm going to select the admin user. Just going to try and move this around a little bit as I go throughout because I can't see the next button on that screen. Okay. Now I could make this a role based permission. I can make this a date time based permission. I'm just going to do user based for the purposes of this demo, but you could set it based on whatever parameters you like. Step through that again. And at the review page, we'll say, hey, this is the method. We're going to be writing it for. This is the user. The ID for this policy is going to be randomly generated. And I said I'm going to do that one more time for AC post as well, because that's what's needed for this environment. I'll do that off screen just again, because I can't see the next button while dealing with the resolution. All right. So now that's been completed. We see HP get an HP post. I'm going to hit refresh PDP cash. And what this does is we optimize our environment to not constantly have our agents making web requests to look at policies. So what happens is our agents pull once a minute the latest policy. And if there's been no policy changes, it keeps the most optimized version of the policy. By hitting refresh PDP cash, we're essentially alerting the agent the next time you check in to pull the latest version of our authorization cash. So after that happens, typically about a minute, within a minute, it could be a little bit less, could be a little bit more, depending on what your configuration is. You'll see the changes apply on this server. So I'll hit refresh now. Hopefully it's applied. It has. You'll notice now it's welcome admin because it's pulled that user name from the Java ACP user principle, again, which is not specified through secure passcode. If you go back to these incident pages, though, you should notice that all these data points are still here. And that's because we haven't actually added an agent onto the back end web service. It's applying this information. That back end web service is located at, I'll pull this up real quick, this URL. Now it automatically directs here. It says not found because this is a soap web service and a rest web service. I'm not making any real regular requests on this. So it's not going to give me any visual data here. This is the web server where our soap and rest web services are going to be hosted. I noticed there's a question. So let me just look to see if I can answer that quickly. If not, I'll hold it till the end real fast. So let's just check on it. That was just me asking for questions. So sorry. Oh, okay. Cool. Okay. So what I'm going to do is I'm going to go back to our main server page. I'm going to add another web server. In this case, it's going to be the web server instance. And make sure that matches up 7518 does. And we'll call it demo service. I'll download the next agent that we need for this one. And now I will close out this old putty terminal and I'll open up a new one to the web server instance for this service as well. So let's open that. So it's our agent finished downloading. I'm going to change my one SCT instance as well. And just like last time, we're going to copy that agent across. Make sure it's the right agent. Number three. So now this agent is copied over here. We're going to do essentially the same steps as last time. So a change to root. I'm going to unzip that secure pass agent. I'll change my credentials or excuse me, my permissions for that server. And then we're going to make our Java agent. At this point, I'm going to restart that app server as well. We'll give that a few moments while that comes back up. We should see the change inside of here rather quickly. Close this. So let's do like we did last time. Let's go look and see what changes that are actually being made right now. And if we look down, you can actually see when it recognizes a new service. So you'll notice it'll say, hey, I detected a Jax RS, which is essentially a REST web service implementation. So it injects our cap servlet for controlling that application access. You'll see that happening kind of all over the place. You can obviously disable that functionality of this seeing all those changes in debug mode. And now we're going to go back to here. It changed back to demo so we can now see that it's a J Boss instance. We see both our REST and SOAP services. And if I go here and hit refresh on all these pages, you're going to notice all the data disappearing. And that's because all of this data just like with this web application is now being blocked access. So we have to granularly grant access to all these applications and web services as well. So I'm going to click on SOAP because I think SOAP is a lot of it's pretty interesting to be able to see the individual SOAP methods show up. Specifically, we're going to be looking at the SHIFT web service. There's some other web services that are in here. PYChart, Navy, Marine Corps, and so on and so forth. With that, I'm going to go out of new permission. And this time we're going to see the SOAP method show up. These SOAP methods are associated with the different data fields we saw on the SHIFT screen. So I'm going to grant access to just the A SHIFTS. I'm going to do the same thing as last time. I'm going to make it user based rather than role based. I could make it roles or I could make it daytime though as well. Okay. Now that I made that permission, let's go ahead and also make a REST web service change as well. Now, because this application, the REST web service is built with REST easy. It doesn't outline all the REST URLs. So I have to add them custom, which is actually extremely easy. What I'm going to do is hit this plus sign. Say from the root URL, I know I have a REST web service named A Tickets. There's also B Tickets and C Tickets, but I'm just going to do it for A Tickets for now. And because this is a REST based service, get means read, post means create, put means update, and delete means delete. So I'm going to create read access for that web service as well. It looks like we may have another question popping up, trying to find the screen where I can look at the questions. I have so many screens up right now. I'll read it up to you here. Jonathan is asking, what do you have shown us so far seems to focus on denying access to endpoints by default? What other security controls can you implement? For example, can you automatically redirect to a third party authentication page? You could key closed or OAuth 2 service when someone accesses a service endpoint. That's a good question. So our system is built with SAML in mind. Our identity provider provides multiple types of access control. So you can use things like two factor from you and 2 ASL. You can use OAuth or OpenID Connect for login mechanisms for the login portal itself. If you wanted to direct the login to something completely different than the identity provider that we provide in package, you can have it point to another SAML based identity provider and use that for your authentication mechanism. If it was something in regards to using an OAuth 2 service provider that you wanted to use and have, again, no correlation to our secure pass identity provider, that's something we could talk to you about offline and maybe we can build out a customer implementation for you. Our company is all about open source. We want to help everyone adopt and use the technology as best as humanly possible. So is it possible with the way it's built today to point to a third party authentication page? No. But our current identity provider does provide the ability to use third party authentication mechanisms outside of just the LDAP authentication mechanism we provide out of the box. Does that make sense? Does that help answer your question, Jonathan? Yep. Let's see. Great. Okay. So now that I've created that get policy, I'm sorry, I haven't finished creating it. I was in the middle of doing it. Let me finish creating that ridder quickly. I'm going to just like before, refresh my PDP cache. And I'm going to give it a minute to update so that way we can see the actual page. Now, I must have accidentally closed out my web app. Not a big deal. Go back to that web app. Got a recent incidences and see if we got any different data. Now, as I said, this takes about a minute to update so it might not have been updated yet. We will find out shortly. I'm still loading, so we'll wait and see. In the meantime, I will bring us to the auditing page. And our audits are relatively close to real-time. They're about a minute in discrepancy. But you can get pretty fine granular with this. You can look at what changes have been made inside of the management interface. You can look at what changes have been made to a given application, who's been accessing what. So for example, if I wanted to look at the Polish demo's logs, I can filter on them rather quickly. If I wanted to look at a given web server such as A-tickets, we can see when someone was denied access to it, when someone successfully logged into it, you can kind of get a pretty good instance of who was doing what when. And out of the box, we are only showing the last five minutes, but you can dig down as far back as a year if you wanted to. Granted, the further back you look, the more memory has to be processed inside the browser, so be aware of those types of changes. But it is very fluid in that regard. Let's go back here and try to hit refresh and see. And yep, sure enough, here's our new data that's showing up on that. We go to here and hit refresh. We can now see all the people who've made service tickets that are located in the A zone, not the B or Z zone though, because we haven't granted access to those. And the same occurs on here. We can see all the A-ticket references, but not the B or C's. If we wanted to add the ability to be able to submit a ticket, we could change update permissions to allow for post input, and that would allow us to submit new tickets as well. With that, that's pretty much the end of the presentation of what we can do out of the box today. We're also, as I said, in the process of making this work for .NET, and we're going to be including features such as cross-site scripting prevention, as well as SQL injection prevention and feature iterations of this. Does anybody have any questions for us regarding where our roadmap is? Any questions around how they can use it or thoughts in mind for where they'd like to see this be used in the future? So I don't see any questions coming into the chat. If people want to ask a question, just raise your hand in the chat, and I'll unmute you if you can ask that. Derek, this has been great. Can you put up your slide on how to contact you, and I think you had how to get access to using to do that. Yes, I can do that. So let's do that real quick. If you want to try out the test drive yourself and go through and see all the different changes you can make to this, go to securepass.com, click the test drive button, and sign up for a test drive with us. It's really, really, really simple. If you want to contact us about securepass, you can go into the contact page of securepass and send your information here. You can contact me directly. My email address is dsutherland at shadow-soft.com and if you're interested in more of the stuff that we do as a company and all the services we can provide to you, you can go to shadowsoft.com and view all the different stuff that we have up here and contact us from our contact page as well. Perfect. Well, I think you did a great deep dive into this and we've not getting any more questions. I'm looking for people if you want to raise your hand. So we'll also pop over and if you want to join the OpenShiftCommons.slack channel and you can follow up there and if you're not a Commons member yet just drop me a line dmueller at redhat.com and I will sign you up and we'll get you in there. Thanks again, Derek, for taking the time to do the briefing today and we're really happy to have shadowsoft as part of the OpenShift Commons community. Thank you. We really appreciate the time. Take care everyone and we'll talk to you next week.