Forming a Computer Security Incident Response Team (CSIRT) is a complex affair. It normally involves a certain combination of staff, processes and technologies.
However the essentials are the same in most situations, no matter what the mission of your CSIRT is. This publication attempts to provide a list of must-have technologies for all forming incident response teams out there.
One of the security risks of software development is passwords and other credentials hard-coded into the source code.
A quick analysis of the leaked Ashley Madison dumps shows that software developers of AM forgot about these risks. Their source code contains AWS tokens, database credentials, certificate private keys and other secret credentials.
The consequence of this is a more vulnerable infrastructure, which probable made the lateral movement easier for the Impact Team.
Even pure technologists have to write security policies in an enterprise environment. As a subject matter on something, technology experts might be asked to contribute to the Software Development or the Internet Acceptable Use policies.
However this leads to policies that nobody reads. Copy-and-paste texts, dry language and 60-page long documents. Rings a bell, anyone?
In the following post I reveal a few tricks up my sleeves for writing simple, crystal-clear and straightforward security policies.
While ISPs in the UK and other countries are blocking file sharing websites such as The Pirate Bay, movie-lovers have different alternatives to circumvent these restrictions. One popular way to overcome the filtering is using mirrors.
Torrent mirrors are essentially reverse proxies, which are forwarding HTTP traffic between the UK and the original sites hosted elsewhere. Data supposed be left intact and the only difference should be the address in the URL bar.
This experiment proves however that 99.7% of the tested BitTorrent mirrors are injecting additional JavaScript into the web browsing traffic. A great share of these scripts serve content with malicious intent such as malware and click-fraud.
I took the recently leaked git repos from of Hacking Team from GitHub and ran them through a couple of static code analysis tools.
Manual analysis has successfully unfolded a few 0days. Hopefully these results may assist further research.
While Hacking Team was cleaning up the mess, security professionals were raging on Twitter. The company was publicly shamed for its bad passwords, worse reaction and questionable business practices on social media.
But was it really necessary to post random screenshots of private emails from the 400 Gb pack, totally out of context? Or mock HT employees because of something they already knew? Dumping their source code on GitHub?
Thoughts on the recent breach at Hacking Team, privacy and responsible behavior of security professionals