Legacy applications are a brush fire waiting to happen. But retrofitting custom code built in the early 2000's is just a small part of the application security problem.
Security hasn’t changed much in the last 10 years. Companies still use pattern matching and pattern-based defenses which aren’t enough to protect websites and company data from the bad guys. Hackers continuously find unique ways to create fuzzing techniques or to perform fuzzing to create new exploits, and a lot of companies can’t run regular expressions, and most can’t use pattern matching to defeat that.
In order to protect against cross-site scripting (XSS) or SQL injection (SQLi), why not look at application security through the lens of a web browser or a database engine? What if there was a unique way to solve these problems instead of just solving it at the perimeter? Why don't companies protect from within the application where they have access to contacts and important contextual information? Most say it's lag time, or performance issues that inhibit this kind of solution. But I’m not so sure.
Runtime Application Self-Protection,
Runtime Application Security,
A recent Wall Street Journal article outlines that health insurer Anthem did not encrypt its data and that this was one of the major factors resulting in the very public theft of masses of personal identifiable information (PII).
There has been some discussion around the method of penetration with stolen credentials meaning that the value of encryption would have been nullified. Without knowing the details, I don’t feel qualified to reach a conclusion on that but it seems hard to fathom that a single user would have had access to the keys to decrypt everything.
On top of developing runtime application self-protection tools, the Prevoty Engineering team is always looking for better technologies to manage our cloud and on-premise service-oriented architectures. A package of the Go standard library that we use extensively is
net/rpc - this particular package simplifies the approach and LOC when it comes to developing your own RPC. If you're unfamiliar with Go, then I highly recommend that you take the tour - it's worth it.
Based on the positive feedback we've received from our customers, the Prevoty engineering team has added seven new typed input validations:
- Credit Card numbers
- IPv6 addresses (in addition to the previously released IPv4 validation)
- MAC addresses
- UUID (MAC address + DCE Security)
- UUID Version 3 (MD5 hash)
- UUID Version 4 (random)
- UUID Version 5 (SHA-1 hash)
When we started Prevoty, one of our main goals was to give developers a systemic approach for creating and managing secure applications. Our product roadmap began with the ambition of preventing the most difficult OWASP attacks and over the last 18 months, our engineering team has created novel algorithms and technologies to prevent XSS, SQLi and CSRF. On top of that, our team has developed an on-premise version of the Prevoty engine while continuing to support nearly a dozen different SDKs + frameworks (servlet filters and HTTP modules). We've covered a lot of ground in such a short period of time!
Talking with people in the industry at large, there is no question about the high level of admiration (and sometimes a bit of envy and angst) for what Amazon Web Services (AWS) has done to revolutionize the world of IT infrastructure. But I’m not sure everyone is aware of just how critical AWS has become to the startup world in particular.
photo by sylwia bartel
Despite efforts to incorporate security into the web application, enterprises find themselves forced to take shortcuts, so they can address other security projects. Meanwhile, user content continues to be unprotected, resulting in fire drills between the web developers and security team. We've highlighted a few myths that top security experts and leaders have shared with us to debunk common misconceptions of web application security: