devopsy.kinsta.cloud

Tag: continuous security

  • Q&A with Mark Carrizosa of Soha Systems on secure transition to DevOps and cloud computing

    Q&A with Mark Carrizosa of Soha Systems on secure transition to DevOps and cloud computing

    We recently spoke with Mark Carrizosa, vice president of security at secure application delivery service provider Soha Systems about the trends he sees with enterprises moving to cloud services. Prior to recently joining Soha Systems, Carrizosa held the position of principal security architect at Walmart where he developed and implemented the company’s global e-commerce security architecture framework. Prior to Walmart, Carrizosa held security positions at companies including Wells Fargo, where he analyzed the company’s infrastructure and application compliance to improve the security of both customer-facing and internal systems. Before that, Carrizosa held positions at Freeport-McMoran and PetSmart. This interview has been edited for brevity.

    devopsy.kinsta.cloud: With the rapid move to DevOps and cloud, are there opportunities to improve automation and for enterprises to do more with less? Or is DevOps moving so fast that there are additional challenges being created that outweigh some of the benefits?

    Carrizosa: In my opinion, and in my experience, particularly over the last few years in dealing with predominately DevOps shops, the challenges that we faced were not necessarily “can we automate something,” rather it’s “should we automate something.” There are absolutely some things that should not be left entirely out of the automation stream, but should have controls setup as a requirement at a staging gate. For example, you can automate the dynamic scanning your application for vulnerabilities, but what you also need is somebody to actually look at those applications and manually verify and make sense of the reports. These are key components in deploying and delivering secure applications.

    There are also ways to expedite processes by integrating certain security frameworks into your workflow, providing the right training, and also creating a shift in your culture. And DevOps, for the most part, is a good thing. It allows organizations to rapidly come to market.

    It’s also common in DevOps to have contentions between security and IT. The security group says “No, you can’t do this, it’s going to hurt us.” While the engineers say “We need this to push this out.” How well organizations manage these relationships is a mixed bag. But there is a formula for doing it successfully, and it is all about ingraining security into the culture, into the operations, so that you come out with a secure product and not have to remediate it once it’s done.

    devopsy.kinsta.cloud: When you’re constantly iterating and changing your infrastructure and deploying new apps and updates, how does that affect aspects of security that can’t be automated, such as threat modeling applications before they are built or changes are put in?

    Carrizosa: Threat modeling, while a new term, it’s not a new concept. If you think about risk management, typically audits are done at a point in time. But very good information assurance programs not only audit a point in time, but they implement a continuous model of checks and balances. So should threat modeling.

    Threat modeling needs to happen at inception to ensure that the concept is sound and the methodology is acceptable from a security perspective. But there should also be some levels of checks and balances to ensure that the baseline, or security posture, is maintained throughout the entire change management cycle from inception all the way to delivery.

    These are some of the things that can be embedded within DevOps and Agile. Microsoft has a very good, secure lifecycle management methodology that incorporates various elements of security checks throughout the entire development lifecycle. It’s something like this that needs to be included within these operations to ensure that every step you take has some level of checks and balances, whether it be automated or manual, to ensure that the process of an application or an environment is up to what organizations are requiring.

    devopsy.kinsta.cloud: There’s still considerable interest out there when it comes to how companies are meeting the challenges of moving to cloud services. Are there common threads you see out there when it comes to the challenges enterprises face when moving to cloud services?

    Carrizosa: Yes, absolutely, and one of the key factors is that organizations are looking for ways to securely move to the cloud, or move to a more shared compute environment while still maintaining the control and the reduction of risk that they are used to internally. I spent the majority of my career dealing with these topics from an enterprise level. Most recently at Walmart E-commerce, but I’ve also done the same for PetSmart, Wells Fargo, and some leading industrial companies throughout the industry.

    Some of the challenges that I faced have to do with public exposure. You have to deal with migrating from on-premises to cloud, and dealing with BYOD enterprise users. There are a number of potentially sensitive customer-facing applications or data sets that organizations are a little hesitant to move to, particularly at large organizations.

    Those large organizations are used to doing things a certain way. Time and time again I’ve heard the phrase, “but we’ve always done it this way.” That in essence could be some of the downfall, or some of the hesitance with these organizations in moving to the cloud, because they are not absolutely sure that they will maintain the control and the effectiveness for environments that they can’t manage.

    That’s what Soha is about. Soha allows these organizations to make that next step, to be able to take advantage of these cloud benefits, or even take advantage of some of the cost overhead and the security controls that they’re typically having to address at a high rate of cost and a great deal of effort.

    devopsy.kinsta.cloud: Broadly, considering a lot of the credit card and other significant breaches that have occurred in the past decade, do you think the sense of control enterprises have about how well their security and governance efforts are doing is illusionary?

    Carrizosa: Well, there’s that old adage of, “it’s never ‘if,’ it’s always ‘when.’ These recent breaches, for instance, are not necessarily based on the types of controls that organizations have, but a lot of times legacy controls or legacy approaches have always seemed to be good enough. And until there is some sort of catalyst to effect change, organizations aren’t necessarily going to stick their necks out. You have CIOs saying, “We do this, we do this, and we do this,” because that’s what they’ve always known. It’s time to now shift to a more open model. With that comes many risks, but in order to do so, there needs to be a fundamental change in the methodology of how organizations are tackling security.

  • The continuous continuousness of DevOps

    The continuous continuousness of DevOps

    Defining DevOps is getting easier, but it’s still an elusive goal. Part of the challenge is that DevOps is more of a culture than a specific “thing” and how that culture exists is subjective and varies from one organization to the next. DevOps is what you want or need DevOps to be to some extent, but one thing seems to be consistent no matter how you define DevOps—it’s continuous.

    If DevOps is the buzzword du jour for tech, then continuous is the buzzword du jour of DevOps. Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response…or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.

    What does it all mean? I mean, aside from being a catchy buzzword and making that new DevOps tool or service sound sexy and impressive?

    In a nutshell it means there’s no end. You don’t really reach a point where everyone can shut down their PCs and grab a beer to celebrate the completion of the project. The project—whatever it is—is more of a living, evolving thing than a deliverable.

    There’s also no beginning—or at least no new beginning. All of the continuous activities cycle back over each other like a Spirograph drawing. Have you ever tried to find the beginning or end of a Spirograph drawing? Good luck.

    DevOps is the Alpha and the Omega, the beginning and the end, the first and the last.

    When you strip out the buzzwords what it really means is working in a more effective and efficient way. I’ve worked on software development projects the old-fashioned way. No, not Agile—Waterfall. The cascading tasks feed each other in what appears to be a logical progression. It makes sense to define requirements, design the software, implement it, test or verify it, and then kick back and go into maintenance mode…on paper at least.

    In the real world new requirements are discovered when you’re ready to implement, and testing results in new design elements. Those new requirements need to be designed and the new design element needs to be implemented and it all needs to be tested and maintained which inevitably creates new requirements, design elements, and so on.

    Waterfall was already DevOps—it was just dysfunctional because each “continuous” loop was treated as a unique and separate project. Items that were identified after the design phase were just accumulated on a list to be incorporated into the next phase or iteration. The net result was producing a somewhat stable product that you already knew was flawed, but that you’d get to fixing eventually.

    Agile development accelerated some of the feedback loops of Waterfall and resulted in faster refinements to projects, but it still had issues. The primary issue is that developers can’t go faster by themselves. Developers are just one cog in the machine and producing software faster just creates a bottleneck if operations isn’t prepared and the infrastructure isn’t ready to handle it.

    Chris Riley explained the challenge of Agile. “However, the Ops department was inherently left behind with deployments piling up faster than they could be released and customers never actually received the value they demanded. This trend ultimately gave rise to DevOps, a new-age version of Agile methodology encompassing the Dev and Ops segment to enable service delivery agility and quality.”

    Another way of looking at it is that DevOps is an evolution of Agile. I wrote recently, “DevOps is just a natural extension of Agile. It takes the guiding principles and best practices that Agile brought to developers and applies them on a much broader scale across the organization.”

    So now everything is continuous. There is no top of the waterfall that cascades through multiple layers until you reach the bottom of the waterfall. Now there’s a continuous culture of continuity. It may sound confusing when viewed through all of the various buzzwords, but when you step back it makes sense. It makes sense because that’s really the way it worked—or should have worked—all along.

    DevOps gets processes and policies out of the way to enable people to get things done more efficiently. For some reason we’ve decided that every element should be labeled continuous—which actually makes it sound a little frenetic or overwhelming. Maybe we should use “efficient” instead. That can be our new buzzword.

  • DevOps Makes Security Assurance Affordable

    DevOps Makes Security Assurance Affordable

    Despite the fact that information security is a top priority, many organizations face challenges integrating security assurance practices into their product and service development practices. All too often security problems are only detected and resolved with software patches following a security breach. Security assurance is often reactive but what is needed is a more consistent proactive and affordable approach to security. As indicated by Sean Michael Kerner in his article The DevOps model isn’t a threat to security; it’s a tool that can be used to enforce security like never before.

    DevOps with Continuous Testing (CT), when implemented according to best practices, is an opportunity for organizations to systematically and affordably integrate security assurance into product and service development. Using DevOps techniques, continuous security testing can be built into software change and deployment operations. Many refer to the application of DevOps practices to security assurance as “SecDevOps”.

    Below are some continuous testing best practices that make continuously testing security affordable:

    1) Develop expertise in SecDevOps CT: Security assurance demands that an organization develops expertise and processes to identify threats, protect against them, detect threats when they occur, respond with solutions and recover quickly. SecDevOps CT is not so different from any other DevOps CT except that it includes a security focus. Security assurance is really a special case of quality assurance and the practices for continuous testing also apply to security assurance. Other than the general continuous testing practices which I have described in my blogs on continuous testing, here are some specific skills needed for effective SecDevOps continuous testing:

    a. Include security experts in the DevOps CT team who are familiar with security domain knowledge including next generation network security protocols, understanding of BYOD security, cybersecurity attacks, in-application aware networks, streaming media and content delivery, virtualization and cloud security.

    b. Security experts should partner with and train the rest of the organization. This should be done from the beginning of the development process. This is important to ensure security is no longer an afterthought for an isolated department to worry about, but integrated at all stages of a project. This will ensure that developers and testers have a security mindset as part of their daily work.

    2) Leverage DevOps and continuous testing to make security assurance affordable: Because security assurance like quality assurance is considered a cost rather than a revenue generation activity, organizations are challenged to afford proactive security assurance. DevOps, when implemented in accordance to best practices, has a number of characteristics that make security assurance affordable as follows:
    a. DevOps infrastructures are configured as a common resource shared by the entire development, test and deployment teams and consolidate separate department test labs which allow budgets to be pooled.

    b. Orchestration tools include automated test topology re-configurations of products, test tools and interconnection components within physical, virtual and hybrid test lab deployments. This enables a wide range of security relevant production configurations to be stood up without expensive dedicated test equipment for each topology.

    3) Use Security-CT-Ready test tools which support security test protocols and flexible automation workflows: As indicated in my prior blogs not all test tools are CT ready and this is true for security tools also. Using the right security test tools that are CT-ready will make the job of integrating security into CT much easier. Here are key ingredients to look for in Security-CT-ready test tools:

    a. Use test tools with built-in security tests….no need to recreate them! These tools need to be compatible with security standards. The following whitepaper provides a framework of the impact –
    NIST Cyber Security Framework.

    b. Use test orchestrations tools that integrate well in the DevOps environments and can stand-up any production configurations consisting of a variety of platforms, mix of vendor components from the device level all the way to large scale network topologies. A good example is Spirent’s Velocity solution.

    c. Use static code analysis tools during continuous builds with built-in checkers that verify software security coding standards including CWE/SANS, OWASP and PCI DSS. For example Parasoft static analysis tools.

    4) Engage outside expertise to help accelerate your progress towards continuous security testing best practices: Many organizations make the mistake of trying to do everything themselves instead of employing expert consultants. Bringing in outside expertise can greatly improve the speed of accomplishing best practices. A good example of security expertise is Spirent’s Network Security Testing brochure.

    The above is a partial list of suggestions for continuously testing security that have been proven to yield good results for SecDevOps. At Spirent we think testing has a bright future in DevOps. You can read more about our views at Spirent.com/solutions/devops

    What do you think of these suggestions and do you have others that should be mentioned?

  • Continuous is the new Black

    Continuous is the new Black

    We have gone from the city that never sleeps to a world that is continuous. That’s right, it seems along with the world shrinking, it is always on, someone is always watching or doing. Continuous has become the new black.

    Nowhere is this more true than in IT.  We have Continuous Delivery, Continuous Integration, Continuous Testing, Continuous Monitoring, continuous this, continuous that, continuous everywhere. Infosec is not immune to this either. We are trying to protect against continuous attacks by deploying continuous scanning, continuous threat protection, continuous monitoring, all of it part of our continuous security. All of this sounds like an old George Carlin routine. But it’s not it, it is the way things are today.

    Of course all of this continuous around security had to lead to continuous compliance. After all who would want to be compliant at only a point in time (even if that point was at the time of audit)?

    The newest version of the PCI DSS tries to move compliance from point in time compliance to continuous compliance. Some question whether this puts too big a burden on merchants. How many resources can they dedicate to compliance to make sure it is continuous?  Others say that continuous is the only way that makes sense.

    For me there is a lesson here that security can learn from DevOps.  The key is automation.  Automation is the secret weapon in doing continuous.  Without automation, continuous would require too many resources to truly succeed. But with automation we can duplicate, perform act over and over again without a human initiating every step, every move.

    That is not to say that humans are no longer needed. On the contrary, automation frees up humans to work on tasks of a higher nature. Automation frees up humans from the repetitive, mundane tasks that need to be done over and over again. Working instead on things that are of a higher value (at least they should be).

    But wait there’s more! Not only does automation empower continuous, automation brings speed. Once we automate, we can speed things up as well. So not only are we performing continuously, we are also performing faster.

    Now we are automating tasks without human intervention and at the same time doing them faster. I know for many a security admin the hairs on the back of your neck are standing up. This can’t end well.  Things are going out of control. Automating and speeding things up almost goes against being cautious and careful.

    But as counter-intuitive as it may be, automating and performing faster can actually result in being more secure and more compliant. Wait lets repeat that again: by automating and speeding up performance we can actually become more secure and more compliant.

    How? You don’t believe me? Impossible you think? How can continuous make us more secure and more compliant? Is it even possible to do all of this continuously?

    This is the topic that I along with Jody Brazil, CEO of Firemon are going to explore as hosts of a P2P session at RSA Conference. The session is on Thursday at 10:20am, it is titled Continuous Network Compliance: Finding Flaws and Betting Futures, you can click on the link for more info. Put it on your RSA calendar if you are attending. The P2P sessions only hold 25 or 30 people so come early.

    I will post a follow up to this post after the session with some of the discussion points around this. If you would like to hear the answers before then though, you will have to come to the session.  See you in San Francisco at RSA Conference.

  • DevOps – A wake up call to security vendors

    DevOps – A wake up call to security vendors

    DevOps is changing the way IT works.  Through a collaboration of development and IT teams, organizations can achieve tremendous scale at increased speed to deploy and maintain critical applications and infrastructure.  The key technologies of virtualization and configuration automation have made this possible.  Without these technologies, development may not slow down, but deployment would slow to a crawl and the benefits of DevOps would be minimal.

    It is interesting to note that in almost no definition of DevOps is the security process discussed as a key element.  In some cases you will hear mention of improved security through consistent configuration management enabled through automation, but security teams are not at the DevOps table.  Why is that?  I would suggest that for most people security is considered a barrier to IT.  Not surprisingly, DevOps, a practice focused on streamlining IT, security has been left out of the conversation so as to not prevent achieving the goal.

    But if you accept that security needs to remain a part of the story, then it must be just as manageable as the infrastructure or it will never have a seat at the DevOps table.  Take a look at Puppet or Chef; they automate the configuration of the systems necessary to run the applications.  Through automation scripts, systems are deployed, configured, updated, and managed.  Development boxes are configured consistently with production boxes limiting impacts related to deploying an application into production.  So why can’t security fit into this picture?

    One reason, is a lack of standardization.  Every security vendor wants to be unique.  They promote their solution as so incredibly unique from their competitors that there is no way to standardize.  So, creating scripts to manage security would require not only a unique script for each vendor, but a unique solution.  In comparison, the command to edit a route in Linux may be slightly different than in Windows, but the parameters are the same.  When you are managing security rules on a firewall as an example, you can’t even get agreement on that.  Zones are required for some firewalls, not used in others.  Applications define access in Palo Alto, but don’t exist in Cisco.  Even firewalls that share the idea of Applications use non-standard dictionaries of Applications.  So, creating a script becomes a non-standard solution.  Worse yet, the script that worked today won’t necessarily work tomorrow when the vendor changes their solution.

    To make it all unmanageable, is the fact that they are so proud of their uniqueness that they have obscured even how they do it.  If you take all the firewall vendors on the market, not one of them publishes an API on how to fully manage their firewall policies.  Palo Alto exposes some capabilities for object management in a cool SDN sort of way.  Check Point has a very powerful, but proprietary API that allows full management, but they do not recommend it be used in that way.  Cisco is straight up command line with some newly available API’s and should be commended for making it at least obvious how to do it, if not easy.

    The result: security is not a big part of the DevOps picture today.  And if the vendors don’t do something, they will be replaced by solutions willing to operate in this new DevOps world.  Open source firewalls or integrated firewalls in the virtual stack for example are ready to take their place.

    The solution for security vendors: publish API’s to fully manage their systems.  They must accept that their UI is no longer what differentiates them from their competitors, it is the security engine and enterprise manageability.  Make it possible for others to manage their solution through open API’s with their full support.  All the security vendors will not come together and agree on a single API, but each should at least publish a usable API for their own product.  Vendors like FireMon or open source contributors to solutions like Puppet and Chef will solve the rest.

    Security vendors better wake up or they will get left behind.