devopsy.kinsta.cloud

Tag: security

Murphy’s DevOps: The Internet Apocalypse

I’ve been immersed in cybersecurity for a good stretch, since it was known as just “infosec” and “security.” Over time, I’ve had opportunities to work with some brilliant minds and young-gun “hackers” (I’m not a name dropper, so I’ll refrain from using them as SEO-bait). I’ve watched attackers transition from being basement-dwelling teenagers to organized intruders to APTs. At one point or another, I’ve met all of Five Horsemen of the Internet Apocalypse: Scam, Extortion, Embarrassment, Theft and Death.

The biggest cybersecurity news story of all time is still Edward Snowden. Fancying himself a “whistleblower,” champion of the Constitution and privacy rights expert, this fugitive data thief accused of espionage by the United States government has done more to force businesses and individuals to think about digital security and privacy than anyone or incident before him.

Snowden aside, there are thousands of other stories about just how fragile our online lives and businesses are. If you were at the devopsy.kinsta.cloud Rugged DevOps event at RSA 2015 and caught the presentation by Wired cybersecurity and privacy writer Kim Zetter, “2015 — The Year in Hacks,” then you had a chance to get a great overview of some of 2015’s biggest digital crimes. You might have even noticed the Internet Apocalypse Horsemen riding through.

With an ear to the ground on everything the NSA and APT-using hackers are guilty of, @KimZetter never fails to intrigue readers and live audiences. Whenever you read her stories or listen to her speak, you always walk away reassured that when all the smoke and headlines have cleared, the great deep-down reality is that everything we digitize is subject to the whim of Scam, Extortion, Embarrassment, Theft and Death. If you didn’t have a chance to attend, please enjoy some of the highlights listed below.

China vs. U.S., Spy vs. Spy

She kicked off with the biggest hack of 2015: the one that penetrated the U.S. Office of Personnel Management (OPM). The full extent of the damage done and who the actual attackers were may never be fully realized. Were they Chinese spies, rogue hackers or a combination of both? What we do know is that it exposed millions of identities tied to covert U.S. operatives and their family members listed on security clearance forms. It may have even exposed personal information on everyone who has ever applied for a job with the federal government. One for-sure lesson is that even after several decades of security product development (with more than 800 available for review at RSA), the world is still in need of innovation in the space.

Men Behaving Badly …

Some might argue that Embarrassment made a special appearance at Ashley Madison, but the fact that suicide was part of that hack leaves me to think that Death was the lead actor there. @KimZetter pegged the data theft as the most brazen hack of 2015. With 30+GB of account information stolen and dumped, login credentials for 32 million accounts purloined, credit card transaction information accessed and even several suicides tied to the incident, the hack again reminded the world that the great deep-down reality is that everything we digitize can be used by attackers to scam, extort, embarrass, steal and even kill us.

From the Keyboards of Babes …

Anyone at the presentation must agree that Embarrassment really stole the show in the hack of CIA Director John Brennan’s AOL email account. Allegedly perpetrated by a teenager, Zetter describes the incident more deeply in her October story: Teen Who Hacked CIA Director’s Email Tells How He Did It

Keep Calm and Internet On

Anyone reading this may be walking away with a rather pessimistic view of our chances of remaining secure online. The truth, however, is that the existence of determined hackers should do no more to stop individuals or businesses from going online than road rage should to prevent anyone from getting behind the wheel of a car.

If any lesson can be learned from news articles pumped out by @KimZetter and her peers, it’s that the world should continue to take full advantage of the Internet but to also take the time needed to apply effective security. Quite simply, we all should keep calm and Internet on …

April 22, 2016
DevOps Chat: Threat Stack’s Pete Cheslock and Chris Gervais

I recently had a chance to sit down with Pete Cheslock and Chris Gervais of Threat Stack to talk DevOps and Security. Both of these guys are dialed in on both topics so as you can imagine it was a great conversation. Here is the audio file with the transcript underneath.

Pete Cheslock, Senior Director of Ops and Support – As the head of Threat Stack’s operations and support teams, Pete is focused on delivering the highest level of service, reliability, and customer satisfaction to Threat Stacks growing user base. An industry veteran with over 15 years’ experience in DevOps, Pete understands the challenges and and issues faced by security, development and operations professionals everyday and how we can help. Prior to Threat Stack, Pete held senior positions at Dyn and Sonian where he built, managed and developed automation and release engineering teams and projects.

Chris Gervais, VP, Engineering – As Threat Stack’s head of Engineering, Chris is passionate about building, not only a rock solid, high-performance product, but also a team of elite engineers, industry best processes and a culture that attracts the best talent. Prior to Threat Stack, Chris held senior positions at lifeIMAGE, Enservio, Partners Healthcare, Inc., Inflexxion, Inc. and VIS Corporation, where he was responsible for engineering, technical operations, and technology strategy for cloud platforms.

Alan: Hi, this is Alan Shimel from devopsy.kinsta.cloud for another DevOps chat. Happy to be joined today by two special guests, both from Threat Stack. First is a gentleman pretty well known within the dev ops and security space, Pete Cheslock. Pete, welcome.

Pete:                             Yeah. Thanks for having me.

Alan:                             Thank you. And joining Pete and I is, he’s kind of Pete’s partner in crime here, Chris Gervais. Chris, welcome.

Chris:                           Thanks so much.

Alan:                             Great. That was our audio check, guys, and we’re good. So Pete and Chris, why don’t – our audience may not be familiar with Threat Stack. Can you give briefly a little background on the company?

