Microsoft Support Scam

The phone number and web address keep getting taken down and new ones keep popping up. But there is a Microsoft support scam going on requesting personal information. Do Not give them any information.  Here are a couple screen shots from a few different people encountering this scam. Vigilante hackers have done some research and identified a group based in India that also operates a business called iyogi, believed to be responsible for these attacks.

 

 

microsoft support scam

Microsoft-support-scam-phishing

 

Microsoft support scam takeaway

Always be cautious and pay attention to the details such as sender info and never ever enter credentials if there is a shadow of a doubt about its legitimacy.

PCI DSS – what you need to know in order to stay compliant

The PCI DSS (Payment Card Industry Data Security Standard) is an industry-wide data security benchmark for firms that deal with payment cards issued by the biggest payment card gateway organizations. The guidelines increase the security of cardholder data as well as minimize the risk of credit card fraud. Developed by the PCI Security Standards Council (PCI SSC), the initial members included Amex, Visa, Mastercard, JCB, and Discover.

 

PCI DSS is not a mandatory legal requirement. Compliance with the regulations and guidelines put forth by the council does however allow merchants to improve security, increase customer trust, and reduce the risk of financial fraud. Furthermore, numerous laws refer to PCI DSS. The entire card-processing environment is subject to vulnerabilities such as malicious elements could theoretically infiltrate via a point-of-sale device, a server(s), a computer, an application, or even a wireless hotspot.

 

The PCI DSS is a global standard

PCI DSS is intended for all merchants that store and send cardholder data. It applies to firms of any size that accept credit card payments. The standards apply to service providers as well if they process, store, or send cardholder data either directly or indirectly. It is advised that merchants build strong hardware firewalls as well as update their security parameters on a constant basis.

 

Currently in version 3.2, the standards were updated and released to the public in April last year. PCI DSS follows a set of six major objectives, principles or goals. These six goals are again divided into a dozen high-level PCI DSS requirements. It provides a baseline of technical and operational requirements developed to protect cardholder data.

 

1) Develop and secure a robust network and system

The network through which any financial transactions take place must utilize sufficient firewalls in order to comply with the standards set by the PCI SSC. Companies must securely hold authentication data, and customers allowed to change them as required without compromising their data. You must change passwords and firewalls from the vendor-supplied defaults. In addition to any other default security parameters provided by the vendor. You may also need specialized firewalls developed to meet all requisite guidelines.

 

2) Guard cardholder information

This is your goal of the entire operation, information must be secure wherever it is. All the data repositories must meet the standards set by PCI SSC. You should encrypt cardholder data whenever it traverses a public network.

 

3) Have a vulnerability management system

Anti-virus and anti-malware programs are should be continually updated and tested against the latest threats to ensure top-notch security. Companies must strive to develop security apparatuses and applications that can withstand all types of hacking attacks. However, anti-virus software is incredibly ineffective and it is much more important to actually test your security.

 

4) Employ robust access control mechanisms

Access to your critical system information must be heavily controlled and regulated to minimize risks. System components and employees must all have unique identification numbers, and there should be strong physical and electronic access security measures for cardholder data. You should basically minimize direct access to cardholder data as much as possible.

 

5) Constantly test and supervise networks

Every network, system, and application under your purview affecting the flow of cardholder data should be tested on a periodic basis. Additionally, monitor the network on a 24/7 basis to ensure that malicious elements cannot access the data. Scan programs and applications that exchange cardholder data, regularly, if continuous monitoring is not possible.

 

6) Have updated data security practices

You should have a formal, well-defined information security policy developed before processing cardholder data. This policy is applied to all personnel with access to cardholder data. Additionally, you should have enforcement measures to encouraged and ensure continued compliance.

Sox Compliance Requirements a Basic Outline

Introduction

The Sarbanes-Oxley Act is the law as of 2002. You may remember the infamous corporations that were the driving force behind the Act, such as WorldCom and Enron. SOX accordingly expanded and defined new requirements for all public companies as well as management accounting firms. In addition, boards of public organizations in the United States hold significantly more responsibility.

The act is designed to the safeguard the interests of investors by various means. Such as increasing the reliability and truthfulness of corporate disclosures in relation to securities laws. The legislation stipulates that the Securities and Exchange Commission must develop regulations defining how publicly traded corporations comply with the law. The Act also makes an effort to prevent companies from withholding information from their investors.

