Thursday May 17, 2007
By bartbl on May 17, 2007
The 5 cent tour of Solaris Role-Based Access Control is a five minute overview of the main bits and pieces of RBAC.[Read More]
Wednesday May 09, 2007
By alecm on May 09, 2007
A man is going on vacation (ie: on holiday) - and he's worried about the possibility of someone breaking into his house whilst he's away; so he checks all the window locks from inside the house, steps outside, walks around the house to inspect for anything he's missed - checking that patio doors, etc, are locked - then locks his front door and drives off. What's he done wrong?...which is my usual schtick for trying to explain the importance of doing things in the right order, because even if you have the right security-ingredients you can still mess up by not using them properly, or not laying them out in a sensible manner. I was blown away by some of the creativity that was provided in the responses - the person who went for the jugular and got my typically sought-for answer was Andy Paton:
While he was busy checking the windows and backdoor he left the front door unlocked!!...which is the obvious flaw in the process; it's astonishing how many people completely miss that. That said - and thank you Andy - this being an open question there is always room for a different perspective, eg: trojan horses:
- Wes W:
- Apparently he's assumed someone hasn't already broken in or compromised existing security already. For example, your vacation man didn't seem to check the interior for a trojan horse (stowaway) and he didn't change the locks.
- Mark Musante:
- He hasn't checked the first floor?
...the architectural and integrational:
- My first thought was that it has to relate to the "then locks his front door" i.e. he hasn't 'tested' his security from the outside in the state it will actually be in. As the other comment mentions, he ahs also left the door unlocked while checking! And the second thought was around "and drives off" - the car present/missing is a clue of his absence but I can't see much that you can do about that unless you religously use the garage (which isn't stated either way, so I supect it isn't that).
...and the slightly tongue-in-cheek operational risk:
- assuming it's a single story house without any other mean of entrance except doors and windows and all access will need separate keys; so he checks all the window locks from inside the house - should check/test the locks from the outside. steps outside - How, through what? - Lock it from the outside before proceed. Checking that patio doors - How does he protect it? it's a big visual vulnerability. Does he taken steps to make like the house has someone living [in it and is] not abandoned. interactive :)
...all of these are legitimate and interesting answers; even the last one by analogy of the occasion I saw someone enable system-auditing in a particularly nitpicky mode, only to see the machine crash from filling its root partition two days later. This is related to the reason I generally put /var/log and /var/adm on a partition completely separate from root and the normal /var - it's a signature perversity of a Muffett-specified machine, but your machine is at less risk from log-flooding.
- Tom Hawtin:
- He hasn't checked that the iron is switched off. He returns to find a perfectly secure but somewhat charred house. With two weeks worth of milk on the doorstep.
So, next time I have to stand up and give this talk to somebody, I'll have something extra to say. Thank you folks, and thank you for sharing. Thank you also to Tom for this little gem which made me smile:
He should check that the front door is locked, from the inside? My father's old front door you could open the lock through the letterbox using a handily located small crowbar....which just goes to prove that security can be perfectly acceptable if it fits your environment; I still know places where nobody bothers to lock their doors when they go out for the day, but nowadays they seem somehow fewer and further between...
Friday May 04, 2007
By alecm on May 04, 2007
Last week, security expert Bruce Schneier caused a bit of a stir when he said that there shouldn't be a security industry. While his comment engendered a lot of debate, it really wasn't a particularly radical statement. As he's made clear in his latest Wired column, all he meant was that IT vendors should be building security directly into their products, rather than requiring customers to purchase security products and services separately.
...citing Bruce as reported at Silicon.COM:
"The fact this show even exists is a problem. You should not have to come to this show ever. [...] We shouldn't have to come and find a company to secure our email. Email should already be secure. We shouldn't have to buy from somebody to secure our network or servers. Our networks and servers should already be secure."
...and I think he is right, as I find Bruce generally is. My experience bears this out - I have friends who ask "What Anti-Virus Software / Malware Detector / Intrusion Detection System Should I Use?" - and in none of these cases do I actually have an answer for them.
Sometimes they must really wonder what I do for a living, if I'm a "security expert" and don't know what AV software to use.
It's true, however. Given what I use at home (Solaris, Mac, Linux, and an solitary and rarely booted XP system), plus the manner in which I connect to the Internet (NAT/firewall built in to my DSL router) and the fact that I understand the value of keeping security patches up to date, not running services/daemons unless they are necessary, and cycling WEP and login passwords occasionally, with all that in place I don't have to use any specialist security software at all.
Instead I use what tools I have available with my network hardware and software platforms - generally some form of Unix - making sure they're all properly deployed. Sometimes I get a hacker knocking on my door, I've certainly seen a few attempts in my logfiles, but it's not something I fret about since there's very little exposed to attack, and of the latter it's all generally well-maintained.
So why should I worry? Beats me. The Silicon.COM article also contains this quote from Graham Cluley at Sophos:
"I can't imagine there ever being a 100 per cent secure operating system because a vital component of programming that operating system is human."
Well yes, Gray, you're right, but one of the things you've left unstated is that there is no such absolute thing as 100% security.
Security is relative: 100% security means "100% Adequate" security, that the security features you've deployed are proportionate to the exposure you make in transacting with the rest of the network, plus mitigation of any risks you face in terms of availability ("I can't access my Gmail! Argh!") or physical security ("Someone stole my laptop!")
No, there won't ever be a 100% secure system, but people who care are currently able to get systems which are adequately "secure by default" and if they know how to use and maintain those systems properly then yes, there won't be a security industry any more.
Thursday Apr 26, 2007
By alecm on Apr 26, 2007
We were in the midst of some on-the-fly rearchitecture discussion (read: "if we replumb it all in a more elegant fashion, what needs to be fixed or added in order to make it safe?") and it turned out that an extra firewall to demarcate a line between some public and private machines, would make matters a lot more secure.
"It'll cost a lot, this new firewall", says their long-haired sysadmin.
"Why", says I?
"Firewall license" says he, and names a largeish four-figure number. Eek. That's more than the hardware!
So one of the things I've never understood - and I've told him this - is why the "Cult Of Firewall" is such that only a "dedicated box or appliance" running "genuine firewall software" for which $$$$$$ are paid, is what people go running towards whenever firewalls are mentioned.
Sure, in an enterprise context where people bandy words like "five nines" (ie: 99.999% uptime) - or "extreme(ly) high availability", or where you need "management consoles" - then do buy an enterprise solution where you might be able to sue the vendor if it blows up.
But if you are a small-to-medium organisation with your own in-house pet geeks, then why not take advantage of general-purpose functionality of general-purpose operating systems and deploy Solaris, Linux or \*BSD as a firewall? Consider your choice carefully, minimise it to the utmost, but it'd be a lot cheaper and often perfectly adequate and more than adequately performant.
I started at Sun in 1992 and if I had had more business sense back then, and if I had had more money, then I would have cottoned on to the number of SparcStation2's that I was buying, to act as "routers" for our intranet. This observation might have led me to invest in Cisco and its dedicated routers, and made me a tidy profit. Oh well.
But the thing about IT security is that "what goes around, comes around". Maybe it's time for the comeback of the general-purpose operating system, in tiny tasks, on more-than-adequately-powerful hardware?
 yes, this is an intentional pun. :-)
