A couple of podcasts on various security topics can be found on sun.com/security

• On Systemic Security
• On Solaris (and Solaris Trusted Extensions)
• On ECC crypto interoperability

The Systemic Security recording is of Hal Stern talking to Glenn Brunette about what we're building, documenting and sharing to (help) make everything that gets deployed more secure.

In the Solaris podcast they are joined by Darren Moffatt, and chat about what security features we have in Solaris (crypto, Trusted Extensions, RBAC...) and what will be coming in the future.

Ellyptic Curve Cryptography is the topic of the third podcast, this time with Hal discussing matters withVipul Gupta. After an overview of what ECC is, they look at the interoperability aspects of these algorithms.

Update: To hear another voice -- Joel Weise's -- on one of the topics Hal raised in those podcasts there's the systemic security "Net Talk" programme.

-Bart

tags: cryptography ecc podcast security solaris trusted

Permalink | Comments [1]

So I've been away for a bit, but now I'm back; while I've been away:

• Two key members of Sun's security community got married - veritably a match made in SunScreen

• Another, with his wife (a sterling expert on the topic of web certificate checking) were overjoyed with the birth of their first child.

• Today it appears that yet another person doesn't realise that wordprocessor documents - and powerpoint, etc - contain rather a lot of information which is not immediately visible on-screen.

• And some legislators in Germany have decided that they can define that which I can't do even after 20 years experience, viz: what constitutes a 'hacking' tool rather than a sysadmin tool? This means I am probably a wanted felon, or something. In Germany. Where (being in the EU) I can be extradited. Presumably. Ooh...

Bleagh. I need coffee...

Permalink | Comments [0]

Following the integration of the Secure By Default (SBD) work into Nevada build 42 and, subsequently, Solaris Express and Solaris 10 11/06, some colleagues have been asking me whether the Solaris Security Toolkit (SST, aka JASS) still has a useful part to play. My answer is "definitely", and here's why.

SBD acts to either disable services completely, or to force them to only bind listeners to a loopback (127.0.0.1) interface. SST is equally capable when it comes to disabling services, however the "bind only to loopback" capability is currently beyond its capability.

By contrast, there's a whole bunch of things which SST can do that SBD doesn't, today. These include:

• setting nscd cache timeouts to zero
• restricting the use of cron and at
• enforcing the use of particular password encryption algorithms and requiring the use of what are considered to be "strong" passwords
• setting warning banners on login services
• randomising packet sequence numbers (as per RFC 1948)
• controlling where core files are put

...in short, where SBD hardens a system by disabling or constraining service listeners, SST further hardens a system by finessing the ways in which services and the underlying OS capabilities (network stack, etc) are configured.

There's a few design reasons why SBD doesn't do all the things that SST does - such as enabling packet sequence number randomisation by setting TCP_STRONG_ISS to 2 in /etc/default/inetinit and setting nscd timeouts to 0. As SST isn't run on a system by default, whereas SBD is the default configuration on Nevada and Solaris Express (although not on Solaris 10, for reasons of backward compatibility), SST can "get away with" doing some things that SBD can't.

So, how can you best go about using the two capabilities together?

First, ensure that once you've installed SST, you also patch it with 122608-03 or later, so that it understands SBD. Next, depending on what services you intend to present from your system, you can set SBD to netservices limited; about the only situation I can think of when you wouldn't necessarily want to use SBD everywhere is when you want to present something which has a lot of dependencies on Solaris services, such as Sun Ray services. If you're building a SNAP server on Trusted Extensions, for instance, while it's sensible to use netservices limited on the non-global zones handling each label, it's easier to leave the global zone (aka Trusted Path) at netservices open, and lock it down with SST.

For a service with less complex dependencies, it's sensible to use netservices limited, open up whatever dependent services are required using SMF, and then apply SST. In the event that the system needs to be reconfigured, make sure that SST and SBD operations are "nested" correctly; as SST is the last thing applied it needs to be the first thing undone with jass-execute -u, and then SMF can be used to change the SBD profile before re-hardening with a suitably-modified SST .driver.

-Dave

Permalink | Comments [2]

If the video is the 5 cent tour of Solaris RBAC then this is probably the book for the "self-guided walk through RBAC".

This is a transcript of an early draft version of the video (one which I canned as looking at 20 minutes of someone typing is just not that interesting...)

-Bart