What does it require of public companies?

The Sox Act requires all publicly traded companies to establish procedures, processes, and internal controls for all forms of financial disclosure. Showcasing absolute compliance in the event of an audit. Sox also seeks to formalize and mandate an internal system of checks and balances.

Furthermore, it requires top management figures to individually certify the accuracy of financial data, serving to increase liability in the event of fraud. Senior executives therefore hold the most liability & responsibility. Accordingly, penalties under Sarbanes Oxley for fraudulent activities have drastically increased. On the other hand, outside, independent auditors are provided with much greater protection when reviewing financial statements.

The Public Company Oversight Accounting Board

The act contains eleven titles and mandates the creation of the Public Company Oversight Accounting Board (PCOAB). The PCOAB provides constitutional authority to oversee, inspect, discipline, and regulate accounting firms. in relation to their roles as auditors of publicly traded corporations. Additionally, the PCOAB is in charge of registering auditors, defining processes for compliance audits, and enforcing strict compliance with respect to the mandate of Sox.

How can an organization be Sox compliant?

Much of the of the act relates to information security, data transmission, data storage, financial governance and accountability. Consequently, IT infrastructure is the backbone of communication, compliance with Sox requires a slew of information accountability measures. The IT department is often involved in the audit process. IT managers need to develop high-level data security systems. Apart from merely passing the federal audit, Sox compliance can have real, tangible benefits to the operations of a business.

Sox compliance audits take place on an annual basis. Before the audit, company executives meet with the accounting firm and discuss all the specifics. Audits cover specifics such as who has access to what kind of data, what kind of security protocols exist for every tier of data, how change management is implemented, the nature and strength of backup procedures, the safeguards that exist to curb data tampering, the requisite protocols to respond to security breaches, and other relevant information.

All in all, Sox compliance can be a complex task and it will require considerable investment of a firm’s time and resources. Overall, a Sox audit is just a measure of how well a company manages its internal controls.

 

Failure to comply with the provisions of Sox can lead to significant civil penalties for non-compliance. CEOs and CFOs face fines up to $5 million and 20 years incarceration if they fudge details on Sox audits.

 

NIST Special Publication 800 53

What Is NIST Special Publication 800 53?

NIST Special Publication 800 53, developed by the National Institute of Standards and Technology, provides Federal organizations with a dossier of security controls for the information systems under the purview of the concerned agency. This catalog is not applicable to information systems that are related to national security. The NIST developed the publication to further its statutory responsibilities under the Federal Information Security Management Act (FISMA).

 

The SP 800 53 leans upon the low, high, and moderate security control baselines to maintain consistency with Federal Information Processing Standards 199 and 200. The security control baselines provide a framework on which guidelines are developed on the basis of information sensitivity. NIST updates the SP 800 53 on a periodic basis to reflect the ever evolving threat from the technological landscape. The latest revision, SP 800 53 Rev 5, is supposed to be rolling out on March 28, 2017.

 

The purpose of SP 800 53

SP 800 53 is a part of the NIST’s wider SP 800 series that are developed in accordance with rigorous research conducted by the Information Technology Laboratory (ITL). Meeting the guidelines provided by the publication is a critical part of the accreditation and certification process for all federal information systems. In its most basic essence, SP 800 53 introduced and defined the concept of security control baselines. In addition. it is stressed that SP 800 53’s guidelines are not minimum guidelines. Rather it is an introductory framework on which more comprehensive and relevant control mechanisms may be devised.

 

The publication specifically covers the steps of a Risk Management Framework as defined by the NIST. The NIST Risk Management Framework defines a distinctive six-step approach to providing a comprehensive process. Moreover, it integrates the system development life cycle and information security risk management. On this tier, SP 800 53 falls under Step 2, and it specifically pertains to the selection of security control systems for federal information systems. NIST Special Publication 800 53 as well as other NIST SPs as defined by the NIST Risk Management Framework, require Federal agencies to meet certain standards in order to receive certification and accreditation on a yearly basis.

 

Risk management is the underlying goal of SP 800 53

The FIPS Publication 199 allows federal agencies and organizations involved in managing the information system processes of agencies to categorize the security of the information at their disposal. Then the agencies must determine the impact levels of their information systems in accordance with FIPS 200. It is only after this can a federal agency tailor their security controls in accordance with SP 800 53. The publication works in tandem with FIPS 199 and 200. This is to ensure that every federal information system is secure in the event of worst case scenarios. The publication allows organizations to customize the security control baselines based on the agency’s mission, requirements, and working environment.

 

