Follow us

Knowledge

Knowledge Articles

What does it mean to be an outlier?

I started writing this post last week, from my hotel room in […]

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

The Curious Incident of the Dogfood Pen Test

You’ve probably heard the expression “dogfooding” or to “eat your own dog […]

Anthi Gilligan Co-founder & CISO, Cork, Ireland

Time Is Money… Or Is It?

Isn’t Wordle great? If you’re not aware of it, it’s a daily […]

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

“INSECURE DESIGN” hits the charts at number 4!

“Shift-left” is a term we’ve all heard used ad infinitum over the […]

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

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

What does it mean to be an outlier?

Outlier

I started writing this post last week, from my hotel room in London. Myself, Anthi and Stuart were in town for a very exciting reason, which is that… drum-roll please… Akeero has been invited to join the first ever cohort of Arc Europe, Sequoia’s seed-stage catalyst! 

Sequoia is a very well-known venture capital firm. I know this for a fact, because most of my friends and family know next to nothing about the VC world – no more than I did before Akeero – and yet lots of them have been contacting me since the news was announced to tell me that “even I’ve heard of Sequoia!”. So to have been chosen as one of only 17 companies overall to be asked to participate in Arc is genuinely thrilling, and I know the rest of the Akeero team feel the same. 

It’s also further validation that what we are doing at Akeero makes sense. We’re very lucky to have some amazing investors who have supported us since the beginning of our journey,  but whilst I’ve never doubted our vision, it’s not always easy to convince others that your vision is one that they should share. I believe that what we are doing will revolutionise secure design for companies, but I will also admit that in order to do so, some companies will need to come around to a new way of thinking about how they build security into their software development processes.

With Arc, Sequoia made it clear from the outset that they were looking for outliers. This got me thinking, what does this mean exactly? And what makes Akeero an outlier?

Outliers see things differently. They do things differently. They look at the way things have always been done and they say: we can do that better. We can do it faster. We can do it smarter. Not only that, outliers are truly transformative.

I believe that in order for security teams in every organisation to be able to scale – in order for them to be able to adapt to all of the challenges presented by modern engineering and the cloud – secure design needs to be embraced and embedded at the very start of the SDLC. I also believe that in order for this approach to truly add value, it needs to be automated as much as possible. Transforming organisational approaches to secure design is our mission at Akeero, and it’s what makes us an outlier.

Having said that, I don’t think that our viewpoint on security-by-design will be an outlier viewpoint forever. Soon the Akeero approach will be the approach that every smart company takes – there is simply no other way for security teams to scale and meet the demands of modern engineering teams.

I’d hoped to get this blog out last week (as I said at the start, I began writing it in London) but that plan soon fell by the wayside. Week one was fascinating and rewarding, but also quite busy, meaning all thoughts of blog posts had to be shelved for a few days. At time of writing I’m back in Ireland, and week two of the eight-week programme starts later today. If the first week is anything to go by, our leadership team will learn so much as part of Arc. If anyone has any questions about Akeero, or about my experience with Arc to-date, just reach out to me. We’re (wonderfully) busy right now, but I can always find some time to chat!

The Curious Incident of the Dogfood Pen Test

CURIOUS INCIDENT

You’ve probably heard the expression “dogfooding” or to “eat your own dog food”. It’s certainly a memorable phrase… although if you think about it literally, it doesn’t really make a whole load of sense. Just because your company makes dog food, that doesn’t mean you, a human (presumably), should eat it. After all, dog food is made specifically for canine consumption.

Perhaps the expression should be amended to “your dog eats your own dog food”… but that’s just not as catchy. And there’s another issue with the amended version: it depends on the dog. Your dog eating your dog food is not necessarily an indicator of said dog food’s quality. Your dog might just be one of those dogs that eats… well… anything. Don’t worry if they are though, I’m sure they’re still a very good boy or girl. 

Hmmm. As usual with one of my blogs, I appear to have gotten distracted. And as usual, dogs are to blame. Now, where was I? Ah yes… “dogfooding”. 

Despite what I just wrote, I do agree that the idea behind “dogfooding” is sound. Your product or service should be good enough that you’d be happy to use it yourself. Otherwise, how can you truly believe in it? And if you don’t believe in it, how can you expect your customers to?  Eating your own dog food is a good test of where your product really is, and early on here at Akeero, we decided to get out the can opener and chow down… 

