Do Software Engineers Encourage Bad Security Practices?

Tuesday, April 26, 2011

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

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

Possibly Related Articles:
7490
Security Awareness
Information Security
Email Hardening Software Employees Policies and Procedures Engineers
Post Rating I Like this!
681afc0b54fe6a855e3b0215d3081d52
Susan V. James I doubt you can change their behavior. The only thing you can do is deliver information over the medium they want (or make a close approximation of it) and come up with a way to do that securely. Barring that, the acceptable secure forms of notification should be documented in the customer's contract, and they should sign off on any variations they want to make that take them outside of an acceptably secure form of communication.

Perhaps if more employers started demanding that their sysadmin / engineering staff have at least one of the entry-level security certifications, we would see a change in how systems administrators think about security. I used to be a sysadmin who thought that after 15 years as a UNIX and firewall admin, I knew all that I needed to know about security. I then undertook study for my first certification and realized in fact how little I really knew or understood, and how my limited knowledge could have exposed my employer to unnecessary risks.
1304003414
4085079c6fe0be2fd371ddbac0c3e7db
Jamie Adams Susan... your feedback always makes me think -- thank you for that.

In the end, it is the organization's responsibility to safeguard their data and their right to choose the manner in which to disseminate it. As a software engineer, I try to implement as many safeguards as possible and warn the user but in the end... it is on their shoulders.

Yes, I recall from some other feedback you provided that you were a sysadmin for many years. When I was a young sysadmin, my number one priority was always system availability at all cost. If that meant circumventing a few things to achieve high system availability -- then so so be it. Data integrity was important but the easiest thing to measure in those days was availability.

That is a bit naive but I wonder how many of today's young sysadmins believe that. So, your suggestion of requiring at least one sysadmin have at least an entry-level security certification is spot on.

As a software engineer, I still feel obligated. Much like engineers who design and build cars which can go 150+ miles an hour... what kind of safeguards if any do you put in place to prevent the novice driver from killing themselves??

Thanks again for your feedback.
1304009078
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.