कॉन्टेंट प्रबंधन

कॉन्टेंट मैनेजमेंट policies, कॉन्टेंट मैनेजमेंट switches का एक सेट हैं जिन्हें किसी विशेष file type पर लागू किया जा सकता है।

कॉन्टेंट मैनेजमेंट switch का उपयोग किसी file element type और उससे संबंधित action की पहचान करने के लिए किया जाता है।

कॉन्टेंट मैनेजमेंट setting किसी विशेष कॉन्टेंट मैनेजमेंट switch के लिए Glasswall द्वारा की जाने वाली action को निर्दिष्ट करती है। प्रत्येक कॉन्टेंट मैनेजमेंट switch को तीन settings में से किसी एक पर सेट किया जा सकता है:

• Allow - Glasswall Embedded Engine किसी भी संबंधित file element types को process करता है और वे regenerated file में बने रहते हैं। संबंधित structure को Analysis report में Allowed Item के रूप में log किया जाता है।

• Disallow - यदि file में संबंधित file element types में से किसी की पहचान होती है, तो Glasswall Embedded Engine file को non-conforming के रूप में पहचानता है और file को regenerate नहीं किया जाएगा। संबंधित structure को Analysis report में Issue Item के रूप में log किया जाता है।

• Sanitise - यदि file में संबंधित file element types में से किसी की पहचान होती है, तो Glasswall Embedded Engine उन्हें regenerated document से हटा देता है। संबंधित structure को Analysis report में Sanitisation Item के रूप में log किया जाता है।

कॉन्टेंट प्रबंधन रिपोर्टिंग​

निम्नलिखित अनुभाग दिखाते हैं कि कॉन्टेंट मैनेजमेंट switch के नियंत्रण में रहने वाला content, content switch setting के आधार पर XML Analysis report में कैसे प्रस्तुत किया जाता है।

Allow​

यह metadata युक्त Word (.doc) Binary file के लिए XML report का एक अंश है। कॉन्टेंट मैनेजमेंट switch metadata को allow पर सेट किया गया है।

    <gw:Camera cameraName="wordConfig">
    <gw:ContentSwitch>
        <gw:ContentName>metadata</gw:ContentName>
        <gw:ContentValue>allow</gw:ContentValue>
    </gw:ContentSwitch>
    ...
    <gw:AllowedItems itemCount="1">
        <gw:AllowedItem>
            <gw:TechnicalDescription>Metadata detected in #05SummaryInformation</gw:TechnicalDescription>
            <gw:InstanceCount>1</gw:InstanceCount>
            <gw:TotalSizeInBytes>4096</gw:TotalSizeInBytes>
        </gw:AllowedItem>
    </gw:AllowedItems>

अस्वीकार करें​

यह उस Word (.doc) Binary फ़ाइल के XML report का एक अंश है जिसके भीतर metadata है। content management switch metadata को disallow पर सेट किया गया है। Protect Mode में, इससे फ़ाइल को non-conforming के रूप में चिह्नित किया जाएगा।

    <gw:Camera cameraName = "wordConfig">
    <gw:ContentSwitch>
        <gw:ContentName>metadata</gw:ContentName>
        <gw:ContentValue>disallow</gw:ContentValue>
    </gw:ContentSwitch>
    ...
    <gw:IssueItem>
        <gw:TechnicalDescription> Metadata detected in #05SummaryInformation</gw:TechnicalDescription>
        <gw:IssueId>96</gw:IssueId>
        <gw:InstanceCount>1</gw:InstanceCount>
        <gw:RiskLevel>Medium</gw:RiskLevel>
    </gw:IssueItem>

Sanitise​

यह उस Word (.doc) Binary फ़ाइल के XML report का एक अंश है जिसके भीतर metadata है। content management switch metadata को sanitise पर सेट किया गया है। Protect Mode में, इसका परिणाम regenerated file से metadata हटाए जाने के रूप में होगा।

    <gw:Camera cameraName = "wordConfig">
    <gw:ContentSwitch>
        <gw:ContentName>metadata</gw:ContentName>
        <gw:ContentValue>sanitise</gw:ContentValue>
    </gw:ContentSwitch>
    ...
    <gw:SanitisationItem>
        <gw:TechnicalDescription>Metadata detected in #05SummaryInformation</gw:TechnicalDescription>
        <gw:InstanceCount>1</gw:InstanceCount>
        <gw:TotalSizeInBytes>4096</gw:TotalSizeInBytes>
    </gw:SanitisationItem>

Content management policies​

ये उपलब्ध content management policies हैं:

