Follow us

Knowledge

Knowledge Articles

Putting the Fun into SDLC Fundamentals

Ok, confession time. The blog title is misleading. Software Development Lifecycles aren’t […]

Anthi Gilligan Co-founder & CISO, Cork, Ireland

“This is only for Dev…”

Ladies and gentlemen: the story you are about to read is true. […]

Ciaran O'Keeffe Co-founder & CEO, Cork, Ireland

Please don’t use the A-word!

Monday morning. 9.04am. Rain is hammering against your office window. You take […]

Anthi Gilligan Co-founder & CISO, Cork, Ireland

How I Learned to Stop Worrying and Love the Cloud

In my last blog I wrote about FOGO — or the Fear Of […]

Ciaran O'Keeffe Co-founder & CEO, Cork, Ireland

Forget FOMO, what about FOGO?

You’ve probably heard of FOMO: the “Fear Of Missing Out”. It’s a […]

Ciaran O'Keeffe Co-founder & CEO, Cork, Ireland

Putting the Fun into SDLC Fundamentals

SDLC FUN

Ok, confession time. The blog title is misleading. Software Development Lifecycles aren’t exactly “fun”, and nothing I can write will change that! It is an interesting topic though: consider that you could ask 20 different DevSecOps engineers “how do you secure your SDLC?”, and the answers you get may outline 20 different ways of doing things… and what’s even more interesting is that all 20 may be correct and valid approaches. 

As with skinning cats, it’s the case that there’s more than one way to operate a secure SDLC, but in my experience, there are some fundamental building blocks that you need:

  • Cultural Awareness – the success of your SDLC may hinge on whether or not your organisation as a whole has bought into the importance of security
  • Secure Design – assuming you have that level of cultural buy-in, you need to embed security in your design from the outset.
  • Secure Coding – it stands to reason that your secure design needs to be securely coded for it to work as intended.
  • Robust Testing – less bugs at this stage usually means you’ve done a good job with the previous three – provided your security testing regime is comprehensive.
  • Effective Monitoring – things change so you always need to keep an eye out for anything that goes wrong, but again, if you’ve nailed the previous stuff, you shouldn’t see many problems here, and monitoring should give you peace of mind instead of cause for concern.

Obviously, these building blocks can and will contain many different facets depending on the nature of your organisation. For example, if I was to examine Testing in detail… well, that’s a whole series of blogs in itself, and I don’t want to get too bogged down with the relative merits of SCA, SAST and DAST, etc. I think it’s fair to say though that if you stick to the fundamental building blocks listed above, and do them all well, you’ll significantly reduce the likelihood of suffering a security incident.

Of course in the real world, I’ve found it can take years to get to the stage where you’re comfortable that all of these fundamentals are being covered adequately. Your available resources are finite – headcount, time, money – and this will invariably restrict the amount of work you can do, so you can end up playing security Whack-A-Mole unless you know what to focus on. In order to establish this, there are 3 key questions you need to ask:

1 – Where is our biggest risk? 

Knowing your organisation is vital to understanding which part of your Software Development Lifecycle is riskiest. Start at the beginning and evaluate how your team approaches each of the 5 building blocks in turn. Once you have identified where your weaknesses are, you can start to address them. For example, maybe you look at your development team and see a bunch of people who understand the importance of secure design and secure code. However, maybe they also use a large amount of open source libraries for their code, because… well, doesn’t everyone? Given the interdependencies that exist between libraries, this will inevitably lead to huge security vulnerabilities. You can’t change this fact, but acknowledging it is key, as you can then focus on managing these risks by using a Software Composition Analysis (SCA) tool. 

2 – Can we automate?

You can have your team do everything manually. It’ll take a lot of time though. And bear in mind you’ll need to account for the manual errors that they make. And unless your manual workers are clones (which would be weird), each of them will probably do things slightly differently. That’s why it makes sense to automate where you can – you’ll get faster, error-free and more consistent results. Look at your SDLC and examine what aspects of it can be automated. It’ll pay off in the long run.

3 – Can we shift left?

