ComplianceOnline Interview with Michael S. Oberlaender: Practical Lessons for CISOs

Well, when I started working as a programmer, DBA, and software engineer (and later application software engineer) I had certainly not a CISO career in mind. I had programmed during school (and later university) and loved the technology and the new approach to solutions of math, physics, and then later (while working in companies) business problems. Even at that time then there were the first viruses and worms, so I took care of them via AV tools and similar. I advocated to management early on to have standards for AV, system patching, and backups. I also realized the need to configure the access controls both in the used applications as well as in the network and so started doing more and more "security related" work...

about 10 years later, in 1999 I started to work at Suedzucker, then the largest global sugar and frozen food manufacturer as Project Leader Enterprise Security - the CIO had realized my skills, knowledge, and potential and tasked me with securing the company's IT and information assets (note: at that time the CISO title was not common - but I did that work and was acting CISO). For over 5.5 years I have developed, designed, built, operated, and maintained everything for the security program: from policy and standards, over server hardening and patching, AV and anti-malicious code endpoint controls, to firewalls, network segmentations and DMZ, backups and software management, and even awareness for management and personal, just to name some. One of the biggest projects was the complete development and build of their DMZ and internet binding, and I am proud that my back-then designed high-available, load-balanced, multi-zoned solution concept and structure is still in place today (of course with certain updates). I then moved on to Heidelberg (then the globally leading printing press manufacturer) as Global IT Security Manager, relocated to the US, and was globally managing their entire security efforts (acting CISO) for 2 years, and then joined FMC Technologies as their first ever CISO.

The importance of the CISO role for any (!) enterprise cannot be understated, but to be clear, the issue is that most companies and organizations still don't understand that. That has to do with several aspects of the role: it is a highly complex subject dealing with human behavior, short-term business focus (making profit / creed), highly technical vulnerabilities AND threats, denial at the management layer (incl. C-suite and board), and the (unrealistic) expectation that this problem, that over 50 years IT / digital revolution have created, can be solved with a minimum spend on costs, investments, personnel, and change in process. The opposite is true. This is not going away, the sins of the past will cost organizations billions and trillions of dollars (I use this currency intentional), and they MUST change their business approach - but they don't want to. It is so easy to keep doing what you have been doing for the last decades..& it's insane however to think that doing the same thing over and over again will suddenly result in a better / more secure result. So, because the problem is not going away, the role of the CISO has received some more attention, and has been promoted - but still is in many cases (according to industry research between 50-75%) just reporting within the technology function, and not - as it must - to the CEO and board. The fact is, where the CISO reports directly to the CEO, the problems will be addressed and over time (and with the necessary money spent and process change established) significantly reduced.

