Thanks to everyone who attended the first Crash Course Series webinar. As we ran out of time before answering all of the questions at the end (and thank you all for so much participation!), I thought I’d pull the unanswered and reply to them here in longer form than the time allotted.
Q: Do we expect performance issues from AES?
A: That depends largely on how you are using it. For a review of the relative speeds of various cryptographic algorithms, I recommend looking at the speeds and feeds section of comparative studies done. You can decide from either of these if AES is the algorithm of best choice depending on what functionality you are calling.
Q: Considering current ransomware/zero day exploits, do you think HTTPS is comparatively weak to these attacks?
A: No, but mostly because this is not the right question to ask. HTTPS is always a good idea. Aside from Google’s announcement that HTTPS will improve your SEO ranking algorithm, HTTPS is required if you accept payments OR personal information for any reason. HTTPS is part of the solution. It is, however, not the entire solution.
As an additional thought – there is a category of server-side ransomware attacks such as Samas.A or SamSam. This Ransomware started by victimizing servers based on JexBoss/JBoss de-bugging tools used by your developer teams, and has been seen graduating into a brute-force tactic against weak Remote Desktop Protocol passwords.
Q: How do DevOps practices come into play with assuring secure site development?
A: Security by Design is a key control point for compliance these days, from the extremely detailed NIST Systems Security Engineering to much more vague (on details) GDPR article on Security by Design. I like a simpler way of summarizing: Find your control points in DevOps, and test early and often. You can think of it as testing in stages linearly:
Or insert checks into your DevOps workstream:
Howsoever you choose to implement DevSecOps – remember that you cannot alter all your development processes overnight. This breaks your production stream, which is never desired. DAST and SAST may be the simplest first steps, and easiest to begin.
Q: Is designing the HTML form with malicious content the only way to test for CSRF? Are there simpler ways to do it?
A: I really like the OWASP page summary on CSRF for providing multiple scenarios in testing. I recommend this and all of their pages highly.