The Self-Guided Walk Through Solaris RBAC

To make use of Solaris' Role Based Access Control you can use any "out of the box" version since Solaris 8, although to make use of fine-grained privileges you'd need either Trusted Solaris 8, Solaris 10, or more recent, such as Solaris Express.

The only preparation (optional, really) is to enable Solaris Auditing - which I recommend doing anyway, though it's important to note that for most systems logging only a limited set of events will do.

So: on a newly installed system the only account that can be used is the root account, so log in as root.

The first thing to do is to add (at least one) user account, so that someone other than root can log in and use the system. Here we create two accounts, one of which will be permitted to assume the root role:

# useradd -u 1001 -g staff -d /home/bart -s /bin/ksh -c "Bart who is also the admin" -m bart
# useradd -u 1002 -g staff -d /home/joe -s /bin/ksh -c "Joe who is just a user" -m joe

# passwd bart
# passwd joe

Now there are two user accounts on the system, as well as the root account. The problem with that root account is that anybody who has the password can walk up to this system and log in as root -- and, even with full auditing enabled, there'd only be a list of things done by root, with no way of knowing who actually ran those commands...

With RBAC there's an easy way to fix this: make root a role -- because fundamentally that's what roles are: from the system's point of view they're just regular accounts (with the expected entries in /etc/passwd and /etc/shadow), that cannot directly log in. The only difference between a role and a user account is one little item in /etc/user_attr: it says "type=role" for a role, and "type=normal" for a user - which is the default, so if there's no entry the account is considered a regular account.

The thing that differentiates roles from users in practice is a little PAM module pam_roles that checks wether an account is a role, and if so it denies direct log-in, and denies su by unauthorised users.

Making root into a role can be done with one command:

# usermod -K type=role root

though doing just this and then logging out would make it impossible to become root (though when booting the system in single-user the restriction that the account can't be used directly is not enforced. If nobody should ever be permitted to become root without an audit trail it's probably best to set an OBP or BIOS password, and have that be stored somewhere where the admins need to sign a log to retrieve it...), so (at least) one of the users should be permitted to assume the root role.

# usermod -R root bart

When now someone tries to log-in to the system as root the system won't let them, even if they have the right password -- they'll be shown an error message indicating that "Roles can only be assumed by authorized users".

If our other user (Joe) tries to su to root he'll get the same error message; only Bart would be permitted (with root's password) to become root. This is one of the obvious differences between sudo and RBAC: in sudo users generally authenticate using their own password, not the root account's password.

One of the big advantages of using roles is that an auditor can later determine who assumed which role, and - if auditing is configured to log this - what they did as that role.

This is pretty much the most basic use of roles that one can have, and in many circumstances be sufficient: only authorised users can become root, and there is a log of who did what on the system.

Now: you can also create other accounts as roles, but that in itself would not be very interesting: they'd be normal accounts, that can't do anything special -- so besides giving people controlled access to a set of files (those owned by the role) there'd be not much else those roles can be used for.

There may be some people that need to perform some tasks without being given complete root access, or they may have root access when needed but it would be convenient if some administrative commands could be used without the extra step of assuming a role.

In Solaris RBAC both of these are possible by assigning "rights profiles" (sometimes also called "rights", sometimes also called "profiles") to those accounts: assigning it to a user account gives that user the extra magic abilities that come with the profile, assigning a profile to a role provides those powers to users who are authorized to assume the role.

Most of the profile configuration files live in /etc/security, with the exception of /etc/user_attr - which we saw earlier.

A rights profile, described in prof_attr, is a container that can contain other rights profiles (so we can create hierarchies of profiles), plus possibly some authorizations, and maybe a list of commands and their attributes.

Let's start with those commands and their attributes: there is a list of commands in /etc/security/exec_attr and for each entry we can specify a number of things :

• the real and effective UID and GID - so when someone executes a command that's in a profile it'll run with those UIDS,
• and (as of Solaris 10) we can specify privileges.

