Imagine what a cluster of 700 to 1,000 blade servers running the latest Intel Xeon CPU's can do now! =)
Actually, it would be a very crappily-performing cluster. Blade servers are designed with two major goals - CHEAP and SMALL. Blade servers are engineered for high availability applications (think webserver farm).
Just because you CAN do something doesn't mean it's the optimal solution. It amazes me when I see vendors selling blade server clusters.
(Disclaimer: I work as an engineer with a company with builds Linux based clusters for universities and labs)
How do coders who produce no code get work, while other programmers who can program circles around their colleagues are out of work?
At the risk of sounding like an arrogant ass (or at least, as arrogant as the post I am replying to), it is generally not your technical/coding abilities that get you the work - it is your ability to work well with a team, to communicate. Soft people skills are far, far more important than technical skills.
Why is this true? Because anyone who's worked as a professional programmer knows that your technical skills are constantly evolving - approaches to problems are constantly being refined. But if you cannot communicate effectively with other people, your technical ability doesn't matter. The key is to develop both sides of oneself - be an amazing programmer with amazing communication and people skills, and watch your career take off.
90% of every job I have ever had involved taking requirements from non-technical people and translating that into technical reality.
Re:Good for some, nightmare for others
on
Peek-a-Boo(ty)
·
· Score: 4, Insightful
No this makes it a security issue. Remember, all web browsers have remote expoits in them from time to time. Pr0n sites tend to be the first one's to exploit these holes (to get email addresses, install software, pop up ad pushing, etc.) Surfing pr0n sites at work is an almost for sure way to compromise the office network.
If you DON't want something to be public knowledge..... then try not putting it on a PUBLIC network. The Internet for example last time I checked was available to the public.
If you DON't want your house broken into...then try not living on a PUBLIC street. The world for example last time I checked was available to the public.
You are making a common mistake with your assertion that PGP will solve this issue.
All you have proven beyond a reasonable doubt is that the data was signed by someone with your private key. Nothing else. It is impossible to prove that YOU signed the data.
Not one to normally flame, but not using ssh in ANY environment because it's inconvienent is just plain stupid. If I ever had an admin working for me who believed this drivel, I'd fire him on the spot; However, I realize security isn't the easiest thing to learn, so I will explain here. Please indulge me for a moment.
Who can you trust in a datacenter environment (by datacenter, I am refering to a co-lo facility; for most companies, this is a datacenter)? Can you trust:
The $7/hour security guards that "patrol" the area?
The script kiddez who happen to land a job in the NOC (Where they study for their MCSE all day, no doubt)?
The often-incompetent datacenter "engineer" who can't seem to get the router to your cage configured correctly?
Now, let's take your arguments one at a time:
90% of servers have 6 or less users, who are admins or senior dba's/developers. Most connectivity is done through client/server connections to databases or other applications.
Even this statement reflects a poorly designed production area. No developer should have access to the production area. The only people to have access are the release engineer (and only the access he/she needs to get the code out) and the sysadmin.Period. Anything less is just asking for trouble.
Most end-user types cannot even directly connect to the server subnets. All connections go through a broker of some sort.
A "broker"? Do you mean a firewall? The packets have to get to the firewall somehow. I'm willing to bet you don't control every hop along the way as well. I'm also willing to bet that your firewall is allowing packets in and out somewhere.
Besides...we all know that firewalls never get compromised, right?
It's a pretty new network. Everything is switched. Hard to sniff on a switch.
It's trivial to sniff a switch, especially if it's a "pretty new" network. Managed switches all have traffic redirection which can be used to direct all traffic to a specific port. All commercial switches tend towards pathetic security. (There were Cisco advisories on Bugtraq only yesterday).
And even in an office environment, you have to deal with misconfigured clients, viruses (this is a very, very big reason to use ssh), malicious employees, socially-engineered quot&;good intentioned" people, etc., etc.
One snag. Most of us are male, and Mills College is for women only (at least, it was when I lived in Oakland, nearby where Mills is located).
Re:Backdoor challenge for you hackers...
on
NSA Linux In Depth
·
· Score: 5
I would think that the best way to hide an "Easter Egg" in openly available code would be not to attempt to hide it at all.
Just because the source is available, doesn't mean that people will examine it, nor does it mean that the people who do examine it are competent to do so. A good example of this is the OpenBSD team. Many people trust that OpenBSD has been audited. Can anyone here give one good reason why this auditing should be trusted, or what qualifies the OpenBSD team to audit the code? Even with the auditing, security compromises have been found in the audited OpenBSD code, as recently as late last year.
This is even more true the larger the system gets. For example, how many people in the world understand, line by line, exactly how the entire linux kernel operates? Even Linus himself doesn't; he delegates code he doesn't find interesting (or doesn't have the time or ability to work on) to other people.
Besides, there are far, far more effective ways to compromise information than a direct technology attack. Sideband attacks, social engineering, tempest readings, bribery, etc. I am of the opinion that the reason the NSA are not as up in arms as they used to be about encryption is that they have other means of obtaining that same information.
As a DBA, you shouldn't provide one that uses the database. I'm serious -- a production database has no business running SQL that hasn't been vetted by the DBA and run in a test database.
I agree, 100%. (And I am not a DBA; just a sysadmin that has been bitten by stupid management decisions in the past.)
What people often fail to understand is that a production database can (and often does) have different requirements than a business database, especially if the term "production" means that it drives a web-based application. If the data model is designed correctly, it is possible to have two entirely seperate databases, with secure data transfers between them at appropriate times (the word "appropriate" is defined on a case by case basis, but it is almost never in real time).
In the company I work for, we have two, entirely seperate databases. Data is transfered and loaded between the two on a nightly basis (NOT via ODBC; ODBC is very slow, very insecure, and experience has shown that it is buggy at times. The data is dumped, ssh'ed back and forth, and loaded via custom scripts. Perl is your friend;-) )
The production database uses replication to two seperate backup databases, and the business database is similiarly protected. Our replication scheme allows us to recover easily from data loss (which has never happened). The dba and our boss (who is a hacker first, and a manager second; a rareity these days) own the data.
This scheme allows the front end to be customized based on need. The business people are happy with their "point and click" interface, and the dba and engineering team are free to manipulate the data according to production application needs.
A solid data model can be implemented; all it takes is a great deal of foresight and solid software/database engineering practice.
As an interesting look into Geek history, is it possible to resurrect this old site, for archival purposes? I'd be interested in seeing what it looked like.
The trouble is is that VA is a hardware company at the end of the day. And their selling point was their Linux expertise.
And they couldn't even sell that. The company I work for (in Menlo Park, CA) wanted to contract with VA for some performance tweaking of a few large MySQL database servers running Linux. While the cost was about average for consulting rates, there was a four week lag time until the consultant could visit.
We didn't have the time. We figured it out ourselves.
But who were they selling to? The geek market is more likely to be making their own computers and installing their own distros. The large corporate market is likely to have their own staff that can deal with installing and configuring Linux.
This is somewhat true. We use Linux, FreeBSD and OpenBSD in our production environment. However, we buy systems from ASL Labs. The VA boxes were just too damn expensive, and the ASL machines were of higher quality hardware.
My perception of VA is that they are too concerned with Community "Look Good", and not concerned enough with running a profitable business. On one hand, they've done a great service to the Linux community. On the other, they are starting to fall apart because of it.
And so the merchant raises prices a little and you and I still end up paying for it.
Yes, but you also have the option of seeking out other merchants (for most products, that is).
I have been doing systems security for over ten years, and it is my professional opinion that it is IMPOSSIBLE to completely secure a machine (short of unplugging it totally and encasing it in concrete). Anyone who tells you any differently is either a)completely clueless when it comes to system security, or b) trying to sell you something.
The point is, is that compromises ARE going to happen. It is the job of the security engineer to make this more and more difficult. Constant vigilance is key here.
As long as there are systems on the Internet, there will be crackers. As long as there are crackers, there will be security compromises. And as long as there are security compromises, the cost of this will be passed on to the consumer.
This is simply an operational cost associated with online commerce. This is no different than the cost of shoplifting being passed on to the consumer in meatspace stores. It can be minimized greatly, but cannot be completely eliminated.
Actually, although security through obscurity is not a solution in and of itself, it is necessary. A properly designed security policy will not only protect against unauthorized traffic, it will have detection mechinisms in place to detect when crackers are "Rattling the Doornob" (i.e. NIDS, portsentry, multi-level firewalls, etc...)
By not publishing the security policy, you are forcing crackers to figure it out for themselves, which greatly increases the chance that they will trigger alarms set to catch them.
It is the merchant, not the bank nor any other CC company, that is liable for fraudulent purchases. This is where the money comes from. This is why it is so easy to challange a change on your credit card.
If the merchant can hold it together, the soon go out of business, via both bad press and lost profis on CC fraud.
I believe that the guys that work at the CC's probably have done quite a bit of work to make the unique transaction numbering issue a non-issue.
Very, very wrong. I've developed secure transaction systems that were audited by Visa. They don't have a clue. They have no concept of asymetric encryption (their specs only required things to be encrypted using 3DES, which is useless for storing credit cards). They had no cooncept of known-plaintext attacks on credit card numbers, and very little concept of systems security in general. They were more concerned with hiring policies than anything else.
As to why a symetric algorithm is useless in storing CC numbers, I will leave this as an exercise for the reader.
It is actually the vendor, not the credit card company, who is responsible, because the vendor has to eat the cost in a fraudulent purchase (this is federal law in the US). The CC companies have no vested interest in e-commerce security, other than via a marketing angle.
According to current (US) laws, the business has to keep a record of the cards, in the event of the charge being challanged, or fraud investigation. (At least, this is what was explained to me at work). If this is, in fact, the case, then the business has to hold onto the cc numbers (for 7 years, I believe, but I could be wrong.)
Heck, a simple socket that takes in a request and returns a success or failure isn't all THAT hard. neither is a quick java-based twofish implimentation (i'm assuming the cc were in cleartext).
If the cc exist in a database, then anyone who can query the database can get the cards, meaning if the system is compromised, all bets are off.
blowfish (or any other symetric algorithm, for that matter) is absolutely useless in this case, as the key (which is used for both encryption and decryption) must be stored on the machine hosting the database. If the machine is compromised, the cracker can easily get the key, making the crypto as useful as storing the cc numbers plaintext. The only way to do this properly is to use ElGamel or RSA, along with padding generated by a PRNG to prevent known-plaintext attacks.
Using an asymetric algorithm, if the database is compromised, you have sucessfully protected all previous cards (that is, if the private key does not exist on the system; all plaintext cc processing should occur offline). You do have to worry about future cards being snarfed, but you address this with other security measures, not crypto.
When dealing with credit cards, allways assume that the machine that the database is on CAN be cracked, then work hard to prevent this from happening.
Stallion Technologies offers embedded OpenBSD-based appliances, but there is little to no information regarding the building of such a device. It seems to me that OpenBSD would be great as a floppy-based firewall, and I can think of many other uses for a small-footprint/embedded version of OpenBSD. Does OpenBSD have any plans for providing consise documentation on the building of such a system? Barring this, does the OpenBSD project have any plans to document how the OS can be installed on a single floppy disk?
If this is about code written on company time, I can't see how it can be justified that the developer owns the IP.
This logically makes sence; however, there are a few instances that "company time" never ends. I, for one, am on call 24-hours a day, 7-days a week.
In my case, it can be argued that "all" my time is "company time". Fortunately, our CTO (my direct supervisor) is first and formost a hacker and an engineer; his policy with outside projects is do whatever I like, just let him know ahead of time.
I've even convinced him to release a number of things that I've developed at work that NEED to be peer reviewed (read: cryptographic protocols for the secure handling of credit cards).
His position is that outside projects enhance your abilities to do work for the company, and he whole-heartedly encourages it. I am very fortunate to be working for such a liberal-minded company.
I think stock options are still important, just not overwhelmingly so.
I work at a very rare company; the "Realistic Startup". We are actually working to become profitable within the next two years (and are well on track to do this). The options are important, but they are treated as extra money; the salary still must be competitive.
It is my opinion that the stock market is returning to a realistic market valuation of tech companies, that it is not "bottoming out". Given this, expect to cash in your stocks for a down payment on a house, rather than the millions that people assumed they could get, but were never promised.
There are several issues that make online banks easy targets:
1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure.
2. Sensitivity to bad press - online banking systems, when compromised, are often hushed up quickly, due to the fact that the publicity will scare clients away.
3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.
4. user passwords - people in general are dumb about choosing passwords. They often choose easy to guess passwords. It doesn't matter what security mechinisms you have in place; if a password can be compromised, the cracker has access.
5. poor sysadmin training - this is the plague of the industry. Most sysadmins don't know much of anything about security. The one's that do are rare.
Slashdot Mirror
Imagine what a cluster of 700 to 1,000 blade servers running the latest Intel Xeon CPU's can do now! =)
Actually, it would be a very crappily-performing cluster. Blade servers are designed with two major goals - CHEAP and SMALL. Blade servers are engineered for high availability applications (think webserver farm).
Just because you CAN do something doesn't mean it's the optimal solution. It amazes me when I see vendors selling blade server clusters.
(Disclaimer: I work as an engineer with a company with builds Linux based clusters for universities and labs)
At the risk of sounding like an arrogant ass (or at least, as arrogant as the post I am replying to), it is generally not your technical/coding abilities that get you the work - it is your ability to work well with a team, to communicate. Soft people skills are far, far more important than technical skills.
Why is this true? Because anyone who's worked as a professional programmer knows that your technical skills are constantly evolving - approaches to problems are constantly being refined. But if you cannot communicate effectively with other people, your technical ability doesn't matter. The key is to develop both sides of oneself - be an amazing programmer with amazing communication and people skills, and watch your career take off.
90% of every job I have ever had involved taking requirements from non-technical people and translating that into technical reality.
No this makes it a security issue. Remember, all web browsers have remote expoits in them from time to time. Pr0n sites tend to be the first one's to exploit these holes (to get email addresses, install software, pop up ad pushing, etc.) Surfing pr0n sites at work is an almost for sure way to compromise the office network.
Not even on your unopened box?
Jackass.
If you DON't want your house broken into...then try not living on a PUBLIC street. The world for example last time I checked was available to the public.
You sir, are quite the idiot.
You are making a common mistake with your assertion that PGP will solve this issue.
All you have proven beyond a reasonable doubt is that the data was signed by someone with your private key. Nothing else. It is impossible to prove that YOU signed the data.
Not one to normally flame, but not using ssh in ANY environment because it's inconvienent is just plain stupid. If I ever had an admin working for me who believed this drivel, I'd fire him on the spot; However, I realize security isn't the easiest thing to learn, so I will explain here. Please indulge me for a moment.
Who can you trust in a datacenter environment (by datacenter, I am refering to a co-lo facility; for most companies, this is a datacenter)? Can you trust:
The $7/hour security guards that "patrol" the area?
The script kiddez who happen to land a job in the NOC (Where they study for their MCSE all day, no doubt)?
The often-incompetent datacenter "engineer" who can't seem to get the router to your cage configured correctly?
Now, let's take your arguments one at a time:
90% of servers have 6 or less users, who are admins or senior dba's/developers. Most connectivity is done through client/server connections to databases or other applications.
Even this statement reflects a poorly designed production area. No developer should have access to the production area. The only people to have access are the release engineer (and only the access he/she needs to get the code out) and the sysadmin.Period. Anything less is just asking for trouble.
Most end-user types cannot even directly connect to the server subnets. All connections go through a broker of some sort.
A "broker"? Do you mean a firewall? The packets have to get to the firewall somehow. I'm willing to bet you don't control every hop along the way as well. I'm also willing to bet that your firewall is allowing packets in and out somewhere.
Besides...we all know that firewalls never get compromised, right?
It's a pretty new network. Everything is switched. Hard to sniff on a switch.
It's trivial to sniff a switch, especially if it's a "pretty new" network. Managed switches all have traffic redirection which can be used to direct all traffic to a specific port. All commercial switches tend towards pathetic security. (There were Cisco advisories on Bugtraq only yesterday).
And even in an office environment, you have to deal with misconfigured clients, viruses (this is a very, very big reason to use ssh), malicious employees, socially-engineered quot&;good intentioned" people, etc., etc.
Now tell me again why you don't use ssh.
One snag. Most of us are male, and Mills College is for women only (at least, it was when I lived in Oakland, nearby where Mills is located).
I would think that the best way to hide an "Easter Egg" in openly available code would be not to attempt to hide it at all.
Just because the source is available, doesn't mean that people will examine it, nor does it mean that the people who do examine it are competent to do so. A good example of this is the OpenBSD team. Many people trust that OpenBSD has been audited. Can anyone here give one good reason why this auditing should be trusted, or what qualifies the OpenBSD team to audit the code? Even with the auditing, security compromises have been found in the audited OpenBSD code, as recently as late last year.
This is even more true the larger the system gets. For example, how many people in the world understand, line by line, exactly how the entire linux kernel operates? Even Linus himself doesn't; he delegates code he doesn't find interesting (or doesn't have the time or ability to work on) to other people.
Besides, there are far, far more effective ways to compromise information than a direct technology attack. Sideband attacks, social engineering, tempest readings, bribery, etc. I am of the opinion that the reason the NSA are not as up in arms as they used to be about encryption is that they have other means of obtaining that same information.
I agree, 100%. (And I am not a DBA; just a sysadmin that has been bitten by stupid management decisions in the past.)
What people often fail to understand is that a production database can (and often does) have different requirements than a business database, especially if the term "production" means that it drives a web-based application. If the data model is designed correctly, it is possible to have two entirely seperate databases, with secure data transfers between them at appropriate times (the word "appropriate" is defined on a case by case basis, but it is almost never in real time).
In the company I work for, we have two, entirely seperate databases. Data is transfered and loaded between the two on a nightly basis (NOT via ODBC; ODBC is very slow, very insecure, and experience has shown that it is buggy at times. The data is dumped, ssh'ed back and forth, and loaded via custom scripts. Perl is your friend ;-) )
The production database uses replication to two seperate backup databases, and the business database is similiarly protected. Our replication scheme allows us to recover easily from data loss (which has never happened). The dba and our boss (who is a hacker first, and a manager second; a rareity these days) own the data.
This scheme allows the front end to be customized based on need. The business people are happy with their "point and click" interface, and the dba and engineering team are free to manipulate the data according to production application needs.
A solid data model can be implemented; all it takes is a great deal of foresight and solid software/database engineering practice.
As an interesting look into Geek history, is it possible to resurrect this old site, for archival purposes? I'd be interested in seeing what it looked like.
And they couldn't even sell that. The company I work for (in Menlo Park, CA) wanted to contract with VA for some performance tweaking of a few large MySQL database servers running Linux. While the cost was about average for consulting rates, there was a four week lag time until the consultant could visit.
We didn't have the time. We figured it out ourselves.
But who were they selling to? The geek market is more likely to be making their own computers and installing their own distros. The large corporate market is likely to have their own staff that can deal with installing and configuring Linux.
This is somewhat true. We use Linux, FreeBSD and OpenBSD in our production environment. However, we buy systems from ASL Labs. The VA boxes were just too damn expensive, and the ASL machines were of higher quality hardware.
My perception of VA is that they are too concerned with Community "Look Good", and not concerned enough with running a profitable business. On one hand, they've done a great service to the Linux community. On the other, they are starting to fall apart because of it.
Got the url for the BBS? I would LOVE to play TW again.
Got a url to it? This sounds like an interesting read.
Yes, but you also have the option of seeking out other merchants (for most products, that is).
I have been doing systems security for over ten years, and it is my professional opinion that it is IMPOSSIBLE to completely secure a machine (short of unplugging it totally and encasing it in concrete). Anyone who tells you any differently is either a)completely clueless when it comes to system security, or b) trying to sell you something.
The point is, is that compromises ARE going to happen. It is the job of the security engineer to make this more and more difficult. Constant vigilance is key here.
As long as there are systems on the Internet, there will be crackers. As long as there are crackers, there will be security compromises. And as long as there are security compromises, the cost of this will be passed on to the consumer.
This is simply an operational cost associated with online commerce. This is no different than the cost of shoplifting being passed on to the consumer in meatspace stores. It can be minimized greatly, but cannot be completely eliminated.
Actually, although security through obscurity is not a solution in and of itself, it is necessary. A properly designed security policy will not only protect against unauthorized traffic, it will have detection mechinisms in place to detect when crackers are "Rattling the Doornob" (i.e. NIDS, portsentry, multi-level firewalls, etc...)
By not publishing the security policy, you are forcing crackers to figure it out for themselves, which greatly increases the chance that they will trigger alarms set to catch them.
It is the merchant, not the bank nor any other CC company, that is liable for fraudulent purchases. This is where the money comes from. This is why it is so easy to challange a change on your credit card.
If the merchant can hold it together, the soon go out of business, via both bad press and lost profis on CC fraud.
Very, very wrong. I've developed secure transaction systems that were audited by Visa. They don't have a clue. They have no concept of asymetric encryption (their specs only required things to be encrypted using 3DES, which is useless for storing credit cards). They had no cooncept of known-plaintext attacks on credit card numbers, and very little concept of systems security in general. They were more concerned with hiring policies than anything else.
As to why a symetric algorithm is useless in storing CC numbers, I will leave this as an exercise for the reader.
It is actually the vendor, not the credit card company, who is responsible, because the vendor has to eat the cost in a fraudulent purchase (this is federal law in the US). The CC companies have no vested interest in e-commerce security, other than via a marketing angle.
According to current (US) laws, the business has to keep a record of the cards, in the event of the charge being challanged, or fraud investigation. (At least, this is what was explained to me at work). If this is, in fact, the case, then the business has to hold onto the cc numbers (for 7 years, I believe, but I could be wrong.)
If the cc exist in a database, then anyone who can query the database can get the cards, meaning if the system is compromised, all bets are off.
blowfish (or any other symetric algorithm, for that matter) is absolutely useless in this case, as the key (which is used for both encryption and decryption) must be stored on the machine hosting the database. If the machine is compromised, the cracker can easily get the key, making the crypto as useful as storing the cc numbers plaintext. The only way to do this properly is to use ElGamel or RSA, along with padding generated by a PRNG to prevent known-plaintext attacks.
Using an asymetric algorithm, if the database is compromised, you have sucessfully protected all previous cards (that is, if the private key does not exist on the system; all plaintext cc processing should occur offline). You do have to worry about future cards being snarfed, but you address this with other security measures, not crypto.
When dealing with credit cards, allways assume that the machine that the database is on CAN be cracked, then work hard to prevent this from happening.
use strict;
Stallion Technologies offers embedded OpenBSD-based appliances, but there is little to no information regarding the building of such a device. It seems to me that OpenBSD would be great as a floppy-based firewall, and I can think of many other uses for a small-footprint/embedded version of OpenBSD. Does OpenBSD have any plans for providing consise documentation on the building of such a system? Barring this, does the OpenBSD project have any plans to document how the OS can be installed on a single floppy disk?
This logically makes sence; however, there are a few instances that "company time" never ends. I, for one, am on call 24-hours a day, 7-days a week.
In my case, it can be argued that "all" my time is "company time". Fortunately, our CTO (my direct supervisor) is first and formost a hacker and an engineer; his policy with outside projects is do whatever I like, just let him know ahead of time.
I've even convinced him to release a number of things that I've developed at work that NEED to be peer reviewed (read: cryptographic protocols for the secure handling of credit cards).
His position is that outside projects enhance your abilities to do work for the company, and he whole-heartedly encourages it. I am very fortunate to be working for such a liberal-minded company.
I think stock options are still important, just not overwhelmingly so.
I work at a very rare company; the "Realistic Startup". We are actually working to become profitable within the next two years (and are well on track to do this). The options are important, but they are treated as extra money; the salary still must be competitive.
It is my opinion that the stock market is returning to a realistic market valuation of tech companies, that it is not "bottoming out". Given this, expect to cash in your stocks for a down payment on a house, rather than the millions that people assumed they could get, but were never promised.
There are several issues that make online banks easy targets:
1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure.
2. Sensitivity to bad press - online banking systems, when compromised, are often hushed up quickly, due to the fact that the publicity will scare clients away.
3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.
4. user passwords - people in general are dumb about choosing passwords. They often choose easy to guess passwords. It doesn't matter what security mechinisms you have in place; if a password can be compromised, the cracker has access.
5. poor sysadmin training - this is the plague of the industry. Most sysadmins don't know much of anything about security. The one's that do are rare.