New CISSP, New Job?

[Gunner]

     For the seasoned CISSP's out there, or for that matter even new CISSP's that may have experienced this and would like to pass along "lessons learned".  What sage advice should be passed on to a new CISSP that just took over a new job, hired to perform CISSP duties? 

     Brand new job, new people, different mission, etc...  What are some of the first things you would recommend that they should do?  Not do??  I imagine there are some horror stories out there.

[CISOScott]

Learn the culture of the organization.

All your good ideas about improving security will be fought against if what you present goes counter to what the current culture is. I learned this the hard way. I started in a new organization, along with 2 other "outsiders". We were not internal candidates, we all came from other agencies. We could see how bad the IT security was, but we could not get the current staff to agree. The culture was that of blissful ignorance and the belief that they knew what they were doing, when they, in fact, did not know what they were doing. All efforts to improve  the IT security were met with resistance because we were attacking them with facts instead of realizing that there was a hidden insecurity to admit they had been doing it wrong all along. Even though their own Inspector Generals office had been pointing it out for years! Looking back on it with much more experience I would have found a different way to present our security recommendations in a away that allowed them to save face and work toward accepting our ideas rather than trying to force our ideas on them. Needless to say 2 of us left the organization, along with the CIO, for better assignments.

[TonyDS]

Yeah - I totally agree with CISOScott there.

You have to learn the culture of company and try to change it from the within.

At the same time though, you have to remember your own standards and values. 

It's a balancing act and probably one of the toughest parts of being a Security Professional.

[CISOScott]

Step 2 would be to learn about what regulations affect your business. There are a lot of frameworks out there. Find out what affects your business. If in the US then does PCI affect you? HIPPA, Sarbanes/Oxley, etc? Learn what frameworks you have to comply with so you will not fail compliance checks and you can protect your company.

Step 3 would be to assess the current situation. Are they in compliance? Do they have good IT policies and procedures around backups/disaster recovery, account creation/maintenance, change management procedures, etc. How do they stack up against the SANS top 20 critical controls (Now called The CIS Critical Security Controls for Effective Cyber Defense). 

Step 4 would be to create an effective plan for bringing them in to compliance by assessing the current risks associated with each "finding" you find.

Step 5 Would be developing a plan for the future. Once the findings have been fixed, how do you help the organization from repeating the mistakes of the past?

[CISOScott]

Step 6 would be to see if the security dept has been a roadblock in the past. You will have to see if you can fix the mistakes of the past. You should always provide the why behind your security decisions, not just the No. Understand what the customer (who is anyone that comes to you for security advice is) really wants. They usually want a way to connect some device to some network. If there is no way the new device can connect to existing networks, is it possible to create a new one just for exceptions like this, even if just a small temporary network? Can there be ways to layer security to help it meet the existing security requirements? Do the existing security requirements still make sense? Here is a story to show that sometimes requirements are created but then never looked at again, even though they seem to not make much sense.

A beer distributing company had a  policy for their delivery drivers: All of your long delivery runs had to be done at the beginning of the week and your shorter distance runs were to be done at the end of the week. Some drivers got done with their long distance deliveries early and had enough time to complete some of their shorter distance deliveries but were  told "The policy is that shorter runs must be done at the end of the week". Even though they had enough time to do them, they were denied the chance due to policy restrictions. 

One day the company held a picnic and invited everyone who had ever worked there, including retired employees. Some of the new delivery drivers were sitting around complaining about the distribution policy with some of the retired delivery drivers from when the company was first started over 50 years earlier. The new drivers  were complaining about the fact they had enough time to complete the shorter deliveries but didn't understand why the policy prohibited making the shorter deliveries after the longer ones had been done that day. One of the oldest former delivery drivers spoke up and said "Well the horses were too tired after making the long deliveries to ask them to go out again on the shorter runs the same day." The new drivers brought over some company executives, both new and old, and told them what they found out about the policy. Turns out the old delivery driver was correct, the policy was based off of the distribution method of the time (horses) and not the current delivery method (trucks). When they returned to the office on Monday they revised the policy to state that delivery schedules could be adjusted to what made sense.

So review your policies and look to update them, replace them or retire them, as necessary. Look for ways to be creative about providing security.