אבטחת סייבר במסמכי SRS: A MUST HAVE
אבטחת סייבר במכשור רפואי אינה בגדר Nice to Have – היא חלק בלתי נפרד ממסמך
SRS (Software Requirements Specification). הדרישות בתחום הזה לא רק מגדירות מה המערכת יכולה ולא יכולה לעשות, אלא מהוות שכבת הגנה קריטית מפני תקיפות ואיומים.
יישום נכון של דרישות אבטחה מבטיח שהמערכת תתפקד כפי שתוכננה – ולא תשמש וקטור תקיפה שעלול לפגוע במטופלים, במידע הרפואי ובשרשרת האספקה הרפואית.
מה צריך להיכנס ל-SRS בהקשר של אבטחת סייבר?
דרישות פונקציונליות (Functional Requirements)
בקרת גישה ואימות משתמשים (Authentication)- הבטחת גישה מאובטחת למערכת באמצעות מנגנוני זיהוי מתקדמים.
- מה לא לכתוב?
“המערכת תהיה מוגנת באמצעות סיסמאות חזקות”
מה נחשב “חזק”? דרישה מעורפלת ולא ניתנת לבדיקה.“המשתמשים יזוהו באמצעות שם משתמש וסיסמה”
האם יש דרישות חוזק לסיסמה? האם יש מנגנון לנעילת חשבון?“הגישה תתבצע בצורה מאובטחת”
לא ברור איך יש להבטיח זאת, ואילו מנגנונים יש להפעיל.
- מה כן לכתוב?
“משתמשים עם הרשאת Admin יחויבו להיכנס באמצעות מנגנון MFA הכולל SMS או אפליקציית אימות“
“המערכת תהיה מוגנת אך ורק באמצעות סיסמאות חזקות באורך של 12 תווים, כוללות לפחות אות אחת גדולה, אות אחת קטנה, מספר ותו מיוחד“
נעילת חשבון לאחר מספר ניסיונות שגויים (Mitigation against Brute Force) – מנגנון הגנה מפני ניסיונות פריצה אוטומטיים.
- מה לא לכתוב?
“המערכת תחסום ניסיונות פריצה”
לא ברור איך היא תזהה ניסיון כזה ומה הפרמטרים להפעלת החסימה.“אם סיסמה הוזנה שגוי יותר מדי פעמים, המשתמש לא יוכל להיכנס”
כמה פעמים זה “יותר מדי”? ומה נדרש כדי לשחזר את החשבון?“המערכת תדע להתמודד עם ניסיונות Brute Force“
אין פירוט של המנגנונים הקיימים כדי למנוע את המתקפה.
- מה כן לכתוב?
“אם משתמש נכשל בהזנת הסיסמה 5 פעמים בטווח של 10 דקות, חשבונו ינעל אוטומטית למשך 30 דקות או עד לשחזור ידני באמצעות מנגנון אימות נוסף“
“בעת ניסיון כניסה חוזר לאחר נעילה, המשתמש יקבל הודעה כי עליו להמתין או לבצע שחזור סיסמה באמצעות אימות דו-שלבי 2FA“
הצפנת מידע בתעבורה ובמנוחה – שימוש בפרוטוקולים מאובטחים בהתאם לתקנים רלוונטיים.
- מה לא לכתוב?
“המידע יהיה מוצפן“
איזה סוג הצפנה? האם יש תקן מחייב?“נשתמש בפרוטוקולי הצפנה חזקים”
לא ברור איזה פרוטוקול נבחר ומה הקריטריונים להחלפתו בעתיד.“כל הנתונים במערכת מאובטחים”
לא מפרט כיצד ומה נחשב “מאובטח”.
- מה כן לכתוב?
“כל המידע הרגיש בתעבורה בין השרת ללקוח יוצפן באמצעות פרוטוקול TLS 1.2 או גבוה יותר.“
“נתונים רפואיים המאוחסנים במסד הנתונים יעברו הצפנת AES-256 כדי להבטיח הגנה מפני גישה לא מורשית.“
“מפתחות ההצפנה ינוהלו באמצעות HSM (Hardware Security Module) ויוחלפו באופן מחזורי כל 6 חודשים.”
דרישות לא פונקציונליות (Non-Functional Requirements)
ניהול לוגים (Logging & Auditing) – יצירת לוגים מפורטים למטרות חקירה ואכיפה.
- מה לא לכתוב?
“המערכת תשמור לוגים לכל האירועים”
מה נחשב “אירועים”? לא ברור אילו נתונים יש לשמור ולאיזו תקופה.“יהיו לוגים זמינים במקרה של בעיה”
מה כוללים הלוגים? האם הם מספקים מידע מספיק לחקירה?“המערכת תשמור היסטוריה של שגיאות”
כמה זמן? מי יכול לגשת אליהן?
- מה כן לכתוב?
“המערכת תשמור לוגים של כל ניסיונות ההתחברות, כולל תאריך, שעה, כתובת IP וסטטוס הניסיון (הצלחה/כישלון)“
“לוגים של שגיאות גישה ישמרו למשך 12 חודשים לפחות ויהיו נגישים רק למנהלי מערכת מורשים“
“המערכת תייצר התראות על 5 ניסיונות כניסה כושלים רצופים מאותה כתובת IP בטווח 10 דקות“
זמינות גבוהה והתאוששות מתקיפה (High Availability & Cyber Resilience) – מנגנונים למניעת השבתה במקרה של מתקפת סייבר
- מה לא לכתוב?
“המערכת תהיה זמינה כל הזמן”
האם היא באמת יכולה לפעול 100% מהזמן? מהם אמצעי ההתאוששות במקרה של תקלה?“המערכת תתאושש מהר אחרי מתקפה”
מה נחשב “מהר”? מה הפרוצדורה במקרה כזה?“גיבויים יתבצעו באופן קבוע”
מהי תדירות הגיבוי? כיצד ניתן לשחזר מידע?
- מה כן לכתוב?
“המערכת תכלול מנגנון failover שיאפשר חזרה לפעולה מלאה תוך 5 דקות במקרה של כשל בשרת הראשי.”
“במקרה של תקיפת מניעת שירות (DDoS), המערכת תעביר תעבורה דרך רשת הגנה מבוססת WAF (Web Application Firewall)”
“בסיס הנתונים ישמור גיבוי אוטומטי כל 24 שעות, עם אפשרות שחזור נתונים מהגיבוי האחרון בתוך 15 דקות במקרה של תקלה.”
דרישות נגזרות (Derived Requirements): ההגנה שמבוססת על הבנת איומים
כאן הדברים מתחילים להיות מורכבים יותר – אבל גם קריטיים הרבה יותר. דרישות נגזרות אינן “נולדות” באופן שרירותי, אלא מבוססות על Abuse Cases והבנה מעמיקה של האיומים הפוטנציאליים. ניתוח תרחישי שימוש לרעה – יש להגדיר מהם המסלולים שבהם תוקפים עשויים לנצל חולשות קיימות.
- מה לא לכתוב?
“המערכת תהיה מאובטחת מפני מתקפות”
לא מציין כיצד המערכת תגן על עצמה או אילו איומים נלקחו בחשבון.“משתמשים לא יוכלו לגשת לנתונים רגישים שהם לא מורשים לצפות בהם”
איך זה נאכף? אילו מגבלות מיושמות בפועל?“לא יהיה ניתן לשנות נתונים ללא הרשאה”
מה נחשב “הרשאה”? איך מתבצעת הבקרה?
- מה כן לכתוב?
אימות משתמשים: “אם משתמש מנסה לאפס סיסמה, המערכת תדרוש אימות נוסף באמצעות קוד חד-פעמי (OTP) הנשלח למכשיר רשום מראש“.
נובע מהבנה שתקיפות Phishing יכולות לנצל מנגנוני איפוס סיסמה חלשים.מניעת גישה לא מורשית לנתונים רגישים: “אם משתמש עם הרשאות רגילות מנסה לגשת לרשומת מטופל שאינה תחת אחריותו, המערכת תציג הודעת שגיאה ותתעד ניסיון הגישה ביומן האירועים“.
(נגזר מהחשש לדליפת מידע באמצעות הרשאות שאינן מוגדרות נכון).- הגנה מפני הזרקת קוד (SQL Injection): “המערכת תשתמש בפרמטרים מאובטחים (Prepared Statements) ותמנע שימוש ישיר בכניסות קלט ממשתמשים למסדי נתונים“.(נגזר מאיומים נפוצים כמו תקיפות SQL Injection, שבהן תוקפים יכולים לגשת למידע על ידי שינוי שאילתות מסד הנתונים).
כתיבת דרישות נכונה – איך מוודאים שהן באמת אפקטיביות?
כתיבת דרישות אבטחת מידע מחייבת גישה מתודולוגית ומדידה. אז איך יודעים אם הדרישה מנוסחת נכון?
- Testability – האם ניתן לבדוק את הדרישה?
“המערכת תהיה מאובטחת” – דרישה מעורפלת ולא ניתנת לבדיקה.
“המערכת תחסום חיבורי TLS שאינם TLS 1.2 ומעלה” – דרישה ברורה שניתן לבדוק.
- מה לא לכתוב?
- “המערכת תהיה מאובטחת” – דרישה מעורפלת ולא ניתנת לבדיקה.
- מה כן לכתוב?
- “המערכת תחסום חיבורי TLS שאינם TLS 1.2 ומעלה” – דרישה ברורה שניתן לבדוק.
כתיבת דרישות אבטחת מידע מחייבת גישה מתודולוגית ומדידה. אז איך יודעים אם הדרישה מנוסחת נכון?
- Measurability – האם ניתן למדוד את האפקטיביות של הפתרון?
- Completeness – האם הדרישות מכסות את כל נקודות החולשה, או שמיקדנו אותן רק ב-API ושכחנו את הלוגים?
- Clarity & Consistency – האם כל המעורבים (מפתחים, QA, מנהלי רגולציה) מבינים את הדרישה, והיא מנוסחת בצורה ברורה ואחידה?
כדי לייצר מערכת רפואית מאובטחת – חייבים להתחיל בכתיבת דרישות מדויקות
יותר מדי פעמים מסמכי SRS כוללים דרישות אבטחה כלליות ולא ממוקדות, במקום דרישות מחייבות שמבוססות על ניתוח איומים, תקנים רגולטוריים והערכת סיכונים. אבטחת מידע לא יכולה להיות “נספח” – היא חייבת להיות חלק אינטגרלי מהדרישות כבר בשלב התכנון.
ב-MedDev Soft אנחנו מתמחים בכתיבת SRS שמטמיעים אבטחת מידע כחלק אינהרנטי מהמערכת, בהתאמה מלאה לדרישות ה-FDA ועם דרישות ניתנות לבדיקה (Testable Requirements).
רוצים מסמכי SRS שמובילים לאבטחת מידע אמיתית? צרו איתנו קשר עוד היום.
