devopsy.kinsta.cloud

Tag: secops

  • How to un-domesticate your network: DevOps!

    How to un-domesticate your network: DevOps!

    When I look at how compliance and regulations have affected network security over the years, I’m reminded of what dog breeder standards and regulations have done to dogs over the years. I’ll use this analogy to make the case that networks have become too domesticated to the point that they are not able to adapt and thrive when faced with their natural predators on the Internet. DevOps in my opinion is a way to undomesticate your network so that processes and technologies can deal with the threat in the most natural manner, striking the balance portrayed in complex ecosystems.

    cute2

    This entire thought process began when I was hanging out with my buddy Hugo. He is my one-year-old French Bulldog. We hang out a lot, and there are times when I think he telepathically helps me solve hard technical problems (but that is off topic). Anyway, if you know anything about French Bulldogs, you know they are mutants. They have been bred to the point where their breathing is compromised and they can overheat and die when it is too hot. They have common back and spinal diseases, and I can go on and on, but they essentially need humans at this point to keep them alive. I have to put a life vest on poor Hugo if we are near water because, while all dogs can swim, his head is so heavy that after a short while he will drown. Nonetheless, he is my sidekick in many ways, and we both lack vital characteristics of our ancestors who thrived in much more hostile environments.

    While I can go on and on talking about my buddy Hugo, the point I’m trying to make is that while standards like PCI help to raise the bar regarding online security measures, I have to stop and ask: security measures against whom? The level of innovation, change and adaptation that is taking place on the threat side of the equation is out pacing the rate at which security standards can be institutionalized and implemented. So your network may be cute and cuddly like my Hugo, and maybe even win a ribbon or two, but it would also not survive when faced with an advanced threat.

    When we trace the domesticated dog back tens of thousands of years, we arrive at the grey wolf. They traveled in packs, they faced threats on a daily basis, they thrived and adapted in a very hostile environment. DevOps takes us back to the time when the wolf finds its strength in the pack, and the pack finds it strength in the wolf when faced with conflict. Survival is very real and practical; there is no level of certification, checklists or deterministic process that must be followed. It is a delicate dance between attacker and defender, and like it or not, we are headed back in that direction.

    DevOps brings us the opportunity to constantly represent the changing threat in our everyday lives – such is the case with anything connected to the Internet. It is back to the wild, back to the days where a loss at the organism level meant evolution and resiliency at the species level. Our goals change from securing our networks to evolving our networks as this tempo of change raises the costs to the adversary. DevOps makes your network more expensive to attack!

  • DevOps: The Last Great Hope for Application Security?

    DevOps: The Last Great Hope for Application Security?

    Once upon a time, there was a great battle between speed and security.  Development wanted to go fast.  But, Security wanted to slow down and be safe.

    “We must protect our gilded apps”, cried the application security team.

    “Speed is cherished by our people”, declared the development team.

    For years, they endured the pain of testing late in the lifecycle, sorting through reams of false positive reports, and dealing with the added cost of pushing bad software out the door.  They knew there had to be a better way…

    And then came, The DevOps Revolution.  The DevOps team had an answer.  “Let’s bring Application Security and Development closer together — and shift its focus further to the left”.  The DevOps team knew that by introducing awareness of security vulnerabilities and policies early in and across the software development lifecycle — without creating a time-consuming tax on development — that both teams could win.

    During an evening event named “Wining Not Whining” at the RSA Conference 2014, we gathered some of the top DevOps experts and influencers and asked them “Why is application security so important to the DevOps revolution?”

    Listen to what they had to say:

  • Hacking Your Auditor

    Hacking Your Auditor

    No, not that kind of hacking, give me a little credit…

    Recently I was having a conversation with a consulting friend about DevOps, and he found himself in a bit of a tough situation. The organization he was working with was a pure cloud/DevOps shop, but one that was stepping into having the meet compliance obligations. Needless to say, things weren’t going well with the auditor.

    For those of you who haven’t had to deal with the miasma of audits, one of the strongest requirements, for nearly any regulation/contract/agreement, is strong change management. This is especially true after those Enron guys screwed everything up for the rest of us.

    Change management makes a ton of sense from both an operational and compliance standpoint. I, myself, have blown things up in production but not being smart about my change management. For compliance, it is absolutely essential. If you are dealing with anything with financial or privacy implications, you sure as heck want to get it into a stable, secure, compliant state and ensure that state is kept over time.

    There is a big misconception out there that DevOps-style organizations don’t have change management. That when you push multiple changes per developer per day into production, there is no accountability or control. Now, while you can certainly build things this way, that sure isn’t how I see successful teams doing it. Not even close.

    The problem isn’t that DevOps necessarily skips change management, it’s that it looks different. Much of change management becomes automated, and the fundamental nature of changes themselves is different. But think about how you describe DevOps to your traditional IT-focused friends. Now imagine trying to explain this to an auditor working off set standards that are still figuring out if cloud includes a co-hosted Mac Mini duct taped to a rack.

    Here are some tips on how to both adjust your process, and explain it to the auditors:

    • First, figure out which pieces of your application and operations are in-scope for the regulation. Odds are only financial and privacy related bits are, and you can then apply more-granular controls or logging to these if you need.
    • Make sure your continuous integration tool (if you have one) includes some security checks and logs all updates/changes. If you push right from your code repository to production, get a CI tool.
    • Keep records of all changes as they flow from dev to test to prod (or whatever you use). Again, this should be trivial to automate and dump the records to a secure log repository someplace.
    • Unless your cloud provider tracks all API calls (like CloudTrail does on AWS, although that only works for some services and regions) use an API or web UI proxy like Netflix’s Asgaard. This really is a good security practice anyway, and can actually speed up infrastructure and platform management processes anyway. Keep the logs from this to make the auditor happy.
    • If you SSH into instances, you need to log that activity and dump the logs to a central repository.
    • Make sure you keep revisions of both all code changes and infrastructure automation changes (e.g. your CloudFormation templates, Chef/Puppet scripts/etc.). This is often built-in, but make sure you configure it correctly.
    • Those suggestions now give you logs of all application changes, infrastructure changes, and direct access to instances. These are the things the auditor wants to know exist.
    • Filter them based on your in-scope compliance requirements. Such as payment systems components only.
    • Explain to your auditor that all changes go through an automated approval system that checks the code, tests it (detail the tests), tracks the change, and then moves it into production. That all server logins and infrastructure changes are logged, as is the complete history of the structure of your entire environment. And that you can provide all the documentation, filtered for the pieces within compliance scope.

    This might look like a lot, but odds are very high you are already doing most of this. You keep code revisions, run changes through test suites before they go into production, and track all infrastructure changes. You might not have your own Ops portal/proxy, but you really should for a lot of reasons that have nothing to do with compliance.

    The trick is explaining this to your auditor in their terms. They expect manual checks and records. You need to show them that you still have these checks and balances, but they are automated. You still might need to add some pieces, such as an alert if certain parts of your code are changed (e.g. the file with payment processing or account reconciliation), but these will hopefully be minimal.

    A good DevOps environment actually has a much better compliance infrastructure in place than traditional infrastructure. The automation and template-driven models give us much better control and insight as compared to manually fixing everything, even when we push more day to day changes. The trick is to document this, add a couple pieces if you need it, and then explain it all to someone with… less than refined technical skills.

     

     

  • Busting The 4 Biggest DevOps Security Myths

    Busting The 4 Biggest DevOps Security Myths

    Last month when the IT security world convened in San Francisco for the annual RSA confab, a number of security experts tackled DevOps in talks that covered the crossover between continuous improvement and risk management. Among them was a lively panel mythbusting some of the most prevalent misconceptions about DevOps held by the security community.

    Moderated by Dwayne Melancon of Tripwire, the panel was made up of Josh Corman, CTO of Sonatype, Nick Galbreath, vice president of engineering at IPONWEB, Gene Kim, author of The Phoenix Project, and David Mortman chief security architect and distinguished engineer for Dell Enstratius, all of them security professionals and very active DevOps evangelists. The banter backed-and-forthed between the participants, with four myths bubbling to the surface as particular highlights from the discussion.

    Myth #1: DevOps Pace Will Leave Security In The Dust

    One of the most prevalent myths about DevOps within the security community is that the rapid deploys of the approach will throw all risk management precautions to the wind and leave security practices behind as a result. Quite the contrary, panelists argued. They believe that DevOps patterns make it more possible than ever to bake security practices into IT processes more than before, when it is frequently bolted on “at the end of the caboose,” as Galbreath puts it.

    “You’re not throwing out your current security system,” he said. “What you’re doing is removing a lot of the junk work that eats up so much time and keeps people underwater. You’re really enabling different teams to all improve security together.”

    As Corman explained, security people say all the time that complexity is the enemy of security.

    “It also happens to be the enemy of stability,” he said. “That is the reason DevOps people come willingly with open arms to the security community.”

    Not to mention, Kim added, “because you can’t be highly available and have stuff coming continuously through the pipeline if it is not secure.

    Myth #2: DevOps Destroys Compliance And Control Frameworks

    This myth came up during the audience Q&A portion of the panel, where one audience member from the financial industry wondered at how possible it would be to institute DevOps in a highly regulated industry. According to Mortman, as seemingly chaotic and fast-and-furious as the DevOps pace can seem to the uninitiated, it is actually far more process-oriented than people realize.

    “People say ‘Oh, there’s no process to this.’ But it is actually very process oriented,” he said. “It’s just not very bureaucracy-oriented. There’s not a lot of paperwork. In its very guts, it is very service-oriented and very delivery-oriented.”

    As he puts it, every compliance framework in the planet says you need to log, audit and approve changes. But none of them stipulate a workflow where each change has to be approved one at a time.

    “The workflow can be ‘Please approve the following list of actions that I can do without notifying you first,’” he explained, “and as long as you have an audit trail showing that that has been done properly, I have yet to meet an auditor who will not buy into that.”

    Myth #3: DevOps Gives Developers Too Much Power

    Many dyed-in-the-wool security pros fear DevOps because they believe it is a cowboy environment that gives developers too much power.

    “I’ll be honest, when i first started observing DevOps patterns, developers doing their own deploys seemed immoral to me; irresponsible, reckless, just shouldn’t be done,” Kim said. “No sane person would want to be associated with that, right?”

    The thing was, after Kim dove in and also did a benchmark study with Tripwire several years ago across 4,000 organizations, he found that when comparing groups where ops did the deploys to those where developers shepherded code through deploys, change success rates and mean time to repair were not adversely affected, and in fact, “it is often considered indispensible that developers take code all the way through the deployment pipeline and you know they are getting great outcomes.”

    And from a security controls perspective, the truth is that in a DevOps situation developers “are not logging individually into each server and SSH’ing the code up, untarring it and installing it,” Mortman said. Instead these actions are being done by automated systems.

    “They’re actually going to give you much better timestamps, much more accuracy, and more consistent results and visibility than a manual process being done by someone in ops,” Mortman said. “So, actually, you’re getting better change management out of that system than you are in other situations.”

    Myth #4: DevOps Cuts Important Testing

    One discussion point also brought up during audience Q&A was the possibility that DevOps would somehow excise important testing functionality from the IT process. The panel quickly put that one to bed.

    “You can do bad testing in any model,” Corman said. “If DevOps starts eliminating any kind of testing, its a bad DevOps program. I think that’s orthogonal to some of the benefits or opportunities of DevOps.”

    Kim pointed to Google as an example of how testing fits into the DevOps methodology.

    “So, Google does about 5,500 code commits per day, they have about 15,000 software engineers, and 75 million hours of testing is run each day,” he said. “You can’t get that massive amount of deployment frequencies without a tremendous amount of testing.”

  • What is Security Policy Orchestration and Why Should DevOps Teams Care?

    What is Security Policy Orchestration and Why Should DevOps Teams Care?

    After attending the DevOps day I wrote about in my last post, I wanted to take a minute to explain exactly what Security Policy Orchestration actually is so we can begin to understand how the two concepts overlap.

    Simply put, Security Policy Orchestration is intelligent network change automation. It goes beyond simple task automation by truly understanding the network through simulation and analytics. It also gives security people an extra level of governance and control, which is so critical to assure security and business continuity.

    Security Policy Orchestration reflects the growing relevance that managed security policies are having on IT systems.   In network security lingo, security policies are firewall policies, but can also apply to Access Control Lists (ACLs), router and load balancer configurations.  Managing security policies is an arduous task that requires automation, and Security Policy Orchestration has emerged in response to numerous factors happening in tandem – mainly, that:

    • Business agility is gaining importance as a key competitive factor. This is creating an increased demand for automation across IT and, specifically at the network layer.
    • IT organizations are pressured to match the speed, convenience and self-service provisioning the cloud environment offers for internal application deployment.
    • Enterprise networks are growing larger and more complex with numerous traffic routing and shaping technologies to service multiple data centers.
    • The widespread use of stateful and next-gen firewalls for external and internal network segmentation has significantly increased the size of the enterprise firewall estate, forcing security policies to morph into complex rule sets that map how business is conducted over the network.

    The collective impact of these developments on network and security operations tasks is having a profound impact on people, processes and technology, including DevOps groups, who like their Security Operations (SecOps) brethren, are under pressure to roll out services faster.

    Security Policy Orchestration helps to alleviate that pressure, enabling SecOps teams to keep up with the demands of the business while ensuring security and preventing an outage or a breach.  Being able to automatically generate, provision and synchronize Security Policy changes across a growing set of systems – with security, compliance and governance concerns accounted for – means that security will not become a bottleneck that slows down DevOps teams.

    While Security Policy Orchestration evolved out of network security operations, its benefits transcend security.  Even though it will remain a SecOps function, its impact on DevOps is only going to increase, especially as Network and Security Operations continue to converge.  However, the fundamental enabler of Security Policy Orchestration is automation.

    As a result, there is significant common ground between DevOps and SecOps when it comes to automating application connectivity. This may not have been an issue for you yet, but my introduction to DevOps came from my experiences helping Tufin customers automate application connectivity.  It’s a subject that is extremely germane to DevOps teams, and a topic that I plan to explore in depth in this blog because those of us leading the Orchestration charge within SecOps are kindred spirits with DevOps evangelists.  

    Contrary to popular belief, Security Policy Orchestration wasn’t created to restrict a company but to free it and help DevOps teams to accomplish its vision at the lowest IT risk level possible.  After all, there is no such thing as bulletproof security where the Internet is concerned.

    Instead, security folks focus on reducing risk, which puts us in a much better position to add value to the business.  Plus,  since so many of today’s biggest threats (i.e. APTs, for example) are network-based, introducing the tenets of Security Policy Orchestration  – which literally automates best security practices into change processes – is in the mutual best interest of both SecOps and DevOps teams. 

    In my next post, I plan to dig into more detail on the stakes Security, Dev and Ops all share to make IT work faster, better and safer, and propose a few ways in which SecOps and DevOps teams can collaborate to gain some quick wins.

  • Tufin Partners with Puppet Labs to Automate and Orchestrate Security Policies for Host-Based Firewalls

    Joint Customers Can Now Increase IT Agility and Improve Security Through Central, Automated Management of iptables Firewalls

    Published: Tuesday, Feb. 25, 2014 – 5:08 am

    MORRISTOWN, N.J., Feb. 25, 2014 — /PRNewswire/ — Tufin Technologies, the market leading provider of Security Policy Orchestration solutions, today announced an integration that enables Tufin customers to leverage the IT automation capabilities of Puppet Enterprise, Puppet Labs’flagship commercial product, to configure and provision security policy changes to iptables, a host-based firewall commonly found on physical and virtual Linux servers. The ability to automate and orchestrate iptables policy changes improves collaboration and information sharing across server, application and security operations teams and ensures that network connectivity changes for iptables-protected servers are implemented securely, accurately, and at the pace of business. Concurrently, Tufin is also announcing new security, automation and orchestration capabilities as well as the results of a recent survey that underscores the need for automation to effectively manage change in today’s highly complex, dynamic and distributed network environments.

    “This integration enables our customers to leverage Puppet Enterprise’s automation prowess to automate application connectivity in both on-premise and previously uncontrolled environments such as cloud deployments and virtualized environments,” said Reuven Harrison, CTO, at Tufin. “This is incredibly useful to our customers and ensures that security is woven into the server’s connectivity requirements. As the convergence of security and network operations continues, this module enables our customers to manage change with automation that delivers tangible business value.”

    The Tufin Orchestration Suite™ enables organizations to increase automation and accelerate the pace of network infrastructure changes while maintaining security and compliance. Puppet Enterprise provides system administrators the operational agility, efficiency and insight they need to proactively manage a dynamic infrastructure, scaling from tens of servers to thousands on-premise and in the cloud.

    “This integration gives joint customers the ability to provision changes to iptables security policies,” said Nigel Kersten, CIO at Puppet Labs. “We expect Security Policy Orchestration to become a core requirement for our customers, and integrating with Tufin enables our customers to quickly and effectively address connectivity requirements across the enterprise without compromising security.”

    About Puppet Labs Puppet Labs, Inc. is the leader in IT automation. Puppet Labs’ software provides system administrators the operational agility, efficiency and insight they need to proactively manage dynamic infrastructure, scaling from tens of servers to thousands, on-premise and in the cloud. Thousands of the world’s leading organizations use Puppet Labs’ software to configure and manage their IT infrastructure, including Citrix, eBay, NYSE, Cisco WebEx, Salesforce, Bank of America and PayPal. Based in Portland, Oregon, Puppet Labs employs more than 250 people. The company is backed by investors Kleiner Perkins Caufield & Byers, Google Ventures, VMware, Cisco, True Ventures, Radar Partners, and Emerson Street Partners. To learn more, please visit www.puppetlabs.com.

    Puppet Labs and Puppet are trademarks of Puppet Labs Inc. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies.

    About Tufin Technologies Tufin® is the leader in Security Policy Orchestration, automating and accelerating network infrastructure changes while maintaining security and compliance. By improving network change processes, organizations using the Tufin Orchestration Suite™ will have a positive impact on the business by reducing the time and cost spent implementing network changes by up to 80 percent. Taking a holistic view of IT, the Tufin Orchestration Suite helps organizations automate security and efficiency into day-to-day operations, enabling them to be more agile and leverage technology to gain a competitive advantage. Founded in 2005, Tufin serves more than 1,300 customers in industries from telecom and financial services to energy, transportation and pharmaceuticals. Tufin partners with leading vendors including Check Point,Cisco, Juniper Networks, Palo Alto Networks, Fortinet, F5, Stonesoft, Blue Coat, McAfee and BMC Software, and is known for its technological innovations and dedicated customer service. For more information visit www.tufin.com, or follow Tufin on:

    Twitter: http://twitter.com/TufinTech