Agencies must provide their answers to accreditation officers in terms of an effective risk management process. A good process appropriately identifies, mitigates, monitors, and responds to threats to their information systems. Furthermore, it must meet guidelines provided by SP 800 39.  This is in relation to managing information security risk at the organizational tier, the mission process tier, and the information system tier. The publication’s guidelines are applicable to all aspects of an information system that process, record, and/or transmit federal information. The publication seeks to provide a flexible, yet stable catalog of controls. They should protect current information and also meet the requirements of future information systems protection. In addition, it provides a common ground on which federal agencies can discuss and deal with risk management. The publication also seeks to improve inter-agency communication.

The Federal Information Security Management Act (FISMA) and Compliance Requirements

An introduction to FISMA

The Federal Information Security Management Act (FISMA) is a landmark piece of federal legislation that was enacted by the United States in 2002 under the E-Government Act of 2002. The federal government enacted the law in order to acknowledge the growing importance of information security to the political, economic, military, and financial interests of the United States. FISMA requires all federal agencies to review their policies related to information security on an annual basis and then inform the Office of Management and Budget (OMB) of the results.

In its most basic level, FISMA requires all the federal government agencies to develop new processes that document and provide information security for all the data systems that supported the functions and assets of the agency in question. The act is designed to increase the security of crucial government information and establish a “risk-based policy for cost-effective security.”

Agencies that govern FISMA compliance policies?

The National Institute of Standards and Technology (NIST) developed guidelines for all the relevant agencies in order to ensure FISMA compliance among all agencies. The Office of Management and Budget (OMB) exercises oversight authority to define methods for standardizing FISMA compliance reports by agencies. The OMB also presents these reports to Congress. In 2014, FISMA was amended to provide the Department of Homeland Security with the authority to implement and oversee processes and policies for information systems.

Under FISMA, the OMB is required to define what constitutes a major breach of information security. Distinction of authority between the NIST and the OMB is clear. NIST develops standards pertaining to the provision of information security to the other federal agencies. The OMB on the other hand, makes assessments based on those standards to determine if compliance requirements are being fulfilled. The Computer Security Division of the Information Technology Laboratory is the division of the NIST that develops and tests the various programs, applications and systems that provide network security to those agencies and bodies that fall under FISMA jurisdiction.

What does FISMA compliance constitute and who must maintain compliance?

The NIST develops standards that outline how agencies are to be FISMA compliant. There is no FISMA certification as such, and agencies need to implement the controls defined in NIST 800-53. The agencies must develop the infrastructure to implement the associated procedures and policies. This ruling applies to both executive and legislative agencies.

FISMA compliance is required for the following bodies and organizations

• All Federal departments and Agencies

• All state agencies that support or take part in federally funded programs such as the disbursement of student aid, unemployment benefits, and Medicare and health services covered under the affordable care act.

• Recently, FISMA expanded to require compliance from all private sector firms that have a relationship with the federal government. All vendors and suppliers who hold federal contracts must comply. In addition, those receiving federal funding or are participating as a supporter or beneficiary of a federal program may need to comply.

Basic outline of compliance requirements

The NIST outlines basic steps toward compliance with FISMA. Under the act:

• All agencies must have a dedicated inventory for information systems. The head of each agency will be directly responsible for developing and maintaining.

• The agency must determine the constitution of the information system under its jurisdiction.

• Data and data systems are categorized according to risk levels. The definition of each risk level and security category is provided under FIPS 199.

Each tier of system security must have a dedicated plan and NIST SP-800-18 defines concepts of the system security plan. This plan is crucial as it determines the accreditation and security certification process for the information system of each agency. Risk assessment is also a critical aspect of the compliance process. Of course, all federal information systems must meet the standards set by NIST Special Publication 800-53 and FIPS 200

The accreditation and certification process takes places according to the standards defined by NIST SP 800-37. An independent assessor conducts the assessment process and then passes on the results to an authorizing official (AO). The AO is a federal employee who has the “ultimate” authority and therefore formal responsibility. Finally, the AO demonstrates sufficient compliance on the agency’s behalf.