back to article Chef launches Compliance: Server security policy as code

Chef Software has released Chef Compliance, a product which aims to automate verification of server security policies to enable rapid application delivery without threatening compliance. The company has also announced general availability of Chef Delivery, a continuous delivery product first announced in March 2015. The …

  1. Bronek Kozicki

    describe port(443) do

    it { should be_listening }

    its('protocol') {should eq 'tcp'}

    end

    that is nowhere near enough. Should be able to verify that it's actually HTTPS and not some random protocol, that secure socket does NOT support old insecure protocols like SSL2 SSL3 or TLS1, that DES CBC and RC4 are disabled if TLS1.1 was negotiated. Should verify minimum negotiated key and offered public key certificate is of acceptable length etc. Otherwise its just another tool designed to lull users into false sense of security.

    And lets not forget about validation of actual application code : is there a fuzzer available for simulation of illformed inputs? What about validating that communication from application to databases is not vulnerable to SQL injection? What about verification that secret information that applications need is protected adequately ?

    1. Bronek Kozicki

      PS. El Reg, could you please stop adding <p/> tags inside <pre/> section?

    2. phil 27

      I would think this *should* be targetted for realtime monitoring of things in the field as early warning and early mop up of issues to stop more serious issues deeper in being missed, to clear the wood from the trees, not to replace skilled compliance testing during intergration testing. Its in the same space as Tennable's security centre coupled with nessus probes or IP360, though hopefully the logic in it might actually be better designed than them.

      I've been involved with the latter for quite some years, and we have written some in house scripts which do the basics which hopefully will get the devices into a roughly ready for test scenario, then we dig round each component for more information and for things more complex as detailed by yourself and check the output from our scripts for false positives. Differentiating between the two end products is sadly something management and non security specialists are unable to manage. Or they don't want to manage to understand because pretending you don't lets you get rid of that resource for a immediate impact on your departmental costs. Ask talktalk and others where that leads...

      This is not a pancea for everything, but in its niche its a useful and complemental technology to a wider security solution. Something I personally will download and see if I can recommend it to any future clients should my next job as pianist in a whorehouse prove not quite as palateable as its looking right now :-)

    3. Jim 43

      Relax there Sparky, it was an example. If it's a compliance tool, then, yeah, of course all that other stuff should be incoming.

      1. Bronek Kozicki

        yeah "compliance" is my problem, it implies that someone less technically qualified (e.g. compliance officer, or some middle manager) would use it to asses work done before sign-off. They not necessarily may be aware that the tool supports very limited set of checks.

    4. stephendv

      there's another framework for that

      Yes, and it would be ideal to test that type of configuration on the host itself.

      In lieu of such a solution we built a BDD based framework specifically aimed at security testing both the infrastructure and web application tiers. It can be found by searching for "BDD-Security".

  2. Alistair
    Windows

    Seen it in operation.

    am testing the OpenSource, standalone version.

    You have have some outstanding rules in there. Looking to couple it with Cfengine so that INBUILD states will take the test results from the compliance validation and apply fixes to enforce.

    INSTEPUP will re-apply rules on the devs/apps as they drop in applications, code, etc.

    INPROD goes to alerting only mode.

    (sorry that was my inside architect voice speaking)

    Actually cut our security team off at the knees with cfengine about 5 years ago when they insisted that they had to deploy code on every single linux host in house in /usr/local/security and set the dir 777 and the code 755. The opened up all sorts of escalation that my tool was breaking their code. Oddly, *grin* we had directors and VPs a the time that understood the implications and the security folks got slapped. Happily that particular lot aren't around any more. Wunder why.

    1. phil 27

      Re: Seen it in operation.

      I think I know where they got jobs anyway... Or maybe its endemic. Except now they'll be "cyber" not security as cyber is the current lightbulb job title the moths are drawn to.

      Isn't letting it automatically "fix" problems without intervention flying a bit close to the edge?

      Usually when something has been altered you want to know about it to go poke around and see why, its often a good way to see early on when someone might need some re-education, or that someone is up to no good or early warning signs to nip a incident in the bud before it becomes worse. Plus, there's always the chance that someone has done something for a good reason, and without understanding that reason your tool might just be rebreaking something that just got fixed before someone remembers they have to teach the fix to it too...

      Not a huge fan of fixing things by script as you can imagine, I worked one place that borked most of their infrastructure with a automated change system that applied exactly the logic someone loaded into it in the most efficient manner possible. Only took about a weeks downtime and a few hundred thousand in resource to recover.

      Just my experience. YMMV.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon