4 ms·

For all you hacker types out there. I'm a software engineer who knows very little about security. Any good resources to learn it? Currently my company just ass

For all you hacker types out there. I'm a software engineer who knows very little about security. Any good resources to learn it? Currently my company just assumed that Spring handles all those issues for us.

typicalrunt 6y ago
Security is mutli-faceted, so it's hard to know where to start. I like to help people begin by getting them to learn the fundamentals. A lot of security training is changing your mindset (perspective) on situations. Two books I like to start this process: * Threat modeling by Adam Shostack * CISSP all in one handbook by Shon Harris You don't need to get a CISSP cert, but the resources and education are generally applicable in most situations.
- banads 6y ago
  If you're looking for something more practically related to securing the code you write, the OWASP Top 10 (and OWASP in general) is probably the best place to start. Many modern frameworks like Spring have lots of nice security features baked in, but I've still seen plenty of low hanging Top 10 vulnerabilities in Spring apps -- most often caused by simply failing to use allowlist (formerly known as whitelist) validation on key inputs. It is astonishing how often people neglect basic programming best practices (input validation, error handling, logging, access control) which in turn leads to security vulnerabilities. My theory is this is caused moreso by Agile Management forcing developers to cut corners, rather than just developers being ignorant/lazy. https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_Top_10.html https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top... Threat modeling can be a good practice to learn, because it gets you into the habit of thinking about how you could hack each new thing you're developing. I dont think the CISSP is a good recommendation for this person's case, unless they plan on becoming a cyber security manager.
  - typicalrunt 6y ago
    That's not my point suggesting CISSP. The book I recommended takes the reader through the different OSI layers for networking and security, a basic intro to threat modeling, and other stuff that is fundamental to security. One can always skip the managerial stuff, but it doesn't mean the CISSP book is not a good recommendation. Also, having a developer understand the value and need for code security from the perspective of a security person is important to the overall success of an infosec program. Otherwise both engineering and infosec are going to be grating on each other.
- tptacek 6y ago
  Ignore threat modeling and CISSP, both of which are industry kabuki dances. The rest of the advice in this comment is fine.
tenebrisalietum 6y ago
- Validate ALL data that comes from external sources, even if you think it could not possibly be changed unexpectedly. External sources includes things like user input, configration and session files, and even things like dynamic libraries if you care enough. - Sending data to an external system that processes commands, including destructive ones like DROP DATABASE? Verify what you're sending doesn't contain commands you don't want to run, each time, every time. - If you are programming in C or derived, and using expressions that will be involved in array indices or pointer arithmetic, make sure the expression falls within acceptable range before using the resultant data. Since NULL or 0 is an invalid pointer value, it shouldn't ever reach the code that tries to access pointers. - Should a sensitive function only be called from certain other functions? Should a sensitive variable only be modified/accessed from certain other functions? Enforce that. - Someone will eventually find anything that's not documented, so don't rely on that for security. Don't expose an interface (especially not through any network accessible method) without an authentication or verification mechanism if it's not OK for it to be 100% public. - Define everything. A function call should never have an unexpected result. Invalid inputs should cause the function to return errors or throw exceptions. The above is a good percentage of it I think.
- tptacek 6y ago
  Telling people to "validate all data" is like telling them "not to have security bugs". It's not helpful advice. Validate for what? Length? SQL metacharacters? Javascript notation? HTML? Authentication? Concurrent submission? The list of things to consider is essentially a list of practically all vulnerabilities.
  - MattGaiser 6y ago
    I know a lot of forms out there that will accept any input. The standard to improve upon here is often rock bottom. A lot of developers do not know that data should be validated.
    - tptacek 6y ago
      The point isn't that you shouldn't validate data. It's that telling developers to validate data doesn't help them. It begs the question of "how" to validate data, and the answer to that question is so big that it encompasses most of software security. Meanwhile, left to their own devices after that one instruction, developers come up with silly input validation schemes, like password fields that don't accept SQL metacharacters.

typicalrunt 6y ago

Security is mutli-faceted, so it's hard to know where to start. I like to help people begin by getting them to learn the fundamentals. A lot of security training is changing your mindset (perspective) on situations. Two books I like to start this process: * Threat modeling by Adam Shostack * CISSP all in one handbook by Shon Harris You don't need to get a CISSP cert, but the resources and education are generally applicable in most situations.

banads 6y ago
If you're looking for something more practically related to securing the code you write, the OWASP Top 10 (and OWASP in general) is probably the best place to start. Many modern frameworks like Spring have lots of nice security features baked in, but I've still seen plenty of low hanging Top 10 vulnerabilities in Spring apps -- most often caused by simply failing to use allowlist (formerly known as whitelist) validation on key inputs. It is astonishing how often people neglect basic programming best practices (input validation, error handling, logging, access control) which in turn leads to security vulnerabilities. My theory is this is caused moreso by Agile Management forcing developers to cut corners, rather than just developers being ignorant/lazy. https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_Top_10.html https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top... Threat modeling can be a good practice to learn, because it gets you into the habit of thinking about how you could hack each new thing you're developing. I dont think the CISSP is a good recommendation for this person's case, unless they plan on becoming a cyber security manager.
- typicalrunt 6y ago
  That's not my point suggesting CISSP. The book I recommended takes the reader through the different OSI layers for networking and security, a basic intro to threat modeling, and other stuff that is fundamental to security. One can always skip the managerial stuff, but it doesn't mean the CISSP book is not a good recommendation. Also, having a developer understand the value and need for code security from the perspective of a security person is important to the overall success of an infosec program. Otherwise both engineering and infosec are going to be grating on each other.
tptacek 6y ago
Ignore threat modeling and CISSP, both of which are industry kabuki dances. The rest of the advice in this comment is fine.

tenebrisalietum 6y ago

- Validate ALL data that comes from external sources, even if you think it could not possibly be changed unexpectedly. External sources includes things like user input, configration and session files, and even things like dynamic libraries if you care enough. - Sending data to an external system that processes commands, including destructive ones like DROP DATABASE? Verify what you're sending doesn't contain commands you don't want to run, each time, every time. - If you are programming in C or derived, and using expressions that will be involved in array indices or pointer arithmetic, make sure the expression falls within acceptable range before using the resultant data. Since NULL or 0 is an invalid pointer value, it shouldn't ever reach the code that tries to access pointers. - Should a sensitive function only be called from certain other functions? Should a sensitive variable only be modified/accessed from certain other functions? Enforce that. - Someone will eventually find anything that's not documented, so don't rely on that for security. Don't expose an interface (especially not through any network accessible method) without an authentication or verification mechanism if it's not OK for it to be 100% public. - Define everything. A function call should never have an unexpected result. Invalid inputs should cause the function to return errors or throw exceptions. The above is a good percentage of it I think.

tptacek 6y ago
Telling people to "validate all data" is like telling them "not to have security bugs". It's not helpful advice. Validate for what? Length? SQL metacharacters? Javascript notation? HTML? Authentication? Concurrent submission? The list of things to consider is essentially a list of practically all vulnerabilities.
- MattGaiser 6y ago
  I know a lot of forms out there that will accept any input. The standard to improve upon here is often rock bottom. A lot of developers do not know that data should be validated.
  - tptacek 6y ago
    The point isn't that you shouldn't validate data. It's that telling developers to validate data doesn't help them. It begs the question of "how" to validate data, and the answer to that question is so big that it encompasses most of software security. Meanwhile, left to their own devices after that one instruction, developers come up with silly input validation schemes, like password fields that don't accept SQL metacharacters.