In the case of the TJX brief, we found out in SEC disclosures in their 8-K filings. We have generally understood that a significant breach is a material corporate disclosure. So yeah, they wrote a law.

First and foremost, the most common reason I see to have poor network traffic controls (on network or system level firewalls) is that defining the traffic ACLs is to skill/labor intensive. You need to have the skills and patience (read: time) to make sure that everything works and you're blocking everything else.

That being said, I tend to design systems to rely primarily on the network level when I can for traffic controls because I reduce the number of possible points of configuration which helps configuration management, auditing, and troubleshooting. If I do want focus on the host I am more likely to use host level firewalls on Linux systems for 2 reasons, 1) the services to be permitted are easier to isolate, and 2) iptables configurations are much easier to archive, manage, and audit (at least for me, I really haven't had much success with any kind of task automation with the windows firewall or ForeFront).

Cloud IaaS can make this complicated, because it's much more involved to employ network or "soft" VM based firewalls, and creating traffic isolation in elastic environments is tricky. The times I've designed for Amazon AWS, I pushed the systems design to Linux, rather than windows (Drupal/MySQL system that was being migrated from a Windows implementation to cloud hosting) partially because of the network traffic controls.

Network security design is not about firewalling everything, it's not that simple and the more things you have manipulating traffic, the more trouble you're buying down the road. It's about defining your security zones (how needs access to what, and how are they getting there), and then determining what controls to use. If, in the OP's instance, it's a web server and DB server in a DMZ that has ingress of HTTPS (443/TCP) and no egress, then I'm not sure that an additional control between the 2 servers buys you too much. The main advantage I see is limiting the depth of exploit if either of the 2 servers is compromised, but given that they are windows servers, and it's likely that they are using SMB/CIFS (137/TCP, 139/TCP, 445/TCP) rather than SQL server authentication, you have to allow all the ports you'd want to block anyway.

Your solution,"Stop liking what I don't like.", does not scale.

The point here is that regardless of where the customer unfriendly behavior is coming from, the customer has very little recourse to vote with their wallet. Market freedom isn't working, and regulation is unfortunately capriciously applied. I'll accept that streaming introduced negative externalities to the Internet peering arrangements, but service providers have been much more interested in being content providers than dealing with the inherent overhead problems.

Ms Granick, I'd really appreciate your perspective of where you think the personal privacy equilibrium will be.

What personal privacy protections do you believe will survive the next 20 years in the US?

Do you believe that there will be individual control of personal information that will have suffice force of law to be functional meaningful in the US?

Do you believe those protections will be useful if the information is stored outside the US?

Thanks for the ./interview.

If it works that way than it's likely that the blocks form a file will all be contained on the same volume (all of a file will be on the SSD or the HD, but not both). In that case, normal forensics of the volume would work as expected. It depends on how the file allocation tables are written, but it's possible that the volume might be mountable by a linux system.

Here's an approach that would be possible:

  - All files are contained on the HDD
  - Highly accessed files are copied to the SSD
  - The file table on the HDD is marked to say "this file is at that block on the SSD - go read it there"
  - If a marked file is written to, then both the HDD and the SSD copy are written to
  - There'd probably be some coordination magic, such as the versions on the SSD are checksumed against the versions on the HDD on boot, and the HDD ones take precedence - that way you could fix something off line and it would still work.

If the object is to keep highly read files on the SSD because of the seek and access time advantage, then this approach would do that without killing your ability to work on the filesystem offline. This assumes that we only want to use the SSD for caching files to be read, which is reasonable, as writes to SSDs are slower and are where the wear issues are.

Frankly we won't know what the limitations are until we do forensic examination of the volumes handled by the driver.

Stuxnet was signed by stolen certificates: http://www.securelist.com/en/analysis/204792208/Stuxnet_Duqu_The_Evolution_of_Drivers?print_mode=1 . it's possible that Flamer was signed by compromised certificates, but if we believe that Stuxnet and Duqu were the products of a nation state level actor then we could conclude that Flamer is in the same category.

I get infections an average of once a year. About 2/3s of the time I can fight them off with a combination of rest, sinus irrigation, and antihistamines. When that fails, I do not get better without a course of antibiotics. I have waited weeks to months before going to the doctor for the prescription. In my case I strongly doubt that it's a placebo effect.

This leads me to ask if the problem is one of selection, meaning that maybe doctors are either writing prescriptions too soon or they need another data point to make an accurate diagnosis.

The enterprise mobile email system really needs to move to an app. Fewer folks and fewer companies want to deal with a work issued phone. We need an app for all of the smartphone platforms that keeps the mail store encrypted and authentication credentials at rest. It also needs an infrastructure that supports remote wiping of the app's authentication and user data. We no longer need to run the hardware side for mobile enterprise mail and sticking to that model is just making RIM's biggest problem over again.

There are hard parts to solving a lot of expected functions, like how do you keep the authentication information secure and do automatic email pulls or how to keep the user data secure and still do calendar reminders.

My success rate with Cisco's TAC is 5%. They have solved my problem before I solved it myself, worked around it, or went with another solution. So far, for me they're 2 for 40. Their documentation is generally quite comprehensive though. The site search has never been very good, so I find it best to google using 'site:cisco.com'.

It's a question of price discrimination. In a broadcast free-to-view environment that is ad supported, you are required to seek as many viewers as possible. If your high desire viewers (the ones that will pay) are willing to pay 10x the rate of ad dollars, you only need to attract 10% of the audience. That might even be better than break even, first because your audience will likely be more loyal, and second with a shift toward quality the income from rebroadcast licensing may increase (you can sell DVDs or get Netflix/Amazon to pay you to stream BSG, but not The Jumping of Sharktopus (in 3D)).

It would be a high risk strategy in today's world. We are just beginning to test what people will pay for long tail content, and how it needs to be distributed.

I resist the implication that commercial software is, in general, well engineered. I'm not going to claim that the "many eyes" concept always, or even usually, lives up to it's billing; but in several high profile projects the FOSS system has resulted in some of the highest quality and most widely deployed applications and services in world. The market challenge that many projects have represented have motivated vendors to improve in way they claimed were impossible.

A very short list off the top of my head:

Apache
Mozilla
OpenSSH
Snort
the collective GNU utilities
Wireshark

I apologize for feeding the trolls.

Doesn't matter the OS is it's a browser targeted attack. based on the scant information in the article, I'm guessing this is a XSRF attack.

Based on the fact that HR has access to company accounts, the businesses targeted/affected are probably 1 person does all the management functions. Most banks I've seen use the same authentication for small businesses as personal accounts. If they have a PIN/keypad or a rotating authentication question, then a straight credential capture isn't easy. Unfortunately, while those measures are common, they aren't universal. This might also be a cross site request forgery (XSRF) attack, which would be prevented or at least mitigated by re-authenticating for each transaction. But again, if these are small businesses using the same essential security measures as personal accounts, transactional re-authentication isn't a common feature of those types of accounts.

Yeah, but if he can get twice the array for less than he can build a mirrored striped array for less than the price of striped array w/ parity of the same size. It depends on what exactly you're comparing, but if you're just looking at the redundancy features of ZFS building a better array and letting the RAID controller handle it is at best marginally worse than using the Sun solution. If on the other hand you want to use some of the other kung-fu of ZFS like the NFS integration, then the cost benefit calculus changes. The point is that, if your needs could be reduced to commodity hardware, Sun always lost badly on price.

I was gonna do the same thing, but you win. I for one welcome our gray bearded overlords.