Please consider donating:


CSO : Common Sense Operator/Operations

As the CSO/CISO/person responsible for Information Security, your job is to…  well … do you even know?  Does upper management know? 

"Our crappy CSO …" and "Our stupid CSO …" are statements commonly used by various (techie) people, throwing their hands up in despair, attempting to prove that their CSO doesn’t understand technology and has no idea what he or she is doing.  Point taken, some of the CSO’s/CISO’s I know don’t have a background in Systems Administration, System Engineering and have no hands-on experience with Information Security work.  At the same time, the CSO position is often driven by a need to be compliant to X and Y and by business economics/priorities (growth, revenue, stability, performance, etc). Even though the CSO may understand the need for a Risk Management based approach, including all bells and whistles, his or her problem may not be around failing to understand "what he should or shouldn’t do", but about "what he or she is allowed to do".  It doesn’t make the CSO stupid, life is not that black and white, but if he or she fails to share these constraints with co-workers, he or she might be badly understood in general. In order to still achieve certain things in a pragmatic way, it might help if both CSO’s & tech people try to take some steps to close the gap between technology and business requirements.  Or, in other words, it might help the CSO to do the things that *should* be done, without compromising the business goals.

I started my career as a Systems Administrator, Systems Engineer and Network Engineer more than 15 years ago.   Information Security was just a "hobby" and wasn’t added to my responsibilities until later.  I became the CISO for a pan-European company 2.5 years ago and I must admit, I have struggled to make the transition from being a techie to working on less techie stuff.  In fact, one of the things that can be quite difficult as a former-techie-now-manager, is when you realize that a certain defense measure won’t be 100% effective because you *know* that there are ways around it.  At the same time, it’s still a good idea to apply the defensive technique because it’s better than doing nothing. Putting things in perspective, we’re merely trying to implement various layers of defense, in an attempt to make the life of a criminal as hard as possible, in all phases of a potential attack.  In this short blog post, I’ll share some of my experiences and I’ll try to provide my 2 cents on some of the things you can do to make your environment more secure, by applying common sense. 

Why are we here?

First of all, people working in IT and Information Security should wonder "why" they are part of the company.  "Making things secure" is a pretty vague answer, and can be overwhelming at the same time, because there are "so many things" that are not secure yet, and seemingly cannot be secured because of "Business Priority A or Business Decision B".   Instead of complaining about it, we can try to figure out what exactly it is that the company cares about, and how that translates into IT or Information Security.   If your manager can’t tell you what part of your work is important for the company, perhaps you can find out for yourself:

1. Check the company vision & mission.  Companies often post a mission statement on their website. Find it, break it into pieces, and check how/where "Information Security" would be important/applicable to reaching those goals.  Example: :  "Google’s mission is to organize the world’s information and make it universally accessible and useful".   This statement includes "Organizing information", "making information universally accessible" and "making information useful".     Those 3 pieces are "functional requirements" and don’t seem to be about "security" at all.  In fact, you probably won’t find "secure" or "security" in any mission statement (unless the company is delivering security solutions).  In any case, these "functional requirements" are what the company cares about.  This is what generates revenue and this is what makes sure you get paid.  If your actions will cause a negative impact on one of these 3 things, you’ll find yourself looking for a new job soon.

2. Identify IT components needed to achieve the company vision & mission.  If you know what IT components are necessary to reach the goals, you’ll know where to focus on when implementing IT Security measures.  In other words, you’ll know what is important and why it is important.   "Information" often means "data", so perhaps the company wants to make sure access controls are implemented.   "Universally accessible" means that you probably won’t be allowed to prevent people from accessing the data when they are authorized to do so.  At the same time, there may be a need to block access in certain cases.   

3. Establish a solid baseline.   Aside from implementing security that directly affect/support the company vision & mission, you’ll need a solid baseline that may be driven by ISO/Industry standards, legal requirements (compliance) or just common sense.  This is the grey zone that often causes frustration because people either try to do too much, or don’t care enough about.   Making sure your IT systems have a reasonable level of security, good enough to prevent an easy way in for criminals, but without spending too much money and certainly without disrupting the company, is important.

