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?

Customer experience

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!

Scaling

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 fuzzer to test in parallel?

How to scale security?

It is simple, yet complicated. Automate. If you are doing a pentesting and not utilizing a DevOps approach and, for example, deploying testing machines by hand, creating a test environment by copy-pasting commands instead of configuration management. Well, then you are doing it wrong. Security won’t be solved by putting more bodies into the security department. Firstly, there is a lack of workforce. Secondly, you do not have the budget to scale manually. And most importantly business will outgrow you to irrelevance.

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.

Prioritization

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?

Conclusion

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

The post 6 biggest security pain points​ appeared first on Rolken.

There are multiple reasons why you want to use red teaming but let’s curb the first enthusiasm and set a little bit of the expectations:

• there is no magic going to happen – a blue team and a red team have still to work security out and it is going to take time;
• everyone is unique and it is not sufficient reason to do red teaming just because everyone is doing it;
• the bad red team is worse than no red team – starting with red teaming is more about culture than results. The bad red team is going to move your culture at least one year back.

When to use red team

When you have basics done. These basics are: you have staff, you are able to monitor at least the network level, and you think you can respond to incidents. This carry you did at least these things:

1. an asset inventory and you understand your landscape (where are devices, which firmware your switches have, how many access points you are operating, how many unsupported windows XP you have etc.);
2. centralized logs and network monitoring;
3. you did basic hygiene – regular vulnerability scanning and penetration tests;
4. and fixed pentests and vulnerability scans outcomes and documented what could not be fixed. And you are monitoring the weak points which can’t be fixed.

You don’t need to have fancy tools like an anomaly monitoring, SIEM, security automation etc. In our experience, the motivated team of juniors with open source tools would give us way harder time than just one person with many fancy tools.

How to use red team

There is the sole purpose of a red team – to improve a blue team. It is like vaccination – if you want your immune cells able to react properly to a real adversary, you need to expose them to one in a controlled environment. Also, practice makes perfect and worst time to practice is during the real crisis.

There is another important thing to consider and it is continuity. You want continual improvement of a blue team and to achieve the continual improvement you need to do regular exercises.

Pro-tip:
This is how you can differentiate between bad and good red team. For bad one an objective is to hack you all the ways up and down. Good one focuses on the tested part and on skills transfer. During retrospectives, we often find the distribution of time is 40% testing, 20% recommendations, 40% skills transfer to the blue team.

What does it mean to win?

Our approach is “if we win, we lose”. A side note: we almost always win. The good thing is we tend to win using a different approach compared to the last engagement. Our payloads from last time did not work? Very well! Physical security caught us? Good. Immediate detection of scanning? We are very happy.

If our tricks from the last exercise did not work it means we did our job well and a blue team have improved. Bonus for us: we have to improve too and make another clever way to overcome a blue team countermeasure.

Simply put, we are iterating together to moment when we have to say, sorry there is no way how we can attack you.

In-house vs external?

Let’s speak a little bit about quality. In red teaming there is a correlation between quantity and quality in term there is no single person red team (that is why is it called team). Red team by definition is a team consisting from people with various skills. From security assessment via development, social engineering, physical security to business analysis.

This means if you do not have a budget for at least 3-4 persons there is almost no point in making an internal one. Your blue team will benefit more from less interaction with a good external party than from more interactions with a less skilled internal team.

It does not mean you should not have someone responsible for interaction with a red team and organisation of red teaming activities. But it could be a manager of a blue team – in the end, it is this role which strives excellence of his team. In our experience, we delivered the best results when on the other side was a technically competent project manager. Often it is pentester or security analyst with people and project management skills.

Decided to go for the internal one? Try to understand who you are hiring and what they are going to do. You can start by reading Red Team Field Manual and Blue Team Field Manual because you’v got to have defenders first.

TL; DR

Red teaming is less product or service and more cultural change. To embrace this cultural change you’ve got to know when and how to do it and understand nuances and motivations (what you want to achieve and what is on the market).

To succeed and implement red teaming into your organisation fix basics at first (assets, vulnerabilities, pentests and countermeasures), communicate with a blue team and let them know you want to transfer skills from red to blue not test and catch them with pants down. Decide on the best approach – whether you have enough resources to build internal one or you are going for the external route.

The post Red team explained appeared first on Rolken.

In general, as the red team, we are almost always on the winning side. But why? Are we so much smarter than the blue team? Or is it because to defend is harder than to attack?

To answer the question, why is the red team significantly more successful, we performed a short analysis of the assessments aimed at assessing the difficulty of obtaining protected data. Based on the analysis, we present three basic, continual activities of the blue team that significantly reduces the red team’s success.

Time for “spring clean-up” or do you know your assets? Red team does!

Even thought you would like to, it’s not necessary to immediately throw away all old apps and systems on long time forgotten servers. But, do a “clean-up” in your assets inventory. We know, setting up new vulnerability scans and finding new air gap vectors is more fun. However, this attack vector is complicated. In a real world, we are going to find an old web application purchased by the marketing department for a campaign finished three years ago and exploit it. It is always “the low hanging fruit” first. Remember we are doing for your improvement not a conference show case.

Asset inventory is the most important basic line of defence. You need to know about every item you are protecting. Therefore, we recommend to set a basic, the most important target for the Blue team, to update the asset inventory every week. That is all. If your are doing this continuously, the attacker will not have an easy work, because with this measure you will eliminate “the lowest hanging fruit”.

Curiosity is good or learn to detect the anomalies!

What is your detection capability? Yeah, we know, you probably have IDS and IPS, firewalls, correlation engine and all those cool stuff. But do you know how usually we got backconnect from the cracked machine? Meterpreter TCP. A bit more challenging is using OpenVPN on port 443 / TCP. Sometimes it is necessary to use a more complicated approach, let’s say like Raspberry PI with LTE modem. And occasionally we use sat link (OK, full disclosure here we wanted to try it, it’s was not really needed).

If you have properly set up an asset management and detection capability, you should uncover our activities immediately (because we had to put something into your network) – so no big deal.

To be able to detect anomalies, we recommend to set a simple target – always know everything about egress traffic. Egress is more important than ingress because you can detect a successful attack in the egress traffic.

Practice makes perfect or train for incident response

When I had a role in the purple team, I had many interviews with blue and red team members. Funny thing, how much the red team and the blue team do not know each other. The blue team expects super-elite hackers who will use the never-seen techniques and tools. The red team expects that the blue team is able to detect an attack in the style of “Minority Report”. None of these is true.

Practice makes perfect. Therefore, you should do periodic incident response exercises. Do you know how much harder it would be for an attacker if your operator would be work with an analyst and upon detection there would be a clear list of actions and countermeasures?

In conclusion, I would like to share with you this tip from Twitter account Picard’s management tips (by the way, a great Twitter account, try it):

What do you think? We agree with Mr. Picard!

The post Why is a Red team usually more successful than a Blue team? appeared first on Rolken.