Home > Cloud Computing, Cloud Security, CloudAudit, Compliance, Virtualization, Virtualization Security, VMware > (Physical, Virtualized and Cloud) Security Automation – An API Example

(Physical, Virtualized and Cloud) Security Automation – An API Example

The premise of my Commode Computing presentation was to reinforce that we desperately require automation in all aspects of “security” and should work toward leveraging APIs in stacks and products to enable not only control but also audit and compliance across physical and virtualized solutions.

There are numerous efforts underway that underscore both this need and the industry’s response to such. ¬†Platform providers (virtualization and cloud) are leading this charge given that much of their stacks rely upon automation to function and the ecosystem of third party solutions which provide value are following suit, also.

Most of the work exists around ensuring that the latest virtualized versions of products/solutions are API-enabled while the CLI/GUI-focused configuration of older products rely in many cases still on legacy management consoles or intermediary automation and orchestration “middlemen” to automate.

Here’s a great example of how one might utilize (Perl) scripting and RESTful APIs against VMware’s vShield Edge solution to provision, orchestrate and even audit firewall policies using their API. It’s a fantastic write-up from Richard Park of SourceFire (h/t to Davi Ottenheimer for the pointer):

Working with VMware vShield REST API in perl:

Here is an overview of how to use perl code to work with VMware’s vShield API.

vShield App and Edge are two security products offered by VMware. vShield Edge has a broad range of functionality such as firewall, VPN, load balancing, NAT, and DHCP. vShield App is a NIC-level firewall for virtual machines.

We’ll focus today on how to use the API to programatically make firewall rule changes. Here are some of the things you can do with the API:

  • List the current firewall ruleset
  • Add new rules
  • Get a list of past firewall revisions
  • Revert back to a previous ruleset revision

Awesome post, Richard.  Very useful. Thanks!

/Hoff

Enhanced by Zemanta
  1. Kin Lane
    June 7th, 2011 at 13:07 | #1

    In reference to your talk at Gluecon. I have a lot of SysOP and Network Admin associates who would love to automate their security and take advantage of APIs but they are scared of programming. They don’t consider themselves programmers even though they often use many scripts they find for various manual tasks, and are perfectly competent. Something do with silos of roles or something.

    I think they need more examples like the Perl / VMWare solution above in a central location / book and they can put to use and get more used to automation.

  2. June 7th, 2011 at 13:17 | #2

    In reference to your Gluecon discussion, which was great. I have a lot of sysadmin and network admin associates who would love to automate their systems but they do not consider themselves coders.

    If you give them a script to use, that has value…they will use and even modify and extend on their own. It seems because of the silos they work in, they are afraid to write code or do this themselves.

    I think if there was a central repository or book of scripts like the Perl / VMWare example above, they would make use of and further security automation in the way you wish.

  3. June 7th, 2011 at 13:26 | #3

    I certainly like the push for API and automation in infrastructure and security, and it's undoubtedly the right thing to do and the right path to move forward. But I don't yet see many people asking questions about how all these devices will interoperate, how info will be passed between various layers of defense, and so on. The fact that info is accessible programmatically does NOT automagically lead to good interop.

    Also, it's going to be interesting when people realize that their management scripts and systems that call APIs also need to be protected against attack, and so on and so forth.

    Having API and being able to call it is just a first step, not the end goal. I want to see tools and systems that use API from various vendors to get me a higher level view + intelligence. That would be cool.

    As a sidenote, been a long time since I came here – like the overall redesign, but the font in this window where I am typing this is horrible (Chrome on Mac).

    • RatSurv
      June 7th, 2011 at 13:58 | #4

      Agreed, but we're not likely to have a consistent policy across heterogeneous security engines for along time UNLESS we abstract and use that abstraction as a lever (even if it's kludgy to start) in order to make progress here. To the point about securing APIs, that was the point of my blog a couple of days ago. Everything has a price (or a "tax" as it's known in these parts) BTW, I'll look into the font issue…it's the comment stylesheet of IntenseDebate I'm having an issue with. Thanks.

      • helper
        June 20th, 2011 at 15:59 | #5

        style.css line 40
        pull the "text-shadow: 1px 1px 0 black;"

        • RatSurv
          June 20th, 2011 at 16:21 | #6

          Thanks very much…I know it sounds stupid, but I kept looking for/in the wrong place/stylesheet for this! I thought it was an IntenseDebate problem, but it was in the theme's CSS.

          Thanks very much!

          /Hoff

  4. RatSurv
    June 7th, 2011 at 13:56 | #7

    Kin:

    Great point. I don't think you need to be a "coder" to successfully automate, but to your comment of a central repository, I was talking to the guys from OpsCode about launching a community effort focused around recipes/cookbooks for Chef specifically for security components of well known products. I need to kick that discussion back up (/ht to Adrian Cole with whom I originally had this discussion two years ago at Glue)

  5. gray
    June 9th, 2011 at 17:04 | #8

    Chris – RSS feed has disappeared? Can't seem to find one that updates to primary blog. Help pls.

  6. June 13th, 2011 at 11:22 | #10

    Glad to be of service! VMware has committed to improving their vShield API over time to offer even more functionality, which is great news for security vendors such as ourselves who want to further leverage VMware integration.

    For those who are interested in integration with vSphere in general (not just vShield), there is an open source API called VMware Infrastructure Java API available at http://vijava.sf.net. The API abstracts the vSphere Web Services SDK to make it easier to work with. You can use any language that leverages the JVM such as jRuby, Scala, jython, etc.

    The API author Steve Jin has a site at http://www.doublecloud.org with lots of good coding examples. He's also written a book called "VMware VI and vSphere SDK: Managing the VMware Infrastructure and vSphere". I highly recommend it!

  1. June 20th, 2011 at 11:53 | #1
  2. June 24th, 2011 at 15:03 | #2
  3. June 29th, 2011 at 11:20 | #3
  4. July 4th, 2011 at 22:21 | #4
  5. July 4th, 2011 at 22:23 | #5
  6. July 29th, 2011 at 12:59 | #6
  7. October 27th, 2011 at 16:39 | #7