Now I’m sure you know this already, but Akeero is a SaaS platform that allows users to securely design cloud-native applications and infrastructure. We currently support AWS – though support for Azure and GCP are both on our product roadmap so watch this space! – and Akeero itself is built on AWS. So, in order to eat our own dog food, we decided to design Akeero… using Akeero.  

“Wait… what?!? How does that work?” I hear you ask, scepticism clear in your voice. And I understand, because on the surface it sounds like some Inception-level shenanigans. Let me explain…

A lot of the power behind Akeero lies in our threat analysis engine, which looks at AWS architectures and quickly identifies all of the potential threats, then suggests best practice mitigations to be implemented during development. It’s like taking the knowledge of the most reliable, consistent and experienced Security Architect and cascading it throughout your organisation.

Although the product has come a long way since we ate our own dog food, the fundamentals of our threat analysis engine were in place even then. We didn’t have the awesome drawing canvas, or the ability to import existing architectures in a few clicks, or… well, pretty much any of the great features and integrations that we have now, but we had our engine

So we designed Akeero, and we ran our design through the engine. The engine told us what to do in order to secure Akeero as we built it, and we did everything it told us to. 

I’m the CISO at Akeero, but before that I have held lots of different roles within the world of InfoSec. I have a lot of experience in penetration testing – both as a tester and as a client. Full disclosure: I LOVE pen testing. I call it the “sexy” side of security (without any hint of irony). I’ve seen hundreds of pen tests in my time, some good, some bad, some horrifying. The one kind of pen test I have never, ever seen is a clean pen test. 

After we built Akeero, we had an independent information security consultancy come in and perform penetration testing on the platform. They spent their contracted week probing and prodding, looking for gaps and vulnerabilities to exploit. Then they asked for a second week. They wouldn’t charge us anything extra, they said, they just wanted more time.

The second week came and went. We asked them for their report. They were hesitant. Eventually they handed it over, almost apologetic.  Their report showed just three findings. They felt bad, like they had failed us. They felt even worse when we explained that two of their findings had already been fixed in our development environment, and they’d run their pen test on production. The third finding was informational only, meaning it had the lowest risk severity.

It wasn’t entirely pristine, but it was by far the cleanest pen test I’ve ever seen. It was also validation for what we had been working so hard to achieve. We’d tried our own dogfood, and you know what? It tasted great!

Akeero’s goal is to help every team shift security left within their SDLC. Identifying threats during the design phase and building securely is the ONLY way that security can scale alongside the rest of your growing business.

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

Time Is Money… Or Is It?

TIME IS MONEY

Isn’t Wordle great? If you’re not aware of it, it’s a daily word game that’s exploded online in the past month or so. If you haven’t tried it yet, I urge you to give it a shot – you’ll soon be hooked!

If you do play Wordle every day, you soon start to identify good starter words. Some people like to use the same starter word every day, but I prefer to mix things up, and recently I played both “TIMES” and “MONEY”. Both have 2 vowels and 3 commonly-used consonants, so they’re a solid foundation as a first guess.

Anyway, it was just a coincidence, but playing those two words in close succession sparked something in my brain. “TIMES”. “MONEY”.

“TIMES… MONEY”

“TIME’S MONEY”

“TIME IS MONEY”

I looked into it, and found out that it’s a phrase that’s been in existence for 300 years. So it must be true, right? Time IS Money, isn’t it?

Now, I know that it’s a metaphor and is not meant to be taken too literally, but still, as I get older I find myself disagreeing more and more with the old adage. 

Of course there are lots of similarities. We spend both. Most of us end up wasting a fair bit of both. And we all think about what great things we could do if we had just a little bit more of both.

But the big difference is that when you run out of money, there’s usually ways to generate some more… but when you run out of time, unless you have a working flux capacitor, you’re not going to be able to do much about it. 

This is why time is so much more valuable than money. It’s always tempting to distill hours spent into a direct monetary cost in our professional lives. There’s a myriad of formulas out there that allow us to do just that, and it can be a useful tool, but ultimately, the thing we should be valuing most is our team’s TIME. 