Putting things together: If it’s the company’s desire to "get somewhere fast" (mission), perhaps they want to use a fast car to do so (IT component), and it’s your job to make sure it has an airbag, the brakes function correctly and that it doesn’t leak fuel (baseline). Furthermore, it’s in the company’s interest to make sure the car drivers know how to operate it correctly and safely (training & awareness).  Whether it needs collision detection and automatic brakes or not is up to the company and shouldn’t be your first priority. Remember this, and take some time to review the company vision & mission on a yearly basis.

Anyways, in this article I’ll try to provide some ideas about this baseline and what you can do to improve the overall level of security using some basic, effective steps.

How/Where do we start?

1. Positive attitude

Whether you like it or not, success heavily depends on your approach and your attitude.   Instead of focusing on problems and poisoning others by telling how "broken" things are , try to take those "problems" as facts, as challenges and find creative, effective and ideally low-cost ways to mitigate those "problems".  There is no such thing as perfection, so stop wasting your energy on negativity. Try to be positive and accept that technology changes and security is a process.  There are so many things that can be done, let’s start with the basics first.

2. Common Sense Priorities

Instead of buying the latest "Next Generation" Appliance that features blue, red, green, yellow and (woo-hoo brand new) black leds, you have the choice and opportunity to focus on things that may be even more effective and may cost less.   In the first 2 years as a CISO, this is what I did:


It’s important to explain to your peers, IT and Business partners that you understand what is important to the business and that you will try your best to avoid an impact to the business processes.  People care about functionality and performance, so keep that in mind.   At the same time, Information Security usually has a negative image in a lot of companies, and it’s hard to get rid of that image.  A possible way to change that image is to convince people to allow you (Information Security) to become part of new projects and initiatives at an early stage.  At the same time, do you very best to make sure you’re not slowing down the project/process at that time.  If you’re building a car, it makes more sense to implement the idea of having airbags at an early stage.   If the company has to do a recall on hundreds of thousands of cars so they can add the airbags afterwards, guess what, they might blame you.   Explain that you are committed to making sure they can deliver in time, and that you want to avoid slow downs and problems at the end.

Be Pro-Active

Take the time to listen and talk to people.  Ask how the business is doing and listen to what they have to say.  If you hear rumors about new initiatives in the hallway or if you happen to pick up ideas from people at lunch or during a coffee break, try to come up with an approach to help facilitate those new ideas rather than coming up with reasons why the new idea won’t be secure.  Be an early adopter, set up a proof-of-concept within the IT (Security) department and then try to convince "key" people in the organization that your approach does work.  Also, most managers don’t like to lose an argument. Every time you take something away from them or give them a "No", you’ll need a series of "Yes" to convince them you are still on their side. 

Increase Visibility

You can’t fix things if you don’t know what is going on.  At the same time, it’s easy to get buried under alerts and information if you don’t do things right from the start.  This means you need to understand how the network and systems are laid out and identify what you really care about.   Do you really care about a million port scans that happen each day on the internet? Do you really want to see the next wave of mass SQL injection scans if you’re not hosting a website?  Perhaps knowing what traffic leaves your network may be more important.  Or maybe you want to know what happens to the "keys to the kingdom".  These are some ideas:

– First of all, agree on a protocol to report issues and stick to it.  Increasing visibility means that you’ll get a bunch of alerts, and some of those will need somebody to take action.  If IT wants you to report everything through their helpdesk, then do so.  Let them decide on how they want you to report issues and try to avoid using "Urgent" unless something is really "Urgent".  The fact that you’re getting alerts only means that your capability to detect things has improved. It doesn’t mean that things got worse.  Don’t use it to point fingers at someone or to show how bad things are. Avoid personal attacks and show that you are the same side of the table and want to work on solutions together.  Allow IT people (outside of security) to look at your dashboards, so they feel involved and can even react/respond before you do. In any case, try to work together with IT, from the very beginning. Behave the way you want others to behave.

