Hey, glad to see ISS's PR department knows about Slashdot. And, hey! You're right, I was affected by the product line "simplification"! Glad to meet you, now sit down and listen.
Knifing the Nokia relationship left lots of enterprise customers in the dust, not because it was done, but it was done while 1) the product was still being actively pushed by both companies, and 2) without an assessment of what impact it would have on the customer base. Let's face it, the Nokia stuff was axed because ISS wanted to enter the appliance space, without regard to existing deployments. I still remember the arrogant tact of ISS's sales staff when they approached us with the news AND a quote for replacing all of our deployments with Proventia -- it was 20% higher than our TCO on Nokia! That was, and still is, a bad BUSINESS move, and left a lot of customers with a bad taste in their mouths about ISS. That aside...
I find your assertion about the Proventia G and M being "wildly popular" a bit dubious for a product that has only had about a year and a half in the market (and, yes, I'm counting that from the launch of the G400 and G2000 -- as an enterprise customer, they're the only ones we every considered). I talk with a lot of ISS customers. The big ones -- the truly big ones -- consider themselves saddled with their Proventia investment. They see other vendors coming in providing multi-gigabit solutions that operate at wire speeds on all packet sizes... They see IPS functionality being rolled into core switch fabrics, some of them on general purpose blades... They begin to wonder why they're invested in edge IPS when their firewalls are starting to gain the same feature functionality... And they get angry when a Core update munges their SiteProtector AGAIN... Leave the assessment of "wildly popular" to the point in time when these users report themselves as being totally satisfied with the investment they've made, not because our installed base is X^2 instead of X.
I know you've still got a "general purpose" network sensor out there. We used to run a few of those, until we had little nagging issues with XPUs where the proposed solution was "get to Proventia" because "that's where the development is being done now". And although your Network Sensor has an "inline mode," I know for a fact that your sales force actively steers people away from using it as an IPS. Having a product available is not the same as being able to provide undeniably good support for it -- just ask CA about that one.
As for the BlackICE (nee Desktop Protector, nee Proventia Desktop) installation, hey; what can I say? I wish we could all adopt a product at a point along its lifespan where everything is as we want it. But that didn't happen for us -- and for other customers (mostly bleeding-edge adopters). To speak to the "integration" with SiteProtector, I'd say the selling point there is relatively limited compared to what it was proposed to be when sold to us. But what do I know? I'm just a guy that has to redeploy a bunch of crap that will be replaced by GPO-managed Windows firewall rules and next-gen platform health checking that Microsoft will eventually give us for free. For the second time.
ISS is having its clock cleaned in the market, pulled apart by high-performance enterprise IPS vendors (Tipping Point, Juniper, Cisco, and the like) on one side, and having their thunder stolen by platform security vendors (Sygate, Check Point, Netscreen, and, yes, even Cisco) on the other -- not to mention the "built-in" stuff that Microsoft has released and the more advanced platform security controls that the company is prepping for release.
Not too long ago, ISS made the fateful decision to knife most of its IDS/IPS product lines in the back by discontinuing support for "General Purpose" servers and third party appliances, effectively forcing all of its enterprise customers to buy an "owned" ISS appliance (the Proventia series). Companies with large deployments of ISS RealSecure on now End of Lifed platforms suddenly found themselves offered a year of update support and another capital outlay to "upgrade" to Proventia appliances. Not many followed the company down that path, but the ones that did get "first cut" appliances found that they, well, sucked. The company then recentered on a more "appliance"-looking hardware platform, but, by then, the damage was done.
Then ISS took a market-leading desktop security product, BlackICE, and folded it into their IDS/IPS management product. The integration damn near killed a lot of existing BlackICE customers, not to mention the fact that succeeding software releases were, in many cases, incompatible with previous releases. Those customers who bravely rolled out a BlackICE installation found themselves in the unenviable position of having to do the rollout all over again.
Then there's ISS's reputation for "leading-edge" security research. Enter the firing of Michael Lynn related to the Cisco BlackHat presentation... They look like idiots out of the whole ordeal, more interested in protecting their corporate butts from the Cisco PR engine than the disclosure of even SANTITIZED security information.
IBM? Good luck with your new toy. It was broken before you bought it.
It always kills me when things like this happen because the backup systems aren't tested on a regular basis. ANY generator -- from the massive ones that can power datacenters to those little camping jobbies with two AC outlets on them -- should be run regularly under some form of load to ensure that when they're needed they still function.
Many generators, in fact, have an automatic "exercise" function that will kick them on at least once a month, run for about 15-30 minutes, and shut off. Any failure to start will turn on a failure light. My home natural gas-fed generator is like this. Our large generators at our datacenters do this. Hell, even the deep-cycle batteries that "carry over" until the generators are fully running are tested on a regular basis. Someone just has to be responsible enough to monitor the test runs for any failures.
It's easy to take all these good "survivable" resources and use them incorrectly in a datacenter environment. I _have_ seen instances where some bullheaded fire safety engineers will take a datacenter buildout and do very strange things with fire sensors and EPO (Emergency Power Off). It's typical that a fire suppression system will fire alarms when two or more sensors detect smoke. Many data centers will then trigger a Halon or FM200 dump to snuff out ignition sources after a fixed amount of time and a lot of head-splitting klaxon warnings. But I've seen some engineers rig the suppression system so the EPO is tripped BEFORE the dry suppression dumps (FM200 and Halon is incredibly expensive), effectively darkening the whole datacenter. EPO also locks out the generator and battery UPS systems, isolating them to their own busses.
Sounds sane? Consider this. Say you have an HVAC system that's spitting out a little smoke from a worn belt. When the EPO trips, the belt stops moving, the smoke disappears, and now your poor security guards have to use flashlights to try to find a now non-existant ignition source. They don't find it, so you have no choice but to turn the power back on. And then the belt starts smoking again, and... *click*
So often it's not the fact the datacenter has this stuff -- most do -- it's the fact that the stuff isn't really connected properly to the datacenter, isn't designed properly, or isn't managed well by datacenter staff.
Oh, absolutely true. Your security shouldn't depend on your silence, but silence should be a component of it (I believe the expression is "loose lips sink ships"). I'm not saying to keep completely tightlipped about the strategies you employ currently, but telegraphing your future steps in a public forum just adds to the overall risk of your current architecture and your future deployments.
That's not the reason for my post, though. It's been my experience that someone in a position like this who does interviews that are almost totally comprised of "we're going to do this" statements almost always DON'T. They never get that far.
I wish guys like him would save their interviews until after they DO something. Then they'd give us Infosec people less of a bad name.:>
"The first thing I intend to do as IT Chief to fix this security issue is to give a widely-disseminated public interview telegraphing the specific steps I intend to take to the public at large. I'm sure that will have the desired effect of reducing my network's overall risk level. Absolutely."
First, I should point out that some of the other posters here seem to think Sourcefire == Snort. It does not, although Sourcefire's products have some dependency on Snort as a general engine. Sourcefire's main product line is actually far deeper than just SnortOnABox -- it delves into areas like vulnerability management and event collection/aggregation, things that "open source" Snort does only if you have a really good administrator who knows how to piece together all the various moving parts into something manageable.
Second, it's remarkable that the DoD would question Check Point's intentions. If they truly cared whether this particular deal was in the best interests of "national security" (whatever that happens to mean today, then they wouldn't use Check Point's firewall products either. But they do! The US Navy uses Check Point firewalls in great, prodigious quantities -- enough that they need Check Point's ISP-class management console software to run all of them! And they're not the only branch of the military using it, not to mention the multitude of other Federal agencies.
This sounds like a reach to me. Something based in rumor, started by a politician, that has to be ended by the press finding the real story inside the rumor...
90% Of this problem would be solved with good FAQs on their website.
I wholeheartedly agree with you there -- and with your point about Tech Support. Do yourself a favor, though, and find out who your region's Sales Engineer is... They can answer questions frontline support can't. Plus, for a 70,000 employee company, they would agree to sit in your front pocket and print up fresh $20 bills for you if they thought it would sell more product, trust me.:>
Your experience with Checkpoint's support policies aren't all that strange -- they just recently started offering an "Enterprise Support" model that allows you to not _have_ to attach a support contract to a particular license. Made things a hell of a lot easier for us.
One note -- the version of Redhat that they last supported _is_ 7.3, but it's far more convienient to run SecurePlatform. That's Checkpoint's own Linux distribution -- a pretty slick little toy, IMHO. It should install nicely on most modern server hardware and can be upgraded from the management software simultaneously with the firewall software upgrade packages.
Don't discount Checkpoint as a product because the reseller is a dick. As the number of firewalls you maintain goes up, the way Checkpoint aggregates firewall policy starts to make a whole lot of sense...
If you couldn't get the software you needed easier than that, sounds like it's time to fire a reseller.:>
The book is good in many areas, especially dealing with Site-to-Site VPN configuration, but is seriously lacking in other areas. Some of the things missing are:
High Availability of management stations
Coverage of Provider-1, SiteManager-1 installations and the differences between them and the traditional management method
More detail on Checkpoint log servers (specifically CLMs and what they can and cannot do, including where they should typically be deployed and in what sitations)
Handling, munging, searching, and maintaining log files for Checkpoint products (there are scads of logfiles available, and some are quite hidden)
Steps to take to verify proper operation of a Firewall-1 node, including performance tuning ("fw ctl pstat" and how to read it, basically)
Using Checkpoint State Synchronization with AND without Checkpoint Clustering, and how to troubleshoot it
More information about tuning and maintenance of SmartDefense (the IPS features of Firewall-1) paying attention to "protocol gotchas" that can be eliminated through altering its configuration
A tutorial for the new Checkpoint administrator about all the different types of licenses with which one can and will deploy as part of a standard installation
The mentions of SecureRemote (the Client-to-LAN VPN built in to Checkpoint Firewall-1) are lacking in many respects -- for example, there is little mention of Secure Configuration Verification, Visitor Mode/Office Mode, IP address assignment mechanisms (there are many), etc.
More detail in the following areas: CIFS blocking, Exchange/Windows RPC custom handling, integration with URL filtering via UFP, differences between the FTP/FTP_BASIC methods, etc.
Of course, I suppose 80% of the administrators that would buy this book don't care one bit about these details if they're only running a couple of standalone Firewall-1 boxes. The funny thing, though, about companies that buy a product as expensive as Checkpoint Firewall-1 is that they tend to expand their investment in the product fairly rapidly -- if they buy enough of it up front to be a serious investment. For those administrators, it's the type of information like the above that is really missing.
What's a shame is that it's also generally missing in Checkpoint's own documentation.:>
What's described here is not so much a hack of the Streamium itself as a reverse-engineering of the XML-based protocol used by the MusicMatch Jukebox Media Server. The Streamium requires MM Jukebox to be loaded on at least one PC on the local subnet for the PC-Link feature to work.
It works like this: The Streamium sends out a broadcast UDP packet -- sorry, I forget which port at the moment, but it's in my notes -- and any PC with the MM Jukebox Media Server loaded sends back a UDP packet in response. The collected responses are displayed on the front panel.
The XML format is interesting, as it is sort of a page-description language over XML. There are root-nodes, menu-nodes, and leaf-nodes, and these correspond to tracks and subcategories. But all of this, of course, it automagically generated by MM Jukebox (Genre, Title, etc...). So this perl script is really of limited usefulness until someone can graft it to something like XMMS which keeps and categorizes tag information.
A long time ago, you could destroy your files and have a very bad day by using that floppy from your friend that had creeping crud on it.
Shortly thereafter, your files were potentially at risk from files that you spent all day downloading from a BBS. Fairly soon after that, a malicious file could sneak onto your hard drive and cause mischief once FTPed from the Internet at a bit higher of a rate. In each case, you pretty much had to type the name of the file to run it.
Enter the world of Windows. Now running the file gets a hell of a lot easier, just a few points and clicks. And obtaining those lovely infected files gets a lot easier with the faster Internet connections and new "killer apps" like Usenet, e-mail, and the World Wide Web gaining in popularity. In less than a year, these files gain literally thousands of new vectors.
Then it becomes possible to pick up an infection by receiving a file via e-mail inside a program that loves to muck about with files before you run them by, er... running them. The only user interaction required is hitting the "send/recieve" button.
After that, malicious files no longer need to be files. They can be specially formatted e-mails, and all you need to do is preview them -- you don't even have to read them -- in order to get smacked by the latest nasty bug.
Don't feel e-mail is safe? Well, it wouldn't matter if you stopped using it entirely, the creeping crud will still get in if you click on a link on the Web. And as if the front door didn't put up a paper-thin defense, the back door will allow malware to slip in via Web server software, file shares, file transfer servers, and even instant messaging.
Now what do we have?
A malicious file you only have to point at for a moment to get an infection.
When I was looking at a BRS for a Cessna 172, there was a disclaimer about deployment being fatal to an aircraft. I was told that although the plane may survive well enough to be flown again, the BRS system manufacturer had to agree with the FAA that any plane whose parachute had been deployed in flight would be red-stickered and permanently grounded.
Two things are different, I suppose, from the Cirrus: the Cessna BRS is an add-on to an existing airframe whereas the Cirrus is an installed option, and the mooring points for the aircraft are not located above the airframe's center-of-gravity (no room for the deployment tube there).
Maybe that holds true for a Cessna and not a Cirrus? Don't know.
It all seemed a little odd to me -- I've seen aircraft scraped off the bottom of a lake by a salvage company and returned to flyable condition in a few months, so even a rough and tumble parachute landing didn't seem too much of a cause for grounding the aircraft permanently.
An interesting note about this type of aircraft parachute: most of the ones that are deployed on GA aircraft are ballistic-assisted parachutes. Once triggered, the parachute is fully extended from a compacted state inside a tube by a small rocket. The chute itself reaches full extension in a little over 1 second. That short deployment time makes the chute more useful in the lower altitudes that a small aircraft would frequent.
Then there's the matter of "spillover" -- the state that a parachute will quickly find itself in if deployed behind a fast-moving heavy ballast. If this happens, the chute will collapse and begin to work a little more line a streamer than a parachute -- it won't inflate after the air gets forced out of it. To combat this, a "speed ring" -- essentially a small baffled airfoil attached to the chute harness -- blocks the air entering the chute from the bottom. As forward momentum decreases, gravity causes the ring to slowly fall downward, allowing the chute to slowly and safely inflate.
A really fascinating thing about the BRS type parachutes: Once they deploy the aircraft is totalled. It can never fly again. First, a deployment typically stresses an airframe in two ways that it usually never is stressed -- the wing spars are pulled backwards while in flight, and the vertical impact of the ground with the aircraft at a relatively high speed. The FAA will never allow the aircraft to be flown again.
The second reason: the parachute tethers are typically stowed under the skin of most aircraft, and in deployment can actually rip through the skin. Damage of this type is very difficult to repair, so the pilot that chooses to use the BRS system _knows_ that he will lose the plane permanently.
That usually keeps pilots looking for that tempting field or road if they have an in-flight emergency.
That would make sense -- if the license didn't also make the program free to use for all entities both commercial and non-commercial. They may be exceedingly underfunded, but they aren't deriving _any_ income from Pine by license!
So, the question stands: What gives with the license?
Pine is a really nice mail app, for sure. But I still think it has one of the quirkiest licenses of any source-available application out there. It specifically forbids development and support of branches of the codebase -- if I add a cool new feature that the maintainers refuse to add (web browsing, maybe), then I can't split off and make "Joe's Pine," I have to distribute a diff file with the original source tarball.
The question you should be asking is whether you have the freedom from pervasive government oversight as a result of Constitutional statute. Anonymity has never been a right of every citizen (that's the American way, just ask the advertising and marketing industry). However, there is a reasonable expectation to freedom from having our actions _overseen_ by our own government. It's one of the core distinctions of democracy itself, that the citizenry are the government's overseers, not the other way around.
I think I can. The US Army-operated root server looks like it took the brunt of the attack, as opposed to the JPNIC servers, which seem to have had a much lower rate (perhaps because most of the attacking hosts were US-based?).
If you want to see in gory detail what a DDOS attack looks like in relation to what NORMALLY happens to these servers, try here. Notice the really big spike. As if you could miss it.
Quality of instruction? Bah! You should feel damned good that the place you work still has money to spend to bring in outside trainers at all. I don't know who you work for, but myself and most of my friends (all professional programmers and Infosec types) haven't gotten any training -- outside or otherwise -- approved since September 11th.
Maybe it's just the general slowdown in the IT world in general, but the picture I get from most of the techies with which I associate is grim. Every single one tells me how the company they work for cut the training budget to the bone, along with any budget for travel. Hell, at my company, to save money, they've even restricted who gets business cards!
Perhaps it's for the best. I've had, in the past, a lot of training -- both off-site and on-site -- with a lot of different companies. From big league Verisign to small-potatoes Motive, I've found that professional trainers usually run about 3 or 4 months behind a good programmer that reads selected forums and Dr. Dobbs. In one particular instance with a Verisign instructor, _I_ ended up teaching the class because the instructor had never used the LDAP integration native to Firewall-1 -- this in an Engineer-level class!
So if you are getting a training budget at all, your money might be better spent if your guys get together and pick someone they know by code rather than reputation. Fly that person in, and spend a week with them at work and after hours -- it'll be a lot more constructive. In other words, have the company pony up its money for someone whose technique you want to know rather than a professional instructor whose methods are unknown and suspect. Who _wouldn't_ want a memory-management tutorial from Linus, or a UI design class from Andy Hertzfeld?
This approach works fine if the firewalls allow ssh traffic (22/tcp). But I was referring to the instance where an extremely restrictive firewall (and the ones where censorware exists tend to be the paranoid ones) allows only 80/443 and sometimes ftp. To jump past that, it's possible to use HTTPS CONNECT to push through to an SSH server ("CONNECT sitename:22 HTTP/1.1") -- the majority of firewall configurations I've seen always forget to restrict CONNECT.
I was at the talk. This is exactly the audience they're looking to serve.
Well, I figured that. For the Average Joe living in Average-JoeLand, this approach doesn't make much sense -- which is what a lot of the commenters seem to be assuming.
There were a lot of yet-unanswered questions raised about this tech, but they did address the one you raise about responders being known, and addressed it rather well. Basically, it should be difficult to identify responders by randomly talking to servers, and those that use the system are assumed to be in dire enough straits to keep the knoweledge of where responders are secret. They do, however, require the existence of a large network of responders and a client that can move amongst them seemingly at random to avoid basic traffic analysis that would show which servers the responders are. But if the tech is actually implemented as they envision, the problem you're talking about wouldn't really be there.
The requester has to know how to get to the responder -- and it may mask its requests with traffic to "random" sites -- that much is perfectly clear from the document. But it doesn't escape the fact that the following _must_ hold true in any "proxy avoidance" scenario where a large group of potential proxy sites is available:
1) The requester must obtain a list of possible responders from somewhere that is encoded into the requester itself, or 2) The requester must have a list of "master" responders encoded into itself, or 3) The requester must have a list of all active requesters loaded into it, either by hand or included in the distribution.
If the software is then made _generally_ available, then the knowledge of the identities of the "list container" sites, the "master" responders, or the master list would be known. And that's all the censorware people need to figure out how to block the traffic.
A far simpler approach would be to encode web traffic in steganographic traffic carried over ANOTHER common protocol that usually _isn't_ watched by common censorware. FTP? Telnet? SMB? As it is, this might work for limited P2P, but a "public" phalanx of these responders would get blocked ASAP.
Wish I could have been at that talk, though. It's a fascinating concept.
I have quite a bit of experience with a few of the "censor" systems that exist due to my work in Infosec at the corporate level. I have to say that, based on my reading of the whitepaper, I'm uncertain that this will be a sufficient way to bypass most of the censorware that is widely deployed on (at least) corporate network gateways.
The problem here is that the "Infranet" software must talk to the responder directly in order for its steganographic stream to be understood. In the parlance of at least one censorware product, this type of thing would be classified as a "Proxy Avoidance System" and be blocked accordingly. This might be effective against keyword blocking due to the nature of the information being transmitted, but if used as a straight proxy bypass, most censorware products would only need to know where the responders are.
This method would be more difficult to detect than a straight proxy-through, but it still doesn't account for the fact that the "responders" must be known in some way to the transmitter. If a series of public responders is set up, it would only be a matter of time before those sites would be sewed up tighter than a drum by most "reputable" censorware companies' research teams.
As it is, it's not terribly difficult to bypass censorware if you have the ability to put something up on the outside to bounce off of. Nearly all of the production censorware that I see does absolutely nothing with HTTPS -- and the lax security of most firewall policies doesn't restrict the destination port of a standard HTTP/1.1 CONNECT request. With that available, give me any SSH server on the outside and I can get an encrypted session running to a proxy in a matter of minutes.
Come to think of it, I've never heard the people complaining about censorware's _limitations_, only about the limits that it places on them. The truth is that every one of them is imminently bypassable already. Why bother with steganographic communications unless you live in a place where even initiating encrypted communications would put you in the pokey?
Slashdot Mirror
Hey, glad to see ISS's PR department knows about Slashdot. And, hey! You're right, I was affected by the product line "simplification"! Glad to meet you, now sit down and listen.
Knifing the Nokia relationship left lots of enterprise customers in the dust, not because it was done, but it was done while 1) the product was still being actively pushed by both companies, and 2) without an assessment of what impact it would have on the customer base. Let's face it, the Nokia stuff was axed because ISS wanted to enter the appliance space, without regard to existing deployments. I still remember the arrogant tact of ISS's sales staff when they approached us with the news AND a quote for replacing all of our deployments with Proventia -- it was 20% higher than our TCO on Nokia! That was, and still is, a bad BUSINESS move, and left a lot of customers with a bad taste in their mouths about ISS. That aside...
I find your assertion about the Proventia G and M being "wildly popular" a bit dubious for a product that has only had about a year and a half in the market (and, yes, I'm counting that from the launch of the G400 and G2000 -- as an enterprise customer, they're the only ones we every considered). I talk with a lot of ISS customers. The big ones -- the truly big ones -- consider themselves saddled with their Proventia investment. They see other vendors coming in providing multi-gigabit solutions that operate at wire speeds on all packet sizes... They see IPS functionality being rolled into core switch fabrics, some of them on general purpose blades... They begin to wonder why they're invested in edge IPS when their firewalls are starting to gain the same feature functionality... And they get angry when a Core update munges their SiteProtector AGAIN... Leave the assessment of "wildly popular" to the point in time when these users report themselves as being totally satisfied with the investment they've made, not because our installed base is X^2 instead of X.
I know you've still got a "general purpose" network sensor out there. We used to run a few of those, until we had little nagging issues with XPUs where the proposed solution was "get to Proventia" because "that's where the development is being done now". And although your Network Sensor has an "inline mode," I know for a fact that your sales force actively steers people away from using it as an IPS. Having a product available is not the same as being able to provide undeniably good support for it -- just ask CA about that one.
As for the BlackICE (nee Desktop Protector, nee Proventia Desktop) installation, hey; what can I say? I wish we could all adopt a product at a point along its lifespan where everything is as we want it. But that didn't happen for us -- and for other customers (mostly bleeding-edge adopters). To speak to the "integration" with SiteProtector, I'd say the selling point there is relatively limited compared to what it was proposed to be when sold to us. But what do I know? I'm just a guy that has to redeploy a bunch of crap that will be replaced by GPO-managed Windows firewall rules and next-gen platform health checking that Microsoft will eventually give us for free. For the second time.
Thanks for the response, though.
This is a horrible move on IBM's part.
ISS is having its clock cleaned in the market, pulled apart by high-performance enterprise IPS vendors (Tipping Point, Juniper, Cisco, and the like) on one side, and having their thunder stolen by platform security vendors (Sygate, Check Point, Netscreen, and, yes, even Cisco) on the other -- not to mention the "built-in" stuff that Microsoft has released and the more advanced platform security controls that the company is prepping for release.
Not too long ago, ISS made the fateful decision to knife most of its IDS/IPS product lines in the back by discontinuing support for "General Purpose" servers and third party appliances, effectively forcing all of its enterprise customers to buy an "owned" ISS appliance (the Proventia series). Companies with large deployments of ISS RealSecure on now End of Lifed platforms suddenly found themselves offered a year of update support and another capital outlay to "upgrade" to Proventia appliances. Not many followed the company down that path, but the ones that did get "first cut" appliances found that they, well, sucked. The company then recentered on a more "appliance"-looking hardware platform, but, by then, the damage was done.
Then ISS took a market-leading desktop security product, BlackICE, and folded it into their IDS/IPS management product. The integration damn near killed a lot of existing BlackICE customers, not to mention the fact that succeeding software releases were, in many cases, incompatible with previous releases. Those customers who bravely rolled out a BlackICE installation found themselves in the unenviable position of having to do the rollout all over again.
Then there's ISS's reputation for "leading-edge" security research. Enter the firing of Michael Lynn related to the Cisco BlackHat presentation... They look like idiots out of the whole ordeal, more interested in protecting their corporate butts from the Cisco PR engine than the disclosure of even SANTITIZED security information.
IBM? Good luck with your new toy. It was broken before you bought it.
It always kills me when things like this happen because the backup systems aren't tested on a regular basis. ANY generator -- from the massive ones that can power datacenters to those little camping jobbies with two AC outlets on them -- should be run regularly under some form of load to ensure that when they're needed they still function.
Many generators, in fact, have an automatic "exercise" function that will kick them on at least once a month, run for about 15-30 minutes, and shut off. Any failure to start will turn on a failure light. My home natural gas-fed generator is like this. Our large generators at our datacenters do this. Hell, even the deep-cycle batteries that "carry over" until the generators are fully running are tested on a regular basis. Someone just has to be responsible enough to monitor the test runs for any failures.
It's easy to take all these good "survivable" resources and use them incorrectly in a datacenter environment. I _have_ seen instances where some bullheaded fire safety engineers will take a datacenter buildout and do very strange things with fire sensors and EPO (Emergency Power Off). It's typical that a fire suppression system will fire alarms when two or more sensors detect smoke. Many data centers will then trigger a Halon or FM200 dump to snuff out ignition sources after a fixed amount of time and a lot of head-splitting klaxon warnings. But I've seen some engineers rig the suppression system so the EPO is tripped BEFORE the dry suppression dumps (FM200 and Halon is incredibly expensive), effectively darkening the whole datacenter. EPO also locks out the generator and battery UPS systems, isolating them to their own busses.
Sounds sane? Consider this. Say you have an HVAC system that's spitting out a little smoke from a worn belt. When the EPO trips, the belt stops moving, the smoke disappears, and now your poor security guards have to use flashlights to try to find a now non-existant ignition source. They don't find it, so you have no choice but to turn the power back on. And then the belt starts smoking again, and...
*click*
So often it's not the fact the datacenter has this stuff -- most do -- it's the fact that the stuff isn't really connected properly to the datacenter, isn't designed properly, or isn't managed well by datacenter staff.
"This text had been classified as
INAUTHENTIC
with a 24.9% chance of being authentic text"
No kidding.
Oh, absolutely true. Your security shouldn't depend on your silence, but silence should be a component of it (I believe the expression is "loose lips sink ships"). I'm not saying to keep completely tightlipped about the strategies you employ currently, but telegraphing your future steps in a public forum just adds to the overall risk of your current architecture and your future deployments.
:>
That's not the reason for my post, though. It's been my experience that someone in a position like this who does interviews that are almost totally comprised of "we're going to do this" statements almost always DON'T. They never get that far.
I wish guys like him would save their interviews until after they DO something. Then they'd give us Infosec people less of a bad name.
"The first thing I intend to do as IT Chief to fix this security issue is to give a widely-disseminated public interview telegraphing the specific steps I intend to take to the public at large. I'm sure that will have the desired effect of reducing my network's overall risk level. Absolutely."
First, I should point out that some of the other posters here seem to think Sourcefire == Snort. It does not, although Sourcefire's products have some dependency on Snort as a general engine. Sourcefire's main product line is actually far deeper than just SnortOnABox -- it delves into areas like vulnerability management and event collection/aggregation, things that "open source" Snort does only if you have a really good administrator who knows how to piece together all the various moving parts into something manageable.
Second, it's remarkable that the DoD would question Check Point's intentions. If they truly cared whether this particular deal was in the best interests of "national security" (whatever that happens to mean today, then they wouldn't use Check Point's firewall products either. But they do! The US Navy uses Check Point firewalls in great, prodigious quantities -- enough that they need Check Point's ISP-class management console software to run all of them! And they're not the only branch of the military using it, not to mention the multitude of other Federal agencies.
This sounds like a reach to me. Something based in rumor, started by a politician, that has to be ended by the press finding the real story inside the rumor...
Trillian Pro can do that -- including SIP messaging with Live Communications Server -- with the (very alpha) SIP plugin for Trillian located here.
Oddly, it looks like CIA Headquarters and the NSA headquarters in Fort Meade don't suffer the same fate as these other "public" structures. Wonder why?
I think you might be able to take your pick from Thinkgeek today, if you're so inclined.
90% Of this problem would be solved with good FAQs on their website.
:>
I wholeheartedly agree with you there -- and with your point about Tech Support. Do yourself a favor, though, and find out who your region's Sales Engineer is... They can answer questions frontline support can't. Plus, for a 70,000 employee company, they would agree to sit in your front pocket and print up fresh $20 bills for you if they thought it would sell more product, trust me.
Your experience with Checkpoint's support policies aren't all that strange -- they just recently started offering an "Enterprise Support" model that allows you to not _have_ to attach a support contract to a particular license. Made things a hell of a lot easier for us.
:>
One note -- the version of Redhat that they last supported _is_ 7.3, but it's far more convienient to run SecurePlatform. That's Checkpoint's own Linux distribution -- a pretty slick little toy, IMHO. It should install nicely on most modern server hardware and can be upgraded from the management software simultaneously with the firewall software upgrade packages.
Don't discount Checkpoint as a product because the reseller is a dick. As the number of firewalls you maintain goes up, the way Checkpoint aggregates firewall policy starts to make a whole lot of sense...
If you couldn't get the software you needed easier than that, sounds like it's time to fire a reseller.
- High Availability of management stations
- Coverage of Provider-1, SiteManager-1 installations and the differences between them and the traditional management method
- More detail on Checkpoint log servers (specifically CLMs and what they can and cannot do, including where they should typically be deployed and in what sitations)
- Handling, munging, searching, and maintaining log files for Checkpoint products (there are scads of logfiles available, and some are quite hidden)
- Steps to take to verify proper operation of a Firewall-1 node, including performance tuning ("fw ctl pstat" and how to read it, basically)
- Using Checkpoint State Synchronization with AND without Checkpoint Clustering, and how to troubleshoot it
- More information about tuning and maintenance of SmartDefense (the IPS features of Firewall-1) paying attention to "protocol gotchas" that can be eliminated through altering its configuration
- A tutorial for the new Checkpoint administrator about all the different types of licenses with which one can and will deploy as part of a standard installation
- The mentions of SecureRemote (the Client-to-LAN VPN built in to Checkpoint Firewall-1) are lacking in many respects -- for example, there is little mention of Secure Configuration Verification, Visitor Mode/Office Mode, IP address assignment mechanisms (there are many), etc.
- More detail in the following areas: CIFS blocking, Exchange/Windows RPC custom handling, integration with URL filtering via UFP, differences between the FTP/FTP_BASIC methods, etc.
Of course, I suppose 80% of the administrators that would buy this book don't care one bit about these details if they're only running a couple of standalone Firewall-1 boxes. The funny thing, though, about companies that buy a product as expensive as Checkpoint Firewall-1 is that they tend to expand their investment in the product fairly rapidly -- if they buy enough of it up front to be a serious investment. For those administrators, it's the type of information like the above that is really missing. What's a shame is that it's also generally missing in Checkpoint's own documentation.It works like this: The Streamium sends out a broadcast UDP packet -- sorry, I forget which port at the moment, but it's in my notes -- and any PC with the MM Jukebox Media Server loaded sends back a UDP packet in response. The collected responses are displayed on the front panel.
The XML format is interesting, as it is sort of a page-description language over XML. There are root-nodes, menu-nodes, and leaf-nodes, and these correspond to tracks and subcategories. But all of this, of course, it automagically generated by MM Jukebox (Genre, Title, etc...). So this perl script is really of limited usefulness until someone can graft it to something like XMMS which keeps and categorizes tag information.
A long time ago, you could destroy your files and have a very bad day by using that floppy from your friend that had creeping crud on it.
Shortly thereafter, your files were potentially at risk from files that you spent all day downloading from a BBS. Fairly soon after that, a malicious file could sneak onto your hard drive and cause mischief once FTPed from the Internet at a bit higher of a rate. In each case, you pretty much had to type the name of the file to run it.
Enter the world of Windows. Now running the file gets a hell of a lot easier, just a few points and clicks. And obtaining those lovely infected files gets a lot easier with the faster Internet connections and new "killer apps" like Usenet, e-mail, and the World Wide Web gaining in popularity. In less than a year, these files gain literally thousands of new vectors.
Then it becomes possible to pick up an infection by receiving a file via e-mail inside a program that loves to muck about with files before you run them by, er... running them. The only user interaction required is hitting the "send/recieve" button.
After that, malicious files no longer need to be files. They can be specially formatted e-mails, and all you need to do is preview them -- you don't even have to read them -- in order to get smacked by the latest nasty bug.
Don't feel e-mail is safe? Well, it wouldn't matter if you stopped using it entirely, the creeping crud will still get in if you click on a link on the Web. And as if the front door didn't put up a paper-thin defense, the back door will allow malware to slip in via Web server software, file shares, file transfer servers, and even instant messaging.
Now what do we have?
A malicious file you only have to point at for a moment to get an infection.
You've come a long way, baby.
When I was looking at a BRS for a Cessna 172, there was a disclaimer about deployment being fatal to an aircraft. I was told that although the plane may survive well enough to be flown again, the BRS system manufacturer had to agree with the FAA that any plane whose parachute had been deployed in flight would be red-stickered and permanently grounded.
Two things are different, I suppose, from the Cirrus: the Cessna BRS is an add-on to an existing airframe whereas the Cirrus is an installed option, and the mooring points for the aircraft are not located above the airframe's center-of-gravity (no room for the deployment tube there).
Maybe that holds true for a Cessna and not a Cirrus? Don't know.
It all seemed a little odd to me -- I've seen aircraft scraped off the bottom of a lake by a salvage company and returned to flyable condition in a few months, so even a rough and tumble parachute landing didn't seem too much of a cause for grounding the aircraft permanently.
An interesting note about this type of aircraft parachute: most of the ones that are deployed on GA aircraft are ballistic-assisted parachutes. Once triggered, the parachute is fully extended from a compacted state inside a tube by a small rocket. The chute itself reaches full extension in a little over 1 second. That short deployment time makes the chute more useful in the lower altitudes that a small aircraft would frequent.
Then there's the matter of "spillover" -- the state that a parachute will quickly find itself in if deployed behind a fast-moving heavy ballast. If this happens, the chute will collapse and begin to work a little more line a streamer than a parachute -- it won't inflate after the air gets forced out of it. To combat this, a "speed ring" -- essentially a small baffled airfoil attached to the chute harness -- blocks the air entering the chute from the bottom. As forward momentum decreases, gravity causes the ring to slowly fall downward, allowing the chute to slowly and safely inflate.
A really fascinating thing about the BRS type parachutes: Once they deploy the aircraft is totalled. It can never fly again. First, a deployment typically stresses an airframe in two ways that it usually never is stressed -- the wing spars are pulled backwards while in flight, and the vertical impact of the ground with the aircraft at a relatively high speed. The FAA will never allow the aircraft to be flown again.
The second reason: the parachute tethers are typically stowed under the skin of most aircraft, and in deployment can actually rip through the skin. Damage of this type is very difficult to repair, so the pilot that chooses to use the BRS system _knows_ that he will lose the plane permanently.
That usually keeps pilots looking for that tempting field or road if they have an in-flight emergency.
That would make sense -- if the license didn't also make the program free to use for all entities both commercial and non-commercial. They may be exceedingly underfunded, but they aren't deriving _any_ income from Pine by license!
So, the question stands: What gives with the license?
Pine is a really nice mail app, for sure. But I still think it has one of the quirkiest licenses of any source-available application out there. It specifically forbids development and support of branches of the codebase -- if I add a cool new feature that the maintainers refuse to add (web browsing, maybe), then I can't split off and make "Joe's Pine," I have to distribute a diff file with the original source tarball.
The question you should be asking is whether you have the freedom from pervasive government oversight as a result of Constitutional statute. Anonymity has never been a right of every citizen (that's the American way, just ask the advertising and marketing industry). However, there is a reasonable expectation to freedom from having our actions _overseen_ by our own government. It's one of the core distinctions of democracy itself, that the citizenry are the government's overseers, not the other way around.
I think I can. The US Army-operated root server looks like it took the brunt of the attack, as opposed to the JPNIC servers, which seem to have had a much lower rate (perhaps because most of the attacking hosts were US-based?).
If you want to see in gory detail what a DDOS attack looks like in relation to what NORMALLY happens to these servers, try here. Notice the really big spike. As if you could miss it.
Quality of instruction? Bah! You should feel damned good that the place you work still has money to spend to bring in outside trainers at all. I don't know who you work for, but myself and most of my friends (all professional programmers and Infosec types) haven't gotten any training -- outside or otherwise -- approved since September 11th.
Maybe it's just the general slowdown in the IT world in general, but the picture I get from most of the techies with which I associate is grim. Every single one tells me how the company they work for cut the training budget to the bone, along with any budget for travel. Hell, at my company, to save money, they've even restricted who gets business cards!
Perhaps it's for the best. I've had, in the past, a lot of training -- both off-site and on-site -- with a lot of different companies. From big league Verisign to small-potatoes Motive, I've found that professional trainers usually run about 3 or 4 months behind a good programmer that reads selected forums and Dr. Dobbs. In one particular instance with a Verisign instructor, _I_ ended up teaching the class because the instructor had never used the LDAP integration native to Firewall-1 -- this in an Engineer-level class!
So if you are getting a training budget at all, your money might be better spent if your guys get together and pick someone they know by code rather than reputation. Fly that person in, and spend a week with them at work and after hours -- it'll be a lot more constructive. In other words, have the company pony up its money for someone whose technique you want to know rather than a professional instructor whose methods are unknown and suspect. Who _wouldn't_ want a memory-management tutorial from Linus, or a UI design class from Andy Hertzfeld?
Why so long?
% ssh -D8080
browser -> configs -> proxy -> socks4 proxy = 8080
This approach works fine if the firewalls allow ssh traffic (22/tcp). But I was referring to the instance where an extremely restrictive firewall (and the ones where censorware exists tend to be the paranoid ones) allows only 80/443 and sometimes ftp. To jump past that, it's possible to use HTTPS CONNECT to push through to an SSH server ("CONNECT sitename:22 HTTP/1.1") -- the majority of firewall configurations I've seen always forget to restrict CONNECT.
I was at the talk. This is exactly the audience they're looking to serve.
Well, I figured that. For the Average Joe living in Average-JoeLand, this approach doesn't make much sense -- which is what a lot of the commenters seem to be assuming.
There were a lot of yet-unanswered questions raised about this tech, but they did address the one you raise about responders being known, and addressed it rather well. Basically, it should be difficult to identify responders by randomly talking to servers, and those that use the system are assumed to be in dire enough straits to keep the knoweledge of where responders are secret. They do, however, require the existence of a large network of responders and a client that can move amongst them seemingly at random to avoid basic traffic analysis that would show which servers the responders are. But if the tech is actually implemented as they envision, the problem you're talking about wouldn't really be there.
The requester has to know how to get to the responder -- and it may mask its requests with traffic to "random" sites -- that much is perfectly clear from the document. But it doesn't escape the fact that the following _must_ hold true in any "proxy avoidance" scenario where a large group of potential proxy sites is available:
1) The requester must obtain a list of possible responders from somewhere that is encoded into the requester itself, or
2) The requester must have a list of "master" responders encoded into itself, or
3) The requester must have a list of all active requesters loaded into it, either by hand or included in the distribution.
If the software is then made _generally_ available, then the knowledge of the identities of the "list container" sites, the "master" responders, or the master list would be known. And that's all the censorware people need to figure out how to block the traffic.
A far simpler approach would be to encode web traffic in steganographic traffic carried over ANOTHER common protocol that usually _isn't_ watched by common censorware. FTP? Telnet? SMB? As it is, this might work for limited P2P, but a "public" phalanx of these responders would get blocked ASAP.
Wish I could have been at that talk, though. It's a fascinating concept.
I have quite a bit of experience with a few of the "censor" systems that exist due to my work in Infosec at the corporate level. I have to say that, based on my reading of the whitepaper, I'm uncertain that this will be a sufficient way to bypass most of the censorware that is widely deployed on (at least) corporate network gateways.
The problem here is that the "Infranet" software must talk to the responder directly in order for its steganographic stream to be understood. In the parlance of at least one censorware product, this type of thing would be classified as a "Proxy Avoidance System" and be blocked accordingly. This might be effective against keyword blocking due to the nature of the information being transmitted, but if used as a straight proxy bypass, most censorware products would only need to know where the responders are.
This method would be more difficult to detect than a straight proxy-through, but it still doesn't account for the fact that the "responders" must be known in some way to the transmitter. If a series of public responders is set up, it would only be a matter of time before those sites would be sewed up tighter than a drum by most "reputable" censorware companies' research teams.
As it is, it's not terribly difficult to bypass censorware if you have the ability to put something up on the outside to bounce off of. Nearly all of the production censorware that I see does absolutely nothing with HTTPS -- and the lax security of most firewall policies doesn't restrict the destination port of a standard HTTP/1.1 CONNECT request. With that available, give me any SSH server on the outside and I can get an encrypted session running to a proxy in a matter of minutes.
Come to think of it, I've never heard the people complaining about censorware's _limitations_, only about the limits that it places on them. The truth is that every one of them is imminently bypassable already. Why bother with steganographic communications unless you live in a place where even initiating encrypted communications would put you in the pokey?