(A brief refresher on privileges: Traditionally in Unix when a process tries to do something like accessing devices, configuring the system, or opening a file for which it doesn't have permission, the kernel would check the process' credentials and if the process was run with userid 0 (the root account) then the system call in question would succeed. With privileges the kernel now doesn't merely check the userid but instead checks a new process attribute, which is the privilege set.)

With RBAC we can now specify individual commands and the privileges they need, so we can let a user execute one or two commands with magical extra privileges, whilst all other commands run just the way they always have.

The exec_attr configuration file shows which profile an entry applies to, plus the command in question and the security attributes of the command (effective UID/GID, real UID/GID, and a list of privileges). If you don't specify privileges or UIDs/GIDs then those will be inherited from the parent process, just like any other command that a user executes.

In short a user can be allowed to run a couple commands with extra privileges -- perhaps, to change some of the graphics settings, to renew a DHCP lease, or to reset a print queue -- to help things run smoothly.

If there's a need to store files for a specific task, then assigning the rights profiles to a role is probably more appropriate, as the role's home directory can be used as a task-specific storage area.

A role would usually be given a function-specific list of commands to execute, for instance to support an operator, DBA, or auditor.

If it is mandated that a user enter a password before utilising magic powers then the only way of doing so is to assign the magic powers to a role, requiring the users to assume that role for the function specified.

If secondary authentication is not needed and if there's no need for shared storage (i.e. the role's home directory) then I recommend you just assign the rights profile to the user.

There is one constraint when assigning commands to users or roles:

in order to get those commands to run with different UIDs or GIDs or with extra privileges they will need to be executed from a "profile shell" -- /usr/bin/pfsh, /usr/bin/pfcsh, /usr/bin/pfksh -- or via the sudo-like pfexec command. These are the tools which know about rights profiles, and they ensure that the correct attributes are set when the command is executed.

A role gets a profile shell by default, but users who have special rights profiles will need to be given a different shell, or they must run the commands via pfexec (To reiterate for people familiar with sudo: pfexec is the closest equivalent on Solaris, but note that it doesn't do secondary authentication and doesn't currently limit command line options to any of the commands).

As an example we'll allow Bart to review the audit logs on the system, and will grant him the appropriate rights profile: (As root or other administrative account:)

# usermod -P "Audit Review"  bart

...and now Bart can run things like "/usr/sbin/praudit" (either by invoking the command via pfexec, or by running it from pfsh, pfcsh, or pfksh).

NB all users are given the "Basic Solaris User" rights profile by default as specified in /etc/security/policy.conf; it allows all users to run all commands they have access to -- but without any special attributes. Taking this away means that an account which uses a profile shell will be allowed to only run those commands listed in the output of profiles(1) and no others.

Besides specifying commands and their attributes in a rights profile we can also list authorizations. Authorizations are defined in /etc/security/auth_attr in a hierarchical manner. When a user is assigned a root or subroot of that hierarchy they get all authorizations which exist under it. Authorizations are attributes of users -- they're not "process attributes" like privileges, instead they are something that the kernel doesn't know about. They are used by individual applications to determine wether the application should perform some action on behalf of a user.

Even though privileges permit finer grained control over what applications are permitted to do, you can't use them to control modification of records within a file. Using application to mediate access to those records and authorizations in that application you can get the level of control that you desire.

One of the applications that makes extensive use of authorizations in this manner is the Solaris Management Console: it may permit one account (e.g. the system administrator) to create users, while not permitting that account to set the user's password or audit mask (which might be done by someone else, such as the security manager).

The Solaris Service Management Facility is one of the more recent users of authorizations which permits allowing a user or role to restart a service without permitting that user or role to reconfigure the service - and without the need to allow that user or role direct access to the process or its configuration files.

