The 5 key characteristics of a strong security culture

The internet can be a hazardous place for employees and companies alike – phishing attacks, malware, and hackers are all things we need to protect ourselves against. But protecting against these threats requires more than just updating software, installing firewalls, and monitoring access. People are often considered to be “the weakest link” in cyber security circles and security awareness training doesn’t always work.

We take security very seriously at ThisData, because well, that’s what we do. But taking security seriously requires having a strong security culture and allocating resources appropriately to prevent, mitigate, and respond to security issues.

So, I’ve come up with 5 key characteristics of a strong security culture that when implemented, will have your company well on the road to being better protected for the current threat landscape:

1. Encourage a positive security culture

Security culture: The ideas, customs, and social behavior of a particular people or society that allows them to be free from danger or threats.” – The Security Culture Framework

A positive security culture is one where all members of the organization help each other to “do security better” and where rules, expectations, and values – with regard to security – are openly communicated and conformance is encouraged. For example, team members need to be encouraged to be comfortable discussing security in each other’s work and making constructive suggestions. There should be an expectation of erring on the side of ‘more secure’, and not on ‘easier ‘or ‘more efficient’ to build. Everyone in the organization needs to be on the same page and know the risks and impact security issues can have on the company.

Most of our conversations take place for all our team to see in our Slack channels and in our weekly stand-ups. Team members should be encouraged to think about the security aspects of their own work, openly discuss issues, and work together to improve systems. Encourage the discussion of security issues by having specific “roundtable” discussions on a weekly or monthly basis, whatever works best for you. You could consider introducing a “no blame” principle so that team members know that issues they disclose will never be used against them or one another. The goal should always be to improve security rather than apportion blame.

Ensure that secure practices are integrated into day to day work. You should create ground-rules for the disclosure of account information or add a security “checkpoint” in code reviews.’

You’ll see I come back to this one often, but connect and collaborate with other similar organizations and find out about the security problems they have faced, and how they resolved them. Encourage responsible team members to join relevant meet-up groups, and attend talks and conferences. This helps you and your team understand the similar issues other organizations face, and learn what you might have missed, and what you can do better. We’ve just started a Slack group called Security Together for this purpose and already have some great discussions going on in there with people from different backgrounds.

2. Cover off the security basics

  • Control physical access. Ensure physical spaces, equipment, and networks are adequately protected. There’s also this good post on staying safe when you are working from a cafe or shared space.
  • Patch systems. Subscribe to security disclosure mail lists for the hardware and software you use and patch systems appropriately. Ensure you have a process for this so it is done in a frequent and timely manner.
  • Configure systems securely. This post, security checklists for new employees covers some basics for configuration and physical security.
  • Have automated, frequent, thorough, and tested backups for all data.
  • Put in place appropriate perimeter security to protect on-premises and mobile devices, networks, etc.

3. Monitor & log access

At a bare minimum security sensitive activities like account log-ins, password changes, and role changes should be monitored and logged to an audit log or a system specifically designed for this purpose. And you need to have an incident response plan that it is clear on who will deal with a security incident and how they should handle it, should one pop up. Establish the ground rules about how any related external communication will be handled (see SANS Institutes white paper on incidence response).

It’s important to understand and meet legal and contractual obligations with regard to security and privacy. Are you handling credit cards directly? You’ll need to comply with PCI standards. Are you appropriately disclosing which third parties have access to customer and personal information? Once again, periodically review your organization’s own security needs – each one is different – and allocate resources to log and measure where necessary.

4. Control change to codebase & dependencies

It’s important to use a change control process like Github issues, pull requests, and Git commit tracking to keep a record of changes to your codebase and dependencies. This will help you understand what is changing, and what new or altered measures might need to be put in place. This is also essential for audits and basically any compliance framework you may encounter. When you perform code reviews do so with a specific step that examines security issues and impact before code is merged in. If you’re not already involved in bug bounty programmes like HackerOne then you should seriously consider it because this adds another layer towards ensuring you have an on-going, re-assessment of security issues taking place in the background.

5. Develop in-house expertise

Ensuring your development team has up to date knowledge of security fundamentals and know how to avoid security issues in code, is key. Attending InfoSec conferences, joining professional organizations (who often offer great short courses), and attending meet-ups are all great ways to keep on top of new developments. Keep up to date with industry or sector-specific best practices – for the web see OWASP Top 10 – but keep in mind that engineers should be reading and keeping track of new developments as a regular part of their job. Sharing knowledge and experience also helps to develop expertise and gives fresh perspectives on security issues.

Some great general security resources I listen to include:

If you’re already doing weekly stand-ups then integrate the security conversations in to that to discuss issues, techniques, and trends, as well as asking advice of one another. Make your organizational mantra: “there is no such thing as a stupid question”. Again, it’s a great idea to open up communication channels to connect and collaborate with similar organizations in your area.

Finally, have periodic external audits to uncover any blind spots or deficiencies in your security practice.

People are at the heart of organizations, so no effort to secure an organization is complete without considering the people that comprise it. With a strong security culture your people are aware of current issues and follow best practices in their work in an open and collaborative way. And this in turn, helps to ensure systems are secured and company data is safeguarded.