If your monitoring and testing is routinely showing up issues, you can spend lots of time and money fixing these issues. But this is a response to detective work, and leads to firefighting in perpetuity. There’s always a root cause and that root cause won’t be fixed unless you shift your focus left. The earlier you can embed security into your SDLC, the less remediation you’ll have to do. Whenever you’re looking at a problem, ask yourself if you could shift the problem left… get to it earlier and before long you’ll eradicate the root cause.

Akeero can’t make your organisation adopt a strong security culture, but the fact that you’re still reading this blog suggests that at least one person in your organisation does (ie you!). What Akeero can do, through our intuitive user interface and native integrations, is allow your organisation to shift way left and embrace automated Secure Design. You can identify security and compliance requirements for complex cloud architectures in minutes, with minimum impact to existing security and development toolsets and processes. 

If you’ve any feedback on the topics I’ve covered in this blog, or want to learn more about Akeero, please reach out to me – I’d love to hear from you.

“This is only for Dev…”

This is only for dev

Ladies and gentlemen: the story you are about to read is true. Only the names have been changed to protect the innocent.

A security architect sits at her desk, lost in thought.

“Excuse me, Tina? Do you have a minute?”

Tina looks up. It’s Quentin, one of the developers.

“Sure, Quentin. What’s up?”

Quentin pulls up a chair, and places his laptop on the desk in front of Tina.

“I just wanted to show this to you. It’s something we’ve been working on and this is how we are going to secure it.”

Quentin points to a diagram on the screen. Tina studies it for a few moments, and her face begins to contort in anguish.

“I know it’s a bit rough but don’t worry! This is only for Dev! It will never go into Production!” Quentin says, hurriedly.

Tina takes a deep breath. “Ok, no problem. I need time to review and understand the architecture. Can you set up some time for us to go through it next week?”

Fast forward to a week later. Tina sits alone in a meeting room. She glances at the clock again, sighs and gets up from her chair.

Tina walks across the office floor to Quentin’s desk. Now, she is the one interrupting his thoughts.

“Hi, Quentin. Did you forget about our meeting?”

He looks up, sees Tina. A sheepish expression flashes across his face.

“Oh yeah… sorry about that, Tina. It’s actually fine now though. We had to push the changes to Production for our next release. It’s ok, we got it signed off.”

Tina walks away. She’s not angry. This is not new to her. Tina has learned that things are rarely (if ever) done “only for Dev”.

This is what happens when developers are under pressure to release new features quickly, and security teams are stretched so thinly that their availability has a lead-time of a week or more.

As a result, priorities become forced to compete with one another. Despite everyones’ good intentions, agreed structures become stressed and can fracture. Organisations are faced with a choice between two evils: the costly, disappointing delay versus the speedy but risk-laden release.

I have been in Tina’s position many times. I don’t blame the Quentins of this world — they want to do the right thing, but routinely find themselves in an impossible situation.

If you could make one change to how the interaction between Tina and Quentin played out, what change would you make?

Would you ease some of the pressure on Quentin, allowing him to wait until the meeting with Tina before he released his changes into Production?

Or would you free up some of Tina’s time, so that Quentin didn’t have to wait a week to get her input?

I used to think those were the kind of things that needed to change, but then I started to think about it differently. I went right back to the start.

What if the sight of Quentin’s diagram hadn’t made Tina recoil in horror? What if Quentin had used a tool that allowed him to identify security controls easily and seamlessly at the very start of the design process? What if Tina had access to that same tool, allowing her to review multiple projects easily and efficiently?

Thinking about things in that way is how Akeero was born, and I believe that it delivers:

  • Secure and compliant infrastructure
  • Increased team and resource efficiency
  • Reduced security spend and effort
  • Increased speed to market for secure products and services

If you found yourself identifying with Tina or Quentin, or if the situation resonated with you from your own experiences in your organisation and you want to learn more about what Akeero can offer, please reach out to me. Or if you simply want to share your thoughts about this blog post, I’d be delighted to hear from you.

Akeero automates product security design and compliance for cloud-native environments, enabling teams to deliver secure apps and networks better, faster.

Please don’t use the A-word!

Monday morning.

9.04am.

Rain is hammering against your office window.

You take a sip of coffee as you scan through your emails.

That’s spam. *delete*

That’s spam. *delete*

That’s sp-… wait a second… what’s this?

An upcoming AUDIT?!?

FML!

Could this day get any worse?

Does this scene seem familiar at all?

