It didn’t happen once or twice, that I fooled myself into thinking that I can build the very thing that I aka my organization needs. Even when I in fact was able to, it doesn’t mean I should’ve done so.

See, when you’re growing an organization and you happen to have your own software engineering team, it’s easy to push more work on them. It’s easy to assume that they can build something in a week to fit the needs of your particular usecase, which will save you a few $thousands/year on a subscription to the 3rd party service. Building your own toolkit is great and is often the right thing to do. But at a certain point, you need to start more thoroughly evaluating the question of – will this investment be sound if I look back at it 9 months from now?

There is a bunch of tools every IT company needs to have tailored to their needs. Scripts, one-off programs, orchestration software capable of dealing with the custom nature of you infrastructure and all that. Then, there is software which appears to be cheap to build and relatively cheap to maintain and extend. But as your organization grows, so grows the needs of that software to fulfill more duties.

Initially you’re happy that you’ve saved your budget a $3k spend on third party tool, by utilizing your in-house engineers who’ve built it for $1k. The misery kicks in, when you get attached to the investment you’ve made in building that piece of software. Your company grows, and you need one more functionality to the original program, so you decide to add it, because you’ve already built the core framework and you won’t kill the project to buy 3rd party solution – current parity of core features doesn’t justify replacing the thing that your engineers built.

And so it goes, week by week, month after month, and ultimately you get to the point where your spend on this single piece of software already matched the pricetag of 3rd party solution. You’ve spent much more time of your engineers, yours, your project managers and product owners than it was reasonable. There was a point where you should have stopped but you haven’t because you couldn’t step back and see what is going on.

I myself am an engineer by heart. I love building things, I love to bring my creations to life and create my own little piece of art.
All that needs to be put aside, when you’re working for a business, you need to focus on what’s best for the company both in the short and long-term. Your ambition is often the reason for unnecessary waste of resources. You feel like it’s beneath you to delegate responsibility of building a tiny program to 3rd parties, because you can roll up your sleeves and build it yourself.

Leaders in startups that have to manage growth with limited resources really need to learn how to disassociate their ego from their decision making process. If you aren’t able to detach yourself and see through things objectively, you’re at risk of wasting the most scarce resource every startup has – time of your engineers. You can’t just put a market value as an hourly pricetag for an engineer who’s been working on your systems for a year. The reality is that if you’re spending an hour of an engineer who’s paid $50/hour, then it’s actually costing you 10 times that number. That’s how much you’re losing not letting them do the work they’ve been trained to do. In that sense, each individual who’ve been trained with your systems is in a sense irreplaceable, when you consider the cost of them being distracted. The opportunity cost is real.
Now consider the lost focus, that you could’ve invested into the things that actually matter. And the perk of using 3rd party solutions, which can sometimes surprise you with great features you didn’t event know you needed til they built and gave it to you.

If you still believe you need to build it, so be it. Hire a bunch of contractors to do that work for you instead of pulling your resources from their daily work which immensely contributes to organization’s bottom line.

In the early days of my career, I’d pick build nine out of ten times we were evaluating a solution. Now, a decision to buy is what I usually end up doing, because when you take into consideration the hidden costs of building, extending and maintaining the solution, it just doesn’t make sense to follow my ambition to build it.

At the end of the day, it’s not my ambition which will be staying long hours on weekends to debug the custom system we’ve built accruing a lot of technical debt along the way.
It’s my people who’ll be dealing with my lack of thoughtfulness and I don’t want that for them.

Regardless whether you’re creating and selling software or you’re just using it to run your daily operation, you are an IT company. Show me a business which doesn’t require technology as an essential element of its strategy and I’ll show you what you’re missing.

If you’ve been listening closely to the things taking place in the security industry you might have heard the following statement “security perimeter doesn’t exist anymore” thrown around like it’s nothing. Many of those who claim so in fact mean something else, which would be phrased more accurately as “security perimeter has shifted and the attack surface has changed due to wider adoption of cloud technologies and application of the DevOps culture”.

The reason for me bringing this up is that I’m seeing a lot of folks, ranging from security engineers, CTOs to even CISOs getting confused by that prior, blunt statement.

Security perimeter still exists and you still need protect the externally exposed resources the way you used to. You shouldn’t use that claim to justify your lack of capacity and not spending a sufficient amount of resources on the security of your externally facing infrastructure.

The first line of defense still matters. Yes, internal threat actors are a thing and shadow IT is prevalent, but cohorts of script kiddies, bots and newbie cyber-criminals are still probing your external infrastructure against common vulnerabilities. And they’re doing that all day long.
While for you to become a target for more advanced type of an attacker, you need to be doing something really well to become interesting enough for them to invest their time in breaking your security model. It’s not to say that it doesn’t happen for small companies, but likelihood of facing certain level of threat actors must be taken into consideration.

