I found out I am dealing with InfoSec or cybersecurity for over 15 years with more than 10 years professionally. This means at least two things – I have seen quite a few things and I have a lot of blind spots.
In my journey to uncover these blind spots, I asked my peers, colleagues, customers, and friends how do they see security, what we are doing wrong and about their experiences. It is a very broad and open question for a distinct group of people – from CEOs, CIOs, CSOs via risk management, HR to software developers and pentesters.
I compiled those answers and ordered by a number of “complaints”.
User experience sucks
To hear complaints about quality of user interface (UI) and user experience (UX) of security tools is something I was not expecting. Seems like we, as a security community, got quite accustomed to bad UI, inconsistent dialogs, laggy interfaces, and misleading names. I wanted to oppose but then I took a look at how junior or newbies are working with tools like SIEM, vulnerability scanners and… Just visit User Inyerface to check how many bad patters you will spot in your tooling.
How to fix bad UX and quality of UI of tools?
When you are designing something, please think about your users. I know it firsthand. I am really bad at designing interfaces. That is why I always hire someone to do it for me. If I do not have a budget I find the most junior person from my user-base and watch them accomplish typical tasks people will do with tool. If you are creating a vulnerability scanner, watch them how they create and execute a new vulnerability scan. If you are creating ransomware protection, ask the junior end-user computing administrator to deploy your tool. Write notes. Don’t explain why UI works certain way. If you have to explain UI, your UI is probably bad. There is difference between complicated and bad, ours are mostly bad.
Although responses were mostly oriented towards vendors and tooling. Internal InfoSec guys have no worries, there is space for improvement for you too. Did you look at your board reports or dashboards? Have you ever thought how much technobabble are you using in your outcomes? Or do you even directly export data from SIEM and create a report for board? And do you wonder why board is ignoring you?
This answer came mainly from non-expert and non-security people. In general, most objections might be translated:
To buy security products or services I have to be a security expert first. To hire the right security person, I have to be a security person. It does not make sense.
This means we do not know our customers and we do not understand them. When I asked more I found out most products and services are perceived as a snake-oil. Our customers hate fearmongering. I do not get how can most of the security industry sell-by fear and when I ask CISO or CIO they will immediately tell me this is the thing they hate most.
There are not clear processes and expectations management for customers – either internal or external. In most companies security is seen as disabler and not an enabler. When wrapped up, security is providing really bad customer experience.
How to fix a bad customer experience?
Just know you have a customer and accept there are stakeholders. It might be your board, CIO, users in your organization. Design your processes and playbooks around customers, not your problems.
Here goes one pro-tip: if you hear complains like: “security is only bossing people around” try to help them instead of bossing them. I am not saying you are not useful, but you might not help them personally. Visit your users, discuss their issues, give insights and shift from default to no mindset.
If you have junior staff, you want to train in dealing with end-users create open door Friday and let know people in your company they can visit you every Friday with personal computer security issues. You will get to know each other and help them. There is a secret benefit for your organization too – every problem on user computer is sooner or later be your problem. Remember ransomware? Someone will bring it on USB stick.
Customer experience in the security field is a big topic and I am still researching this area. If you see yourself as a customer for security please get in touch and help me research this topic!
Maybe your company is hiring growth hackers, development teams are closing bugs blazing fast and delivering features with speed of light. You have gone full DevOps, Agile way. Doing whatever is cool these days – be it microservices, serverless, No-as-a-service.
What are security guys doing? If you are a security professional, did you help to scale security with the rest of the company? Integrated static and dynamic analysis into CI/CD? If you work securing industrial control systems, did you help to set up a manageable process for testing new releases of firmware? Are you ready for getting connected ICS to corporate network because digital, IIoT or whatever is fancy now? If you are developing software, do you have automated fuzzing in place? With an emphasis on scalable, automatic and predictable?
Fear not, it is not about people only. Our tooling does not scale too. Licensing is per application. If you deploy 1000 microservices, is it 1000 applications? Or we have one application consisting of 1000 microservices? Can you spin 200 instances of
How to scale security?
It is simple, yet complicated. Automate. If you are doing a
If you are assuming, you are doing boutique-niche service like red teaming and don’t need to use the power of automation, you are still wrong. Deploy C&C infrastructure automatically, when bad guys can scale by DevOps tools, you can too.
Ignoring CI/CD pipeline
This objection is more about software development and less about operations. The two biggest groups I work with are software development-based companies and industrial or utility companies. There was traditionally a big gap (and still is, but closing) between these groups in the speed of releasing. In a software development environment, releases were in days and this shifted towards hours. In an industrial environment, releases were in months and now they are in weeks.
If I make average from responses I can say almost 50% of our customers are releasing on a daily base, 25% on a weekly base, 10% on a monthly base. Of course, the manufacturing floor is not releasing on the same schedule like mobile app producer but still, shift towards speed is obvious.
However, these two big and distinct groups have one thing in common – security testing is done quarterly if at all.
When I asked why development and testing are not aligned, over 90% of responses were due to a lack of resources on the security side. This seems like the same scaling problem described above right? When I looked closer on the issue I found another, different issue. It is a more philosophical issue – security sees itself as verification and wants to be the gatekeeper. DevOps or field operators in the case of ICS want to see security as an organic part of the process.
Stop ignoring the delivery pipeline
There is nothing more to say. Yes, security has a gatekeeping role but it still does not mean we are an ivory tower in the organization. We, as security professionals, want to have insight and ability to respond adequately and this is not done by gatekeeping only. We need a hands-on approach. If you are ignoring the delivery pipeline you don’t have a hands-on approach. It means you might be more burden than an asset.
Lack of talent
This was a one-voice response from CEO’s, CISO’s, HR and consulting friends. There. Are. No. People. We are spending so much money on the cafeteria system, HR, employer branding and bonuses and nothing. I did a little experiment. I downloaded job ads from the company websites of my respondents. And then I sent it to them with the question, if they know someone who fits these descriptions. Few quotations:
I do not know unicorns.
Jesus died 2000 years ago.
Sorry, I already have a job in 10 years if I will be studying for 10 hours a day.
These are the three funniest responses. What was not so funny (at least for my peers, I had a good laugh) was letting them know I took job descriptions from their corporate websites.
How to win talents?
Don’t win talents. Grow people. Take a developer and train him or her for the AppSec role. Take sysadmin and teach him how to be a threat hunter. We all should stop looking for unicorns. If the military can take Average Joe and make him skilled enough to not die on the battlefield (this is your organization), be able to use weapons and operate heavy machinery (this is your tooling), we can do it too. But first, maybe stop looking for 10x engineers, create a training program and at least know whether you are looking for a generalist or specialist and team leader or individual contributor.
Over the last few years, I started to look at security as a subset of quality. Good product (or organization, company, whatever you are doing) must be secure to have good quality. To achieve quality, you need to have a roadmap – to know where are you going and prioritize to differentiate what is important and what can be omitted (what does not add to quality).
This sounds very simple and it should be project management 101, but I did not see this in almost any organization. Mostly, security was overwhelmed by repetitive tasks (see vulnerability scanning), checklists for compliance or investigating “incidents” in SIEM. I usually ask how is the security department going to look in two years, what tools and processes will be in place, about education, I either did not get any answer or super long wishlist without priorities. Both are wrong.
How to prioritize?
This is not rocket science but still, I do not see it implemented often. CSO or CISO should know the business goals of the organization they are securing. I was very surprised when CISO of the company I worked with was not informed about the acquisition and was only told they will be merging codebases to integrate products.
And at the same time, most of the product or CEO guys I asked could not tell a security roadmap for their organization. This means you are making each other job harder. Take a look from their side – they do not know your expectations. If you come with a request they will default to No.
Either, the group I asked is so advanced they could just operate and there are no fixes needed or there is a communication problem.
Do you have a security roadmap you can share with your peers and superiors?
These were six most often mentioned issues with security and helped me to see through my blind spots. I did not realize our tools are so unfriendly, our communication is unclear, we do not know how to prioritize and present priorities. That problem with people might be a problem with our unrealistic expectations. I hope my colleagues, peers, and friends will not block my number and mail. Because I am going to compile feedback we all should ask for.
What are your thoughts? Agree or disagree?
Jozef Mareš, founder and security expert