ਕਾਰਗਰ AI ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਅਸੀਂ ਵਿੱਤੀ ਸੇਵਾਵਾਂ ਵਿੱਚ ਗਾਹਕਾਂ ਲਈ ਬਣੀ AI ਐਪ ਦੀ ਜਾਂਚ ਅਤੇ ਪਰਖ ਕਰਨ ਵਾਸਤੇ ਹਮਲਾਵਰਾਂ ਵਾਂਗ ਕੰਮ ਕਰਦਿਆਂ ਰੈਡ ਟੀਮਿੰਗ ਕੀਤੀ। ਸਾਡੀਆਂ ਖੋਜਾਂ ਉਨ੍ਹਾਂ ਸਭ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ ਜੋ LLM ਨਾਲ ਚੱਲਣ ਵਾਲੀਆਂ ਅਜਿਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੈਨਾਤ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਸੁਰੱਖਿਆ ਲਾਜ਼ਮੀ ਹੈ।
ਰੈਡ ਟੀਮਿੰਗ ਵਿੱਚ ਜਾਣਬੁੱਝ ਕੇ ਆਪਣੇ AI ਸਿਸਟਮ ਨੂੰ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਅਸਲ ਹਮਲਾਵਰ ਦੇ ਲੱਭਣ ਤੋਂ ਪਹਿਲਾਂ ਕਮਜ਼ੋਰੀਆਂ ਦੂਰ ਕੀਤੀਆਂ ਜਾ ਸਕਣ। ਵਿੱਤੀ ਸੇਵਾਵਾਂ ਵਿੱਚ ਜੋਖਮ ਖ਼ਾਸ ਤੌਰ ’ਤੇ ਵੱਡੇ ਹਨ: AI ਐਪਲੀਕੇਸ਼ਨਾਂ ਗਾਹਕ ਡਾਟੇ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ, ਲੈਣ-ਦੇਣ ਸੰਸਾਧਿਤ ਕਰਦੀਆਂ ਅਤੇ ਵਿੱਤੀ ਜਾਣਕਾਰੀ ਦਿੰਦੀਆਂ ਹਨ। ਨਾਕਾਮੀ ਦੇ ਨਤੀਜੇ ਖ਼ਰਾਬ ਵਰਤੋਂਕਾਰ ਅਨੁਭਵ ਤੋਂ ਲੈ ਕੇ ਨਿਯਮਾਂ ਦੀ ਉਲੰਘਣਾ, ਵਿੱਤੀ ਨੁਕਸਾਨ ਅਤੇ ਬ੍ਰਾਂਡ ਨੂੰ ਨਾ ਪੂਰਾ ਹੋਣ ਵਾਲਾ ਨੁਕਸਾਨ ਤੱਕ ਹੋ ਸਕਦੇ ਹਨ।
ਸਾਡਾ ਟੀਚਾ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਛੇਤੀ ਲੱਭਣਾ, ਯਥਾਰਥਵਾਦੀ ਹਮਲਾ-ਤਰੀਕਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਅਤੇ ਸੰਗਠਨ ਨੂੰ AI ਸੁਰੱਖਿਆ ਸਬੰਧੀ ਉਨ੍ਹਾਂ ਉਮੀਦਾਂ ’ਤੇ ਖਰਾ ਉਤਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਾ ਸੀ ਜਿਨ੍ਹਾਂ ਨੂੰ ਨਿਯਾਮਕ ਬਹੁਤ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਂਦੇ ਹਨ।
ਇੱਥੇ ਇੱਕ ਫ਼ਰਕ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਹੈ: ਜੇਲ੍ਹਬ੍ਰੇਕ ਮੂਲ ਮਾਡਲ ਦੇ ਸੁਰੱਖਿਆ ਫਿਲਟਰਾਂ ’ਤੇ ਹਮਲਾ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਪ੍ਰੌੰਪਟ ਇੰਜੈਕਸ਼ਨ ਗ਼ੈਰ-ਭਰੋਸੇਯੋਗ ਵਰਤੋਂਕਾਰ ਇਨਪੁੱਟ ਨੂੰ ਡਿਵੈਲਪਰ ਦੇ ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਂਪਟ ਨਾਲ ਜੋੜ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ’ਤੇ ਹੀ ਹਮਲਾ ਕਰਦਾ ਹੈ। ਪ੍ਰੌੰਪਟ ਇੰਜੈਕਸ਼ਨ ਵੱਧ ਜੋਖਮ ਪੈਦਾ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਆਮ-ਉਦੇਸ਼ ਵਾਲੇ ਮਾਡਲ ਦੀ ਬਜਾਏ ਤੁਹਾਡੇ ਸਿਸਟਮ ਅਤੇ ਉਸ ਵੱਲੋਂ ਵਰਤੇ ਜਾਂਦੇ ਗੁਪਤ ਡਾਟੇ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ।
ਸਾਡੀ ਜਾਂਚ ਦੇ ਪਹਿਲੇ ਦੌਰ ਵਿੱਚ ਇਨ੍ਹਾਂ ਖੇਤਰਾਂ ਦੇ ਲਗਭਗ 750 ਟੈਸਟ ਸ਼ਾਮਲ ਸਨ:
ਵੱਖ-ਵੱਖ ਸੈਸ਼ਨਾਂ ਵਿਚਕਾਰ ਡਾਟਾ ਲੀਕ
PII ਦਾ ਪਰਦਾਫਾਸ਼ (ਕੁਦਰਤੀ ਭਾਸ਼ਾ, API ਵਿੱਚ ਹੇਰਾਫੇਰੀ ਅਤੇ ਵੱਖ-ਵੱਖ ਇਨਕੋਡਿੰਗਾਂ ਰਾਹੀਂ)
SQL ਇੰਜੈਕਸ਼ਨ
ਸਿਸਟਮ ਪ੍ਰੌਂਪਟ ਓਵਰਰਾਈਡ
ਉਸ ਸ਼ੁਰੂਆਤੀ ਜਾਂਚ ਦੌਰਾਨ ਅਸੀਂ ਮੌਜੂਦਾ ਸਿਸਟਮ ਵਿੱਚ ਦੋ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪਛਾਣੀਆਂ: ਕਈ ਇਰਾਦਿਆਂ ਵਾਲੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਅਤੇ ਇਨਕੋਡ ਕੀਤੇ ਪ੍ਰੌਂਪਟਾਂ ਦੀ ਵਰਤੋਂ।
ਕਈ ਇਰਾਦਿਆਂ ਵਾਲੀਆਂ ਪੁੱਛਗਿੱਛਾਂ: ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਜਾਇਜ਼ ਅਤੇ ਖ਼ਤਰਨਾਕ ਮੰਗਾਂ ਇਕੱਠੀਆਂ ਹੋਣ। ਉਦਾਹਰਨ ਲਈ: “ਸ਼੍ਰੇਣੀ ਮੁਤਾਬਕ ਮੇਰਾ ਖ਼ਰਚ ਦਿਖਾਓ ਅਤੇ [ਖ਼ਤਰਨਾਕ SQL] ਵੀ ਚਲਾਓ।” ਐਪਲੀਕੇਸ਼ਨ ਖ਼ਤਰਨਾਕ ਇਰਾਦੇ ਨੂੰ ਫੜ ਨਹੀਂ ਰਹੀ ਸੀ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਗਲੀ ਡਾਟਾ ਪਰਤ ਦੇ ਸੁਰੱਖਿਆ ਉਪਾਵਾਂ ’ਤੇ ਨਿਰਭਰ ਸੀ। ਇਹ ਤਹਿਖ਼ਾਨੇ ਵਿੱਚ ਪਈ ਤਿਜੋਰੀ ’ਤੇ ਭਰੋਸਾ ਕਰਕੇ ਘਰ ਦਾ ਮੁੱਖ ਦਰਵਾਜ਼ਾ ਖੁੱਲ੍ਹਾ ਛੱਡਣ ਵਰਗਾ ਹੈ।
ਇਨਕੋਡਿੰਗ: ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਜੋ Base64, Hex, LeetSpeak ਅਤੇ ਸਮਰੂਪ ਅੱਖਰਾਂ ਵਿੱਚ ਇਨਕੋਡ ਕੀਤੀਆਂ ਹੋਣ। ਸਿਸਟਮਾਂ ਲਈ ਖ਼ਤਰਨਾਕ ਇਰਾਦੇ ਨੂੰ ਛਾਣ ਕੇ ਕੱਢਣਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ। ਭਾਵੇਂ ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਇਨ੍ਹਾਂ ਪੁੱਛਗਿੱਛਾਂ ਨੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਉਜਾਗਰ ਨਹੀਂ ਕੀਤਾ, ਪਰ ਇਨ੍ਹਾਂ ਕਾਰਨ ਸਿਸਟਮ ਕਾਫ਼ੀ ਅਸਥਿਰ ਹੋਇਆ, ਜਿਵੇਂ ਮਨਘੜਤ ਜਵਾਬ, ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਖ਼ਤਰਨਾਕ SQL ਦੁਹਰਾ ਕੇ ਦੇਣਾ ਅਤੇ ਇਰਾਦੇ ਦਾ ਉਲਝਿਆ ਵਰਗੀਕਰਨ।
ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਜਾਂਚ ਦੇ ਨਤੀਜਿਆਂ ਨੇ ਇਹ ਦਿਖਾਇਆ:
ਸਮੇਂ ਸਬੰਧੀ ਮਨਘੜਤ ਜਵਾਬ: ਮਾਡਲ ਵੱਲੋਂ ਭਰੋਸੇ ਨਾਲ ਦੱਸੀਆਂ ਪਰ ਘੜੀਆਂ ਹੋਈਆਂ ਮਿਤੀਆਂ, ਲੈਣ-ਦੇਣ ਦੇ ਸਮਾਂ-ਚਿੰਨ੍ਹ ਜਾਂ ਸਮਾਂ-ਸੀਮਤ ਸਾਰ—ਵਿੱਤੀ ਸੰਦਰਭ ਵਿੱਚ ਇਹ ਵੱਡਾ ਜੋਖਮ ਹੈ, ਕਿਉਂਕਿ ਗ਼ਲਤ ਮਿਤੀ ਦੇ ਆਧਾਰ ’ਤੇ ਗਾਹਕ ਦੀ ਕਾਰਵਾਈ ਦੇ ਅਸਲ ਨਤੀਜੇ ਹੋ ਸਕਦੇ ਹਨ
ਵਰਤੋਂਕਾਰ ਨੂੰ ਖ਼ਤਰਨਾਕ SQL ਦੁਹਰਾ ਕੇ ਦੇਣਾ, ਜੋ ਮੈਮੋਰੀ ਵਿੱਚ ਜ਼ਹਿਰੀਲਾ ਡਾਟਾ ਭਰਨ ਦੇ ਜੋਖਮ ਕਾਰਨ ਚਿੰਤਾਜਨਕ ਹੈ
ਇਰਾਦੇ ਦਾ ਉਲਝਿਆ ਵਰਗੀਕਰਨ
ਵਿਗੜਿਆ ਹੋਇਆ ਆਉਟਪੁੱਟ ਸਰੂਪ
ਇਨ੍ਹਾਂ ਖੋਜਾਂ ਦੇ ਆਧਾਰ ’ਤੇ ਅਸੀਂ ਆਪਣਾ ਧਿਆਨ ਕੁਝ ਖ਼ਾਸ ਖੇਤਰਾਂ ਤੱਕ ਸੀਮਤ ਕੀਤਾ। SQL ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਇਨਕੋਡਿੰਗ ਟੈਸਟਾਂ ਨੂੰ ਘੱਟ ਤਰਜੀਹ ਦਿੱਤੀ ਗਈ, ਕਿਉਂਕਿ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਉਨ੍ਹਾਂ ’ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਸੀ। ਇਸ ਦੀ ਬਜਾਏ ਅਸੀਂ ਸਭ ਤੋਂ ਕਾਮਯਾਬ ਹਮਲਾ-ਮਾਰਗਾਂ ’ਤੇ ਧਿਆਨ ਦਿੱਤਾ: PII ਦਾ ਪਰਦਾਫਾਸ਼ ਅਤੇ ਵੱਖ-ਵੱਖ ਸੈਸ਼ਨਾਂ ਵਿਚਕਾਰ ਡਾਟਾ ਲੀਕ।
ਦੂਜੇ ਦੌਰ ਦੀ ਸਭ ਤੋਂ ਹੈਰਾਨੀਜਨਕ ਖੋਜ ਬੇਹੱਦ ਸਧਾਰਨ ਸੀ: ਅਕਸਰ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਵੀ ਚਲਾਕੀ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ।
ਕਈ ਮਾਮਲਿਆਂ ਵਿੱਚ ਜਾਇਜ਼ ਲੱਗਣ ਵਾਲੀ ਬੇਨਤੀ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਅੰਦਰੂਨੀ ਡਾਟਾ ਸਿਰਫ਼ ਮੰਗਣਾ ਹੀ ਸਿਸਟਮ ਨੂੰ ਉਹ ਉਜਾਗਰ ਕਰਨ ਲਈ ਰਾਜ਼ੀ ਕਰਨ ਵਾਸਤੇ ਕਾਫ਼ੀ ਸੀ। ਸਧਾਰਨ ਪੁੱਛਗਿੱਛਾਂ ਦੇ ਜਵਾਬਾਂ ਵਿੱਚ ਅੰਦਰੂਨੀ IDs ਅਤੇ ਸਿਸਟਮ ਖੇਤਰਾਂ ਦੇ ਹਵਾਲੇ ਆ ਜਾਂਦੇ ਸਨ, ਜੋ ਅੰਤਿਮ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਕਦੇ ਨਹੀਂ ਦਿਸਣੇ ਚਾਹੀਦੇ।
ਹੋਰ ਡੂੰਘੀ ਜਾਂਚ ਤੋਂ ਪਤਾ ਲੱਗਾ ਕਿ ਇਹ ਸਿਰਫ਼ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਦੀ ਨਾਕਾਮੀ ਨਹੀਂ ਸੀ। ਅਗਲੀ ਟੈਕਸਟ-ਤੋਂ-SQL ਸੇਵਾ ਅਜਿਹੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਬਣਾ ਰਹੀ ਸੀ ਜੋ ਲੋੜ ਤੋਂ ਵੱਧ ਖੇਤਰ ਮੰਗਦੀਆਂ ਸਨ, ਅਤੇ ਉਸ ਦੇ ਵਿਆਖਿਆਤਮਕ ਜਵਾਬਾਂ ਵਿੱਚ ਉਸ ਡਾਟੇ ਦੇ ਹਵਾਲੇ ਸਨ ਜਿਸ ’ਤੇ ਪਾਬੰਦੀ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ। ਇਸ ਨਾਲ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਇੱਕ ਅਸਲ ਦਰਾਰ ਸਾਹਮਣੇ ਆਈ। ਅਜਿਹੀ ਕਮਜ਼ੋਰੀ ਉਦੋਂ ਹੀ ਦਿਸਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਨੂੰ ਇਕੱਲੇ ਪਰਖਣ ਦੀ ਬਜਾਏ ਪੂਰੇ ਤਕਨੀਕੀ ਢਾਂਚੇ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ।
ਮਾਡਲ ਦੀ ਨਹੀਂ, ਪੂਰੇ ਸਿਸਟਮ ਦੀ ਰੈਡ ਟੀਮਿੰਗ ਕਰੋ। LLM ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਪਰਖਣ ਨਾਲ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਸਥਿਤੀ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਪਤਾ ਲੱਗਦਾ ਹੈ। ਪੂਰੇ ਤਕਨੀਕੀ ਢਾਂਚੇ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਅੰਤ ਤੱਕ ਉਸੇ ਤਰ੍ਹਾਂ ਜਾਂਚ ਕਰੋ ਜਿਵੇਂ ਕੋਈ ਵਰਤੋਂਕਾਰ ਉਸ ਨਾਲ ਕੰਮ ਕਰੇਗਾ।
ਇਨਪੁੱਟ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂਚ LLM ਤੋਂ ਪਹਿਲਾਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਨਕੋਡ ਕੀਤੀਆਂ ਪੁੱਛਗਿੱਛਾਂ, ਕਈ ਇਰਾਦਿਆਂ ਵਾਲੇ ਹਮਲੇ ਅਤੇ ਇੰਜੈਕਸ਼ਨ ਦੀਆਂ ਬੁਨਿਆਦੀ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਬਾਹਰੀ ਹੱਦ ’ਤੇ ਹੀ ਫੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਅਗਲੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਹਵਾਲੇ ਕੀਤਾ ਜਾਵੇ।
ਸਿਸਟਮਾਂ ਦੇ ਜੋੜਾਂ ’ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਕਈ ਸੇਵਾਵਾਂ ਵਾਲੇ ਢਾਂਚਿਆਂ ਵਿੱਚ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਕਮਜ਼ੋਰੀਆਂ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰਲੀਆਂ ਦਰਾਰਾਂ ਵਿੱਚ ਲੁਕੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਕਿਸੇ ’ਤੇ ਭਰੋਸਾ ਨਾ ਕਰਨ ਦਾ ਅਰਥ ਸੱਚਮੁੱਚ ਕਿਸੇ ’ਤੇ ਭਰੋਸਾ ਨਾ ਕਰਨਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਪਰਤ ’ਤੇ ਹਰ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕਰੋ।
ਸਧਾਰਨ ਹਮਲੇ ਵੀ ਕਾਮਯਾਬ ਹੁੰਦੇ ਹਨ। ਗੁੰਝਲਦਾਰ ਜੇਲ੍ਹਬ੍ਰੇਕ ਸੁਰਖੀਆਂ ਬਣਦੇ ਹਨ, ਪਰ ਕਈ ਵਾਰ ਤੁਸੀਂ ਸਿਰਫ਼... ਪੁੱਛ ਸਕਦੇ ਹੋ। ਜੇ ਕਿਸੇ ਆਮ ਜਾਇਜ਼ ਪੁੱਛਗਿੱਛ ਵਿੱਚ ਅੰਦਰੂਨੀ ਪਛਾਣਕਰਤਾ ਸ਼ਾਮਲ ਕਰਨ ’ਤੇ ਤੁਹਾਡਾ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਉਜਾਗਰ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਹੈ।
ਸਮਝੋ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਸ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ। ਜਾਣੇ-ਪਛਾਣੇ ਹਮਲਾ-ਤਰੀਕਿਆਂ ਨੂੰ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਉਪਾਵਾਂ ਦੀ ਬਜਾਏ LLM ਦੀ ਆਪਣੀ ਸਿਖਲਾਈ ਹੀ ਫੜ ਸਕਦੀ ਹੈ। ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਨਿਯੰਤਰਣ ਵਰਤੇ ਜਾ ਰਹੇ ਹਨ, ਆਪਣੀ ਰੈਡ ਟੀਮਿੰਗ ਵਿੱਚ ਨਿਗਰਾਨੀ ਯੋਗਤਾ ਸ਼ਾਮਲ ਕਰੋ।
ਪਾਬੰਦੀਆਂ ਵਾਲੇ ਮਾਹੌਲਾਂ ਲਈ ਰਚਨਾਤਮਕ ਹੱਲ ਚਾਹੀਦੇ ਹਨ। ਕਸਟਮ ਪ੍ਰੋਵਾਈਡਰ ਅਤੇ ਸਥਾਨਕ ਮਾਡਲਾਂ ਲਈ ਸਹਾਇਤਾ, ਵਿਸ਼ੇਸ਼ ਕਲਾਊਡ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ ਵੀ ਸਾਰਥਕ ਰੈਡ ਟੀਮਿੰਗ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ। ਪਰ ਇਸ ਨਾਲ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਸੀਮਾਵਾਂ ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ।
ਰੈਡ ਟੀਮਿੰਗ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਕਰਨ ਵਾਲਾ ਕੰਮ ਨਹੀਂ ਹੈ। ਇਹ ਦੁਹਰਾਓ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਇਸ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਦੇ ਵਿਕਾਸ ਨਾਲ ਇਸ ਨੂੰ ਵੀ ਵਿਕਸਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੱਲ੍ਹ ਮਹੱਤਵਪੂਰਨ ਹੋਣ ਵਾਲੇ ਹਮਲੇ ਅੱਜ ਮਹੱਤਵਪੂਰਨ ਹਮਲਿਆਂ ਵਰਗੇ ਨਹੀਂ ਹੋਣਗੇ।
ਨਿਯੰਤ੍ਰਿਤ ਮਾਹੌਲਾਂ ਵਿੱਚ AI ਸਿਸਟਮਾਂ ਦੀ ਜਾਂਚ-ਪੜਤਾਲ ਘਟੇਗੀ ਨਹੀਂ, ਸਗੋਂ ਹੋਰ ਵਧੇਗੀ। ਜਿਹੜੀਆਂ ਸੰਸਥਾਵਾਂ ਸੁਰੱਖਿਆ ਜਾਂਚ ਨੂੰ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਸਿਰਫ਼ ਇੱਕ ਰਸਮੀ ਚੈੱਕਬਾਕਸ ਦੀ ਬਜਾਏ ਇੱਕ ਨਿਰੰਤਰ ਅਨੁਸ਼ਾਸਨ ਵਜੋਂ ਲੈਂਦੀਆਂ ਹਨ, ਉਹ ਇਸ ਜਾਂਚ-ਪੜਤਾਲ ਦਾ ਸਾਹਮਣਾ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਕਰ ਸਕਣਗੀਆਂ ਅਤੇ ਗਾਹਕਾਂ ਦਾ ਭਰੋਸਾ ਗੁਆਉਣ ਵਾਲੀਆਂ PR ਤਬਾਹੀਆਂ ਤੋਂ ਬਚ ਸਕਣਗੀਆਂ।