• Безопасность

  • Тесты и Аудит

  • ПО


  • ISO27001

  • Планирование безопасности

    Наш подход к планированию и разработке стратегии безопасности ERP основан на оценке рисков, которым подвергается бизнес и принимает во внимание: Корпоративные требования...
    Читать дальше...
  • Корпоративная Безопасность


    Технология CODEFEND позволяет проводить автоматизированную проверку исходного кода приложений с привязкой к используемой технологии и с возможностью написания кастомизируемых...
    Читать дальше...
  • Тест на проникновение

  • Анализ кода

  • Ping Identity

    Решение для идентификации и SSO c низкой стоимостью владения. Это инновационное решение может поставляться как облачный сервис (on-Demand) и как решение для интеграции в...
    Читать дальше...
  • Сервис Panaya для SAP ERP

  • Retalix

  • Требования PCI DSS

  • ISO 27001

    Информация зачастую является ключевым активом компании, а ее защита - приоритетной задачей. Получение сертификации по стандарту ISO 27001 позволит сохранить и защитить...
    Читать дальше...
Developed by JoomVision.com

GRC - защита Вашего кода


Written by Avi Douglen, Senior Application Security Project Manager

Governance, Risk Management, and Compliance – or GRC – is a growing concern for enterprises. However, this field apparently bears only a passing semblance to the security disciplines. Indeed, most enterprises will usually have a clear separation between the two fields even though risk management is an important aspect of security. In concurrence, security officers are often required to participate in compliance efforts (e.g. for PCI-DSS) only to ensure that their part of the regulated systems is compliant to the specific clauses relating to security, and rarely does overall responsibility for regulatory compliance fall under the purview of security. Governance, of course, is most often perceived as completely unrelated to the security field.

Since GRC does not, for the most part, guarantee security, an organization will often have to choose between spending resources on GRC or on security. Even in the rare organization that does include security officers in the GRC discussion and relevant work, Application Security will get left behind.

So, why must an enterprise bother with software security, in the context of GRC?

When examining the important business processes that need to be governed, risk-managed, and compliant, enterprises will find that these are, in fact, represented by the software applications: it is the applications that are actualized business processes. It is applications that store and process the organization's sensitive information (e.g. credit card data, financial information, etc.); it is applications that users access; the business processes are mostly based on applications. This can include line-of-business systems, accounting software, supply chain management, ERP systems, and more.

In fact, some regulations explicitly demand software security (e.g. PCI-DSS); additionally, most vulnerabilities are in these applications (according to a study by NIST, it is 77% of vulnerabilities).

It is clear that security flaws are in contrast to the GRC outlook – if attackers can take control of your systems, you cannot govern them (since you don't have control over them); you're definitely not managing risks properly; and the systems are not even compliant. Thus, it is apparent that GRC efforts must integrate software development.

Unfortunately, corporate officers tasked with implementing aspects of GRC – even security officers – seldom understand development processes, even though these take place in their organization. In an informal survey, we discovered that less than 5% of corporate officers – Risk Officers, Security Officers, etc. – have actual development experience, and the majority of those are far removed from development today. And yet, these officers are the ones responsible for implementing control throughout the organization, including application development.

The solution to this challenge is for enterprises to implement a Secure Development Life-Cycle (SDLC) policy. This is a development policy – not a security policy – that prescribes additional, security-focused activities to be performed at each phase of the existing development methodology. This enables management to involve the different stakeholders in the system, at different points throughout the lifecycle of the application (or, "actualized business process"). Effective application security is critical to ensuring proper business control.

For example, during the Requirements Analysis phase proper classification of the system's data and processes should be performed and security requirements should be gathered in addition to purely functional requirements; during the Architecture and Design phases, security principles should be implemented and Threat Modeling performed; during the Coding phase, secure coding guidelines should be followed and the code should be reviewed for security flaws; Penetration Tests and Security Audits should be performed during the testing phase; and a Security Incident Response Plan should be in place for the Maintenance phase, while following a secure Change Management policy.

Now, let's examine how SDLC would impact GRC efforts. Implementing a well-defined SDLC process enables stakeholders – including non-technical stakeholders, such as risk officers, business managers, and C-level executives – to access and influence the development lifecycle, in a way that otherwise would not be available. The SDLC grants control, by allowing stakeholders to provide input at pre-defined checkpoints. Developers are provided with guidance, so that they know what they are supposed to do in order to create applications that fit in with overall GRC strategy. And the SDLC forces transparency, facilitating visibility into the process and results, through reporting and metrics. These elements together enable an organization to incorporate into GRC both the development processes (as individual business units), and the application itself (as an actualized business process).

SDLC also meets specific goals, and assuages specific pain-points, of each individual element of GRC.

Compliance – How do you get your developers to build compliant systems? And b) How do you know they did?

Typically, SDLC covers standard security controls. If necessary, it is easy to tailor the SDLC for specific regulatory requirements, to be enforced during application development; in fact, certain regulations explicitly require SDLC. It is a truism that if you’re provably secure, you’re most of the way to compliance. SDLC helps focus on business needs – and avoid compliance checkbox olympics.

Risk Management - How do you ensure the developed system has low risk (i.e. risk has been managed), and how do you know the current level of risk?

SDLC activities identify and mitigate risks early and efficiently, in addition to providing prescriptive guidance to avoid or fix vulnerabilities. This in turn helps recognize higher risk and eliminate focus on low risk. A well-defined process is needed in order to properly manage risks, instead of juggling them as one-offs. It is necessary to manage risks early and throughout the entire process.

Governance – How do you govern (control) the development process, from outside the development group? More importantly, how can you control the output (applications, i.e. actualized business processes)?

The SDLC can provide solutions to this, by providing transparency through use of metrics; enforcing control through guidelines and checkpoints; defining standard security mechanisms and controls to be built directly into the applications; and full business monitoring throughout. Thus, governance is achieved through defining and ensuring what must go into applications, how they are built, and reporting the results to stakeholders.

These are effects that are difficult, if not unfeasible, to achieve without SDLC in place. Accordingly, with SDLC providing both security for applications, and GRC elements throughout, it becomes practical to be both secure, and governed/risk managed/compliant. With applications being seen as software versions of the organization's business processes, it is no longer one at the expense of the other.

Joomla! Template design and develop by JoomVision

Случайная новость

В 63% организаций отсутствует архитектура системы безопасности

По данным отчета «Глобальное исследование информационной безопасности, 2012 год», опубликованного компанией «Эрнст энд Янг», для защиты от угроз, исходящих от существующих и новых технологий, организациям необходимо коренным образом изменить подход к обеспечению информационной безопасности. Всего в исследовании приняли участие более чем 1850 руководителей информационно-технологических подразделений и подразделений по обеспечению информационной безопасности, а также других руководящих работников … полный текст

Источник: CNews