If you worked in a business role you likely know that resources company can spend on engineering are, and always will be limited. Security will always compete for resources with other aspects of business. While you’ll be unlikely to compete for resources with sales department as those units have separate budget, you will be splitting the budget with software engineers, QA engineers, DevOps engineers, IT OPS and alike. For that reason, you need to accept that your resources will be limited and keep in mind that while rarely you can do much (unless you’re a senior D/C-level exec) about the sum you’ll be able to spend, you are in control how efficient you are with your resources.

What I’m trying to say is that when you’re working as an infosec specialist at a company, you should never consider yourself from a perspective of us vs them. It’s in your interest to make infosec a part of engineering organization and work arm in arm with other engineering teams, because if you plug yourself into their discussions and workflows you can reap significant benefits from being able to interact with them. If you’re pulled into early discussions about SDLC, software architecture, infrastructure overhaul and you’re on good terms with other engineers you have a chance to influence the outcome of those discussions, embedding security into the process.

Each and every company wants to spend money wisely, meaning spend the least of it in a way that yields the highest benefits to the bottom line. You shouldn’t expect that one day you’ll be provided with enough resources to manage the security technical debt and clean up everything.

Especially in case of bootstrapped startups it’s hard to start thinking about security, performance and overall quality from the early days of your venture. The reality is that if you’re in an early stage of startup development you split your hair to improve your prototypes and make MVP out of it. That is fine and expected, but the moment your business starts being profitable with positive trend of it staying that way, you should rethink the priority of your security investments.

Now, getting to the point where you have a reasonable level of certainty about your startup’s future may take you a year or three or five, so don’t rush it. You don’t want to create a product all rugged and an engineering piece of art which is of not practical use. Business longevity comes first.

But if you’ve been profitable for a few years – take the word ‘profitable’ with a grain of salt. If you’re burning VCs money and you have a vision of an liquidation event but for now you’re spending more than your revenue would allow you to, then that is fine – having a solid position on the market and hundreds of paying customers should be a good marker to determine your readiness to switch gears a little bit and start investing in your organization’s safety.

For many startups, there happens to be an ideal moment when you can take your shots.
At a certain level of startup’s growth you get to the point where you can’t continue with the technical debt you accrued while building the MVP, at the same time your business is stable enough that you can slow down the growth of the product and invest in architecture overhaul.
That’s the sweet spot to introduce professional security practices into the process. You’re tearing things piece by piece and remodeling it to make it ready for the growth of your business, and each part you refactor should now get injected with quality/security/performance/resilience practices. At this point, it’s as if you were embedding your processes into the business from the day 0, but it’s even better than that – you now have semi-mature infrastructure, tooling and competent engineering team who can fit security much better than it would have when the whole product was sitting on a paper in a design phase.

It’s uncommon to be capable of pushing the business to give you resources to refactor a piece of application just to address the security technical debt. But in that peak of startup’s growth, right before accelerated-growth phase, engineering is provided a significant budget to invest in technical debt, at the same time enabling you to multiply your potential impact, because your changes will take up an insignificant sum of it all.

For that reason while running security operations for organizations at any level of its maturity, you must leave wishful thinking aside and start to strategize on how you can embed security practices in the work of other departments. The perfect moment when all eyes are on security won’t happen – unless you’ve been compromised already and your executive team has strong incentives to do something about it.
Whenever you see a new project or an overhaul of an old project, that’s the real perfect time for you to focus on building the security into it. That’s the moment when you should drop your other tasks and focus solely on the opportunity at hand, because once that’s gone it’s gone and you’ll need to either way a long time for next refactoring or fight for the dedicated budget to improve its security – and that’s never easy, no matter how mature you think your organization is.

After all, we all want to get things done with as little friction as possible and for that reason we need to compromise on the ideal, to achieve the general efficacy of IT security operations.

Regardless of current trends, my style will remain to be such that human education comes first, perimeter safety comes right after and only if I know I have the viable level of safety there I move to securing the internal assets. Until then, I won’t realistically bother with shadow IT, APTs and internal threat actors, ’cause changing ones strategy to adapt to current trends and abandoning common sense is nothing but a security theater.

Triage, prioritize, execute.

While studying new material in private time I like to take notes to memorize things better and have neat reference material for the future. I often end up polishing some of my notes on a specific subject and releasing it to the infosec community, and I’ve found such a piece of work from last year when I’ve been intensely studying the security concepts of Google Cloud Platform.

I’m NOT a DevOps/GCP expert by any means – just wanted to share something to add a building block to our community knowledge base and make it easier for others to learn the ropes of cloud security engineering.

Table of Contents includes:

