Software engineers sometimes enable or even encourage bad security practices. You might be saying, “How dare he say that!”
It's not the technology that we've chosen or developed but rather those convenient features which continue to enable system administrators to do bad things.
For example, electronic mail (email) is probably the primary means of notifying system administrators of problems or job completion. These emails might be notifying the system administrator that a backup job is complete, a system is down, or a system must be patched.
Many vendor services such as a subscription to the Red Hat® Network will help system administrators manage their systems by sending a list of systems and the packages which need to be patched due to vulnerabilities.
As a software engineer on a product which assesses and hardens the operating system, my customers ask me for an email notification capability. I reluctantly tell them that we are working on a “secure solution” but they wonder why it is such a big deal.
When I explain to them that sending security assessment results of their systems via email isn't a smart thing to do, they can appreciate my concern but they still want the notification capability.
The thought of listing how their systems are vulnerable over an unsecured email channel just makes me cringe. By the way, it isn't just the system administrators — their own security officers are requesting such notifications. Oh, the horror.
Nonetheless, my customers want it. I've proposed implementing technology which might mitigate the risk such as encrypting the emails. However, some people think that it is just too confusing and inconvenient for the end-user to configure.
I have even suggested just sending a hyperlink to a secure console connection where they'll need to authenticate in order to see the assessment report. In the end, perhaps I can convince the team to just deliver a pass or fail status of the client machines and provide a hyperlink.
Many organizations are so scared of email attachments and phishing attacks they've set up elaborate complex mechanisms severely limiting email capabilities. When communicating with many of my customers, they request that I send emails with attachments (e.g., zip files) to their Hotmail™ or Gmail™ account because their work email won't accept such emails.
When I ask them if I can place the file on our secure public website (https), send them a hyperlink and a SHA1 finger print of the file via email, some respond with “Oh, I don't have access to download stuff from some websites.” Then I wonder why their employer permits them to go to Gmail and Hotmail.
Some have even admitted that their system administrator related notifications are sent to their free Internet email accounts. Given all of the email security problems, such as hijacked accounts, all I can say again is “Oh, the horror!”
Internal restrictions on email which result in personnel using outside resources is similar to the problem with excessively long and complicated password requirements. Users just end up writing the password down on a Post-it® note which is stuck to their monitor.
As software engineers, we want to deliver the right solutions but when it comes to commercial products, the customers drive the features. Do we simply submit to these demands in order to make a buck or do we take a stand as leaders in information security and encourage system administrators to treat vulnerability data with more care?
Cross-posted from Security Blanket Technical Blog