Practical cloud security overview

Information security, or cybersecurity, is a never ending systematic effort to manage security risks. The risks mostly stem from the fact that people tend to make suboptimal decisions and mistakes - in design, processes, code, configurations, operations - creating vulnerabilities in systems. Some other people try to exploit these vulnerabilities. Probably the most popular way to handle the computing infrastructure and applications these days goes by the name cloud (native) computing. The following security principles and goals don’t change with the adaption of a new paradigm, like cloud computing or DevOps.

The principles that help mitigate the security risks:

  • simplicity - the worst enemy of security is complexity, it makes attacks easier and defense harder
  • minimal attack surface - minimize possible ways a system can be attacked
  • least privilege - deny by default to limit the blast radius of a compromise
  • segmentation - create boundaries between systems to limit the blast radius of a compromise
  • defense in depth - since any security control can fail have multiple overlapping layers
  • ability to restore data and systems - backups, IaC, documentation, fire drills

CIA triad represents the traditional (since 1977) security goals: “The protection of system data and resources from accidental and deliberate threats to confidentiality, integrity, and availability.”

  • confidentiality: no unauthorized read access to data or systems
  • integrity: no unauthorized write access to data or systems
  • availability: data and service available when needed

To not get overwhelmed one might create some abstractions in the form of distinct areas to cover.

Governance and risk management

You should get at least a rough understanding of your organization’s business. Understand what is your responsibility (IaaS, PaaS, SaaS) and what data and compute/storage/network resources you are protecting. Get some idea which of these assets are the most critical (valuable) and who is most likely to cause problems and how.

Risk is the possibility of something bad happening. Risk level is the likelihood of a risk times its impact. Threat is a path to the risk occurring. You can approach each risk in one of these ways:

  • avoid it - don’t build or turn off the system if benefits < risk
  • transfer it - pay someone else to manage the risk (e.g. SaaS, insurance)
  • mitigate it - apply some security measures (controls)
  • accept it - if benefits > risk (this should be conscious)

You might need to prove your security to a 3rd party; this is called compliance.

Identity and access management

If an attacker gets credentials all patches and firewalls won’t help. Manage user and program identities (auth) and access rights (authz) in as few places as possible. Have process of removing users that left the company. Make sure that strong passwords and MFA are used. Use a password manager (1password) and don’t commit unencrypted passwords or API keys to repositories. Access rights (roles, policies) should follow the least privilege principle.

Vulnerability management

Detect and remediate security bugs and misconfigurations in application (Sonar[Qube|Cloud], ZaP, trivy) and infrastructure (tfsec) code, systems and networks (Nexpose). Before (SAST, SCA) and after (DAST) deployment. Important point to emphasize here is to make sure that the vulnerabilities found by the scanners are also remediated not only reported. So detect them as soon as possible in the process of developing and deploying code and infrastructure. First handle only the critical ones. Code reviews and penetration testing is helpful but expensive.

Security monitoring

You want to know what’s going on and then do something about. Detect threats and security incidents, and respond to them. You do this by first collecting and parsing logs and metrics in a central place. Then you create alerts (a log/metric query with a threshold) and handle them when they get triggered. Find a good balance between too many and too few alerts. Prefer quality over quantity to avoid alert fatigue.

Network security

If you can’t talk to a component, you can’t compromise it. Use network policies, ACLs, WAFs, antiDDoS, IDS/IPS, honeypots when it makes sense. Try to create trust boundaries. Anything inside a trust (or security) boundary can trust, at least to some level, anything else inside that boundary but requires verification before trusting anything outside that boundary. Also (almost always) encrypt data in motion using TLS.


The anomaly of cheap complexity

(This is my summary of Andrew Appel’s sunmmary of Thomas Dullien’s talk.)

How does one design an electric motor? Would you attach a bathtub to it, simply because one was available? Would a bouquet of flowers help? A heap of rocks? No, you would use just those elements necessary to its purpose and make it no larger than needed – and you would incorporate safety factors. Function controls design.

– Prof. Bernardo de la Paz in The Moon Is A Harsh Mistress (Robert A. Heinlein)

Why are computer systems so insecure?

The reason is that they have so many complex layers. Why there are so many layers? And why those layers are so complex (even for what should be a simple thing like counting up votes)?

It’s because complexity is cheap. For most of human history, a more complex device was more expensive to build than a simpler device. This is not the case in modern computing. It is often more cost-effective to take a very complicated device, and make it simulate simplicity, than to make a simpler one. The same is true of sofware.

Suppose you need a machine that does something not that complex, like a fridge. Complex general-purpose CPUs are cheap because of economies of scale and Moore’s law (ARM Cortex-M0 CPUs cost pennies). Software specializes a CPU that could do anything (universal computation) to become a device that does something.

Similarly a (huge and complex) general-purpose operating system is free, but a simpler, custom-designed, perhaps more secure OS would be very expensive to build.


Preventing git leaks

I keep most of my code and prose on public GitHub. I do it because I get reliable and easily accessible storage for free. Other reasons are that it engages my hubris and it might be helpful to others.