Pete:                             Yeah. Absolutely. So Threat Stack is a company that’s been around for a few years now, and what we’re doing is we have a cloud security platform that is basically designed to work with all kinds of different workloads that are running, whether in the cloud or in your own data center, to analyze for internal/external threat, to analyze for data loss prevention, or – and basically just auditing the kind of, answering the question of who did what when on your system.

So if you’re someone who is on a security team and you need to follow various auditing rules, PCI, or HIPAA, or things like that, you can use Threat Stack to basically comply with those policies. And also if you’re just an operations team and just trying to understand, you’re doing, kind of doing the dev ops. You’re giving people broader access to your systems a you’re trying to understand what they’re doing with that access, trust but verify, you can use Threat Stack to basically determine and answer those questions for you.

Alan:                             Fantastic. And Pete, is this delivered as a service, or is it – not an appliance any more, but and not even a on prem. But is it a service?

Pete:                             Yep. It’s a SaaS app. We have a very lightweight agent that runs on the system, and what we do is right now we support Linux systems. We’re capturing events from the Linux kernel, so it’s that source of truth of all activity on a system. And we also do some integration with if you’re on Amazon we do some integration with the cloud trail so that we can alert on not only your system-level events, but also for Amazon users to _____ on cloud trail events, so events that are happening at a higher kind of EPI level.

Alan:                             Great. And guys, I don’t – I didn’t mention your titles. I apologize. Chris, what’s your role at Threat Stack?

Chris:                           So I’m the VP of engineering here.

Alan:                             Okay. Excellent. And Peter?

Pete:                             So, I run the operations and support teams, the technical operations.

Alan:                             So we’ve got tech ops and engineering? Excellent. So guys, and we were talking a little bit before we started the recording here about this whole – the evolution, if you will, of security, you know, security tribe merging or at least joining into this larger dev ops tribe, if you will. I don’t know if it’s larger. But the merger of security and dev ops. Chris, I know this is something that you followed now for a few years. What’s kind of your take on it?

Chris:                           You know, I think it’s, like there’s a couple things here, one of which is, especially for folks who are building in the cloud and trying to take advantage of all of the sort of speed and velocity you can get with software to find everything and all that stuff is you can’t adhere to the model the security is the domain of the few any more, and that it’s a walled-off thing over in the corner, or that it lords over your software development engineering process, roll-out process, infrastructure process.

Like, all that stuff has to get baked in, right? And it has to get baked in at the earliest possible point that it can. And one of the best ways to do this, and it’s a thing we’ve done at Threat Stack is, it’s not just about the tools. It’s about making sure that your entire team is involved with this from the start, and that it’s not just a person who’s got to sit there and be a gateway and a worrier about this, but everybody is focused on it, right?

Just like today, you’ve got, whether you’re a software engineer or infrastructure engineer, you’re an engineer. You’re sitting together, and you’re solving problems together of how do I get my stuff out? What kind of systems do we need? What do my work loads look like? You’ve got to take that same approach with security and make it just part of that flow. And so in some ways, like if you think about the democratization of this stuff, it’s really about – and this is one of the things behind Threat Stack is make this inclusive, not exclusive, because you can solve problems better that way.

Alan:                             Amen. Pete, you and I first met, I think it was shortly before I even launched devopsy.kinsta.cloud. And so I know you’ve dealt with this and have been dealing with this issue for years. My impression in speaking to a lot of people is that the developer and even ops community seems much more open, if you will, to welcoming the security folks into the meeting, into the tribe, and giving them the seat at the table. Where too often I’m afraid to say, because I come from the security side of the house, it’s the security guy who’s digging in his heels and saying, “No. We can’t have that. We need to maintain control. We need to maintain independence. We need to have our own kind of thing.” But the good news is I see that kind of hard headedness softening and I do see us, the security folks coming in. What’s your impression?

Pete:                             Yes. I remember. We were actually doing a – it was like a kind of roundtable dev ops discussion, and what I thought was most interesting is a lot of the _____ were all tilting more towards the security side. And yeah, that was a couple years ago at this point. Yeah. So I definitely agree. The conversation that I see in attending a lot of the different kind of web operations and dev ops related conferences is much more on the side of operators and developers who have essentially kind of figured out how to work well together and deliver value for businesses are realizing that security is much more important than it ever was.

The kind of joke is it was always important. It’s just a lot of people just didn’t really care about it. But now it’s affecting so much of what we’re doing and more and more issues and vulnerabilities and open-source software are kind of coming to light that I think more operations and dev teams are realizing that this is something that we really need to deal with now versus having some sort of company-ending event. And so I think what’s happening is that especially smaller start-up companies, even companies that get up into a few hundred engineers don’t even have a dedicated security team, so they kind of have to do it themselves.

In more legacy teams, I see it as well where they want to, more legacy companies, they want to build _____ they bring in security engineers for that organization. And you find a lot of the same thing where, like you were saying is, they want to slow things down and they want the control. The problem is is that that model doesn’t work any more. And we’ve seen it. It’s the concept of shadow IT, right? The security team up there constantly saying, “Nope. Can’t use Amazon,” because of whatever reason. It doesn’t stop anything. The company will end up having ten Amazon accounts under ten corporate credit cards.

Chris:                           Yeah. That’s such a good point, too, because I think one of the things, like the fundamental shifts you have to make is, right, a lot of that old security thinking was rooted in prevention, right? And so if you really think that you can use that model in sort of the modern era, God bless ya. But, man, that’s going to be tough. Versus if you can now focus on detection and involvement, you’re going to be – and then, right, you’re dev opsing the things because you want to go fast. You can now put changes into effect super fast by connecting your information sources to the things that allow you to take, allow you to make change quickly. That’s how you get – I think you really make some progress. And that’s where we see a lot of folks fall down when they think they can take the sort of legacy enterprise IT approach and just bring that to the cloud, including the type of people that are involved.