Tuesday Apr 24, 2007
By alecm on Apr 24, 2007
Friday Apr 20, 2007
By davew on Apr 20, 2007
Historically, Trusted Solaris was a completely separate environment from "regular" Solaris. The Solaris 10 11/06 production release finally broke the mould, when Trusted Extensions integrated into the main Solaris release. Granted, the packages which need to be installed on the top of an unlabelled Solaris 10 install still need to be installed using an extra install tool, but you'll nonetheless find them on the regular distribution media under the Solaris_10/ExtraValue/CoBundled directory, right alongside the SunVTS hardware validation test suite.
Configuring everything once the packages are in place is a more interesting proposition, but there's a good recipe here (for laptops).
We make no bones about the fact that Trusted Solaris began life as an engineering project for the US Government, first went live 17 years ago, and has seen little use in the commercial world (with one or two notable exceptions) by its nature as a separate product with military heritage ever since - however, now that it's no longer a separate product, we believe that the time is right for commercial adoption.
To this effect, we've been looking at some of the areas in the commercial world where its capabilities have a natural fit. So far, the partial list looks like:
- Grid segregation: Where a multi-tenant grid within an organisation or consortium is required, such that data associated with one set of users is very rigorously segregated from data associated with another set of users. Have a label per tenant organisation, and run Grid Engine within the zones associated with the labels. Academia may find this interesting, as may some areas of Financial Services (eg where Chinese walls have to be maintained).
- Datacentre Base Services consolidation: Trusted Extensions makes the perfect multi-client-organisation NTP server (see http://blogs.sun.com/davew/entry/tempus_fugit_addendum) - apply "labels" as "zones" :-). Given the way that both DNS and NTP work (in terms of "client fails gracefully to next nominated server if previous is unavailable"), clustering wouldn't be a concern - or DNS could be load-balanced in the network. Co-location service providers would find this interesting, especially where separation of services between customers is required to be rigorous.
- Laptop security: Consider the well-known issues of open-access wireless for folk working "out in the world" who nonetheless need to communicate with the office. Walk into your nearest Starbucks, connect to the untrusted wireless at PUBLIC, establish a VPN over the top of that at CONFIDENTIAL (or whatever label you want your corporate intranet to be treated as), job done. I gather Glenn Faden already works this way; Darren also suggested the elegant further finessing of making the PUBLIC zone whole-root so that the VPN packages could be removed from it :-). Such a solution would likely find interest with "everybody who carries sensitive data on a laptop and uses third-party networks".
- Segregation of CCTV server feeds and archives: We have a solution in trials for using our servers as an aggregation and analysis point for good-sized numbers of IP-based CCTV feeds. I think Trusted Extensions could have a valuable part to play in terms of segregating feeds associated with multiple businesses from eachother, and tightly controlling which users are allowed to see feeds from which cameras.
If we extend this a little further, we have:
Any organisation where leakage of internal data is an issue could benefit from having a simple, two-label system of "Public" dominated by "Internal", where "Public" is the Internet connection and "Internal" is the Intranet. If all users are (as is the default) denied permission to downgrade data, then it becomes much more unlikely that internal data will leak. Giving users the ability to upgrade data by default still allows external data to be brought internal. This works well even when organisations do not differentiate between classifications of internal materials, and the Safe Browsing mechanism comes into its own, when web sites on the intranet need to make pointers to materials in the wider world.Press Officer and Auditor roles could also be created, which would potentially be the only roles allowed to downgrade data as part of the external release process.
In educational establishments, denying the ability to upgrade and downgrade data means that while a number of websites can readily be viewed (assuming filtering software is already in place on the Internet link), data can't readily be plagiarised using cut and paste from external sources into essays, etc. Also, if Public and Internal zones are installed as whole-root rather than sparse-root zones, such that careful use of pkgrm can subsequently be used to deny access to internal tools (such as IM) in an external context, so cyber-bullying could be more readily tracked; bullies wouldn't be able to create anonymous / pseudonymous external accounts "on the fly" from which to abuse their victims.
As well as co-location facilities, law firms may wish to extend their "duty of care" capability, in terms of ensuring segregation of client data, by having a compartmented label per client.
If you have some more ideas, please add them in a comment :-)
Wednesday Apr 18, 2007
Tuesday Apr 10, 2007
By alecm on Apr 10, 2007
Alec, I'd like to identify some aspects to trends in Security. Have you observed particular security trends for web computing?
...and this is my response. I'll be mailing him the URL. You get to see it first. :-)
So, have I observed particular security trends in Web Computing?
Not really, for reasons which I partially explain in a recent posting on my home blog - the short version being that I believe there are no new security bugs, ever, and from this it's a pretty easy step to declaring security to be a "solved problem", although that carries the proviso: "if and only if you bother to hire people who understand security".
So if we want to write about the state of the art of "security and web computing" then I feel we should do it in terms of the "maturation" of Web Computing technologies.
Twenty years of geekery has taught me all technologies go though a wild-and-insecure phase until the implementational goofs instilled by the visionaries get hammered out by the embarrassment of exploits, and the needs of business. How often do you see websites which still use plaintext password cookies in anger? Yes, some people still goof in implementation, but at least a large body of people now recognise that such design and implementation artifacts are goofs.
For the people who don't know this, there are always consultants who can help. :-)
So my thesis would be: people are getting used to the idea that perhaps mashups need a little more thought than "we'll just glue it together and it will work OK"; also people are finally getting to understand that the concept of "security" is bogus, being as it is actually an umbrella term for a bunch of qualities, including but not restricted to:
- privacy and secrecy
- privilege separation and enforcement, leveraging all of
- authorization and
- and all of the other stuff above, plus finally and most important of all...
- wisdom regarding the creation of security policy, and consequent design and implementation
So as we move into an age of maturation of web technologies, attitudes and received wisdom are starting to shift; people are now less scared of letting just anyone write all over their website so long as you know who it is that is doing it, and people are beginning to realise that by replacing barriers-to-creation with knowledge-of-authorship (ie: identity, authentication, authorization) - plus the additional ability to 'roll back' so you can circumvent the expected but surviable inevitable vandalism - people realise you can now invite the world to create content with you.
Sufficient technologies to solve all extant security problems now exist - modulo the chest-beating efforts of vendors to pitch new solutions to problems which they hope people will encounter - but from my perspective it's the shift in peoples' attitudes to security which is most interesting.
"Forget prior restraint and access control, build trust, identity and integrity instead."
I find that exciting; it's always been possible, but twenty years ago had you stated it was your goal, people would say you were nuts.
This blog provides security vulnerability fix notifications relevant to third party software components distributed and supported as part of Oracle Products.
Summarized version of this blog is available as a mapping of CVEs and solutions.
- CVE-2013-5211 Input Validation vulnerability in NTP
- CVE-2013-4496 Credentials Management vulnerability in Samba
- CVE-2014-0092 Cryptographic Issues vulnerability in GnuTLS
- Multiple symlink attack vulnerabilities in logilab-commons
- CVE-2007-0227 Information Disclosure vulnerability in slocate
- CVE-2014-0015 Authentication Issues vulnerability in libcurl
- CVE-2013-4545 Cryptographic Issues vulnerability in libcurl
- CVE-2013-1944 Information Disclosure vulnerability in libcurl
- CVE-2013-2174 Buffer Errors vulnerability in libcurl
- CVE-2012-1833 Permissions, Privileges, and Access Controls vulnerability in Grails