devopsy.kinsta.cloud

Tag: security

  • Security Through ‘Legisurity’: Impacts of SB-327

    Security Through ‘Legisurity’: Impacts of SB-327

    With more devices connecting to the internet every day, security through obscurity should have died a long time ago. Still, high-profile cases of devices with mass-produced default login credentials and easily cracked crypto keys persist. As a result, say hello to security through “legisurity”: California SB-327—“Information privacy: connected devices”—became law Sept. 28. How will this impact DevOps teams?

    What SB-327 Does and Doesn’t Do

    Here’s a quick look at what SB-327 does, starting with its timing and scope. The provisions go into effect Jan. 1, 2020, giving teams a little more than a year to prepare compliant connected device designs. The legislation defines a connected device as one “… capable of connecting to the Internet, directly or indirectly, and that is assigned an Internet Protocol address or Bluetooth address.” Authentication is “… a method of verifying authority of a user, process, or device to access resources in an information system.”

    The operative passage in SB-327 calls for a “reasonable security feature … appropriate to the nature and function of the device.” (Before you get too excited, it explicitly shuts the door for individuals suing manufacturers over non-compliance.) With implementation left open, the legal standard is very clear. Reasonableness is a device with features meeting either of two requirements:

    “(1) The preprogrammed password is unique to each device manufactured,

    “(2) The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.”

    Also written into SB-327 is a list of things it does not do. The law does not extend these requirements to third-party software a user installs, and it does not force retailers or software providers to review compliance of a device. It doesn’t apply to devices sold only to federal agencies or the military, and it yields to HIPAA requirements. It does not permit manufacturers to hinder law enforcement agency access to a device with these required features.

    What Should DevOps Do Now?

    As with most first attempts at legislation, the unwritten implications of SB-327 may be even more interesting. Here are a few things I see changing for DevOps teams securing devices and infrastructure:

    • SB-327 only applies to devices sold or offered for sale in California. However, setting up California-only design efforts, supply chains and customer support would be costly. (For $20,000 cars? Sure. For $200 devices? Not so much.) Practically, I see these becoming de facto requirements nationwide by the 2020 rollout. Companies should start now to be ready.
    • If you’re a device manufacturer, you should add both requirements into your minimum viable product baseline, if you haven’t already. You’ll obviously need a strategy for assigning and tracking default passwords and a crypto key authentication method for setup connection. Customer support procedures and documentation also need to change. Consider using one-time programmable non-volatile memory or PUFs (physically unclonable functions) to establish a unique device identity.
    • On the deployment side, you’ll need added tracking for unique default passwords in your device provisioning database. Your customer support teams will need device-specific information at their fingertips to get new or factory-reset devices back online quickly. Crypto key authentication methods will be a more important criterion for device evaluation and selection.
    • If you don’t have a good UX person and an experienced pen tester on your team, hire or contract those roles right now. Simplicity with security is always going to be the right answer.

    More Laws Ahead?

    Will the debut of “legisurity” satisfy lawmakers and stem connected device breaches? My guess is this is only the beginning; SB-327 does nothing about requiring stronger passwords or thwarting more sophisticated protocol-based cyberattacks. The main point of SB-327 doesn’t seem about securing a single device, although it should help; rather, it’s trying to prevent rapid compromise of an entire population of that device. (Pro tip: whatever you do, don’t use a device’s MAC address in a simplistic algorithm, or you’ll end up like this sad, not-so-smart lock story. Cracking one device cracked them all.)

    For the more curious, here’s the entire text of SB-327, and some other analysis on legislative proposals at the federal level. What are your thoughts on SB-327, how you see it affecting DevOps, and if legislation is the right path for securing connected devices?

    — Don Dingee

  • WhiteSource Raises $35M to Mainstream Open Source Security Management

    Accelerated revenue growth, tripling YoY, underscores rapid market adoption of automated Open Source management

    TEL AVIV, Israel, Oct. 17, 2018 /PRNewswire/ — WhiteSource, the leader in continuous open source security management, announced a $35 million funding round led by Susquehanna Growth Equity, with participation by existing investors 83North and M12 – Microsoft Ventures. This $35 million Series-C adds to the $11 million raised by WhiteSource in previous financing rounds.

    Founded in 2011, WhiteSource was created with the mission to help businesses harness the power of open source without compromising on security or slowing development. With the latest funding, WhiteSource plans to double down on serving the enterprise market where leading customers such as Microsoft, IBM, Comcast and KPMG already leverage the WhiteSource platform.

    Open source has become the main building block in modern applications, and it is almost impossible to develop software at today’s pace without it.  However, as the open source community grows, and the number of reported vulnerabilities keeps climbing, manually verifying the security and compliance of open source components can no longer provide the necessary control over the security of these components.

    “We are now at a stage where the question is not whether or not to use open source components, but how to put in place the solutions and policies to manage them well,” said Rami Sass, Co-Founder and CEO of WhiteSource. “Microsoft’s acquisition of GitHub for $7.5B showcases that companies have accepted open source as crucial to the software development process, but incidents such as the Equifax data breach underscore the necessity for all companies to protect their products from attacks that would exploit the open source components they are using.”

    This reality is the fuel behind the incredible growth of the Software Composition Analysis (SCA) market which automates open source components management. This market quickly transitioned from early adopters to the early majority over the last 18 months and is now becoming mainstream. Serving more than 500 customers today, WhiteSource has established itself as the leader in the SCA space with the first continuous, automated open source management platform.

    WhiteSource continues to gain attention for its ability to think beyond the abstract concepts of security and compliance and has delivered capabilities that answer the business needs of development and security teams alike, as it has proven with its latest revolutionary offering, Effective Usage Analysis, which reduces open source vulnerabilities alerts by 70%.

    “WhiteSource has established the standard for open source security solutions with its strong leadership and breakthrough innovation,” said Martin Angert, Director at Susquehanna Growth Equity. “We are excited to join WhiteSource on their journey to help businesses develop better software, faster.”

    With offices in New York, Boston, and Tel Aviv, WhiteSource is planning to further expand its reach with the opening of sales, marketing and customer support operations in London and San Francisco as well as additional locations for global expansion.

    About WhiteSource

    WhiteSource is the pioneer of open source security management. Founded in 2011, its vision is to empower businesses to develop better software by harnessing the power of open source. WhiteSource is used by more than 500 customers worldwide, from all verticals, and sizes, including 23% of Fortune 100 companies, as well as industry leaders such as Microsoft, IBM, Comcast and many more. The company has been recognized by Forrester as the best current offering in its Software Composition Analysis (SCA) Wave™ report. For more information, please visit www.WhiteSourceSoftware.com

  • DevOps Chat: disrupt:Ops Brings Security Closer to DevOps

    DevOps Chat: disrupt:Ops Brings Security Closer to DevOps

    Shifting security left during the software development process can be tough for companies because of the sheer number of operational things that go along with implementing security that must occur somehow in the realm of DevOps. It can be easy to lose control over their security processes without some sort of guardrails in place to help.

    A brand new company is helping do just that. I’m excited to introduce disrupt:Ops, which bills itself as a guardrails platform to help companies include and enforce best practices across security and operations, bringing security into the DevOps process at the beginning. My friend Mike Rothman, disrupt:Ops co-founder and president, joins me in this DevOps Chat to discuss the vision of his company and how it hopes to help make security truly a part of DevOps.

    You can read more about disrupt:Ops and their guardrail approach to cloud security and devsecops from another co-founder of the company, my friend Rich Mogull at https://devopsy.kinsta.cloud/building-great-cloud-security-guardrails

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Breaking some big news today on DevOps Chat, the launch of a labor of love of some friends of mine. I’m happy to be joined by Mike Rothman, cofounder and president of disrupt:Ops. Mike, welcome.

    Mike Rothman: Alan, it’s great to be here, thanks. It’s always fun to catch up with old friends.

    Shimel: Yep, and old friends it is, Mike. We should let our audience know – maybe we shouldn’t let them know. But we are old friends. We go back a long time now, back to the beginning of blogging and security –

    Rothman: That’s right.

    Shimel: It’s got to be 2004, 2003 or something like that.

    Rothman: Yeah, that’s right, that’s right. When I had dark hair. Actually I didn’t have dark hair back then, but you know, it’s –

    Shimel: I had hair.

    Rothman: You had hair. That’s right.

    Shimel: I had hair. But you know what, Mike? I said it was a labor of love and everything else. Just in the way of background, why don’t you share with our audience your personal sort of journey in tech and, you know, work history.

    Rothman: Well sure. I started out, God, in what feels like 100 years ago, as a mainframe programmer. Ended up doing some local area networking stuff. Kind of found my way to network security. Went into research for quite a while. Did a couple of companies and then went back to research and for the last 10 or 11 years at this point I’ve been partnered up with Rich Mogull and Adrian Lane at Securosis, doing a bunch of kind of information, security-centric research. And actually about a year and a half ago we spun out some technology that we had prototyped within Securosis in cloud management and cloud automation into our new company disrupt:Ops, and have been just making a lot of progress over the last year with that. And that’s what we’re announcing this week.

    Shimel: Yep. So Mike, you’re being humble. When you say you did research, you were an analyst at Giga, were you not?

    Rothman: META Group, yes. META Group, exactly.

    Shimel: META Group. And then you were also – you had executive positions in several cyber – we didn’t call it cyber – infosec companies back then. 

    Rothman: It was. Yeah, you bet. So companies like TrueSecure and CypherTrust, you know, back early in the e-mail security days. I did a network monitoring company called EIQ. So yeah, I’ve been there, done that. Have the road rash and kind of the screw-ups under my belt to prove it. But you know, it’s interesting in terms of just how long and how small an industry security is for being actually a really big thing nowadays. 

    Shimel: Being so big, yeah. It really is. And Mike, again, for many people in our audience who come from DevOps or even from security – but they’re worldwide and they not be familiar with Securosis. You know, Rich Mogull comes over from Gartner. Adrian’s been CTO at major companies. You know, you guys are probably the leading, let’s call it independent security analyst research firm – you said 10 years-plus. Certainly in my time you guys laid the fundamental kind of – a lot of the fundamental backbone of what Cloud Security Alliance teaches and so forth. 

    Rothman: Yeah, that’s exactly right. So it was interesting. So I guess it was probably eight and a half years ago we partnered up with the Cloud Security Alliance and helped them build their curriculum for their CCSK certification. And that got us to be much deeper than your typical analyst in terms of having to play around with cloud, having to understand automation, having to build a number of the kind of scripts and – I’ll call it the inherent messiness of building out a stack in the cloud and really making it operational, because we were eating our own dog food. Our website, a lot of the stuff that we had prototyped was really demonstrative of the challenges that organizations face as they move a bunch of their stuff into the cloud, and really as they embrace a DevOps mindset of trying to be agile, trying to be innovative, trying to move towards more of a continuous type of deployment model. We really came across a number of the challenges these organizations have in terms of just really maintaining control, right? Once you have multiple DevOps teams doing things in multiple kind of accounts, you start to run into challenges relative to how you enforce best practices.

    And that’s really one of the challenges that security people have with this whole DevOps revolution, which is, “Hey, this sounds great, but we’ve got a playbook, a set of practices and policies that we really require all of our environments to adhere to in order to protect that data.” And obviously the faster you move, the more agile and continuous you try to operate, the harder it is to enforce those best practices.

    Shimel: More about that in a second. You touched on two things there that we’re going to dig into. Let me just finish laying my groundwork. Mike, besides you, Rich and Adrian, the Securosis gang, there are at least two other key people on the founding team of disrupt:Ops who also happen to be friends of ours for years –

    Rothman: Yeah, that’s right.

    Shimel: Give them their due. Why don’t you give them a shout out?

    Rothman: You bet. So back when we spun the technology out of Securosis, we brought on two guys, very experienced guys in the security space. Our CEO is Jody Brazil. So Jody was a cofounder and long-time CEO of a company called FireMon, which I know you’ve done work with for a long time –

    Shimel: Sure.

    Rothman: So Jody kind of is really the driving force behind a lot of what we’re doing at disrupt:Ops. And our CTO is a guy named Brandy Peterson, another longtime security professional. He was actually the CTO of FishNet Security for 15 or 16 years.

    Shimel: As was Jody before Brandy, right?

    Rothman: Yeah. I met both of them around the same time.

    Shimel: Yes, when I first met Jody, he was CTO and FishNet, and he said, “Who is this Jewish guy with the New York accent?” I went out to visit him in Kansas City to tell him why you shouldn’t use Qualys, and he should use StillSecure, and he made fun of my accent. [Laughs]. Good times. Anyway. But Mike, let’s turn back to a couple of things you were saying about kind of the genesis driving disrupt:Ops. You touched on one thing; you said, “multiple DevOps teams.” So this is something we see, and I call it almost second-generation DevOps. You know, when a company or an organization is first embarking on their DevOps journey and they do sort of a trail balloon, and they pick a project and they have a DevOps team – you know, and they may not call it DevOps. They  have a team that’s practicing DevOps sort of principles on this one particular project. And oftentimes, wow, great success, because you are – you know, it’s an isolated environment, right? In some ways you’re not in the quote/unquote real world.

    And then you say, “This is great. Let’s take it out. Let’s expand that beachhead. Let’s expand the bubble.” And all of a sudden – you know, larger organizations; small teams or smaller organizations not so much, but larger organizations – now you start having two, three, four, six different projects that are being run with a DevOps mindset and you have multiple instances of Jenkins and you have three different – this team’s using Puppet; that one’s using Chef. And serverless. And all of the complexities that we see in today’s modern software factory. And it’s chaos, right? And then at some point the CIO or VP or director of IT says, “Oh my God, this DevOps thing isn’t working so good. It’s all over the place.” Let alone the security guy’s screaming, you know, right out of the Phoenix Project, “No, no, no!”

    Rothman: That’s right.

    Shimel: And that’s a problem that we see with a lot of second-gen, if you will, DevOps installs, where it goes beyond the initial team to several teams.

    Rothman: That’s right.

    Shimel: That’s what you guys see.

    Rothman: We do. And it’s interesting, because what you have are really kind of two paths at that point, in terms of how these teams start to behave when starting to be put under scrutiny in terms of, kind of again, their ability to enforce operational and security best practices. You know, one group kind of buries their head in the sand and continues to move forward and really don’t do much, right? They’re like, “Oh, it’s okay,” and you know, they’ll maybe run a vulnerability scan to kind of prove that they’re sort of within policy, but they really don’t have an operational environment that is built to work in concert with the rest of their factory. I love that term, right? That really does encompass a lot of how software is being built today. And then the other part ends up being folks starting to build their own scripts, right? They take maybe an open source-looking thing, they start to build a bunch of their own scripts and code around it, and then what they find is they’ve got a suitcase full of these scripts that they end up having to maintain, upgrade. They don’t have any means of reporting or any scheduling for how they enforce and run a lot of these scripts.

    It’s really – you know, we call it automation, but it’s manual automation, which I get is a total oxymoron. But that’s really how it is. You know, you have a bunch of folks, they’re building these scripts out, they’re executing them manually or through very simple triggers, without any means of maintaining, upgrading or scheduling or reporting on what these really key aspects of their operational environment are doing. And it becomes, again, a big problem, where you have – it’s unwieldy because of just the sheer number of things that are happening in a modern DevOps environment with multiple teams. Then you compound it with a number of very tactical scripts that are built to surround the environment, if you’re doing anything. And then at some point somebody says, “Hold on a sec, folks. This is just not where we want to be. We really need to think about it more from an operational excellence perspective and make sure we’ve got an environment that we can enforce our best practices for security and operations.”

    And that’s kind of when they get the sense that, “Well, I’m either going to have to make a significant investment in this and become like” – Rich calls them the unicorns of cloud land, right? You know, the Netflix and the Capital One and, you know, the folks who have whole teams of environments that are building tools to do this. Or they have to start looking for some kind of commercial option, because there really is no option, but you’ve got to do something. You can build it yourself or you can look to buy it. And candidly, until the last handful of months, there really wasn’t a realistic commercial offering to start implementing some of these capabilities.

    Shimel: No, no. I think the bigger – you know, a lot of what you’re saying certainly obviously rings true. The other fundamental piece of this is, even if you are using one of these homegrown, cockamamie, you know Rube Goldberg kind of things –

    Rothman: Yeah.

    Shimel: – is it the security guys who are? You know what? Shame on me. It’s not the guys. Is it the security team who’s doing this, people? Is it the DevOps cross-functional team? Is it a little bit of both?

    Rothman: Yeah, yeah.

    Shimel: You know, how many of – look, here’s my basic, fundamental belief. You are not going to find a developer who raises his hand who says, “I want to write shitty code. I can’t wait to put something insecure out there.” No one says that. No one says that, right? They’ll tell you they’ve got time pressure, there’s pressure to release, pressure to release, they wish they could do more on security. And some of them, the enlightened ones, as you said, they’ll even try. They’ll run a vulnerability scan, because there are certainly open source kind of tools out there for them to mess with.

    The problem is, they go to a lot of the security guys, and as you alluded to before, security guys say, “Well we have our rules and procedures here. This is a no.” Right? And they don’t want to hear no. They’ve got to go.

    Rothman: You know, what’s interesting, Alan – I want to hit on a couple things that you alluded to there, because they’re important, right? The first is kind of where you start to see the agitation for better operational and security practices. And it’s not that it’s not the security folks. Obviously they’re always going to push for that. But it really is – you mentioned it, right? The DevOps teams that we’ve worked with, they’re very cognizant, they’re very serious stewards of kind of the corporate data, and they want to do the right thing. But in a lot of cases they don’t know what to do, right? So you have a whole bunch of folks who don’t know what they don’t know and they don’t want to go to the internal security team because of a lot of those things you were just alluding to. They’d say, “No, we can’t do that. We have all of these rules.” And in a lot of cases the security team has not updated their set of conditions, their set of policies – 

    Shimel: Exactly.

    Rothman: – to work in a DevOps type of environment, so these folks really struggle. They talk to – again, on the consulting side of our house at disrupt:Ops, we do a lot of work with those teams in terms of helping them understand what cloud native architecture looks like and how to integrate cloud security into their environment, and really just to help them build a program in order to do that. So then you do that with one DevOps team, then you end up talking to another DevOps team and maybe the third DevOps team, and finally IT, at some point, they’re like, “Um, what are you telling our folks? They seem to like what you’re doing and they seem to be doing things in a more secure way. So can you help us?” And then IT starts to get religion. The security team starts to get a little bit of religion about what they have to evolve to. And it really is kind of that interesting transition where it has started kind of out in the DevOps community with, again, those enlightened ones going, “I don’t know what I don’t know. Let me get some help,” and then it kind of back-ending into security. That’s not always the case, but probably three quarters of the time, that tends to be the transition that we see.

    And the other thing I want to hit is just about velocity, right? JA very forward-thinking DevOps leader that we’re working with, he said it the best. And he’s just like, “I’ve got 20 DevOps teams. I cannot slow these people down. They are doing stuff; they are making progress. The last thing I can do is put a bunch of onerous security requirements on what it is that they’re doing. They’ll ignore me, they’ll go around me and that’s counterproductive. I can’t do that. What I really need is to be able to build and enforce a set of guardrails around their environment.” Right? That term, “guardrails?” It just really kind of opened up and was a light bulb in our head when we were having this conversation. It’s not about stopping them from doing things. If anything, it’s about allowing them to go faster, yet making sure they don’t drive the car off the road, right?

    And that’s really the metaphor that resonates relative to what we’re doing at D:Ops, and really just kind of where the environment is going, in that we have to be able to move faster. Slowing things down is not an option, yet you want to make sure that you are not putting corporate data at risk. You are not opening up significant new attack services just – because people are moving so quickly. Sometimes they make mistakes. Sometimes automation isn’t done in the perfect way. Sometimes humans get involved and certainly are fallible from that standpoint. But with a lot of the inherent, underlying automation orchestration that’s possible within the cloud and DevOps and continuous, you have options to enforce these best practices in a way that we couldn’t do in our traditional data center with our traditional waterfall types of development and operational motions.

    Shimel: Absolutely. And you know, Mike – I mean, I’ve spoken about this a lot at various conferences and stuff. A lot of that has to do – you know, we use this term “shift left” in security and all that. A lot of it does have to do with getting to security earlier, faster. Yeah, we’re going to have to automate it. Yes, we can’t be the roadblock. But we can be the appendix after – when I say, “we,” I mean security. We can be the appendix after the delivery or after the deployment.

    Rothman: I’ll raise you. I see your point and I’ll raise you one, right? I’m of the opinion that security isn’t a thing. Right? Security should be within everything.

    Shimel: Yeah.

    Rothman: And that’s really the mentality that we’ve been trying to push on the industry for a long time.

    Shimel: Amen.

    Rothman: And it’s one of these things where we really can’t afford to wait and be in a position where we’re trying to retrofit poorly architected systems that are moving faster than we’ve ever seen before and then say, “Oh hey, we’ve got to change it because of security,” or because of any other operational gap that we see there. Right? What we have to do is be building in a way that allows us to use architecture as security control, right? Isolation, segregation, multi-factor authentical, identity management – all of these things that are fundamental building-blocks of what we do in the cloud and DevOps can be utilized to build in a much more secure fashion. And it’s really about those kinds of practices that are going to make the biggest difference relative to what it is that we see and what it is that we deploy over the next couple of years.

    Again, like I said, I don’t think security is a thing five to seven years from now. Because if it’s not embedded within everything that we deploy, we screwed up.

    Shimel: Yep. You know, I heard – because I never come up with original ideas. I just listen. But I heard something awhile back – “Security needs to become synonymous with quality.” And we’ve had QA as a concept in software technology forever or for a long time. Security needs to be just built in, like as part of the quality control. Right? The same way shit or stuff gets tested, whether it be hardware or software or whatever. Security needs to be part of that quality. 

    Rothman: You bet. To use a software term? Right? Why is a functionality defect different than a security defect?

    Shimel: Exactly.

    Rothman: Right? And they should all be within the same thing. And again, that’s a lot of when you start talking about immutable, when you start talking about kind of building security testing into your pipeline, which again, is stuff I know that you guys at devopsy.kinsta.cloud write about quite a bit. Again, it’s really not any different than you managing and making sure that you hit your functionality kind of specs from the standpoint of just building code, right? Part of that factory. So yeah, the code has to work, but it also can and should be secure, and there really aren’t different operational motions to make that happen. And that’s what’s so exciting. For a guy who spent 25 years trying to retrofit and get people to think about security as part of their core structure and to treat it as really a business function, it’s really enlightening to be in a situation where you actually can implement a lot of those functions within the core processes that you use to develop the technology.

    And again, are we there yet? Of course not. Is there a lot of education to be done? Without a doubt. But we at least have the option now, right? That’s the aspirational goal to what it is that we all do every day, which is to make sure that we’re pushing for the right types of decisions to be made as early in the process as we can, because we all know how much it costs to fix it later.

    Shimel: Absolutely. Mike, I’ve got to tell you, listening to this conversation, I’m thrown back to, “NAC: is it a feature or stand-alone?”

    Rothman: You’re dating both of us, man. Stop that out. Cut that out.

    Shimel: It’s such a pleasure to talk a little theory here with you. But let’s turn for a second to real stuff. Not that what we’re talking about isn’t real. But I wanted to give our audience a little bit of a taste – so disrupt:Ops – great people, great big problem to tackle out there. Give us some specifics. What are you guys doing?

    Rothman: Yeah, so what we’re doing is we’re basically building a cloud management platform to implement a lot of these ideas that we’ve been talking about for the last couple of minutes, Alan. Initially it’s a guardrails platform. So what we have is the ability to, in an AWS environment, enforce a set of best practices across security, operational and also cost management. So one of those things we don’t talk about too much is that developers don’t really like to shut their stuff down because, “No, it’s going to mess with something. I don’t have to. The CFO bitches but we don’t really care.” What we can do is also implement best practices in order for folks to clean up their room, right? We try to do that with our kids all of the time, too. You know, so we try to do that with our developers as well.

    So really implementing a platform for security, operational and cost management guardrails, to again, immediately not just find the issues – there are a lot of tools, as you said. A lot of vulnerability scanners can kind of look at your cloud environment and tell you you have problems. The issue with that is that most operations people are overwhelmed with the number of other things they have to fix every day. Adding more stuff to their list doesn’t really help them. So disrupt:Ops is really focused not just on finding the issues, but also fixing them and enforcing those best practices. Let me give you an example of that. So let’s just say some person decides they want to open up a server to the internet because it’s just easier for them to do that. Well obviously that would be a pretty significant security problem. So as opposed to just taking that server offline, what you can do is you can basically change the security group to make sure that it’s only accessible via a known, good IP address range within your corporation. That’s a good example of a guardrail. Or making sure that you’ve got MFA turned on for every account that gets spun up by your magical Terraform environment that may not build that out as a core security requirement.

    So again, there are 50 to 60 of these guardrails, in effect, that you can implement in your environment, to again, make sure that you are not just alerting when you get out of policy, but actually fixing the issues, in a lot of cases before you even know they’re issues, so that you’re not sitting there trying to pick up the pieces after half of your data is in Chechnya.

    Shimel: Exactly. Or Romania.

    Rothman: Or Romania. It’s somewhere.

    Shimel: Mike, how is the offering packaged? Is it a SaaS kind of offering? 

    Rothman: Yeah, it is. What we found is since – you know, remember the days where people were like, “Oh, I don’t know about this cloud thing or SaaS. I’m not sure I’m comfortable with that”? Now it’s like, “Wait, you want me to install software in my environment? What? What’s wrong with you?”

    Shimel: That would be kind of oxymoronic for a DevOps tool, but –

    Rothman: That’s right. That’s right. So we deliver as a SaaS service. It’s actually a very cool kind of one-click provisioning process where, when you’re logged into your AWS account, you run basically a cloud formation script that really kind of gives us cross-account privileges to your environment. And again, we’re security guys, right? So at the end of the day, we are basically not even just assuming but enforcing least privilege. So we only have read-only access. When we need to make changes, we grant the privilege as we need it, then we revoke it. Because again, what we’re trying to do is make sure we enforce operational best practices; not add more attack service. So again, we’ve built the environment to be secure by design. We use all of our own dog food, to make sure that we are adhering to kind of common best practices. And again, we’re all 25-plus years security folks, so we do take that pretty seriously.

    Shimel: Excellent. Mike, for people who maybe want to download – not download, excuse me – sign up for it or check it out more, where can they get more information?

    Rothman: Yeah, disruptops.com. So by the time you hear this little interview, the site will be live. There’s a place you can sign up. You know, first we start with a demo and show you what it’s about and then you can sign up for early access. And again, we’re kind of expanding towards the end of this month, in October. We’re going to add a bunch more folks to the system with the goal of kind of being ready to actually sell the product by the end of the year.

    Shimel: Fantastic, man. Well, I don’t have to tell you, Mike. I wish you, Rich, Adrian, Jody, Brandy and the rest of the team nothing but success. We’ll be checking in, I have a feeling, pretty often here, whether it be through Security Boulevard, devopsy.kinsta.cloud, Container Journal or what have you. And you know, fantastic. It’s good to have you back in the game.

    Rothman: Yeah, no, I’m excited. Again, really it’s not just a big promise and not just a huge opportunity. You know, and what Rich, Adrian and I, and now Jody and Brandy have always done is – you know, we’re trying to do the right thing to evolve the practice. Right? And that’s what it’s about. It’s a big world and there’s a lot of opportunity. There’ll be a lot of folks talking about guardrails over the next year. And that’s great, right? Because what we want to do is get to a position where we can move faster but move more securely, and I a lot of cases, in the world that we grew up in, those were counter indicators. Right? You couldn’t move fast and be secure. You couldn’t do operational excellence and make sure that you’ve got a lot of these things enforced. And now you can, and that’s what’s really exciting to us. Again, we’re just excited to partner with you, as always, and again, just go out and solve some bring problems for a lot of organizations.

    Shimel: Fantastic. All right. Mike Rothman, president and co-founder of disrupt:Ops, a hot new entrant in the DevSecOps space, with a great pedigree and a real reason for being our guest today on DevOps Chat. I hope you’ve enjoyed this. This is Alan Shimel for devopsy.kinsta.cloud. Until next time, everyone, have a great day. Bye-bye.

    — Alan Shimel

  • Integrating DevOps: Avoid These Common Mistakes

    Integrating DevOps: Avoid These Common Mistakes

    DevOps, as the name implies, is a combination of two professional teams—software development and the IT experts. Both the teams collaborate well with the aim of creating a bridge that accelerates and automates the process of software development and a more intensive testing before releasing it into the market with high confidence.

    DevOps has been identified as a software engineering culture that relies on philosophies and practices to bring more agility and improve the organization’s efficiency to cater continuous delivery and integration.

    Now, with the introduction of DevOps culture and transforming trends, the development and operations teams no longer work in isolation. In fact, the role of the DevOps team is also to keep an eye on the software development and manage the infrastructure.

    Many organizations have already begun using the DevOps, while various others are on their way to implement the new software development trend. According to a survey, the number of software developers adopting DevOps has increased to 17 percent in 2018 from 10 percent in 2017 worldwide.

    It is a good decision to implement DevOps and maximize its benefits to the fullest. However, choosing the right tool can be difficult, which could lead to mistakes and further lead to project delay or a complete failure. To avoid this situation, here are some of the common mistakes DevOps developers usually commit while undertaking the projects.

    Choosing the Wrong Team to do the Job

    One of the major mistakes organizations make while integrating DevOps is choosing the wrong team to do the job. It is the task of a proficient project manager to choose an appropriate team, but when inexperienced people come on the board, there can be issues.

    DevOps is a blend of both development and operations; thus, it’s a complicated job. DevOps is not limited to just bringing agility but also conducting the right deployment. Also, developers have to focus on both ends—development and administration—equally.

    Problems can occur when you start concentrating on one aspect of the cycle. So, it is better to hire an experienced team on both ends that can work in full coordination and collaboration with one other. Thes should have a sound technical knowledge and expertise in bringing the best.

    Starting a DevOps Project Without Planning

    Before commencing any project with DevOps, you first need a foolproof strategy and extensive planning. All of the members involved in the project need to understand their role comprehensibly.

    However, some organizations don’t think much about the planning and preparing a road map. They are just anxious to work on the project to complete it as soon as possible.

    This is a wrong mindset that will never be successful. Maintaining a good speed and delivering the project on time is perfect practice, but you cannot prefer speed over quality.

    Emphasizing More on the Agility

    Some of the DevOps developers have a misconceptions that Agile development alone will create a win-win situation for them and that they will deliver optimum applications. But the truth is the other way round.

    Yes, you cannot deny the significance of agility in DevOps development, as it has changed a lot from waterfall. However, merely depending on it to implement DevOps is not the right approach. When you use Agile, you primarily work on incremental, iterative work cadences. It is focused more on ensuring the customer satisfaction but you cannot deliver quality product, as Agile doesn’t have the proper infrastructure.

    Getting Rigid During the Implementation

    Don’t try to be too rigid while integrating the DevOps. This can hamper the entire project; it is difficult to act in accordance with the core tenets of DevOps. However, you can make adjustments using the DevOps model.

    You also should lay some guidelines about how to manage the stability of DevOps in the beginning and make sure it remains the same, even if problems occur.

    You won’t always get the desired result, so be prepared for any unexpected outcomes. You need to identify the root cause of the issue and so make adjustments accordingly within the DevOps ecosystem.

    Not Complete Buy-in

    Your DevOps implementation can also fail if both the development and the IT team are not fully on board. Therefore, it’s crucial that every professional involved in the project is synchronized.

    Remember, if you get stuck at even one point during the development or the testing, it would delay your project. Coordination should be well-knit and there should be one experienced person who can manage the entire team.

    Not Conducting Tests at Regular Intervals

    Another mistake during DevOps implementation is not running tests at regular intervals, which will provide improved outcome. You need to run the tests synchronously.

    Executing the tests at the same time will save lot of time and will allow you to complete your project within set deadlines. You need to employ the concept of continuous integration and continuous deployment (CI/CD) for the automatic process of test cases.

    Don’t Take Security for Granted

    While incorporating the DevOps, you are making a big mistake if you take security for granted. The two complement each other, and so security cannot be ignored. You have to plan a strategy for strengthening the security right from the beginning so that you don’t face any problems later on.

    For instance, if you expand the architecture using DevOps and afterwards find that security is not updated, you will have trouble. If you are developing a microservices architecture, security will come into play as apps interact with one another. And keep in mind that at no point of time can you compromise with security to provide ease of access.

    Not Giving Importance to Database

    Often developers avoid the importance of database during the integration of DevOps—while the implemention expands, the database falls short due to the automation process.

    The automation of database is also necessary as part of other issues such as managing the codes and continuous integration. You have to deal with the database carefully, as it plays vital role for the data-related apps.

    Implementing New Technologies Earlier

    It is good practice to choose the latest technologies for a project but when you are implementing DevOps, you need to be cautious. It is recommended not to jump on new techniques straightaway without proper knowledge and research—don’t go for the experiment.

    Don’t be a copycat and use any procedure just because others are using it. Plugins change frequently. You need to use tools smartly and intelligently according to the project requirements. Analyze the pros and cons of each of the use cases and then make a proper decision.

    Conclusion

    DevOps is a good software development and cultural practice that has gained enough attention round the world. It advocates automation and keeps a check on the entire cycle of software engineering, bringing both the development and the IT team in union.

    However, the developers commit mistakes while implementing the DevOps and so it’s important that they should be aware about these in advance.

    — Mehul Rajput

  • Trend Micro Redefines Endpoint Security with Trend Micro Apex One™

    All-in-one advanced endpoint security solution automates detection & response, delivers insight for stretched IT and security teams

    DALLAS, October 15, 2018 – Trend Micro Incorporated (TYO: 4704; TSE: 4704), a global leader in cybersecurity solutions, today launched the evolution of its advanced endpoint security offering. Now re-branded as Trend Micro Apex One™, the product redefines endpoint security with the sheer breadth of capabilities delivered as a single agent, with consistency across SaaS and on-premises deployments. This simplified offering enhances automated detection and response and provides actionable insights that maximize security for customers and offers growth opportunities for the channel.

    Overextended IT security teams are increasingly overwhelmed by the number of products required to fully protect their endpoints. Combined with an increasing number of alerts and siloed log information, there is a struggle to respond quickly enough to today’s advanced threats.

    “Our latest release has advancements that address the most pressing endpoint security issues being faced in the industry today,” said Kevin Simzer, chief operating officer for Trend Micro. “Despite the claims of some so-called ‘next-gen’ vendors, effective protection requires multiple layers of security, which is foundational to our strategy. Apex One™ is a fantastic choice for businesses seeking to displace traditional AV or struggling next-gen deployments.”

    Trend Micro Apex One™ delivers three key highlights:

    • Automated Detection & Response:

    Apex One™ is built upon the XGen™ security techniques, which is a cross-generational blend of threat defense functionality that intelligently applies the right technology at the right time. The product includes the industry’s most timely virtual patching capabilities powered by Trend Micro’s Zero Day Initiative, along with a range of modern technologies to detect and block advanced attacks, including fileless threats.

    • Actionable Insights:

    Apex One™ introduces significantly expanded endpoint detection and response (EDR) capabilities. Additionally, it connects to Trend Micro’s managed detection and response (MDR) service option that boosts in-house teams with threat hunting and alert monitoring.

    • All-in-one:

    Apex One™ offers an industry-leading breadth of capabilities from a single agent, while many vendors are still only shipping two or more. In particular, Apex One™ powerful EDR with the automated detection & response tools, simplifying deployment and eliminating silos.

    Together, these key highlights of Trend Micro Apex One™ provide a major growth opportunity for channel partners looking to offer a higher-value product that meets the security needs of enterprises.

    “These days both channel leaders as well as discerning IT decision makers can end up confused due to the level of noise in the cybersecurity market. When it comes to endpoint security I encourage a focus on the proven performance, security improvements, and flexibility of delivery models of each solution in consideration,” said Doug Cahill, senior cybersecurity analyst and group director at ESG. “By offering automated detection and EDR investigation in a single agent that is easy to deploy and provides the right defense at the right time, Trend Micro offers a modern approach to endpoint protection.”

    “Our business is faced with constant security pressures, needing to defend against increasing threats like fileless malware and ransomware while meeting security compliance standards,” said Tim Masey, Director of Cybersecurity, for Carhartt. “Today, Trend Micro provides us with effective advanced endpoint security and we look forward to the expanded capabilities of Apex One™.”

    The product’s single agent form factor, available in November 2018, eases deployment while addressing today’s demanding protection and compliance requirements. Apex One™ furthers Trend Micro’s existing OfficeScan product and current OfficeScan customers will receive Apex One™ as a regular update at no additional cost; certain features such as EDR investigation require additional licensing, depending on current entitlements.

    For more information, please visit: www.trendmicro.com/apexone.

    About Trend Micro

    Trend Micro Incorporated, a global leader in cybersecurity solutions, helps to make the world safe for exchanging digital information.  Our innovative solutions for consumers, businesses, and governments provide layered security for data centers, cloud workloads, networks, and endpoints. All our products work together to seamlessly share threat intelligence and provide a connected threat defense with centralized visibility and investigation, enabling better, faster protection. With over 6,000 employees in 50 countries and the world’s most advanced global threat research and intelligence, Trend Micro enables organizations to secure their connected world.  For more information, visit www.trendmicro.com.

  • DevOps Chat: The New Security Breed with Veracode’s Mark Curphey

    DevOps Chat: The New Security Breed with Veracode’s Mark Curphey

    DevSecOps has changed the way developers approach security in their application development cycle. But it’s also been the source of confusion, as some developers grapple with understanding how DevSecOps is different from application security. Mark Curphey, VP of strategy at CA Veracode, is clued in to the differences, which he discusses in this DevOps Chat.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and you’re here for another DevOps Chat. Today’s DevOps Chat is all about DevSecOps, AppSec, what’s happening on the front lines. I’m joined by an old friend of mine, Mark Curphey. Mark is currently VP of strategy at CA Veracode. Hey, Mark, welcome to DevOps Chat.

    Mark Curphey: Thanks, Alan. Great to talk to you again.

    Shimel: All right. So Mark, let’s start off with this. I know you’ve fairly recently joined Veracode. Give our audience a little bit of your background and how you came to be where you are.

    Curphey: Yeah, sure. So misspent youth, went back to university late, did a master’s degree in information security, and wound up working for a bunch of banks in the city of London. Moved here to the states in 2000, then ran software security for Charles Schwab. So Microsoft were creating the SDLs. You know, sort of Gates had sent out the famous memo and I was doing the same for an online service basically at Charles Schwab. So that’s where I started. Then at OWASP, which some people sort of associate my name with, which is the Open Web Application Security Project.

    And since then I’ve worked at Microsoft around the security tools team and then I think with MSDN, the Microsoft Developer Network. I more recently created a startup called SourceClear which was focused on helping developers use open source code safely in the modern DevOps world. We were acquired by Veracode about five months ago. So I’m now the VP of strategy at Veracode helping the Veracode platform and how we really sort of work with DevOps and the new way of doing things.

    Shimel: Fair. Okay, so Mark, let’s start off with this though, and I think there’s some confusion out there with both security people as well as non-security people in terms of what’s the difference between AppSec and DevSecOps? Is one really just synonymous with the other? Is DevSecOps another name for AppSec? I don’t think it is. What do you think and how do you define the differences between them?

    Curphey: Well, certainly every vendor’s got a DevSecOps product these days, right? So it’s easy why people are getting confused. I mean I think the reality is the way you have to do AppSec in a DevOps world is fundamentally different to the way we’ve done it before. It used to be about educating developers, writing policies that people had to read, human processes to do final check off, things like threat modeling, you know, all of these sort of things. They kind of worked okay in a waterfall world were kind of modified a bit to work in an agile world. But, you know, DevOps is changing the game completely. So we’re in a world of automation, and, you know, the modern ways that we have to secure it are fundamentally different. So for me DevSecOps is about how do you apply security in this modern, you know, DevOps world and that’s predominantly focused around, you know, automation. What can you automate and, you know, how can we put automation in those pipelines that are happening so that security happens inline as code is created and it’s moved through the pipelines?

    Shimel: Fair enough. We talked pipelines. We talk left to right, Mark. You know, and Veracode is probably one of the leaders in this space when we talk about DevSecOps and shifting left and working. But I think what people want to know is really how does the security person or the security team work with the development team? It’s easy to say, but what does it really –

    Curphey: Sure.

    Shimel: What does it really mean?

    Curphey: Yeah. I mean, look, I think there’s a new breed of security people which is exciting to see. Like the old world that used to be the development team and then there were the security team. There were kind of the two separate teams. The security team needed to sort of bless things before they went into production, but we get appointed a data center and whatever. These days what you see is it’s all about velocity.

    So, you know, there are security people that are embedded into the security teams and they’re kind of acting like consultants and helping the dev team do security as and when it’s needed and make the right decisions without slowing things down. So instead of it sort of being this procedural thing where they were required to go through whatever a control grate, they’re just tired of the flow. That’s exciting to see because I think we’re seeing a paradigm shift of how that happens.

    Shimel: Yep, I think we are seeing a paradigm shift in this. So here’s going to be a question you’re going to say, “Alan, you’re crazy,” but Mark, does it make a difference? Is it definitively improving our security here?

    Curphey: Yeah. First, Alan, I’m never gonna call you crazy, but that’s good to know, I think.

    Shimel: I figured you would.

    Curphey: No, but look, I mean like, for sure, like think about like we all know what happened with Equifax, right? Like biggest data breach in history, result of open source that was insecure and hadn’t been updated. That problem is solvable and it’s solvable at scale in a pipeline. So what we were doing at SourceClear – I don’t want to turn into a product pitch in any sense, but we were basically trying to close the loop of this library is out of date, issue the pull request, figure out if it’s going to break things, and if so, update it. And the developers loved that, not because they’re fixing security but they’re fixing the dependency hell problem.

    So we’ve not been able to do that before because, you know, we hadn’t been injected directly in the pipelines. So these are opportunities that really make a difference and companies that implement these tools like us and there are others around, totally can avoid the whole Equifax thing. It’s not a case of like no one got notified or no one knew. Like it happens automatically in the pipeline. So there are great opportunities to do things like that.

    And I think moving forward we can also look at things like are people using dangerous APIs? Are they calling, you know, external services that we don’t want them to call? Like to a large extent the pipeline has become the new firewall and it’s a place where we can put controls, inspect the traffic, and decide what we want to allow and what we don’t want to allow which is a great place to be.

    Shimel: I agree. I agree there. So Mark, I guess where I wanted to go next with this is a lot – again, I’m a man who lives with a foot in each world, right? I spend a lot of time with my security friends and colleagues that I’ve known for years and years and years, but as part of devopsy.kinsta.cloud I’m out speaking to developers an awful lot, right?

    Curphey: Mm-hmm.

    Shimel: And some of the questions that I hear from both sides is, okay, you can’t serve two masters, there can’t be two people in charge. How does the day-to-day of this flow? You know what I’m saying?

    Curphey: Yeah, no, for sure. I mean look, the reality is in all organizations the digital transformation and everything else happens that it’s all about value creation and the value is created by developers. So they’ve been empowered to choose their tools. They’ve been empowered to figure out which process allows them to innovate faster and all those things. With that we’ve seen the rise of the cloud and everything else. So it can’t be an us or them scenario. It’s how do you support those developers on their mission to change things and create this digital transformation? So the old ways, you still see it but you still see the old school of security people saying no and stopping people; but those battles are not going to be won. It’s about how do we help people move forward at the right rate.

    I mean I kind of equate it like someone was saying the other day, like similar to autonomous cars, like you’re not going to stop them. Like figure out how to make them work properly, safely, and securely. But if you don’t like it, you’re not going to stop that, have that technology happening and being created so you’ve got to embrace it. That I think is the philosophy that is going to win out the day.

    Shimel: Fair enough. I don’t disagree with you there, Mark. Let’s talk a little bit about what you see near term and maybe a little bit longer term in developments here that, you know, our listeners, you know, could fundamentally change their day to day. Where do you think we’re heading?

    Curphey: Yeah, sure. So, you know, I think machine learning and artificial intelligence and big data were sort of touted and, you know, the hype cycle kick off and, yeah, people didn’t always deliver on that. But there are exciting things happening in that which allow us at scale and at speed to do things that we couldn’t do before. So a good example of that is in the security world most of the vulnerabilities no longer exist in the CV system open source code. They just can’t keep up with the scale. We’re releasing thousands of libraries. In the DevOps world, developers find things, fix them, push them out. They don’t go back to monitor and publish these vulnerabilities, etc.

    But the great news is, you know, there are big data systems, machine learning that can process that data and we can identify those things at scale. Those same kind of techniques have been applied by Google and the Android App Stores and things like that. So that application of like that modern tech I think has great opportunities for us to do things which we’ve not been able to do before, and you’ve certainly seen some of the big vulnerabilities that have been released have been a result of that stuff coming out.

    Shimel: Got it. Got it. I just had my phone ringing there. I apologize. Mark, let’s, if I can and if you’re not too shy about it, I doubt you will be, let’s talk specifically a little bit about Veracode.

    Curphey: Yes.

    Shimel: You know, you’ve been there five months. What do you see? What gets you excited there in the morning?

    Curphey: Yeah. We had loads of places to sort of land. We came to the conclusion that people wanted to have less tools than more. So they wanted to buy a suite. When you look around, what the Veracode guys had done is built sort of best-in-class SAST and it started working on software composition analysis. We had best-in-class software composition analysis. So it made sense from that perspective.

    Also as you know, the heritage of the company, you know, it isn’t a fly-by-night company. It’s Chris Wysopal and Christien Rioux, right? These guys were in the loft, right? So that legendary around the place. So the company has this real DNA about it around security. So for me it’s kind of this exciting security DNA in the company embracing the way we build modern software. So that’s what attracted us to join forces. We’ve been extremely excited since. A lot of exciting things happening that for sure will start to come out of it at the other side no doubt.

    Shimel: I agree with you. I actually have Chris on a panel we’re doing on DevSecOps next week. I’m really excited to have Chris as well as Dave Duncan from CA, I think is on the panel with us.

    Curphey: Right. Right.

    Shimel: So Mark, you know, running out of time here, but I wanted to talk a little bit more about, you know, you came into Veracode, as you said, about five months ago via the acquisition. There’s a lot of people out there seeing a lot of buying and selling, M&A kind of stuff going on in especially around DevSecOps and DevOps related companies. I mean obviously a rising tide lifts all boats and there’s consolidation going on, but is there anything else at play that you’re seeing that’s kind of driving this stuff?

    Curphey: Well, I mean, you know, in the place that you look on the horizon is actually where the dev tools are going. So you know, if we look at companies like AWS, it’s not really just a hosting platform. It’s a full tool suite, right, of everything from machine learning libraries in the cloud to real-time databases and things. Google and Azure are building the same. As we start to think about like what is a next generation of developer look like, they’re likely to use an IDE and a browser. It’s not going to run on a desktop anymore. And you know, co-changes happen and everything happens up in the cloud. So I think there are a lot of exciting things happening there and how do you integrate security into that world for sure. So that’s a lot of the stuff that I’m focused on. Then you can get scaled I think.

    Shimel: Got it. Got it. Mark, you know, I appreciate you talking to us today. I think we’re about out of time. But for people who want to get more information on what’s going on, veracode.com obviously, correct?

    Curphey: Yeah, veracode.com is an excellent, well-trafficked blog with Wysopal and various other people and myself contributing to it which is great and we’re out speaking at conferences and talking about some of the both current work and sort of some of the futuristic stuff as well. So love to engage with the community and the industry for sure.

    Shimel: Perfect. All right. Hey, Mark Curphey, VP of Strategy, CA Veracode. Thanks for being our guest in this episode of DevOps Chat and we look forward to having you on again soon.

    Curphey: Yeah, great, Alan, thanks a lot. Great to reconnect and look forward to doing so the next time.

    Shimel: Okay.

    Curphey: Take care.

    Shimel: This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat.

    — Alan Shimel

  • Database Security: Best Practices for Keeping Data Safe

    Database Security: Best Practices for Keeping Data Safe

    Database security is of utmost importance to sectors including IT, banking, finance and ecommerce. Every other transaction is based on how secure their database is, as it holds every detail including usernames, passwords, customers’ credit card information and so on.

    The term “database security” denotes a series of measures initiated by the service provider to proactively protect the information and database management software from malicious threats, phishing attacks, DoS (denial-of-service) and malware. The security is achieved by using streamlined processes, automation, security tools and trained experts who work around the clock.

    Different Levels of Database Security

    There are different levels of securing your databases, including:

    • Data Level Security: The process of protecting the data itself from getting stolen or tampered with in the servers.
    • System Level Security: Protecting networking servers, hardware and other inbound/outbound communications from acting as a funnel to distribute malicious software.
    • User Level Security: A server is always attacked from a user level, which is why organizations rely on real-time protection software to monitor transactions and also restrict the user from visiting unauthorized websites or downloads from untrusted sources.

    Most Commonly Spotted Database Attacks

    These are the most common attacks triggered that threaten database security:

    • Buffer overflow vulnerability
    • DoS attacks
    • Privilege escalation
    • Weak authentication
    • SQL injection threats

    Best Practices for Database Protection

    Experts recommend following a checklist that includes some of the most widely used and trusted methods to ensure database security:

    Physical Security

    The first method is securing physical servers using digital locks, using CCTV cameras to monitor them continuously and preventing any unauthorized entry with the help of 24/7 security services.

    Establishing Firewall for Servers

    Every connection to the database can be set by default to deny all incoming traffic using a firewall. It will also block direct client access and allow only authorized applications. The firewall rules will be strictly monitored and maintained by system administrators (SAs) and database administrators (DBAs). They will also perform network scans and ISP scans to strengthen the server machines.

    Using a Trusted Database Software

    The database software can either be open source or a paid version supported by the vendor. The software will run only on active devices while inactive devices will be unplugged and default accounts that are no longer in use will be removed periodically. Timely security patches are applied.

    It’s also important to take a close look at your software vendor to determine if they’re keeping their code as secure as possible.

    Implementing Application Code

    The DBAs will ensure all configuration files and source codes are accessible only through authorized operating system accounts. Application code is regularly reviewed to ensure it is not vulnerable to SQL injection.

    Role of SAs and DBAs

    The role of DBAs and SAs are vital, as they play the role of strict administrators. Authorization is allowed only to select people and all of them will sign an NDA along with a background check.

    DBA staff will be allowed to use individual accounts and not shared accounts to access the server. They are required to create and maintain the strongest of passwords that meet the necessary security and safety guidelines.

    Change Management and Database Auditing

    Another security measure is to keep track of change management by logging all database activities. Every bit of login data will be maintained for at least one year for security audits, and any account that faces maximum failed login attempts will automatically be notified to the database administrator to take necessary steps.

    The Triangular Concept for Database Security

    • Confidentiality: Maintaining confidentiality is enforced through encryption by encrypting both data that is being transferred and data that is stored in the database in case it gets breached.
    • Integrity: A user access control system will be in place to ensure only authorized personnel are allowed access to the data and a log is maintained of everyone who gains access to it to ensure there are not data breaches caused by internal errors.
    • Availability: The data stored should be made available to both users and administrators, which is made by reducing downtime. Servers are periodically updated for maximum security while boosting business through continuous service.

    When a database administrator is aware of the most common threats and the different methodologies that they should implement to protect data, they can be rest assured that the data stored in servers are protected to the core. Besides, they should also practice best practices in backup and data recovery to safeguard themselves against ransomware.

    — Sophie Ross

  • DevOps Chat: Container Security and More with StackRox’s Ali Golshan

    DevOps Chat: Container Security and More with StackRox’s Ali Golshan

    Security has many faces, which is why it’s so difficult to implement effectively. Each environment is different; each security solution is different; the needs of each organization is different. That’s why, as Ali Golshan, StackRox founder and CEO Ali Golshan put it, security has gotten a bad rap.

    Golshan and his company are approaching security from a more DevOps-focused view, providing the necessary tools to enable DevOps teams to include security throughout the entire process. In this DevOps Chat, he and I discuss the many facets of DevSecOps, container security and more.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Today’s chat is a little DevOps, a little security, a little containers, little bit of everything. Happy to be joined by StackRox founder and CEO, Ali Golshan. Ali, welcome.

    Ali Golshan: Thanks for having me.

    Shimel: And, Ali, I think I mispronounced your name. It’s “Golshan.” Correct?

    Golshan: Correct. Yes, thank you.

    Shimel: Cool. I try to do it right. So, Ali, let’s start with the obvious, though, maybe some people out here have not yet heard of StackRox, so, before we dive in, just a quick sorta elevator pitch so they have some context.

    Golshan: Sure. We started StackRox three-and-a-half years ago. The premise for the company was we saw a couple of major shifts in the industry. One happened to be the introduction of containerization and microservices, which is a sub-effect of this larger trend that we’ve been seeing, which is application security and development becoming full product life cycle, so ensuring that you can cover security and compliance and requirements from build to deployment to runtime. And containers provided, really, a great packaging and a construct for building applications and microservices.

    And then the second part of it is is that, when you look at this model, we realize that there’s really three fundamental things that are disrupting a $30-billion security industry. This is the whole notion of a full product life cycle needing to be automated. It’s immutability and ephemerality. And, because you can’t forklift traditional security solutions and deal with these three constructs, we decided to go after solving this much bigger problem for what we like to see is for the future of cloud.

    And where we started was containerization just as the fundamental building blocks. As time and market has progressed, we’ve progressed with it, which is focus more on things like APIs and orchestrators and managed cloud environments, but very much with kind of a host-application-centric view of the world. We’re not a network-based tool. We’re not a log-ingest based tool. We tend to focus a little bit more on security automation, detection, and creating a multifaceted risk view of your environment, specific to containers and microservices.

    Shimel: Got it. So, you know, there’s a lot in there and we’ll come back to StackRox maybe a little later in our chat today, but I wanted to – let me hit on a couple of things you mentioned. So the first thing is this whole idea of cloud-native, container-native. You know, when we first saw the shift to the cloud, the security industry’s response was what some analysts called “cloud-washing” existing security solutions. So they took their existing security solutions and they said, “Okay, now it could run in the cloud too. It’s a cloud security solution,” but it really wasn’t. It was a on-prem security solution moved to the cloud. It wasn’t cloud-native and it really was a little bit of a round peg in a square hole.

    I think we’re seeing the same thing when we talk about security solutions built or trying to provide security for containerized applications. Right? What’s involved? Can you – you know, I don’t wanna coin the phrase, but can you “container-wash” an existing security solution and make it a container security solution, Ali, or do you really need sort of container-native-designed security?

    Golshan: To your point regarding traditional cloud environments, I think that was a smaller chasm, where security companies had to cross, because that original movement was a little bit more about virtualizing your environment. So there was still some kind of applicability of running things like WAS or endpoint solutions, to be able to broaden your security posture to the cloud. Obviously, the fundamental problems we saw were created were around how do you automate and provision workloads and then the nature of those workloads remaining. Those were kind of – the new capabilities in the cloud were actually the pieces that created gaps for security.

    So, if you then think about that and expand that further, the capabilities and designs for containers are even kind of another order of magnitude different than traditional. It’s not just virtualization and then outsize your boundaries. It’s virtualization; it’s microservices, every function broken down into a particular service; controlling it end to end. So, if you think about that there’s a large portion of the security industry that doesn’t even look at some of the most critical components of this process, which is the build and deployment. Building constant context there. Building declarative policies from that environment and then using it further. So I think that’s one of the major reasons we don’t see the applicability of traditional security solutions, even more so in containerized environments.

    Shimel: Yep. I mean, Ali, I agree with you and I think that’s why, frankly, a lot of what is today passing for container security seems to be people doing vulnerability scans of containers or, as I think I had spoken to you about the last time we chatted, you know, network IDS for the container. It just doesn’t – it seems very much square peg, round hole. And I’m not saying you don’t need vulnerability management, whether you’re in a container or not, and I’m not saying you don’t need intrusion detection, whether you’re in a containerized environment or not. But to say that that is, quote unquote, a “container security solution” seems just pushing it and just trying really hard to sell.

    But wanted to come back to another thing you mentioned in your opening remarks. And that was around this whole idea of not only are we living in a containerized age, but we’ve seen the rise – and I don’t wanna say the dominance of – but, you know, the whole CI/CD software factory pipeline model of which DevOps is an integral part of and we talk about shifting security left into the software development life cycle. And this is yet another way that traditional security has to give way to how things are done today, so how does that influence or how does that play itself out, in terms of StackRox?

    Golshan: The way we think about that is, if you think about who were the first companies who moved towards containerization and microservices, they were all companies that needed to deal with massive scale, building velocity in their development and to the offerings they have for their customers. And, as a result, they realized that kind of traditional model of building and deploying and managing was just not sustainable because it wouldn’t scale with the human element. So this notion of DevOps, and even containerization as a result, were really tools and methods for companies to be able to increase their level of automation and sophistication as to how they managed and run their infrastructure.

    So the way we look at this is is that, also, it’s the same reason why a lot of those first movers build their own security models around this environment ’cause nothing like it existed. So we see security kind of mapping to the same model, which is, if you think about it, things used to be a little bit more around a model of batch process, respond, do analytics, take those sorts of options. And, again, the way we look at this is is that what containers have done is break that fundamental workflow. That fundamental workflow isn’t kind of “Build something. Check. Build. Check. Build. Check. And have all these gating factors applied by security.” It’s a lot more fluid now. So, as a result, security has to kind of integrate into that whole workflow.

    And this is one of the big things we talk about, which is is that the reason you can’t take traditional security solutions and apply ’em here, it’s not just the form factor of what they’re applying to, but it’s also the entirely new workflow that’s been created by DevOps and these types of environments that impact how a security tool should run. Because it’s not just tying it to a form factor or choke point. It becomes more of a service mesh – not to borrow the word “service mesh” from kind of the service mesh project, but that’s why it lends itself very well. It’s a number of services integrated across the process and then, as you automate these processes, they become force multipliers for each other. That’s how DevOps works and that’s how security should work as well. You can’t break that workflow model just because your security tool.

    Shimel: Agreed. And you’re using the term “workflow model” and I think that’s a great descriptor of it, but, you know, a lot of goes back – and, again, part and parcel with DevOps – a lot of it goes back to the whole sort of Lean IT, based on Lean manufacturing. Sort of, it really is a factory pipeline kind of workflow model. And, when you think about it, the fact that, all this time, we’ve always kinda just stuck security on at the end, at the end of the packaging, so to speak, and then wondered why it didn’t work so great. It’s kinda obvious when you look at it that way, isn’t it?

    Golshan: No, absolutely. I mean, that’s a interesting analogy, right? If you think about it. If you have kind of a industrial environment and you have manufacturing, if you move from a manual workflows to robotics and automated work flows, the sort of security you apply is gonna be very different – how you look for bugs, how you look at, for example, applications. This is a good analogy because it’s a very indicative kind of model of what the current industry’s going through.

    Shimel: Mm-hmm.

    Golshan: So I’ve become a big believer that you can’t – this is where I think security goes wrong, trying to cover too many things at once. If you have a completely new emerging model, like containers and microservices and DevOps, it’s okay to say that our security or our approach deals just with that particular area. And, as small or as big as it may be, it’s important because it adds credibility that you actually understand what it fundamentally is built from and what it’s doing ’cause, if you say anything other than that – “Well, no, mine can cover network and end points and VMs and containers and Lambda.” – well, that’s just a lot of the reasons why the security industry got the bad rap it did. It’s just things fundamentally work different.

    Shimel: Agreed. Agreed. So, Ali, I think we’ve done a great job here, in the first ten minutes or so, of laying out these sort of macro-factors that are affecting not just the tech or even just the security industry, but the – it’s really affects the whole world because we’re all – every company’s a software company now. And so this really has worldwide bedrock kind of effect.

    But let’s turn back to StackRox, right? Full circle back to the beginning. So how are all of these things manifesting itself in –

    Golshan: Yeah, so the way we look at it is –

    Shimel: – in what became StackRox?

    Golshan: – is have one solution that has two modules to it that interoperate. We have the StackRox module that covers build and deployment and StackRox that covers runtime and production. And the way we look at this entire flow is very basic – on one side of the equation, you get to look at all the static and declarative information and you get to use it to say what things should be able to do, and then, any time you run it, be it in deployment, QA, or production, you get to learn from that application more and more and see what it actually can do.

    So our mission is really bridging what it should do versus what it can do. And the reason, for us, the automation part of it is a big part of it is, you know, as companies mature their overall workflow, they will have additional tools that are gonna be provided by their platform providers, by their cloud providers. As an example, you touched on vuln-scanning. Absolutely everybody should do vuln-scanning, but, more and more, we’re seeing it cloud providers and platform providers provide it, so the key there is not to provide vulnerability; it’s to be able to do vulnerability management.

    And the way we look at vulnerability management, it’s either being able to provide the customer the scanner or ingesting the data from all the scanners and then helping them prioritize it – “Where is this running in production? In production, what services are accessible by this?” So, if you have a low vulnerability that is running in a production environment, in a mission-critical app that is exposed to the Web, it should be valued higher than a high vulnerability that is running in dev in a closed-off EPC that has no access to any other services.

    So context is what helps you prioritize, but it also flows the other way. So, in runtime, if you’re doing detection, it’s important to understand, if an attacker, for example, shelved and broke into a – broke out of a container, grabbed some tokens or credentials, you wanna be able to go back and look at the, for example, the secrets that are being managed through the orchestrator and see where else those particular credentials or secrets are available, where else that deployment has happened.

    So, if you think about it, on the left side, you get a lot of really great insight. On the right side of the process, with the runtime and production side, you can make use of those to build very good boundaries and gating factors, and that naturally reduces your attack surface. So, as you feed this information back to the build and deployment, remove credentials or privileges or tools that are unnecessary, you’re inherently making your infrastructure and applications more secure. And, as a result, we have a much better landing zone for what we apply detection to. We don’t have to detect everything; we know where the weak points or where the gaps are in the system, to focus our detection.

    So that’s kinda how we think about the overall StackRox product. Give the customers, especially the build and deployment and dev teams, the right security, auditability, automation tools on the build and deployment side, and then give the right runtime detection, alerting, response, forensics, and enforcement on the runtime protection side, for security folks.

    Shimel: Excellent. And we’ve got a few minutes left here, Ali. I wanted to – for people who wanna get more information about StackRox, is it stackrox.com? S-T-A-C-K-R-O-X?

    Golshan: It is. Yeah. We have all of our information on our website and we actually offer free risk assessments using one module of our product, where a customer can just grab it and understand much better as to what they’re dealing with when it comes to their container infrastructure.

    Shimel: Okay. Let me come back one other thing to you and, you know, the proverbial “Let’s see your roadmap” slide, but I don’t really want you to show me your roadmap. But what do you think is next, not only for StackRox, but as a result of this macro environment that we’re living in? What’s the next shoe to drop here and how do StackRox sort of – I’m sorry about the noise there – how do StackRox respond?

    Golshan: Sure. I think it’s a couple of things. One is we’re seeing more maturity across this entire stack, so we’re seeing convergence around orchestrators; we’re seeing kind of the standards around runtime engines being built; we’re seeing how public cloud providers are consolidating certain services and making other services much easier to use. Perfect example’s all the efforts around, for example, Kubernetes, between AKS, between EKS and GKE.

    So, when we look at these trends, it shows a couple of different things. One, not only are the containers different, but the entire attack surface is going to look very different, so the way you approach this world is gonna look very different in the future. We’re not gonna make the same mistakes we did with traditional security, which is we’re not gonna make the host overly exposed with a lot of user accounts and credentials and privileges and tools and packages. So we think that that host will obstruct the way and the orchestrator will become kind of a new cloud operating system, with APIs.

    And, as a part of that, you’re gonna end up seeing a lot more complexity, so, as companies get more comfortable running applications as microservices, more containers, better grasp of the orchestrator, they’ll get more comfortable running more complex operations and applications on top of it. Naturally, that comes with maturity. And once you have that, you end up going from kind of what right now is, which is very early stages of this ecosystem, which I would consider to be low entropy, to a very high entropy environment you’re gonna end up seeing.

    As a result of that, the way we see security being built is, one, that’s why it’s very important to focus on automation, integration, and the workflow, but, secondly, we see security having to be built in cloud native as a form-factor-agnostic model, meaning leverage the existing frameworks to – if it’s collecting data, for example, from the system, use, for example, things like the extended Berkeley Packet Filter to use that. If you’re running on Amazon or Google, you can use things like Pub/Sub or Kinesis.

    So it’s building more modular, programmable, and pluggable architectures, versus building a binary that deploys in a container and then you replicate that container against a bunch of hosts. It’s about building a sensory model that can understand different environments and make sense of them, not single agents that unilaterally take action, because, as complexity, heterogeniality grows, naturally, there’s gonna be a lot more gray area, as far as use cases go. And that’s where you run into the old problem of alert fatigue, noise, false positives, and then, eventually, you end up with 50 security solutions.

    Shimel: Excellent. Excellent. Well, Ali, we’re about out of time, but I gotta tell you, man: I love this chat. This was great. I’d love to have you back on the –

    Golshan: Yeah, same here, Alan.

    Shimel: We’ll dive into some more of this stuff. Good stuff. Ali Golshan, cofounder and CEO of StackRox, here on DevOps Chat. This is Alan Shimel. You’ve just listened to another chat. Have a great day, everyone.

    — Alan Shimel

  • The Hybrid Cloud and Why DevOps Teams Need Unified Stack Observability

    The Hybrid Cloud and Why DevOps Teams Need Unified Stack Observability

    The modern data center is constantly evolving to keep up with the demands of always-on, anywhere computing. Long gone are the days of monolithic, on-premises data centers. Today, the computing modus operandi is that of the hybrid cloud, which, according to Statista, will be worth close to $50 billion in 2018—just about double what it was in 2014—and will grow to almost $92 billion by 2021.

    As more and more DevOps and security teams are integrating hybrid cloud environments and serverless architectures, they need to gain visibility and insight into the increasingly distributed workloads provisioning and supporting their applications. Without a single pane of glass across their hybrid clouds, Dev, Sec and Ops teams cannot quickly discover vulnerabilities or identify and respond to attacks.

    The emerging best practice to the cross-cloud visibility conundrum is unified stack observability. Unified observability is the ability for Dev, Sec and Ops to share the same application-aware monitoring environment for vulnerabilities, threats or attacks across all workloads supporting their applications. The idea behind unified observability is that each team can look at the different stack layers as one—with an app-aware, single-pane, top-down view. For Dev teams, unified observability means that they can see and define all the third-party services connected to their applications; for Ops, it means they can see and monitor all workloads. And for Sec teams, it means the ability to set security policies for detecting and blocking attacks at each layer of the app stack by enforcing policies uniformly. There are a few recent trends accelerating the need for unified stack observability.

    The Accelerated Need for Unified Stack Observability

    Recent computing and application development trends are changing the way Dev, Sec and Ops teams develop and manage their distributed applications across hybrid cloud infrastructures. These changes include the increased use of third-party services, an overabundance of purpose-built security tools and the increasing need to address the shared cloud responsibility model, among others.

    An Uptick in Third-Party Code Use

    Third-party code increasingly is being used in apps and is one of the critical attack vectors exploited by hackers. SafeCode research notes that 78 percent of companies are running part or all of its operations on open source software, while 66 percent create software for customers built with open source. These stats have nearly doubled since 2010. The very practice of code-lifting, or pulling open source code from different repositories, which has enabled developers to share innovation and collaborate across architectures and levels, is turning to be one of the biggest attack vectors for hackers to exploit. Running on many different functions, open source applications and code borrowed from third-party services increasingly are becoming more vulnerable and therefore require a need for constant observability and monitoring.

    Even though such code is usually vigorously tested for vulnerabilities during the build and deploy stages, it can—and in some cases is—compromised in production. The global Magecart credit card skimming incident is an indicator of this: The hackers were able to infiltrate the third-party components and exploited them to gain credit card information, resulting in 800 e-commerce sites being compromised. To avoid such distributed vulnerabilities, Dev, Sec and Ops teams need to constantly index third-party functions and services, and scan for possible vulnerabilities or attacks. Such monitoring requires unified observability at the app code level.

    The Growing Overabundance of Purpose-Built Security Tools

    Increasingly enterprises are leveraging multiple cloud providers while still running their own data centers, either on-premises or as private clouds. A 2017 report from Forrester Research points to 89 percent of enterprises using at least two clouds, while 74 percent use three or more public clouds. Despite a wide industry effort lead by global leaders such as VMware to provide seamless cross-cloud orchestration and management, most clouds remain in their own environments with a set of purpose-built management and security tools.

    Then there is the traditional security approach, which can get in the way. According to Cybersecurity Insider’s “2018 Cloud Security Report,” only 16 percent of organizations believe the capabilities of traditional security tools are sufficient to manage security across the cloud. Eighty-four percent said traditional security solutions either don’t work at all in cloud environments or have only limited functionality, meaning that more tools with specific functionality must be integrated within the cloud. On-premises, private and public clouds remain siloed for most team, stressing an overtaxed security resources across organizations.

    Shared Responsibility Can Be a Shared Burden

    Even though the shared responsibility model has been well-documented, securing public cloud environments can be a burden to security and IT teams as their responsibilities continue to grow, while available talent is short to find. The traditional shared responsibility model assumes that the cloud vendor secures the hardware and software of the cloud itself, while the customer is responsible for the security of their assets within the cloud.

    With the shared responsibility model, most security teams are unsure about how to do their part. Gartner reports that through 2022, at least 95 percent of cloud security failures will be the customer’s fault. This can include anything from a failure to monitor to a failure to adequately secure the correct elements. This can also include customer misconfiguration, mismanaged credentials or insider theft. Additionally,  The “2017 IBM X-Force Report” noted a 424 percent jump in breaches related to misconfigured cloud infrastructure, largely due to human error. These gaps in security leave security teams with their organization, data and apps vulnerable.

    App-Aware Stack Observability: The New Modern Security Mandate

    The biggest distributed security blind spot facing modern Dev, Sec and Ops teams today is for them to monitor for vulnerabilities or attacks at each layer of the stack—at the application/third-party code-use level, their distributed workloads and the network each in isolation. Unified application-aware stack visibility and observability is becoming the only way to fully see and understand potential risks in today’s increasingly distributed environments, effectively addressing some of the biggest security challenges faced by modern Dev, Sec and Ops teams.

    — Gadi Naor

  • DevOps Chat: Open Source and DevSecOps with Azi Cohen, WhiteSource

    DevOps Chat: Open Source and DevSecOps with Azi Cohen, WhiteSource

    The security of open source code is one many organizations are grappling with. Add to that the number of times that applications using open source code are updated and the integration issues that come with those updates, and it’s no wonder open source security comes into question.

    WhiteSource thinks it has a solution to the open source code security problem. In this DevOps Chat, we speak with Azi Cohen, head of U.S. operations at WhiteSource, about the issues surrounding the security of open source code and how his company is helping to reduce the problem.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. In today’s DevOps Chat, I’m happy to be joined by someone who I’ve had the pleasure of speaking with several times, but not on a podcast, I believe, and it’s Azi Cohen – “Cone” or “Cohen,” depending how you pronounce it. Azi is head of U.S. operations and a co-founder at WhiteSource Security. Azi, welcome to DevOps Chat.

    Azi Cohen: Hi there. Good morning. How are you doing, my friend?

    Shimel: Good. Happy to have you here with us. So, Azi –

    Cohen: Okay, and, by the way, the name of the company is WhiteSource Software.

    Shimel: Oh, okay.

    Cohen: Yeah.

    Shimel: I apologize. WhiteSource Software.

    Cohen: Yes.

    Shimel: You know, and that’s a good bridge, Azi. Before we jump into today’s topic, which is DevSecOps-related, for those who may not be familiar with the company, why don’t you give us a little background?

    Cohen: Sure. Perfect. So WhiteSource Software was initiated by three of us. We are three partners that were actually working in a different company that was acquired, going through an acquisition, by CA Technologies. And, through this process of due diligence, we found ourselves getting questioned about open-source that was included or not included, you know, in our technology. And that was a very cumbersome process. Took a lot of time and effort. So, not surprisingly, after the three of us been acquired and spent some time acquiring companies, we realized, “Hey, there must be better way to do all these things,” and, a few years later, we started WhiteSource.

    The idea was to allow companies that develop intellectual property using open source – and, remember, we’re talking about 2011, 2012; open source was well-known phenomena or the use of open source, but still not very well-adopted by the large enterprises – so the premise was to help software houses or companies that developed their own intellectual property, using open source, to have a better management and control of the inventory, the legal aspect or the compliance side, and, later on, in security.

    So we started the company in Israel. We got some grants from the Israeli government. We developed a solution and, obviously, we started to focus on companies – you know, at startups and technology companies. And we were doing very well for quite a long time. I think that the big change came somewhere like 18 months ago, maybe 24 months, where we started to feel a growing demand from large enterprises – banks and technology companies, consultants, large chains, health companies. So all those started to use open source and started to look also for a solution, and that’s when we realized, “Hey, there’s a big opportunity here.”

    We went out, raised a lot of money from VCs, including from Microsoft, etc. Started the U.S. operation. And, fast-forward today, we have a very large office here, more than 30 people, in North America. I run the U.S. operation. We’re growing 300 percent year over year. Almost more than 500 clients, from multibillion companies to small ones, and it looks, right now, that demand is not going to drop.

    Shimel: Fantastic. You know, as they say here in America, mazel tov.

    Cohen: [Laughs]

    Shimel: It’s an American –

    Cohen: Thank you for that.

    Shimel: – _____ success story, right? And congratulations to you and the team. But, Azi, you know, sometimes – and, like you, I’ve been in business 30 years – sometimes, it’s better to be lucky than smart. It’s good to be both. But you really – WhiteSource Software and your team has been a little bit of a benefactor of being in the right place at the right time. We live in an age where so much of our – well, everything is software and applications, but so much of our applications are built on open source component, primarily, right? A majority of –

    Cohen: Absolutely. That there is a Gartner report that states that something like 40 to 60 percent of the new web applications consist of – is consisted of open source and this is just going to grow. Right? So it’s not going to stop there. And we definitely see that by our biggest clients. We see them starting when they have something like 20 percent of their code being open source, very quickly reaching to 30, 40 and more, right?

    So this is not something that is going to happen, and I think there is a very good reason for that. If you look at large ITs today – banks, etc. – you know, the CIOs are being asked to create more and more innovation. Someone wrote an article about it. Something like that they’re required to generate something like 25 percent of new ideas and new application or, if you want new lines of code, you know, 25 line of code, year over year, but they don’t get 25 percent more people to do it. Right? They just get 2, 3 percent. So reuse instead of build is the most obvious solution, and that’s why we’re not going to see that percentage dropping, but going higher and higher.

    Shimel: Oh, and – but it makes good sense, right? So much – you know, when you look at the average application, so much of it is rinse and repeat, right? Sending an e-mail, firing off an e-mail or registration, opening a window. So many of – there’s no sense reinventing the wheel of these things _____ _____ –

    Cohen: Oh, absolutely.

    Shimel: You know, when you look, there’s so much Java script reused, there’s so many Java components reused. There’s so much of these open source reuse – like you say, it’s only gonna be more and more, as these libraries and repositories get bigger. But that begs the question, Azi, of it doesn’t make us more secure, necessarily. And, as a matter of fact, some may argue it makes us less secure. What’s your position?

    Cohen: Well, it’s a great question. You know, and, obviously, when you have one component being used by millions, it’s just an opportunity for attacker to find a way to hack it, crack it and now they have thousands of companies that may be vulnerable to this one, right? And then, for them, an open door to get into those accounts. So what we actually see is that, with the fact that more and more open source is being used, on one end, we have attacker trying to exploit those open source components and we have seen some cases in the past, right?

    In the same time, the community tries to find more vulnerabilities and fix them as fast as possible, but, if you look at the DevOps guys, this create a huge problem because, think about it, on one hand, they use more and more open source; on the other hand, the community, which is very active, is finding more and more vulnerabilities in those open source and provide fixes, right?

    So now the DevOps guys have more stuff to deal with, a larger inventory to track and check and validate, but, on the other hand, we know that the attacker, that know that these guys will patch those vulnerability very quickly, try to hit them faster and faster. So DevSecOps or DevOps guy have more stuff to do in less time. So the only solution is by automation, right? The only solution is by some control that will let them know what’s good, what’s bad, and provide alerts when something bad is happening or when new vulnerability that is – that they are exposing the inventory is _____ _____.

    Shimel: Yep. Absolutely. And you know what, Azi? This is – what you just described, yes, it’s 100-percent dead on for DevSecOps, but it also describes so much of what we are seeing in software development in general. If the machine, if the factory is gonna run, at the optimum speed, we must automate so much of this, right? Because, otherwise, it just can’t keep up and security is certainly no exception. No exception. _____ –

    Cohen: Absolutely. And another thing here is that you have to detect or try to stop bad things from coming in at the gate and not later, right? Because every step later – so it’s automation but also automation at the front of what’s called shift left, right? As early as possible in the development cycle. And then, at WhiteSource, we do exactly that.

    Shimel: Yep. So this begs the question, though, “Sounds wonderful. Let’s all do it. Why aren’t we more secure? Why aren’t more people doing it? Is it really that easy?”

    Cohen: I think it’s mostly a matter of awareness and perception as well. So, firstly, when I meet with CIO, CISOs, they don’t – in many cases, they don’t understand what level of adoption of open-source they have in their environment. Their perception is that, in many cases, that they use only 10 percent or 15 percent of the code, is open source. The reality is it’s higher.

    So perception of the problem is one thing, and top managers in many places don’t understand that the amount of open source being used right now is larger than what they have, but the other thing is that, you know, the perception is that standard tools, like application security testing tools from IBM or from Checkmarx and from other vendors, right, are solving the problem. You know, since they scan the proprietary code, then most likely scan the open source as well, but that’s not true. That’s not the case.

    And the last thing is that, once more awareness or, if you want, education – the assumption by most managers is that open source behaves like the proprietary code, right? You use a scanner. You test the open source. You find vulnerabilities. Somehow, you either fix them or not, and they’re fixed. It’s a one-off. What they miss is that open source is a living thing. You may have a clear open source component that are using now, which is fine, but then, month later, there could be a vulnerability in it, right? You have to be able to track it later on. It’s not a one-off test and gone.

    A good example is Apache’s Struts No. 2, right? A year ago, the whole world was astonished by this Equifax thing that was created by an attack to Apache Struts. Everyone mostly likely fixed it by today. And guess what? Three days ago, a week ago, a new vulnerability in Apache Struts No. 2, which was fixed, was discovered. And that’s not going to be the last one, right? So open source is a living thing, vulnerabilities are coming and going, and you have to keep track.

    So I believe the top managers – CIOs, sometimes CISOs – are not aware of all those effects that came out there, with more open source, right, that the current tools does not solve it. And, finally, that they need a tool that is designed to track changes in the security of their open source inventory along the time.

    Shimel: Exactly. I mean, you talk about Struts 2, which is sort of the poster child here because of all the press and notoriety that Equifax got. And I saw a presentation by – I forgot what company it was, but what really surprised me, Azi, is, even after we knew it was bad and you had to patch it, you had to upgrade it, the amount of people who were still downloading and using the old version – it dropped off from maybe 80,000 a month to 70,000 a month. Right?

    Cohen: Awareness, right? And, by the way, these numbers are changing, so you may not know, but we just released a tool called “Vulnerability Checker.” It can be downloaded from out website, whitesourcesoftware.com, and, basically, it will check – it will do an automatic check to check, for clients _____ – people that are interested whether their systems are affected by Apache Struts 2, right? So for those that are aware and would like to know whether they have some issues with that right now, they can download it free and check very quickly their system and find whether they are affected or not.

    Shimel: Yeah. But this is also the future of where companies need to be. They need to do this and then they need – you know, Azi, I remember I was selling vulnerability management and patching, oh, maybe 2005. I was talking to one of the CIOs. They had three CIOs at Citibank. This is before it was called “Citi”; it was “Citibank.” They had three global CIOs. I showed them a system that would scan for vulnerabilities and, if there was a known patch for the vulnerability, it’d integrate it with a patch manager that would automatically – that would patch these up.

    Cohen: Sure.

    Shimel: And he said, “This is great, but, Alan, we don’t just install a patch ’cause we found a vulnerability. Before we can install a patch, we have to do regression testing on all of the applications. We run about three months behind.” So, literally, there was a three-month cycle by the time they would patch a known vulnerability that they found. And, yeah, I’m not saying it’s that bad today, but that sort of mentality, that approach, just doesn’t work at the speed of business today.

    Cohen: You’re 100 percent right. And I bet that Citi today have hundred times more vulnerabilities per application than they used to have at those days, but this is an important point because we face that any of our large clients – and, actually, we just came up with a very, very smart solution for that. So we know, as you mentioned, that it takes them a long time to patch, right? And we know that they have thousands of vulnerabilities sometimes, and they need to know where to put their time, right? Especially if it takes longer time.

    So we came up with a tool called “Effective Usage Analysis,” and the idea is very simple. When a developer picks up a new open source component, this component usually come with 10 or 15 different functions. Each one of them may have some vulnerabilities, etc., so this entire package could come with, let’s say, 10 different vulnerabilities. But the developers will use only one or two functions, and, therefore, you’ll be exposed only to two or three out of those 10 vulnerabilities. So Effective Usage Analysis is a new module that we release. It runs over the code and identify how the developers use the open source and, therefore, clean out all the non-relevant code.

    So, for this kind of – for the Citis of the world, that have thousands of vulnerabilities, Effective Usage Analysis will drop the number of relevant vulnerabilities by 70 percent – seven-zero. These are the statistics. And now they’ll have only the most severe 30 percent where they can and should spend those three months in order to fix them, on the road to get a better security solution. It’s huge. This difference is huge. We get a lot of good feedback from clients that are testing that. It really helps them to make sure that every hour that they spend is much more effective.

    Shimel: Excellent. And this thing you can also get at WhiteSource Software?

    Cohen: Absolutely. Yeah. It’s a new model that we just released.

    Shimel: And what’s the name of it again?

    Cohen: Effective Usage Analysis.

    Shimel: Effective –

    Cohen: EUA.

    Shimel: – Usage Analysis. EUA.

    Cohen: Yep. Yeah.

    Shimel: Got it. Well, Azi, as I mentioned to you before we started recording, the 15 minutes here goes very fast.

    Cohen: [Laughs]

    Shimel: We’re already over 15 minutes. We could probably talk all day about this, but we’re gonna have to call an end to this episode of DevOps Chat. But maybe we’ll have you back on soon and we can continue the conversation.

    Cohen: Sure. Thank you. It’s always a pleasure talking with you, Alan, so I’m looking forward to it.

    Shimel: No, it’s my pleasure, Azi. I feel like we could sit and talk and go all day about this, but we’ll call it a wrap. Azi Cohen, a co-founder and chief of U.S. operations for WhiteSource Software, thanks for being our guest on this episode of DevOps Chat.

    Cohen: Thank you for the opportunity, Alan. Always a pleasure.

    Shimel: Pleasure. This is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard. You’ve just listened to another DevOps Chat.

    — Alan Shimel