devopsy.kinsta.cloud

Tag: securosis

  • Securosis Identifies Benefits of Runtime Application Self-Protection (RASP) in New Report

    MONTREAL–(BUSINESS WIRE)–IMMUNIO, the industry leader in runtime application self protection (RASP), today announced the launch of a research report authored by information security and research firm Securosis entitled, “Understanding and Selecting Runtime Application Security and Protection.” The independent report explores how DevOps teams are addressing today’s current application security issues and where RASP can provide immediate and measureable benefits within the agile development process.

    According to Securosis, “For [DevOps] teams, security products must do more than address application security issues; they need to mesh with continuous integration (CI) and continuous deployment (CD) approaches, while offering automated capabilities and better integration with developer tools.” The research paper summarizes how RASP has emerged as a tool that can examine requests at the application layer to detect attacks and misuse in real time, fitting into the agile development process and behaving as its own code — running anywhere the application does.

    “We’ve been examining DevOps for several years now and figuring out how to embed security into the development process is a huge goal for most organizations today. RASP is a technology many are exploring for this very reason, and most teams we talked to for this report were either considering RASP or already engaged in a proof-of-concept project,” said Adrian Lane, senior security strategist, Securosis. “RASP solutions are much more effective at attack detection than web application firewalls (WAFs) because — being embedded within the application at runtime — they actually see what’s really happening, and can more effectively apply security controls. Couple that with the ability to scale right along with the application, and it’s not hard to see why developers and operations teams are embracing this technology.”

    The research paper defines RASP and covers the following topics related to the technology:

    • Use Cases: details the primary function of RASP while providing an overview of how it works as it relates to today’s market drivers
    • Overview of the Technology: highlights the technical facets of RASP, including deployment models, application integration, detection and blocking capabilities, language support, performance, maintenance and training
    • Integration: outlines how RASP fits both into the technology stack and development process to deliver applications

    “Based on Securosis’ findings, it’s obvious DevOps teams are facing new challenges when implementing fast, agile development processes and WAFs, manual pen testing and static analysis of source code require a lot of manual effort and niche expertise to be effective at detecting vulnerabilities and attacks,” said Zaid Al Hamami, CEO and co-founder, IMMUNIO. “RASP is a completely different approach to application security and one the industry is still getting familiar with. The more teams realize how it can benefit them and begin piloting RASP software, the closer we’ll get to environments that truly protect applications in real time. Application security technology has evolved, and now you can have both effective security and agile development.”

    The research report also features a detailed buyers guide for individuals and teams looking to understand how to best evaluate RASP solutions, and avoid the pitfalls that can come with new technologies. The paper is now available for free download athttps://www.immun.io/securosis-runtime-application-self-protection-report.

    About IMMUNIO
    IMMUNIO is a pioneer in runtime application self-protection (RASP), providing automatic detection and protection against application security vulnerabilities. The company’s mission is to make truly effective real-time web protection technology easily available and widely deployed, and by doing so, stop the biggest source of breached data records. For more information, visithttps://www.immun.io/ or follow @immunio.

  • 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.