devopsy.kinsta.cloud

Tag: security

  • 5 Common Misconceptions of Serverless Technology

    5 Common Misconceptions of Serverless Technology

    The rapid growth in serverless technology affords companies opportunities to save money on server costs and allows developers to save time and focus on coding rather than back-end operations. A challenge with such swift adoption is the difficulty in maintaining a standard understanding. In anticipation of the Serverless Conference, which was held last week in Austin, Texas, we asked experts in Heavybit’s community about common misconceptions.

    Myth #1: Serverless is a Revolutionary New Direction for Software

    “A common misconception is that it’s a revolutionary new direction for software,” says Nick Martin, co-founder and CTO at Meteor. “Really, it’s just the next step in the evolution of making software development faster and easier. Like the compiler, the database and cloud computing did in previous eras, serverless further abstracts away the complexities of modern app development and is part of an ongoing trend to free developers from entire classes of concerns.”

    As for the benefits for developers, Martin notes that developers can now “focus on their application logic and avoid undifferentiated work like provisioning, server management, or load-balancing.” Serverless ultimately “promises to let developers ship apps faster and at a lower cost,” he says.

    Myth #2: Serverless is a Gadget Technology for Hobbyists

    Nick Gottlieb, head of Growth at Serverless Inc. believes that one of the biggest myths is that it’s a ‘gadget’ technology that’s not mature or only for a hobbyist. “While serverless compute is still a very early technology, it’s built on the same core infrastructure that providers like AWS, Google, and Microsoft have been investing in and selling to enterprises for years,” says Gottlieb. Furthermore, “because the underlying infrastructure is battle tested, and the value it provides around cost savings and faster time to market are so great, there is already huge amounts of mission-critical enterprise workloads being done on serverless compute.”

    Myth #3: Serverless Will Hurt the Movement Toward Containers

    “Containers will continue to be front and center in terms of the underlying infrastructure, but that doesn’t mean they will be the primary unit of deployment for developers,” says Lawrence Hecht, author at The New Stack. “Take, for example, a cloud provider that may build its FaaS (function as a service) on top of containers and use Kubernetes to manage that deployment,” he says. “Individual developers would then deploy application components to functions instead of to container images.”

    Hecht notes that this will not happen right away and in the meantime, “We’re seeing emerging companies build dashboards that allow developers to choose which VM, container or function they want to deploy to. Those dashboards are becoming the gateway to the CI/CD pipeline.”

    Myth #4: Serverless is Free of Security Vulnerabilities

    “The biggest security misconception is thinking you no longer need to worry about known vulnerabilities,” says Guy Podjarny, co-founder and CEO at Snyk. While serverless addresses the risk of known vulnerabilities in OS dependencies, such as OpenSSL’s Heartbleed vulnerabilities, “These ‘unpatched servers’ account for the vast majority of successful attacks today. Serverless applications still contain a large and growing number of application dependencies, pulled from npm, Maven, PyPI and more. These components often carry known vulnerabilities, and require diligent monitoring and preventative tools.”

    Myth #5: Serverless Means No More DevOps

    “A common misperception is that it completely absolves development teams from the harsh realities of operating software,” says Joe Ruscio, partner at Heavybit. “While it does promise to almost completely do away with the ‘undifferentiated heavy lifting’ of provisioning and managing infrastructure, understanding how your application code performs in production remains of paramount importance.”

    — Malia Powers

  • DevOps: Here’s How to Slack Securely

    DevOps: Here’s How to Slack Securely

    With 1.7 million daily active users, it’s clear Slack has come to dominate the team chat world, especially in the tech industry. This, however, means that a fair amount of security is required to ensure that strategic assets remain safe.

    From a security perspective, Slack has done a solid job of keeping its assets on lock, going so far as to score Geoff Belknap from Palantir in 2016 as its chief security officer. The company is also transparent about its approach to security and has dedicated a whole section of its website to it, including interviews with Belknap and others that delve into Slack’s precautions and philosophy around security.

    The company has also certified many of its products to meet strict compliance regulations including FINRA, HIPAA and SOC 2 and 3, which makes it a no-brainer for small teams and enterprises alike.

    So, it’s perfectly possible for companies of all shapes and sizes to lean on Slack for team chat and ops without worrying too much about security. However, no one’s perfect, and Slack’s ubiquity and popularity mean it will always be a target for cybercriminals looking to steal information—that’s basically the nature of being a cloud-based application.

    While, there’s no need to run scared, you do need to be smart about how you use this valuable tool. Here are a few tips for running Slack securely at your organization.

    Use Slack for SecOps

    Slack can be easily used for distributed security alerting, which means every member of your organization can play a role in keeping the business secure.

    Your security operations likely include members of the DevOps team as well as dedicated security folks, and Slack can help all team members integrate security into their workflows seamlessly. DevOps folks may not frequently log in to Threat Stack platform directly. However, any relevant alerts or notifications can be sent to them immediately via Slack, where they can be reviewed and the determination can be made whether further action is needed—all without having to step outside the daily workflow. This means security tasks don’t pose an extra headache, but are just a natural part of the way the company’s operations run.

    Require Two-Factor Authentication

    Slack’s built-in security precautions won’t do you much good unless you actually put them into practice. One great example is two-factor authentication (2FA). It’s up to team owners and admins to require this of their users (otherwise, it will be optional, and most users won’t bother). It is highly advisable you take advantage of this feature, which makes it much more difficult for hackers to tap into your organization’s Slack channels.

    Set Up User Provisioning and Deprovisioning

    Security-minded organizations need to be conscious of and work around insider threats. This also includes employees who have left the company, whether on their own terms or due to an incident.

    To ensure that you do not have any “lurkers” who might be able to take advantage of company information shared on Slack after they have left the company, it’s a good idea to plan ahead for user provisioning and deprovisioning.

    In fact, this should be built into your process for onboarding and offboarding employees, just like it would be for email or any other company asset. If possible, automate the process, so that the moment someone leaves the company, they no longer have access to Slack. To get started, here’s Slack’s guide to provisioning and deprovisioning users.

    Don’t Share Secrets

    Slack is a great place to have secure conversations, which unfortunately can lull some users into a false sense of complete security. “Secure” doesn’t mean you should treat it like it’s watertight; in other words, Slack should never be used to share secrets such as passwords, sensitive customer data or valuable corporate IP—basically, anything that could be considered highly confidential. A good rule of thumb is this: If a piece of information could be dangerous in a hacker’s hands, it doesn’t belong on Slack. Instead, it’s a good idea to use encrypted communication channels, like PGP-enabled email.

    Educate Users

    None of the tips above will do your organization any good if no one knows about them. So make sure that you regularly educate your users about steps they need to take to stay secure while using Slack (such as never sharing passwords there). You should hold user security training whenever new employees come on board, and also make sure to do a refresher now and again with the entire company.

    Additionally, if you change up security protocols around tools like Slack, make sure employees are given a heads up and reminded when new measures go into effect so they know what to expect. Remember: The best offense is a good defense.

    Don’t Slack on Security

    Slack is a great platform with all kinds of benefits for teams. As long as you take the right security precautions, there’s no reason why it can’t be used to its full potential on your team, whether you’re a small shop or a multinational enterprise. As with any other tool, the shared responsibility model is key. Take responsibility for your half of the security equation, and you should be well on your way to a secure Slack implementation.

    — Pete Cheslock

  • Security Implications for a DevOps Transformation

     

     

     

     

     

     

     

     

     

    SLIDES

    [slideshare id=75476834&doc=devopsandsecuritywebinarslides-170427175227]

    RECORDING

    [slideshare id=75476834&doc=devopsandsecuritywebinarslides-170427175227]

     

  • Veracode Makes DevSecOps Transition Easier for Developers

    Veracode Makes DevSecOps Transition Easier for Developers

    Following the formal acquisition of Veracode by CA Technologies, a much bigger effort to make security a more integrated element of DevOps has kicked off in earnest.

    Veracode recently unfurled an update to its application security platform aimed specifically at developers that provides security findings as each application module is scanned. Tim Jarrett, senior director of enterprise security strategy for Veracode, says the idea is to provide developers with that information from static analysis delivered via the Veracode platform as early in the application development lifecycle process as possible.

    Other new capabilities include support for custom cleansing functions to automate remediating issues involving common known vulnerabilities and an auto-scan capability that gets implemented any time a file is saved.

    Also with this release, Veracode is adding support for the Perl programming language that is still widely used for building web applications.

    Jarrett notes that organizations these days are holding developers more accountable for security issues that are easier to fix during the application development process. Addressing those same issues after an application is deployed in production not only exposes organizations to security threats, but can be much more expensive to fix.

    The challenge is that most organizations have yet to solve the riddle for getting developers to address security issues earlier in the application development cycle. Jarrett says far too many developers are conditioned to view IT security has being someone else’s job inside the organization. Veracode is trying to make it simple to address security issues using tools that make the process as frictionless as, say, relying on a spell checker to publish a higher-quality document.

    Obviously, there will never be perfect security. But far too many of the issues that IT security teams regularly deal with relate to known exploits. At a time when cybercriminals are making use of a variety of automated tools to discover those exploits, most IT security teams are outgunned. Worse yet, many IT organizations can’t even find qualified cybersecurity professionals to hire in the first place.

    On the plus side, however, as DevOps processes mature, many developers are now assuming complete responsibility for the maintenance of the code they write, including all security issues. This not only leads to higher-quality applications, it also results in those developers being more vigilant when it comes to address security issues they would otherwise need to address themselves once an application is deployed in production. In some quarters, this earlier focus on security in the application development and deployment process is referred to as DevSecOps. As a discipline within most IT organizations, however, DevSecOps remains relatively nascent.

    Of course, regulatory bodies are increasingly treating organizations that fall prey to security attacks less like victims. Instead, they are holding them accountable for ignoring best security practices by assessing fines for losing control over sensitive data. As those fines increase the blame for incurring those fines eventually cascades back to the developer. Given that changing climate, it might not be too long before developers recognize that embracing DevSecOps is in their own best interests.

    — Mike Vizard

  • From a Commodore 64 to DevSecOps

    From a Commodore 64 to DevSecOps

    We all know the story: a farm, a kid, a Commodore 64, and a modem maxing out at 300bps. A few unexpected phone bills later, and young Ian Allison is figuring out how to game the system so he can keep using his newfound gateway to the world of tech. According to Ian, that is where he began building the foundation of skills for his career in computer security.

    At the recent All Day DevOps conference, Ian (@iallison), now with Intuit, talked about his history of being “that” security guy. You know, the one who thinks developers don’t care about security or deadlines and, really, are just plain “stupid.” But, don’t worry, he is enlightened now and realizes that we all have the same goal: Everyone wants to build a secure system.

    Ian realized that “security doesn’t understand how developers or operations works. Security solves for security, but that leaves everyone else in their own place.” He started his enlightenment when his career path led him to a place called DevSecOps; that is, DevOps where security plays a more integral role.

    Ian pointed out that traditional InfoSec relies on compliance, regulations, appliances and perimeter (CRAP). He then realized the selfishness of his own and his peer’s perspective: Remediation is left up to the developers, the feedback they get are 200-page scanner reports, and it only solves problems for security and compliance. It doesn’t help developers reach their shared goal of a secure system.

    DevOps creates an opportunity for security to get a better view into our infrastructure, operations and development efforts.  DevOps is not only fast, lean and efficient, but when done right, it is also collaborative and empathetic. Couple speed with collaboration and empathy, and DevSecOps can blossom.

    Here is the reality that Ian was facing: Scanners find the absolute bare minimum; bad default configs are a HUGE problem even with SaaS vendors; manual testing can uncover defects that have been hiding for year; and the attackers are more skilled and motivated.

    How do you implement it and make it better?

    • Allow Dev teams to assume the risk of their decisions.
    • No more Security exceptions or signoffs.
    • Security is everyone’s responsibility.
    • Test the crap out of your own stuff like an attacker would.

    At Intuit, Ian wanted to help build stronger bridges between development, operations and security teams.  To do this, he set up a Red Team to:

    • Use same tactics as attackers.
    • Only scope is “Don’t take down production.”
    • Need to adapt and evolve like an attacker.
    • Prove risks actually exist.
    • Should be writing their own exploits.
    • Should have ongoing campaigns that mimic attackers.

    The Red Team started small and lean and focused on the cloud. It worked like an Agile DevOps team, working manually with the use of some tools. In the end, the team found, reported and fixed thousands of vulnerabilities not found by scanners.

    Ian goes into more details and lessons learned in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free-of-charge here.

    This blog series is reviewing sessions from the All Day DevOps conference from November which hosted more than 13,500 registered attendees. Last week I discussed, “System Hardening with Ansible.” Next week, look for my review of an awesome session by Erlend Oftedal:  “There is No Server: Immutable Infrastructure and Serverless Architecture.”

    — Derek E. Weeks

  • Threat Protection Appliances: As Valuable to Security as Your Toaster

    Threat Protection Appliances: As Valuable to Security as Your Toaster

    Nothing in the IT security community is as widely deployed and universally reviled as anti-virus. But, threat detection appliances, including intrusion prevention appliances, application firewalls and advanced threat protection appliances, should be almost as reviled. These appliances are nearly as useless as they are toxic. They do a horrible job finding problems and ultimately create more costs for security organizations than they save by crippling organizations with false alerts.

    Protection is Impractical

    In terms of security, detection appliances have never been effective, since the network makes a lousy location for any kind of security hub from the outset. Few network protection devices can even prevent attacks, much less respond to them, and most appliances are simply used for detection, even those with rudimentary prevention capabilities. In theory, an intrusion prevention device can drop a connection before letting the bad stuff through, but, in practice, that seldom happens.

    In most enterprises, security detection appliances are sitting off to the side, only capable of looking at a copy of network traffic as opposed to the actual network traffic itself. Organizations choose this less-than-ideal setup to avoid the inevitable network latency issues that otherwise occur when a single point of failure such as an appliance gets flooded or has a bug, for example.

    That’s not to say a network appliance can’t respond to an attack in progress in any way. If an appliance determines a particular network connection is malicious, and there is complete confidence in the appliance’s judgment, then an organization can have the device signal something that is in-line, such as a router or firewall. That device can then take action by killing the connection or blacklisting the offending IP address.

    The problem with that scenario is that often there isn’t enough context at the network layer. If a network appliance tries to make fast decisions, it’s going to produce an extraordinarily high number of false positives, making its judgment suspect.  Whenever there’s any doubt about an appliance’s judgment, it shouldn’t be trusted to make decisions whether to take action. Action in such circumstances could affect legitimate connections, which could have catastrophic consequences for the entire business.

    Appliances: What’s Really Happening  

    While old-school devices (e.g., traditional intrusion prevention devices) sacrificed accuracy for speed, today’s more sophisticated appliances do a better job of processing available data, which gives vastly superior results with far fewer false positives.

    The typical “next-gen” security detection appliance (such as an “advanced threat detection” appliance) tries to give as good an answer as possible about whether the connection represents an attack by simulating the end destination of the traffic to predict whether anything malicious will happen. This is done by running a copy of the traffic into a specialized virtual machine, and then monitoring the simulated outcome. If something malicious is found at the destination in the virtual machine, then there’s reasonably high confidence that the connection represents an attack. The goal of this approach is to limit false positives to the point where the organization can respond to every event. Some organization may even be willing to automate that response, by killing the connection if a suspected attack is detected in time, for example.

    While this class of a device tends to reduce noise, it doesn’t eliminate “false negatives,” which allow attacks to sail through without being noticed. In fact, some believe they make the false negatives problem of appliances even worse.

    If an attack works against an actual end user but not in the virtual environment, it could easily be overlooked by an appliance. Imagine a company buys an appliance and configures it to test network traffic by sending it to a virtual machine running Windows 10, but the traffic being tested only runs its proper course if running on Windows 9. In that case, if the network traffic’s destination is a user’s desktop that is running Windows 9, the attack can easily be successful, since the appliance won’t find the problem (because it’s running Windows 10).

    This class of problem was first discovered for network intrusion prevention by Ptacek and Newsham in 1998. While “next-gen” technologies are capable of more accurately modeling the systems they’re trying to protect, this problem will never go away when protecting from the network. Even when companies attempt to force all systems onto a single “gold” image, exceptions tend to quickly come out of the woodwork. For example, users within development and technical organizations often may find themselves in need of software that isn’t on the gold image, or they may need to run older software for testing purposes. Also, the gold image approach tends to only work for desktops.

    Making things worse, the “black hat” community can get their hands on the same appliances and reverse-engineer the virtualization technology and detection techniques it uses. Then, they figure out how to detect whether they’re running on such a device. Once they’ve done that, their real-life attacks will go unnoticed on the appliance, while still reaching the intended target.

    In the “advanced threat detection” appliance space, this problem is prevalent. A dirty secret of the appliance sector is that the majority of detections from these devices are discovered on machines that have already been infected, which are then beaconing out to external command-and-control infrastructure. If instead, these appliances had detected the actual inbound threat, the attack might have been prevented.

    Alert Fatigue: Poor Detection Quality  

    Drowning in alerts is perhaps the single biggest problem IT sSecurity organizations face. Even after all the raw data coming from around the network goes through a best-of-breed correlation and analysis engine, there is still an overflowing sea of information. These besieged engines generate so many alerts that organizations can’t possibly and cost effectively provide proper review for every priority alert they would like to investigate.  As it turns out, the vast majority of alerts are likely to be false positives anyway. Even the best talent can often and easily miss real incidents when pouring through so much superfluous data.

    Imagine the proverbial needle in the haystack, but multiply the number of haystacks so that the entire state of Kansas is covered in hay. Now you can begin imagine the scope of the problem. Sure, you might find an occasional needle or two—especially with some ingenuity. But, there’s virtually no chance that you could tractably look for them all even if you wanted to. That aside, your vigilance is likely to wane for at least a haystack or two, which is all it takes for one devastating needle to puncture your organization.

    Security appliances—particularly more traditional devices—represent the single biggest contributor to alert fatigue by far.  When you’re limiting your investigation to network traffic and trying to get work done as quickly as possible, you don’t have enough context to make good decisions. So, if you want to err on the side of caution, keep in mind that appliances will give you plenty of reason for caution, while uncovering few actual problems.

    If we are serious about eliminating the problem of alert fatigue, we must move beyond appliances and begin managing all of our detection at the machine-level. On a machine we can see what’s happening on the file system, what’s happening in memory, what’s happening in the OS and even what’s happening in the application (for common applications). That’s far more telemetric data to isolate signals and ignore noise (assuming we use all that data wisely).

    Many of the “next-gen” approaches live in a poor middle ground; they try to simulate the machine but generally can’t afford to create an accurate or effective simulation. If an organization is trying to protect a thousand servers, how many appliances would be needed to thoroughly simulate every inch of network and each bit of traffic that crosses? The answer is about a thousand appliances, which is far too cost-prohibitive. Most organizations prefer one appliance to protect hundreds or even thousands of machines, which is clearly insufficient.

    The Future: Will Be Worse

    The standards community is finally embracing the less is more philosophy as it prepares to launch TLS 1.3. This new protocol will ensure there aren’t straightforward back doors to subvert end-to-end encryption. Right now, most security appliances rely on those back doors as a means to provide detection (they need to be able to see the decrypted traffic). The new standard is going to require IT organizations have man-in-the-middle for every hop if they want their security appliances to work. That will add massive latency and expense, so most people won’t do it and appliances will become even less reliable as a result.

    Additionally, the rise of containerization and microservices will exacerbate the situation further, since putting container-to-container traffic on the same machine is well beyond the reach of any appliance.

    Security appliances may seem better than anti-virus, because they occasionally provide some value and don’t add as much attack surface. On the other hand, anti-virus software doesn’t drown organizations in an ocean of spurious reports. Besides, at least anti-virus now has credible alternatives, unlike an appliance. Security appliances are not worth the silicon they’re printed on and should be cursed in the same breath as anti-virus.

    About the Author / John Viega

    John Viega is CEO of Capsule8. Previously, he served as EVP of cloud security provider Silversky, where he led the technological advancement of the company’s cloud-based security suite. Following the successful acquisition of SilverSky by BAE Systems, John went on to serve as EVP of Product. Prior to SilverSky, John was SaaS CTO at McAfee. John is an award-winning author with a half dozen books to his name, including “Building Secure Software” and “Network Security with OpenSSL.”  He also co-designed the GCM encryption algorithm, which is nearly universally supported in the HTTPS and IPSec standards. Connect with him on LinkedIn and Twitter.

     

  • DevOps Security: Stop Discussing, Start Implementing

    DevOps Security: Stop Discussing, Start Implementing

    Is it Strong DevOps? DevOps Security? Secure DevOps? DevSecOps? DevSecQAMktSalesOMGBBQOps?

    Who cares?

    Like a ton of people with an interest in information security, I was appalled when I read “The Phoenix Project.” Here was a book that portrayed DevOps, why it was required, how it could help and the benefits very well. But it served security terribly. Worse than terribly. While it did accurately portray the predominant feelings of developers and Operations toward security, it utterly failed to adequately consider the correct usage of DevOps to attain InfoSec goals. Indeed, while it is a light treatment, it certainly comes across as, “Give up on InfoSec and you’ll be happier, healthier and more popular!”

    Clearly it was not a book written by information security staff.

    The Point Is …

    Don’t get me wrong, those who follow me know that I’m a developer that learned operations and has always found himself doing security bits, because no one else was, or because I was teamed with them (as an enterprise architect, our team was EA + Infosec, so we did a lot together). But that abiding interest in InfoSec has made it easy for me to see that the bulk of the problem between Security, Dev and Operations really is communication. An example might be in order.

    When SQL injection first hit the scene in a big way, it came with simple examples and was easy (for a developer) to understand the danger. Nearly immediately, developers had worked up solutions, were sharing them and tools were being developed to scan for injection weaknesses. Things moved very quickly, because developers understood the danger and agreed that it was a big deal.

    Meanwhile, using page data—hidden fields, hard-coded values (like from a list), etc.—pose the same level of risk. Copying the page, modifying those values and submitting the page—or using any of a dozen easy to use tools to mock up the data—makes them equivalent to user input, particularly in cases where they are used directly in queries. Yet even today, many many developers still use them without user-input error checking.

    Why? Because they don’t believe the risk is equivalent. For SQL injection, all a bad actor has to do is hit a vulnerable webpage and enter the right (and, I might add, well-documented) characters to open themselves to free querying of the database—at least one table, possibly much more. They see that as a much greater risk than someone having to modify HTML to get the right field to have the correct data and submit it.

    The fact that both attackers and tools are advanced enough to make the difference negligible doesn’t change the belief unless security convinces developers through education.

    ‘Faster’ has Challenges

    By the same token, both agile and DevOps move fast. They are designed to move fast. Security is more concerned with “protected” than fast, and is designed that way. Security staff (and this is the real source of a lot of burnout) hires on with “Protect Our Systems” as a job title, with the subnote, “But don’t get in the way.” This is a set of core principals that are at odds before the InfoSec person even sits down to interview. Agile and DevOps aggravate this tension, because, “Wait, there is a problem here, give us until tomorrow to get details,” now violates “but don’t get in the way.” “The developers in question have a stand-up coming and really short, really tight deadlines to meet. And InfoSec is interfering—again,” will likely be added to that statement by Dev. The same is true in Ops. Stopping an entire deployment because InfoSec is worried about security of private keys inside the private network violates the “but don’t get in the way” rule.

    But Solutions are Available

    So how can these tensions be brought together to resolve your problems? I’ve got some suggestions (they probably aren’t in the order you would expect, so I’ll explain as I go), but honestly  they are just a starting point. Entire books have been written on these topics, and more are about to be, if the state of the DevOps/InfoSec union is any indication. We can’t even agree what to call it, so we clearly aren’t agreed as to how to achieve it. Take these as what they are—suggestions—and start moving forward with what your org needs to be successful.

    1. Automate all of the things. Yep. Go download the various OWASP security tools, or your other favorite open-source tool, or call up your preferred vendor and get the automation of security checking—from source code analysis to penetration testing—going. Do those tools have weaknesses when compared to manual security evaluation? Most of them, yes. But here’s the thing. There is a quality staffing shortage in both InfoSec and DevOps. It is time to lean a little more on those tools, even contribute to make them better. Because the security checking they can do is better than nothing, and frankly is better than spending limited resources checking by hand. And that is why this step is first on my list. You need those resources. You need them to handle the rest of the steps. Once you have a tool like Jenkins auto-running these tools, and output review being just part of the job, then you can start to consider using those freed up resources more productively, or reporting that you’ve got more testing with DevOps than you had, whichever is true.
    2. Embrace and enhance education. Because of the rate of movement in an agile-plus-DevOps world, this must become a partnership with both Dev and Ops. Focus on helping developers and admins with the why as much as the how. People are more quick to adapt if they understand the reason for doing so. And for InfoSec to keep pace, they will need to adapt quickly.
    3. Look for ways to automate beyond implementing simple tools and reviewing results. The more repetitive work is built into the process, the more InfoSec is available to tackle bigger, less scriptable problem-solving. I’ve been talking a lot with CloudCoreo, for example, and its auditing tools can help InfoSec understand the state of cloud deployments with both alerting and reporting. Infrastructure monitoring tools make a lot of sense in a world of frequent infrastructure changes initiated by both auto-scaling and more frequent deployments.
    4. Shift automation of InfoSec to the DevOps team. Security is normally a relatively small function, and open positions can sit there or bring in people who need training in an organization’s tools and processes. So once automation is in place and reliable, shift responsibility to maintaining it (software updates, etc.) to the DevOps team, because it is a part of the DevOps process. Security can continue to monitor output and validate automated security testing results, but maintaining that piece of the DevOps infrastructure should not be InfoSec’s job.
    5. Rank what’s left that’s manual. Give each an importance. If there is potential impact to the business, ask business people to help you. Then assign work based on severity rankings. We do this stuff with risk management and threat assessment; this is no different, except you have to be willing to drop low-priority things—not to let them slide because you never get to them, but to publicly say, “This is a risk we are willing to take.” Let the team know that they’re not the only ones adapting.

    Will these basic starting steps solve all of InfoSec’s problems and make security never seem to “get in the way”? Of course not. Don’t aim for hanging around the campfire singing “Kumbayah”; aim for working as a team to turn out quality secure compliant code in a more predictable (and if you are an org that needs it, much faster) manner.

    A Rose by Any Other Name

    What, then, we should call it?

    Frankly, I suggest we call it DevOps. We’re not going to add every team that is subsumed into the DevOps umbrella into the name, so just call it DevOps and have a security piece in the process.

    Because it really doesn’t matter what you call it—it matters that it is compliant and protected.

    — Don Macvittie

  • The Leadership Suite DevOps and Business Alignment Success Guide

    The Leadership Suite DevOps and Business Alignment Success Guide

    There’s not much point to DevOps if the business isn’t directly benefiting through increased efficiency, productivity and, hopefully, profitability. This is possible only when IT and DevOps teams are delivering the technology the business actually needs to succeed and compete.

    As IBM director in IBM Cloud writes in his post, “Putting the ‘Biz’ in DevOps“: “The goal in any meaningful DevOps practice is to reduce the time and improve the efficiency in moving from the “Business Need” on the left to the “It’s Live!” on the right.”

    That alignment, while essential, isn’t easy to achieve. As I mentioned previously in my post, “The Big Digital Transformation Trends Through 2017,” the Deloitte 2016 – 2017 Global CIO Survey found that the expectations business has for IT are out of sync when it comes to what IT actually can deliver. The survey found this to be true when it comes to customer focus, technology-enabled business growth and innovation. For example, “even though 57 percent of the CIOs surveyed said that customers were their organization’s top business priority, less than half were involved in delivering customer experience (45 percent) or working on customer acquisition, retention and loyalty (44 percent),” that report found.

    That survey also found, startlingly, that while only 5 percent of organizations say that strategic alignment of IT activities with business strategy is a leading-class capability in their organization, 80 percent of organizations believe such alignment is critical to success.

    With this in mind, we’ve cultivated some of the best stories and other content on devopsy.kinsta.cloud when it comes to effective alignment of DevOps efforts and business strategy.

    The Big Digital Transformation Trends Through 2017

    Some of the most important trends in 2017 will include CIOs struggling to break out of the role of IT plumber and to better align the business with IT.

    How to Align Your DevOps and Cloud Initiatives – devopsy.kinsta.cloud

    One of the best ways to align with the business is to move software more swiftly with continuous delivery efforts. In this post, Michael Schmidt, head of the Automic DevOps Practice, details how to best manage IaaS, PaaS along with DevOps so that organizations can develop more quickly, and rapidly move to continuous delivery.

    The Conundrum of Adopting DevOps within Organizational Constraints

    In this post, devopsy.kinsta.cloud regular contributor JP Morgenthal explains that as with most changes within IT, with DevOps adoption, there is a need for bottom-up support as well as a top-down requirement that provides the coverage, financing, motivation and accountability to the business to enable change to occur.

    Putting the ‘Biz’ in DevOps

    Here, Rick Weaver, director IBM Cloud, explains how by adopting the right business-oriented metrics will help expand DevOps capabilities into a broader, more meaningful “BizDevOps” practices.

    Enterprise DevOps: Organizational Change a Must

    In this article, Sanjeev Sharma, IBM Worldwide lead, details the principles necessary to foster application delivery team alignment from a people and team perspective—something that is essential if teams are to successfully align with DevOps.

    It’s Time to Couple Security, Business Leadership

    In this post, yours truly reviews the importance of aligning security and business leadership, and if organizations conducted themselves that way, there’d be a much smaller gap between security teams and their organization’s board of directors when it came to cybersecurity expectations and reality.

    — George V. Hulme

  • DevOps Connect: DevSecOps Edition Complete Session Videos

    DevOps Connect: DevSecOps Edition Complete Session Videos

    [nextpage title=”Introduction” ]

    The third annual “DevOps Connect: DevSecOps” held at RSA Conference 2017 shows just how far DevOps has matured in recent years from IT subculture to mainstream practice. In the presentations in this slide show, you’ll see firsthand accounts where enterprises have transformed legacy methodologies to DevOps practices, building more healthy cultures and, of course, more secure software.

    [/nextpage]

     

     

     

     

    [nextpage title=”Breaking Bad Equilibrium” ]

    Breaking Bad Equilibrium

    John Willis

    In DevOps we try to identify and fix bad equilibrium. We constantly look for discontinuity in the areas of technical debt, collaboration, risk and work-life balance. In this presentation, John Willis looks at some other successful fields that address equilibrium and discontinuity in their respective fields. Willis looks at areas of behavior economics, cognitive psychology and game theory. He also has some fun with a few pop culture books, movies and game shows as examples of bad and/or Nash equilibrium.

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”A Tale of Two Stories” ]

     

     

    Building Security In: A Tale of Two Stories

    Laksh Raghavan

    The holy grail for software security professionals is to make their development teams treat functional and non-functional requirements as equal citizens. This becomes even more challenging in “agile.” Wouldn’t it be great if you had a quick and easy means by which you can write pertinent and actionable “security stories” and place them into the backlog of all your scrum teams so that they can get prioritized and completed along with “user stories”? The challenge, however, is making this scalable and seamless in a large enterprise with diverse sets of frameworks, application stacks and programming languages. In this talk, Raghavan shares tales from the trenches of implementing such a system—what worked, what proved challenging and the associated outcomes.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”2016 State of DevOps Report” ]

     

     

    DevOps and Security: What We’ve Learned from the 2016 State of DevOps Report

    Dr. Nicole Forsgren & Jez Humble

    Four years and more than 20,000 survey respondents later, Forsgren and Humble have learned a lot about what makes IT and organizational performance awesome. They also have learned some things about the role that security plays in technology transformations. Their latest research includes insights into trunk-based development, lean product management and employee engagement. Watch this talk for practical takeaways that will  make your teams and technology transformations even better.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Bits and Bytes” ]

     

    Where Bits and Bytes Meet Flesh and Blood: DevOps, Cybersecurity and IoT

    Joshua Corman

    We’ve heard software is eating the world. Corman says software is infecting the world. Our dependence on connected technology is growing faster than our ability to secure it—in areas affecting public safety and human life. Adding millions of lines of code and connecting everything to everything else exposes cyber-physical systems to new accidents and adversaries, Corman contends in this talk. This is truly where bits and bytes meet flesh and blood.

    Despite best practices, modern software development and security have allowed 100 of the Fortune 100 to lose intellectual property and sensitive information—even our governments routinely succumb to adversaries. These failure rates cannot stand with the consequences of failure being measured—not in record count—but in human lives and GDP. Paradoxically, Corman says, it may take DevOps to rise to these challenges. Rugged DevOps is finding un-obvious common ground and breakthroughs like software supply chain principles, greater visibility and response agility, and immutable infrastructure. Corman says we must be better, and provides his view of what better looks like.

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”Release engineering” ]

     

    The Intersection of Release Engineering and Rugged DevOps

    Paul Reed

    At RSAC 2016, release engineering’s role in rugged DevOps was discussed with a focus on how it relates to software delivery supply chains and the increasingly critically important topic of security and security management.

    This year, J. Paul Reed explores what we’ve learned in the past year about the intersection of release engineering and rugged DevOps.

    He takes take a deeper dive into specific release engineering techniques and tools that can not only start you on the path to effectively managing your software supply chain, but also pay concrete dividends in making your software’s security posture better and help you remediate issues more quickly when a security issues arises.

    He also explores some nascent trends on the frontier of software delivery and security management, including the role of human factors and systems safety in the broader context of fast, sustainable and, yes, secure delivery of increasingly critical software components in our society.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Next Gen Security” ]

     

    Next Gen Security Needs You!

    Shannon Lietz

    Next-generation software deserves security from the start and better collaboration to effectively reduce the real risks posed by attackers. Some might say this is heresy, but given the endless trend of security breaches from traditional methods, likely not. The ideal state of security has always been to achieve continuous improvement or level 5 maturity. By this very intention, security has always been a significant factor in the production of software but relatively difficult to commoditize because of its complexity.

    Using DevSecOps methods and principles, simplicity and high-fidelity controls are emerging within the software industry to help organizations forecast and react faster to attackers. Lietz’s talk provides an essential road map for security practitioners to tackle how to bring DevSecOps to their organization and avoid common pitfalls that have come from early day lessons.

    You can see this presentation here.

     

     

    [/nextpage]

    [nextpage title=”DevOps in a Regulated Environment” ]

     

     

    Implementing DevOps in a Regulated Environment: The Aetna Experience

    Duane Schleen

    One of the big challenges organizations are facing is how to introduce DevOps principles to regulated industries. Industries such as health care or financial services must adhere to stringent security and governance controls, which often make it difficult to adopt new technology stacks such as DevOps and containerization. If you have adopted an agile approach to software development and have plans for moving to DevOps, microservices and containerization, what processes do you follow to avoid compliance missteps? This talk shares Aetna’s journey of modernizing its application stacks and infrastructure.

    Schleen covers which considerations went into the design and selection of the DevOps methodologies, which applications were moved to microservices and containerization first and what was observed as a result. Schleen also covers how security departments can help the business understand the advantages of DevOps and containers—removing fear rather than adding fear. Finally, Schleen details the experience of architecting security across a rapidly changing application environment, and how continuous integration and continuous monitoring can go hand in hand in delivering application agility, but also security vigilance and competency.

     

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”Ops Happens” ]

     

     

    Ops Happens: DevOps After Deployment

    Damon Edwards

    Listen to enough DevOps conference talks and it all starts to sound like: “deployment, deployment, deployment.” But what happens after deployment? What does DevOps mean for other traditional enterprise operations activities such as incident response, problem management and compliance?

    Damon Edwards tackles these questions in this session. Here, Edwards examines what happens when the “go fast” ethos of DevOps inspired delivery teams meets the “be stable, be secure, be compliant” mandate of traditional enterprise operations organizations.

    Damon also identifies DevOps-inspired principles and practices being leveraged by high-performing enterprises who are currently transforming their operations organizations.

     

    You can see this presentation here.

     

    [/nextpage]

     

    [nextpage title=”Requirements Gathering” ]

     

     

    Requirements Gathering for a Successful Rugged DevOps Implementation

    Hasan Yasar

    It is a must to include secure coding practices in application development life cycles to produce rugged software. Yet, each organization’s development pipeline and application is different compared to others. It is also necessary to have preparation prior to having a successful implementation of rugged DevOps. This includes organizational culture, security policy, development platform, application technical stack, operational team involvement and foremost secure coding practices. The questions are: how to assess, what to find as bottleneck, train whom on what, what to measure and, finally, how to monitor. Then, build up your customized integrated DevOps platform where you can build a rugged application along with other quality attributes such as compliances, secure testing, performance monitoring.

    The burgeoning concepts of DevOps include a number of concepts that can be applied to increasing the security of developed applications. These include adding risk-based architectural design, automated security testing techniques such as fuzz testing, software penetration testing to the software development cycle or the continuous integration cycle. Applying these and other DevOps principles can have a big impact on creating an environment that is resilient and secure. In this session, Yasar explains how his company figured the right requirements and then how you can utilize this in your own organization for Rugged DevOps.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Getting Security Up to Speed” ]

     

    Getting Security Up to Speed

    Oleg Gryb

    So, you’ve adopted agile software development life cycle and your DevOps team runs continuous integration/continuous deployment. But what about security? If you haven’t figured out yet how to speed up your security processes , it can easily become a bottleneck and slow down the whole software development process. Gryb shows how to avoid this.

    Gryb discusses how to replace old security processes with the new processes, and how to add more security automation tools that utilize existing quality assurance test cases.

    You can see this presentation here.

    [/nextpage]

    [nextpage title=”Scaling Rugged DevOps” ]

     

     

    Scaling Rugged DevOps to Thousands of Applications 

    Tim Chase, Aaron Rinehart, Jeff Williams

    Most of the talks on rugged DevOps are trivial. Write a script to hook up your scanner to Jenkins, and your WAF to your SIEM, feed the results to developers via JIRA, and claim victory. If you have multiple tools, maybe push the results into ThreadFix. But very quickly your cup will runneth over with vulnerability reports that need to be manually triaged. If you try to scale, you’ll need a dump truck and an army. If you want to really scale rugged DevOps, you need to get the humans out of the critical path.

    In this talk, this trio explores how large enterprises handle this challenge by instrumenting their application portfolio, assessing and protecting applications in parallel and integrations enabling instant notification directly to stakeholders. The result is continuous protection during both development and operations.

     

    You can see this presentation here.

     

    [/nextpage]

    [nextpage title=”Other articles” ]

    Other devopsy.kinsta.cloud Articles you might like:

    Security @ the Speed of DevOps Survey: Efforts Still Lag

    The Elusive Definition of DevOps

    DevOps in 2017: From Building to Executing

    [/nextpage]

    — George V. Hulme

  • All Day DevOps: System Hardening with Ansible

    All Day DevOps: System Hardening with Ansible

    The DevOps pipeline is constantly changing.  Therefore, relevant security controls must be applied contextually.

    We want to be secure, but I think all of us would rather spend our time developing and deploying software. Keeping up with server updates and all of the other security tasks is like cleaning your home: you know it has to be done, but you really just want to enjoy your clean home. The good news is you can hire a “service” to keep your application security up to date, giving you more time to develop.

    At the recent All Day DevOps conference, Akash Mahajan (@makash), a founder/director at Appsecco, discussed hardening your system’s security with Ansible. In addition to his role at Appsecco, Akash is involved as a local leader with the Open Web Application Security Project (OWASP).

    Misconfiguration

    During his presentation, Akash mentioned the OWASP Top 10 Security Vulnerabilities list, zeroing in on No. 5: Security Misconfiguration. To determine if you comply with the guidelines, No. 5 on the list asks:

    • Is any of your software out of date?
    • Are there any unnecessary features enabled/installed including ports, services, accounts, pages or privileges?
    • Are default accounts and their passwords enabled/unchanged?
    • Are security settings and libraries not set to secure values?

    I am sure no one reading this article still uses the default administrator password, but can we say the same of your peers? Have you gotten around to installing the latest software patches on your server?

     

    Automation

    If a task can be automated, developers automate it. So we should automate our security tasks too, where we can. OWASP provides guidance here, suggesting you should:

    • Have a repeatable security hardening process.
    • Ensure your development, QA and production servers are configured identically but with different passwords.
    • Automate the process to minimize the effort required to setup a new secure environment.
    • Implement a process for deploying all new software updates and patches in a timely manner to each deployed environment.
    • Run scans and audits periodically to help detect future misconfigurations or missing patches.

    This is all part of security hardening, which is, “the process where we identify default configuration present on a system and apply changes that will change the configuration to secure values.” This can be applied to your network, transport, application, and kernel networking parameters.

    Ansible Playbooks

    Ansible is one of the solutions Akash likes to work with, but there are others solutions on the market that provide similar value. Without trying to endorse or evaluate one solution over another, let me share perspectives from Akash’s experience with his toolset.

    Why does he like it? It boils down to playbooks. An Ansible playbook is a codified security document, allowing you to describe the desired state of a system, rather than the specific steps of how to get to that state. As Akash points out, things change—it is better to have the end state described rather than have to change commands when the system changes.

    Other advantages of playbooks include:

    • Playbooks are written in YAML providing us with structure that we can learn and train on
    • Playbooks are text files, so we can use Git for version control
    • Managing playbooks is just like managing any software project
    • Playbooks are infrastructure as code but for security
    • Playbooks consist of roles, a key aspect of security
    • Numerous playbooks are available as open source

    The bottom line is you can—and you should—automate your security hardening process. Your users and other stakeholders will thank you and, most of all, you will thank yourself because you can spend more time on the things you love to do.

    Ansible is just one example of a solution that can be used to automate your security tasks. If you want to know more, Akash goes into further detail on getting started with Ansible in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free of charge here.

    This blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “DevOps at Massive Scale.” Next week, look for “Operationalizing a Red Team for Fun and Profit,” delivered by Intuit’s own Ian Allison.

    — Derek E. Weeks