נושא 1 - Security and Risk Management
פרק 1 - Cybersecurity Governance
בפרק זה - מהי אבטחת סייבר וכיצד יש לנהל אותה
נושא 3 - Security Policies, Standards, Procedures and Guidelines
Security Policies Standards Procedured and Guidelines
תוכנית אבטחה ארגונית
מחשבים ומידע קשורים ישירות למשימות הליבה של הארגון, ולכן הגנה עליהם היא עדיפות עליונה של ההנהלה הבכירה.
תפקיד ההנהלה הבכירה
ההנהלה חייבת:לספק
תמיכה, תקציב, זמן ומשאבים להגנה על מערכות ומידע
להגדיר את תחום האבטחה, מה מוגן ועד כמה
להבין דרישות עסקיות ורגולטוריות (חוקים, תקנות, אחריות משפטית)
לקבוע מה מצופה מהעובדים ומה יקרה במקרה של אי-ציות
עיקרון חשוב: ההחלטות נלקחות על ידי מי שיישאו באחריות אם משהו ישתבש, אך מומחי האבטחה (Security Officers) משתפים פעולה ביישום.
תוכנית האבטחה (Security Program)
תוכנית אבטחה מלאה כוללת:
מדיניות Policy
נהלים Procedures
תקנים Standards
הנחיות Guidelines
בסיסי הגנה Baselines
גם משאבי אנוש וגם הלשכה המשפטית חייבים להיות מעורבים בפיתוח ואכיפה.
כתיבת תיעוד האבטחה
גורמים שיש לשקול:
שפה ורמת פירוט - להתאים לסוג הארגון ותרבותו
ארגונים ממובנים - ימשיכו תיעוד בצורה אחידה יותר
ארגונים פחות ממובנים - צריכים יותר הסבר ודגש לציות
איזון חשוב:כללים מפורטים מדי → מכבידים ולא יעילים
כללים כלליים מדי → קשה לדעת מתי הופרו
אחריות משפטית
סיכון קריטי: אם הארגון מצהיר במסמכיו כיצד הוא מגן על מידע רגיש — אך בפועל לא עומד בהצהרות אלו — ניתן להגיש תביעות פליליות ואזרחיות.
המסקנה: האבטחה חייבת להיות טובה הן על הנייר והן בפועל.
נקודות מפתח לבחינה
Senior management = אחראים סופיים לאבטחה
תוכנית אבטחה = אסטרטגיה ארוכת טווח
תיעוד חייב להיות ריאליסטי - לא רק אידיאלי
פער בין מדיניות כתובה למציאות = חשיפה משפטית
Security Policy
מדיניות אבטחה
מה זה מדיניות אבטחה?
מדיניות אבטחה היא מסמך כללי שמנהלים בכירים כותבים, שמגדיר:
מה תפקיד האבטחה בארגון
מי אחראי על מה
כמה סיכון ההנהלה מוכנה לקבל
3 סוגי מדיניות
ארגונית (Master)
כללית - מגדירה את כל תוכנית האבטחה
נושאית (Issue-specific)
נושא ספציפי - למשל: מדיניות דוא"ל, גישה מרחוק
מערכתית (System-specific)
מחשב/מערכת ספציפית - למשל: איך להגן על מסד נתונים מסוים
אכיפת אי-ציות
חייב להיות תהליך מובנה ומוגדר מראש למי שלא מציית, כולם צריכים לדעת מה מצופה מהם ומה התוצאות של הפרה.
כללים חשובים לכתיבת מדיניות טובה
המדיניות משרתת את העסק - לא להיפך.
היא לא אמורה לעכב את הפעילות העסקית
שפה פשוטה וברורה - כולם צריכים להבין, לא רק אנשי IT
לא תלויה בטכנולוגיה ספציפית - מגדירה מה רוצים להשיג, לא איך בדיוק
תחת ניהול גרסאות - כל עדכון ממוספר ומתוארך
נגישה לכולם - בדרך כלל מפורסמת ב-Intranet הארגוני
מתעדכנת באופן קבוע - בעיקר לאחר אירועים, שינויים ארגוניים או מיזוגים
מראה מקצועי - מסמך מקצועי מחזק את חשיבות המדיניות ואת הציות אליה
נכתבת לטווח ארוך - מתוכננת למספר שנים קדימה, לא לטווח קצר
דוגמה - מדיניות דוא"ל
מדיניות נושאית על דוא"ל יכולה לקבוע:
ההנהלה רשאית לקרוא מיילים שנמצאים על השרת
אסור לעובדים לשלוח מידע סודי במייל
לפני השימוש - העובד חותם שקרא והבין את המדיניות
היררכיה נפוצה של מדיניויות
מדיניות ארגונית ראשית
├── שימוש מותר (Acceptable Use)
├── ניהול סיכונים
├── הגנת מידע
├── בקרת גישה
├── המשכיות עסקית
├── מדיניות דוא"ל
├── תגובה לאירועים
└── ... ועוד
המבנה השלם של תוכנית אבטחה
מדיניות → בסיס כללי
נהלים + תקנים + הנחיות → מסגרת מפורטת
בקרות טכניות / מנהלתיות / פיזיות → יישום בפועל
המדיניות היא הבסיס — אבל בלי הנהלים והבקרות שמגיעים אחריה, היא נשארת דף ריק.
ISMS vs.Ent. Security Architecture
ISMS מול ארכיטקטורת אבטחה ארגונית
ההבדלים המרכזים:
ISMS
שאלה מה צריך להיות?
אופי מדיניות וכללים כלליים
תקן ISO/IEC 27000
ארכיטקטורת אבטחה ארגונית
שאלה איך מיישמים אותו?
אופי מפה טכנית לשילוב בשכבות הארגון
תקן SABSA, TOGAF, Zachman וכד'
ISMS - מה זה?
Information Security Management System
מגדיר אילו בקרות נדרשות:
ניהול סיכונים
ניהול פגיעויות
המשכיות עסקית (BCP)
הגנת מידע
ביקורת (Auditing)
ניהול תצורה
אבטחה פיזית
ISMS אומר: "צריך לנהל סיכונים" — אך לא מפרט כיצד זה מתבצע בפועל בארגון שלך.
ארכיטקטורת אבטחה ארגונית — מה זה?כלי ליישום - מראה כיצד הבקרות של ה-ISMS משתלבות בשכבות הארגון.
דוגמה 1 — ניהול סיכונים:ISMS קובע: "יש לנהל סיכונים"
↓
ארכיטקטורה מחלקת לשכבות:
Strategic → סיכונים עסקיים ברמת ההנהלה
Tactical → תוכניות יישום ומדיניות מחלקתית
Operational → בקרות יומיומיות טכניות
דוגמה 2 — הגנת מידע:ISMS קובע: "יש להגן על מידע רגיש"
↓
ארכיטקטורה מראה כיצד:
Infrastructure → DLP לזיהוי מידע רגיש ברשת
Application → בקרות גישה + הצפנה
Component → פונקציות קריפטוגרפיות ספציפיות
Business → קישור לדרישות עסקיות
ISO/IEC 27000 - מדוע כללי בכוונה?
התקן כללי ומכוון — כדי שיוכל להתאים לכל סוג ארגון.
החיסרון: קשה לדעת כיצד ליישם אותו בתשתית הספציפית שלך.
הפתרון: ארכיטקטורת האבטחה הארגונית — היא הגשר בין התקן לבין המציאות.
סיכום ויזואלי
ISO 27000 / ISMS
↓ "מה צריך?"
[מפרט בקרות]
↓ "איך מיישמים?"
ארכיטקטורת אבטחה
↓ משולבת בכל שכבות הארגון (לא בסילואים!)
Strategic / Tactical / Operational
נקודות מפתח לבחינה
ISMS = מה לשים | Security Architecture = איך לשלב
הבקרות חייבות להיות רוחביות בכל הארגון - לא בסילואים מחלקתיים
ISO 27000 = כללי בכוונה → גמישות → צורך בארכיטקטורה ליישום
ISMS vs.Cybersecurity Program vs. Ent. Security Architecture
ISMS מה צריך להגן עליו ואיך לנהל את זה
Cybersecurity Program יישום טכני של האבטחה בפועל (כלים, תגובה לאירועים, ניטור)
Enterprise Security Architecture מפת שילוב — איך הכל מתחבר לשכבות הארגון
הדרך הקלה לזכור:
ISMS שואל: "מה הכללים והבקרות הנדרשים?"
Cybersecurity שואל: "איך אנחנו מגינים מפני איומי סייבר?"
Architecture שואלת: "איך הכל משתלב יחד בארגון?"
האנלוגיה שתעזור:
בנייה בית:
ISMS = קוד הבנייה (מה חובה לכלול)
Cybersecurity Program = הקבלן שמבצע את העבודה
Architecture = תוכניות האדריכל (איך הכל מתחבר)
בקיצור: ISMS הוא הבסיס התיאורטי-מדיניותי. Cybersecurity Program הוא היישום הטכני. הארכיטקטורה היא הגשר שמראה איך ISMS מתורגם לכל שכבות הארגון.
Standards
תקנים (Standards) וסוגי מדיניות
תקנים — מה זה?
כללים מחייבים שמפרטים איך ליישם את המדיניות.
מאפיינים:
חד-משמעיים, מפורטים, וניתנים למדידה
אין ספק האם משהו עומד בתקן או לא
מחייבים לכולם, ייאכפו בפועל
דוגמה קלאסית:
מדיניות: "כל מידע סודי חייב להיות מוגן"
↓
תקן: "מידע סודי חייב להיות מוצפן ב-AES256
במנוחה ובמעבר"
מה תקנים יכולים לכסות:
שימוש בחומרה ותוכנה
התנהגות משתמשים
פרמטרים טכניים (לדוגמה: תעודת חכמה שפגה לאחר 12 חודשים, נעילה לאחר 3 ניסיונות PIN כושלים)
אסטרטגי מול טקטי
אסטרטגי - היעד הסופי, דוגמא - מדיניות אבטחה
טקטי - הצעדים להשגתו. דוגמא - תקנים, נהלים, הנחיות
תקנים, נהלים והנחיות = כלים טקטיים שמממשים את המדיניות האסטרטגית
EXAM TIP — המילה "Standard" משמשת ב-3 הקשרים:
1. תיעוד פנימי מחייב. דוגמא - תקן סיסמאות ארגוני
2. best practices של גוף תקינה. לדוגמא ISO/IEC 27000
תקן טכנולוגי. לדוגמא - IEEE 802.11
הבחינה לא תתעה אותך - רק הבן את ההקשר.
סוגי מדיניות
Regulatory. מטרה - עמידה בדרישות חוק/רגולציה. דוגמא - HIPAA, SOX, PCI DSS
Advisory. מטרה - הנחיית התנהגות עובדים + תוצאות של אי-ציות. דוגמא - טיפול במידע רפואי/פיננסי
Regulatory = מחויב מבחוץ (חוק) | Advisory = מחויב מבפנים (ארגון)
Baselines
בסיסי הגנה (Baselines)
מה זה Baseline?
נקודת ייחוס בזמן - המצב המוסכם והמאושר שממנו מודדים כל שינוי עתידי.
קובעים אותו לאחר שהסיכונים טופלו והאבטחה הוטמעה — ומשם הכל נמדד ביחס אליו.
שני שימושים עיקריים
1. נקודת השוואה לשינויים
כמו דופק במנוחה, קודם מודדים את הבסיס, אחר כך בודקים סטיות ממנו.
2. רמת ההגנה המינימלית הנדרשת
כל מערכת/סוג מערכת יכולה לקבל baseline משלה.
דוגמה:כל מערכות המחלקה הפיננסית
חייבות לעמוד ב-EAL 4 (Common Criteria)
= רק מערכות שעברו הסמכה ברמה זו מורשות לשימוש
מדוע זה קריטי?
כל שינוי במערכת — עדכון, תיקון (patch), תוכנה חדשה — עלול לפגוע ב-baseline.
לפני שינוי: מערכת עומדת ב-baseline ✓
אחרי patch: צריך לבדוק מחדש! ✗ אם לא בודקים
→ פגיעויות חדשות → פתח לתוקפים
האחריות: אנשי אבטחה חייבים לוודא שה-baseline נשמר לאחר כל שינוי.Baselines
לא רק טכניים
גם נהלים פיזיים יכולים להגדיר baseline:
דוגמה
כל עובד חייב להציג תג זיהוי עם תמונה - baseline פיזי
מבקרים חותמים בכניסה ומלווים בכל עת - baseline פרוצדורלי
נקודות מפתח לבחינה
Baseline = מינימום מוסכם, לא אידיאל
חל על מערכות, תהליכים, ונהלים פיזיים כאחד
חובה לבדוק מחדש לאחר כל שינוי - patch, עדכון, התקנה
נגזר מניהול סיכונים - קובעים אותו לאחר שמטפלים בסיכונים
Guidelines
הנחיות ונהלים
(Guidelines & Procedures)
המלצות, לא מחייבות, אך שימושיות במקרים שהתקנים לא מכסים.
מתי משתמשים?
כשאין תקן ספציפי שחל על המצב
באזורים אפורים שדורשים שיקול דעת
כדרך מומלצת ליישום תקן קיים
דוגמה:
מדיניות: "גישה למידע סודי חייבת להיות מבוקרת (audited)"
הנחיה: "הביקורת צריכה להכיל מספיק מידע
לצורך השוואה עם ביקורות קודמות"
נוהל: "שלבים מפורטים להגדרת מערכת הביקורת"
תקן- מחייב, גמישות מועטה, מטרה מוגדרת וברורה
הנחיה- לא מחייבת, גמישות גבוהה, הנחיה לא מוגדרת - יש כיוון כללי.
נהלים (Procedures)
מה זה? הוראות עבודה מפורטות צעד-אחר-צעד לביצוע משימה ספציפית.הרמה הנמוכה ביותר בשרשרת התיעוד - הקרובה ביותר למשתמשים ולמחשבים.
דוגמאות לנהלים נפוצים:
התקנת מערכת הפעלה
הגדרת ACL (רשימות בקרת גישה)
פתיחת חשבון משתמש חדש
ביצוע גיבויים (כולל לוחות זמנים ואחסון)
דיווח על אירועי אבטחה
השמדת חומרים רגישים
דוגמה:
מדיניות: "גיבויים חייבים להתבצע"
↓
נוהל: 1. מתי לגבות (תדירות)
2. אילו קבצים לכלול
3. לאן לשמור את המדיה
4. איך לוודא תקינות הגיבוי
5. כמה זמן לשמור
סיכום ההיררכיה המלא
המדיניות ← מה רוצים (אסטרטגי, מחייב)
תקנים ← כללים ספציפיים (מחייב)
בסיסים ← מינימום נדרש (מחייב)
נהלים ← איך מבצעים (מחייב, הכי מפורט)
הנחיות ← המלצות גמישות (לא מחייב)
נקודות מפתח לבחינה
Guidelines = גמישות לאזורים אפורים - לא מחייב
Procedures = הרמה הנמוכה ביותר - הכי קרובה לטכנולוגי
הנהלים מתרגמים מדיניות, תקנים והנחיות לפעולות ממשיות
נהלים חייבים להיות ברורים מספיק למגוון אנשים (לא רק מומחים)
Implementation
יישום - קישור כל המרכיבים יחד
דוגמת יישום מלאה
מדיניות: "מידע סודי חייב להיות מוגן כראוי"
↓
תקן: "מידע לקוחות בבסיסי נתונים — מוצפן ב-AES
שידור באינטרנט - רק עם IPSec"
↓
נוהל: הוראות מפורטות להטמעת AES ו-IPSec
↓
הנחיה: מה עושים אם מידע נפגם בטעות בזמן שידור
↓
Baseline: המצב לאחר ההגדרה הנכונה = המינימום שיש לשמור
הבעיה הנפוצה - מסמכים שלא בשימוש
מסמכי אבטחה רבים נכתבים רק כי רואה חשבון/מבקר ביקש זאת - ואז נשמרים בשרת קבצים ואף אחד לא קורא אותם.
מסמכים שלא מיושמים = חסרי ערך.
תנאים ליישום אפקטיבי
1. נראות (Visibility) עובדים לא יפעלו לפי כללים שלא יודעים שקיימים.
אמצעים להגברת נראות:
הדרכות מודעות אבטחה
מדריכים ומצגות
ניוזלטרים פנימיים
באנרים על מסכי המחשב
2. תמיכת הנהלה ברורה
חייב להיות ברור שההנחיות מגיעות מהנהלה בכירה ושהיא עומדת מאחוריהן.
3. ציפיות ברורות
עובדים חייבים להבין מה מצופה מהם ב:
פעולות יומיומיות
התנהגות
אחריות אישית
אחריות משפטית (Liability)
יישום מדיניות = הוכחת Due Care של הארגון.
דוגמה:
עובד שפוטר בגין הורדת תוכן פורנוגרפי יכול לתבוע ולנצח בבית משפט - אם יוכיח שלא הוסבר לו מה מותר/אסור ומה ההשלכות.
המסקנה: הודעה לעובדים על הכללים והתוצאות של אי-ציות היא חובה משפטית, לא רק פורמליות.
נקודות מפתח לבחינה
מסמך שלא מיושם = חסר ערך, גם אם כתוב מצוין
Due Care = ארגון הוכיח שנקט צעדים סבירים להגנה
חוסר בהדרכה = חשיפה משפטית בפיטורי עובד
נראות + תמיכת הנהלה + ציפיות ברורות = מדיניות אפקטיבית