Alan:                             Absolutely. So, guys, let me bring this back to Threat Stack, if I can for a moment. Your customers, you think they come from the dev and sys admin or ops space? Or are the security people your customer, as well?

Chris:                           It’s both, and as our company’s grown and as our customer base had grown and we go up market more, we’ll start having more and more folks who have info sec and other titles like that in discussions with us. Where we kind of started was with the dev ops community, right? We’re a very dev ops friendly tool in terms of getting our agent deployed. And like Pete did an awesome job of building cookbooks and templates that people could use to get Threat Stack running really quickly so that it wasn’t a pain in the ass to get started. It was really, really simple. But that is going to sort of start to change over time, but what we hope is that we’ll continue to see the folks who are dev opsing and infrastructuring involved in that conversation and it doesn’t just turn into the domain of just the security people.

Pete:                             Yeah. In a lot of cases, too, what happens is you have a CTO or a head of engineering for some company, and maybe they’re running 200, 300, 400 servers on Amazon. Not trivial number of systems, but still not kind of enterprise scale of thousands of systems. But they’ll have their head of engineering come to them and say, “We’re about to close this deal. It’s with this company. They are going to require us to get our PCI compliance, or HIPAA compliance,” or some sort of audit _____. And so as an operations person, I’ve been in this scenario before at a previous company. I was running an operations team and we were about to sell it to the US government, which required us to go through a thisba audit, which was very intensive audit. And this was years ago, and we ended up having to build a lot of the tools. And I always kind of joke here. It’s like I love working at Threat Stack in operations because I get to use Threat Stack on my platform that I run. It’s awesome that way.

Chris:                           I have to go build tools like I used to.

Alan:                             Yeah.

Alan:                             Exactly.

Chris:                           Yeah. And to that point, it’s actually one of the reasons why I joined Threat Stack was that in previous roles where I delivered – my teams delivered – stuff into health care and other regulated industries and something like Threat Stack didn’t exist, so I had to stitch together stuff painfully from other types of tools to answer like all these security requirements being dumped on my desk from larger enterprises who weren’t used to dealing with sass companies. And thrown into the world of print security. And having a tool for me like Threat Stack, and frankly getting the opportunity to help build it out, was such a huge opportunity and attractive for me to come here because you could just instantly see the problem that this was going to solve.

Alan:                             Absolutely. So, guys, we’re running low on time because these things always go quickly – too quickly. But I’m doing a webinar next month with a couple of companies called New Frontiers in Cloud Security. I’m going to ask each of you, what do you see as sort of the biggest new threat, if you will, on the horizon for cloud security?

Pete:                             Yeah. That’s a really good question. I think what we’re finding is that as people move to the cloud, there was a long time a lot of thud around the cloud is not secure. You can’t move to the cloud. It’s not secure. And in reality, the cloud is just as or can be more secure than your existing environment if you use kind of the right tools to manage and monitor the systems, especially for Amazon users. They have a whole suite of tools that can really assist you to secure your system well.

What I regret it’s, and especially as someone who runs an operations team for a security company, we do everything we can to lock down the front door, to make sure that it is extremely hard to get onto systems to do things. Like we have a lot of checks and balances in order to do so. But honestly the biggest fear I have is people coming in from the back door, essentially, and trying to get in through some sort of malware on their systems, or through some sort of fundamental breakage in an open-source code where like Heartley had happen last year.

Alan:                             Yeah.

Pete:                             So that’s where I’m glad to have tools here via Threat Stack and other tools that we have that I can continually monitor my systems for these anomalies. Because it’s going to be nearly impossible to know of what the next zero day kind of critical bug is. But if I can monitor for anomalous activity, that can give me a heads up in advance.

Chris:                           Right.

Alan:                             Perfect. Chris, how about you?

Chris:                           So, I think one of the biggest threats, actually, is, and just adding to what Pete said, is people thinking they can solve cloud security like they solve on-prem security. And I can just worry about things at the ingress and egress point of my network. And I used this appliance thing at my last place that had, you know, it was co-load or my own data center, and I just want to replicate that model in the cloud, right?

Which, I just think is – you have to look at the work load and the host as that’s the, right, that’s the battle ground, and if you’re thinking you can solve this at a network layer, it’s going to be really tough because that doesn’t tell you what’s happening on your systems, which is, again, these things are coming and going, right? You’ve got probably more cattle than pets. You’re able to build up and burn down really quickly.

Are you able to really identify what was anomalous on those work loads over time? And if you can and if you think you can just solve it like you solved stuff five, ten years ago, it’s just like a rude surprise. To me, that’s one of the biggest threats out there.

Alan:                             I don’t disagree, guys. Hey, I’d love to sit and chat all day, and maybe we will in the future. We’ll get together at some dev ops days or something. But I’m going to need to wrap up here. We’re kind of at the end of our time limit. So Pete Cheslock, Chris Gervais, Threat Stack. Thank you so much for appearing in this segment of DevOps chat, and we’re looking forward to hearing more about Threat Stack and dev ops and security working together to make the cloud better for everyone, and continued success.

