+Achieving Security, Compliance & Resilience Requirements
|
Achieving Security, Compliance & Resilience Requirements
Description
Mechanisms exist to design Technology Assets, Applications and/or Services (TAAS) so that required capabilities continue to operate in a controlled and acceptable manner, when conditions are both routine and degraded.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
SCR-CMM
Level 0 Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 Performed Informally
Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Security engineering-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ IT and/or cybersecurity personnel use an informal process to design, build and maintain secure, compliant and resilient solutions.
Level 2 Planned Tracked
Secure Engineering & Architecture (SEA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Secure engineering and architecture management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ IT and/or cybersecurity personnel define entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD. ▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices. ▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).
Level 3 Well Defined
Secure Engineering & Architecture (SEA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with SEA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with SEA domain capabilities are well-documented and kept current by process owners. ▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management solution). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with SEA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS). ▪ An implemented and operational capability exists to achieve resilience requirements in normal and adverse situations.
Level 4 Quantitatively Controlled
Utilize SCR-CMM Level 3 criteria definitions: ▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. ▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.
Level 5 Continuously Improving
Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
1. Преглед
1.1 Препратки
1.2 Идентифицирани изисквания
1.3 Свързани регулации
2. Идентифицирани изисквания
Изисквания
| Източник |
Изискване |
3. Свързани регулации
Регулации
| Източник |
Регулация |
|
EULAW
|
Член 4 Определения
Член 4
За целите на настоящия регламент:
1)
„лични данни“ означава всяка информация, свързана с идентифицирано физическо лице или физическо лице, което може да бъде идентифицирано („субект на данни“); физическо лице, което може да бъде идентифицирано, е лице, което може да бъде идентифицирано, пряко или непряко, по-специално чрез идентификатор като име, идентификационен номер, данни за местонахождение, онлайн идентификатор или по един или повече признаци, специфични за физическата, физиологичната, генетичната, психическата, умствената, икономическата, културната или социална идентичност на това физическо лице;
2)
„обработване“ означава всяка операция или съвкупност от операции, извършвана с лични данни или набор от лични данни чрез автоматични или други средства като събиране, записване, организиране, структуриране, съхранение, адаптиране или промяна, извличане, консултиране, употреба, разкриване чрез предаване, разпространяване или друг начин, по който данните стават достъпни, подреждане или комбиниране, ограничаване, изтриване или унищожаване;
3)
„ограничаване на обработването“ означава маркиране на съхранявани лични данни с цел ограничаване на обработването им в бъдеще;
4)
„профилиране“ означава всяка форма на автоматизирано обработване на лични данни, изразяващо се в използването на лични данни за оценяване на определени лични аспекти, свързани с физическо лице, и по-конкретно за анализиране или прогнозиране на аспекти, отнасящи се до изпълнението на професионалните задължения на това физическо лице, неговото икономическо състояние, здраве, лични предпочитания, интереси, надеждност, поведение, местоположение или движение;
5)
„псевдонимизация“ означава обработването на лични данни по такъв начин, че личните данни не могат повече да бъдат свързвани с конкретен субект на данни, без да се използва допълнителна информация, при условие че тя се съхранява отделно и е предмет на технически и организационни мерки с цел да се гарантира, че личните данни не са свързани с идентифицирано физическо лице или с физическо лице, което може да бъде идентифицирано;
6)
„регистър с лични данни“ означава всеки структуриран набор от лични данни, достъпът до които се осъществява съгласно определени критерии, независимо дали е централизиран, децентрализиран или разпределен съгласно функционален или географски принцип;
7)
„администратор“ означава физическо или юридическо лице, публичен орган, агенция или друга структура, която сама или съвместно с други определя целите и средствата за обработването на лични данни; когато целите и средствата за това обработване се определят от правото на Съюза или правото на държава членка, администраторът или специалните критерии за неговото определяне могат да бъдат установени в правото на Съюза или в правото на държава членка;
8)
„обработващ лични данни“ означава физическо или юридическо лице, публичен орган, агенция или друга структура, която обработва лични данни от името на администратора;
9)
„получател“ означава физическо или юридическо лице, публичен орган, агенция или друга структура, пред която се разкриват личните данни, независимо дали е трета страна или не. Същевременно публичните органи, които могат да получават лични данни в рамките на конкретно разследване в съответствие с правото на Съюза или правото на държава членка, не се считат за „получатели“; обработването на тези данни от посочените публични органи отговаря на приложимите правила за защита на данните съобразно целите на обработването;
10)
„трета страна“ означава физическо или юридическо лице, публичен орган, агенция или друг орган, различен от субекта на данните, администратора, обработващия лични данни и лицата, които под прякото ръководство на администратора или на обработващия лични данни имат право да обработват личните данни;
11)
„съгласие на субекта на данните“ означава всяко свободно изразено, конкретно, информирано и недвусмислено указание за волята на субекта на данните, посредством изявление или ясно потвърждаващо действие, което изразява съгласието му свързаните с него лични данни да бъдат обработени;
12)
„нарушение на сигурността на лични данни“ означава нарушение на сигурността, което води до случайно или неправомерно унищожаване, загуба, промяна, неразрешено разкриване или достъп до лични данни, които се предават, съхраняват или обработват по друг начин;
13)
„генетични данни“ означава лични данни, свързани с наследени или придобити генетичните белези на дадено физическо лице, които дават уникална информация за отличителните черти или здравето на това физическо лице и които са получени, по-специално, от анализ на биологична проба от въпросното физическо лице;
14)
„биометрични данни“ означава лични данни, получени в резултат на специфично техническо обработване, които са свързани с физическите, физиологичните или поведенческите характеристики на дадено физическо лице и които позволяват или потвърждават уникалната идентификация на това физическо лице, като лицеви изображения или дактилоскопични данни;
15)
„данни за здравословното състояние“ означава лични данни, свързани с физическото или психическото здраве на физическо лице, включително предоставянето на здравни услуги, които дават информация за здравословното му състояние;
16)
„основно място на установяване“ означава:
a)
по отношение на администратор, установен в повече от една държава членка — мястото, където се намира централното му управление в Съюза, освен в случаите, когато решенията по отношение на целите и средствата за обработването на лични данни се вземат на друго място на установяване на администратора в Съюза и на това място на установяване има правомощия за прилагане на тези решения, в който случай мястото на установяване, където са взети тези решения, се счита за основно място на установяване;
б)
по отношение на обработващ лични данни, установен в повече от една държава членка — мястото, където се намира централното му управление в Съюза, или ако обработващият лични данни няма централно управление в Съюза, мястото на установяване на обработващия лични данни в Съюза, където се осъществяват основните дейности по обработването в контекста на дейностите на дадено място на установяване на обработващия лични данни, доколкото обработващият има специфични задължения съгласно настоящия регламент;
17)
„представител“ означава физическо или юридическо лице, установено в Съюза, което, назначено от администратора или обработващия лични данни в писмена форма съгласно член 27, представлява администратора или обработващия лични данни във връзка със съответните им задължения по настоящия регламент;
18)
„дружество“ означава физическо или юридическо лице, което осъществява икономическа дейност, независимо от правната му форма, включително партньорствата или сдруженията, които редовно осъществяват икономическа дейност;
19)
„група предприятия“ означава контролиращо предприятие и контролираните от него предприятия;
20)
„задължителни фирмени правила“ означава политики за защита на личните данни, които се спазват от администратор или обработващ лични данни, установен на територията на държава членка, при предаване или съвкупност от предавания на лични данни до администратор или обработващ лични данни в една или повече трети държави в рамките на група предприятия или група дружества, участващи в съвместна стопанска дейност;
21)
„надзорен орган“ означава независим публичен орган, създаден от държава членка съгласно член 51;
22)
„засегнат надзорен орган“ означава надзорен орган, който е засегнат от обработването на лични данни, тъй като:
a)
администраторът или обработващият лични данни е установен на територията на държавата членка на този надзорен орган;
б)
субектите на данни с местопребиваване в държавата членка на този надзорен орган са засегнати съществено или е вероятно да бъдат засегнати съществено от обработването; или
в)
до този надзорен орган е подадена жалба;
23)
„трансгранично обработване“ означава или:
a)
обработване на лични данни, което се осъществява в контекста на дейностите на местата на установяване в повече от една държава членка на администратор или обработващ лични данни в Съюза, като администраторът или обработващият лични данни е установен в повече от една държава членка; или
б)
обработване на лични данни, което се осъществява в контекста на дейностите на едно-единствено място на установяване на администратор или обработващ лични данни в Съюза, но което засяга съществено или е вероятно да засегне съществено субекти на данни в повече от една държава членка;
24)
„относимо и обосновано възражение“ означава възражение срещу проект на решение относно това дали е налице нарушение на настоящия регламент или не, или дали предвижданото действие по отношение на администратора или обработващия лични данни отговаря на изискванията на настоящия регламент, което ясно доказва, че проектът за решение води до значителни рискове за основните права и свободи на субектите на данни и, където е приложимо, за свободното движение на лични данни в рамките на Съюза;
25)
„услуга на информационното общество“ означава услуга по смисъла на член 1, параграф 1, точка б) от Директива (ЕС) 2015/1535 на Европейския парламент и на Съвета (
1
);
26)
„международна организация“ означава организация и нейните подчинени органи, регламентирани от международното публично право, или друг орган, създаден чрез или въз основа на споразумение между две или повече държави.
|
|
EULAW
|
Член 15 Точност, надеждност и киберсигурност
-
|
Свързани задачи
- Secure Controls Framework -
"The SCF is the Common Controls Framework™ (CCF), the world's most comprehensive cybersecurity and data privacy metaframework - it is also free to use. The entire concept is building secure, compliant and resilient capabilities in the most efficient and cost-effective manner possible.
The SCF is more than just a unified control catalog, since its included content creates a playbook for Governance, Risk & Compliance (GRC) capabilities. Used globally by organizations of every size, the SCF is a robust and scalable solution for security, compliance and resilience controls. As a comprehensive security framework, the SCF maps 1,400+ controls across 200+ laws, regulations, and industry frameworks so you can implement once and comply everywhere.
Like it or not, cybersecurity is a protracted war on an asymmetric battlefield, where the threats are everywhere and as defenders we have to make the effort to work together to help improve cybersecurity and data privacy practices, since we all suffer when massive data breaches occur or when cyber attacks have physical impacts. Hackers share information on attack methods with other hackers, so why shouldn’t the good guys share information on how to best protect an organization? We decided to take action and make a difference, since we feel it is too important to wait for someone else to fix the problems that exist.
The SCF is made up of volunteers, mainly specialists within the cybersecurity profession, who focus on GRC and the cybersecurity side of data privacy. These are auditors, engineers, architects, incident responders, consultants and other specialists who live and breathe these topics on a daily basis. The end product is "expert-derived content" that makes up the SCF." https://securecontrolsframework.com/
Terms & Conditions
The SCF End User License Agreement (EULA) governs the use of the Secure Controls Framework® (SCF) under the Creative Commons Attribution-No Derivatives 4.0 International Public License.
|