by Randgalt on 9/9/17, 3:39 PM with 151 comments
by mevile on 9/9/17, 3:54 PM
Having said that, definitely keep up on the vulnerabilities of software you use. It's hard though, especially when you're relying on a great deal of dependencies. A company the size of Equifax should have had a team dedicated to this. A team. It doesn't seem like they had anyone who knew anything about basic security at all.
by smaili on 9/9/17, 3:50 PM
1. Understand which supporting frameworks and libraries are used in your software products and in which versions. Keep track of security announcements affecting this products and versions.
2. Establish a process to quickly roll out a security fix release of your software product once supporting frameworks or libraries needs to be updated for security reasons. Best is to think in terms of hours or a few days, not weeks or months. Most breaches we become aware of are caused by failure to update software components that are known to be vulnerable for months or even years.
3. Any complex software contains flaws. Don't build your security policy on the assumption that supporting software products are flawless, especially in terms of security vulnerabilities.
4. Establish security layers. It is good software engineering practice to have individually secured layers behind a public-facing presentation layer such as the Apache Struts framework. A breach into the presentation layer should never empower access to significant or even all back-end information resources.
5. Establish monitoring for unusual access patterns to your public Web resources. Nowadays there are a lot of open source and commercial products available to detect such patterns and give alerts. We recommend such monitoring as good operations practice for business critical Web-based services.
by gedy on 9/9/17, 3:55 PM
by orange_county on 9/9/17, 4:07 PM
by solomatov on 9/9/17, 7:17 PM
by idibidiart on 9/9/17, 6:22 PM
by 0xbear on 9/9/17, 6:38 PM
by throwaway699552 on 9/9/17, 4:13 PM
by yogthos on 9/9/17, 4:05 PM