చాలా సందర్భాలలో చట్టంలోని నిబంధనలను అర్థం చేసుకోవడం, దాన్ని గ్రహించడం విసుగుతో కూడుకున్నదే కాక కొంచెం కష్టమైన పని కూడా. ఎక్కువ శాతం సాఫ్ట్ వేర్ డెవలపర్లు చట్టపరమైన విషయాలను అర్థం చేసుకొనే నేపథ్యాన్ని కలిగి వుండరు. ఇలాగే చట్టాన్ని, నిబంధనలను తయారు చేసే వారికి సాఫ్ట్ వేర్ గురించి ఓనమాలు తెలియకపోవడమూ సహజమే. ఈ రెండు గ్రూపలు బ్రతుకు దెరువు కోసం ఎంచుకున్న విభిన్న మార్గాలు ఈ రెండూ. వేరే వేరే దారుల్లో, వేరు వేరు మైండ్ సెట్ తో ప్రయాణించే వాళ్ళు కాబట్టి ఒకరి మాటలు మరొకరు అర్థం చేసుకొనే శాతం కూడా తక్కువే. నిబంధనల్లో వుపయోగించిన భాషను, వాక్యాలను సాఫ్ట్ వేర్ Requirement document లోకి one to one map చేయడమూ సాధ్యము కాని పని కూడా. దీనికి తోడు పెరిగిపోతున్న Regulations, ఈ నిబంధనలు కూడా ప్రతి రాష్ట్రానికి మారిపోతుండడమే కాకుండా, దేశానికి వేరే నిబంధనలు వుండడంతో మొత్తంగా సాఫ్ట్ వేర్ డెవలపర్ల పని గొడ్డు చాకిరితో పాటు, పరమ బోరుగా తయారయ్యింది.
అమెరికాలోని కొన్ని నిబంధనలు
HIPAA : Confidentiality, integrity, and availability of health care information.
PCI : Confidentiality of credit card information stored and used by merchants.
GLBA : Confidentiality and integrity of personal financial information stored by financial institutions.
Sarbanes-Oxley : Privacy and integrity of financial data in publicly traded corporations.
SB 1386 : Confidentiality of customers personal information stored by any organization that does business in the state of California
BASEL II :Confidentiality and integrity of personal financial information stored by financial institutions. Availability of financial systems. Integrity of financial information as it is transmitted. Authentication and integrity of financial transactions.
ఒకవేళ మీరు చేస్తున్న అప్లికేషన్ పై తరగతులలో ఎందులో వున్నా, ఈ నిబంధనల వుచ్చులో గిల గిల కొట్టుకొంటున్నా సందేహ పడనవసరం లేదు. ఒకవేళ ఇప్పుడు కాకున్నా రాబోయే రోజుల్లో నైనా తప్పక ఏదో ఒక సందర్భంలో వీటి గురించి తెలుసుకోవడం అవసరం కూడా. సాఫ్ట్వేర్ వినియోగదారులకు కూడా ఇది ఓ క్లిష్టమైన సమశ్యే. ఒకవేళ వీటిని విస్మరిస్తే వ్యాపారాన్నే మూసేసుకోవాలి మరి. ఇక్కడ ఒక ఆనంద దాయకమైన విషయం ఏంటంటే ఇందులో చాలా వరకు ఈ నిబంధనలు ఆపరేషన్స్ వాళ్ళకు వర్తించేవి. అలాగే వ్యాపారసంస్థలకూ !. డెవలపర్ గా కొన్ని నిబంధనలను మాత్రం కోడ్ రూపంలో ఎక్కిస్తే సరిపోతుంది. అదే మీరే వ్యాపార సంస్థ అధిపతి అయితే మాత్రం నిబంధనలన్నీ మీకు వర్తిస్తాయి.
ఈ టపాలో ఒక్క PCI-DSS ( Payment Card Industry Data Security Standard) గురించి మరికొంత సమాచారమిక్కడ. ఇది ముఖ్యంగా Credit card transactions నిబంధనలకు వర్తిస్తుంది. దీన్ని ఈ ప్లాస్టిక్ కంపెనీ ( Credit card network organizations) వాళ్ళు, bank వాళ్ళతో కలిసి వ్యాపారసంస్థల ద్వారా మనలని దోచుకోవడానికి డబ్బులు లేకుండా నే మీకవసరమైన వస్తువులు కొనుక్కోమని తాయిలాలు చూపిస్తూ ప్రారంభమైన వినూత్న పథకం. దీని నిబంధనలను CC రంగంలో అతిపెద్దవైన నాలుగు నెట్వర్క్ వాళ్ళు ( VISA, AMEX, MASTER,DISCOVER) కలిసి తయారు చేశారు. ఈ నిబంధనలన్నీ తప్పకుండా ప్రతి వ్యాపారస్థునితో పాటు, Credit card processing service providers కూడా తప్పక పాటించవలసిన నియమాలను తెలుపుతుంది. Credit card ఏ రూపంగా నైనా వాడవచ్చు కాక , అంటే వ్యక్తిగతంగా వ్యాపారస్థుని దగ్గర మిషన్ లో గీకడం దగ్గరనుంచి, ఫోను, ఇంటర్ నెట్, మొబైల్ ద్వారా, ఏ రూపంగా వాడినా సరే ఈ నిబంధనలు తప్పక పాటించాలి.
ప్రతి వ్యాపారస్థుడూ కూడా ఈ సర్టిఫికేట్ తప్పకుండా పొంది వుండాలి. వ్యాపారాన్ని నాలుగు తరగతులుగా విభజించి ( 1, 2, 3, or 4.) మీకు ఏఏ నిబంధనలు వర్తిస్తాయో చెప్తారు. ఎన్ని ఎక్కువ transactions జరుగుతుంటే PCI ప్రమాణాలు ముప్పు అంత ఎక్కువగా మీపై వున్నదన్నమాటే !
గోప్యత మరియు ప్రామాణీకరణ: ఈ PCI ప్రధాన ఉద్దేశ్యం వినియోగదారుల క్రెడిట్ కార్డు సమాచారం రక్షించడం. కానీ దురదృష్టవశాత్తు, డెవలపర్లు అప్లికేషన్ ను డెవెలప్ చెయ్యగలరే కానీ, క్రెడిట్ కార్డ్ హ్యాండ్లింగ్ ప్రక్రియ మీద పూర్తి నియంత్రణ వుండదు. క్రెడిట్ కార్డ్ సమాచారం తరచుగా వినియోగదారులకు తెలియని మధ్యవర్తులు గా వ్యవహరించే ( Merchants, Pay ment gateway, Payment processors, Credicard network, Bank ) ఎజెంట్ల ద్వారా వెళుతుంది. ఇక్కడ ఎక్కడ చిల్లు పడ్డా, బ్యాంక్ బాలెన్స్ కి బొక్కే!!. దీన్ని నియంత్రించడానికి ఏర్పరచిన రూల్స్ అవి.
Logging and Auditing: ఇది ఈ నిబంధనల్లో రెండవ ముఖ్యమైనది. ప్రతి లావాదేవీతో పాటు, వినియోగదారునికి సంబంధించిన ప్రతి అంశాన్నీ తప్పక log చెయ్యాలి.
హ్మ్ తెలుగులో వ్రాయడం అంత వీజీ కాదు కాబట్టి...
Logging and Auditing main intention is, in case fraud, merchant must proactively identify fraud and protect consumer's interest. Logging and Auditing is very important if you are developing any PCI compilence software.
While developing PCI compilence software following are few guide lines from MSDN
1) Protect cardholder data : Do not rely on custom or untrusted encryption routines. Use platform provided cryptographic APIs, because they have been thoroughly inspected and tested rigorously. Use an asymmetric algorithm such as RSA when it is not possible to safely share a secret between the party encrypting and the party decrypting the data. A symmetric algorithm such as AES can be used when it is possible to share a secret before the encrypted communication begins. It is important to choose an appropriately sized key so that the encryption is not easily broken. When using RSA, choose a 2048 bit key. When using AES, choose a 128 bit key. These key sizes give some room for growth but will eventually need to be replaced with larger keys as computing power increases.
2) Integrity: Hashing should be used to store confidential information, such as passwords, that may need to be validated but won't need to be retrieved in whole form. Integrity checks should be used to ensure that confidential data has not been tampered with. Use SHA1 when hashing and use HMAC-SHA1 when conducting integrity checks. It is important, however, to keep in mind that the hashing algorithm may need to change over time as computing power increases and previously strong algorithms fall out of favor.
3) Availability: Data availability includes the use of storage solutions that are reliable such as RAID and offsite backups. It is also important to make sure that these backups can be secured. For developers, this means that applications should be designed so that key information is archiveable and recoverable even if there is a terminal failure in the system. Where encryption is used, this means having a mechanism to export keys so that data can be recovered if the system is destroyed. Another important consideration for developers is secure failover of the system. This means that error handling code must not weaken the security of the system and, where appropriate, it should support clustering and safe failover. Error-handling in particular is a common point of failure. When designing and implementing your error handling mechanisms, keep the following guidelines in mind:
Create a consistent error-handling architecture and use it throughout your application.
Do not reveal sensitive information to the user, or the caller, when your application fails.
Catch exceptions or error return values on every API call that can provide such information.
4) Auditing and Logging: Carefully avoid logging any sensitive data — there is no guarantee that access to the logs and access to the sensitive data will require the same privileges. If you are involved in system deployment, ensure that the event log is only exposed to administrators. Even if no private information is logged, the information contained in the log can be used to further attacks on the system. If you are using ASP.NET 2.0 to write your application, you can use the new health-monitoring feature to instrument your application and capture relevant information. For other .NET applications on the Windows platform, you can use the System.Diagnostics.EventLog class. For unmanaged applications you can use the ReportEvent API within the Windows Platform SDK. A common attack that malicious users may employ in order to tamper with logs is to overwhelm the logging mechanism with millions of log events that either cause important information to be lost or obscure the important data. Guard against this by throttling your logging. You may also consider logging to a separate protected system to guard against attacks by unauthorized users. Event logs should contain enough information to make it possible to reconstruct system activity up to any point of failure so that the error can be quickly resolved and fixed.
5) Authentication: When setting up authentication systems, be sure to enforce strong passwords. At a minimum, require passwords to be seven characters long and contain at least one non-alphanumeric character. Do not enable or provision for "guest" accounts or other means of access that do not correlate a specific identity with the accounts or resources being utilized. When storing passwords, be sure to use sufficiently strong encryption to protect the credentials from attackers that might gain access to them. Enforce password policies that will expire credentials on a semi-regular basis. Make sure that inactivity causes automatic log-off when a user is idle for a specific period of time. If you are writing an ASP.NET application you can set the sliding Expiration configuration setting to true in order to expire user sessions in a set amount of time.
ఏమిటో ఈ కార్డులు ఇవ్వటమేమిటో, దాన్ని రక్షించడానికి ఇంత డిఫెన్సివ్ system ఏమిటో !!.