April 15, 2016
The Cost of Not Building with Security in Mind
The unfortunate reality for today’s organizations is the fact that a security breach is bound to happen. Major breaches are happening with alarming frequency and fill the news headlines almost daily. And behind many of these major breach stories is a software vulnerability that has been exploited. There is a silver lining, however. Addressing security at the development stage can help organizations “get upstream” of certain issues, which goes a long way toward alleviating potential breaches.

Now there are always two sides to every coin, and this is where companies need to weigh the costs of not taking a proactive approach to making security a key part of their software development process. Is the upfront time and effort worth it when it comes to developing software and ensuring bugs and vulnerabilities are addressed before it is put into the wild? The simple answer is, yes! We are already seeing this in certain industries such as financial services, which learned the hard way that it is a critical component of software development—mitigating risks and significantly lowering the financial burden associated with a major breach.

In fact, security should have been more central to software development a long time ago. As software, and more broadly technology, continues to evolve and permeate our lives from more angles, it is crucial that security be a consideration—a “use case” as developers call it—from the earliest conceptual stages of a project. The costs of not doing so are simply too painful to imagine otherwise.

Shifting to Security-First

To build more secure software, organizations typically must implement a software security initiative. You can break it down into four steps:
- Assess your current software assurance posture
- Define the strategy your organization should take to ensure a viable posture
- Formulate a road map of how to achieve that posture
- Implement your strategy
The above steps are simple and when you think of the alternative to not doing this, adding security as a pivotal part of the software development process seems like a no-brainer. To better understand what I mean, you need only look at the cost the average breach has on an organization. According to the 10th annual “Cost of Data Breach Study” independently conducted by Ponemon Institute, the average consolidated total cost of a data breach in 2015 was $3.8 million, an increase of 23 percent from 2013. The study also reported that the cost incurred for each lost or stolen record containing sensitive and confidential information increased 6 percent, to a consolidated average of $154 from $145. Depending on how much data has been compromised, the financial fallout can be staggering, if not crippling, to an organization.

Conversely, the cost to repair a single vulnerability in an application during the design phase is less than $500, according to the IEEE Computer Society. The fact that the financial impact of not addressing security during the development process can quickly become cost prohibitive, is a clear indication that secure software development practices can no longer be overlooked. Breaches are now a boardroom issue and require a seat at the development table.

As we can see from the stats above, the economic fallout for organizations is obvious, but with the Internet of Things coming to a house near you, this issue is suddenly becoming more personal and painful for the average person. Whether an attacker takes over your thermostat from Russia or finds a way to monitor your home via your baby camera, vulnerabilities are making it easier for malicious actors to corrupt corporate, government and now individual networks like never before.

We are well beyond the “it will never happen to me” phase. Breach stories that used to happen to so called “other” people are more likely to happen to you if software defects continue to be ignored and are not fixed when they should be. No matter how you crunch the numbers, if security isn’t addressed at the software development level, the result will always end in a costly lesson learned.

About the Author/John Dickson

John B. Dickson is an internationally recognized security leader, entrepreneur and Principal at Denim Group, Ltd. He has nearly 20 years hands-on experience in intrusion detection, network security and application security in the commercial, public and military sectors.

Dickson is a popular speaker on security at industry venues including the RSA Security Conference, the SANS Institute, the Open Web Application Security Project (OWASP) and at other international conferences. He is a sought-after expert and regularly contributes to Dark Reading and other publications. A Distinguished Fellow of the International Systems Security Association, he has been a Certified Information Systems Security Professional (CISSP) since 1998.

As a Denim Group Principal, he helps executives and Chief Security Officers (CSOs) of Fortune 500 companies and government organizations launch and expand their critical application security initiatives.

Twitter: http://twitter.com/johnbdickson
Linkedin: https://www.linkedin.com/in/john-b-dickson-cissp-41a149
April 14, 2016
How Continuous Delivery Challenges Security

Security and continuous delivery each have implications in their effects on each other. While continuous delivery can demand new security measures, traditional security can slow continuous delivery or simply not address its security needs at all.

Micro Case Study Clarifies Security Conflict

Amrit Williams, now CTO of CloudPassage, shares an experience that exemplifies the challenges continuous delivery poses for security. Williams once worked with one of the largest national HMOs in the United States, which developed and supported a customer healthcare portal to enable customers to access health data and take advantage of other HMO services.

At the time of his service there, the company sought to enhance its portal’s performance to challenge other HMOs in the marketplace that were popular, in part, due to the strength of their portal.

“They wanted to add a bunch of new features and make continual improvements by way of moving from a development model of new releases every six-month period to new site releases and updates every couple of hours or about four times per day,” says Williams. But every time the Ops team would bring up new containers and compute resources to deploy new technologies and application code, success would count on repeated manual changes to firewall rules to appropriately pass data, enabling applications to talk to the portal and its technologies.

“They finally decided to allow the firewall rules to apply to the application at the server level rather than at the underlying network level so that they didn’t have to go changing those rules all the time,” says Williams.

In DevOps, Security Still in First Gear

“Traditionally in the enterprise, security has been about speed only when the company is potentially dealing with a compromise, a policy violation or some other threat to the business,” says Williams. The organization is not used to having to respond quickly with security simply to deliver code. Common security tools were not designed to shift and adapt to automated code development and deployment.

“For example, a lot of times the security teams will rely on endpoint security tools that typically require static IP addressing, which is antithetical to dynamic compute models,” explains Williams. These mammoth resource-hogging security applications ask too much and secure too little if they can even work effectively in DevOps shops at all. When you must stop to adjust these security tools, you may trigger change management processes that can slow the development process even further.

Why Not Fail Fast?

