Ok, I have to admit that my first thought was "what a publicity stunt!" But as I thought of it more and more, I grew a little more interested in this idea. Privacy issues are complex, and it's hard for any one person to really understand them all. This could be a convenient way for someone who isn't a specialist in the privacy game to keep track of how things are going, generally speaking.
I only hope that EPIC doesn't use this to "cry wolf" too often (as someone else here put it), or they'll lose their credibility. I'd also really like to see them add some factual backup to justify their alert levels. If I could click on the graphic, for example, and get a nice summary of the top several reasons for setting the alert level to it's current value, I think it would be a much more informative tool.
I've decided to go ahead and give it a try for a while to see how it works out. I've added it to the front page of my web site, InfosecBooks.com.
If they do Good Things with it, I'll keep it up. If not, well, it's quite easy to delete. But for now, I'm going to give them the benefit of the doubt. Something needs to be done, so if they're going to try, I'm willing to help them out.
It's quite common to find errors in technical books.
Some of them are simply typos, others are more complex. In the process of producing a book, the text goes through several hands. The author writes it, of course, then various editors all have their fingers in it. Generally they make it better (that's a plug, if my editors are reading 8-) but sometimes mistakes happen. Overall, writing a book is just such an enormous amount of work and there are so many people involved, mistakes are a given.
Many (most?) books publish errata on their web pages or on their publisher's site. I've even got a few books that had printed errata folded up and stuck into the cover. I don't mind seeing a
reasonable number of errors in a book, especially
a very technically dense book, as long as I see that the author and/or publisher makes the errata sheets easily available. After all, we're all only human.
These security measures sound pretty good, though
I think that the memory layout changes and the
segmentation might cause some problems until
developers get used to the new model. It's probably
worth it, though, in the long run. The extra
layers seem like good precautions to take,
especially the randomized layout. Most of the
canned exploits these days come with scads of
pre-computed parameters for all the different
OSes. Randomized memory layouts will make this
sort of thing much more difficult, though I'm
sure the exploit writers will eventually
learn to compensate.
But my real question is about that ZDNet article.
It said that the segmentation measures came from
"hacking the BSD file system". It sounds to
me like the reporter got confused. Can anyone
familiar with the code comment on this?
You can't really just go by reviews posted to
Amazon, or any of the other vendor sites. It's
quite common for authors and publishers to
solicit reviews of their products to be posted
online. In theory, that's fine, except that the
people they solicit are often people they know,
sometimes the friends and family members of the
author or publisher. Some of these folks actually
go so far as to pull some rather
unethical tricks.
Your best bet is to find a small set of reviewers
with whom you tend to agree, and stick
with them unless they prove themselves untrustworthy. A good reviewer considers his or
her reputation to be as precious as gold, and
once it's lost, it's gone forever. They'll try
very hard to provide consistently fair and balanced reviews.
PS. I run a book review website, so this
topic is something I naturally have an interest
in.
I think the original poster is talking about a
whole different level of sandboxing. True, chroot
environments keep you from playing with other files
outside the jailed environment, but they do nothing
to address (for example) your ability to install and run a network sniffer on the target.
A good virtual machine, on the other hand, could let you have this level of security because the hardware is virtualized too. VMWare allows you to assign a number of different types of network interfaces to each VM, and using NAT you can prevent the VM's NIC from seeing traffic to/from any other host.
Also, on a more philosophical level, the deeper your defenses are, the better. It's possible to break out of chroot jails (though it's difficult). It may be even harder to break out of a VM. The jury is still out on this, but it's certainly an unexpected move that would probably throw most crackers for a loop.
Finally! Now I can leave my notebook's airline power adapter at home and just use those tiny bottles of cheap vodka. A measly $5 per recharge
sounds fine to me.
Seriously, though. This could be good news for the
cereal grain industry. Corn is abundant, cheap and
easy to ferment. I wonder how the efficienccy of this technique will compare to that of regular
batteries and more "traditional" hydrogen fuel
cells?
Don't assume that he should go directly to the
police. After all, in most cases it's not a crime to be insecure. True, you might be opening yourself up for a civil suit later, probably for failing to
exercise due diligence, but that doesn't imply an obligation for a consultant to report anything to anyone.
Like most things in the Information Security realm,
it boils down to one thing: trust. Computers can only do what humans tell them to do. Somewhere
there's a human involved, and you have to trust them to do the right thing. It's like Kurt Goedel's incompleteness theorem. The human element is effectively outside the system of technological security measures.
Most companies elect to accept this risk, because otherwise they couldn't accomplish anything without people. You can mitigate the risk through performance contracts, background checks, adequate compensation and other measures, but you can never actually eliminate it.
In my opinion, trust is the issue at the core of Information Security. This is a difficult problem, and maybe one that will literally never be solved.
IMHO, this was the best-managed vulnerability disclosure in recent years. I read the release pretty early on, and vendor patches were already available! Wow!
Although there have been a few grumblings, it looks like there are a lot of others who feel the same way I do: it's perfectly OK to have a short lag time between vulnerability discovery and disclosure, as long as the Baddies don't start taking advantage of the situation before the patches are available. In this case, I read that the lag time was about 2 weeks, which seems perfectly reasonable.
It's worth noting the vendors were all notified of the sendmail problem in mid-February. They all agreed to release the patches and the vulnerability announcements on 3 March.
One of my colleagues was complaining about not being notified immediately, but I think the situation was rather well handled (in contrast to some other recent vulnerability disclosures I could name). The vendor patches were available nearly as soon as I had heard of the vulnerability, and I won't even *guess* when the last time that happened to me was.
It can be done, but there are usually better ways.
on
Honeypots Via VMware?
·
· Score: 2, Interesting
Check this page out. Someone has already written a very good starter page on VMWare honeypots, including a nice section on how to determine whether or not you've been trapped by a VMWare session.
I would have to say that VMWare is a pretty heavyweight solution for most needs. If you've got the time to properly make use of a honeypot, maybe you've also got the resources and skills to make VMWare worthwhile. On the other hand, check out Honeyd, a small daemon that can emulate an entire Honeynet easily on one box. This may be a better solution for you, depending on your needs.
Actually, there's a lot more to security than just
keeping your data secret. Information Security
practice is based on three pillars: Confidentiality,
Integrity and Availability (AKA "CIA", which sounds
like an oxymoron, doesn't it?). There's a lot more
to it than just keeping people away from the
physical storage medium.
Maybe I should have made this more clear, but
the nicest thing about this book is that they
cover *all* the security bases, not just the
ones most people think of. They show how to
evaluate technologies or specific solutions on
the "I" and the "A" as well. That's why I think
this book is so useful. It points out areas of
security that many people often overlook.
I guess it only puts the contest in question for you. For most of the rest of us, at least, those of us involved in the security community, Rain Forest Puppy's involvement is a source of positive credibility, not negative. He's well known and very well respected.
It's much improved now. I admit that the original versions were crap. Also, keep in mind that even the SPARC machines Sun sells have a lot of standard PC parts in them, so the Intel port is naturally more compatible. Not perfect, but still good.
Don't forget that there's a critical difference between "a piece of hardware that's 25 years old" and "a piece of hardware that was designed 25 years ago". I agree that the age of the shuttle fleet is a significant concern, but the design work. NASA does have some difficulty finding the appropriate replacement parts, since some are no longer manufactured, but so far the situation has been managable. I still don't see any need to force a redesign just because the systems are based on old, proven stable technology.
Well, I used 8.0 and it's ok. I don't use it for interactive desktop type applications much anyway. I mostly use it like a server, so video support doesn't matter much. I'll keep it in mind for Sol9, though.
I've been waiting for this. Solaris for Intel gets
too little love. I tell you what I like about it:
On my (relatively cheap) PC at home, I can run it
in a VMWare session and test out things that I will
later use on the SPARC version. It should be great
for OSS developers, who can compile and test their
applications on their desktop, even though they don't have the SPARC hardware. It's source compatible, baby!
Also, I write about system administration and security topics, and it's nice to try out certain procedures. I don't have a SPARC at home, so using the Intel version under VMWare is a lifesaver.
In this case, a stable, well-known and quite familiar technology is "the best kit we can." If it ain't broke, don't fix it. Upgrading for the sake of getting "newer" components is more likely to cause safety hazards than leaving older, perfectly good systems in place.
Re:Expect fianl report in 6 months
on
Latest Columbia News
·
· Score: 5, Informative
From what I've read, the shuttle doesn't have a black box. Black boxes are used to store instrument and voice data on traditional aircraft, but NASA's Mission Control serves the same purpose for the Shuttle. It archives all telemetry and voice communication, and there's no worry about having to find it later.
According to this
story on Yahoo! News, the two men were arrested
for their alleged part in spreading the "TK" worm,
which is completely different. How did this suddenly mutate into a story about Slammer?
If you really want the reference for the technical and social history of the telegraph, check out Tom Standage's The Victorian Internet: The Remarkable Story of the Telegraph and Nineteenth Century's On-Line Pioneers.
I read this book shortly after it came out in paperback, and I have to say that it's fascinating. It discusses various early telegraph systems in detail, including those not using electricity at al. More importantly, it draws startling parallels between the telegraph's influence on 19th century society and the Internet's influence today, especially during the dotcom boom. This is a must-read for the true geek.
The semantic web idea might be the best implementation we can come up with right now, but I doubt it'll ever become very successful. It relies on content providers using tags to provide meaning to their information. Not only does this open the door to massive confusion (how do they decide which tags to use in which circumstances, and how will every semantic browser know all the tags?) but it's more work. These two factors will probably kill Semantic technology before it even gets off the ground.
IMHO, search engines will eventually be able to read and understand the context of the words users search for. If that happens, then the search engine could have semantic search capabilities built in, without relying on the content owners to provide special tags. In other words, the benefit without the extra work. I think semantic searches will eventually prove to be of great use, but won't become widespread until search engine technology can support them without changing the content in any way.
A fruit-filled-baked-goods-at-high-altitude dream, perhaps, but an achievable one (eventually).
This article wasn't much of a review, so I thought I'd chime in. I read this book recently, and here are some of my thoughts.
First, what's in this book? The bulk of the book is given over to scenarios of different types of social engineering attacks. This includes things like acting helpless, offering help and guilting your victim into "owing you something", and pushing certain psychological buttons designed to make the victim feel whatever emotions you want. There's also some stuff about how to create a
good security policy for your organization, but you can skip that. There are much better references for this sort of thing.
What did I like? The scenarios sure are entertaining! The book covers a wide variety of different situations and goals, from tricking someone into telling you their password to gaining physical access to "secure" facilities. The authors tell the story of each attack both from the victim's point of view and from the attackers, then provide an analysis of why it worked and how it could have been prevented. Very valuable!
What did I dislike? There's a substantial amount of repetition in the scenarios, but some may view that as useful reinforcment, so it's not necessarily a bad thing. As I said, I think the security policy section isn't very good, and it could easily have been left out.
My overall impression is good, and I highly recommend this to anyone responsible for physical or information security in their organization.
Slashdot Mirror
Now, finally , I see how this is relevant to Slashdot. ;-)
I only hope that EPIC doesn't use this to "cry wolf" too often (as someone else here put it), or they'll lose their credibility. I'd also really like to see them add some factual backup to justify their alert levels. If I could click on the graphic, for example, and get a nice summary of the top several reasons for setting the alert level to it's current value, I think it would be a much more informative tool.
I've decided to go ahead and give it a try for a while to see how it works out. I've added it to the front page of my web site, InfosecBooks.com. If they do Good Things with it, I'll keep it up. If not, well, it's quite easy to delete. But for now, I'm going to give them the benefit of the doubt. Something needs to be done, so if they're going to try, I'm willing to help them out.
Many (most?) books publish errata on their web pages or on their publisher's site. I've even got a few books that had printed errata folded up and stuck into the cover. I don't mind seeing a reasonable number of errors in a book, especially a very technically dense book, as long as I see that the author and/or publisher makes the errata sheets easily available. After all, we're all only human.
But my real question is about that ZDNet article. It said that the segmentation measures came from "hacking the BSD file system". It sounds to me like the reporter got confused. Can anyone familiar with the code comment on this?
Your best bet is to find a small set of reviewers with whom you tend to agree, and stick with them unless they prove themselves untrustworthy. A good reviewer considers his or her reputation to be as precious as gold, and once it's lost, it's gone forever. They'll try very hard to provide consistently fair and balanced reviews.
PS. I run a book review website, so this topic is something I naturally have an interest in.
A good virtual machine, on the other hand, could let you have this level of security because the hardware is virtualized too. VMWare allows you to assign a number of different types of network interfaces to each VM, and using NAT you can prevent the VM's NIC from seeing traffic to/from any other host.
Also, on a more philosophical level, the deeper your defenses are, the better. It's possible to break out of chroot jails (though it's difficult). It may be even harder to break out of a VM. The jury is still out on this, but it's certainly an unexpected move that would probably throw most crackers for a loop.
Seriously, though. This could be good news for the cereal grain industry. Corn is abundant, cheap and easy to ferment. I wonder how the efficienccy of this technique will compare to that of regular batteries and more "traditional" hydrogen fuel cells?
Don't assume that he should go directly to the police. After all, in most cases it's not a crime to be insecure. True, you might be opening yourself up for a civil suit later, probably for failing to exercise due diligence, but that doesn't imply an obligation for a consultant to report anything to anyone.
Most companies elect to accept this risk, because otherwise they couldn't accomplish anything without people. You can mitigate the risk through performance contracts, background checks, adequate compensation and other measures, but you can never actually eliminate it.
In my opinion, trust is the issue at the core of Information Security. This is a difficult problem, and maybe one that will literally never be solved.
Although there have been a few grumblings, it looks like there are a lot of others who feel the same way I do: it's perfectly OK to have a short lag time between vulnerability discovery and disclosure, as long as the Baddies don't start taking advantage of the situation before the patches are available. In this case, I read that the lag time was about 2 weeks, which seems perfectly reasonable.
Kudos to all involved!
One of my colleagues was complaining about not being notified immediately, but I think the situation was rather well handled (in contrast to some other recent vulnerability disclosures I could name). The vendor patches were available nearly as soon as I had heard of the vulnerability, and I won't even *guess* when the last time that happened to me was.
I would have to say that VMWare is a pretty heavyweight solution for most needs. If you've got the time to properly make use of a honeypot, maybe you've also got the resources and skills to make VMWare worthwhile. On the other hand, check out Honeyd, a small daemon that can emulate an entire Honeynet easily on one box. This may be a better solution for you, depending on your needs.
Actually, there's a lot more to security than just keeping your data secret. Information Security practice is based on three pillars: Confidentiality, Integrity and Availability (AKA "CIA", which sounds like an oxymoron, doesn't it?). There's a lot more to it than just keeping people away from the physical storage medium.
Maybe I should have made this more clear, but the nicest thing about this book is that they cover *all* the security bases, not just the ones most people think of. They show how to evaluate technologies or specific solutions on the "I" and the "A" as well. That's why I think this book is so useful. It points out areas of security that many people often overlook.
I guess it only puts the contest in question for you. For most of the rest of us, at least, those of us involved in the security community, Rain Forest Puppy's involvement is a source of positive credibility, not negative. He's well known and very well respected.
It's much improved now. I admit that the original versions were crap. Also, keep in mind that even the SPARC machines Sun sells have a lot of standard PC parts in them, so the Intel port is naturally more compatible. Not perfect, but still good.
Don't forget that there's a critical difference between "a piece of hardware that's 25 years old" and "a piece of hardware that was designed 25 years ago". I agree that the age of the shuttle fleet is a significant concern, but the design work. NASA does have some difficulty finding the appropriate replacement parts, since some are no longer manufactured, but so far the situation has been managable. I still don't see any need to force a redesign just because the systems are based on old, proven stable technology.
Well, I used 8.0 and it's ok. I don't use it for interactive desktop type applications much anyway. I mostly use it like a server, so video support doesn't matter much. I'll keep it in mind for Sol9, though.
Also, I write about system administration and security topics, and it's nice to try out certain procedures. I don't have a SPARC at home, so using the Intel version under VMWare is a lifesaver.
In this case, a stable, well-known and quite familiar technology is "the best kit we can." If it ain't broke, don't fix it. Upgrading for the sake of getting "newer" components is more likely to cause safety hazards than leaving older, perfectly good systems in place.
From what I've read, the shuttle doesn't have a black box. Black boxes are used to store instrument and voice data on traditional aircraft, but NASA's Mission Control serves the same purpose for the Shuttle. It archives all telemetry and voice communication, and there's no worry about having to find it later.
According to this story on Yahoo! News, the two men were arrested for their alleged part in spreading the "TK" worm, which is completely different. How did this suddenly mutate into a story about Slammer?
I read this book shortly after it came out in paperback, and I have to say that it's fascinating. It discusses various early telegraph systems in detail, including those not using electricity at al. More importantly, it draws startling parallels between the telegraph's influence on 19th century society and the Internet's influence today, especially during the dotcom boom. This is a must-read for the true geek.
IMHO, search engines will eventually be able to read and understand the context of the words users search for. If that happens, then the search engine could have semantic search capabilities built in, without relying on the content owners to provide special tags. In other words, the benefit without the extra work. I think semantic searches will eventually prove to be of great use, but won't become widespread until search engine technology can support them without changing the content in any way.
A fruit-filled-baked-goods-at-high-altitude dream, perhaps, but an achievable one (eventually).
First, what's in this book? The bulk of the book is given over to scenarios of different types of social engineering attacks. This includes things like acting helpless, offering help and guilting your victim into "owing you something", and pushing certain psychological buttons designed to make the victim feel whatever emotions you want. There's also some stuff about how to create a good security policy for your organization, but you can skip that. There are much better references for this sort of thing.
What did I like? The scenarios sure are entertaining! The book covers a wide variety of different situations and goals, from tricking someone into telling you their password to gaining physical access to "secure" facilities. The authors tell the story of each attack both from the victim's point of view and from the attackers, then provide an analysis of why it worked and how it could have been prevented. Very valuable!
What did I dislike? There's a substantial amount of repetition in the scenarios, but some may view that as useful reinforcment, so it's not necessarily a bad thing. As I said, I think the security policy section isn't very good, and it could easily have been left out.
My overall impression is good, and I highly recommend this to anyone responsible for physical or information security in their organization.