Is the work they’re doing actually worth the effort required? Even if it is, can the level of effort required be reduced, so that they can spend their time doing things that add even more value? Most people prefer to work on something that they feel is worthwhile, and get less satisfaction from doing tasks that they believe should be quicker and easier to do.

That’s why our ultimate goal at Akeero ISN’T about saving your organisation money… Instead, with our automated threat modelling platform, we focus on reducing the time that your teams need to spend finding and fixing security issues.

Designing your AWS architecture in Akeero WILL save time, right across your organisation: from your security team to your engineering team to your GRC team. The fact that it will save money too… well, that’s just a happy by-product.

I guess I’ve talked myself around a little bit, because there’s no denying that Time and Money are inextricably linked, especially in business. So I guess I need to say thank you, for choosing to spend a couple of your valuable minutes reading my thoughts on the matter.

I hope you’re not thinking “well, there’s two minutes I’ll never get back!”, but if you want to find out how Akeero can get you some time back (a lot more than two minutes!) then please reach out to me or sign up for more info on Akeero.com.

“INSECURE DESIGN” hits the charts at number 4!

OWASP Blog

“Shift-left” is a term we’ve all heard used ad infinitum over the past few years. However, this approach has – to date – rarely shifted far enough left to encompass secure design, which is something that has both baffled and frustrated me in equal measure. So I was heartened to see that the risk of Insecure Design has been included for the first time in the 2021 OWASP Top 10 – the organisation’s first update to their list in four years.

OWASP’s Top 10 has long been recognised as an invaluable resource for security and dev/engineering teams when it comes to securing products and services. It’s a vital indicator of trends and patterns in Application Security, and many organisations use it as a starting point for embedding robust, up-to-date security practices.

In fact, not only has Insecure Design been included this year, but it has debuted at number 4 on the list, which goes to show just how vital an activity it is when it comes to securing your organisational resources.

As a security architect, I have long advocated for secure design principles and threat modelling to be a standard part of every secure SDLC. You cannot truly say you have shifted left unless you have started considering your product’s security before you’ve actually started building the product.

The 2021 OWASP report says that “if we genuinely want to “move left” as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures.” Music to my ears!

One of the biggest challenges with this approach lies with the eternal mismatch in numbers between security and engineering, which can lead to a lack of availability (and perceived lack of engagement) from the security team. Now, in my experience, they’re not actually disengaged – they just have too many engineers to support, and not enough time in their day!

Another challenge is the sheer manual effort required to do threat modelling and secure design – especially to do it consistently and at scale. Traditionally, this required gathering a bunch of busy people in a room together, over a number of different sessions, and spending time mapping out and diagramming As-Is and To-Be architectures on a whiteboard. Which – and I say this as a security architect – is rarely anyone’s favourite way to spend an afternoon. Let’s just say there’s nearly always something else that people find they could be doing instead.

I think it’s fair to say that many organisations don’t even bother trying, and the ones that try struggle to complete these tasks, tasks that should be considered essential – ARE essential – but get relegated to non-essential simply because… well, because they’re painful.

As a result, secure design and threat modelling are overlooked in favour of detective controls, which are like a ticking time-bomb. Such tools have their place, of course they do, but if they’re finding lots of things that need fixing, that can’t be good. All of those things are in production by now, after all. What if the next time one gets found, it gets found by an external bad actor, rather than by your own detective tool?

The inclusion of Insecure Design as a risk in the latest OWASP Top 10 is a clear signal to our industry that the importance of secure design practices is finally being recognised, and I see this as a really positive development. Of course, it’s not one that surprises me, as the benefits of secure design practices and threat modelling are immense. When done effectively, they can save an organisation vast amounts of time and money, and they don’t even have to be difficult to implement into your SDLC!

OWASP believe it’s worth doing – they’ve said as much – and deep down, you know it’s worth doing too. Don’t worry about the traditional pain – at Akeero, we believe our automated threat modelling tool can make most of that pain go away.

We’re here to help you take those initial steps in your Secure Design journey, or help you get back on track if you’ve started the journey previously, but somehow lost your way.

I’d love to spend some time explaining what we do at Akeero and how it can help your team, so please reach out to me if that’s something you might be interested in. Or reach out even just to share your thoughts on this blog, whether you agree or disagree! I love nothing more than a healthy debate!

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.

Ready to jump onboard?

Akeero helps you design quickly and securely.