• Resources hierarchies and policies
• Cloud IAM Overview
• IAM roles
• Service Accounts
• Cloud Identity
• Cloud IAM Best Practices
• Network Security
• VPC Network details
• Firewall rules
• Load Balancers
• VPC Best Practices
• Cloud Interconnect and Cloud VPN
• Cloud DNS and DNSSEC
• Encryption
• Cloud Key Management Service (KMS)
• Cloud Identity-Aware Proxy
• Data Loss Prevention
• Cloud Security Command Center
• Forseti
• DDOS Mitigation
• Cloud Security Scanner
• Compute Engine Best Practices
• Google Kubernetes Engine(GKE) Security
• Secrets Management
• Cloud Storage and Storage Type:
• Cloud Storage Permissions and Access Control Lists
• Data Retention Policies using Bucket Lock
• BigQuery Security
• Stackdriver
• Cloud Responsibility Model

A big credit for this contribution goes to the bloggers and platforms from which I’ve learnt a ton, to name a few: pluralsight, cybrary, pentesteracademy, linuxacademy, cousera, udemy, infosecacademy.

Hope this is helpful.

Coraz częściej dociera do mnie pytanie o to, jaki certyfikat i szkolenie wybrać by wystartować ze swoją karierą w branży bezpieczeństwa IT.

W tym nagraniu pomogę Ci wskazać moje podejście do wybierania pomiędzy certyfikatami i szkoleniami w które inwestuję swój czas i energię.

Earlier this year I was asked to prepare a presentation for SecureGuild 2019 – an online conference focused on application security.

I’ve decided to take it a bit further and instead of talking just about appsec, I showed up with a presentation about DevSecOps and my real-life experience with it. I felt like there still isn’t enough content released for the community to learn from individual cases.

The main theme of my talk was how to achieve a successful DevSecOps evolution through realistic expectations and company-wide transparency and here is how I summarized the talk:

Although most companies are somewhere in the middle and it’s hard to really determine the factors that allow them to effectively manage their security operations, there is a lot we can learn by studying the stories of companies that thrive on DevSecOps and those that really struggle to make it work. In my experience, the biggest reason for companies failing to succeed with DevSecOps is that instead of embracing it, they engage in the project with deep resistance because they know they haven’t really done their homework and aren’t prepared enough to comprehend the big-picture perspective. During my presentation, I want to share with you my observations from over 5 years spent in the trenches, which should turn helpful if your goal is to build a DevSecOps roadmap that focuses on practicality and positive long-term influence at your organization.

The video was originally published in May 2019, and I’ve received a confirmation from the organizer that I can release it to the community in December, so here we go!

I hope that my research and experience help the community a bit. Curious to hear your stories on the experiences you’ve had with DevSecOps and DevSecOps-wannabe organizations.

All the best,

Dawid

A couple of weeks ago I was asked by my colleague to give him some clues and tips on how to become a Cloud Security Architect, as that’s the venture he wants to follow and he knows I’ve been in architect-alike roles for a while.
Knowing how much fulfillment one can get from a good career and work-life, I’ve had decided to sit down and write down some tips right-away. I did share it with him, but then I’ve had looked at it myself and I’ve come to realize that instead of a few tips, I happened to write a lengthy article on the subject. So I’ve polished it a bit and wanted to share this with you.

Please note, that I’m never in this article claiming that this is the ideal path, the only path or anything of that nature.
I’m no guru, no career expert or some crazy good security architect.  I’m just a dude who happened to manage to get to the point I’m right now, and I want to share my perspective as a mean to help you see the journey of others and maybe get some clues on how to proceed with your career.

To me, the role of a security architect is as much about technical work as it is about business and leadership. While the specifics of the role definitely vary between companies, it’s a common requirement for architects to know how to talk to C-level executives, lead teams and independently manage the workload in such as way that the project gets delivered in compliance with the business requirements. Sometimes reading through the job descriptions you may get the impression like the productivity of a security architect equals their social-savviness and there is something to it. Rarely you can build great things without the involvement of great people and if you can’t influence them to follow your leadership, then you’re missing out on a huge potential of the group work.  But I published a whole book on how to level up your social skills game to boost your career in infosec, so I’ll skip that and will focus on other aspects of the role.

My path isn’t obvious but it’s very common

In my case, I can’t really speak of any certifications or training aimed at becoming a security architect – if you know some, please leave a comment with some about it – but I have completed a bunch of Cloud Security Architecture related courses and training, which I believe helped me tremendously in getting better.

I haven’t had any formal education that got me into the role of a security architect, but rather a lucky series of opportunities that presented themselves in front of me and I was able to get hold of them.
To cut it short, I’ve started gaining exposure to the commercial IT about 10 years ago. I’ve started as a programmer, then became a network administrator(netops), sysadmin, bug bounty hunter, pentester, offensive security engineer, security engineer working in a blue team focused on SOC/IR. During that time I’ve been focused on self-development to mature – as each human should – both in personal and professional life. I’ve made sure to keep myself educated on business, social dynamics, relationships and all types of things, to get more context and wider perspective. It took quite a while, but I feel that the appreciation to the challenges faced by people on different roles and different levels of seniority eventually made me a better security architect.

