Where have all the Security Architects gone?

as Sunshine stated, ‘looking at it from the other side, though, this comes to show some of the ill in our industry. people buying “products” to do security rather than incorporate products in their security strategy and infrastructure.’

he’s dead on the money. i had planned on blogging about this some time in the next month…but, since he brought it up :) the *art* of architecting secure networks seems to have gone the way of the dodo. many current security tools seem to be fixing the symptom and ignoring the cause. the cause of many of our woes is simply poor initial architecture. period. you don’t need an application firewall if you’ve followed the guidelines for architecting good code. you don’t need an ips to only allow x% of your traffic to flow to a certain service if you have correctly implemented traffic-shaping on your edge (or core) router. i could go on and on. many “security” tools are just “second chance” devices. you’ve incorrectly configured your edge router or never really had a clue how to configure it in the first place? that’s ok, put our “security device” (a router with a fancy gui) in front of your servers and try it again. good initial architecture falls into that 80/20 rule. it solves 80% of the problem in 20% (or less) of the time.

Share
  • sunshine

    There is a long discussion about the uselessnessss of I[DP]S, and I do agree they are defences against something you can fix completely… (in most cases).

    Still, I don’t see how the router solves the need for an I[DP]S completely?

    In my opinion using an I[DP]S without first securing (from the get-go) the infrastructure and forming (enforcing) policy as discussed is useless, it just adds another link that can be broken into.

    Let’s not start the whole I]DP]S is useless discussion again, though. I love them (even if Aviram claims I’m the only one in the world who actually needs them).

    This all reminds me of what Noam says about XSS/SQL Injections. Why buy a possible compromise with yet another software-based machine to solve 10% of the problem, when you can make sure it’s not there and eliminate it completely? After you have done that by changing very few lines of code… talk about buying.

  • dmitryc

    I was just using the ‘traffic-shaping’ as an example. I don’t have IPS deployed on my network. I was talking with a guy that did deploy it. I asked him what the best feature was and he stated that he could specify what percentage of traffic he allowed (as a max) to a certain server. Of course, you can do that with a good router. And I would contend that if you are trying to stop a DoS through traffic-shaping rules, you want to do that as far away from your end device as possible. That is, the best spot is at the edge router (into your network) of your ISP. The second best spot is at your edge router. And, finally, the worst spot is directly in front of your app server :)

  • sunshine

    I heard of people using IPS devices as “anti-DDoS”, I still don’t understand what’s that all about?

  • http://www.cisco.com Roland Dobbins

    ‘Architecting’ is not a word. I think you mean ‘designing’.

    ;>

  • http://www.BeyondSecurity.com aviram

    Yes, Anti-DDoS devices. But before we discuss that, I have a bridge to sell you.

  • dmitryc

    Yes, I’d say that I meant to write ‘designing’, but that would be a lie. I just speak bad english, how about that? :-)

    Oh, and Roland would likely have some input into the whole (D)DoS-prevention discussion ;-)

  • sunshine

    Only way to *prevent DDoS* is shoot DDoS-ers. Only way to *prevent DDoS effects* is more bandwidth.

    Then comes mitigation which is somewhere between expensive and working to a bit less expensive and a fraud.
    :)

  • http://www.ursecta.com Martin W

    I’d go much further. If the actual applications are designed right, there is much less need of tacking on the second chance stuff. For instance, if you only pass (and store) encrypted messages and if you design for asynch messaging instead of sessions, your internet connected hosts don’t need to contain sensitive data or have excessive rights on the rest of your networks.

    IOW, design the apps, and the messaging protocols at the application level, then the network layouts, considering security and resilience first. If you do, protecting the network then turns out to be a whole lot easier.