_gaq.push(['_setAccount', 'UA-35754314-2']); _gaq.push(['_setDomainName', 'securityeverafter.com']); _gaq.push(['_trackPageview']); Security Ever After: 2016 var _gaq = _gaq || []; (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();

Saturday, August 20, 2016

What are YOU doing to give back to the security community?

I recently posted the below on the SANS Internet Storm Center.

Someone has played a large role in helping us become inspired and motivated to develop as an information security practitioner. We certainly did not get where we are today on our own. Without a doubt, I have been fortunate to have learned from skilled security practitioners who have directly shaped my career growth - many may never fully recognize that impact. It remains a priority for me to lean into the direction of helping others grow and develop into the very best security practitioner they can become. A favorite topic of mine is sharing a lesson learned that quite often revolves around "from now I will always" and "never again will I" do that again.

We can all benefit from others successes and often times even more by others failures. There is absolutely no need to repeat the lessons already learned by others. By being intentional about growth, we can all improve and get wisdom as cheaply as you can.

Several ideas to get you inspired:
  • Ask yourself regularly "Who can I share that lesson with”
  • Establish an informal mentoring program at your $DayJob
  • Serve in the leadership of your local security group such as BSides, ISSA, InfraGard, ECTF, OWASP
  • Volunteer at your next local information security event 

What one thing can you commit to do next week to give back?

It Is Our Policy

I recently posted the below on the SANS Internet Storm Center.

How many times have you heard someone say out loud our "our security policy requires..."? Many times we hear and are sometimes even threatened with "the security policy". Security policy should set behavioral expectations and be the basis for every technical, administrative and physical control that is implemented. Unfortunately, solid security policies are often elusive for several key reasons.

I regularly get the question, "How many security policies should I have”? My response is often found by raising my hands and wiggling my fingers in the air. There is nothing magic about the number of security policies, my observation is that many times there are more security policies than are actually needed.  

One of the most important aspects of a security policy, just like the jar of mayonnaise in your refrigerator, is an Expiration Date. This non technical control can help facilitate regular updates to account for current issues being faced and capabilities that may not have existed when the security policy was originally created. Think of this as a built in process to ensure that it is regularly reviewed - consider a recurring calendar reminder.

Should your employees be expected to memorize all of your security policies and is that even realistic for them? I hope not for their sake. What if you redefine the win by each of your employees knowing where to find the policy when faced with a decision? A Central Location for security policies, versus being spread all over your company is best and can serve as the set of guardrails to protect both the employee and the company. This will serve as a key resource for everyone to go to when regular faced with a decision of "is this allowed or not in the security policy”. 

Finally, as you start to develop or even assess the quality of your security policy, there are several Key Stakeholders, often outside of the information security team, who can provide valuable feedback specific to their respective areas.
  • Human Resources - Because many times employee behavior is involved in an incident
  • Legal - Because many times employee behavior is involved in an incident
  • Privacy - Because sometimes personally identifiable information is involved in an incident
  • Information Security - Because threats against company systems and data are involved in an incident
  • Physical Security - Because sometimes an employee needs to be encouraged to leave as a part of an incident

Take a look at the SANS policy website and look for any any topics that may be missing in your organization.

All that said, what two things can you do next week to improve your security policies? Let us know in the comments area!

Russell Eubanks

Thursday, June 23, 2016

An Approach to Vulnerability Management

I recently posted the below on the SANS Internet Storm Center.

No need to do anything to make your auditor happy than to purchase the most popular scanning tool

No need to worry, when the scan is over and the report has been produced - you are all done

No need to ever leave your cube and speak directly with your system administrators

No need to ever test the scanner on a non-production network in advance

No need to worry, a clean scan means you are both compliant and secure

No need to ever leave your cube and speak directly with your application developers

No need to ever let anyone know when your scan starts, after all an attacker is not going to do that so why should you

No need to worry, if something becomes unavailable during a scan it is totally not your problem

No need to show good stewardship after the purchase by producing metrics such as the percentage of findings that have been fixed as a percentage of all the findings

No need to seek data that demonstrates your scanner could serve as a platform to improve your security posture

No need to keep your boss informed of your progress, s/he would not understand 

No need to divert any of your time from finding things to fixing things

No need to ever think that your scanning tool is every anything but spot on accurate

No need to hold back, it would be great if you shared your Vulnerability Management “best practices" in our comments section below

Russell Eubanks

Saturday, May 28, 2016

Applied Lessons Learned

I recently posted the below on the SANS Internet Storm Center.

What were those tough lessons learned that you will never forget and more importantly vowed to never repeat again? Especially those of you who have been in information security for many years and perhaps a member of several different teams. Consider yourself encouraged to remember those "from now on I will Always and I will Never again” lessons that were learned at your $OldJob.  

I remember all to well when I decided to perform a network scan from a new laptop. I was so eager to use the new equipment that I failed to record the MAC and IP address of this shiny new device. I tested it out and everything seemed to be great - until the next morning when an enormous amount of scan traffic was detected inside a sensitive network. Our teams went into full incident response mode in an effort to determine what happened. After learning “who did it”, the team was gracious in its response to me and none of us made that mistake again. 

To get you motivated for action, the following are a few ideas to consider.

1 - Never settle for “we have always done it that way”. Assume nothing by asking lots of questions, such as “When was the last time we compared the GPO to the written security policy”?

2 - Share regularly within your trusted communities in a way that does not put your organization at risk, but demonstrates you are still learning and remain willing to contribute. Don’t think that you need to share all of the gory details to make a difference with this approach. In fact, you will be much better off by leaving those out entirely. 

3 - Behave like the Fresh New Guy/Gal (FNG) regularly, especially if has been a very long time since you have served in that role.

By leaning into this approach, you can not only get wisdom as cheaply as you can but also and also help make our world a better place. What lessons are you actively trying to avoid learning over and over again?

Russell Eubanks

Saturday, April 2, 2016

Why Can't We Be Friends?

I recently posted the below on the SANS Internet Storm Center.

Now is the time for us to play match maker by setting our application and operating system owners up on their first date. We could call it Stake Holder Speed Dating (SHSD). In SHSD sessions, information security professionals can intentionally facilitate a closer relationship between two critically important, yet often times not very well connected teams. Application and operating system owners typically have much more in common than what each realizes. On their first SHSD session, several strategically placed questions could be used to get each team better connected by helping them recognize they should be together forever. Imagine if you will the conversation -

"So wait, you get notified in the middle of the night when bad or unexpected things happen on your systems? So do I! Would you mind adding me to your notifications? I bet it will help me know about potential problems on my systems ahead of time. That would be awesome and I can do the same thing for you as well”.

I see this as yet another reason to get up from our desks and walk around more. In addition to the positive health benefits of not staring at a screen all day long, it will also serve as a means to better "connect the dots” inside your own organization as well. The SHSD sessions do not have to be formal, in fact a brown bag lunch time session or perhaps an after hours get together could serve to foster these relationships quite well.

By exploring simple ways in which each team has a common interest, scenarios like this can be leveraged as a means to help each team understand how they can better help each other. Bonus points if they give greater insight to you as an information security professional.

We all benefit when realizing that we're all in this together. I encourage you next week to schedule time to pursue application and operating system owners in your respective organization. This simple act could very well facilitate a life long relationship that is beneficial for everyone. 

What success have you realized by nurturing the relationship between your application and operating system owners? Please share them in the comments section below.

Russell Eubanks