– Locate important network entry & exit points.  (i.e. geographical/country network connections, internet access, intersections between network segments that have a different level of security) and implement simple IDS to look at internal traffic, and at internal-to-internet traffic. Stay away from internet-to-internal traffic first, you can still add that capability later. Make sure all events get logged in a central database. Don’t just enable all monitoring at once, but take a phased approach.  Enable monitoring for a certain type/class of events and analyze the results for a few weeks.  Tweak the rules, so the number of false positive events would be close to zero, before enabling a new set of rules.   If you feel like hosting a low-cost solution yourself, take a look at Snort / Snorby. It’s not perfect, but it works and it will increase visibility.   Also, explain to management and the network guys that the IDS is merely listening to traffic.  Show them that the IDS host is connected to a "monitoring" port and not "in-line", show them that it won’t degrade network performance and that it won’t be a single point of failure.  Demonstrate that you are aware of their concerns and that you are committed to making sure everything works properly.

– Identify who has administrator permissions on your key systems and monitor the use of those accounts, and/or monitor the group membership that would lead to gaining administrator permissions.  Monitor account changes (account lockouts, password changes) of important accounts.  If a server-specific service account is used on another machine, you should know.  If an admin account is used to access emails, you should be aware.   Windows Server/Active Directory has the ability to perform detailed event logging and you can use simple powershell scripts to export events and filter them.  If you have a bit of budget, you can take a look at auditing software such as "Netwrix Auditing Suite", which will make your life so much easier. 

Think about what you want to see and monitor before implementing tools.  If a tool doesn’t do exactly what you need, challenge the vendor/developer; or write something yourself.

Set up a formal User account lifecycle management system.   Start by identifying user accounts that are no longer active/unused and/or user accounts that have high privileges.  Clean up unused accounts and see if you can convince HR to report the names of people who have left the company on a monthly basis.  At the same time, continue to run a script that identifies accounts that are no longer used and make sure they get cleaned up in the end.  Make sure IT admin passwords are changed (faster than other accounts) and change important IT admin passwords if somebody in IT leaves the company.  Adopt and apply high standards to yourself.

Decrease risk

Only when you have a good understand of what is happening on your network and systems, you’re ready to make some changes. I think we all agree that changing things doesn’t come without risk and people may come up with both good and bad reasons why you can’t make changes.  Plan ahead, make sure to test changes properly and apply the changes to yourself long before forcing them onto someone else.  If things don’t work well for you, they won’t work for other people either. Don’t give people a chance to state "it won’t work" by trying it out first, and trying it out in a realistic setting, using an environment and application set that resembles the environment of everyone else. Finally, even if the company does not have a great history of testing changes or change management in general, be professional and apply high(er) standards to yourself.  Keep in mind that anything you do can be used against you.

Simplify the administration model: There is usually no reason for IT people to use a user account that has administrator permissions for day-to-day work.  I have designed, implemented and operated large and complex Active Directory topologies in the past and there usually is no reason for anyone to be a Domain Admin or Enterprise Admin.   Most, of not all, of the work can be technically delegated to certain accounts.   Additionally, to make sure IT people understand the frustrations of end-users, they should use a regular end-user account as well, and only switch to a user account with higher privileges when needed, and for the time needed.   If they are reluctant to do this, they probably know something in the environment is not set up correctly, preventing them from doing their work, which means some of the end-users are facing the same issues. Additionally, explain that if their account gets compromised, the impact to the entire company would be a lot higher.   Tightening the administrative model is not without risk, so you really need to be well prepared to make changed to the environment and make sure you’ll never run into a case where you’re left without administrator permissions whatsoever.  At the same time, it would make sense to implement a split-secret password technique for the "keys to the kingdom".  Save both parts of the password in a safe and make sure you always need 2 people to be together to use the most dangerous/powerful accounts.

– Simplify the network topology:  If you simplify the network, for example limit the number of internet gateways or entry/exit points in general, you’ll also improve your ability to monitor and to apply protective filters.  Forcing the use of a cloud proxy, for instance, will make it easier for you to filter out certain attacks in a centralized way, without forcing roaming people to connect back to the company first, wasting a lot of bandwidth, to access the internet.   Try not to be too restrictive on what people can do, but focus on blocking obvious threats.  If HR wants to apply additional filters, let them handle and communicate this. Don’t be an advocate for restrictive content filtering unless there’s a clear security reason.