Authorizations are attributes of a user, so they can be assigned directly to a user (in which case they're listed in etc/user_attr), but they can also be assigned indirectly as part of a rights profile - in which case they're listed in /etc/security/prof_attr.

And, really, that's pretty much all there is to Solaris RBAC.

In summary, there are users and there are roles -- which are just like users, except that they tend to be used for specific tasks (system administration, operations and so on), and can only be "assumed" via su rather than accessed directly. Both types of accounts are defined in /etc/passwd & /etc/shadow, and their account type is specified in /etc/user_attr. In the latter file we grant users and roles authorizations, so that applications and tools which are authorization-aware (such as Solaris Management Console and the Service Management Facility) will perform their magic on behalf of authorized staff.

In user_attr we also assign "rights profiles" which may add extra authorizations and which will permit those users and roles to execute particular commands with extra magic privileges or different UIDs or GIDs, if they choose to do so via pfexec or a use of a profile login shell.

tags: introduction rbac solaris

Permalink | Comments [1]

Sometimes when trying to fix a problem or writing some piece of code I realise I only have a very vague idea how to go about attacking it. Usually there's a fair bit of documentation, but lacking a clear idea of what exactly I need I have no idea where to start reading...

And that's why it's nice to have water coolers (be it the real ones in the break room or the virtual ones on IM or IRC): you can usually find someone who knows more about the stuff that puzzles you, who will happily explain how things fit together, providing the big picture so that now you know where to start.

Having for a while now dabbled in things Trusted Solaris and Trusted Extensions I've also become more familiar with Solaris Role-Based Access Control, so I've been the one to provide the 5 minute "big picture" about those topics to a couple colleagues... so I thought it might be useful to do something similar for people that I tend to not run into at the water cooler...

This 5 cent tour of Solaris Role-Based Access Control is a five minute overview of the main bits and pieces of RBAC. It's not meant to replace the documentation: it's a rough guide, providing enough background to maybe have a go at making root a role on your system, or to help find your way in the man pages and maybe set up your system for dual-role administration...

Click To Play

The video is also available in QuickTime (30MB) or Shockwave Flash (3MB).

I'm considering doing one of these around Trusted Extensions; if you'd find that interesting please do leave a comment (comments about this video are welcome too, obviously).

-Bart

tags: introduction rbac solaris video

Permalink | Comments [10]

So a friend punted this URL over to me:

InfoWorld: Should vendors close all security holes?
Fix it or forget it? A reader presents an intriguing counterpoint

In last week's column, I argued that vendors should close all known security holes. A reader wrote me with a somewhat interesting argument that I'm still slightly debating, although my overall conclusion stands: Vendors should close all known security holes, whether publicly discussed or not. The idea behind this is that any existing security vulnerability should be closed to strengthen the product and protect consumers. Sounds great, right?

The reader wrote to say that his company often sits on security bugs until they are publicly announced or until at least one customer complaint is made. Before you start disagreeing with this policy, hear out the rest of his argument.

(continues...)

...and I shared the link and article with our security community chat channel, inviting comment. The result itself surpassed what I was intending to write, and provides food for thought:

• (15:36:32) alecm has changed the topic to: http://www.infoworld.com/article/07/05/11/20OPsecadvise_1.html - Comments please before I SLOTD a critique...

• (16:13:03) bartb: alecm: what kind of comments are you looking for? Summary of thoughts: reality says you'll always have bugs, you'll always be short-staffed, so fix those that are publicly known, fix those that have a large-ish impact, fix the remainder if time permits.

• (16:33:14) darrenm: re: the topic, I agree with some of what is being said in that article though not the "defer indefinitely until it is reported" way; priority scheduling for fixes to get patches out for those that are publically known is a no-brainer.

• (17:32:15) bartb: alecm: schneier's fresh blog posting may be of interest around your planned blog post

• (17:46:27) alecm: My take on the Infoworld article: I think it's a bad idea, I'm with Bart and Darren but probably showing my sys-admin heritage. To me security-bugs need "fixing" ASAP they are found, and yes I expect vendors to do the extant exploits first... but if a hole is wide-open and I am told about it, I can mitigate it in more ways than a software patch. Eg: Firewall port-blocking. Hence why I support full-disclosure within a per-event "reasonable" time period.

• (18:08:45) Avalon: Yes, vendors should close all security holes.

• (18:09:14) sommerfeld: the more interesting question is: given limited development resources, in what order should they be closed.

• (18:09:59) Avalon: There's another question that begs to be asked by that article: what about security holes that are closed without being disclosed publicly? I make that point because quite obviously someone is saying that fixing one (and subsequent patch/fix announcement) draws more attention and therefor exploits than without said publicity.

• (18:11:19) sommerfeld: what about security holes that are closed without the developer realizing that they bug they fixed was exploitable? I have done this. IMHO that's the best kind of security fix - *NOBODY* knows about the exploit! The one time in my memory when someone asked me why I didn't publish a security alert on a bugfix, it was because I had been fixing a bunch of gcc -Wall warnings and didn't stop to check whether any of the fixes were exploitable.

• (18:12:38) Avalon: hmmm, the article does mention people reverse engineering patches. Hmmm... Would you rather have only the Red Army know about your bugs or everyone? It's unquestioned that there are teams of Chinese hackers trying to break into military and commercial systems around the world. They've got access to more man power than most hacker organisations ever will...

• (18:18:12) alecm: Avalon: have you a citation for the chinese thing ?

• (18:37:02) Avalon: USA Today.

...and on rolls the paranoid chatter which drives all us security geeks. I thought I would post this and open it up to discussion than just leave it hanging.

In summary I would suggest (in slight disagreement with the "fix it when it goes public" position cited by the article) that the consensus amongst our little group is that we should fix everything because that's the right thing to do; but pragmatic prioritisation in the face of exploitation is wise.

You just can't rely on that, since you don't always know when you're being exploited.

- alec

tags: engineering hacking schneier security slotd vulnerability

Permalink | Comments [0]

I found out today that I can use Nautilus, the GNOME filemanager, to browse file systems accessible over sftp (the IETF secsh filexfer protocol). I was surprised this worked already since I wasn't expecting it to be available until we had FUSE on (Open)Solaris. It turns out that the gnome-vfs layer does this on its own. So while I can't 'cd /net/myhomemachine.com/home/darren/Documents' I can do it graphically. There are also gnome-vfs plugins for SMB (using Samba), Webdav and Webdav over SSL/TLS.

As far as I know this something we got in Solaris Express by virtue of keeping up with the GNOME community, it isn't an OpenSolaris or Solaris invention or even needed to be changed to work.

This all works without any privilege even though it looks like the user is mounting filesystems. Since it happens in the users Nautilus process it doesn't cause any problems with Trusted Extensions labeling. I need to investigate how copy/move of files between a local file system and one using one of these gnome-vfs plugins will work though. There can't be a security violation because of how nautilus works in Trusted Exensions but it might not allow the copy/move.

- Darren

tags: gnome opensolaris sftp

Permalink |

I just spent 30 minutes with Darren, filming a noisy-but-interesting overview of encryption technologies that protect data at rest. I'll edit it over the next few days, and hopefully have a 5 to 10 minute video up here next week.

In the interim, here's an old video that I made in 2002, along the theme of utilising the correct tools in the correct manner:

Click To Play

Permalink | Comments [0]

So I posted this:

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 systemic:

Neil:

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).