नोट: xlsConfig, pptConfig और wordConfig content management policies, Office Open XML और Office Binary दोनों फ़ाइल प्रकारों को कवर करती हैं।

उपलब्ध content management switches और लागू फ़ाइल प्रकार नीचे दी गई तालिका में दिखाए गए हैं:

प्रत्येक फ़ॉर्मैट के लिए वर्तमान में उपलब्ध switches नीचे दी गई तालिका में दर्शाए गए हैं:

[ *]: Editor के "enablerebuild" (default) mode या केवल Rebuild में उपलब्ध content management switch [ †]: Editor के "editoronly" mode में उपलब्ध content management switch, जिसे केवल Export/Import feature के साथ उपयोग किया जा सकता है

किसी विशिष्ट फ़ाइल फ़ॉर्मैट के लिए content management type द्वारा प्रदर्शित न किए गए सभी content types को यदि उन्हें malicious के रूप में पहचाना जाता है, तो Glasswall engine द्वारा स्वचालित रूप से remediated किया जाएगा।

Embedded files​

"Embedded Files" content management type उन non-image file formats पर लागू होता है जो किसी अलग container file के भीतर स्थित होते हैं। MS-Office formats के लिए, embedded files की policy अलग तरीके से लागू की जाती है, यह इस बात पर निर्भर करता है कि विचाराधीन फ़ाइल engine द्वारा supported और accessible है या नहीं:

Microsoft Office files के लिए content management policy के अनुसार embedded file पर लागू की गई कार्रवाई:

नीचे दी गई तालिका यह बताती है कि प्रत्येक container फ़ाइल प्रकार के भीतर कौन-से embedded फ़ाइल फ़ॉर्मैट समर्थित (✓) हैं और कौन-से नहीं (✗)।

[†]: container फ़ॉर्मैट द्वारा अनुमत नहीं

[‡]: Embedded Files switch द्वारा नहीं हटाया जाता, लेकिन All Actions switch द्वारा हटाया जा सकता है। Embedded फ़ाइल को प्रोसेस किए बिना पुनर्जनित किया जाता है।

⚠️ नोट: फ़ाइलों के मूल और sanitised संस्करणों के बीच दृश्य अखंडता बनाए रखने के लिए, असमर्थित embedded फ़ाइलों के संबद्ध दृश्य तत्व (जैसे thumbnails और blip references) sanitisation के दौरान नहीं हटाए जाते। इससे यह सुनिश्चित होता है कि post-processed फ़ाइलें अपने मूल संस्करणों के साथ दृश्य रूप से सुसंगत बनी रहें।

Embedding depth support​

Embedded Engine, OfficeXML फ़ाइलों के भीतर nested embedded content के अधिकतम नौ स्तरों का समर्थन करता है। यदि इस गहराई से आगे कोई embedded फ़ाइलें मिलती हैं, तो container फ़ाइल अस्वीकृत कर दी जाएगी, और यह दर्शाते हुए एक Issue Item उठाया जाएगा कि अधिकतम recursion सीमा पार हो गई है। यह सीमा केवल nesting की गहराई पर लागू होती है, और एक ही स्तर पर मौजूद कई embedded फ़ाइलें इसमें नहीं गिनी जातीं।

Embedded images​

इमेज फ़ाइल फ़ॉर्मैट्स के लिए, "Embedded Images" content management switch का उपयोग किया जाना चाहिए। switch setting के आधार पर इसका व्यवहार निम्नलिखित है:

content management policy के अनुसार embedded image पर लागू की गई कार्रवाई:

[ ^* ] : यदि engine filetype को पहचान नहीं पाता है, तो असमर्थित embedded images को इसके बजाय "embedded_files" switch द्वारा संभाला जा सकता है

The table below shows which image formats we attempt to regenerate (✓) when "Embedded Images" is set to sanitise versus those which are removed (✗):

[⸸]: container file द्वारा एक अलग format में convert किया जाएगा

कृपया ध्यान दें कि जब "Embedded Images" को "Disallow" पर सेट किया जाता है, तो मिलने वाली कोई भी images containing file के अस्वीकार होने का कारण बनेंगी। इसमें containing या embedded documents के thumbnails भी शामिल हैं और इसलिए यह "Embedded File" content management switch को supersede कर सकता है।

Macros​

MS Office files के लिए macros content switch, Microsoft Visual Basic for Applications (VBA) और Excel 4.0 macros दोनों पर लागू होता है।

Microsoft Visual Basic for Applications​

