If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(Slashdot)   Creator of the Linux kernel switches from XFCE to KDE because A) more configurability options B) less resource reliant or C) wobbly windows eye candy   (linux.slashdot.org) divider line 103
    More: Obvious, linux, Xfce, kde, gnomes, IIRC, Linus Torvalds, Mark Hurd, switches  
•       •       •

4545 clicks; posted to Geek » on 13 Nov 2012 at 7:26 PM (2 years ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



103 Comments   (+0 »)
   
View Voting Results: Smartest and Funniest

Archived thread

First | « | 1 | 2 | 3 | » | Last | Show all
 
2012-11-15 01:21:36 AM  

AustinFakir: I worked at a company that had the highest level of PCI compliance, and developers were free to run whatever we wanted on our machines. PCI compliance has very little to do with that. For PCI compliance, the potential hostile force controlling a developer's computer is the developer himself. The PCI guys focused on network security, network topology, development practices, etc. Some of our developers were interviewed during the certification process, but they were only asked about how security worked for specific applications and about general security-related programming practices.

The way IT handled desktop administration was handled was, if you can't make your computer work, IT will be happy to wipe it and reinstall Windows.


PCI compliance depends on the scope of your business. In our case, the company not only didn't outsource CC payments, they wrote their own transaction handling code -- that put the *entire* network and developers workstations under compliance.

Not my choice as that pre-dated my arrival but the compliance scope because of that made it a nightmare.

Yeah, in other scenarios, I agree for the most part the developers are on their own -- except that they still had to comply with data handling standards and that meant FDE. Try to find a solution that works across all linux variants *and* offers central automated recovery key escrow.

Is it a pain? Yes. It's is solvable? Yes. Cheaply (that means factoring in IT salaries to support it)? No.
 
2012-11-15 04:51:25 AM  

lohphat: AustinFakir: I worked at a company that had the highest level of PCI compliance, and developers were free to run whatever we wanted on our machines. PCI compliance has very little to do with that. For PCI compliance, the potential hostile force controlling a developer's computer is the developer himself. The PCI guys focused on network security, network topology, development practices, etc. Some of our developers were interviewed during the certification process, but they were only asked about how security worked for specific applications and about general security-related programming practices.

The way IT handled desktop administration was handled was, if you can't make your computer work, IT will be happy to wipe it and reinstall Windows.

PCI compliance depends on the scope of your business. In our case, the company not only didn't outsource CC payments, they wrote their own transaction handling code -- that put the *entire* network and developers workstations under compliance.

Not my choice as that pre-dated my arrival but the compliance scope because of that made it a nightmare.

Yeah, in other scenarios, I agree for the most part the developers are on their own -- except that they still had to comply with data handling standards and that meant FDE. Try to find a solution that works across all linux variants *and* offers central automated recovery key escrow.

Is it a pain? Yes. It's is solvable? Yes. Cheaply (that means factoring in IT salaries to support it)? No.


That's just weird. Our developers never had access to cardholder information. We were under very strict orders that if we ever saw any card numbers or cardholder information anywhere, in a log file or a support request or an email, or even if we heard such information on the phone, we would immediately contact a superior so the incident could be documented. We could run rampant outside the CHE (developers had login access on most of the production machines and many could sudo; most had at least read access to production databases) but the CHE was like the Forbidden City. Only high-level ops guys could access the CHE, and they had to painstakingly expurgate any information they passed on to us from those machines. We weren't allowed to see core dumps, for example, and only hand-vetted snippets from log files. To me it sounds crazy for developers to have access to cardholder data at all, much less to expect them to store it securely.

We did use one or more third-party processing services, though I doubt it made PCI compliance any easier, since we had to transmit and store complete payment information, including card numbers.
 
2012-11-15 01:14:27 PM  

AustinFakir: We did use one or more third-party processing services, though I doubt it made PCI compliance any easier, since we had to transmit and store complete payment information, including card numbers.


At another place I worked we were able to pull the payment portal traffic into one cabinet in the datacenter (where the webservers handling that content to the outsourced CC handler were) and PCI payment compliance ended there. Yeah we hand to demonstrate best practices yadda-yadda but the nasty stuff was well contained.

Not at the other place though -- developers could login into db servers where CC info was. Yeah. Madness. I know. And that made client computing security a nightmare.
 
Displayed 3 of 103 comments

First | « | 1 | 2 | 3 | » | Last | Show all

View Voting Results: Smartest and Funniest


This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »
On Twitter





In Other Media


  1. Links are submitted by members of the Fark community.

  2. When community members submit a link, they also write a custom headline for the story.

  3. Other Farkers comment on the links. This is the number of comments. Click here to read them.

  4. Click here to submit a link.

Report