It’s working nicely but sometimes I get a bad feeling when I push stuff. I’m worried that I might leak some sensitive information like passwords, API keys or tokens. The obvious solution is to think twice before committing and pushing data.

But there are also some helpful tools, like gitleaks or git-secrets.

They basically find and report secrets in your existing commits or in the files you are about to commit. I want to run them whenever I commit something in any of my repos. These are the steps to make that happen:

  1. Install the tool(s).
  2. Add hooksPath = ~/.git-global-hooks to .gitconfig.
  3. Create pre-commit hook in ~/.git-global-hooks.


Coming back to this blogging platform

I simplified my personal servers setup, meaning I took down reisinge.net home page and replaced it with jreisinger.github.io. For this reason I'm going to backport blog posts from now dead https://reisinge.net/blog (contents can be found on GitHub) here.


Let's have just fun

Some engineers, both junior and senior, have random approach to work as opposed to a systematic one. By random (or freestyle) approach I mean:

  • generating quick ideas without followup
  • kidnapping discussions with unrelated digressions
  • presenting ideas without putting an effort into thinking them over
  • making decisions without discussion
  • organizing useless meetings
  • hacking code without designing it
  • not using drawings when explaining concepts or designs
  • not tracking issues/tickets/projects
  • not documenting

By systematic (or disciplined) approach I mean the opposite.


I get that the random approach is easier (and more fun?) and that it tends to produce new ideas. But if you use it too much it will create unnecessary chaos and technical debt after some time. In other words it will increase technical and organizational (when embraced by managers) complexity without adding value. So you need some balance between freestyle and disciplined approach. To evaluate the balance look for the signs.

The signs of unhealthy level of technical complexity in software systems:

  • hard to use
  • unclear API and documentation
  • unclear design
  • difficult to find bugs
  • difficult to add new features
  • difficult to take over (or hand over)
  • operational problems and outages

The signs of unhealthy level of organizational complexity are:

  • meetings without agenda, conclusions and followup
  • people don’t show interest in the meetings
  • the same problems being discussed again and again
  • difficulty to schedule meetings, too many meetings
  • bureaucracy and rules that make no sense
  • non-existent or unclear team/company strategy and goals
  • non-existent or toxic team/company culture

(You can have unnecessary complexity also on personal level but I won’t discuss this here and now.)


I suspect that the main reason causing this problem is underestimating the importance of simplicity.

Simplicity is actually hard. To keep things simple you have to think about them, write your ideas down and review them several times. Consider what is the goal, what resources you have, what are the pros and cons of various ways to achieve the goal. You also have to discuss your ideas and listen to other people’s ideas. Once you have somehow clear ideas you have to communicate them well. Then you have to implement them (e.g. writing some code) and organize in accordance with them (via meetings, documentation, code structure). You have to be able to resist various pressures and temptations (you must be able to say NO to most things). And you have to do all this again and again. This requires time, energy, skill, motivation, patience and persistence. On the other hand it brings satisfaction.

In case your current team/company doesn’t want or is not able to do this (and you want or are) there are three options for you:

  • accept it and consider it a party instead of chaos :-)
  • get into a (management) position from which you can influence things
  • get into a company (which seems to be) heading in the right direction

The first option is the easiest one but not necessarily the right one. Of course you can and should always strive for simplicity on individual level. But you only have a certain amount of time, energy and patience.


My infosec career evaluation

I read Daniel Miessler’s article and liked it. So I tried to evaluate myself against it.

  • ✅ come from one of these backgrounds
    • system administration 👈
    • networking
    • development
  • ✅ have a good foundation in all these and a decent strength in one
    • system administration (Linux, LDAP, hardening, …)
    • networking (TCP/IP, switching, routing, protocols, …)
    • programming (concepts, scripting, OOP basics) 👈
  • ✅ have some relevant certifications (CCNA, CISSP, LPIC-2, CCENT, CKAD)
  • nurture your programming skills; you can build websites, tools, PoCs, …
  • ✅ stay up to date (twitter, email digests, …)
  • ✅ have a lab (AWS + home server)
  • ✅ be always working on (GitHub) projects
  • ✅ make contributions (on GitHub)
  • 🚫 practice with bug bounties (BugCrowd, HackerOne)
  • ✅ have a presence (web site, blog, Twitter)
  • ✅ network with others (interact on Twitter, go to conferences, …)
  • 🚫 respond to Call for Papers (CFP)
  • ✅ professionalism
    • dependability
    • speak concisely
    • tighten up you writing
    • learn to present
  • ✅ understand the business
  • ✅ have a passion
  • ✅ you’re in your 30’s, 40’s, or 50’s, and things are looking good :-)
  • 🤏 financial knowledge
  • ✅ management experience (managing people not only projects)
  • 🤏 extensive network (know a good percentage of the major players in infosec and business)
  • 🤏 dress/etiquette :-)
  • ✅ advanced education
  • 🚫 media savvy (trained to speak with the media about various topics)
  • 🤏 tech/business hybrid (be able to speak and work with devs and managers)
  • 🤏 creativity (able not only execute what you’re given but come up with new ideas and approaches to problems on a regular cadence)

Some of the above attributes are applicable only to certain career phases (junior, senior, team lead). Others are universal.