devopsy.kinsta.cloud

Tag: TK Keanini

  • Swim in the DevOps pool or drown in security problems

    Swim in the DevOps pool or drown in security problems

    There has been a significant shift recently in security. Most security vendors and organizations recognize that the traditional model of keeping the bad guys out by detecting malicious exploits is flawed at best. The reality is that the bad guys are already inside the network using authorized credentials to bypass security controls and exfiltrate sensitive data. That sounds ominous but the silver lining is that DevOps changes the game and shifts the advantage back to the good guys.

    There was a time when the traditional model made sense. The attack techniques used and the motivations behind the attacks were different. In recent years, however, the line between inside and outside attacks has been blurred beyond recognition. There have been some high-profile insider attacks like Bradley Manning and Edward Snowden, but the reality is that most of the “outside” attacks were perpetrated using stolen or compromised credentials. In other words there is no difference between an inside and an outside threat at the actual point of attack.

    Organizations have to guard against both inside and outside attacks. In almost all cases, though, the root problem is credential abuse. Whether it’s an authorized employee accessing systems or data in an unusual way or an outside attacker moving laterally through the network and exfiltrating data using compromised credentials the crucial part for an organization is to have detection methodology in place capable of performing anomaly analysis to identify concerning behavior and activity.

    Improving security through DevOps

    That’s where DevOps comes in. Organizations need to have continuous monitoring in place. Anomalous activity isn’t something you can just conduct a daily or weekly scan for. If you don’t detect the activity in real-time and do something to stop it immediately the damage will already be done by the time you retroactively review log data and discover the breach.

    Things are heading in that direction—but slowly. The good news is that DevOps seems to be picking up steam as more security vendors and organizations face the reality that the traditional security model can’t effectively protect against attacks.

    “The DevOps movement is really gaining momentum but unfortunately still small,” agreed TK Keanini, CTO of Lancope. “It is a small but passionate community that can do nothing else but grow and help fill a void as we move from traditional enterprise IT to Internet IT. The tempo of DevOps is its major security feature and—with the principals of John Boyd’s OODA loop—has a winning formula to make it too expensive for adversaries to attack.”

    DevOps isn’t just a trendy way of providing or delivering security. The security vendors themselves are also starting to embrace DevOps internally as a means of keeping up with attackers and working to develop new tools and techniques more effectively and efficiently.

    Keanini explained that everyone will be moving to DevOps over the next 3 years—just not all at the same time. “Where IT was infrastructure and development was applications, suddenly infrastructure is the application or you could say that applications have become infrastructure but in either case, the business is forced to redraw the org charts and redo the processes.”

    Jump in! The water is great

    Attacks are relentless and attackers are nothing if not innovative. If you’re using yesterday’s security tools and techniques to defend against last week’s attacks and attackers you’ve already lost. Organizations need to move faster to stay ahead of attacks, and the most effective way to accomplish that goal is to incorporate DevOps tools and principles into the security model.

    Keanini summed up with, “It is exciting and I encourage folks to start jumping off the diving board as they are filling up the pool.”

  • Embracing a culture of continuous incident response

    Embracing a culture of continuous incident response

    In a world of continuous development and rapid iteration combined with being connected online 24/7/365, you are bound to encounter threats. In fact, attackers use automated tools so you are under constant siege from continuous threats. The natural response is to implement some form of continuous incident response.

    The standard development model involves different stages of requirements gathering, writing code, and beta testing, resulting eventually in a defined, periodic software release. That model is being replaced by the DevOps culture of continuous development. Security faces a similar transformation from the pervasive legacy model of the “us vs. them” protect-the-perimeter model to a new system of continuous incident response that addresses the current threat landscape in the real world.

    There is no “us”, and there is no “them”. There is no perimeter. Your authorized users are actually more likely to expose sensitive data, or compromise your systems—whether intentionally or inadvertently—than external bad guys. Your authorized users are also just as likely to be “outside” of the mythic perimeter—connecting from personal smartphones or tablets, or logging in from a Starbucks across town. The traditional security model is simply not equipped to deal with today’s technologies or threats.

    So, what is continuous incident response? I spoke with TK Keanini, CTO of Lancope, who explained, “Some people when thinking about process think of it as a linear model where there is a beginning and end; a better way to model adaptive processes is with a loop and continuous incident response is a loop.”

    He elaborated, “Borrowing from John Boyd’s OODA loop, continuous incident response is where there is an observation, orientation, decision and action cycle that outpaces or runs at a faster tempo than the adversaries.”

    Zane Lackey, director of security engineering for Etsy.com, gave a presentation at the Hacktivity conference on the topic of “Attack-driven Defense”. The concepts he described are essentially the sort of logic and pattern that need to be applied for continuous incident response.

    There are a few key elements organizations need to embrace in order to effectively implement continuous incident response. The first is the loop Keanini described. In order to be “continuous”, you have to continue to cycle through the various phases. There is no “end”.

    One of the crucial components of continuous incident response is continuous monitoring. It isn’t good enough to scan the network once a month, or once a week, or even daily. The threat landscape is constantly changing and evolving, and you have to be continuously monitoring for new vulnerabilities, new attack techniques, and anomalous or suspicious activity that might indicate a security incident is occurring.

    Another important factor is to view continuous incident response as a cross-functional business process. Keanini stated, “I think continuous incident response—when implemented well—touches all critical parts of the business, not just IT. Making it an IT thing is just too narrow and people who experiment in this manner are destined to fail.”

    Companies that have a DevOps mindset, or have adopted DevOps principles will find it easier to relate to the concept of continuous incident response. DevOps organizations are not constricted by the departmental barriers of traditional companies. The hierarchy and red tape of an org chart can get in the way of effective continuous incident response, but DevOps businesses have a more open, fluid organizational structure that makes it much easier to adapt to the dynamics of both operating on, and responding to threats from the Internet.

    Adopting continuous incident response may be easier said than done. It is a different approach to security, which may make it more difficult to get buy-in and support from executive management. You may also encounter resistance from the IT admin and existing security personnel because they’re used to doing things the old-fashioned way, and change is uncomfortable.

    Keanini sums it up well, though. “Just step back and ask yourself how important being connected to the Internet is to your business or customers—and then just consider that continuous incident response is the cost of doing business on the Internet.”