Like I’ve said earlier, education never stops because you always learn new things on the go and try to be prepared for new projects. To stay as current as I can in this fast-paced industry, I try to take advantage of the content shared by people generous enough to share their knowledge. I can’t really express the level of gratitude and admiration I have towards people who’ve had done something and then have decided to share their knowledge on the Internet. You can really, really learn a ton by following what others have tried, what they succeeded in as well as what they’ve failed at. Each lesson holds enormous value, regardless of it’s a study of the success of a failure – you’re focused on studying somebody’s attempt and then deciding on how you can put that knowledge to use in your particular real-life scenario.

Recommended technical training for Cloud Security Engineering and Architecture

When it comes to the cloud I’m really a fan of vendor-specific training and certification, because due to the complexity of each of those environments, the generic training just doesn’t cut it.
Vendor-specific training allowed me to much easier navigate through the piles of knowledge I’ve collected along the way while playing with various environments on different projects and helped me put a solid structure around the knowledge I’ve had from reading blog posts, articles, podcasts and whatnot.

All of the leading cloud service providers – Google, AWS and Azure – have fantastic training and certifications that prepare you for hard scenarios you’ll face in real life. I’d say that before the training I’m about to mention, I used to cope with the security in the cloud and each and every next training made me feel like I’m more thriving in those environments rather than fighting each day and stressing about every little thing, dreading the unknown.

After having a few years of average-quality experience in playing with various cloud environments, I took enormous value from signing up for the following training which I’ve completed over the years:

Google Cloud Platform(GCP): 

Google Cloud Professional Cloud Architect
Google Cloud Professional Associate Cloud Engineer
Google Cloud Professional Professional Cloud Developer
Google Cloud Professional Cloud Security Engineer

Amazon Web Services(AWS):

With AWS they have a few tiers depending on your experience so I’ve always tried to opt for the Professional level, as it’s much deeper and for a security professional who doesn’t like getting unpleasantly surprised it’s excellent as it provides more depth in many critical components.

AWS Certified Cloud Practitioner
AWS Certified Solutions Architect
AWS Certified DevOps Engineer
AWS Certified Security Specialty

Microsoft’s Azure:

I haven’t participated in any big projects related to Azure, so just to have some overview of the platform I took the following courses:

Microsoft Azure Security Technologies
Microsoft Azure Architect

And when it comes to really generic training or certifications, I’ve enrolled for a course preparing for ISC2’s Certified Cloud Security Professional training which was nice but I probably should’ve had done it years ago to really benefit from it.

Note that I haven’t gotten myself to go after the actual corresponding certification after completing the courses/training, because to me the paper isn’t worth spending $500 per each and stressing about my scoring. It’s just my personal decision and I’ve never been interested in spending money on things that don’t directly improve my working knowledge, but it doesn’t mean you shouldn’t do it. If you want to spend the money or you have the company covering your training + certification costs then, by all means, go for it, because for some employers it matters and some folks enjoy passing the exam.
To me, during my whole formal and informal education I was never excited about passing exams. I guess it’s just my nature, because I’m always looking at the next thing I’m going to do after finishing something and I’m more excited about getting myself into the next course and using my money to grow and through my professional growth be able to bring more value to the company I work for.
The cost vs benefit ratio never made sense to me, but I wanted to write this paragraph to let you know that it’s not necessary but if you want to – go for it. Still, this is just my opinion of a guy who’s pretty conservative when it comes to spending money.

At the end of the day, a security architect is a role where you don’t just build secure software or secure infrastructure. Your point of focus is on building a security company/securing your business, which is where big-picture perspective gets beneficial, so while I focused here on the cloud environments, I think you should really try to make yourself familiar with as many building blocks of your company as possible. Obviously, you need to assess what’s beneficial and what not and what type of sacrificed you’re willing to make, but I’ve never seen anyone’s career being hindered by knowing too much.
Even though I’ve started working in the role of a security architect over 4 years ago, I’ve all that time focused on becoming. Becoming better at being a security architect, because getting into that position is just a test of your basic abilities required to get an opportunity to start the journey of becoming a good Security Architect.

To sum it up, if someone is wondering what to do to become better I think the training/certs listed above are a fine way to go about it. I’m not saying it’s the best or the only way to do it, but if you have no idea where to go next – which was the case for me for a way too long time – then it’s better to pick either of those and do something. It’s always better to do some than do none.

All the best to Y’All,
Dawid