January 13, 2017 at 9:40 am
richlion2 - Friday, January 13, 2017 8:20 AMhammackk - Thursday, January 12, 2017 9:24 AMThe problem is, nobody pays developers to do security, and developers aren't held accountable for the security flaws in their systems.I often myself feel like I am trying to do a very good job, but often seen as someone of an odd person. To give one example, I recently was asked to install SQL-Server and create a new database. Correct me if I am wrong, but I read a lot about the SA account and that it should not be used and disabled, so I did and created admin accounts instead. When passing the database to a 3-rd party the first thing they did was to recreate a new instance and use the SA account to setup another database because they had some sort of trouble cofiguring their part.
A few years ago when I joined my company one of my suggestions was to stop using FTP/Telnet, RCP, Etc. I started installing and using SSH, mainly it was our parent company that requested this to be used. Just today I finished installing SSH on another old outdated AIX server, thankfully I still had the old software packages. Nobody else from my admins are ever bothered that "rcp" is still in use.
I find some third party companies the bigest culprits. They develop their software, sell it, that's what only counts. They use default settings, SA accounts and you have to give PUBLIC and DB_OWNER privileges for users for the application to be able to perform it's functions. Usually after 3-6 months when a database is handed over to a DBA it turns out it doesn't even have a backup.
Consultants and commercial application vendors can be the worst. I knew of a company that used a commercial application that had hard-coded the user name SA with a password of sa. This was back in the years of SQL 2000 and when I confronted the vendor, they said that they expected the database be installed locally and the server not be connected to a network at all. Their fix was to disable the network protocols for MS SQL and run in shared memory mode. The application had no security so anyone who could get to the machine, could get to the data.
Again, the DBA team was only notified after the purchase was made and the application was deployed and in use.
January 13, 2017 at 11:09 am
richlion2 - Friday, January 13, 2017 8:30 AMEric M Russell - Thursday, January 12, 2017 10:44 AMSecurity has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice.I would agree, however there is one problem. Your management may be outsourcing a lot of applications and whatever process control you have in place cannot be used or usually is ignored by managment. Any reasonable suggestions from local admins can be ignored and are often dismissed are scaremongering. Adminstrators should be part of the implementation process right from the beginning when the opposite is the case. A DBA is the last person to be informed a new database has just been setup and is up and running. Too late to implement any serious security measures.
Where I've worked in the past, outsourced contractors would either work on-site or they would remote desktop into on-premises hosted PCs and VMs. From an environment and process standpoint, they were do different from staff developers. Ideally, a developer should at most have DB_OWNER membership, so creating logins and databases is not an option without going through the DBA.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 13, 2017 at 11:13 am
Iwas Bornready - Friday, January 13, 2017 9:22 AMToo bad they couldn't just come out with the systems fully secured so that you couldn't set them up unsecured. If we should encrypt then don't allow a system be set up that wasn't. That sort of thing. I mean if an unsecured setup is bad, why allow it to exist that way. Don't allow that kind of setup.
Windows Server and SQL Server out of the box are locked down. Someone has to explicitly add logins and grant permissions, and that someone should be outside the development team.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 14, 2017 at 6:12 am
Eric M Russell - Friday, January 13, 2017 11:13 AMIwas Bornready - Friday, January 13, 2017 9:22 AMToo bad they couldn't just come out with the systems fully secured so that you couldn't set them up unsecured. If we should encrypt then don't allow a system be set up that wasn't. That sort of thing. I mean if an unsecured setup is bad, why allow it to exist that way. Don't allow that kind of setup.Windows Server and SQL Server out of the box are locked down. Someone has to explicitly add logins and grant permissions, and that someone should be outside the development team.
That someone depends on the local processes (and staffing levels and expertise) and will vary from place to place.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 28, 2017 at 7:45 pm
hammackk - Thursday, January 12, 2017 9:24 AMThe problem is, nobody pays developers to do security, and developers aren't held accountable for the security flaws in their systems. Of course, it's hard to hold someone accountable for doing something they're not trained to do. My team wants to be more security-savvy, but there are some pretty substantial barriers to making the organization's professional development policy work for us, and in a lot of cases we don't even know what we don't know.I think we should be hiring security people, just like we hire DBAs and IT people to do different jobs, and part of the security person's job should be to make sure everyone in the organization knows basic best practices for keeping things secure. Then organizations could start having policies that enforce security practices instead of just paying for lawyers to fight for them when something goes wrong.
Sounds like a very badly run organisation. Developers should be briefed on security preferably by security people, not by DBAs (who often think they know more about security than they actually do) and in particular on any particular aspects of security that are specific to the company rather than being general stuff. And if developers are not held accountable for security flaws in their systems the management has got it all wrong: it should ensure that its developers understand securty and are trained to design and implement thigs that meet security requirements (either by recruiting only people with that knowledge or by training them) and are given what they need to provide security (so that they can take responsibility for it.
Having professional security people to ensure developers (and DBAs) understand the issues and have the neccessary knowledge is a ggod idea provided the management hiring them are bright enough to distinguish real security people from people with a pretty uniform and a trucheon (who are often called "security guards"). But if the organization is as poor at professional development as is suggested by the idea that the team doesn't even know what ot doesn't know and can see substantial barriers to having prfessional development actually work the management is probably not that bright and the team might do well to start job hunting.
Tom
April 28, 2017 at 7:58 pm
Eric M Russell - Thursday, January 12, 2017 10:44 AMSecurity has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice. For example, servers and databases in development should be provisioned by the DBA with default security in place, and developer should not have privilege to alter security settings or add logins without a change request. If the application and database objects are developed within those constraints, then the developers will soon learn what's "normal", how to code within the box, and the deliverable will deploy to production without issue.
No, it's more likely that DBAs will not undertand why development needs certain things and will refuse change requests that, if granted, would allow the development to take place more rapidly and be more thorioughly tested during the course of development, because DBAs don't understand that developers need open access to mchines for experimentation. Of course they also need some secured machines, since they have to ensure that their output works on properly configured and secured systems, but too many DBAs and SysAdmins fail to understand that.
Another point is that your environment is presumably a pretty unprofessional and unhappy one, as you recruit people who can't be trusted to use as your developers - or is that just something that isn't there but is made to appear to be there by a baselessly prejudiced "I'm a DBA and these plebeian developers are all too dim to understand" attitude that all too many DBAs and SysAdmins display, perhaps a consequence of the over-specialisation pushed by incompetent managers leading to class boundaries in the office?
Tom
April 28, 2017 at 8:29 pm
Gary Varga - Thursday, January 12, 2017 4:43 AMI have raised system security questions only to be told to assume that it was covered, when everyone knew that it wasn't, as it was outside of my area. Not the smartest of moves in my opinion.
I haven't had that problem: whenever I raised a security issue I ended up having security for the system concerned added to my responsibilities. I think that at first that was partly because the company I worked for had a lot of concern for security and partly because I had in effect specialised in being a generalist so was expected to (and did) include security in my skills.
Tom
April 28, 2017 at 8:37 pm
jarick 15608 - Thursday, January 12, 2017 2:20 PMEric M Russell - Thursday, January 12, 2017 10:44 AMSecurity has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice. For example, servers and databases in development should be provisioned by the DBA with default security in place, and developer should not have privilege to alter security settings or add logins without a change request. If the application and database objects are developed within those constraints, then the developers will soon learn what's "normal", how to code within the box, and the deliverable will deploy to production without issue.Great statement "Security has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice. "
Yes, that one sentence is dead right. It's the only thing in that post that is right, the rest is pure rubbish.
Tom
April 28, 2017 at 8:40 pm
Eric M Russell - Friday, January 13, 2017 11:09 AMWhere I've worked in the past, outsourced contractors would either work on-site or they would remote desktop into on-premises hosted PCs and VMs. From an environment and process standpoint, they were do different from staff developers. Ideally, a developer should at most have DB_OWNER membership, so creating logins and databases is not an option without going through the DBA.
Anyone who gives outsources contractors the same rights as staff developers hasn't a clue about security; outsourced developers cause more breaches than staff developers (and underpaid staff secretaries cause more breached that developers), and outside developers using remote desktop access should never be given the privileges that developers need to do their jobs. Outsourced contractors on a personal contract working on-site to do development are less of a problem and need many of the privileges developers need, but you will not know them as well as you know your staff so again why trust them as much?
Tom
May 1, 2017 at 6:58 am
Iwas Bornready - Friday, January 13, 2017 9:22 AMToo bad they couldn't just come out with the systems fully secured so that you couldn't set them up unsecured. If we should encrypt then don't allow a system be set up that wasn't. That sort of thing. I mean if an unsecured setup is bad, why allow it to exist that way. Don't allow that kind of setup.
This kind of statement is a perfect example of the problem. I'm not mocking, I'm being very serious.
Those of us not directly involved with info-sec (i.e. everyone but hackers) have no idea what security really is, how it can be circumvented, or what LSD-induced nightmare prompted finding the latest vulnerability/security hole/flaw/bonzo technique hackers will stumble across next.
99% of new exploits are "unknown unknowns". Not only do you not know it needs protection/mitigation you often have no clue such a thing was even possible.
So, in answer to your question about perfectly secured systems out of the box, the answer is--don't open the box! :Whistling:
May 1, 2017 at 8:59 am
This has dramatically improved, and secure out of the box is close. Privileges, remote access, and more aren't enabled. Homegroups in Windows don't have default shares, nor do they allow open access without setting passwords.
Many, many systems have improved their default security. There still are options, encryption being one, but part of that is encryption is serious. If you forget or lose a password, there's no way to undo encryption (in a practical, cost effective sense), so people must make a decision on install to have a flash drive or other way to store the key securely. Many don't. Especially developers.
There are quite a few social engineering or phishing items that are hard to protect against, and we're not at the point where the software can make all decisions, especially in mixed environments. If we could draw a line in the sand, abandon pre-Win 8, WS2012, OSX10, etc., we could do better, but lots of orgs aren't ready for that.
I'd never setup a device without encryption or even 2FA, ever. They aren't perfect, but they solve lots of issues. I'd rather lose some data and have to reinstall than walk around insecurely. However, our systems aren't designed from the ground up to be secure. I had hoped that the NSA's work with *Nix would give us a really secure system that separated auditing from root level access and allowed setup, but at this point, we can't trust anything built with the NSA. Maybe nothing.
At the least, I'd hope that we could continue to publish more info, and one thing I'd like to see is vendors including a "secure checklist" with their installs so people that aren't as up to date (and I'm not, even though I try to watch for issues) would know which things are recommended.
Viewing 11 posts - 16 through 25 (of 25 total)
You must be logged in to reply to this topic. Login to reply