VBA macros, Visual Basic प्रोग्रामिंग भाषा में लिखे जाते हैं और किसी भी MS Office file format में शामिल किए जा सकते हैं। VBA macros के प्रबंधन को निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - फ़ाइलों से VBA macros हटा दिए जाते हैं।
• Disallow - VBA macros निषिद्ध हैं। यदि कोई पाया जाता है, तो उसे शामिल करने वाली फ़ाइल अस्वीकार कर दी जाती है।
• Allow - VBA macros को प्रोसेस किया जाता है और यदि वे specification के अनुरूप हों, तो उन्हें शामिल करने वाली फ़ाइल के हिस्से के रूप में पुनर्जनित किया जाता है।

Export mode का व्यवहार​

Export mode में, VBA Project Binaries recursion limit में गिने जाते हैं। इसका अर्थ है कि यदि सबसे गहराई में एम्बेड की गई फ़ाइल में VBA macro हो, तो अधिकतम nesting depth घटकर eight हो जाती है।

Excel 4.0 macros​

Excel 4.0 macros, XLSX और XLS फ़ाइलों में शामिल एक legacy feature हैं। Excel 4.0 macros वाली XLSX फ़ाइलें ".xlsm" file extension का उपयोग करके सहेजी जाएँगी, और यदि इस extension को बदला जाता है तो त्रुटि उत्पन्न होगी। Excel 4.0 macros के प्रबंधन को निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - XLS फ़ाइलों में, फ़ाइल को ब्लॉक कर दिया जाएगा और Excel 4.0 Macro found: Not supported को issue item के रूप में रिपोर्ट किया जाएगा। XLSX/XLSM फ़ाइलों में, macros वाली sheets को दस्तावेज़ से हटा दिया जाएगा और sanitisation item के रूप में रिपोर्ट किया जाएगा। यदि इससे फ़ाइल malformed हो जाती है (अर्थात visible sheets की संख्या शून्य हो जाती है), तो फ़ाइल अस्वीकार कर दी जाएगी और उपयुक्त issue item रिपोर्ट किया जाएगा।
• Disallow - Excel 4.0 macros निषिद्ध हैं। यदि कोई पाया जाता है, तो उसे शामिल करने वाली फ़ाइल अस्वीकार कर दी जाती है।
• Allow - XLS फ़ाइलों में, फ़ाइल को ब्लॉक कर दिया जाएगा और Excel 4.0 Macro found: Not supported को issue item के रूप में रिपोर्ट किया जाएगा। XLSX/XLSM फ़ाइलों में, फ़ाइल को macros यथावत रखते हुए पुनर्जनित किया जाएगा।

Metadata​

OOXML में, metadata उस जानकारी को संदर्भित करता है जो किसी दस्तावेज़ की सामग्री, संरचना और गुणों का वर्णन करती है, लेकिन दस्तावेज़ की मुख्य सामग्री का हिस्सा नहीं होती। OOXML दस्तावेज़ों में metadata मुख्य रूप से docProps directory के भीतर स्थित XML files में संग्रहीत होता है:

1. core.xml: Dublin Core Metadata Element Set पर आधारित मुख्य properties शामिल करता है।
2. app.xml: Microsoft Office applications के लिए विशिष्ट विस्तारित properties शामिल करता है।
3. custom.xml: कस्टम properties शामिल हैं।

OOXML metadata का प्रबंधन निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - metadata हटाकर फ़ाइल को फिर से जनरेट किया जाता है (वर्तमान में sanitise की जाने वाली सभी properties के लिए नीचे देखें)
• Disallow - Metadata निषिद्ध है। यदि कोई metadata (नीचे सूचीबद्ध properties) पाया जाता है, तो संबंधित फ़ाइल अस्वीकार कर दी जाती है।
• Allow - फ़ाइल को प्रोसेस किया जाता है, और metadata को फिर से जनरेट किया जाता है।

'metadata' content management switch के हिस्से के रूप में, हम वर्तमान में निम्नलिखित को sanitise करते हैं:

• core.xml: title, subject, creator, keywords, description, lastModifiedBy, revision, lastPrinted, created, modified, category, contentStatus, language, और version.
• app.xml: manager, company, और hyperlinkBase
• custom.xml: OOXML document में जोड़ी गई कोई भी custom properties.

OfficeXML (DOCX, XLSX, PPTX) के लिए विशिष्ट switches​

छिपा हुआ डेटा​

Office फ़ाइल फ़ॉर्मैट वैध रूप से टेक्स्ट या डेटा को "छिपाने" के कई अलग-अलग तरीके प्रदान करते हैं, जिनमें पूरी Excel sheets, PowerPoint slides, या Word document में टेक्स्ट की पंक्तियाँ शामिल हैं। Glasswall engine content management switch setting के आधार पर hidden data को निम्नलिखित तरीकों से संभालता है:

