Circumventing common Pitfalls when auditing sourcecode for Security vulnerabilities Aljosha Judmaier & David White
The awful truth
There is no magical patch that will make everything secure
Vendors don’t tell the full story
Security is rarely considered in the development process
Tools are useful, but only in the right hands
Security tools rarely prevent developers from make security mistakes
Often the term security refers to the use of security features
But in reality these default measures can be easily bypassed
Security Features vs. Secure Features
Security features may or may not be enough to protect an application
Secure Features are secure by their very definition
Vulnerabilities that are found late in the development process cost more than those found earlier in development.
Faults found later on are also less likely to be fixed due to time/cost.
So what is a “security problem”
Something that affects the output or the input in a negative way (in regards to the CIA triangle)
Even small things can be a big problem when put in the right context
Secure Development Life-Cycle
- Plan
- Design
- Implement
- Test / Acceptance
- Deployment
- Compliance Checking
- (Security Feedback ?)
The process should be flexible enough to take input from each stage and go back to an earlier stage to correct issues/faults discovered
Security, Threat Modeling and the SDLC
Take a diagram of your software architecture and mark all points where possible attacks/security issues could be an issue.
This doesn’t need to be in a specific structure, maybe it could be as simple as a brainstorming session on a whiteboard
Important to take into consideration all possible inputs and draw specific trust boundaries
Good baseline for risk management
Useful as a way to express ideas and possible vulnerabilities to management
Thanks to @pyerm for the picture
Performance indicators
- Experience
- External Personel
- Small Teams
The only valid measurement of code quality… WTFs/minute
Tools vs Humans
Type of vulnerabilities is important for comparisons
Tools: Known vulnerabilities
Human: More intelligence behind testing
Clever Tools
Not all tools are dumb scanners however.
Examples:
- Pixy (TU Wien)
- WALER (TU Wien)
- SECoverer
Root cause
Bad code is written by… developers!
By understanding the environment developers work in to develop code.
With that understanding, you can incorporate tools and checks into the already present processes and systems.
Automate the process of QA and development communicating to transfer the correct information at the correct time and to the correct people.
SECoverer
A security workbench built on-top of Eclipse (multi-platform)
By building on-top of an already used interface, it allows for support for any programming language supported in Eclipse
Allows for collaboration with development and QA as it uses the same underlying platform
Unified open analysis platform (static and dynamic)
Provides monitoring and reporting for security issues and code coverage
Integrates with bug tracking systems
Open APIs for easy integration with external systems
Is it open-source
No…
Demonstration versions are available however
Planned open-source component to support the Analyzer Module Interface
Like this:
Like Loading...
Related
Cатсн²² (in)sесuяitу / ChrisJohnRiley 