– System hardening: Aside from performing proper system hardening, consider deploying EMET to your PC’s and maybe even your servers.  EMET is a great tool that significantly increases the difficulty level for criminals to exploit memory corruption bugs.  It’s a free utility, supported by Microsoft, and can be managed centrally.  (You can even deploy it using Active Directory if you don’t have a full blown software management suite)  Yes, it has some issues; and yes, it needs to be tested on all of your applications, but issues can be whitelisted and in the end, things will work.  I have been using EMET for more than 5 years now, without nasty surprises.  Of course, EMET (or other structural defense mechanisms) is not perfect and *can* often be bypassed. Offensive research is necessary to keep pushing the limits and improve the quality and maturity of defensive techniques, but at the same time, we also have to admit that it usually just takes less efforts to prevent the latest bypass than the amount of time it took to perform the research.

– Standardize and patch:  Identify what software the company is using and determine the standard set of applications. Evaluate how easy it is to patch the applications and look for alternatives when needed/if possible.  Make sure patches are properly tested, even if that means that you can’t deploy a patch the same day it was released.  It’s better to deploy a patch 2 weeks after it was released than to deploy it without testing, blow up the environment, and never be able to patch anything again.   If you have to install all kinds of less common applications, check if they are compatible with EMET and make sure they are protected by EMET.

Segment: Group networks and users into entities that have a similar behavior and trust level.  Create a security profile for each entity and implement protection mechanisms based on those profiles.  We all know that C-level executives, managers, sales, marketing, HR, etc…  have different needs and want things to be aligned with how they work. Not everybody is equal. Don’t fight it, but embrace it and figure out ways to make it happen.  It’s better to have multiple security profiles than to have no security applied to a group of people.  Focus on increasing visibility for the cases where you have to be more permissive.

– Centralize management: If you centralize management of networks and systems, it becomes easier to apply the same rules and standards to the entire environment.  Even if it’s hard to achieve at first, you can try to find quick wins and, for instance, try to convince IT to take control over all public DNS records (instead of letting Marketing and other people manage this).

Mubix put a great presentation together, called "Attacker Ghost Stories: Mostly free defenses that give attackers nightmares".  This is a fantastic example on how to apply simple (free/low cost) changes, significantly increasing the barrier for attackers to own your network.

Effective User Awareness

Ah, good ol’ user awareness. One of the most popular statements in Infosec are "people click stuff" and "there’s no patch for human stupidity".  Well, yes people click stuff. They do. But guess what, it’s not because they are stupid. I believe a part of the reason why it is still trivial to convince people to "click stuff" is because we (Infosec) are not trying hard enough.  Instead of impressing girls and boys at the bar on how good your Social Engineering skills are, why don’t we use them to teach people and give them a good reason not to click just anything.   Instead of yelling at people or making fun of people, we can also try to be positive and give people incentives to do better at security awareness.   If you tell your users you’ll buy them a beer if they report a suspicious email and it appears to be malicious, maybe they’ll remember that next time they receive an email.  Or you could buy them a beer if your "password change" audit report indicates that a given person has changed his/her password 4 times a year.  I’m sure you can come up with even more creative ways to give people a good reason to behave differently.  Teach in a positive way, reward them for doing the right thing, and yell less.  They’ll remember and they may even change their habits.


Of course we need to audit to check how effective our measures are.  I usually rotate audits between internal staff and externally hired pentesters.  I even rotate between external companies to make sure different people look at the environment.  One of the criteria I use when selecting an external pentester is their ability to put things in the correct context, which is directly based on their experience with designing/building/implementing systems and networks, rather than just auditing them.  As your security improves, the harder it becomes for auditors for find issues, or the more complex it might be to fix issues.  Make sure to select a partner that has experience with fixing or containing issues too, and does so in a pragmatic way.   If you get a report, read it, give it the attention it deserves, and ask the auditor for more info or help if something is not clear.   Finally, even if you don’t have a team of pentesters, it still makes sense to train your IT "builders" to learn how to "break" things, so they can set up things in a secure way. The same applies to the "breakers".  Try building an entire environment, including monitoring and management, to understand how hard it is.

Hope for the best, Plan for the worst