• Sanitise - सभी hidden data को "unhidden" करके फ़ाइल को फिर से जनरेट किया जाता है, ताकि वह उपयोगकर्ता को पूरी तरह दिखाई दे।
• Disallow - Hidden data निषिद्ध है। यदि कोई hidden data पाया जाता है, तो संबंधित फ़ाइल अस्वीकार कर दी जाती है।
• Allow - किसी भी hidden data को फिर से जनरेट किया जाता है और वह छिपा रहता है।

नोट: इस content management setting के संदर्भ में, “Hidden Data” का अर्थ Office 2007 files में डेटा को अस्पष्ट या गहराई में छिपाने के विभिन्न तरीकों से नहीं है। बल्कि, यह विशेष रूप से Office 2007 GUI में आसानी से उपलब्ध डेटा छिपाने की विधियों को संदर्भित करता है। Obfuscated या concealed data का प्रबंधन उपयोग की गई विधि से संबंधित policy setting द्वारा किया जाता है; उदाहरण के लिए, metadata document के metadata में शामिल free-text fields के भीतर छिपाए गए डेटा को हटा देगा।

ट्रैक किए गए परिवर्तन​

tracked_changes content management switch DOCX और XLSX फ़ाइलों में "Track Changes" functionality द्वारा जोड़ी गई सामग्री को संदर्भित करता है, जिसे "revisions" भी कहा जाता है। इनमें दस्तावेज़ के पिछले संस्करणों से संबंधित ऐतिहासिक डेटा हो सकता है, जिसमें योगदानकर्ताओं के नाम और ऐसी सामग्री के रिकॉर्ड शामिल हैं जिन्हें बाद में हटाया गया हो या अस्पष्ट किया गया हो। tracked changes का प्रबंधन निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - सारा ऐतिहासिक डेटा हटा दिया जाता है और "Track Changes" अक्षम कर दिया जाता है। पुनर्जनित दस्तावेज़ मूल दस्तावेज़ की अंतिम स्थिति के समकक्ष होगा।
• Disallow - tracked changes निषिद्ध हैं। यदि फ़ाइल में पिछले revisions या tracked changes के अभी भी मौजूद होने का कोई भी प्रमाण मिलता है, तो फ़ाइल अस्वीकार कर दी जाएगी।
• Allow - फ़ाइल को सभी ऐतिहासिक changes, revisions और tracked changes यथावत रखते हुए पुनर्जनित किया जाता है।

स्लाइड नोट्स​

slide_notes content management switch PPTX फ़ाइलों में "Notes" functionality द्वारा जोड़ी गई सामग्री को संदर्भित करता है, जिसे "slide notes" (और/या "speaker notes") भी कहा जाता है। Glasswall engine content management switch setting के कॉन्फ़िगरेशन के आधार पर इन slide notes को निम्नलिखित तरीकों से संभालता है:

• Sanitise - फ़ाइल को सभी slide notes हटाकर पुनर्जनित किया जाता है।
• Disallow - slide notes निषिद्ध हैं। यदि कोई भी slide notes मिलते हैं, तो संबंधित फ़ाइल अस्वीकार कर दी जाती है।
• Allow - किसी भी slide notes को पुनर्जनित किया जाता है और वे फ़ाइल में बने रहते हैं।

इन-टेक्स्ट टिप्पणियाँ​

in_text_comments switch DOCX फ़ाइलों में "In-Text Comments" functionality द्वारा जोड़ी गई सामग्री को संदर्भित करता है। switch का प्रबंधन निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - In-Text Comment को core.xml में पाई गई संबंधित document metadata के साथ हटा दिया जाता है।
• Disallow - In-Text Comment निषिद्ध है। in-text comment वाला कोई भी DOCX फ़ाइल को पुनर्जनित होने से रोक देगा।
• Allow - फ़ाइल को DOCX फ़ाइल में मौजूद In-Text Comment के साथ पुनर्जनित किया जाता है।

नोट: जब in_text_comments sanitise को allow पर सेट किया जाता है और metadata switch को sanitise पर सेट किया जाता है, तब पुनर्जनित फ़ाइल में in-text comment मौजूद होगा लेकिन उसमें कोई डेटा नहीं होगा, क्योंकि metadata switch core.xml फ़ाइल से संबंधित description को sanitise कर देता है।

Doc-Variables​

doc_variables स्विच DOCX फ़ाइलों में "Document Variables" कार्यक्षमता द्वारा जोड़ी गई सामग्री को संदर्भित करता है। स्विच के प्रबंधन को निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - फ़ाइल को सभी document variables हटाकर पुनर्जनित किया जाता है।
• Disallow - Document variables निषिद्ध हैं। document variables वाली कोई भी DOCX फ़ाइल के पुनर्जनन को अवरुद्ध कर देगी।
• Allow - फ़ाइल को DOCX फ़ाइल में मौजूद document variables के साथ पुनर्जनित किया जाता है।