While DevOps makes it easier to isolate and fix coding errors quickly, this doesn’t appear to spill over to security. Fixing errors to make the code work doesn’t mean the code is more secure. These changes could even introduce new security flaws that were not there before.

Securing continuous delivery is about the security team surrounding dynamic processes with protections that keep up with the speed of the continuous delivery pipeline. This can be difficult when these processes are automated, bringing up resources on demand to create and deploy software.

“It is really the deployment and configuration of these environments that can lead to some of the biggest security concerns and not necessarily the code itself,” he says. “It is that aspect of DevOps that security is usually not very familiar with, which can really result in them being left out of the process because they try to apply a rule or a government policy that is again, antithetical to that process.”

Continuous Delivery Security Incidents Challenge Legacy Security

In this case example, Williams shares a particular type of threat that legacy security tools would not prevent in a continuous delivery environment.

“It was 2012, during Christmas and it happened to customers using a region of Amazon‘s public cloud services. Amazon rebooted a bunch of servers, and some of those servers were running local host-based firewall management tools that were reliant on connectivity back to the management consoles as well as a static IP address,” says Williams.

When those systems came back online, neither the agents on the hosts or the tools functioned properly. Amazon and its customers had to work to ensure the agent software on the hosts worked and communicated with the firewall management tools and that customer systems were secure. This was important because of the number of sales Amazon customers had to process securely at the time, which was just a few days before Christmas Eve.

Again, this is an example of the failure of legacy security tools inside an environment that was increasingly adding automation while approaching continuous delivery. The lesson here is that as DevOps and continuous delivery approaches are altogether unique from legacy development, so the security tools that protect these environments need to be new, unique and suited to continuous delivery by design, lest they fail to survive partial outages such the Amazon example.

March 24, 2016
Developers Cite Startling Lack of Digital Leadership

Despite app backlogs, developers say their efforts are underfunded and undertrained, and lack a priority for security

We’ve long written about the challenges enterprises face when developing the apps they need, digging out of app backlogs and technical debt, and the overall importance of running a productive development pipeline. And, how to keep up, enterprise’s are seeing more and more citizen developers rising to fill in try to close the lag between what software apps they need built.

Which is why it was disheartening to read in a recently published report, “Investment in Enterprise Developers is the Best Risk Management System,” based on a survey of more than 100 developers by the Application Developers Alliance, that 40 percent of respondents have experienced failed development efforts from lack of funding, and a third are concerned that current projects could be pulled for budgetary reasons. Also, despite survey after survey of executives citing security as a “top priority,” only 45 percent of enterprise developers surveyed believe that their organization sets a “high” priority for security.

Not surprisingly, according to the survey, four out of five enterprise developers surveyed work on Windows and/or OS X, and 24 percent work on Linux. Yet only 20 percent work on mobile platforms exclusively. And, interestingly, two-thirds of enterprise developers develop their apps exclusively HTML5, hybrid or native, with native being the most common. And, not surprisingly today, cloud is the most common way to deploy apps during development, test or production.

Unfortunately, many developers report underfunding in technology, processes and training. A third report outdated technology and processes in their organizations—more than half (51 percent) of those in organizations with more than 100 employees.

Leadership Falling Short in Many Areas

When it comes to cultivating processes and technology guidance, many enterprises also fall short. Only 37 percent of those surveyed said their organization has a Center of Excellence. Not surprisingly, the larger enterprises were more likely to have a Center of Excellence; however the lack of such centers is more common in North America and Europe, Middle East and Africa. Most every organization surveyed in Asia, however, has a dedicated Center of Excellence. Additionally, a surprisingly low 29 percent of of developers surveyed reported that they are required to attend training, certification programs or other continuing education.

That’s stunning, considering that increasingly businesses are driven by their digital efforts. There’s no shortage of surveys citing this. In a recent study commissioned by CA Technologies, “The Battle for Competitive Advantage in the App Economy,” 43 percent of survey respondents said that becoming software-driven is central to being competitive today, and nearly 80 percent said that would be true in three years. Broadly, to be competitive in the years ahead, enterprises are going to have to be exceptional software companies in addition to their core current products and services. Yet survey after survey finds that enterprises are falling behind in their app development goals and are having a challenging time finding the talent they need.

Additionally, the Application Developers Alliance survey found that only 50 percent of enterprises discuss the capabilities and skills they need to succeed, while only 26 percent integrate such competencies in their evaluation process. And, just as when it came to establishing Centers of Excellence, Asian companies stood out, with 78 percent of Asian developers saying necessary skill development is discussed.

Centers of Excellence, the Application Developers Alliance survey found, also are excellent indicators of whether an enterprise is committed to building secure software. While 64 percent of developers believe they’re “adequately” trained to build secure software, more than 70 percent at organizations with a Center of Excellence contend that security is a high priority where they work. If they work in an organization without a Center of Excellence, that number drops to 28 percent, and 17 percent rank security as a low priority in such enterprises.

Clearly, if enterprises expect to compete globally in the years ahead they’re going to need to step up their priorities when it comes to budgeting app development, cultivating the skills they need and building the internal organization necessary to succeed as a digital enterprise.

March 16, 2016
Threat Stack Cloud Security and Monitoring Now Integrates With Slack For Real-Time Response to Security Threats
New Integration Provides Security Alerting and Immediate Collaboration for Security and DevOps Teams

BOSTON– March 9, 2016 – Threat Stack, a leader in cloud security management and compliance, today announced its integration with team communication platform Slack. The Slack integration with Threat Stack’s Cloud Security Platform™ alerts channel members to security concerns and enables instant workflows for cloud-based security operations center (SOC) teams. The Threat Stack Slack integration improves the speed at which team members can respond to and communicate about real threats the instant they happen.

