November 15, 2014 at 7:53 am
I particularly like the point Steve makes about email. Companies put security policies and technical controls in place, then employees inundate each other with loads of email and attachments. So many CYA emails are sent with piles of attachments that it turns into a legitimate and very real security problem.
I once saw an email where someone sent a username to an external client. Since the password has to be sent separately, the obvious choice was to not include it. Instead, she replied to the first email and sent the password, after all, it was a separate email! :w00t: I think that somehow, the intent was lost. I'm sure we all have stories like this, but the point is that if people would stop and think for a minute, things would get better as a whole.
November 16, 2014 at 9:58 am
I think we all recognise the need for good security practises.
I'd like to see some thought given to the policies and procedures that are inflicted rather than enforced.
A 273 page document written in legalese? What an utter waste of time and effort. Any policy or procedure should be designed to help achieve a desirable outcome while enforcing discipline. A security policy that obstructs the day to day operation of a business shows a lack of joined up thinking. It fails to ask "We have a legitimate need to do 'X', how can we do this in a secure way that is straight forward for our employees to adopt and practise"?
If something obstructs us in our day to day life we either give up or find a way around it. Human beings have been finding a way around things for eons and will continue to do so.
My latest bug bear is a company laptop that will happily connect to my router but not beyond to the internet and thus to the companies extranet. There are quite a few entries on Google as to why this might be the case however the laptop is locked down in such a way as to prevent any diagnosis or action to resolve it. Obviously without having the administrator come around to my house this isn't going to get resolved any time soon. The result? I don't work from home or dial in after hours.
November 16, 2014 at 1:29 pm
Could we be looking at this from the wrong way round? Should our languages and components not put security first? Should it be a little harder to make insecure applications?
I think so.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 17, 2014 at 7:30 am
Gary Varga (11/16/2014)
Could we be looking at this from the wrong way round? Should our languages and components not put security first? Should it be a little harder to make insecure applications?I think so.
The way it works now is that security settings can be congifured seperately, making it hard assess whether a database is generally secure by a common standard. Perhaps what we need are declarative security levels, at the database level, that enforce a standard set of security policies at each level. For example, at security level 1, TDE must be turned on, the functionality to add members to db_datareader / db_datawrite would be disabled, CRL and denamic SQL are disabled, cross-database joining is disabled, etc. To enable those options, the DBA would have to set the database security level to 2. So, rather than trying to govern every possible security option seperately, there can be an organizational policy that all databases must operate at security a specific security level.
ALTER DATABASE [Sales] SET SECURITY_LEVEL 1;
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 17, 2014 at 4:31 pm
Gary Varga (11/16/2014)
Could we be looking at this from the wrong way round? Should our languages and components not put security first? Should it be a little harder to make insecure applications?I think so.
I'd argue our OSes should be written to assume the worst, and implement security from the ground up. Also, we should allow for delegation, easily, and sub-sets of groups.
Our applications and components secured as well, assuming people will attack
November 18, 2014 at 5:12 am
Steve Jones - SSC Editor (11/17/2014)
Gary Varga (11/16/2014)
Could we be looking at this from the wrong way round? Should our languages and components not put security first? Should it be a little harder to make insecure applications?I think so.
I'd argue our OSes should be written to assume the worst, and implement security from the ground up. Also, we should allow for delegation, easily, and sub-sets of groups.
Our applications and components secured as well, assuming people will attack
Total agree. When coding I often consider parts of the OS (whichever one) as components. Secure from the ground up is the only way to do it.
This would have the additional benefit of people learning to code will have to learn to consider security and code securely from day 1.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 18, 2014 at 8:41 am
Steve Jones - SSC Editor (11/17/2014)
Gary Varga (11/16/2014)
Could we be looking at this from the wrong way round? Should our languages and components not put security first? Should it be a little harder to make insecure applications?I think so.
I'd argue our OSes should be written to assume the worst, and implement security from the ground up. Also, we should allow for delegation, easily, and sub-sets of groups.
Our applications and components secured as well, assuming people will attack
I would agree. That said, I suspect the quickest and cheapest way to do that is throw out everything smaller than mainframe OS's and start from there, since "implement security from the ground up" starts at requirements and then flows to design.
Fast, cheap, good, secure: pick at most two.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply