აუდიტის ორი კითხვა მსგავსად ჟღერს და სხვადასხვა ტიპის მტკიცებულებას მოითხოვს. რომელი სესია დაუკავშირდა ამ მისამართს, პასუხი კავშირისა და ნაკადის ჩანაწერებიდან შეიძლება გაიცეს. რომელმა ადამიანმა გახსნა ეს გვერდი, ჩვეულებრივ არა, სულ მცირე არა ამ ჩანაწერებიდან. შემგროვებლის არჩევა კითხვის არჩევამდე ის გზაა, რომლითაც ქსელის გუნდი ჰოსტის სახელს დათვალიერების ისტორიად წარადგენს.

დაიწყეთ იმ მოვლენით, რომელიც აუდიტმა უნდა დაადგინოს

დაწერეთ კითხვა წინადადებად სუბიექტით, ზმნითა და დროით. მხოლოდ ეს დისციპლინა ამჟღავნებს სესიის ჩანაწერსა და გვერდის ნახვას შორის არსებულ უფსკრულს. სესიის ჟურნალი ადგენს, რომ იდენტობა მიღებულ იქნა გარკვეული ინტერვალისთვის, მინიჭებული მისამართით და დაფიქსირებული პოლიტიკის მიხედვით, და მას არ შეუძლია დაადგინოს, ვინ რომელი გვერდი წაიკითხა, რადგან მოთხოვნა არასდროს უნახავს.

დაარქვით დაკვირვებას სახელი შეგროვების დაპროექტებამდე. ველი, რომელიც მონახულებული საიტის სახელს ატარებს, მაგრამ რეალურად გადაწყვეტილ სახელს ინახავს, მომავალი შეცდომაა და არა მოხერხებულობა. ველების სახელები უფრო დიდხანს ცოცხლობს, ვიდრე ის ადამიანები, ვინც ისინი აირჩიეს, ამიტომ აირჩიეთ ისეთები, რომლებიც მტკიცებულებას აღწერს და არა დასკვნას.

რისი მხარდაჭერა შეუძლია და არ შეუძლია თითოეულ ჩანაწერს

ჩანაწერის ოთხი ტიპი გვხვდება თითქმის ყველა აუდიტის პროექტში და თითოეული სხვა კითხვას პასუხობს. შეინახეთ ისინი ცალ-ცალკე როგორც ანგარიშში, ასევე დამუშავების ნაკადში, რადგან მათი შერევა არის ის, რის გამოც დასაცავი დასკვნა სამარცხვინო ხდება.

The question being askedRecord that can answer itWhat that record provesWhat still needs a join
Was this address contacted?Flow recordThe connection five-tuple and when it was seenWhich session held the address at that moment
Which account held that address?Session logWhich identity authenticated and the tunnel address it receivedWhich device or person used that account
Was this name looked up?Resolver queryThat this resolver was asked for this nameWhether a page was fetched, and by whom
Was this page viewed?Proxy or application transactionThe request and identity recorded inside that application's scopeTraffic outside that application's visibility
Who was the person?None of the four on its ownAn account in use, at bestA named human, whenever accounts are shared

წაიკითხეთ ბოლო სვეტი ისე ყურადღებით, როგორც შუა. ნაკადის ჩანაწერი აღწერს მისამართებსა და პორტებს, და მისამართის უკუძებნა არ აღადგენს იმ სახელს, რომელიც ბრაუზერმა გამოიყენა, რადგან ერთ მისამართს შეიძლება მრავალი დაუკავშირებელი საიტი მასპინძლობდეს. გამხსნელის მოთხოვნა ამტკიცებს, რომ კითხვა დაისვა, და არა ის, რომ გვერდი იქნა ნაჩვენები. TLS მოლაპარაკების დროს ხილული ჰოსტის სახელი ასევე არ არის დაშიფრული მოთხოვნის გზა.

თითოეული მათგანი რეალური დაკვირვებაა და არც ერთი მათგანი არ არის ის დაკვირვება, რომელსაც ადამიანები ვარაუდობენ. ბრაუზერი, რომელიც საკუთარ დაშიფრულ გამხსნელზე ამტკიცებს, დაკვირვების ზონის გარეთ დგას და ანალიზი ვერ დაიბრუნებს იმას, რაც ჟურნალს არასდროს უნახავს. ეს უფსკრული ანგარიშში გამოცხადებულ საზღვრად უნდა იყოს და არა სქოლიოდ.

წინასწარი მოთხოვნები და ქეშირებული პასუხები

ბრაუზერები სახელებს წინასწარ ხსნიან, ზოგჯერ არაფრის ჩატვირთვის გარეშე. ისინი ასევე პასუხობენ ქეშიდან იმ გამხსნელისთვის ახალი მოთხოვნის გაგზავნის გარეშე, რომელსაც თქვენ აკვირდებით, რაც ნიშნავს, რომ მოთხოვნის არქონა ვიზიტის არქონა არ არის. ორივე ქცევა ამტვრევს უბრალო განტოლებას DNS ჟურნალსა და დათვალიერების ისტორიას შორის.

DNS HTTPS-ზე ამატებს მეორე საზღვარს: საკუთარი გამხსნელის მქონე ბრაუზერი ან სტუმარი აპლიკაცია ორგანიზაციის აღრიცხვას არასდროს არაფერს ეკითხება. ზუსტი ტრანზაქციები მოდის მხოლოდ თავად აპლიკაციის მოვლენებიდან ან იმ პროქსიდან, რომლის ჟურნალირებასაც თქვენ ღიად უჭერთ მხარს. ჩვეულებრივი HTTPS CONNECT გვირაბი პროქსის ტოვებს მის შიგნით არსებული გვერდის ბილიკების ყოველგვარი ხედვის გარეშე. ქსელის ფლობა ნებართვა არ არის, ჩუმად შეიცვალოს აპლიკაციის ნდობის მოდელი.

მისამართი სესიას ეკუთვნის, არა ადამიანს

გვირაბის დიაპაზონიდან მისამართის მქონე ნაკადის ჩანაწერი საწყისი წერტილია და არა პასუხი. დააკავშირეთ ეს მისამართი და დროის ნიშა იმ მომენტში აქტიურ სესიის გამოყოფასთან, რადგან ეს მისამართი საათში შეიძლება სხვა სესიას მიეკუთვნოს. სტატიკური მისამართება ამ კავშირის შენარჩუნების ერთი გზაა და არა ერთადერთი.

სადაც თარგმანის საფეხური რამდენიმე მოწყობილობას აერთიანებს ერთ წყარო მისამართში სენსორის ზემოთ, შეერთებას მხოლოდ საერთო კარიბჭის სესიის დასახელება შეუძლია. საერთო ანგარიში ან რამდენიმე ადამიანის მიერ გამოყენებული სერტიფიკატი ზღუდავს მიკუთვნებას, რაოდენ სრულიც არ უნდა ჩანდეს ქსელური მონაცემები. ორივე ანგარიშში საზღვრად უნდა იყოს და არა მოგვიანო დათქმად.

ჩაწერეთ დროის სარტყელი, საათის წყარო, დაკვირვების წერტილი და მათ შორის ყოველი თარგმანის საზღვარი. არქონა იმავე ზრუნვას იმსახურებს, რასაც არსებობა, რადგან დაკარგული ჩანაწერი შეიძლება ნიშნავდეს, რომ ნაკადის ჩანაწერს ვადა გაუვიდა, სენსორმა პაკეტი არასდროს არ ნახა ან აპლიკაციის ჟურნალი გამორთული იყო.

დააპროექტეთ გამოცხადებული მიზნისთვის, შემდეგ დაამტკიცეთ ნაკადი

კითხვის დაფიქსირების შემდეგ განსაზღვრეთ, რომელი ველებია საჭირო, ვის შეუძლია მათი წაკითხვა და რამდენ ხანს ინახება ისინი. მეტის შეგროვება იმიტომ, რომ შენახვა იაფია, ქმნის ვალდებულებას, რომელიც უფრო დიდხანს ცოცხლობს, ვიდრე გამოძიება. კონფიდენციალურობის მოდელი RFC 6973-ში კორელაციას, არასწორ მიკუთვნებას და ზედმეტ შეგროვებას დიზაინის პრობლემებად განიხილავს და არა შემდგომ ფიქრებად.

დაიცავით რუკების შესაბამისობა და ჩანაწერები ერთ ობიექტად, რადგან თითოეული ცალკე გაცილებით ნაკლებად მგრძნობიარეა, ვიდრე წყვილი. შემდეგ გადაამოწმეთ პროექტი იმ აქტივობასთან, რომლის გენერირებაც ნებადართული გაქვთ და უკვე გესმით, იმ უმცირესი მოთხოვნით, რომელსაც ანგარიში დაეყრდნობა. ნაკადი, რომელსაც ცნობილი მოვლენის რეპროდუცირება არ შეუძლია, უცნობსაც ვერ გაამრავლებს. მოახსენეთ მოვლენა, რომელსაც მტკიცებულებები უჭერენ მხარს, იმ სიტყვებით, რომლებსაც მტკიცებულებები უშვებენ, და დიდ დასკვნამდე მისვლა თავად მკითხველს დაუტოვეთ.

დაწერეთ საზღვრები დასკვნის გვერდით: რა დაკავშირდა, რა ითარგმნა და რომელი ჟურნალი დარჩა ჩუმად. დასკვნა, რომელიც საკუთარ საზღვრებს აცხადებს, უძლებს იმ განხილვას, რომელსაც თავდაჯერებული შეჯამება ვერ უძლებს. ეს არის განსხვავება მტკიცებულებასა და მტკიცებულებაზე მოთხრობილ ამბავს შორის.

დაკავშირებული სტატიები