Although I don’t work in GRC exactly, I have worked alongside it for many years now; certainly close enough to regularly get sucked into its gravitational pull. When I meet new people and tell them what I do for a living, they will sometimes ask “do you like audits?”, as if it’s a vocation or a calling. And the answer is… No. Of course not. Not even auditors “like” audits. They just like things to be done right, and I do too.

But why do we feel this way about audits, even when we know that they’re important? I think there’s a couple of reasons.

One is just the natural defensiveness that most people feel when their way of doing things is being evaluated and challenged by somebody else. Nobody likes to be judged and we can all fall into the trap of taking things personally. That’s a trap that can be avoided as long as you’re aware of it, and the more experience you get, the easier it becomes to detach yourself from that mindset.

The second reason why I think audits annoy us (and what I think is the main reason) is that they take up SO. MUCH. TIME.

You start out by reading the scope of the audit. Then you start to prepare, and it’s a scramble to gather the relevant documentation and evidence, constantly chasing people who’ve become suspiciously hard to track down since the audit was announced.

When you finally get hold of them, maybe you find out the documentation isn’t good enough, or worse still, that it doesn’t exist at all. You have to chase people some more, pressuring them, even encouraging them with cake where necessary (that last one sure works for me).

You think you’ve done all you can and then you meet with the auditors and show them all that you’ve prepared… only for them to tell you that it’s still not good enough. You’re thrust back into that cycle of scrambling, and all the while you’re thinking that this is just a distraction from your “real job”.

And finally, in the end, what do the audit results show? It’s nearly always just a case of telling you to do something you already knew you should have done, but you were too busy doing your “real job” to get to it. So, yeah… nobody “likes” audits.

But what if you didn’t need to scramble? What if all the information you needed was ready-to-go, up-to-date and accessible at the click of a button? That’s where Akeero can help — whether your organisation is big, small, or somewhere in-between.

Our platform identifies security and compliance requirements for complex architectures in minutes, and can effortlessly produce all the documentation you need to show an auditor that your team is doing things the right way.

Our intuitive user interface, combined with native integrations, allows your organisation to do this, with minimum impact to existing security and development toolsets and processes. We believe that Akeero delivers:

  • Secure and compliant architecture designs
  • Increased team and resource efficiency
  • Reduced security spend and effort
  • Increased speed to market for secure products and services

We can’t promise you’ll grow to like audits, but we can definitely take a lot of the pain away, leaving you with more time to concentrate on your “real job”.

Akeero automates product security design and compliance for cloud-native environments, enabling teams to deliver secure apps and networks better, faster.

How I Learned to Stop Worrying and Love the Cloud

In my last blog I wrote about FOGO — or the Fear Of Getting Owned, and it got me thinking about fear in general. Fear is one of the most primitive human emotions, and despite the largely negative connotations, it can be a healthy thing.

Imagine a cliff-face of sheer rock, stretching hundreds of feet towards the sky. You look to the top and you see that it’s so high that it’s actually in the clouds.

Now imagine that you’re suddenly halfway up the cliff, clinging to the rock with your fingers and your toes. You probably feel very afraid of falling. This is a natural reaction, and one designed to keep you safe.

What precautions could you have taken before you started climbing? Would you feel better if you had some safety ropes attached? Certainly. What if you were kitted out in some proper climbing gear? That would help too. And what if your route to the top had been marked out in advance by an expert climber, who was on hand to guide you along the way? Yes, please!

Even with these precautions in place, you’re probably still afraid, but maybe now the climb to the clouds seems like a risk worth taking. Sure, it’s going to be tough and scary, but the view from the top will be magnificent.

For many companies, they know that they could benefit from moving their infrastructure to the cloud, and yet they find themselves paralysed by fear. Will we be in control of our data? What if there’s a breach? How do I know my infrastructure is secure? All valid concerns… although if you stop to think, these risks already exist with on-premise solutions too. It’s just that we’re more used to managing them; what we’re really talking about here is the fear of the unknown.

All fears can be overcome, so if your organisation is ready to make the move to the cloud, it’s vital that you do so with a full understanding of what’s involved. Gartner predicts that through 2025, 90% of organisations that fail to control public cloud use will inappropriately share sensitive data. A scary thought. They also predict that 99% of those cloud security failures will be the customer’s own fault. That’s as unsettling as it is scary.