Finally, bad things will happen, intentionally or unintentionally. That’s a fact.  No matter how good the latest audit report was, we have to understand that things change and that nothing/nobody may be ready for a persistent, targeted attack.  We don’t control certain external factors either (environmental issues, etc), but we have an obligation to make sure the company can recover and resume operations as soon as possible.

Putting a business continuity and disaster recover plan together is a tedious job, but in the end it’s based on a couple of basic principles:

– Don’t rely on others.  You, your company, are the only ones who can decide how important certain systems are.  Make sure whomever is responsible for hosting/managing your systems understands your business needs and implements real mechanisms (backups, high-availability, fall-back techniques, procedures, documentation).  Maintain an inventory of what is important to the business, identify how critical a system is (ask the business) and implement techniques accordingly.  Be pro-active, don’t wait until it’s too late, but don’t overdo things either.  Be pragmatic and explain to the business what you want to implement and what the result will be.  If they agree that a system can be down for 3 days and they can afford to lose 2 days worth of data, then there may be no need to implement expensive clustering and 4 hour backup schedules.

– Don’t rely on an SLA.  If you have outsourced some of your operations, verify that they are really capable of surviving incidents and will be able to recover even if things blow up.  Keep in mind that an SLA is only there to protect them, not you.  An SLA is like an umbrella.  It will avoid that your partner gets wet, and you’ll still fall off the cliff, realizing that you really needed a parachute.


Key Performance Indicators (KPIs) are a set of measurements that allow you (or management) to determine the state of something and draw conclusions.  As a manager, you’ll probably get the request to deliver (and meet) certain KPI levels, and if you’re into IT (Security) operations, a part of your work will be used as the basis for these KPI’s.  Defining good metrics is important because the results are usually what gets communicated to upper level management and may even be used as part of your objectives.  If you let other people define the KPI’s, you’ll end up with stuff like "gather the amount of viruses detected and compare with last year". The reality is that we are only partially interested in stuff like that.  In fact, what I really want to know is how many viruses went undetected.  In any case, when putting KPI’s together, it’s important to come up with a reason "why" you want to gather a certain type of information rather than just collecting figures and numbers.  If you really want to prove you’re improving security, make sure you come up with interesting, innovative metrics and not just figures that don’t mean anything.   One of the books that might help you defining good metrics is "IT Security Metrics, A Practical Framework for Measuring Security & Protecting Data", by Lance Hayden.  A second great resource is "Key Performance Indicators, Developing, Implementing and Using Winning KPI’s" by David Parmentier.


These were just a few examples of what you can work on to improve a basic level of security, without spending large amounts of dollars on appliances. Certain appliances definitely have certain value, but only when you already have the basics right and are ready to configure, maintain and operate them. 

Anyways, what is listed here is not perfect, it’s not the holy grail and it doesn’t have all the answers.  After all, I’ve only been a CISO for 2.5 years, but I’m convinced taking some micro steps and working on layered defense is definitely better than not doing anything.  Furthermore, when the basics are done right and the business understands you’re trying to make sure everybody can work and collaborate in an efficient way, you’re building up credits to implement even better things.

CSO’s: listen to your people, techies: listen to the business and your CSO.  Find common goals, educate each other and work together.

Of course, there are a lot more good ideas out there and I welcome you to share them with the community, so we can all learn from your experiences.  So before you start writing a blog post on why I suck (I already know) and everything I wrote here sucks even more (yep, that too), please take the time to come up with some good ideas as well:)

© 2014, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.

One Response to CSO : Common Sense Operator/Operations

Corelan Training

We have been teaching our win32 exploit dev classes at various security cons and private companies & organizations since 2011

Check out our schedules page here and sign up for one of our classes now!


Want to support the Corelan Team community ? Click here to go to our donations page.

Want to donate BTC to Corelan Team?

Your donation will help funding server hosting.

Corelan Team Merchandise

You can support Corelan Team by donating or purchasing items from the official Corelan Team merchandising store.

Protected by Copyscape Web Plagiarism Tool

Corelan on Slack

You can chat with us and our friends on our Slack workspace:

  • Go to our facebook page
  • Browse through the posts and find the invite to Slack
  • Use the invite to access our Slack workspace
  • Categories