אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 8 - מודלים אופייניים לאיום

על מה המחקר?

קישורים לחלקים אחרים של המחקר

• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 1 - יסודות כלכליים.
• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 2 - תשתית IT בנקאית טיפוסית.
• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 3 - גיבוש דרישות למערכת המיגון.
• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 4 - סקירה של תקני מודל איומים.
• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 5 - 100+ קישורים נושאיים על פריצת בנק.
• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 6 - ניתוח עבירות בנקאיות.
• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 7 - מודל איום בסיסי.
• אבטחת מידע של תשלומים בנקאיים שלא במזומן. חלק 8 - מודלים אופייניים לאיום (אתה כאן)

מאמר זה משלים את סדרת הפרסומים המוקדשים להבטחת אבטחת המידע של תשלומים בנקאיים שאינם במזומן. כאן נסתכל על דגמי האיומים האופייניים אליהם מתייחסים דגם בסיס:

• מודל איום טיפוסי. חיבור רשת.
• מודל איום טיפוסי. מערכת מידע הבנויה על ארכיטקטורת שרת-לקוח.
• מודל איום טיפוסי. גש למערכת השליטה.
• מודל איום טיפוסי. מודול אינטגרציה.
• מודל איום טיפוסי. מערכת הגנת מידע קריפטוגרפית.

HABRO-אזהרה!!! חברוביים יקרים, זה לא פוסט משעשע.
40+ עמודי החומרים החבויים מתחת לחיתוך מיועדים לעזור בעבודה או בלימודים אנשים המתמחים בבנקאות או באבטחת מידע. חומרים אלו הם התוצר הסופי של המחקר והם כתובים בנימה יבשה וצורנית. בעצם, מדובר בחסר למסמכי אבטחת מידע פנימיים.

ובכן, מסורתי - "השימוש במידע מהמאמר למטרות בלתי חוקיות הוא ענישה על פי חוק". קריאה פרודוקטיבית!

מידע לקוראים שמכירים את המחקר החל מפרסום זה.

על מה המחקר?

אתה קורא מדריך למומחה האחראי על הבטחת אבטחת מידע בתשלומים בבנק.

לוגיקה של מצגת

בהתחלה ב חלק 1 и חלק 2 ניתן תיאור של האובייקט המוגן. ואז פנימה חלק 3 מתאר כיצד לבנות מערכת אבטחה ומדבר על הצורך ביצירת מודל איומים. IN חלק 4 מדבר על אילו מודלים של איום קיימים וכיצד הם נוצרים. IN חלק 5 и חלק 6 ניתן ניתוח של התקפות אמיתיות. חלק מ- 7 и חלק 8 מכיל תיאור של מודל האיום, שנבנה תוך התחשבות במידע מכל החלקים הקודמים.

מודל איום טיפוסי. חיבור רשת

אובייקט הגנה שעבורו מוחל מודל האיום (ההיקף).

מושא ההגנה הוא נתונים המועברים דרך חיבור רשת הפועל ברשתות נתונים הבנויות על בסיס מחסנית TCP/IP.

אדריכלות

תיאור של אלמנטים אדריכליים:

• "צמתי סוף" - צמתים המחליפים מידע מוגן.
• "צמתים ביניים" - אלמנטים של רשת העברת נתונים: נתבים, מתגים, שרתי גישה, שרתי פרוקסי וציוד אחר - דרכם מועברת תעבורת חיבור לרשת. באופן כללי, חיבור רשת יכול לתפקד ללא צמתי ביניים (ישירות בין צמתי קצה).

איומי אבטחה ברמה העליונה

הִתפָּרְקוּת

U1. גישה לא מורשית לנתונים המועברים.
U2. שינוי לא מורשה של הנתונים המועברים.
U3. הפרה של המחבר של הנתונים המועברים.

U1. גישה לא מורשית לנתונים המועברים

הִתפָּרְקוּת
U1.1. <…>, מתבצע בצמתים הסופיים או הביניים:
U1.1.1. <…> על ידי קריאת נתונים בזמן שהם נמצאים בהתקני האחסון המארח:
U1.1.1.1. <…> ב-RAM.
הסברים ל-U1.1.1.1.
לדוגמה, במהלך עיבוד נתונים על ידי מחסנית הרשת של המארח.

U1.1.1.2. <…> בזיכרון לא נדיף.
הסברים ל-U1.1.1.2.
לדוגמה, בעת אחסון נתונים משודרים במטמון, קבצים זמניים או החלפת קבצים.

U1.2. <…>, מתבצע בצמתים של צד שלישי של רשת הנתונים:
U1.2.1. <…> בשיטה של ​​לכידת כל החבילות המגיעות לממשק הרשת של המארח:
הסברים ל-U1.2.1.
לכידת כל החבילות מתבצעת על ידי החלפת כרטיס הרשת למצב מופקר (מצב מופקר עבור מתאמים קוויים או מצב צג עבור מתאמי Wi-Fi).

U1.2.2. <…> על ידי ביצוע התקפות אדם-באמצע (MiTM), אך מבלי לשנות את הנתונים המועברים (לא סופרים את נתוני שירות פרוטוקול הרשת).
U1.2.2.1. קישור: "מודל איום טיפוסי. חיבור רשת. U2. שינוי לא מורשה של הנתונים המועברים".

U1.3. <…>, מתבצע עקב דליפת מידע בערוצים טכניים (TKUI) מצמתים פיזיים או קווי תקשורת.

U1.4. <…>, המתבצע על ידי התקנת אמצעים טכניים מיוחדים (STS) על צמתי הקצה או הביניים, המיועדים לאיסוף סודי של מידע.

U2. שינוי לא מורשה של הנתונים המועברים

הִתפָּרְקוּת
U2.1. <…>, מתבצע בצמתים הסופיים או הביניים:
U2.1.1. <…> על ידי קריאה וביצוע שינויים בנתונים בזמן שהם נמצאים בהתקני האחסון של הצמתים:
U2.1.1.1. <…> ב-RAM:
U2.1.1.2. <…> בזיכרון לא נדיף:

U2.2. <…>, מתבצע בצמתים של צד שלישי של רשת העברת הנתונים:
U2.2.1. <…> על ידי ביצוע התקפות אדם-באמצע (MiTM) והפניית תעבורה לצומת התוקפים:
U2.2.1.1. חיבור פיזי של ציוד התוקפים גורם לניתוק חיבור רשת.
U2.2.1.2. ביצוע התקפות על פרוטוקולי רשת:
U2.2.1.2.1. <…> ניהול רשתות וירטואליות מקומיות (VLAN):
U2.2.1.2.1.1. קפיצת VLAN.
U2.2.1.2.1.2. שינוי לא מורשה של הגדרות VLAN במתגים או נתבים.
U2.2.1.2.2. <…> ניתוב תנועה:
U2.2.1.2.2.1. שינוי לא מורשה של טבלאות ניתוב סטטיות של נתבים.
U2.2.1.2.2.2. הודעה על מסלולים כוזבים על ידי תוקפים באמצעות פרוטוקולי ניתוב דינמיים.
U2.2.1.2.3. <…> תצורה אוטומטית:
U2.2.1.2.3.1. DHCP נוכל.
U2.2.1.2.3.2. WPAD נוכל.
U2.2.1.2.4. <…> כתובת ופתרון שם:
U2.2.1.2.4.1. זיוף ARP.
U2.2.1.2.4.2. הרעלת DNS.
U2.2.1.2.4.3. ביצוע שינויים לא מורשים בקבצי שמות מארח מקומיים (מארחים, lmhosts וכו')

U3. הפרת זכויות יוצרים של נתונים מועברים

הִתפָּרְקוּת
U3.1. נטרול מנגנונים לקביעת מחבר המידע על ידי ציון מידע כוזב על המחבר או מקור הנתונים:
U3.1.1. שינוי מידע על המחבר הכלול במידע המועבר.
U3.1.1.1. ניטרול הגנה קריפטוגרפית על שלמות וסמכות הנתונים המועברים:
U3.1.1.1.1. קישור: "מודל איום טיפוסי. מערכת הגנת מידע קריפטוגרפית.
אתה 4. יצירת חתימה אלקטרונית של חותם לגיטימי תחת נתונים כוזבים".
U3.1.1.2. נטרול הגנת זכויות יוצרים של נתונים משודרים, מיושם באמצעות קודי אישור חד-פעמיים:
U3.1.1.2.1. החלפת SIM.

U3.1.2. שינוי מידע על מקור המידע המועבר:
U3.1.2.1. זיוף IP.
U3.1.2.2. MAC זיופים.

מודל איום טיפוסי. מערכת מידע שנבנתה על בסיס ארכיטקטורת שרת-לקוח

אובייקט הגנה שעבורו מוחל מודל האיום (ההיקף).

מושא ההגנה הוא מערכת מידע הבנויה על בסיס ארכיטקטורת שרת-לקוח.

אדריכלות


תיאור של אלמנטים אדריכליים:

• "לָקוּחַ" – מכשיר בו פועל חלק הלקוח במערכת המידע.
• "שרת" – מכשיר בו פועל חלק השרת של מערכת המידע.
• "חנות מידע" - חלק מתשתית השרתים של מערכת מידע, המיועדת לאחסן נתונים המעובדים על ידי מערכת המידע.
• "חיבור רשת" - ערוץ חילופי מידע בין הלקוח לשרת העובר דרך רשת הנתונים. תיאור מפורט יותר של מודל האלמנטים ניתן ב "מודל איום טיפוסי. חיבור רשת".

הגבלות
בעת יצירת מודל של אובייקט, ההגבלות הבאות מוגדרות:

1. המשתמש מקיים אינטראקציה עם מערכת המידע בפרקי זמן מוגבלים, הנקראים הפעלות עבודה.
2. בתחילת כל פגישת עבודה, המשתמש מזוהה, מאומת ומאושר.
3. כל המידע המוגן נשמר בחלק השרת של מערכת המידע.

איומי אבטחה ברמה העליונה

הִתפָּרְקוּת
U1. ביצוע פעולות לא מורשות על ידי תוקפים בשם משתמש לגיטימי.
U2. שינוי לא מורשה של מידע מוגן במהלך עיבודו על ידי חלק השרת של מערכת המידע.

U1. ביצוע פעולות לא מורשות על ידי תוקפים בשם משתמש לגיטימי

הסברים
בדרך כלל במערכות מידע, פעולות מתואמות עם המשתמש שביצע אותן באמצעות:

1. יומני פעולת מערכת (יומנים).
2. תכונות מיוחדות של אובייקטי נתונים המכילים מידע על המשתמש שיצר או שינה אותם.

ביחס לפגישת עבודה, האיום הזה יכול להתפרק ל:

1. <…> בוצע בתוך הפעלת המשתמש.
2. <…> בוצע מחוץ להפעלת המשתמש.

ניתן להתחיל הפעלת משתמש:

1. על ידי המשתמש עצמו.
2. רשעים.

בשלב זה, פירוק הביניים של איום זה ייראה כך:
U1.1. פעולות לא מורשות בוצעו במהלך הפעלת משתמש:
U1.1.1. <…> הותקן על ידי המשתמש המותקף.
U1.1.2. <…> הותקן על ידי תוקפים.
U1.2. פעולות לא מורשות בוצעו מחוץ להפעלת המשתמש.

מנקודת המבט של אובייקטי תשתית מידע שיכולים להיות מושפעים על ידי תוקפים, פירוק איומי הביניים ייראה כך:

אלמנטים
פירוק איום

U1.1.1.
U1.1.2.
U1.2.

לקוח
U1.1.1.1.
U1.1.2.1.

חיבור רשת
U1.1.1.2.

שרת

U1.2.1.

הִתפָּרְקוּת
U1.1. פעולות לא מורשות בוצעו במהלך הפעלת משתמש:
U1.1.1. <…> שהותקן על ידי המשתמש המותקף:
U1.1.1.1. התוקפים פעלו באופן עצמאי מהלקוח:
U1.1.1.1.1 התוקפים השתמשו בכלי גישה סטנדרטיים למערכת מידע:
U1.1.1.1.1.1. התוקפים השתמשו באמצעי הקלט/פלט הפיזיים של הלקוח (מקלדת, עכבר, צג או מסך מגע של מכשיר נייד):
U1.1.1.1.1.1.1. התוקפים פעלו בפרקי זמן שבהם ההפעלה הייתה פעילה, מתקני I/O היו זמינים והמשתמש לא היה נוכח.
У1.1.1.1.1.2. התוקפים השתמשו בכלי ניהול מרחוק (סטנדרטיים או מסופקים על ידי קוד זדוני) כדי לשלוט בלקוח:
U1.1.1.1.1.2.1. התוקפים פעלו בפרקי זמן שבהם ההפעלה הייתה פעילה, מתקני I/O היו זמינים והמשתמש לא היה נוכח.
У1.1.1.1.1.2.2. התוקפים השתמשו בכלי ניהול מרחוק, אשר פעולתם אינה נראית למשתמש המותקף.
U1.1.1.2. התוקפים החליפו את הנתונים בחיבור הרשת בין הלקוח לשרת, ושינו אותם באופן שייתפס כפעולות של משתמש לגיטימי:
U1.1.1.2.1. קישור: "מודל איום טיפוסי. חיבור רשת. U2. שינוי לא מורשה של הנתונים המועברים".
U1.1.1.3. התוקפים אילצו את המשתמש לבצע את הפעולות שציינו באמצעות שיטות הנדסה חברתית.

У1.1.2 <…> שהותקן על ידי תוקפים:
U1.1.2.1. התוקפים פעלו מהלקוח (И):
U1.1.2.1.1. התוקפים נטרלו את מערכת בקרת הגישה של מערכת המידע:
U1.1.2.1.1.1. קישור: "מודל איום טיפוסי. גש למערכת השליטה. U1. הקמה לא מורשית של הפעלה מטעם משתמש לגיטימי".
У1.1.2.1.2. התוקפים השתמשו בכלי גישה סטנדרטיים למערכות מידע
U1.1.2.2. התוקפים פעלו מצמתים אחרים של רשת הנתונים, שמהם ניתן היה ליצור חיבור רשת לשרת (И):
U1.1.2.2.1. התוקפים נטרלו את מערכת בקרת הגישה של מערכת המידע:
U1.1.2.2.1.1. קישור: "מודל איום טיפוסי. גש למערכת השליטה. U1. הקמה לא מורשית של הפעלה מטעם משתמש לגיטימי".
U1.1.2.2.2. התוקפים השתמשו באמצעים לא סטנדרטיים לגישה למערכת המידע.
הסברים U1.1.2.2.2.
התוקפים יכולים להתקין לקוח סטנדרטי של מערכת המידע על צומת של צד שלישי או להשתמש בתוכנה לא סטנדרטית המיישמת פרוטוקולי החלפה סטנדרטיים בין הלקוח לשרת.

U1.2 בוצעו פעולות לא מורשות מחוץ להפעלת המשתמש.
U1.2.1 תוקפים ביצעו פעולות לא מורשות ולאחר מכן ביצעו שינויים לא מורשים ביומני הפעולות של מערכת המידע או בתכונות מיוחדות של אובייקטי נתונים, מה שמצביע על כך שהפעולות שביצעו בוצעו על ידי משתמש לגיטימי.

U2. שינוי לא מורשה של מידע מוגן במהלך עיבודו על ידי חלק השרת של מערכת המידע

הִתפָּרְקוּת
U2.1. תוקפים משנים מידע מוגן באמצעות כלי מערכת מידע סטנדרטיים ועושים זאת בשם משתמש לגיטימי.
U2.1.1. קישור: "מודל איום טיפוסי. מערכת מידע הבנויה על ארכיטקטורת שרת-לקוח. U1. ביצוע פעולות לא מורשות על ידי תוקפים בשם משתמש לגיטימי".

U2.2. תוקפים משנים מידע מוגן באמצעות מנגנוני גישה לנתונים שאינם מסופקים על ידי הפעולה הרגילה של מערכת המידע.
U2.2.1. תוקפים משנים קבצים המכילים מידע מוגן:
U2.2.1.1. <…>, תוך שימוש במנגנוני הטיפול בקבצים שמסופקים על ידי מערכת ההפעלה.
U2.2.1.2. <…> על ידי עורר שחזור של קבצים מעותק גיבוי לא מורשה שונה.

U2.2.2. תוקפים משנים מידע מוגן המאוחסן במסד הנתונים (И):
U2.2.2.1. התוקפים מנטרלים את מערכת בקרת הגישה DBMS:
U2.2.2.1.1. קישור: "מודל איום טיפוסי. גש למערכת השליטה. U1. הקמה לא מורשית של הפעלה מטעם משתמש לגיטימי".
U2.2.2.2. תוקפים משנים מידע באמצעות ממשקי DBMS סטנדרטיים כדי לגשת לנתונים.

U2.3. התוקפים משנים מידע מוגן על ידי שינוי לא מורשה של אלגוריתמי ההפעלה של התוכנה המעבדת אותו.
U2.3.1. קוד המקור של התוכנה נתון לשינויים.
U2.3.1. קוד המכונה של התוכנה נתון לשינויים.

U2.4. תוקפים משנים מידע מוגן על ידי ניצול פגיעויות בתוכנת מערכת מידע.

U2.5. תוקפים משנים מידע מוגן כאשר הוא מועבר בין רכיבים של חלק השרת של מערכת המידע (לדוגמה, שרת מסד נתונים ושרת יישומים):
U2.5.1. קישור: "מודל איום טיפוסי. חיבור רשת. U2. שינוי לא מורשה של הנתונים המועברים".

מודל איום טיפוסי. גש למערכת השליטה

אובייקט הגנה שעבורו מוחל מודל האיום (ההיקף).

אובייקט ההגנה שעבורו מיושם מודל איום זה מתאים לאובייקט ההגנה של מודל האיום: "מודל איום טיפוסי. מערכת מידע הבנויה על ארכיטקטורת שרת-לקוח".

במודל איומים זה, מערכת בקרת גישה למשתמש פירושה רכיב של מערכת מידע המיישמת את הפונקציות הבאות:

1. זיהוי משתמש.
2. אימות משתמש.
3. הרשאות משתמש.
4. רישום פעולות משתמש.

איומי אבטחה ברמה העליונה

הִתפָּרְקוּת
U1. הקמה לא מורשית של הפעלה מטעם משתמש לגיטימי.
U2. הגדלה בלתי מורשית של הרשאות משתמש במערכת מידע.

U1. הקמה לא מורשית של הפעלה מטעם משתמש לגיטימי

הסברים
הפירוק של איום זה יהיה תלוי בדרך כלל בסוג מערכות זיהוי המשתמש והאימות המשמשות.

במודל זה, תיחשב רק מערכת זיהוי ואימות משתמש המשתמשת בכניסה לטקסט וסיסמה. במקרה זה, נניח שכניסת המשתמש היא מידע זמין לציבור הידוע לתוקפים.

הִתפָּרְקוּת
U1.1. <…> עקב פגיעה באישורים:
U1.1.1. התוקפים פגעו באישורי המשתמש בזמן אחסונם.
הסברים U1.1.1.
לדוגמה, ניתן לכתוב את האישורים על פתק דביק המודבק על הצג.

U1.1.2. המשתמש העביר בטעות או בזדון את פרטי הגישה לתוקפים.
U1.1.2.1. המשתמש דיבר את האישורים בקול רם כשהם נכנסו.
U1.1.2.2. המשתמש שיתף בכוונה את האישורים שלו:
U1.1.2.2.1. <…> לעמיתים לעבודה.
הסברים U1.1.2.2.1.
למשל, כדי שיוכלו להחליף אותו בזמן מחלה.

U1.1.2.2.2. <…> לקבלני המעסיק המבצעים עבודות באובייקטי תשתית מידע.
U1.1.2.2.3. <…> לצדדים שלישיים.
הסברים U1.1.2.2.3.
אפשרות אחת, אך לא היחידה, ליישום האיום הזה היא השימוש בשיטות הנדסה חברתית על ידי תוקפים.

U1.1.3. התוקפים בחרו אישורים באמצעות שיטות כוח גס:
U1.1.3.1. <…> באמצעות מנגנוני גישה סטנדרטיים.
U1.1.3.2. <…> שימוש בקודים שיירטו בעבר (לדוגמה, גיבוב סיסמא) לאחסון אישורים.

U1.1.4. התוקפים השתמשו בקוד זדוני כדי ליירט את אישורי המשתמש.

U1.1.5. התוקפים חילצו אישורים מחיבור הרשת בין הלקוח לשרת:
U1.1.5.1. קישור: "מודל איום טיפוסי. חיבור רשת. U1. גישה לא מורשית לנתונים המועברים".

U1.1.6. התוקפים חילצו אישורים מרשומות של מערכות ניטור עבודה:
U1.1.6.1. <…> מערכות מעקב וידאו (אם הקשות על המקלדת תועדו במהלך הפעולה).
U1.1.6.2. <…> מערכות לניטור פעולות עובדים במחשב
הסברים U1.1.6.2.
דוגמה למערכת כזו היא StuffCop.

U1.1.7. התוקפים פשרו את אישורי המשתמש עקב פגמים בתהליך השידור.
הסברים U1.1.7.
למשל, שליחת סיסמאות בטקסט ברור בדוא"ל.

U1.1.8. תוקפים השיגו אישורים על ידי ניטור הפעלה של משתמש באמצעות מערכות ניהול מרחוק.

U1.1.9. התוקפים השיגו אישורים כתוצאה מהדלפתם דרך ערוצים טכניים (TCUI):
U1.1.9.1. התוקפים צפו כיצד המשתמש הזין אישורים מהמקלדת:
U1.1.9.1.1 התוקפים אותרו בסמיכות למשתמש וראו במו עיניהם את הכנסת האישורים.
הסברים U1.1.9.1.1
מקרים כאלה כוללים פעולות של עמיתים לעבודה או מקרה שבו המקלדת של המשתמש גלויה למבקרים בארגון.

U1.1.9.1.2 התוקפים השתמשו באמצעים טכניים נוספים, כגון משקפת או כלי טיס בלתי מאויש, וראו כניסת אישורים דרך חלון.
U1.1.9.2. התוקפים שלפו אישורים מתקשורת רדיו בין המקלדת ליחידת מערכת המחשב כשהם מחוברים באמצעות ממשק רדיו (לדוגמה, בלוטות').
U1.1.9.3. התוקפים יירטו אישורים על ידי הדלפתם דרך ערוץ הקרינה וההפרעות האלקטרומגנטיות (PEMIN).
הסברים U1.1.9.3.
דוגמאות להתקפות כאן и כאן.

U1.1.9.4. התוקף יירט את הזנת האישורים מהמקלדת באמצעות שימוש באמצעים טכניים מיוחדים (STS) שנועדו להשיג מידע בחשאי.
הסברים U1.1.9.4.
דוגמאות התקנים.

U1.1.9.5. התוקפים יירטו את הקלט של אישורים מהמקלדת באמצעות
ניתוח של אות ה-Wi-Fi המאופנן על ידי תהליך הקשה של המשתמש.
הסברים U1.1.9.5.
דוגמה התקפות.

U1.1.9.6. התוקפים יירטו את הקלט של אישורים מהמקלדת על ידי ניתוח צלילי הקשות.
הסברים U1.1.9.6.
דוגמה התקפות.

U1.1.9.7. התוקפים יירטו את הזנת האישורים מהמקלדת של מכשיר נייד על ידי ניתוח קריאות מד התאוצה.
הסברים U1.1.9.7.
דוגמה התקפות.

U1.1.10. <…>, שנשמר בעבר בלקוח.
הסברים U1.1.10.
לדוגמה, משתמש יכול לשמור פרטי כניסה וסיסמה בדפדפן כדי לגשת לאתר ספציפי.

U1.1.11. התוקפים פגעו באישורים עקב פגמים בתהליך ביטול גישת המשתמש.
הסברים U1.1.11.
לדוגמה, לאחר שמשתמש פוטר, החשבונות שלו נותרו ללא חסימה.

U1.2. <…> על ידי ניצול נקודות תורפה במערכת בקרת הגישה.

U2. העלאה בלתי מורשית של הרשאות משתמש במערכת מידע

הִתפָּרְקוּת
U2.1 <…> על ידי ביצוע שינויים לא מורשים בנתונים המכילים מידע על הרשאות משתמש.

U2.2 <…> באמצעות שימוש בפרצות במערכת בקרת הגישה.

U2.3. <…> עקב ליקויים בתהליך ניהול גישת המשתמש.
הסברים U2.3.
דוגמה 1. למשתמש ניתנה יותר גישה לעבודה ממה שנדרש מסיבות עסקיות.
דוגמה 2: לאחר שמשתמש הועבר לתפקיד אחר, זכויות הגישה שניתנו בעבר לא בוטלו.

מודל איום טיפוסי. מודול אינטגרציה

אובייקט הגנה שעבורו מוחל מודל האיום (ההיקף).

מודול אינטגרציה הוא קבוצה של אובייקטי תשתית מידע שנועדו לארגן את חילופי המידע בין מערכות מידע.

בהתחשב בעובדה שברשתות ארגוניות לא תמיד ניתן להפריד באופן חד משמעי מערכת מידע אחת לאחרת, מודול האינטגרציה יכול להיחשב גם כמקשר מקשר בין רכיבים בתוך מערכת מידע אחת.

אדריכלות
הדיאגרמה הכללית של מודול האינטגרציה נראית כך:

תיאור של אלמנטים אדריכליים:

• "שרת Exchange (SO)" – צומת / שירות / רכיב של מערכת מידע המבצע את הפונקציה של החלפת נתונים עם מערכת מידע אחרת.
• "מתווך" – צומת/שירות שנועד לארגן אינטראקציה בין מערכות מידע, אך לא חלק מהן.
  דוגמאות "מתווכים" ייתכנו שירותי דוא"ל, אוטובוסים של שירות ארגוני (אוטובוס שירות ארגוני / ארכיטקטורת SoA), שרתי קבצים של צד שלישי וכו'. באופן כללי, מודול האינטגרציה עשוי שלא להכיל "מתווכים".
• "תוכנה לעיבוד נתונים" – קבוצה של תוכניות המיישמת פרוטוקולים לחילופי נתונים והמרת פורמטים.
  לדוגמה, המרת נתונים מפורמט UFEBS לפורמט ABS, שינוי מצבי הודעות במהלך שידור וכו'.
• "חיבור רשת" מתאים לאובייקט המתואר במודל האיום הסטנדרטי "חיבור רשת". ייתכן שחלק מחיבורי הרשת המוצגים בתרשים למעלה לא קיימים.

דוגמאות למודולי אינטגרציה

סכימה 1. שילוב של ABS ו-AWS KBR דרך שרת קבצים של צד שלישי

לצורך ביצוע תשלומים, עובד בנק מורשה מוריד מסמכי תשלום אלקטרוניים ממערכת הליבה הבנקאית ושומר אותם בקובץ (בפורמט משלו, למשל dump SQL) בתיקיית רשת (...SHARE) בשרת קבצים. לאחר מכן קובץ זה מומר באמצעות סקריפט ממיר לסט של קבצים בפורמט UFEBS, אשר נקראים לאחר מכן על ידי תחנת העבודה CBD.
לאחר מכן, העובד המורשה - המשתמש של מקום העבודה האוטומטי KBR - מצפין וחותם על הקבצים שהתקבלו ושולח אותם למערכת התשלומים של בנק רוסיה.

כאשר מתקבלים תשלומים מהבנק של רוסיה, מקום העבודה האוטומטי של ה-KBR מפענח אותם ובודק את החתימה האלקטרונית, ולאחר מכן הוא רושם אותם בצורה של סט קבצים בפורמט UFEBS בשרת קבצים. לפני ייבוא ​​מסמכי תשלום ל-ABS, הם מומרים באמצעות סקריפט ממיר מפורמט UFEBS לפורמט ABS.

אנו נניח שבסכימה זו, ה-ABS פועל על שרת פיזי אחד, תחנת העבודה של KBR פועלת על מחשב ייעודי, וסקריפט הממיר פועל על שרת קבצים.

התכתבות בין האובייקטים של הדיאגרמה הנחשבת למרכיבי מודל מודול האינטגרציה:
"שרת חליפין מהצד של ABS" - שרת ABS.
"שרת חילופין מהצד של AWS KBR" – תחנת עבודה למחשב KBR.
"מתווך" – שרת קבצים של צד שלישי.
"תוכנה לעיבוד נתונים" - סקריפט ממיר.

סכמה 2. שילוב של ABS ו-AWS KBR בעת הצבת תיקיית רשת משותפת עם תשלומים על AWS KBR

הכל דומה ל- Scheme 1, אך לא נעשה שימוש בשרת קבצים נפרד; במקום זאת, תיקיית רשת (...SHARE) עם מסמכי תשלום אלקטרוניים ממוקמת במחשב עם תחנת עבודה של CBD. סקריפט הממיר עובד גם על תחנת העבודה CBD.

התכתבות בין האובייקטים של הדיאגרמה הנחשבת למרכיבי מודל מודול האינטגרציה:
דומה לתכנית 1, אבל "מתווך" לא בשימוש.

תכנית 3. שילוב של ABS ומקום עבודה אוטומטי KBR-N באמצעות IBM WebSphera MQ וחתימה על מסמכים אלקטרוניים "בצד ABS"

ABS פועלת על פלטפורמה שאינה נתמכת על ידי חתימת CIPF SCAD. חתימה על מסמכים אלקטרוניים יוצאים מתבצעת בשרת חתימה אלקטרונית מיוחדת (ES Server). אותו שרת בודק את החתימה האלקטרונית על מסמכים הנכנסים מהבנק של רוסיה.

ABS מעלה קובץ עם מסמכי תשלום בפורמט משלו לשרת ES.
שרת ה-ES, באמצעות סקריפט ממיר, ממיר את הקובץ להודעות אלקטרוניות בפורמט UFEBS, ולאחר מכן ההודעות האלקטרוניות נחתמות ומועברות ל-IBM WebSphere MQ.

תחנת העבודה KBR-N ניגשת ל-IBM WebSphere MQ ומקבלת משם הודעות תשלום חתומות, ולאחר מכן עובד מורשה - משתמש בתחנת העבודה KBR - מצפין אותן ושולח אותן למערכת התשלומים של בנק רוסיה.

כאשר תשלומים מתקבלים מהבנק של רוסיה, מקום העבודה האוטומטי KBR-N מפענח אותם ומאמת את החתימה האלקטרונית. תשלומים שעובדו בהצלחה בצורה של הודעות אלקטרוניות מפוענחות וחתומות בפורמט UFEBS מועברים ל-IBM WebSphere MQ, משם הם מתקבלים על ידי שרת החתימות האלקטרונית.

שרת החתימה האלקטרונית מאמת את החתימה האלקטרונית של תשלומים שהתקבלו ושומר אותם בקובץ בפורמט ABS. לאחר מכן, העובד המורשה - משתמש ה-ABS - מעלה את הקובץ המתקבל ל-ABS באופן שנקבע.

התכתבות בין האובייקטים של הדיאגרמה הנחשבת למרכיבי מודל מודול האינטגרציה:
"שרת חליפין מהצד של ABS" - שרת ABS.
"שרת חילופין מהצד של AWS KBR" - תחנת עבודה למחשב KBR.
"מתווך" – שרת ES ו-IBM WebSphere MQ.
"תוכנה לעיבוד נתונים" – ממיר סקריפט, חתימת CIPF SCAD בשרת ES.

תכנית 4. אינטגרציה של שרת RBS ומערכת הליבה הבנקאית באמצעות ה-API המסופק על ידי שרת מרכזיה ייעודי

אנו נניח שהבנק משתמש במספר מערכות בנקאות מרוחקות (RBS):

• "לקוח-בנק אינטרנט" ליחידים (IKB FL);
• "לקוח-בנק אינטרנט" לגורמים משפטיים (IKB LE).

על מנת להבטיח אבטחת מידע, כל האינטראקציה בין ABS למערכות הבנקאות המרוחקות מתבצעת באמצעות שרת מרכזיה ייעודי הפועל במסגרת מערכת המידע ABS.

לאחר מכן, נשקול את תהליך האינטראקציה בין מערכת RBS של IKB LE ל-ABS.
שרת RBS, לאחר שקיבל הוראת תשלום מאושרת כדין מהלקוח, חייב ליצור מסמך מתאים ב-ABS המבוסס עליו. לשם כך, באמצעות ה-API, הוא מעביר מידע לשרת החליפין, אשר בתורו מזין את הנתונים ל-ABS.

כאשר יתרות החשבון של הלקוח משתנות, ה-ABS מייצר הודעות אלקטרוניות, אשר מועברות לשרת הבנקאות המרוחק באמצעות שרת הבורסה.

התכתבות בין האובייקטים של הדיאגרמה הנחשבת למרכיבי מודל מודול האינטגרציה:
"שרת חליפין מהצד של RBS" – שרת RBS של IKB YUL.
"שרת חליפין מהצד של ABS" – שרת החלפה.
"מתווך" - חסר.
"תוכנה לעיבוד נתונים" – רכיבי שרת RBS האחראים על השימוש ב-API של שרת החליפין, רכיבי שרת החליפין האחראים על השימוש ב-API של הליבה הבנקאית.

איומי אבטחה ברמה העליונה

הִתפָּרְקוּת
U1. הזרקת מידע כוזב על ידי תוקפים דרך מודול האינטגרציה.

U1. הזרקת מידע כוזב על ידי תוקפים דרך מודול האינטגרציה

הִתפָּרְקוּת
U1.1. שינוי לא מורשה של נתונים לגיטימיים כשהם משודרים דרך חיבורי רשת:
קישור U1.1.1: "מודל איום טיפוסי. חיבור רשת. U2. שינוי לא מורשה של הנתונים המועברים".

U1.2. שידור נתונים כוזבים באמצעות ערוצי תקשורת מטעם משתתף חליפין לגיטימי:
קישור U1.1.2: "מודל איום טיפוסי. חיבור רשת. U3. הפרת זכויות יוצרים של נתונים מועברים".

U1.3. שינוי לא מורשה של נתונים לגיטימיים במהלך עיבודם בשרתי Exchange או במתווך:
U1.3.1. קישור: "מודל איום טיפוסי. מערכת מידע הבנויה על ארכיטקטורת שרת-לקוח. U2. שינוי לא מורשה של מידע מוגן במהלך עיבודו על ידי חלק השרת של מערכת המידע".

U1.4. יצירת נתונים כוזבים בשרתי ה-Exchange או במתווך מטעם משתתף בורסה לגיטימי:
U1.4.1. קישור: "מודל איום טיפוסי. מערכת מידע הבנויה על ארכיטקטורת שרת-לקוח. U1. ביצוע פעולות לא מורשות על ידי תוקפים בשם משתמש לגיטימי".

U1.5. שינוי לא מורשה של נתונים בעת עיבוד באמצעות תוכנת עיבוד נתונים:
U1.5.1. <…> עקב תוקפים שמבצעים שינויים לא מורשים בהגדרות (קונפיגורציה) של תוכנת עיבוד נתונים.
U1.5.2. <…> עקב תוקפים שמבצעים שינויים לא מורשים בקבצי ההפעלה של תוכנות לעיבוד נתונים.
U1.5.3. <…> בשל השליטה האינטראקטיבית של תוכנת עיבוד הנתונים על ידי תוקפים.

מודל איום טיפוסי. מערכת הגנה על מידע קריפטוגרפי

אובייקט הגנה שעבורו מוחל מודל האיום (ההיקף).

מושא ההגנה הוא מערכת הגנת מידע קריפטוגרפית המשמשת להבטחת אבטחת מערכת המידע.

אדריכלות
הבסיס של כל מערכת מידע היא תוכנת יישום המיישמת את פונקציונליות היעד שלה.

הגנה קריפטוגרפית מיושמת בדרך כלל על ידי קריאה לפרימיטיבים קריפטוגרפיים מהלוגיקה העסקית של תוכנת האפליקציה, הממוקמים בספריות מיוחדות - ליבות קריפטו.

פרימיטיבים קריפטוגרפיים כוללים פונקציות קריפטוגרפיות ברמה נמוכה, כגון:

• להצפין/פענוח בלוק נתונים;
• ליצור/לאמת חתימה אלקטרונית של בלוק נתונים;
• לחשב את פונקציית ה-hash של בלוק הנתונים;
• ליצור / לטעון / להעלות מידע מפתח;
• וכו '

ההיגיון העסקי של תוכנת היישום מיישם פונקציונליות ברמה גבוהה יותר באמצעות פרימיטיבים קריפטוגרפיים:

• להצפין את הקובץ באמצעות המפתחות של הנמענים שנבחרו;
• ליצור חיבור מאובטח לרשת;
• להודיע ​​על תוצאות בדיקת החתימה האלקטרונית;
• וכן הלאה.

האינטראקציה בין ההיגיון העסקי וליבת ההצפנה יכולה להתבצע:

• ישירות, על ידי היגיון עסקי הקורא לפרימיטיבים קריפטוגרפיים מספריות דינמיות של ליבת ההצפנה (.DLL עבור Windows, .SO עבור Linux);
• ישירות, דרך ממשקים קריפטוגרפיים - עטיפות, למשל, MS Crypto API, Java Cryptography Architecture, PKCS#11 וכו'. במקרה זה, ההיגיון העסקי ניגש לממשק ההצפנה, והוא מתרגם את הקריאה לליבת ההצפנה המתאימה, אשר ב- מקרה זה נקרא ספק קריפטו. השימוש בממשקי הצפנה מאפשר לתוכנת האפליקציה להתרחק מאלגוריתמים קריפטוגרפיים ספציפיים ולהיות גמישים יותר.

ישנן שתי סכמות טיפוסיות לארגון ליבת ההצפנה:

סכימה 1 - ליבת קריפטו מונוליתית


סכימה 2 - פיצול ליבת קריפטו


האלמנטים בתרשימים לעיל יכולים להיות מודולי תוכנה בודדים הפועלים על מחשב אחד או שירותי רשת המקיימים אינטראקציה בתוך רשת מחשבים.

בעת שימוש במערכות הבנויות על פי Scheme 1, תוכנת היישום וליבת ההצפנה פועלות בתוך סביבת הפעלה אחת עבור כלי ההצפנה (SFC), למשל, על אותו מחשב, המריץ את אותה מערכת הפעלה. משתמש המערכת, ככלל, יכול להפעיל תוכניות אחרות, כולל אלה המכילות קוד זדוני, באותה סביבת הפעלה. בתנאים כאלה, קיים סיכון רציני לדליפה של מפתחות קריפטוגרפיים פרטיים.

כדי למזער את הסיכון, נעשה שימוש בסכימה 2, שבה ליבת הקריפטו מחולקת לשני חלקים:

1. החלק הראשון, יחד עם תוכנת האפליקציה, פועל בסביבה לא מהימנה בה קיים סיכון להידבקות בקוד זדוני. נכנה חלק זה "חלק התוכנה".
2. החלק השני עובד בסביבה מהימנה על מכשיר ייעודי, המכיל אחסון מפתח פרטי. מעתה נכנה חלק זה "חומרה".

החלוקה של ליבת הקריפטו לחלקי תוכנה וחומרה היא מאוד שרירותית. ישנן מערכות בשוק הבנויות לפי סכימה עם ליבת קריפטו מחולקת, אך חלק ה"חומרה" שלה מוצג בצורה של תמונת מכונה וירטואלית - HSM וירטואלי (דוגמה).

האינטראקציה של שני חלקי ליבת ההצפנה מתרחשת באופן שמפתחות קריפטוגרפיים פרטיים לעולם אינם מועברים לחלק התוכנה ובהתאם לא ניתן לגנוב אותם באמצעות קוד זדוני.

ממשק האינטראקציה (API) ומערך הפרימיטיבים ההצפנה המסופק לתוכנת היישום על ידי ליבת ההצפנה זהים בשני המקרים. ההבדל טמון בדרך מימושם.

לפיכך, בעת שימוש בסכימה עם ליבת קריפטו מחולקת, האינטראקציה בין תוכנה וחומרה מתבצעת על פי העיקרון הבא:

1. פרימיטיבים קריפטוגרפיים שאינם מצריכים שימוש במפתח פרטי (לדוגמה, חישוב פונקציית hash, אימות חתימה אלקטרונית וכו') מתבצעות על ידי התוכנה.
2. פרימיטיבים קריפטוגרפיים המשתמשים במפתח פרטי (יצירת חתימה אלקטרונית, פענוח נתונים וכו') מבוצעים על ידי חומרה.

בואו נמחיש את העבודה של ליבת הקריפטו המחולקת באמצעות הדוגמה של יצירת חתימה אלקטרונית:

1. חלק התוכנה מחשב את פונקציית ה-hash של הנתונים החתומים ומשדר ערך זה לחומרה דרך ערוץ ההחלפה בין ליבות קריפטו.
2. חלק החומרה, באמצעות המפתח הפרטי וה-hash, מייצר את ערך החתימה האלקטרונית ומשדר אותו לחלק התוכנה דרך ערוץ החלפה.
3. חלק התוכנה מחזיר את הערך שהתקבל לתוכנת האפליקציה.

תכונות של בדיקת נכונות חתימה אלקטרונית

כאשר הצד המקבל מקבל נתונים חתומים אלקטרונית, עליו לבצע מספר שלבי אימות. תוצאה חיובית של בדיקת חתימה אלקטרונית מושגת רק אם כל שלבי האימות הושלמו בהצלחה.

שלב 1. בקרה על שלמות הנתונים ומחברת הנתונים.

תוכן הבמה. החתימה האלקטרונית של הנתונים מאומתת באמצעות האלגוריתם ההצפנה המתאים. סיום מוצלח של שלב זה מעיד על כך שהנתונים לא שונו מרגע החתימה, וכן שהחתימה נעשתה עם מפתח פרטי המתאים למפתח הציבורי לאימות החתימה האלקטרונית.
מיקום הבמה: ליבת קריפטו.

שלב 2. בקרת אמון במפתח הציבורי של החותם ושליטה על תקופת התוקף של המפתח הפרטי של החתימה האלקטרונית.
תוכן הבמה. השלב מורכב משני תתי שלבי ביניים. הראשון הוא לקבוע אם המפתח הציבורי לאימות החתימה האלקטרונית היה מהימן בזמן החתימה על הנתונים. השני קובע אם המפתח הפרטי של החתימה האלקטרונית היה תקף בזמן החתימה על הנתונים. באופן כללי, ייתכן שתקופות התוקף של מפתחות אלה לא תואמות (לדוגמה, עבור אישורים מוסמכים של מפתחות אימות חתימה אלקטרונית). השיטות לביסוס האמון במפתח הציבורי של החותם נקבעות על פי כללי ניהול המסמכים האלקטרונים שאומצו על ידי הצדדים המתקשרים.
מיקום הבמה: תוכנת יישום / ליבת קריפטו.

שלב 3. בקרה על סמכות החותם.
תוכן הבמה. בהתאם לכללים שנקבעו של ניהול מסמכים אלקטרוניים, נבדק האם לחתום הייתה הזכות לאשר את הנתונים המוגנים. כדוגמה, ניתן מצב של פגיעה בסמכות. נניח שיש ארגון שבו לכל העובדים יש חתימה אלקטרונית. המערכת הפנימית לניהול מסמכים אלקטרוניים מקבלת הזמנה מהמנהל, אך חתומה בחתימה אלקטרונית של מנהל המחסן. לפיכך, מסמך כזה אינו יכול להיחשב לגיטימי.
מיקום הבמה: תוכנת יישום.

הנחות שנעשו בעת תיאור מושא ההגנה

1. ערוצי העברת מידע, למעט ערוצי חילופי מפתחות, עוברים גם דרך תוכנת יישום, API וליבה קריפטו.
2. מידע על אמון במפתחות ציבוריים ו(או) תעודות, כמו גם מידע על סמכויות בעלי מפתחות ציבוריים, ממוקם במאגר המפתחות הציבוריים.
3. תוכנת היישום עובדת עם מאגר המפתחות הציבוריים דרך ליבת ההצפנה.

דוגמה למערכת מידע המוגנת באמצעות CIPF

כדי להמחיש את הדיאגרמות שהוצגו קודם לכן, הבה נשקול מערכת מידע היפותטית ונדגיש את כל האלמנטים המבניים בה.

תיאור מערכת המידע

שני הארגונים החליטו להנהיג בינם לבין עצמם ניהול מסמכים אלקטרוניים משמעותיים מבחינה משפטית (EDF). לשם כך הם התקשרו בהסכם שבו קבעו כי מסמכים ישודרו במייל, ובמקביל יש להצפין אותם ולחתום אותם בחתימה אלקטרונית מוסמכת. יש להשתמש בתוכנות אופיס מחבילת Microsoft Office 2016 ככלי ליצירה ועיבוד של מסמכים, ויש להשתמש ב-CIPF CryptoPRO ותוכנת ההצפנה CryptoARM כאמצעי הגנה קריפטוגרפית.

תיאור תשתית הארגון 1

ארגון 1 החליט להתקין תוכנת CIPF CryptoPRO ו-CryptoARM על תחנת העבודה של המשתמש – מחשב פיזי. מפתחות הצפנה וחתימה אלקטרונית יאוחסנו על מדיית המפתח של ruToken, הפועלת במצב מפתח ניתן לאחזור. המשתמש יכין מסמכים אלקטרוניים באופן מקומי במחשב שלו, ולאחר מכן יצפין, יחתום וישלח אותם באמצעות לקוח דואר אלקטרוני המותקן מקומי.

תיאור תשתית הארגון 2

ארגון 2 החליט להעביר את פונקציות ההצפנה והחתימה האלקטרונית למכונה וירטואלית ייעודית. במקרה זה, כל פעולות ההצפנה יבוצעו באופן אוטומטי.

לשם כך, שתי תיקיות רשת מאורגנות במכונה הוירטואלית הייעודית: "...In", "...Out". קבצים שיתקבלו מהצד שכנגד בצורה פתוחה יוצבו אוטומטית בתיקיית הרשת "...In". קבצים אלו יפוענחו והחתימה האלקטרונית תאומת.

המשתמש ישים קבצים בתיקייה "...Out" שיש להצפין, לחתום ולשלוח לצד שכנגד. המשתמש יכין את הקבצים בעצמו בתחנת העבודה שלו.
לביצוע פונקציות הצפנה וחתימה אלקטרונית, מותקנות במחשב הווירטואלי CIPF CryptoPRO, תוכנת CryptoARM ולקוח אימייל. ניהול אוטומטי של כל הרכיבים של המכונה הוירטואלית יתבצע באמצעות סקריפטים שפותחו על ידי מנהלי מערכת. העבודה של סקריפטים נרשמת בקובצי יומן.

מפתחות קריפטוגרפיים עבור החתימה האלקטרונית יוצבו על אסימון עם מפתח JaCarta GOST שאינו ניתן לשליפה, אותו המשתמש יחבר למחשב המקומי שלו.

האסימון יועבר למכונה הווירטואלית באמצעות תוכנת USB-over-IP מיוחדת המותקנת בתחנת העבודה של המשתמש ובמחשב הוירטואלי.

שעון המערכת בעמדת העבודה של המשתמש בארגון 1 יותאם באופן ידני. שעון המערכת של המכונה הוירטואלית הייעודית בארגון 2 יסונכרן עם שעון מערכת ההיפרוויזר, שבתורו יסונכרן דרך האינטרנט עם שרתי זמן ציבוריים.

זיהוי אלמנטים מבניים של CIPF
בהתבסס על התיאור לעיל של תשתית ה-IT, נדגיש את המרכיבים המבניים של CIPF ונכתוב אותם בטבלה.

טבלה - התכתבות של רכיבי מודל CIPF לרכיבי מערכת מידע

שם פריט
ארגון 1
ארגון 2

תוכנת יישום
תוכנת CryptoARM
תוכנת CryptoARM

חלק תוכנה בליבת הקריפטו
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP

חומרת ליבת קריפטו
לא
JaCarta GOST

API
MS CryptoAPI
MS CryptoAPI

חנות מפתחות ציבורית
תחנת העבודה של המשתמש:
- HDD;
- חנות אישורים רגילה של Windows.
היפרוויזר:
- דיסק קשיח.

מכונה וירטואלית:
- HDD;
- חנות אישורים רגילה של Windows.

אחסון מפתח פרטי
נושא מפתחות ruToken פועל במצב מפתח ניתן לשליפה
מנשא מפתחות JaCarta GOST הפועל במצב מפתח שאינו ניתן להסרה

ערוץ החלפת מפתחות ציבוריים
תחנת העבודה של המשתמש:
- RAM.

היפרוויזר:
- RAM.

מכונה וירטואלית:
- RAM.

ערוץ חילופי מפתחות פרטי
תחנת העבודה של המשתמש:
- אוטובוס USB;
- RAM.
לא

ערוץ החלפה בין ליבות קריפטו
חסר (ללא חומרת ליבת קריפטו)
תחנת העבודה של המשתמש:
- אוטובוס USB;
- RAM;
- מודול תוכנת USB-over-IP;
- ממשק רשת.

רשת ארגונית של הארגון 2.

היפרוויזר:
- RAM;
- ממשק רשת.

מכונה וירטואלית:
- ממשק רשת;
- RAM;
- מודול תוכנת USB-over-IP.

פתח את ערוץ הנתונים
תחנת העבודה של המשתמש:
- אמצעי קלט-פלט;
- RAM;
- דיסק קשיח.
תחנת העבודה של המשתמש:
- אמצעי קלט-פלט;
- RAM;
- HDD;
- ממשק רשת.

רשת ארגונית של הארגון 2.

היפרוויזר:
- ממשק רשת;
- RAM;
- דיסק קשיח.

מכונה וירטואלית:
- ממשק רשת;
- RAM;
- דיסק קשיח.

ערוץ חילופי נתונים מאובטח
אינטרנט.

רשת ארגונית של הארגון 1.

תחנת העבודה של המשתמש:
- HDD;
- RAM;
- ממשק רשת.

אינטרנט.

רשת ארגונית של הארגון 2.

היפרוויזר:
- ממשק רשת;
- RAM;
- דיסק קשיח.

מכונה וירטואלית:
- ממשק רשת;
- RAM;
- דיסק קשיח.

ערוץ זמן
תחנת העבודה של המשתמש:
- אמצעי קלט-פלט;
- RAM;
- טיימר מערכת.

אינטרנט.
רשת ארגונית של ארגון 2,

היפרוויזר:
- ממשק רשת;
- RAM;
- טיימר מערכת.

מכונה וירטואלית:
- RAM;
- טיימר מערכת.

ערוץ שידור פקודות בקרה
תחנת העבודה של המשתמש:
- אמצעי קלט-פלט;
- RAM.

(ממשק משתמש גרפי של תוכנת CryptoARM)

מכונה וירטואלית:
- RAM;
- דיסק קשיח.

(סקריפטים של אוטומציה)

ערוץ לקבלת תוצאות עבודה
תחנת העבודה של המשתמש:
- אמצעי קלט-פלט;
- RAM.

(ממשק משתמש גרפי של תוכנת CryptoARM)

מכונה וירטואלית:
- RAM;
- דיסק קשיח.

(קובצי יומן של סקריפטים אוטומציה)

איומי אבטחה ברמה העליונה

הסברים

הנחות שנעשו בעת פירוק איומים:

1. נעשה שימוש באלגוריתמים קריפטוגרפיים חזקים.
2. אלגוריתמים קריפטוגרפיים משמשים בצורה מאובטחת במצבי הפעולה הנכונים (למשל. בנק המרכזי של אירופה אינו משמש להצפנת כמויות גדולות של נתונים, העומס המותר על המפתח נלקח בחשבון וכו').
3. התוקפים מכירים את כל האלגוריתמים, הפרוטוקולים והמפתחות הציבוריים שבהם נעשה שימוש.
4. תוקפים יכולים לקרוא את כל הנתונים המוצפנים.
5. תוקפים מסוגלים לשחזר כל רכיבי תוכנה במערכת.

הִתפָּרְקוּת

U1. פשרה של מפתחות קריפטוגרפיים פרטיים.
U2. הצפנת נתונים מזויפים מטעם השולח הלגיטימי.
U3. פענוח נתונים מוצפנים על ידי אנשים שאינם נמענים לגיטימיים של הנתונים (תוקפים).
אתה 4. יצירת חתימה אלקטרונית של חותם לגיטימי תחת נתונים כוזבים.
U5. השגת תוצאה חיובית מבדיקת החתימה האלקטרונית של נתונים מזויפים.
U6. קבלה שגויה של מסמכים אלקטרוניים לביצוע עקב בעיות בארגון ניהול מסמכים אלקטרוני.
U7. גישה לא מורשית לנתונים מוגנים במהלך עיבודם על ידי CIPF.

U1. פשרה של מפתחות קריפטוגרפיים פרטיים

U1.1. שליפת המפתח הפרטי מחנות המפתחות הפרטית.

U1.2. השגת מפתח פרטי מאובייקטים בסביבת ההפעלה של כלי ההצפנה, בהם הוא עשוי לשהות זמנית.
הסברים U1.2.

אובייקטים שיכולים לאחסן זמנית מפתח פרטי יכללו:

1. RAM,
2. קבצים זמניים,
3. להחליף קבצים,
4. קבצי שינה,
5. קבצי תמונת מצב של מצב "חם" של מכונות וירטואליות, כולל קבצים של תוכן ה-RAM של מכונות וירטואליות מושהות.

U1.2.1. חילוץ מפתחות פרטיים מ-RAM עובד על ידי הקפאת מודולי RAM, הסרתם ולאחר מכן קריאת הנתונים (התקפת הקפאה).
הסברים U1.2.1.
דוגמה התקפות.

U1.3. השגת מפתח פרטי מערוץ החלפת מפתח פרטי.
הסברים U1.3.
תינתן דוגמה ליישום האיום הזה להלן.

U1.4. שינוי לא מורשה של ליבת הקריפטו, וכתוצאה מכך מפתחות פרטיים נודעים לתוקפים.

U1.5. פגיעה במפתח פרטי כתוצאה משימוש בערוצי דליפת מידע טכני (TCIL).
הסברים U1.5.
דוגמה התקפות.

U1.6. פגיעה במפתח פרטי כתוצאה משימוש באמצעים טכניים מיוחדים (STS) המיועדים לאחזור מידע בסתר ("באגים").

U1.7. פגיעה במפתחות פרטיים במהלך אחסונם מחוץ ל-CIPF.
הסברים U1.7.
לדוגמה, משתמש מאחסן את המדיה המרכזית שלו במגירת שולחן העבודה, ממנה ניתן לאחזר אותם בקלות על ידי תוקפים.

U2. הצפנת נתונים מזויפים מטעם שולח לגיטימי

הסברים
איום זה נחשב רק עבור סכימות הצפנת נתונים עם אימות שולח. דוגמאות לתוכניות כאלה מצוינות בהמלצות התקינה R 1323565.1.004-2017 "טכנולוגיית מידע. הגנה על מידע קריפטוגרפי. סכמות להפקת מפתח ציבורי עם אימות המבוסס על מפתח ציבורי". עבור תוכניות קריפטוגרפיות אחרות, איום זה אינו קיים, מכיוון שההצפנה מתבצעת על המפתחות הציבוריים של הנמען, והם ידועים בדרך כלל לתוקפים.

הִתפָּרְקוּת
U2.1. פגיעה במפתח הפרטי של השולח:
U2.1.1. קישור: "מודל איום טיפוסי. מערכת הגנת מידע קריפטוגרפית.У1. פשרה של מפתחות קריפטוגרפיים פרטיים".

U2.2. החלפה של נתוני קלט בערוץ חילופי נתונים פתוח.
הערות U2.2.
דוגמאות ליישום איום זה מובאות להלן. כאן и כאן.

U3. פענוח של נתונים מוצפנים על ידי אנשים שאינם נמענים לגיטימיים של הנתונים (תוקפים)

הִתפָּרְקוּת
U3.1. פגיעה במפתחות הפרטיים של מקבל הנתונים המוצפנים.
קישור U3.1.1: "מודל איום טיפוסי. מערכת הגנת מידע קריפטוגרפית. U1. פשרה של מפתחות קריפטוגרפיים פרטיים".

U3.2. החלפה של נתונים מוצפנים בערוץ חילופי נתונים מאובטח.

אתה 4. יצירת חתימה אלקטרונית של חותם לגיטימי תחת נתונים כוזבים

הִתפָּרְקוּת
U4.1. פגיעה במפתחות הפרטיים של החתימה האלקטרונית של חותם לגיטימי.
קישור U4.1.1: "מודל איום טיפוסי. מערכת הגנת מידע קריפטוגרפית. U1. פשרה של מפתחות קריפטוגרפיים פרטיים".

U4.2. החלפת נתונים חתומים בערוץ חילופי נתונים פתוח.
הערה U4.2.
דוגמאות ליישום איום זה מובאות להלן. כאן и כאן.

U5. השגת תוצאה חיובית מבדיקת החתימה האלקטרונית של נתונים מזויפים

הִתפָּרְקוּת
U5.1. התוקפים מיירטים הודעה בערוץ להעברת תוצאות עבודה על תוצאה שלילית של בדיקת חתימה אלקטרונית ומחליפים אותה בהודעה עם תוצאה חיובית.

U5.2. תוקפים תוקפים את האמון בחתימה על תעודות (SCRIPT - כל האלמנטים נדרשים):
U5.2.1. התוקפים מייצרים מפתח ציבורי ופרטי עבור חתימה אלקטרונית. אם המערכת משתמשת בתעודות מפתח חתימה אלקטרונית, אז הן מייצרות תעודת חתימה אלקטרונית הדומה ככל האפשר לתעודת השולח המיועד של הנתונים שאת המסר שלו הם רוצים לזייף.
U5.2.2. תוקפים מבצעים שינויים לא מורשים במאגר המפתחות הציבוריים, ומעניקים למפתח הציבורי שהם מייצרים את רמת האמון והסמכות הנדרשת.
U5.2.3. תוקפים חותמים על נתונים כוזבים עם מפתח חתימה אלקטרונית שנוצר בעבר ומכניסים אותו לערוץ חילופי הנתונים המאובטח.

U5.3. תוקפים מבצעים תקיפה באמצעות מפתחות חתימה אלקטרונית שפג תוקפם של חותם חוקי (SCRIPT - כל האלמנטים נדרשים):
U5.3.1. התוקפים מתפשרים על מפתחות פרטיים שפג תוקפם (לא תקפים כרגע) של חתימה אלקטרונית של שולח לגיטימי.
U5.3.2. התוקפים מחליפים את הזמן בערוץ שידור הזמן בזמן שבו המפתחות שנפרצו עדיין היו תקפים.
U5.3.3. תוקפים חותמים על נתונים כוזבים עם מפתח חתימה אלקטרונית שנפגע בעבר ומחדירים אותם לערוץ חילופי הנתונים המאובטח.

U5.4. תוקפים מבצעים תקיפה באמצעות מפתחות חתימה אלקטרונית שנפגעו של חותם חוקי (SCRIPT - כל האלמנטים נדרשים):
U5.4.1. התוקף יוצר עותק של מאגר המפתחות הציבורי.
U5.4.2. התוקפים מתפשרים על המפתחות הפרטיים של אחד השולחים הלגיטימיים. הוא מבחין בפשרה, שולל את המפתחות, ומידע על שלילת המפתח ממוקם בחנות המפתחות הציבורית.
U5.4.3. תוקפים מחליפים את חנות המפתחות הציבוריים בחנות שהועתקה בעבר.
U5.4.4. תוקפים חותמים על נתונים כוזבים עם מפתח חתימה אלקטרונית שנפגע בעבר ומחדירים אותם לערוץ חילופי הנתונים המאובטח.

U5.5. <…> עקב נוכחות שגיאות ביישום השלב השני והשלישי של אימות חתימה אלקטרונית:
הסברים U5.5.
ניתנת דוגמה ליישום האיום הזה להלן.

U5.5.1. בדיקת אמון בתעודת מפתח חתימה אלקטרונית רק על ידי נוכחות אמון בתעודה עמו היא חתומה, ללא בדיקות CRL או OCSP.
הסברים U5.5.1.
דוגמה ליישום איומים.

U5.5.2. בעת בניית שרשרת נאמנות לתעודה, רשויות הנפקת התעודות אינן מנותחות
הסברים U5.5.2.
דוגמה להתקפה נגד תעודות SSL/TLS.
התוקפים קנו תעודה לגיטימית עבור הדואר האלקטרוני שלהם. לאחר מכן הם עשו אישור אתר הונאה וחתמו עליו עם התעודה שלהם. אם לא ייבדקו אישורים, אזי בבדיקת שרשרת הנאמנות היא תתברר כנכונה, ובהתאם גם תעודת ההונאה תהיה נכונה.

U5.5.3. בעת בניית שרשרת אמון אישורים, אישורי ביניים אינם נבדקים לביטול.

U5.5.4. CRL מתעדכנים בתדירות נמוכה יותר מאשר הם מונפקים על ידי רשות האישורים.

U5.5.5. ההחלטה לתת אמון בחתימה אלקטרונית מתקבלת לפני שמתקבלת תגובת OCSP לגבי מצב התעודה, הנשלחת על פי בקשה שנעשתה מאוחר יותר ממועד יצירת החתימה או מוקדם יותר מה-CRL הבא לאחר יצירת החתימה.
הסברים U5.5.5.
בתקנות של רוב ה-CA, מועד שלילת האישור נחשב לזמן הנפקת ה-CRL הקרוב ביותר המכיל מידע על ביטול האישור.

U5.5.6. בעת קבלת נתונים חתומים, האישור שייך לשולח אינו מסומן.
הסברים U5.5.6.
דוגמה להתקפה. ביחס לתעודות SSL: ייתכן שלא תיבדק התאמת כתובת השרת הנקרא עם הערך של שדה CN בתעודה.
דוגמה להתקפה. התוקפים פגעו במפתחות החתימה האלקטרונית של אחד ממשתתפי מערכת התשלומים. לאחר מכן הם פרצו לרשת של משתתף אחר ובשמו שלחו מסמכי תשלום חתומים במפתחות שנפגעו לשרת ההסדר של מערכת התשלומים. אם השרת מנתח אמון בלבד ואינו בודק תאימות, מסמכי הונאה ייחשבו לגיטימיים.

U6. קבלה שגויה של מסמכים אלקטרוניים לביצוע עקב בעיות בארגון ניהול מסמכים אלקטרוני.

הִתפָּרְקוּת
U6.1. הצד המקבל אינו מזהה כפילות של מסמכים שהתקבלו.
הסברים U6.1.
דוגמה להתקפה. תוקפים יכולים ליירט מסמך המועבר לנמען, גם אם הוא מוגן קריפטוגרפית, ולאחר מכן לשלוח אותו שוב ושוב דרך ערוץ שידור נתונים מאובטח. אם הנמען אינו מזהה כפילויות, אזי כל המסמכים שיתקבלו ייתפסו ויעובדו כמסמכים שונים.

U7. גישה לא מורשית לנתונים מוגנים במהלך עיבודם על ידי CIPF

הִתפָּרְקוּת

U7.1. <…> עקב דליפת מידע דרך ערוצים צדדיים (התקפת ערוץ צד).
הסברים U7.1.
דוגמה התקפות.

U7.2. <…> עקב נטרול ההגנה מפני גישה בלתי מורשית למידע המעובד ב-CIPF:
U7.2.1. הפעלת CIPF בניגוד לדרישות המתוארות בתיעוד עבור CIPF.

U7.2.2. <…>, בוצע עקב נוכחות של פגיעויות ב:
U7.2.2.1. <…> אמצעי הגנה מפני גישה בלתי מורשית.
U7.2.2.2. <…> CIPF עצמו.
U7.2.2.3. <…> סביבת ההפעלה של כלי ההצפנה.

דוגמאות להתקפות

התרחישים הנידונים להלן מכילים כמובן שגיאות אבטחת מידע ומשמשים רק להמחשת התקפות אפשריות.

תרחיש 1. דוגמה ליישום איומים U2.2 ו-U4.2.

תיאור החפץ


תוכנת AWS KBR ו-CIPF SCAD Signature מותקנות במחשב פיזי שאינו מחובר לרשת המחשבים. FKN vdToken משמש כמנשא מפתח במצב של עבודה עם מפתח שאינו ניתן להסרה.

תקנות הפשרה מניחות כי מומחה ההסדר ממחשב עבודתו מוריד הודעות אלקטרוניות בטקסט ברור (סכימה של תחנת העבודה הישנה של KBR) משרת קבצים מאובטח מיוחד, ולאחר מכן כותב אותן לכונן הבזק מסוג USB הניתן להעברה ומעביר אותן לתחנת העבודה KBR. איפה הם מוצפנים ושלטים. לאחר מכן, המומחה מעביר הודעות אלקטרוניות מאובטחות למדיום המנוכר, ולאחר מכן, דרך מחשב העבודה שלו, כותב אותן לשרת קבצים, משם הם עוברים ל-UTA ולאחר מכן למערכת התשלומים של בנק רוסיה.

במקרה זה, הערוצים להחלפת נתונים פתוחים ומוגנים יכללו: שרת קבצים, מחשב עבודה של מומחה ומדיה מנוכרת.

התקפה
תוקפים לא מורשים מתקינים מערכת שליטה מרחוק במחשב העבודה של מומחה, ובזמן כתיבת פקודות תשלום (הודעות אלקטרוניות) לאמצעי העברה, מחליפים את התוכן של אחת מהן בטקסט ברור. המומחה מעביר פקודות תשלום למקום העבודה האוטומטי KBR, חותם ומצפין מבלי לשים לב להחלפה (למשל עקב ריבוי פקודות תשלום בטיסה, עייפות וכו'). לאחר מכן, צו התשלום המזויף, לאחר שעבר בשרשרת הטכנולוגית, נכנס למערכת התשלומים של בנק רוסיה.

תרחיש 2. דוגמה ליישום איומים U2.2 ו-U4.2.

תיאור החפץ


מחשב עם תחנת עבודה מותקנת KBR, SCAD Signature ונשא מפתחות מחובר FKN vdToken פועל בחדר ייעודי ללא גישה מאנשי הצוות.
מומחה החישוב מתחבר לתחנת העבודה CBD במצב גישה מרחוק באמצעות פרוטוקול RDP.

התקפה
התוקפים מיירטים את הפרטים, באמצעותם מתחבר מומחה החישובים ועובד עם תחנת העבודה CBD (למשל, באמצעות קוד זדוני במחשב שלו). ואז הם מתחברים בשמו ושולחים הוראת תשלום מזויפת למערכת התשלומים של בנק רוסיה.

תרחיש 3. דוגמה ליישום איום U1.3.

תיאור החפץ


הבה נבחן את אחת האפשרויות ההיפותטיות ליישום מודולי האינטגרציה של ABS-KBR עבור סכימה חדשה (AWS KBR-N), שבה החתימה האלקטרונית של מסמכים יוצאים מתרחשת בצד ABS. במקרה זה, נניח שה-ABS פועל על בסיס מערכת הפעלה שאינה נתמכת על ידי חתימת CIPF SKAD, ובהתאם לכך, הפונקציונליות ההצפנה מועברת למכונה וירטואלית נפרדת - שילוב "ABS-KBR" מודול.
אסימון USB רגיל הפועל במצב מפתח ניתן לשליפה משמש כמנשא מפתחות. בעת חיבור מדיית המפתח להיפרוויזר, התברר שאין יציאות USB פנויות במערכת, ולכן הוחלט לחבר את אסימון ה-USB דרך רכזת USB ברשת, ולהתקין לקוח USB-over-IP על הווירטואלי. מכונה, שתתקשר עם הרכזת.

התקפה
התוקפים יירטו את המפתח הפרטי של החתימה האלקטרונית מערוץ התקשורת בין רכזת ה-USB ל-hypervisor (הנתונים הועברו בטקסט ברור). ברשותם של המפתח הפרטי, התוקפים יצרו הוראת תשלום מזויפת, חתמו עליה בחתימה אלקטרונית ושלחו אותה למקום העבודה האוטומטי KBR-N לביצוע.

תרחיש 4. דוגמה ליישום איומים U5.5.

תיאור החפץ
בואו ניקח בחשבון את אותו מעגל כמו בתרחיש הקודם. אנו נניח שהודעות אלקטרוניות המגיעות מתחנת העבודה KBR-N מגיעות לתיקיית …SHAREIn, ואלו שנשלחות לתחנת העבודה KBR-N ובהמשך למערכת התשלומים של בנק רוסיה עוברות אל …SHAREout.
כמו כן, נניח כי בעת יישום מודול האינטגרציה, רשימות של אישורים שבוטלו מתעדכנות רק כאשר מפתחות קריפטוגרפיים מונפקים מחדש, וכן שהודעות אלקטרוניות המתקבלות בתיקייה …SHAREIn נבדקות רק עבור בקרת תקינות ובקרת אמון במפתח הציבורי של חתימה אלקטרונית.

התקפה

התוקפים, תוך שימוש במפתחות שנגנבו בתרחיש הקודם, חתמו על הוראת תשלום מזויפת המכילה מידע על קבלת הכסף לחשבונו של הלקוח המרמה והכניסו אותו לערוץ חילופי הנתונים המאובטח. מאחר שאין אימות שהוראת התשלום נחתמה על ידי בנק רוסיה, היא מתקבלת לביצוע.

מקור: www.habr.com