“Threat Stack’s integration with Slack alerts our entire DevOps team to security concerns and alerts in real-time,” said John de Freitas, principal software engineer, OnShape.”Threat Stack helps us to collaboratively detect potential security issues, and Slack allows us to communicate and address them immediately.”

“Today’s fast growing businesses leveraging modern infrastructure for scale need to incorporate security into day-to-day workflow tools,” said Pete Cheslock, senior director of operations and support, Threat Stack. “Integrating Threat Stack security alerts into Slack allows for context and conversation around important events, providing valuable insight into activities happening across your infrastructure.”

Threat Stack’s Slack integration automates SOC team’s processes, delivering only the most important security alerts directly into a designated Slack channel. After all alerts are thoroughly analyzed and baselined within Threat Stack, Severity 1 and 2 alerts are delivered to Slack, including:
- Abnormal user behavior (e.g., insider threats)
- Abnormal process behavior (e.g., new process behavior)
- Abnormal network behavior (e.g., connections to new and bad IPs)
- File tracking and copying of files
- Abnormal infrastructure and CloudTrail activity
The Slack integration works alongside Threat Stack’s audit trail capabilities, and improves SOC teams’ workflows by pinning alerts, dismissing alerts and identifying new patterns and rules. Additionally, Slack Plus users can easily archive conversations for audit and compliance purposes. By leveraging the benefits of Slack’s real-time communication, users gain deeper context on Threat Stack security alerts and the ability to collaborate pre- and post-alert to determine the best course of action.

To learn more about Threat Stack’s Slack integration, please visit our blog.

Availability

Existing customers can get started by simply providing their webhook API and alert severity preferences in the Threat Stack dashboard. New customers can get started here: http://get.threatstack.com/threat-stack-free-trial

About Threat Stack

Threat Stack enables growth-driven companies to scale with confidence by identifying and verifying insider threats, external attacks and data loss in real-time. The only fully integrated, cloud-native continuous monitoring solution that gives companies instant visibility and automatically responds to changes in their environment, Threat Stack provides the coverage needed to run secure and compliant, in all environments, without sacrificing speed and efficiency. For more information, or to start a free trial, visit threatstack.com.
March 9, 2016
Taking Stock of DevOps: Where to from Here?

Have you noticed how every technology trend goes through a series of stages on the path to mainstream adoption? First comes doubt and denial, then tacit acceptance and finally acknowledgement that it works fine after all. The DevOps movement is no different.

First came questions about what DevOps actually is and its usefulness in an enterprise context (whatever an enterprise actually means these days), then a trickle of success stories and finally the publication of tangible and quantifiable benefits.

Thankfully, we’ve moved on from the “Is it a bird or is it a plane?” stage. Of course, that doesn’t stop hype, but at least the publication of benefits—such as those recently illustrated in the global study, “Assembling the DevOps jigsaw“—allow us to cut through all the “DevOps solves global warming”-type of nonsense being written.

So with the value jury finally in, the next question we should be asking about DevOps is, Where to from here? Interestingly, the old Wikipedia entry for DevOps provides some guidance, stating that DevOps is:

… a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

That’s pretty good, because it emphasizes the importance of collaboration across all IT functions (not just Dev and Ops). However, this still doesn’t quite cut it for me. Although lots of cultural and automation heavy lifting has been done to bridge Dev and Ops, more work is needed to understand how aligning other IT functions to DevOps actually benefits the function itself and the business. Also—and perhaps just as important—how aligning other business functions, such as HR and finance, can lead to more success.

DevOps Works Because It’s Good for Business

Business leaders talk in terms such as faster lead times, customer conversions and time-to-value, which (putting cultural discussion aside) is really the essence of DevOps. And because DevOps adoption directly correlates to making a buck, it has a fair chance of garnering attention and investment from the business.

That said then, information security and other professionals would do well to hitch their wagon to DevOps. One of the beauties of the movement is that teams collaborate and provide input much earlier in the development life cycle, with processes then automated to ensure faster release time and quality. By also involving security earlier, businesses could feasibly harden security, balancing all those “rain on your parade” audits and checklists with automated methods that ensure compliant configurations lead to faster deployments.

An interesting but important benefit is how this approach helps align IT security to business outcomes. Rather than proving its worth through a whole raft of technical sounding measures, such as penetration test scores, patched vulnerabilities or security incidents detected, security can report functional value in context of business goals, such as how automated compliance equals faster releases, leading to increased revenue.

Of course, DevOps doesn’t just involve Dev, Ops and security, it also will involve other functions providing valuable input to help increase speed and quality. Think of it like the old “Stone Soup” story but without the trickery—everyone, be they software designers, product managers and enterprise architects, providing advice and expertise earlier in the software life cycle so essential elements of resilience, supportability and scale are baked in right from the get-go.

DevOps Shouldn’t Start and End in IT

The DevOps way suggests that we shouldn’t just restrict ourselves to IT functions—start there, yes, but other facets of the business should also participate. This sounds like common sense, but in reality it’s more critical because the boundaries between business and digital have blurred significantly. Fail to recognize this and we could end up a silo of good intentions: culturally correct but lacking any teeth.

This explains why even the much-maligned HR function has a DevOps role to play. For too long, many HR departments have been fundamentally back-office, dipping their toes in the muddy waters of organizational culture with periodic staff surveys and performance appraisals. But this doesn’t go far enough. Now, HR leaders must step out onto software factory floor and work hand-in-step with other DevOps practitioners to identify all the organizational and psychological barriers that inhibit business growth and the development of talent.