...the architectural and integrational:

Forrest:

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 :)

...and the slightly tongue-in-cheek operational risk:

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.

...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.

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...

-alec

tags: architecture integration security slotd solaris

Permalink | Comments [1]

Can you think like a security geek?

So: 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? Feel free to critique. My answer will be posted tomorrow, unless it appears in the comments beforehand. :-)

ps: if you've heard me explain this before, please keep schtum. This is just for fun.

tags: puzzle security slotd thinking

Permalink | Comments [8]

I would like to propose the following thesis:

"The threat of denial-of-service by inappropriate upload and proliferation, ideas for rapid identification of duplicate and near-duplicate data, and finding an approach that needs to scale to something big enough for YouTube."

My longer article explaining my thoughts - a few minutes' read, without following links - can be found on my blog.

-Dave

Permalink | Comments [0]

So Techdirt writes:

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.

- alec

tags: by default schneier secure security slotd solaris

Permalink | Comments [1]

Today's SLOTD is a thought-piece - I'm not going to talk directly about the digg.com / HD-DVD key story which you can perfectly-well read about for yourselves and thereby keep more up-to-date with a dynamic story than is possible by reading my witterings; moreover there are many viewpoints on the underlying question of using encryption to "protect" digital media which retailers "sell" (or perhaps "license"?) to everyday people who buy them in aggregate with small shiny plastic disks, and there are wiser people than I who work for Sun who I intend to chivvy about writing about this topic in the future.

Hello, Susan. :-)

However, last week I posted a video about web2.0 security and am in some ways delighted that an example of the gap I didn't cover, coming to the public consciousness so soon.

Our fearless leader two years ago was described and quoted thusly:

redcouch.typepad.com

Blogging's advantage, from his perspective, is in the transparency and authenticity that nothing else can provide. With more than 1000 company bloggers, people can see inside Sun in ways that are infinitely more valuable than Federal governance regulations. 'Executives are missing a point. There is no perfect truth despite transparency.' He argued that SEC requirements for quarterly reporting is far from as revealing as 1000 Sun bloggers talking about 'the guts of the company,' on a daily basis in a public forum.

[...]

