• Log In
  • Sign Up
    • I've been mulling on the whole use of shift-left as a theme and talking about bringing security as a focus into development of an application as early as possible. To me, this is an essential component of devops, and encouraging the building of bridges between the different silos that we get into with specializations. I'm curious how successful folks have been at doing this, and what are they doing outside of specific tools? Do you have an individual that gets assigned a security role and takes on the perspective of analyzing architecture early on? Gets involved in story planning/requirements building? Do you have someone that is dedicated to security that does this?

    • Do you have an individual that gets assigned a security role and takes on the perspective of analyzing architecture early on? Gets involved in story planning/requirements building? Do you have someone that is dedicated to security that does this?

      Great questions!

      I think it's really important for security to be everyone's job. And I don't just mean every engineer; I mean every single person at a company from the CEO to the housekeeping staff.

      Some people are experts, and they can have a large sphere of influence. Other people aren't experts, and their sphere of influence will be smaller. But everyone should think about the security and privacy implications of the work they do, whether that work is managing infrastructure, writing code, reading emails, answering phone calls, or cleaning the office.

      In terms of engineering specifically, I think one of the most valuable things each engineer can do is think about how to break stuff.

      Security is fundamentally about information: who can see it, who can change it, and the processes through which those things happen. So when I'm planning a change or writing code or configuring infrastructure or something, I try to imagine the information that will be flowing through the features I'm planning, the code I'm writing, or the services I'm configuring. I imagine the roadblocks it'll encounter and the unexpected detours it might take. In less abstract terms: I try to think of ways to break the stuff I'm building, and then I do my best to prevent that from happening.

      Prevention may mean doing something simple like ensuring that user input gets sanitized properly, or it may mean seeking out an expert who can help me understand something more complicated that I don't fully understand yet.

    • How do folks learn what the right things to think about when it comes to breaking stuff as they write code? It feels like there is a balance of doing enough at the right time as well. Is this something that gets talked about explicitly as folks join? To me, it feels like the general developer may just happen to find out about security concerns rather than it being distilled practices. I know in my CS degree it wasn't a focus at all, and many companies I've been at didn't have any kind of security program/plan.

    • Education definitely has an important role to play here. I don't have any formal training myself so I may not be the best person to pass criticism, but I think every CS program should at least include basic education about common security issues like buffer overflows (in unmanaged languages), unsanitized user input, and insecure password storage.

      Establishing a security review process for new projects and (at minimum) a security-conscious code review process for all code changes is important, and can be done even if your company doesn't have a dedicated security program.

      One of the most beneficial things you can do is to try to architect your code and services in such a way that doing things securely is easy and doing things unsafely is hard. This way new people are less likely to screw up while they learn the ropes, and dangerous mistakes are more likely to be caught because they'll probably be more obvious.

      In the web industry (the industry I'm most familiar with), I think there's an artificial divide between "security people" and developers that really isn't helpful and doesn't need to exist. The result is that web developers often don't think about security ("I'm not a security person!") and security people often look down on web developers and think they're idiots ("How can you not know about SQL injection?!").

      It would be great if there were less of a divide and more experts sharing their knowledge in non-judgmental ways. There are tons of conferences and training sessions web developers can go to to learn more about web development, but they very rarely feature security-related content, and if they do it's often as an afterthought. I'd love to see that change.

      But for individual developers who aren't sure what they need to know, I think the best advice I can give is to read everything you can. Code, articles about code, books, but especially code. You can learn so much from reading the code of open source projects you use, or even just the closed source projects you work on at your job. When you see something you don't understand, ask questions about it.

      That's more or less how I've learned everything I know. 🙂

    • I don't have a comprehensive answer ready (and I'm not an infosec person per se, much more a devops person who has come from the Ops and networking side initially). But all things considered, and acknowledging that creating an easily digestable InfoSec 101 customized to the realities of a particular project is an awesome onboarding tool that will help a lot, I always try and teach people that it is the matter of some very basic engineering. If you design something, be it a function or a system, you need to think - how will this break. And thinking about what sensitive stuff is in there and how a malicious actor can game your system to extract or misuse it is just an angle in that analysis.