Finance, too, must become aligned to DevOps. This involves moving beyond traditional IT cost-center thinking to developing new fluid funding models needed to stimulate software innovation by agile teams. This means business change agents must join forces with DevOps practitioners to look at better ways to capitalize or expense software development costs or optimally monetize new apps, APIs and information assets. Once again, the earlier this happens in the software life cycle, the better.

From an IT perspective, we’ve come a long way with DevOps in a relatively short amount of time. But this is only the start of the journey. Most businesses haven’t even considered transformation of the whole organization using DevOps principles as a change agent. Those that do most likely will gain first-mover advantage—and that’s a good place to be in an economy increasingly shaped by application software.

March 9, 2016
Murphy’s DevOps: 7 Habits of Rugged DevOps

Attendees of Rugged DevOps Connect at RSA packed Moscone West’s second floor Feb. 29 to immerse themselves in security. Among the presenters of the daylong event was Forrester analyst Amy DeMartine, who provided a tutorial on how security, developers and operations folks can work together better in the new DevOps world.

Through a slide show, DeMartine laid out her Seven Habits of Rugged DevOps, three of which are discussed in this column:

1: Increase Trust and Transparency Between Dev, Sec and Ops

We live in a world where technology’s goal increasingly is to automate everything, with less reliance on humans—at least, that’s what many marketers would have us believe. However, DeMartine emphasized that Security and Risk groups, if they are going to play a key role in DevOps, need to speak to the practice’s true owners—App Dev and Infrastructure and Ops—in a language they can understand. Here, it’s not automation that matters most. It’s communication—among actual human beings—that’s paramount.

She emphasized a real disconnect between these groups, with AppDev being perceived as the department of “Anything Goes,” Infrastructure and Ops thought of as the division of “No,” and Security and Risk seen as the “Persistent Nagging” sector.

Imagine for a minute, a family unit comprised of Mom, Dad and a highly motivated teenager. The teenager is fast, full of energy and always pulling the trigger; Mom is pragmatic, a disciplinarian always having to tug at the teenager’s reins; and Dad is constantly frustrated that no one listens to his determined warnings. The family’s living room is the scene of many “heated” debates, where each side scores its share of wins but there are really no common agreements that satisfy everyone’s needs. When the teenager wins, it’s because Mom simply doesn’t have the energy to resist any further. When Mom wins, the teenager turns on the iTunes, plugs in the headphones, withdraws and possibly even starts searching for a new family. Dad’s victories are often followed by a series of door slams and the silent treatment.

Now imagine if the three sides found a common language? One that not only got each to see the others’ viewpoints but also developed a system where the teenager was set free to operate within defined boundaries, and where he or she even wore enough safety gear to keep risk to a minimum. We’d have a much more harmonious place, one where the teenager continued to grow without risking the family ship.

Interestingly enough, there really isn’t any technology available that addresses this very real human communication challenge. No mater how counter intuitive it may seem, an effective Rugged DevOps environment is highly dependent on human-to-human relations.

3: Discard Detailed Security Road Maps in Favor of Incremental Improvements

The U.S. Office of Personnel Management (OPM), Sony, Hollywood Presbyterian, Anthem—each of these organizations experienced a security breach of massive scale. If these breaches all shared a word in common it would be PANIC—or at least headlines would have us believe this. The OPM breach was the ultimate example, wherein almost as soon as the alarm bell rang the government announced an elaborate plan followed by the big “Sprint.” Although, it might have been wiser just to beef up phishing defenses (smiley face).*

It turns out that a detailed long-term plan may not be the answer to data breaches, ransoms and system shut-downs.

DeMartine said outright that a comprehensive road map for addressing threats should be discarded in favor of a vision for real-time measurement and incremental improvements. Below is the “circle of life in security and DevOps,” as envisioned by DeMartine:

7: Test Preparedness with Security Games

Who doesn’t like competition? Not many. I think security folks and hackers are probably some of the most competitive people around; visit a Black Hat conference and watch as attendees intently capture flags, break out of handcuffs and hack signs.

With that in mind, it makes sense that this is one of the seven habits. There’s little doubt that simulations will do more to prepare people for real-life situations—after all, practice makes perfect.

Communication is a Rugged DevOps Essential Tool

Increasing trust between Dev, Sec and Ops mandates effective and, likely, improved communication. Perhaps one of the biggest takeaways is that, for all the technological bells and whistles the industry throws at combating cybercrime, in the end an age-old skill—communication—is at the foundation of the most-effective security.

*Phishing is assumed the most likely cause of the OPM breach; it is important to disclose that one of my clients, PhishMe, is a phishing defense solutions provider.

March 8, 2016
DevOps Connect at RSA: In Security, Choose Increments
Earlier this week the worlds of DevOps and information security collided at the DevOps Connect Rugged DevOps event, held in conjunction with RSA Conference 2016. The security-centric audience got to hear from a number of thought leaders across the DevOps and infosec worlds about ways security pros and DevOps teams can work together and establish incremental improvements in application security, as IT picks up the pace of software delivery.

Among the talks, Forrester Analyst Amy DeMartine discussed her team’s findings after studying the “best of the best” in implementing Rugged DevOps patterns. There are seven habits universal across organizations that are succeeding with this new way of developing and deploying secure applications, she notes.

“Think of it as a fitness program, and the muscles that you are building up are those that strengthen application security,” she says.

