17 Replies Latest reply on Sep 9, 2013 12:00 PM by subnetwork

    Where security and failure meet.

    subnetwork

      Over the past few weeks, I've been talking about how failure, in broad terms, affects our roles. Most of our discussion has focused on a mistake that causes an outage. However, I'm honestly surprised that no one has asked this question: "Why are you posting this in a security related forum?" Today, let's wrap up this discussion and answer that question.

       

      Many large organizations have a dedicated security team: the team who deals with IDS, perimeter protection, antivirus, patch auditing, and the list goes on.  Sometimes, such specialization can result in engineers and administrators with a blasé attitude toward security.  We forget that security is a part of every task that we complete. Ignoring these security requirements is a form of failure. An undocumented exception to a security policy is a failure, even before it becomes part of a security breach.

       

      We've all read reports of major hacking or security exploits in a large organization. While digging through the details, one is often astounded by the number of different ways that the attack could have been detected or rebuffed. Each open port, non-essential service, or open access rule demonstrates how often we forget that we are all part of the security team.

       

      One final thought: the first week, we recognized the simple truth that we all make mistakes.  The more important aspect of our personalities and careers is how we respond to that failure. The same goes for security based failure. An organization must do penetration testing and security audits. These audits should be problem and resolution focused, not a game of Clue. Knowing that Jim Bob killed security with an ACL in the core router doesn't fix the incorrect ACL; rather, repeated mistakes should be identified, and used as training opportunities for the affected team.

       

      How does your organization handle security? Are you part of the dedicated team? Does your organization regularly audit the internal systems?

        • Re: Where security and failure meet.
          zackm

          How does your organization handle security?

               - Dedicated teams for auditing and basic vulnerability scanning and then separate teams for penetration testing

           

          Are you part of the dedicated team?

               - Negative. But security is everyone's job, so maybe...

           

          Does your organization regularly audit the internal systems?

               - More like audit the tangibles like ACLs, GPOs, etc. I do not think there are audits on processes, which are arguably just as if not more important. What I mean to say is; I think the tendency is to audit the cake, when we really should be looking at the ingredients and temperature of the oven.

          • Re: Where security and failure meet.
            wbrown

            We do have a dedicated security group but their role is mostly auditing and compliance.  My role is network operations.

            The InfoSec group reviews reports from the various IDS, CMDB, AV, and Qualys tools from which they create action items for the various groups to remediate.

            In my particular case I make firewall changes for apps after the recommended rule changes are approved by the InfoSec group.

            Desktop group would confiscate and remediate (i.e. re-image, update AV, etc) infected workstations.

            • Re: Where security and failure meet.
              superfly99

              We have a dedicated security team. They follow stricts guidelines to make sure everything is secure. But they don't look after routers etc, that's part of the network team.

              • Re: Where security and failure meet.
                Kurt H


                1.     We have a dedicated security teams.

                2.     I am not part of that team.

                3.     Yes our organization monitor internal logs.

                 

                Sometimes are company takes security way to strong, where we are not able to do certain things anymore. When security starts getting that tight, then something is wrong somewhere. Security should never get to the point where you are not able to accomplish your job. And it should not get to a point where your workstation is running slower then dirt to keep up with all the changes and constant patching.

                • Re: Where security and failure meet.
                  syldra

                  How does your organization handle security?

                  I am security... sort of... I've been here for two years and I'm trying to change things but it always was a second thought and mentalities are hard to change. Think user password sharing, default password on network equipments, unlocked computers while the user is away... and I'm not talking about the server room...

                   

                  Are you part of the dedicated team?

                  I am the dedicated team... but I will try to train some users to recognize unsecure behaviors so I can have eyes and ears in many places... you can't correct what you don't know about. Also, management must *believe* that security is important or else there is nothing I can say that is going to be heard if managers don't push it to their employees.

                   

                  Does your organization regularly audit the internal systems?

                  No. But I plan an changing that also. The last two years changes have been more hardware related but this year we will set up user training, monthly security awareness activities (one theme per month) and drawing plans of what is where, what impacts on what and so on... big year coming up. After that, recurring audits and spot checks...

                  • Re: Where security and failure meet.
                    michael stump

                    Security people like to talk about security being either "baked in" or "bolted on." Seems to me that if you want security to be truly integrated with engineering efforts, security engineers need to be baked into the various project teams, not simply another team to complicate the project. It's fine to have a team that's dedicated to security, but don't isolate them from the engineers; doing so creates an "us vs. them" mentality that results in project engineers hating security engineers, and vice versa.

                     

                    That said, most places I visit have a separate team for security. And most times they aren't even on the same floor as the server and network teams.

                     

                    Internal audits are few and far between, sad to say.

                      • Re: Where security and failure meet.
                        subnetwork

                        michael stump wrote:

                         

                        Seems to me that if you want security to be truly integrated with engineering efforts, security engineers need to be baked into the various project teams, not simply another team to complicate the project. It's fine to have a team that's dedicated to security, but don't isolate them from the engineers; doing so creates an "us vs. them" mentality that results in project engineers hating security engineers, and vice versa.

                        Michael, I could not have said it better. The other benefit from this methodology is that you now have security people who understand the network and server requirements. Thus, security decisions can be made that strike a balance between security and usability.

                      • Re: Where security and failure meet.
                        rharland2012

                        As a group, we've finally addressed that we need auditing, visibility, and measurement before we can truly address internal security. We have tools in the budget going forward to address all those concerns, and my colleagues are feeling better already.

                        • Re: Where security and failure meet.
                          byrona

                          At our company each team (Windows, Linux, Networking) is responsible for defining and auditing their own security.  We also have external auditors that audit both our internal and customer systems.  We have a few HIPAA environments that are checked by external auditors and we also do SSAE16 audits.

                          • Re: Where security and failure meet.
                            cahunt

                            We have a security team, though they do not exactly look into our devices. They watch for offenders; and remediate as needed. Security from operations to engineering could be spruced up a bit, in the idea of narrowing or removing some Strings used. Since each department sets up their own equipment (Data Center/DC Ops/Data Engineering/Voice Engineering/Data & Voice Operations) I get to see the broad use of security strings and types used. It's a hard task to get through the politial mumbo and have someone allow you to monitor their device in some cases. Then and only then we have the chance to adjust settings to try and convince someone to make things more secure. In the past the attitude was if no one can see into your device it is secure. So keeping it locked up within the department was key. The Solarwinds Suite of products has assisted greatly in being able to show off reporting and alerting for some of these devices. As we get more and more departments on board(Some specific departments have IT support for their Apps and Special type devices, Rx and Diagnostic Imaging for example) we are able to show off more and now we are getting requests from other departments to asssit with their monitoring. It is easy to reccomend and have someone receive your input to make a change for better security when they come to you.