The good news is: you are in control. Provided you prepare in the right way, you can make sure that you realise all of the benefits the cloud has to offer — all that wonderfully scalable and cost-effective flexibility — without taking on any additional risks. In fact, I believe that if you do things the right way, your cloud infrastructure can be even more secure than any on-premise solution.

Akeero was designed with a clear goal of allowing teams to identify security and compliance requirements for complex cloud-native architectures in minutes. Our intuitive user interface, combined with native integrations, allows your organisation to do this, with minimum impact to existing security and development toolsets and processes.

We believe that Akeero delivers:

  • Secure and compliant architecture designs
  • Increased team and resource efficiency
  • Reduced security spend and effort
  • Increased speed to market for secure products and services

Reach out to me if you want more info on how Akeero can help you to do things the right way from the start, and ensure your organisation has the footholds it needs to take those first steps toward the cloud.

And yeah, it’s still a little scary… but the most worthwhile journeys are often the ones that take you out of your comfort zone!

Akeero automates product security design and compliance for cloud-native environments, enabling teams to deliver secure apps and networks better, faster.

Forget FOMO, what about FOGO?

You’ve probably heard of FOMO: the “Fear Of Missing Out”. It’s a well-established and oft-referenced social phenomenon, the kind which can commonly arise from seeing an Instagram post of someone you barely know drinking a cocktail on a sunny beach somewhere. Your heart sinks as you consider that everyone else in the world (EVERYONE!!!) is having more fun than you.

The past year has seen all of us miss out on various fun times, and as a result FOMO has receded, at least temporarily. You could argue that it’s one of the few upsides to the pandemic, but I think I’d take FOMO over lockdowns any day of the week.

What hasn’t receded — and in fact may be getting more severe — is a less well-known anxiety, but one that most organisations can relate to: FOGO, or the “Fear Of Getting Owned”.

As more and more companies adopt a “Cloud First” approach for hosting mission-critical products and services, their architectures are becoming increasingly complex and difficult to manage. Add in some lovely Agile development practices and a dash of Infrastructure-as-Code and it can quickly become overwhelming trying to securely design and deploy cloud native infrastructure.

No organisation wants to be headline news for all the wrong reasons, because it turns out there IS such a thing as bad publicity — just ask Volkswagen about “Dieselgate”. Managing and securing cloud-native infrastructure is challenging, especially at scale, so it’s almost a certainty that people in your organisation are suffering from FOGO. And if you’re lucky enough to have a dedicated security team, it’s likely that FOGO sometimes keeps them awake at night.

A quick Google search of a term such as “cloud data breach” will highlight how many organisations, large and small, are continuing to suffer critical data breaches as a result of insecure configurations for their cloud-native infrastructure. Even something as avoidable as “S3 public access” continues to rear its ugly head, again and again! The question is: with all we’ve learned, why does this continue to happen?

In my experience, there are a few reasons why organisations continue to experience challenges in cloud-native secure design:

  • Lack of time and/or resources leading to inadequate or non-existent security or compliance design
  • Agile engineering teams require too much time to identify security requirements at scale
  • An over-reliance on security testing immediately prior to product or feature release, at which stage it’s often too late to fix all but the most critical issues (and sometimes it’s too late to even fix those!)
  • Too great a focus on detection of security issues and too little focus on prevention
  • Lack of organisation-wide visibility of deployed infrastructure

Of course, none of these problems are insurmountable, and that’s where we believe Akeero can help — whether your organisation is big, small, or somewhere in between. Our platform was designed with a clear goal of addressing these challenges by identifying security and compliance requirements for complex architectures in minutes.

Our intuitive user interface, combined with native integrations, allows your organisation to do this, with minimum impact to existing security and development toolsets and processes. We believe that Akeero delivers:

  • Secure and compliant architecture designs
  • Increased team and resource efficiency
  • Reduced security spend and effort
  • Increased speed to market for secure products and services

Come tell us why you have FOGO and find out for yourself how Akeero can help!

Akeero automates product security design and compliance for cloud-native environments, enabling teams to deliver secure apps and networks better, faster.

Ready to jump onboard?

Akeero helps you design quickly and securely.