These habits included a number of obvious practices, along with a few surprises, including:
- Increase trust and transparency between Dev, Sec and Ops.
- Understand the probability and impact of specific risks.
- Use the continuous delivery pipeline to incrementally improve security practices.
- Standardize third-party software and then keep current.
- Govern with automated audit trails.
- Test preparedness with security games.
All are good tips for getting security, dev and ops to work better at delivering code both faster and more securely. But the seventh habit probably raised the most CISO eyebrows and could have the most potential to effect meaningful change and collaboration:
- Discard detailed security road maps in favor of incremental improvements.
According to her, the “best of the best” organizations in Rugged DevOps have security leaders that make it a habit to ditch detailed security road maps in favor of a establishing broad vision and achieving incremental security improvements over time.

As she related in her talk, she’s seen too many organizations develop extensive and extremely detailed multiyear road maps only to see them grow obsolete not only because of rapid changes in the IT environment, but also the constant pivots attackers make in their attack techniques.

Instead, she said, security leaders have to take the same continuous improvement approach that their peers in development and operations have made in their shift to DevOps.

“This is a mind shift change that has to happen,” she warns.

To achieve good results, security leaders should be focused on “real-time, actionable measurements” to focus on improvements that matter, such as decreasing remediation time for vulnerabilities.

“In DevOps, we call this Plan, Do, Check, Act, where you’re taking very small changes. Say you want to insert static analysis right after a developer checks in new code. So you’re going to go off and plan. The plan is to insert static analysis,” she says. “Then you’ll do—we’re going to look at tools, we’re going to create our rules. We’re going to check to make sure it works, if it improves things. And then we’re going to move on to the next thing—maybe it’s tightening our rules or maybe it’s adding another tool.”
March 3, 2016
How DevOps Prevents DDoS Attacks

Distributed denial of service (DDoS) attacks are some of the most pervasive and difficult attacks to prevent. The attack uses many distributed endpoints and/or systems to flood a web domain, application or service with excessive service requests or application calls. There are limits to the amount of bandwidth or the number of service requests or application calls that the associated web-based resource can handle at any given time, and when attackers using these requests or calls overwhelm these Internet resources, service is denied to genuine users who need legitimate access.

“These attacks are designed to either melt down your network or squash your applications and servers. Industry experts identify them as L3/L4 attacks and L7 attacks accordingly,” says Stephen Gates, principal SE and senior technical expert at NSFOCUS IB, a global provider of network security and advanced analytics. L3/L4 and L7 refer to three of the seven layers in the Open Systems Interconnect (OSI) reference model: L3/L4 refers to the network and transport layers, respectively, while L7 refers to the application layer.

These DDoS attacks are a big concern because they prevent users from accessing services and websites to conduct their business, which impacts user experience, employee productivity and a company’s bottom line. “The largest L3/L4 DDoS attacks on record exceeded 400Gbps in size,” says Gates. “Organizations all over the world regularly feel the effects of L7 attacks,” amounting to a lot of service disruption for a lot of businesses.

Handling DDoS Attacks with Rugged DevOps

Although Rugged DevOps can’t defend against L3/L4 attacks, it could help mitigate L7 attacks, Gates notes. Since L7 attacks are so common, a Rugged DevOps approach that fixes many—if not most—of them is an important tool can be an enterprise’s arsenal against DDoS. For it to work, Rugged DevOps must address the several types of vulnerabilities that appear in development of applications that make successful L7 DDoS attacks possible.

Most of the vulnerabilities susceptible to L7 DDoS attacks unfortunately permit unwanted user behavior in or in conjunction with applications that are accessible via the Internet. “For example, if a client machine continues to do the same thing over and over again (repetitive HTTP GET), this would be indicative of an unusual client behavior,” explains Gates. An HTTP GET is a request to the HTTP (web) server for data. Applications must apply methods for disregarding the several forms of unwanted behaviors.

Attackers can also send DDoS attacks against the application layer by using malformed packets to leverage weaknesses in ill-coded software. Packets are a means for encapsulating data into packages or units for transfer across packet-switched networks. “For example, if an attacker launched the ApacheKiller script against a vulnerable version of Apache, the application would completely fail to operate,” illustrates Gates. Applications frequently display these and other vulnerabilities to specially crafted attack packets.

How Rugged DevOps Can Help

Developers could avoid many of these kinds of application coding errors and vulnerabilities early in development by applying Rugged DevOps, which can catch and fix security holes early in the software life cycle. “Then they will likely not propagate into later versions of the application or the plugins riding on top of these applications,” says Gates.

Running penetration tests on software early in the development process is one way to thwart holes that enable L7 DDoS attacks. When coding missteps are uncovered early in the process, developers can fix them early, before they become part of the software. Tools such as Gauntlt, Mittn and BDD Security are examples of software testing tools that developers can use inside the DevOps shop.

Failed tests require a response. One such response is to automatically fail to build the software when the software fails the test(s). If development can’t move forward without fixing the security holes, the security holes will be fixed.

There are well-worn methods that developers can rely on to fix the most common, most threatening application security vulnerabilities. Developers should not have to do a lot of digging to uncover these methods. Many organizations and resources such as the Open Web Application Security Project (OWASP) clearly set these approaches apart and label each of them on their own distinct Web pages. This SQL Injection Prevention Cheat Sheet is only one example.

DDoS and other forms of attacks are, unfortunately, a part of life. Being able to mitigate an attack before it can occur is a goal. Rugged DevOps is one way to help make that goal a reality.

March 1, 2016