More Network Restrictions This past year has seen quite a rise in ransomware attacks. Certainly some big ones (Baltimore, Florida) are reported in the media, but there are lots of smaller ones that don't make the news. As I've been attending some events in the last couple months, I've talked to various people that disclose they've had ransomware issues. Most of those didn't make the news, but the events did cause IT staffs to scramble, work long hours, and forgo other tasks that might be improving the organization or helping customers. We know that there will be attacks on our organizations in the future, and some of them may be successful. Almost everyone is regularly attacked, though most are repelled with simple firewalls and better coding to prevent SQL injection. There are other things we can do, and certainly other groups in IT that need to worry about systems, but I suspect we'll start to see one more change in how we work. Recently I was accepted to speak at SQL Saturday Memphis and really enjoyed the trip. However, when practicing one of my demos early in the am, I had trouble connecting to some remote resources. It wasn't obvious what the issue was, and since I wasn't in control of the endpoint for demos, I worried that the instratructure had an issue. Not what you want to see on a Saturday before a demo. Eventually I narrowed this down to port 1433 being blocked. Not a big deal as I had a VPN, but certainly something to be concerned about for a database professional. However, then I thought about the ransomeware and other security issues many organizations have had. Maybe some restrictions are a good thing. I wrote about networking segmentation, as did Joey D'Antoni, and I think this is where we will move in the future. After the SQL Slammer worm, plenty of organizations changed networking policy to hide port UDP 1434, which was good. I think some have gotten lazy, and the security issues we are seeing today might change things. That's going to mean less access for people to connect to machines. That also means we need to think about DevOps style automation pipelines for code. We need to learn more about how to let machines run scripts for us and limit access. That way if our machine is attacked, we won't necessarily be able to spread the issues to servers. We'll still have plenty of other machines that might get hacked, but hopefully we can protect our servers. Security has become a bigger part of the job for all IT pros, and certainly critical for database pros. I hope that most of you embrace more stringent security and not try to circumvent it. Use automation, proxies, and more to keep your systems secure. And if they don't quite work as you'd want them to, learn how to adjust them and work with the system, not against it. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums | 