From Schwartz' perspective, blogging is not an appendage to Sun's marketing communications strategy, it is central to it. He believes that the 1000 Sun bloggers contribution hasn't just moved the needle for the company, 'they've moved the whole damned compass. The perception of Sun as a faithful and authentic tech company is now very strong. What blogs have done has authenticated the Sun brand more than a billion dollar ad campaign could have done. I care more about the ink you get from developer community than any other coverage. Sun has experienced a sea change in their perception of us and that has come from blogs. Everyone blogging at Sun is verifying that we possess a culture of tenacity and authenticity.'

...and the flipside of that is summed-up in a nutshell: if you manage to do something which trashes your authenticity, makes you look artificial, opaque, plastic, or disrespectful of the members of your community, then you can suffer in a way that hasn't really had adequate comparison since the days of tar & feathers, stocks or other forms of community social humiliation.

Sun Microsystems has its own internal vocabulary, and one of the phrases which used to be common was that of the CNN Moment - a "damaging public infrastructure failure often experienced by dot-com enterprises" which presumably would be big enough and embarrassing enough to end up on the front page of the eponymous website.

What I am finding is less obvious to some of my colleagues (and customers) is that as mainstream media websites become less relevant, blogs and other communities become more relevant in terms of how people will perceive you and your company; and the distributed nature of blogs means that stories don't get retracted, they get amplified.

So nowadays we should fear "blog moments", or perhaps social-tar-and-feathering, since once humiliation is stuck to your brand then it's awfully hard to wash off.

So there's your security risk for today, and its respective mitigation: if you're going to engage with your community then do respect them and don't junk those amongst them with whom you have an issue; instead you need to engage with your community about the underlying problem - eg: "Our advisers think this is a legal risk to us, so we're very sorry but we're suspending this thread until we sort this out..." - and you'll come out of it a lot cleaner, and with fewer feathers.

And sadly there is no shortcut. No amount of firewalls, VPNs, privilege management, cryptography or methodology will save you from the business risk of not "getting it".

- alec

tags: blogging blogs security slotd sun

Permalink | Comments [0]

This was a great weekend for WiFi on OpenSolaris (and thus future releases of Solaris and Solaris Express) [build 64]. Not only did we get a driver for the Intel Centrino 3945 chipset but more importantly (well at least in the eyes of a security geek like me) we got support for WPA-PSK. I've been working with the project team, not as a core developer - mostly design advice and codereview, on this for quite some time now and I'm really glad to see it integrated I'm really pleased with the architecture and the implementation.

Yeah I know lots of other operating systems had this already and now we do to! This combined with NWAM which integrated its first deliverables into build 62 and we are really going somewhere with usability and security for Solaris on laptops.

Now I can put WPA-PSK on my home router again instead of relying on WEP, not brodcasting my ssid and MAC address restrictions. Meanwhile the project team are now off developing WPA Enterprise support, I expect to work with them a little as they design and implement that support.

- Darren

tags: opensolaris slotd wifi wpa

Permalink | Comments [2]

I attended InfoSec Europe at Olympia in London earlier this week. I find this show generally a little to "PC" biased sometimes so I wasn't expecting to get too much out of it. I spent most of the time looking around for encrypted storage solutions and products. Last year I found an excellent hardware only encrypting disk drive that is approved for UK government use.

This year I found a device by a company called SafeBoot. Initially I almost discounted this device because I was expecting it to be Windows only. The device is a small USB flash drive with a fingerprint reader to access the data, I think it is their phantom product that I saw. While the device can only be configured from Windows the lock/unlock functionality works on any system. We tried it out under the MacOS X laptop we had with us (this ensures there are no drivers needed for this) and it works just fine. What was even nicer is that a simple software eject under MacOS caused the drive to relock again. So I fully expect this to work just the same under Solaris. Under MacOS X the encrypted part of the device that you need your fingerprint to unlock appears as a removable drive that doesn't have the media in it - until you swipe your fingerprint.

Pretty cool little device, I don't have one at the moment to try it out but it looks promising. I can even see some uses for this in a primarily Solaris based solution, so you might see this or something like it in the future....

Apparently the device can also allow the crypto functionality to be used by the host OS, but only Windows. I wonder if I can get them to write (or collaborate with us to do so) a driver for the OpenSolaris cryptographic framework.

- Darren

tags: crypto slotd storage

Permalink | Comments [0]