Web Video Extension​

web_video_extension स्विच DOCX फ़ाइलों में "Web Videos Extension" कार्यक्षमता का उपयोग करके जोड़ी गई सामग्री को संदर्भित करता है। स्विच के प्रबंधन को निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - फ़ाइल को सभी web video extensions हटाकर पुनर्जनित किया जाता है।
• Disallow - web video extension का उपयोग निषिद्ध है। web video extensions वाली कोई भी DOCX फ़ाइल के पुनर्जनन को अवरुद्ध कर देगी।
• Allow - फ़ाइल को DOCX फ़ाइल में शामिल web video extension के साथ पुनर्जनित किया जाता है।

Header और Footer​

headers_footers स्विच DOCX में किसी पृष्ठ के Header या Footer अनुभागों में जोड़ी गई सामग्री को संदर्भित करता है। यह सामग्री पहले पृष्ठ, सम पृष्ठों और विषम पृष्ठों पर अलग हो सकती है, या पूरे दस्तावेज़ में समान हो सकती है। स्विच के प्रबंधन को निम्नानुसार कॉन्फ़िगर किया जा सकता है:

• Sanitise - फ़ाइल को सभी header और footer सामग्री हटाकर पुनर्जनित किया जाएगा।
• Disallow - headers और footers का उपयोग निषिद्ध है। headers या footers में से किसी एक को भी शामिल करने वाली कोई भी DOCX फ़ाइल के पुनर्जनन को अवरुद्ध कर देगी।
• Allow - फ़ाइल को DOCX फ़ाइल में शामिल headers और footers के साथ पुनर्जनित किया जाता है।

केवल PDF के लिए स्विच​

डिजिटल हस्ताक्षर​

अवलोकन PDF फ़ाइलों में Digital Signatures और AcroForms हो सकते हैं, और कुछ प्रकार के AcroForms में डिजिटल हस्ताक्षर हो सकते हैं। जहाँ डिजिटल हस्ताक्षरों का उपयोग किसी दस्तावेज़ की प्रामाणिकता और अखंडता सत्यापित करने के लिए किया जाता है, वहीं AcroForms इंटरैक्टिव फ़ॉर्म फ़ील्ड्स के लिए संरचनात्मक आधार प्रदान करते हैं। जब PDF में डिजिटल हस्ताक्षर मौजूद होता है, तब AcroForm में स्वयं हस्ताक्षर का दृश्य प्रतिनिधित्व होता है।

जब डिजिटल हस्ताक्षर शामिल करने वाली PDF फ़ाइलों को प्रोसेस किया जाता है, तो Glasswall CDR engine एक sanitisation प्रक्रिया लागू करता है, जिसे सक्रिय और/या संभावित रूप से जोखिमपूर्ण सामग्री हटाते हुए दृश्य अखंडता बनाए रखने के लिए डिज़ाइन किया गया है।

CDR Engine डिजिटल हस्ताक्षरों को कैसे संभालता है दस्तावेज़ की सुरक्षा और एकरूपता दोनों सुनिश्चित करने के लिए, Glasswall CDR engine sanitisation के दौरान निम्नलिखित कार्रवाइयाँ करता है:

• क्रिप्टोग्राफ़िक हस्ताक्षर डेटा हटाता है, जिसमें कोई भी embedded certificates, validation logic, या scripts शामिल हैं।
• signature-related metadata और interactive behavior को हटाता है ताकि execution pathways या संभावित exploits समाप्त किए जा सकें।
• signature widget की दृश्य उपस्थिति को संरक्षित रखता है, जैसे signature image, signer name, और date/time text। यह PDF की static content layer में इसे flatten करके प्राप्त किया जाता है।

ऑडिटेबिलिटी और chain of custody​

सुरक्षित परिवेशों में traceability और accountability का समर्थन करने के लिए, Glasswall CDR इंजन इनपुट और आउटपुट दोनों फ़ाइलों के क्रिप्टोग्राफ़िक hash रिकॉर्ड करता है। इससे एक system integrator को यह सक्षम होता है:

• hash तुलना के माध्यम से फ़ाइल provenance सत्यापित करना।
• यह आश्वासन प्रदान करना कि, जहाँ कोई digital signature अब वैध नहीं है, वहाँ chain of custody बनाए रखी जाती है और उसे सिद्ध किया जा सकता है।