Quitting cigarettes is quitting cigarettes. What you're trying to say is that they still have a dependency to nicotine, which is true, but a completely different thing. Nicotine is roughly as harmful as caffeine. Smoking kills.
Nowadays, and even back then I suppose, these were called penetration testing and incident response plan/business continuity plan exercises. These are a standard practice that should be in the year clock of every security minded organization.
Doing those things will make you popular. The fact that people who are open, not selfish and overly dramatic may have more friends probably has nothing to do with this.
I feel it's ignorant and arrogant to assume that none of our actions have consequences. The latest studies actually suggest that for the past 10000 years we've been moving towards a new ice age, and there's compelling evidence that the reasons why it has stalled and later reversed were agriculture and industrialization.
1. Apply the Principle Of Least Privilege (http://en.wikipedia.org/wiki/Principle_of_least_privilege). Make sure all users have basic user accounts, not admin rights. Most malware runs in the context of the logged on user, if the user account doesn't have access to modify system files or install services, neither will the malware.
2. Make sure you have working patch management. Install all security updates asap.
3. Have up-to-date antivirus/antimalware software. Yes, number 3. This is less important the other 2, but still paramount.
Security is not a state nor a technology, it's a process, and you'll never reach 100% protection. The above, however, should be (properly implemented) enough for most organizations. Awareness training, NAC/NAP, IDS/IPS, proxies and application layer firewalls etc are all helpful, but those 3 are IMO the essential ones.
It is true that much of what has been revealed could be explained as the usual cut and thrust of the peer review process, exacerbated by the extraordinary pressure the scientists were facing from a denial industry determined to crush them. One of the most damaging emails was sent by the head of the climatic research unit, Phil Jones. He wrote "I can't see either of these papers being in the next IPCC report. Kevin and I will keep them out somehow - even if we have to redefine what the peer-review literature is!"
One of these papers which was published in the journal Climate Research turned out to be so badly flawed that the scandal resulted in the resignation of the editor-in-chief. Jones knew that any incorrect papers by sceptical scientists would be picked up and amplified by climate change deniers funded by the fossil fuel industry, who often – as I documented in my book Heat – use all sorts of dirty tricks to advance their cause.
Taken out of context some of the emails may look bad, but all he is saying is that they want to stop publications that have been proven faulty from appearing in a report that's used pretty much as a definitive guideline for how to deal with climate change. They're having a hard time convincing world leaders to act as it is, they don't need any additional distractions. Unethical/unprofessional? Somewhat. Condemning or making anything related to their research questionable? Hardly. I bet if granted access to anyone's private emails over a number of years, _any_ kind of conspiracy or federal offense could be "proven".
"Since Motorola Inc launched a patent attack on Nokia in 1989, the Finnish firm has built one of the mobile industry's widest patent portfolios. Only Ericsson and Qualcomm Inc have comparable portfolios."
Nokia has something like the 5th or 6th largest patent portfolio in telecom equipment and the largest in the mobile industry in the world. I somehow don't think Nokia is the one that should be worried.
In what regard is CERN's LHC software critical to you? Your neighbor's wifi router can be critical to your neighbor, and it most likely is to its manufacturer. I'd be hesitant to call any piece of software more complex than "hello world" categorically non-critical. If it's made publicly available or sold, the maker is^Z should be responsible that it doesn't eat anyone's babies, unless of course that is its purpose.
Except the FOI request was from other scientist in the same field. It is one thing to be annoyed by an FOI request by someone outside the field but this was not the case. It is quite disturbing when you have scientist "20+ years" in the filed refusing to share data because???
No, they weren't. All 58 of them during a _5 day span_ were from the same person, Stephen McIntyre. He is the former director of oil and mining companies Northwest Explorations and CGX Energy, who now runs Climate Audit, an anti climate change blog. He is a petroleum scientist, not a climatologist. One reason the data was not disclosed is because it's owned by 150ish meteorological institus around the world, not by CRU.
Yes, what you say is partly true if we are looking at a static piece of code that is never changed or updated (if it's not static, changes or new functionality can always introduce new vulnerabilities). How relevant that is to anything in the real world, not very in my opinion. And only partly, because completely new types of attacks and attack vectors are discovered constantly.
Who said that the security process is _only_ fixing holes after you've been exploited?
If your process is only reactive, maybe you should look into some preventive and detective controls, THEN start evolving it together with changing threats, as the parent poster suggested.
To be PCI compliant every box that stores or *transmits* card data is in scope, including any routers/switches/firewalls that data hits.
This is actually not the whole story. This is what the latest version of the DSS states:
"The PCI DSS security requirements apply to all system components. âoeSystem componentsâ are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (Internet) applications."
The traditional interpretation of that is that every system that transmits, stores or processes cardholder data, and every system directly connected to any of them, are automatically included in the cardholder data environment (CDE). The connected systems part is often forgotten, but it easily includes all backup/management/backend/support systems and workstations in the network. A system is directly connected, if it can "negatively affect the security of the cardholder data", and it's the merchant's responsibility to prove that it cannot. This can be done by for example system documentation or penetration testing.
Any application that allows card data to be captured (even if not stored) should go through PA-DSS (payment application) compliance testing.
PA-DSS only concerns commercially sold software, not software developed in-house or other custom software. The only relevant part about PA-DSS to merchants is that they should make sure that the commercial payment solutions etc. they purchase are PA-DSS certified.
I see. Well, if you were to ask the PCI Council about this, they would most likely answer "ask the QSA".:) If your QSA decided to be strict about the issue, other than changing your auditor there's not much you can do, installing the AV is probably the path of least resistance.
Sir, if you want to write a better security standard that can easily be applied to every operating system from embedded payment terminals to Windows NT3 to AIX, every environment from a cloud-hosted webshop to ones consisting of hundreds of datacenters or a chain of tens of thousands of stores around the planet, and be easily applied to every piece of commercial or custom software on the planet, yet still include specific settings for certain versions of Apache and Joomla, go right ahead.
For example, PCI argues that credit card information should never be stored on a server.
"3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
In other words, it does not say that. In fact, the whole requirement 3 deals with how to secure stored cardholder data.
PCI DSS requirement:
5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.
Testing procedure:
5.1.1 For a sample of system components, verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits).
If your QSA required an AV in an all Linux environment, I would ask him to explain what he based his decision on. The standard requires AV software "on all systems commonly affected by malicious software", in my opinion Linux is not one of them. And yes, I'm a QSA.
This might come as a surprise, but PCI does not have 12 requirements, it has (as of v1.2) 254 specific requirements. What the 12 categories that you're responding to state have very little to do with the actual standard.
"As for PCI level 2 compliance, that requires external scanning via a 3rd party, PCI-approved vendor. It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3, but you cannot achieve level 1 compliance. And you have to provide the appropriate encryption mechanisms and key management processes. "
There seems to be a dangerous misunderstanding about PCI validation requirements in the reply from Amazon. There's no such thing as "level x compliance", the levels refer to merchant levels set by the acquirer. The merchant level is determined by the volume of credit card transactions for a single card brand (e.g. Visa). The actual security requirements for all 4 merchant levels are EXACTLY the same, the only difference is how the compliance has to be validated. Level 1 merchants are required to perform an on-site audit by a QSAP annually, whereas the other levels only require filling a self-assessment questionnaire (SAQ) once a year. Quarterly vulnerability scans by an ASV are required for all levels except 4, where they are optional.
As often is the case with PCI, it depends. Under normal circumstances, in an environment consisting solely of Linux servers, an AV product is not usually required. However, while the linux servers themselves might be "safe" from malware, they can just as well be used to spread them through for example email, file shares etc. If the environment has even one Windows server in the cardholder data environment (CDE), an AV product that catches windows malware would be required on the Linux servers.
I concur. As in, what is "skill" in for example chess or any other "skill-based" game, if not the knowledge of the game's mechanics? ESP? Force?
Main Entry: skill Function: noun Etymology: Middle English skil, from Old Norse, distinction, knowledge; probably akin to Old English scylian to separate, sciell shell â" more at shell Date: 13th century
1 (obsolete): cause, reason 2 a: the ability to use one's knowledge effectively and readily in execution or performance b: dexterity or coordination especially in the execution of learned physical tasks 3: a learned power of doing something competently : a developed aptitude or ability
A false dichotomy is an old debating trick where one party says, "well, you oppose X, and therefore you must be for Y!" It's called "false" because the world really doesn't work that way. There are many different options.
Woah. All this time I've though I can only be strictly for or against abortion, a religion, a political party or movement, an operating system, a war, a football team (the football that's played with not really a ball with your hands) and a number of other issues. This opens up truly fascinating possibilities!
Slashdot Mirror
Quitting cigarettes is quitting cigarettes. What you're trying to say is that they still have a dependency to nicotine, which is true, but a completely different thing. Nicotine is roughly as harmful as caffeine. Smoking kills.
Nowadays, and even back then I suppose, these were called penetration testing and incident response plan/business continuity plan exercises. These are a standard practice that should be in the year clock of every security minded organization.
This is easy, obviously the language should be english spoken really slowly and loudly, everyone understands that, right?
Doing those things will make you popular. The fact that people who are open, not selfish and overly dramatic may have more friends probably has nothing to do with this.
I feel it's ignorant and arrogant to assume that none of our actions have consequences. The latest studies actually suggest that for the past 10000 years we've been moving towards a new ice age, and there's compelling evidence that the reasons why it has stalled and later reversed were agriculture and industrialization.
1. Apply the Principle Of Least Privilege (http://en.wikipedia.org/wiki/Principle_of_least_privilege). Make sure all users have basic user accounts, not admin rights. Most malware runs in the context of the logged on user, if the user account doesn't have access to modify system files or install services, neither will the malware.
2. Make sure you have working patch management. Install all security updates asap.
3. Have up-to-date antivirus/antimalware software. Yes, number 3. This is less important the other 2, but still paramount.
Security is not a state nor a technology, it's a process, and you'll never reach 100% protection. The above, however, should be (properly implemented) enough for most organizations. Awareness training, NAC/NAP, IDS/IPS, proxies and application layer firewalls etc are all helpful, but those 3 are IMO the essential ones.
From George Monbiot's response to the CRU leak:
It is true that much of what has been revealed could be explained as the usual cut and thrust of the peer review process, exacerbated by the extraordinary pressure the scientists were facing from a denial industry determined to crush them. One of the most damaging emails was sent by the head of the climatic research unit, Phil Jones. He wrote "I can't see either of these papers being in the next IPCC report. Kevin and I will keep them out somehow - even if we have to redefine what the peer-review literature is!"
One of these papers which was published in the journal Climate Research turned out to be so badly flawed that the scandal resulted in the resignation of the editor-in-chief. Jones knew that any incorrect papers by sceptical scientists would be picked up and amplified by climate change deniers funded by the fossil fuel industry, who often – as I documented in my book Heat – use all sorts of dirty tricks to advance their cause.
Taken out of context some of the emails may look bad, but all he is saying is that they want to stop publications that have been proven faulty from appearing in a report that's used pretty much as a definitive guideline for how to deal with climate change. They're having a hard time convincing world leaders to act as it is, they don't need any additional distractions. Unethical/unprofessional? Somewhat. Condemning or making anything related to their research questionable? Hardly. I bet if granted access to anyone's private emails over a number of years, _any_ kind of conspiracy or federal offense could be "proven".
http://www.reuters.com/article/idUSTRE5BS2UO20091229
"Since Motorola Inc launched a patent attack on Nokia in 1989, the Finnish firm has built one of the mobile industry's widest patent portfolios. Only Ericsson and Qualcomm Inc have comparable portfolios."
Nokia has something like the 5th or 6th largest patent portfolio in telecom equipment and the largest in the mobile industry in the world. I somehow don't think Nokia is the one that should be worried.
Do you work for TSA by any chance?
In what regard is CERN's LHC software critical to you? Your neighbor's wifi router can be critical to your neighbor, and it most likely is to its manufacturer. I'd be hesitant to call any piece of software more complex than "hello world" categorically non-critical. If it's made publicly available or sold, the maker is^Z should be responsible that it doesn't eat anyone's babies, unless of course that is its purpose.
Except the FOI request was from other scientist in the same field. It is one thing to be annoyed by an FOI request by someone outside the field but this was not the case. It is quite disturbing when you have scientist "20+ years" in the filed refusing to share data because???
No, they weren't. All 58 of them during a _5 day span_ were from the same person, Stephen McIntyre. He is the former director of oil and mining companies Northwest Explorations and CGX Energy, who now runs Climate Audit, an anti climate change blog. He is a petroleum scientist, not a climatologist. One reason the data was not disclosed is because it's owned by 150ish meteorological institus around the world, not by CRU.
I think this sums it up fairly well:
http://www.rifters.com/crawl/?p=886
Yes, what you say is partly true if we are looking at a static piece of code that is never changed or updated (if it's not static, changes or new functionality can always introduce new vulnerabilities). How relevant that is to anything in the real world, not very in my opinion. And only partly, because completely new types of attacks and attack vectors are discovered constantly.
Who said that the security process is _only_ fixing holes after you've been exploited? If your process is only reactive, maybe you should look into some preventive and detective controls, THEN start evolving it together with changing threats, as the parent poster suggested.
To be PCI compliant every box that stores or *transmits* card data is in scope, including any routers/switches/firewalls that data hits.
This is actually not the whole story. This is what the latest version of the DSS states:
"The PCI DSS security requirements apply to all system components. âoeSystem componentsâ are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (Internet) applications."
The traditional interpretation of that is that every system that transmits, stores or processes cardholder data, and every system directly connected to any of them, are automatically included in the cardholder data environment (CDE). The connected systems part is often forgotten, but it easily includes all backup/management/backend/support systems and workstations in the network. A system is directly connected, if it can "negatively affect the security of the cardholder data", and it's the merchant's responsibility to prove that it cannot. This can be done by for example system documentation or penetration testing.
Any application that allows card data to be captured (even if not stored) should go through PA-DSS (payment application) compliance testing.
PA-DSS only concerns commercially sold software, not software developed in-house or other custom software. The only relevant part about PA-DSS to merchants is that they should make sure that the commercial payment solutions etc. they purchase are PA-DSS certified.
I see. Well, if you were to ask the PCI Council about this, they would most likely answer "ask the QSA". :) If your QSA decided to be strict about the issue, other than changing your auditor there's not much you can do, installing the AV is probably the path of least resistance.
Btw the term is Compensating Controls.
Sir, if you want to write a better security standard that can easily be applied to every operating system from embedded payment terminals to Windows NT3 to AIX, every environment from a cloud-hosted webshop to ones consisting of hundreds of datacenters or a chain of tens of thousands of stores around the planet, and be easily applied to every piece of commercial or custom software on the planet, yet still include specific settings for certain versions of Apache and Joomla, go right ahead.
For example, PCI argues that credit card information should never be stored on a server.
"3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
In other words, it does not say that. In fact, the whole requirement 3 deals with how to secure stored cardholder data.
PCI DSS requirement: 5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.
Testing procedure: 5.1.1 For a sample of system components, verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits).
If your QSA required an AV in an all Linux environment, I would ask him to explain what he based his decision on. The standard requires AV software "on all systems commonly affected by malicious software", in my opinion Linux is not one of them. And yes, I'm a QSA.
This might come as a surprise, but PCI does not have 12 requirements, it has (as of v1.2) 254 specific requirements. What the 12 categories that you're responding to state have very little to do with the actual standard.
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
The sad part is, however, that your portrayal of the compliance state of the systems in use is fairly accurate.
"As for PCI level 2 compliance, that requires external scanning via a 3rd party, PCI-approved vendor. It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3, but you cannot achieve level 1 compliance. And you have to provide the appropriate encryption mechanisms and key management processes. "
There seems to be a dangerous misunderstanding about PCI validation requirements in the reply from Amazon. There's no such thing as "level x compliance", the levels refer to merchant levels set by the acquirer. The merchant level is determined by the volume of credit card transactions for a single card brand (e.g. Visa). The actual security requirements for all 4 merchant levels are EXACTLY the same, the only difference is how the compliance has to be validated. Level 1 merchants are required to perform an on-site audit by a QSAP annually, whereas the other levels only require filling a self-assessment questionnaire (SAQ) once a year. Quarterly vulnerability scans by an ASV are required for all levels except 4, where they are optional.
As often is the case with PCI, it depends. Under normal circumstances, in an environment consisting solely of Linux servers, an AV product is not usually required. However, while the linux servers themselves might be "safe" from malware, they can just as well be used to spread them through for example email, file shares etc. If the environment has even one Windows server in the cardholder data environment (CDE), an AV product that catches windows malware would be required on the Linux servers.
...where at least I know I'm free...
I concur. As in, what is "skill" in for example chess or any other "skill-based" game, if not the knowledge of the game's mechanics? ESP? Force?
Main Entry: skill
Function: noun
Etymology: Middle English skil, from Old Norse, distinction, knowledge; probably akin to Old English scylian to separate, sciell shell â" more at shell
Date: 13th century
1 (obsolete): cause, reason
2 a: the ability to use one's knowledge effectively and readily in execution or performance b: dexterity or coordination especially in the execution of learned physical tasks
3: a learned power of doing something competently : a developed aptitude or ability
A false dichotomy is an old debating trick where one party says, "well, you oppose X, and therefore you must be for Y!" It's called "false" because the world really doesn't work that way. There are many different options.
Woah. All this time I've though I can only be strictly for or against abortion, a religion, a political party or movement, an operating system, a war, a football team (the football that's played with not really a ball with your hands) and a number of other issues. This opens up truly fascinating possibilities!