This is highly dependent on each organization's situation and security status. If you work in a mature environment, you can focus on the more advanced threats, and find ways to maintain the robust security posture that you or your predecessors have built. You will have the organization, the processes, the technology and controls in place, and hence you can spend your efforts on optimizations and maintenance. However, that is *NOT* the norm. Most companies are hovering around a 2.5 to 3 on a CMMI model scale from 1-5. Check the media, it is full of the stories and for years the numbers of breached data records and respective fines are getting bigger and bigger. And certainly, read my new book - I am showcasing it in several cases and put things into perspective, before I explain and provide the solutions. So, let's say you start in a non-mature environment - then you have to do the ground work: build an organization (create job roles, hiring, people management, education, awareness, program planning, budget creation (which is likely an uphill battle competing for resources)), strategy and projects, architecture design, tool (automation goes a long way!) selection and implementation, metric definition and implementation/tracking, IR (Incident Response), TVM (Threat and Vulnerability Management), and running operations (SOC). All of that while there is zero support (management in denial - guess who was accountable), push back from the employee base ("I don't want to give up my admin rights", "I need to do the same nefarious stuff that I have been doing for the last 20 years", "who are you" (the latter I was really asked more than a decade ago), and minimal budget ("we need to spend the money on growth" - they don't realize that security is a business enabler or actually keeps you in business until the (in this behavior) unavoidable data breach(es) happen(s) and they get it demonstrated directly while the media is scrutinizing publicly the response)).

Well that is a loaded question, forgive my direct answer: yes, there are several compliance regimes, but compliance is not security. Compliance (whatever the regulation is) merely defines the lowest level a regulated entity MUST do to stay in compliance / business or get fined or otherwise punished by the regulator. Further, because the lowest level ceiling needs to be heightened (raised) over and over based on the continued breaches and snafus, so the controls become better and stronger with each new "version"(regardless if from PCI-DSS 3.1 -> 3.2 or from Directive 95/46/EC -> GDPR), you would have to adapt constantly if you would follow that compliance approach in your design. So, if you're smart and think ahead, the true approach to security is to do the right thing anyway for your organization, and not short cut it. So, you design your security programs and controls by thinking it through from the end - what is the outcome you want to have? Then you define and design those controls, and you protect everything (personnel, data, process, systems) to the best possible. With this, you almost (there might be minimal discrepancies over time) always fulfill the regulator's compliance regime automatically and can focus on those few differences. Otherwise, if you don't follow the best possible approach, you pay lip service to or with your outcome statement (or it sucks anyway and your customers run away). To the 2nd part of your question: via my network, alerts, the media, conferences, research access, being on or listening to expert panels, board & advisory seats

Board level support, CEO reporting structure, adequate budget and support, qualified (trained) employees both in security and other functions, sober process designs and implementations, proper technology architecture design and implementation (e.g. security by design - see my first book), world class operations (execution), and state of the art technology. Core concepts are explained in detail in my books and it would not do the subject any justice to just put bullet points here. Most importantly is to understand that cybersecurity is a continuous process and function - not a one-time effort or technology solution (alone). And further, the groundwork first: strict access control, data centric protection, encryption, backup, infrastructure etc.

Personally, the ENTJ type if you like or believe in the work of Carl G. Jung, Katharine C. Briggs, and Isabel Briggs Myers. If you "are" one of the others, know where you need to change your habits on the job. Of course, no human person is strictly just one of these 16 types, and honestly that would be very boring for a world of 8 Billion people. Most important: critical thinking, precise expression, strong communications, attention to detail, strong decision making (willingness and execution), deep technology understanding, business & political savviness, 100% integrity of character, robustness & coolness under pressure (daily anyway, but certainly when managing data breaches), good people and judgment skills, conflict capability, strong managerial skills, delegation, and follow-up. Persuasion or "selling" is certainly of advantage, too.

Seriously, read my books and other material - and then apply it. First, know who you are, then where you are (what sort of organization and environment), understand where the company wants to be at (or based on your advice should be at), and develop a plan how to get there. Each situation is different and needs a different approach, planting the seeds, nurturing, watering, and then the second round and so forth. Build strong relationships, build strong programs and strategies, execute those using tactics, and lead your teams and organizations with an impeccable spirit and hunger for a better future. Build new leaders, and when necessary, leave an organization to draw a line and raise the bar.

First, you need to become really good and strong at multiple topics, experience is not replaceable with anything else. Practice and theory together - certifications, and on the job experience. Don't follow only a linear approach - but with each new role, make sure you learn something new and towards more covering all the CISO aspects / skills that I had explained above. Build a success story, and make sure to focus on results. It doesn't really much matter what you were "responsible for" - what really matters is what you have really done and accomplished. Measure (!) your success. Also, don't be shy of hard work - success doesn't come overnight, but by continuously producing results, raising the bar, build your stairwell. Always seek feedback and improve your approaches, try out new ways, and learn from mistakes (your own ones and those from others).

IT Security is not information or cyber security - it is just the tech potion of it. A tactical approach alone won't serve you well (look up Sun Tzu) but you need tactics to score wins that provide one more step towards the goal. IT is a cyclical business - you have generations of chips / machines / and software that is using them. Centralization versus decentralization and deployment models like cloud or on prem are cyclical and under different terms and logos are coming and going. You need to adapt your tactics to the cycle you're in and when "cloud" is the current hype term then encryption, HSM, IAM, and CASB could be some guidance. When the next budget rounds comes up, you may invest into the latest TPM chips or then current slots. I am not a fan of biometrics because this is a major attack on privacy which I favor as an individual. You cannot replace your fingerprints, your hand geometry, your retina, etc. once that data is lost, stolen, copied, misused etc. Major influencers are overall market conditions (growth or recession), company healthiness (business situation), and leadership maturity.

Typical risks are: execution speed, time pressure, short cuts, lack of planning, lack of analysis, lack of design, lack of alternatives, lack of documentation, operational oversights / or even the automation of a badly designed process (read Peter Drucker's statement: "There is nothing worse than doing the wrong thing well.").
What should happen during digitizing or automating an organization's processes is to challenge if that process is designed right and then if so to challenge if the automation is secured against unforeseen, unintentional or even intentional changes (both parameters, input / output conditions, or sub-processes), and how the automated process chain can respond to such changes. The digitization requires controls that weren't necessary in manual or semi-manual chains because human intelligence / response was able to adapt on the spot. Machine Learning is not Artificial Intelligence.

It depends how early (the earlier the most impactful) the security team is brought in to that activity. We challenge the status quo, and we certainly make sure that short cuts are blocked / or taken back, and that the proper designs have taken place. We analyze not only the process chain, controls, and monitoring, but also the data flows, their parameters, and tolerance values (crap in versus crap out - we need to make sure that the received data into the process is defined, parameter-bound, monitored, and tagged/secured along the chain).

By becoming visible, accessible, being helpful (not roadblocks but rather road wardens that make sure the business has a secured and open road to run). This is rather easier said than done, and requires a combination of good judgement skills, prioritization, great communication, building rapport and support, and great execution. By guiding the business with guard rails, by showcasing how to do it right, by providing alternatives and better plans, and by clearly articulating the value that security lives by, provides, protects, and serves. Influencing is an important skill and treat..& if the business (regardless if "IT", "Sales", "Marketing", "HR", "Finance", "R&D", "Product Development", "Services", etc.) starts to ask security for their perspective, participation, guidance, advice, or support - then you have already won half the battle. Making it known that you're there to help, that involving you early provides better and faster outcomes (and make sure you do!), and that you're not "Dr. No" is a key goal for you in your role(s).

I use key words here - you'll get the point: Backups, Data Classification, Process Documentation and Design, Access Controls, Network / Cloud Segmentation, Encryption & Key management, Firewalls / Web Application Firewalls, Endpoint Detection & Response and Endpoint Protection and Prevention, User education and training / awareness, metrics and performance management, regular adaption to new threats (cyber intelligence) and new business challenges, strong incident response capability, robust and improved security operations. Also, once you have your controls in place to regularly check for next gen capabilities and when the time has come to upgrade. If you want to know the single most important one, then in my view that is full patch management. While there is no silver bullet, if you close your windows and doors, the attacker must at least use some effort to get in and cannot walk through the open back door (pun intended).

The right approach is what I call SecDevOps (see my book) - by making sure that the company / organization has a defined, implemented, followed, optimized, and monitored secure software / systems development life cycle ("S-SDLC") and making developers part of this process by providing them the training, tools and automation, follow up and security response times, and providing full support to make the(ir) management understand and adhere to that defined process. The change needs to be clearly planned, agreed to, properly rolled out, properly vetted, adapted/optimized where needed, and verified / monitored continuously - if that is all done well, security is now part of the pipeline - and can improve over time not only the results (less code vulnerabilities, faster and better (more robust) code), but even reduce the costs because it doesn't need to get fixed in production (or even at the customer's site/cloud instance). Over the years you improve the controls in that pipeline and mature it further.

By continuous adaption - let me explain. Instead of putting everyone and everything on hold you need to realize the pressing market conditions and business drivers. You may (actually will) not have all the answers, but you use an iterative approach, that is fine and perfectly acceptable - why? Because the business side is doing exactly the same thing. They don't have all the answers, and they try it out. If they are successful, they keep doing it, if not they change it. Security in such conditions need to respond similar and adequately - do what is possible and doable, even if it is only a portion of the end state. Newly discovered risks during that path will need to be addressed, and you then have a business case.

Great question - and you answered it partially already: INFORMED decisions - you need to get to a quantitative understanding of the risk which is hard but necessary. You first qualify it (like high-medium-low) and over time when you know your asset values / process chain values you can come up with quantitative numbers. Then you need to understand what the risk appetite of the organization (board and executives) is. The problem is that they often don't know themselves, and that is where the crux lies. Example: during regular business, these executives tend to think that they are immune to this, it won't happen to us, etc. So they state that it's okay to lose a data record or have an outage (they miscalculate the likelihood and think this is a far in the future event), and they won't give you the budget to prevent this from happening. In the moment the risk materializes (data breach, DC outage, etc.) suddenly their "risk appetite" changes and you have more money at your fingertips than you actually can spend in a smart way. However, if you can make them understand that risk is a product of likelihood AND impact, and it is smart to spend one million (or ten) upfront, to prevent the 100Million (or $1B) loss, then you know (or are much closer to know) which risks to accept and which to mitigate. Another example: it doesn't make sense in most cases to secure the assets worth one million dollar (in asset values and fines if any) with a control that costs you $500k. Pick your battles.

By a.) understanding that value chain, its different steps, processes, functions, and parameters, and then b.) securing those components and values (see for example the S-SDLC as described above, but the same applies to non-software process chains, think for example NDAs in legal or providing your SOC2/II results to your customers). If you apply "end-to-end" thinking and eliminate shortcomings in the business value chain, you contribute to the longevity of the business, and become that trusted partner that you (want and) need to be. Another important aspect is the proper business continuity planning - and here most businesses fail squarely - as the recent Corona virus pandemic drastically shows unfortunately.

As I have shown in my book the (security) industry tends to not learn from its mistakes, and with the next wave, be it IoT, ML, AI, or whatever, we make the same mistakes all over again. Shortsighted business focus on fast money, innovation without governance, and turf wars with lack of integration. The security industry is full of vendors that think they have the silver bullet, which they don't, and who omit the important concept of common standards, languages, tool integrations (open APIs), and best practices. Reaping the existing install base out to place your own products is not convincing to the CISO or security team, and vendors need to understand that foremost the customer's business goals are more important than your products and services. I have described how to approach and work with the CISO, and I can only recommend to any vendor, sales rep, product developer or CTO to apply that advice. Security has been for eons a cat and mouse game - new defenses have created new attack vectors/methods, and vice versa. The next cyberwar is already happening (at least in its "mobilization phase"), and unless we drastically change our learning and adaption methodology there won't be a winner.

Thanks for joining me. Your responses are extremely valuable.

Thank you Stacey as well, it's a pleasure and I am glad to share my expertise with your audience - I encourage that more young people will take a career in InfoSec & CyberSecurity - the opportunities are almost unlimited.