|
It depends, of course. Notably on what you mean by SecDevOps. One on hand, as suggested by jotato, it might be a 'security-aware' DevOps team, in which case, I would suggest looking into things like CIS benchmarks, and tools like openSCAP - i.e. how to build and deliver security-hardened infra.
Similarly, you might look into things like the Calico project for a tool to help deliver secure networking infra, IPSEC, and so forth. One the other hand, you may be thinking of automating the job of the security team, in which case, you would be looking into things like distributing blacklists across the company, automated revocation of tokens/certs, server isolation and re-imaging (or forensic analyst, or both). For that, the ultimate answer is that it really depends on your current security situation and infra, and what your risks are.
You might be fine with having a central distribution point for snort(/suricata/broIDS) rules, and centralised logging.
On a much lower level, fail2ban could be seen as a means of automating security (you can make it read your IDS logs, too). As has been noted, though, do consider this approach may be putting too many eggs in one basket: notably, you might want to consider the tension between the Sec and DevOps roles - asking for one team to handle that tension alone would (to me) require you put great faith in their ability to correctly choose between putting security and agility first - something that might be better done by having each side represented by someone who really owns each concern. I guess the question to ask here is what have you got, and what are you trying to do? |